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:
- domain-adaptive pre-training on registered-document text;
- an instruction "bridge" stage that teaches what the document wording means (roles, IDs, dates);
- 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_nameof 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.