gemma3_4b_deedexp

This model reads the OCR text of a Karnataka property registration document (Kannada + English) and returns one JSON record: the buyers, the sellers, property details and document details.

It is a fine-tune of Gemma 3 4B-it, trained in three stages:

1. domain-adaptive pre-training on registered-document text;
2. an instruction "bridge" stage that teaches what the document wording means (roles, IDs, dates);
3. supervised extraction training, with seven prompt styles, each also in a two-request split form (parties / transaction + property).

Current version: v9.3, for testing. Feedback and failure cases are welcome. Contact: kamananand98@gmail.com.

Versions

main always holds the latest release. Every release is also a git tag, so you can pin one: AutoModelForCausalLM.from_pretrained("anandkaman/gemma3_4b_deedexp", revision="v9.3").

tag	date	main change
v9.3	2026-10-08	micro prompt as default; split mode (parties / transaction + property) for many-party documents; corrected reference labels
v8	2026-10-05	first public release

This repo was named gemma3_4b_deedexp_v8 before 2026-10-08; the old name redirects here.

Output schema

{
 "buyer_details":  [{"name", "gender": "Male|Female|null", "father_name", "aadhaar_number", "pan_card_number", "address", "state"}],
 "seller_details": [ ...same fields... ],
 "property_details": {"schedule_c_property_address", "state", "sale_consideration", "registration_fee", "paid_in_cash": "yes|no"},
 "document_details": {"transaction_date": "YYYY-MM-DD", "registration_office"}
}

Main rules the model was trained on. The full list is in prompts/short_full.txt.

• Roles come from what the document says each party does (sells or receives), not from the order they are printed in. Confirming and consenting parties are never sellers. Minors listed as their own numbered party are parties.
• transaction_date = the document's registration date from the Sub-Registrar endorsement, not the execution date.
• father_name of a married woman = her husband's name when her own description gives it (W/o).
• IDs are copied only for the person they are printed for. Invalid, masked or partial IDs → null. IDs are never repaired. An address keeps a PIN only if it is printed in that person's own address.
• Missing or unreadable → null. The model is trained to leave a value out rather than guess it.

How to call

One request per document: a single user message = the prompt text + "\n\n" + the document's OCR text. Use greedy decoding and up to 5,000 new tokens.

prompt file	status
prompts/micro_full.txt	default (about 350 tokens). The best single prompt in our tests and the one used for every number on this card.
prompts/micro_parties.txt + prompts/micro_txn_property.txt	split mode, recommended for documents with many parties. Two requests on the same OCR text: the first returns buyer_details + seller_details, the second property_details + document_details; merge the two objects.
prompts/short_full.txt, prompts/medium_full.txt	alternatives. Longer wordings of the same rules; they scored a little below micro.

All prompts are part of the training data. Use them exactly as written: the model was trained on that text, so edited prompts can lower accuracy.

pip install "transformers>=4.50" torch accelerate
python inference.py document_ocr.txt                    # default: micro prompt, one request
python inference.py document_ocr.txt --split            # split mode, two requests (many parties)
python inference.py document_ocr.txt --prompt short     # alternative single prompt

Use the tokenizer's chat template as provided. It already starts with <bos>, so do not add a second one. Training inputs were up to 20,480 tokens (prompt + OCR + answer).

Evaluation (preliminary)

The test set is 78 held-out documents from many Sub-Registrar offices, with corrected reference labels. Default micro prompt, one request per document. Scores are F1 or exact match, in %:

field	v9.3 (micro)	v8 (short)
valid JSON	78 / 78	77 / 78
transaction_date	98.7	98.1
sale_consideration	98.7	98.1
paid_in_cash	98.7	91.6
buyer count exact	98.7	94.9
aadhaar_number	97.0	96.2
registration_office	96.2	94.2
registration_fee	96.2	96.8
pan_card_number	95.2	91.9
names	89.4	90.9
father_name	89.2	88.3
seller count exact	88.5	88.5

Both columns are scored against the same corrected labels, so they differ from the numbers on the v8 card.

Split mode on documents with many parties. On the 34 held-out documents with the most parties (185 buyers and sellers, up to 11 sellers in one document), split mode found 168 of the 185 parties, against 163 for the single request. It got the exact seller and buyer count on 64 of 68 lists, against 61, and it was never worse on any document. In one document the single request also listed a heading as a seller; split mode did not. Price, fee, cash and date were the same in both modes.

Known weak spots:

• Long seller lists: a single request can stop the list early. Use split mode for these documents.
• Registration fee in Indian digit grouping (8,00,000.00) is sometimes read ten times too large (2 of 78). Check the fee against the document.
• Minors who sell through a guardian are sometimes left out.

Limitations and responsible use

• The model works on OCR text, so OCR errors in IDs or names carry through. Always check extracted IDs against the document.
• It was trained on Karnataka property transfer documents. Other document types (agreements, mortgages, partitions) and other states are out of scope.
• The training documents contain personal data. Use the model only on documents you are authorised to process, and do not use it to look up or reconstruct information about individuals.

License

This model is a derivative of Gemma 3 and is distributed under the Gemma Terms of Use. Use is subject to the Gemma Prohibited Use Policy.