Build1 distinct publisher3 min readUpdated
A scanned 346-page Kannada novel broke pure vector search. Hybrid BM25 plus dense retrieval with RRF, and a regex page router, took reported faithfulness to 0.92.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
A developer has published a rebuild of a retrieval-augmented generation app built over a scanned 346-page Kannada novel, Heli Hogu Kaarana by Ravi Belagere, along with the architecture and the evaluation numbers [1]. The argument worth taking seriously is the boring one: the same LLM sat behind both the failing and the working version, and the difference was entirely in retrieval architecture [2].
Version 1 was the default recipe: chunk, embed with multilingual MiniLM, store in ChromaDB, retrieve top-5, prompt Gemini [3]. It demoed well and evaluated terribly [4]. The tell was a question about page 120 answered confidently with a passage from a different chapter [5].
Three properties of the corpus explain the failure. The book existed only as a scanned physical object, and Kannada OCR is hard because of ligatures, conjunct characters and noisy print [6]. Kannada is agglutinative, so a name like Himavant appears in several inflected forms depending on grammatical case, and the author's contention is that multilingual embeddings trained mostly on high-resource data compress those forms into a weak, inconsistent semantic space [7]. Literary text is sparse and specific, and rare colloquialisms, proper nouns and page references are precisely where cosine similarity fails [8]. Under dense-only retrieval, proper nouns vanished and page queries returned whatever felt close [9]. Generic models have essentially never seen this book, so with bad retrieval they invent rather than retrieve [10].
The fix has two load-bearing parts. Sparse BM25 runs alongside dense retrieval and the two ranked lists are fused with Reciprocal Rank Fusion at k = 60, followed by a cross-encoder rerank with a confidence guardrail, then Gemini with a Groq fallback [11][12]. Separately, a deterministic regex router classifies exact-page queries and bypasses semantic search entirely, resolving them through a metadata lookup in about milliseconds, which the author reports as 100% precision with zero hallucination surface [13]. That precision is a property of the router's classifier, not of the index: a page query the regex fails to recognise falls back to the semantic path, where the old failure mode still lives [14]. The stated design principle is that no single retrieval signal makes the final decision [15].
Ingestion carries the rest of the weight: pdf2image at 300 DPI, OpenCV denoising and thresholding, Surya OCR, indic-nlp normalization, and semantic chunking with page metadata attached to every chunk [16]. The author calls the metadata the quiet hero, because it is what makes citation possible and what the deterministic router runs on [17].
Reported results are 0.92 RAGAS faithfulness and 0.89 context recall on a 50-query golden set, at 2.8s P50 end to end on serverless [18]. Read those with the denominator in view: on 50 queries, a single query is worth 0.02, so the third digit is noise [19]. This is also one self-reported build, and the supplied write-up gives no v1 RAGAS scores to compare against, only the qualitative claim that v1 evaluated badly [20].
What to watch: whether OCR quality caps the whole system, since the author's own rule is that retrieval is only as good as ingestion [21]; whether the regex router's coverage holds as query phrasing drifts away from the patterns it was written for [14]; and whether the confidence guardrail actually refuses, or just passes low-confidence context through to a fluent answer [12].
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
Ingestion used pdf2image at 300 DPI, OpenCV denoising and thresholding, Surya OCR for Kannada extraction, indic-nlp normalization for Unicode and ligature cleanup, and semantic chunking with page metadata attached to every chunk.
The author built a RAG agent for Heli Hogu Kaarana, a Kannada novel by Ravi Belagere, digitized from a scanned 346-page PDF, and published the ingestion pipeline, retrieval architecture and evaluation numbers.
The same LLM sat behind both v1 and v2; the author states the difference was entirely in retrieval architecture, and that the LLM was never the bottleneck.
V1 architecture was chunk, embed with multilingual MiniLM, store in ChromaDB, retrieve top-5, prompt Gemini.
The author stopped trusting the system when it confidently answered a question about page 120 with a passage from an entirely different chapter, with no citation and full confidence.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Detailed architecture, unverifiable results
The architectural and ingestion detail is unusually specific for a single-source field note — named tools per stage, an ASCII pipeline diagram, the RRF formula with k = 60 and partial code, and an explicit self-limitation about cross-inflection matching. But every result is author-reported with no repository, golden set, judge configuration, OCR error rate, router test set or v1 baseline, and there is exactly one publisher and one author in the cluster, so nothing here can be independently checked.
One personal single-book deployment
Supplied material evidences a single hobby-scale system over one 346-page novel, self-described as running on serverless with a reported P50 latency, plus one self-run evaluation. There is no user count, download, fork, third-party deployment, or replication of the pattern anywhere in the cluster, so adoption is real but minimal.
Headline overshoots the measured path
The framing claims — pure vector search fails, hybrid RRF fixed it, 100% precision and zero hallucination surface — are stronger than what is shown: the precision figure covers only the query class the regex recognises, everything else falls back to the path that produced the original wrong-chapter answer, and the improvement has no published v1 baseline. The gap is moderate rather than severe because the author volunteers the sharpest counterweight themselves, stating that BM25 does not solve cross-inflection matching and that the problem remains partially open, and because the design reasoning stands independently of the numbers.
Self-promotional practitioner post, no vendor tie disclosed
The source is a personal developer-platform write-up whose author is the subject of the result, so there is a straightforward credibility and portfolio incentive to present the rebuild as a clean success — which plausibly explains why final metrics are published but v1 metrics and artifacts are not. Offsetting this, several commercial tools are named (Gemini, Groq, Sarvam, ChromaDB, Surya) with no sponsorship, affiliation or paid placement disclosed or implied anywhere in the supplied material, and the author volunteers limitations against their own thesis.
Confident on design, not on results
Confidence in what the article says and in the structural reading of its limits is high, because the architecture is described explicitly and the coverage gap in the router is visible in the author's own diagram. Confidence in whether the system performs as reported is low: one publisher, one self-reporting author, no artifacts, no baseline, and a 50-query evaluation set.
build
A RAG demo becomes a product at the tenant boundary, not the retriever1 distinct publisher
build
Semantic code search over a monorepo is now a plumbing job, and the plumbing is the hard part1 distinct publisher
build
Your RAG Cannot Find SKU-4471, And A Bigger Embedding Model Will Not Help1 distinct publisher
build
BM25 lost worst on the queries full of file paths. In 54% of them, the path is not in the answer1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 18, 2026