Building a Production RAG Knowledge Base: DeepDOC Parsing, Hybrid Retrieval, and Pixel-Level Source Tracing
Most RAG systems choke on scanned PDFs, long-tail domain terms, and unverifiable answers. This architecture shows a practical path to production: page-level visual parsing with memory bounds, two-granularity tokenization for specialized vocabulary, and citation anchors that survive all the way to the front end.
This post breaks down the full architecture of an enterprise RAG knowledge base built for mineral exploration and engineering standards Q&A. The write path is driven by a Canvas DSL orchestration engine over NATS JetStream queues, splitting ingestion into six serial stages: queueing, metadata read, parsing, chunking, optional LLM extraction, and tokenization/vectorization. The authors highlight a common bottleneck: with default single-worker concurrency, tasks often wait 7 minutes in queue for 3 minutes of execution, so tuning worker count matters more than micro-optimizing single nodes.
The parser routes Office documents through lightweight AST extraction, but PDFs get the heavy treatment via a Go port of DeepDOC. Each page goes through a 216 DPI render, OCR detect, DLA layout analysis with 10 semantic labels, TSR table recognition, and a zero-output zoom retry. A key design choice is forking between text-layer PDFs and scanned pages: normal PDFs reuse embedded characters by merging them into detected line boxes, while scanned pages run full OCR recognition in batches of 16. Memory explosions from large fold-out geological maps are prevented by a triple defense: retry only on zero output, a 48M pixel budget pre-check, and a hard clamp inside the renderer.
After parsing, the chunker applies four modes (general, QA, table, manual) with table header inheritance and hierarchical breadcrumbs. The tokenizer produces both coarse and fine-grained full-text tokens plus dense vectors, and supports optional LLM-generated keywords and reverse HyDE questions. Storage can be Elasticsearch or Infinity. On the read path, hybrid retrieval combines sparse keyword matching with dense kNN (default topK 1024), followed by a service-layer rescore (0.7 term weight, 0.3 vector weight) and optional Rerank on the top 64 candidates. The final response includes pixel-level bounding box coordinates that let users click a citation and jump directly to the highlighted table or figure in the original PDF.
The deepest engineering effort in this system goes into PDF parsing, not vector retrieval. The authors treat layout analysis and table recognition as the real bottlenecks for enterprise documents, and that focus is what makes the whole chain usable.
Using two-granularity tokenization for full-text search is a pragmatic alternative to relying solely on embeddings. It directly addresses the long-tail domain term problem without requiring a specialized embedding model.
The explicit memory budget of 48M pixels per rendered page is a concrete, sensible safeguard that most RAG systems skip. It prevents a single pathological scan from taking down the entire ingestion worker.
The 0.7/0.3 term/vector weight default shows a preference for precision over recall; combined with a Rerank stage and threshold filtering, it suggests real production queries need to avoid hallucinating wrong drill hole numbers.
The port of DeepDOC from Python to Go indicates that performance and memory control drove a rewrite rather than a wrapper. This is a pattern likely to repeat as visual parsing models mature.
The optional VLM plugin is positioned as a bolt-on for semantic understanding of figures, not a core component. That keeps the main pipeline cost predictable while opening a path to future richer indexing.