Anatomy of a Production RAG System: AI-Powered Title Validation for Indian Real Estate
A single missed defect in a property title can invalidate an entire transaction. We built AI to catch what humans miss across tens of thousands of documents in six languages — and the surprising part was that OCR, not the LLM, consumed the majority of engineering effort.
The Problem
A single missed defect in a property title — a revoked power of attorney, a forged partition deed, an uncleared mortgage — can invalidate an entire transaction. In India, verifying that risk means manually stitching together 12–18 documents per property, in whatever language and format each decade happened to produce. A trained legal reviewer takes 3-5 days per typical property. Complex titles with long ownership chains, GPA transfers, or family disputes stretch to weeks. Miss something, and you're exposed to litigation that outlasts the property's useful life.
We built a document intelligence system to automate the first pass of this validation. Not to replace lawyers — every property still received lawyer review — but to make them faster and less likely to miss something.
What We Actually Shipped
Over a thousand properties across six Indian metros (Bengaluru, Hyderabad, Chennai, Mumbai, Pune, and NCR). Tens of thousands of documents — sale deeds, encumbrance certificates, mortgage deeds, bank NOCs, revenue records, property tax receipts, mutation records — in six languages, spanning decades. A 12-week processing timeline where the human review queue, not the AI pipeline, was the bottleneck. What we didn't plan for: OCR — not LLMs or retrieval — consumed the majority of engineering effort.
What Makes Indian Property Documents Uniquely Hard for RAG
Multi-language documents are the norm, not the exception. A single property's document set in Bengaluru contains sale deeds in English, khata extracts in Kannada, revenue records with headings in English and content in Kannada, and sub-registrar endorsements stamped in both. The system needed to process documents in six languages (English, Hindi, Kannada, Telugu, Tamil, Marathi), often mixed within a single page.
Scan quality degrades with document age. A 2020 deed is digitally registered: clean text, structured layouts. A 2005 deed is a 200 DPI scan of a typed document with a hand-stamped registrar endorsement. A 1990 deed is a photocopy of a photocopy. The worst we encountered: a 2015 scan that included a photograph of the original 1975 hand-written deed.
No standardized format across states. An encumbrance certificate from Karnataka looks nothing like one from Maharashtra. Revenue records are entirely different structures. Every document type, in every state, across every era required adaptive parsing. Template matching and fixed field extraction don't work here.
Architecture
We didn't start here. The initial system was a straightforward vector-only RAG pipeline with OpenAI for everything. It failed on identifier-heavy queries, cross-document reasoning, and multilingual inconsistencies. The architecture below reflects those failures. Every component is there because something simpler broke first.
Ingestion pipeline: S3 upload > ClamAV virus scan > ECS Fargate (OCR + language detection + classification) > Step Functions orchestration > chunking > embedding > pgvector + Elasticsearch + Neo4j.
Retrieval pipeline: Query > hybrid search (pgvector semantic + Elasticsearch BM25) > reciprocal rank fusion > cross-encoder re-rank > LLM generation with citations. For chain-of-title queries specifically, the system queries the Neo4j ownership graph first for structural analysis, then retrieves supporting document content from the vector store.
LLM stack: The system was built during 2024-25 using the models available at the time. The architectural patterns (structured extraction, selective long-context usage, batch cost optimization) transfer directly to newer model generations with improved accuracy. We started with OpenAI for everything. It was what we knew, and the fastest path to a working prototype. The migration happened after structured evaluation: Claude outperformed on consistent schema-following across hundreds of documents (OpenAI's extraction would drift after 50-60 documents in a batch). Gemini was added specifically for its long-context window. The final stack (Claude 3.5 Sonnet for bulk extraction, Opus for complex legal reasoning, Gemini 1.5 Pro for selective cross-document consistency checks, AI4Bharat IndicTrans2 for Indic-language translation) reflects months of experimentation, not an upfront architectural decision.
We chose pgvector over a dedicated vector database (we evaluated Qdrant) because at hundreds of thousands of chunks, PostgreSQL with composite indexes handled filtered semantic search without issues, and keeping embeddings alongside relational data made structured joins trivial. Every additional component in your stack is one more thing to monitor, and one more thing that can page you at 2 AM.
One component we did add: Neo4j for ownership graphs. Title verification is fundamentally a graph problem — who sold to whom, when, with what encumbrances — and the SQL workarounds we'd been building for chain-of-title analysis were becoming unmanageable. Neo4j made structural queries (is this chain unbroken? are there circular transfers?) trivial.
OCR Was the Hardest Engineering Problem
In most RAG tutorials, OCR is a solved problem. In Indian property documents, OCR consumed more engineering effort than the retrieval and generation stack combined. We learned this the hard way: if your OCR is 85% accurate, your entire downstream pipeline is compromised. Retrieval finds the wrong chunks. Extraction pulls the wrong values. The LLM writes confident conclusions on top of both. One example: a consideration amount of ₹45,00,000 (about $54,000) OCR'd as ₹54,00,000 — transposed digits that passed every downstream check because the number was plausible. The extraction was confident and the citation checked out. The number was still wrong. We only caught it during manual validation.
We ended up with a three-tier approach — a tiered OCR strategy: most pages handled by standard OCR, a small fraction escalated to multimodal LLMs (Gemini and Claude for text extraction from page images), and a review queue for the rest (handwritten sale deeds from the 1970s-80s, damaged documents, registrar stamps misread as deed content). The human review queue became the bottleneck for the entire 12-week processing timeline. The automated pipeline could have finished in under 5 weeks, but the review queue was never empty.
Where Naive RAG Broke
We started with sentence-boundary chunking, a reasonable baseline. Indian legal documents broke it immediately. A single sentence in a sale deed can span half a page, while a critical clause might be a numbered sub-item with no sentence terminator. We moved to clause-level detection, parsing the numbering schemes (Section 4.2.1(a)(iii)) that structure Indian legal documents.
Clause detection solved the obvious problem but revealed three deeper ones: property tax tables losing their headers across page breaks (so "What was the property tax paid in 2018-19?" returned a number with no context), cross-references turning into dead links between chunks, and OCR garbage being fed to the embedding model as if it were real content. The fix: tables kept as single chunks with repeated headers, cross-reference metadata linking related chunks, and OCR confidence scoring to route unreliable content to human review instead of the embedding model.
Sentence-boundary chunking, table headers lost across pages, cross-references turning into dead links, OCR garbage poisoning the embedding space. We hit all of them processing tens of thousands of documents: Chunking Strategy for Production RAG.
Hybrid Search
Semantic search alone failed on the queries that matter most in title validation. "Encumbrance certificate for survey number 45/3?" Semantic search returned ECs for nearby survey numbers because the numbers embed similarly. "Sale deed from Sharma to Patel?" Proper nouns ranked poorly. "Bank NOC for HDFC loan account ending 4521?" Pure keyword match territory.
Embeddings are designed to capture semantic similarity — not exact identity. In legal and financial domains, identity matters more than similarity. The hybrid approach recovered the precision that legal validation demands. If your domain has precise identifiers — survey numbers, registration numbers, account numbers, case numbers — hybrid search is not optional.
"Encumbrance certificate for survey number 45/3" returned 45/2, 45/4, and 46/3. "Sale deed from Sharma to Patel" returned a different Sharma and a Patil. If your domain has precise identifiers, pure semantic search will burn you: When Semantic Search Fails.
Multi-Language Entity Resolution
Translation wasn't enough. The same person might appear as "Lakshmi Narayana" in one document, "ಲಕ್ಷ್ಮೀ ನಾರಾಯಣ" in Kannada script in another, and "Laxmi Narayan" in a third. Translating the Kannada produces "Lakshmi Narayana," but that still doesn't match "Laxmi Narayan." This isn't a translation problem. It's an entity resolution problem.
Indian naming conventions make it worse: patronymic naming, inconsistent transliteration, initials expanding differently ("S. Raghavan" vs "Srinivasa Raghavan"). Our entity resolution combined fuzzy matching across transliteration variants and spelling inconsistencies, with relationship qualifiers ("S/o", "W/o", "D/o") as disambiguation features. Two people named "Ramesh Kumar" are distinguished by "Ramesh Kumar S/o Gopal Kumar" versus "Ramesh Kumar S/o Venkatesh." 90% of name pairs auto-resolved correctly. The roughly 3-4% false-match rate was caught downstream: the Neo4j ownership graph flags structurally impossible chains, and lawyers reviewing the title flow chart spot the errors.
Security and Validation
Property documents contain Aadhaar numbers, PAN details, and bank account information. Access control had to be architecturally enforced, not prompt-enforced. We implemented pre-retrieval filtering: every vector query includes metadata filters restricting results to documents the querying user is authorized to access. The vector database never returns a chunk the user shouldn't see. Post-retrieval filtering leaks information through latency patterns and result counts. We avoided it entirely.
A housing finance company's CISO sent us a detailed security assessment. We could answer maybe a third of it. The deal stalled for weeks. What it took to unstall it: The AI Security Questions Enterprise Buyers Ask.
The system was never autonomous. Every property still received lawyer review. The flag confirmation rate stabilized at 85-88%, meaning most defects the system flagged were confirmed as genuine issues by lawyers.
The incident that justified this caution: in week 6, the system cleared a property where a General Power of Attorney had been revoked by a subsequent registered deed. The OCR processed the revocation deed correctly, but the document classifier tagged it as "general correspondence," a catch-all category that didn't feed into the chain-of-title analysis. A lawyer caught it because the revocation deed appeared in the document list but wasn't referenced in the title flow chart. We added "deed of revocation" as a classification category, re-processed the batch, and found two more properties with the same misclassification. This is the kind of failure that's invisible in staging and only surfaces on real documents.
Does the Math Work?
The AI reduced analysis cost dramatically. It did not reduce total cost by the same margin, because legal verification still required human review.
The analysis layer — document collection, classification, extraction, chain-of-title mapping — saw per-property cost drop by over 95% compared to the manual baseline (tens of thousands of rupees — a few hundred US dollars — per property). Batch API pricing for LLM calls kept inference costs low.
The workflow layer tells the real story. Every property still went through lawyer review. But lawyers worked 40-50% faster with AI-prepared summaries, flagged defects, and pre-built title flow charts. Net reduction in total cost per property: 35-50%.
Where the system helped most: document collection and organization (50-70% time saved) and chain-of-title analysis (30-50%). Where it barely helped: external verification at sub-registrar offices and courts (10-15%). No document intelligence system can substitute for a clerk pulling a dusty register in a taluk office.
This only works when document volume is high enough to amortize OCR infrastructure and system costs. Below a few hundred properties, manual review with basic tooling remains cheaper.
Lessons
If you're building RAG for regulated domains, this is the hierarchy that matters:
Garbage OCR → garbage retrieval → confident hallucinations → legal risk. Retrieval failures are silent and plausible. Generation issues are the least of your problems.
60% of our debugging time was spent upstream of the LLM.
- Chunk by document structure, not token count. Legal documents have semantic boundaries that must be respected.
- Hybrid search is not optional for precision-critical applications. Semantic-only retrieval returns plausible wrong answers on exact-match queries.
- OCR is your real bottleneck, not the LLM. Budget 40% of your engineering effort here.
- Pre-retrieval access control or rebuild later. Post-retrieval filtering is a security compromise that gets harder to fix as you scale.
- Multi-language is an entity resolution problem, not just translation. Fuzzy matching trained on naming conventions matters more than the LLM choice.
- Title verification is fundamentally a graph problem. Neo4j made chain-of-title analysis dramatically cleaner than the SQL workarounds we'd been building.
- Don't stuff raw documents into long-context windows. Extract structured data separately, compare programmatically, use long context selectively for ambiguities that need the full document text.
- Be honest about where AI helps and where it doesn't. Overselling AI's capability in a legal workflow destroys trust with the people who actually use the system.
While the domain here is Indian real estate, the failure modes generalize to any system dealing with multi-document reasoning, identifier-heavy queries (financial, legal, healthcare), or low-quality scanned inputs. The specific documents change. The architecture problems don't.
Content on this page may not be reproduced, distributed, or republished without prior written permission. Sharing links is encouraged. See our Terms of Use for details.