From BM25 to RAG to GraphRAG to LAKEer: The Road to Trustworthy Information Retrieval

Each generation of information retrieval technology tackled the last one's blind spot: BM25 matched words, RAG found text, GraphRAG found connections. But each generation brought capabilities that the next one never fully replaced. That is why LAKEer combines keyword, vector, graph and table search across documents and images, then adds domain understanding and verification.

The running example: An engineer asks, "Which pumps at Site B had pressure faults last quarter, and are any still under warranty?" Follow-up: "What size bolts do I need to bolt the replacement pump down?" The bolt dimensions appear only on the pump's installation drawing, an image.

Stage 1: BM25 — "Match the exact words"

BM25 is classic keyword search (Robertson & Zaragoza, 2009). It scores documents by how often the query's words appear, with diminishing returns for repeated words, an adjustment for document length, and extra weight for rare words. It needs no training, only an index and two tuning parameters, and remains a robust baseline on modern retrieval benchmarks, though neural re-rankers beat it (BEIR, NeurIPS 2021).

Where BM25 still wins:

• Exact identifiers. Part numbers, error codes and names like "P-104" match precisely. That is why LAKEer keeps a keyword channel.

Where it breaks:

• Vocabulary mismatch. It matches words, not meaning. Example: The engineer asks about "pressure faults"; the maintenance log says "overpressure alarm." BM25 misses it. Search engines patch this with hand-maintained synonym lists (Elasticsearch synonym filter), but someone has to write and maintain them.

• Documents, not answers. It returns a ranked list of documents. Example: The engineer still has to read them, link each pump to its warranty, and filter by date.

• No sense of time. "Last quarter" is just two more words to match.

BM25 matches words, not meaning.

Stage 2: RAG — "Find similar text"

RAG closes that gap: it turns the question into a vector, pulls the most similar document chunks, and hands them to the LLM. It works when the answer sits in one chunk. Many enterprise questions don't.

Two steps are bundled here. Dense vector retrieval came first (DPR, EMNLP 2020); RAG added an LLM that writes the answer from what was retrieved (Lewis et al., NeurIPS 2020). Many production systems don't rely on vectors alone. Hybrid search merges BM25 and vector results, often with reciprocal rank fusion (Cormack et al., SIGIR 2009), and a re-ranker model re-scores the top hits (Nogueira & Cho, 2019). These steps improve which chunks come back. Most of the failure modes below remain, because they come from chunking, missing structure and unchecked generation.

Where RAG still breaks in 2026:

1. Broken co-reference. Length-based chunking fragments coreference and local references, and most RAG approaches still process chunks independently, ignoring coreference links across documents (CHOP, 2026).

   • Example: Doc A says "Dr. Patel led the Q3 pump audit." Doc B says "She recommended replacing P-104." RAG can't tell who "she" is.

2. Entity aliasing. Standard RAG evaluations can't tell whether a wrong answer came from retrieval, from generation, or from an entity-normalization mismatch, such as not recognizing "NYC" and "New York City" as the same entity (GRADE, Findings of EMNLP 2025).

   • Example: "P-104," "Pump 104," and "Site B main pump" look like three assets.

3. Multi-hop reasoning. The best-performing model tested (GPT-5) reached only 22.6% exact match on the hardest 4-hop questions (AgenticRAGTracer, ACL 2026). Prior analyses report that RAG systems near-perfect on single-hop benchmarks degrade significantly on multi-document reasoning (summarized in GRADE, 2025).

   • Example: Linking fault → pump → warranty needs three documents chained together.

4. Chunking loses context. Pipelines split documents into chunks of a few hundred tokens, so related facts can land in different chunks. Simply retrieving more context isn't a free fix: one study found answer quality dropped beyond roughly 2,500 tokens of retrieved context, with the exact threshold depending on the model (Bennani & Moslonka, 2026).

   • Example: The pump ID lands in one chunk, its warranty expiry in another.

5. No sense of time. Retrieval in modern RAG pipelines lacks temporal awareness (ChronoQA, Scientific Data 2025). Without time scoping, temporally irrelevant evidence floods retrieval and misleads generation (Han et al., 2025).

   • Example: "Last quarter" is just text, so RAG returns faults from any date.

6. Hallucination despite retrieval. In a 2026 preprint using synthetic patient cases, a basic RAG setup over raw clinical notes raised the rate of unsupported claims from 5.0% to 43.6% compared with no retrieval (Scanlin et al., medRxiv 2026, not peer-reviewed). In agentic pipelines, a hallucinated intermediate claim can propagate through later retrieval and reasoning steps (SoK: Agentic RAG, 2026). Legal research tools whose vendors claimed to avoid or eliminate hallucinations still hallucinated 17–33% of the time (Magesh et al., Journal of Empirical Legal Studies 2025).

   • Example: The LLM blends two reports and states a wrong fault date as fact.

7. Citations that don't back the claim. Citations raise users' trust even when the citations are random (Ding et al., AAAI 2025), and users favor answers with more citations even when the cited text is irrelevant to the claim (Search Arena, ICLR 2026).

   • Example: The answer cites the right report, but the report never says what the answer claims.

What works: With identical retrieval across systems, a claim-level verification pipeline still cut hallucination rates by 68% relative to the strongest baseline, from 11.3% to 3.6% on FinQA (FinGround, 2026).

RAG retrieves similar passages, not meaning.

Stage 3: GraphRAG — "Follow the connections"

GraphRAG extracts entities and relationships into a graph, so retrieval can hop across links. It links P-104 → located at → Site B → covered by → Warranty W-22. Graph-based variants can help: HippoRAG improved multi-hop retrieval recall by up to 20 points over standard retrievers (Recall@5 on 2WikiMultiHopQA; Gutiérrez et al., NeurIPS 2024), and Microsoft GraphRAG improved comprehensiveness and diversity over vector RAG on broad, corpus-wide questions (Edge et al., 2024). On standard multi-hop QA benchmarks, however, vanilla GraphRAG's results are mixed: sometimes slightly better than RAG, sometimes worse (Han et al., 2025; Zhou et al., VLDB 2025).

What it only partly fixes:

• Aliasing and co-reference depend on entity resolution at build time. Vanilla GraphRAG merges entities only when their title and type match exactly, with no fuzzy or semantic entity resolution, so "P-104" and "Pump 104" become separate nodes and the relationship between them never fires (Microsoft GraphRAG docs).

• Graph quality depends on an LLM guessing relationships without a domain schema, so errors get baked in. (LAKEer also extracts with an LLM, but when a domain ontology is loaded, it guides extraction.)

What vanilla GraphRAG doesn't fix:

• No business vocabulary: "fault," "alarm," and "trip" stay separate.

• Warranty dates in tables still can't be queried as data.

• No answer-time verification: grounding relies on prompt instructions, and the final answer is never checked against the evidence.

GraphRAG retrieves relationships, but trusts them blindly.

Stage 4: LAKEer — "Understand, retrieve, then verify"

LAKEer combines neural (LLM) and symbolic (knowledge graph, ontologies and business vocabulary) reasoning. In grounded mode, every answer passes claim-level verification before it is returned.

LAKEer's symbolic half has deep roots. Ontologies and the Semantic Web (Berners-Lee et al., 2001) and enterprise knowledge graphs (Hogan et al., ACM Computing Surveys 2021) captured domain meaning long before LLMs. GraphRAG has an LLM build the graph from scratch; LAKEer can let a curated domain ontology guide it.

1. Understands the question. With a domain ontology and business vocabulary loaded, LAKEer knows that P-104 and Pump 104 are the same asset, and that "fault", "alarm" and "trip" mean the same thing here — because the business defined them that way, not because a model guessed. It also holds the answer to what you asked for and what you asked it to avoid: a word limit, a bullet format, "leave out the 2023 figures". Linking "she" to Dr. Patel across documents, and turning "last quarter" into a date range, are on the roadmap.

2. Retrieves across many channels at once. Graph, vector, keyword, entity and table channels run together, including SQL over extracted tables. Warranty dates are queried as data, not guessed from text. Scanned documents, PDFs and the images inside them are converted to text and tables on ingestion, so their content is searchable alongside everything else. For the follow-up question, the bolt callouts printed on the pump's installation drawing become searchable text, so LAKEer can answer with the specified bolt size and cite the drawing. Adding documents is incremental — new material is processed, the corpus you already built is left alone.

3. Verifies claim by claim (ClaimGuard). Claims are checked against the evidence before an answer is released. Unsupported claims are corrected or the answer is regenerated, and when a claim cannot be verified, LAKEer says so rather than guessing. It also tells the difference between a real negative finding — "the agreement does not specify a termination date" — and an admission that it couldn't find the answer. The first is an answer. The second isn't, and LAKEer won't dress it up as one. Every factual claim carries a citation back to its source.

LAKEer retrieves meaning, queries facts as data, and verifies its answer.

Capability comparison

Compared against BM25, vanilla RAG and vanilla Microsoft GraphRAG. Iterative RAG variants (e.g., IRCoT) partly handle multi-hop questions.

What about…

…agentic RAG? Agentic systems retrieve in loops: search, reason, search again (IRCoT, ACL 2023; Self-RAG, ICLR 2024). That improves how a system searches; IRCoT gained up to 15 points on multi-hop QA. By itself, it doesn't change what the system searches over: aliases stay unresolved and tables stay text. And in Self-RAG, the same model that writes the answer also critiques it. LAKEer works on the other two axes, what is searched and whether the answer is checked, so the approaches are complementary.

…long context windows? Why not paste everything into the prompt? Models use information in the middle of long inputs less reliably than at the start or end (Liu et al., TACL 2024). Answer quality can drop as retrieved context grows (Bennani & Moslonka, 2026). Cost and latency grow with every token on every query. And most enterprise document collections are far larger than any context window.

…permissions, freshness and accuracy? Questions to ask any vendor, including us: Does retrieval enforce each user's document permissions? How quickly do changes in source systems reach the index? And what is the measured accuracy on your own questions, not just on public benchmarks?

From axe to scalpel

• BM25: an axe. Fast and powerful, but it only hits where you aim the exact word.

• RAG: a cleaver. It chops documents into chunks, whether or not the meaning breaks.

• GraphRAG: a butcher's knife. It follows the joints (relationships) instead of chopping blindly.

• LAKEer: a chef's knife in trained hands. It's precise, and the chef tastes before serving: in grounded mode, answers are checked against evidence before they go out.

• LAKEer + pluggable domain ontologies (the road ahead): a surgeon's scalpel. It cuts to the millimeter, and every cut is checked.

The takeaway

Each generation tackled the last one's blind spot, and none fully replaced the one before it. BM25 matched words. RAG found text. GraphRAG found connections. LAKEer combines them and adds understanding and verification, which is what enterprises and AI agents need before acting on an answer.

References

Key references. Every other source is linked where it is cited in the text.

1. The Probabilistic Relevance Framework: BM25 and Beyond, Robertson & Zaragoza (2009)

2. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, Lewis et al., NeurIPS 2020

3. From Local to Global: A Graph RAG Approach to Query-Focused Summarization, Edge et al. (2024)

4. RAG vs. GraphRAG: A Systematic Evaluation and Key Insights, Han et al. (2025)

5. Hallucination-Free? Assessing the Reliability of Leading AI Legal Research Tools, Magesh et al., Journal of Empirical Legal Studies (2025)

6. FinGround: Detecting and Grounding Financial Hallucinations via Atomic Claim Verification, Guo et al. (2026)

7. Knowledge Graphs, Hogan et al., ACM Computing Surveys (2021)