What Happened
Recent releases and implementations show RAG search moving beyond vector similarity alone. Qdrant 1.20 adds BM25 ranking over full-text payloads without requiring embeddings, a tokenizer for code search, faster indexing for nested filters, and vector-storage options including a 16-bit format that halves storage without reported accuracy loss [1].
An Elasticsearch demonstration turned a 56-page scanned planting guide into a searchable, citable source in under five minutes. OCR converted pages into structured Markdown; ingest-time chunking and embedding supported semantic search; and reciprocal rank fusion combined keyword and semantic results across the guide and a separate product catalog. The application grounded answers in highlighted passages with page markers and withheld product cards when the evidence did not support a recommendation [2].
Operational security remains part of search-system design. Following a certificate-authority compromise, Weaviate reported patching enterprise customers within six hours and completing its broader response in less than 17 hours [3].
Why It Matters to Businesses
Retrieval quality depends on the content and the question. Exact terms, identifiers and code often benefit from lexical search; paraphrased questions benefit from semantic search. Scanned documents add an earlier failure point: if OCR loses a table row or page reference, a strong retriever cannot recover it. Hybrid retrieval and visible citations help address different parts of that problem, but neither guarantees a correct answer [1][2].
Platform choice should follow workload requirements, not a blanket preference for a vector database. Teams evaluating LlamaIndex or LangChain for orchestration, and Weaviate, Pinecone, Qdrant, Milvus, Elasticsearch or Vespa for retrieval, should test their own documents, filters, update rates and access rules. Haystack is another option for assembling retrieval pipelines. The relevant comparison is end-to-end answer quality, latency, operating effort and cost.
Kimbodo Engineering Perspective
We would treat retrieval as a measurable application subsystem rather than an embedding API call. Separate document parsing, indexing, retrieval, evidence selection and answer generation so each stage can be tested and replaced. Keep keyword search where exact matches matter, add semantic search where it improves recall, and evaluate fusion against a single-method baseline before accepting its additional cost [1][2].
Citations should point to stored, page-level evidence, not merely appear in generated prose. Catalog recommendations need a separate eligibility check against actual catalog records. When evidence is weak or absent, the application should say so rather than fill the gap with a plausible answer [2].
How We Would Implement It
- Ingest: OCR scanned pages into structured text while preserving document IDs, page numbers, tables and provenance. Validate extraction on representative difficult pages before indexing [2].
- Index: Store chunks with page references, tenant and access-control metadata, and version IDs. Maintain lexical and semantic indexes; use payload or metadata filters for scoped retrieval. Evaluate compression against measured recall and storage savings before rollout [1].
- Retrieve: Run filtered keyword and vector searches, fuse their rankings, then pass a bounded set of source passages to the model. Search user documents and product or policy catalogs separately when their permissions or recommendation rules differ [2].
- Verify: Require answer claims and recommendations to map to retrieved passages or eligible catalog items. Return page citations and an explicit no-answer outcome when support is insufficient [2].
- Evaluate: Maintain a test set covering exact terms, paraphrases, scanned tables, conflicting passages, permission boundaries and unsupported questions. Track retrieval recall, citation accuracy, answer quality, latency and cost per request.
Risks, Costs and Security
OCR and embedding add ingest time and expense; hybrid queries and larger evidence sets add serving cost and latency. Compression can reduce vector storage, but should be judged against recall on the production workload rather than a general benchmark [1][2].
Apply access controls before retrieval results reach the model, isolate uploaded documents by tenant and document, and treat retrieved text as untrusted input that may contain prompt-injection instructions. Log source IDs and model decisions without exposing sensitive document content unnecessarily. Finally, keep search infrastructure and its dependencies within a tested patching process: Weaviate’s response illustrates how quickly a certificate-related incident can require coordinated customer and platform updates [3].
Where Kimbodo Comes In
Kimbodo builds and operates this in production for businesses — see our RAG Development Services practice, or Estimate My RAG System.
