DEV Community

Cover image for Compile the Knowledge at Index Time
FDE at Trida AI for Trida AI

Posted on Originally published at trida.ai

Compile the Knowledge at Index Time

Originally published at Trida AI.

Ask a document store the same question on Monday and again on Thursday, and watch what the system does. It embeds the question, pulls roughly the same chunks, and hands them to a model that has to work out, from scratch, which sentences in those chunks actually answer it. Nothing Monday's run figured out survives to help Thursday's.

That repeated work is what RAGFlow 1.0 is built to remove. InfiniFlow now positions the open-source engine as a supply layer for retrieval agents rather than an end-to-end RAG pipeline, and the mechanism behind the repositioning is knowledge compilation: move the understanding from query time to index time. Compile once, when a document arrives, and store the result as artifacts the agent can use directly, instead of re-deriving the same understanding inside every prompt.

What compilation stores

Compilation produces several artifact types from the same documents. There is a navigation tree over chapters and sections. There is an entity graph, timelines for collections that change over time, and wikis an enterprise can choose to generate. And there are atomic propositions, the piece the rest of this post is about.

A proposition is a one-sentence fact extracted from the source, paired with a verbatim quote. The quote has to be a contiguous substring of the original text, and that is checked mechanically. A proposition whose quote does not match the source word for word does not count as evidence.

The constraint sounds fussy. It is the design. A summary can drift a little each time it is regenerated. A paraphrase can quietly upgrade a "may" into a "will". A verbatim quote can do neither without failing its check, so a compiled proposition can be cited the moment it is retrieved, with no second pass back through the passage to confirm what it said. Each artifact also records its lineage, which document and which passage it came from, and when a document is deleted, its compiled contributions are removed with it, rather than lingering in the store as facts nobody can trace.

One paragraph, compiled. Each proposition carries a quote that must match the source word for word; the one that cannot is never stored. Example content.

One paragraph, compiled. Each proposition carries a quote that must match the source word for word; the one that cannot is never stored. Example content.

The tree was not the point

The finding that makes this release worth reading closely is one the team published against its own product story. Organizing documents into trees, on its own, did not help. In the accompanying paper, the authors report that structural artifacts gave no detectable accuracy gain on the multi-hop FRAMES benchmark under a competent retrieval harness, and that an outline-style index degraded at scale. That should not surprise anyone who has watched a good agent work a corpus. Given search, reading, and the freedom to reformulate, it finds the right region anyway. A prettier map of that region adds little.

What moved the numbers was attaching claim-evidence pairs to the tree's leaves. When the evidence at a leaf is sufficient to answer, the agent answers from the evidence and skips reading the raw chunk entirely. The paper reports that this cuts query tokens by 91% when the evidence suffices and adds 1.9% when it does not — a 38% average reduction, at a measured sufficiency rate near 43% against a break-even of about 2%.

Read those as the team's numbers, from the team's runs: a harness built on BM25 and grep-style search with a single model, MiniMax M3, measured on BrowseComp-Plus and FRAMES. They are not independent benchmarks, and nobody should plan capacity around the decimals. The shape matters more than the figures. A compiled hit is cheap to use. A miss costs almost nothing, because the system checks the evidence before the model starts searching and, if the set is not enough, discards the whole block and searches as it would have anyway. Compilation does not have to win often to pay for itself. It has to win occasionally and lose cheaply.

The discard rule deserves its own paragraph, because it runs against instinct. Retrieved material usually gets stuffed into the prompt just in case, where every later round pays to carry it and the model pays to ignore it. Here, insufficient evidence is assigned no citation numbers and never enters the context at all. Partial evidence treated as partial credit is how confident, half-grounded answers get built. This design treats it as no evidence, which is the more honest accounting.

Where the understanding work happens. Chunk-and-embed pays it inside every query; compilation pays it once at ingestion and stores the result as evidence.

Where the understanding work happens. Chunk-and-embed pays it inside every query; compilation pays it once at ingestion and stores the result as evidence.

Where compilation stops paying

Compilation is a bet on reuse, and bets have losing sides. A corpus that gets asked once, or asked in ways that never repeat, pays the index-time cost for artifacts nobody retrieves. Long-tail archives with cold traffic are usually better left raw, with a strong search harness over them.

Freshness is the second cost. A compiled proposition is derived data, and derived data goes stale on the source's schedule, not yours. RAGFlow rebuilds compilation as an idempotent full recomputation — cleaner than half-updated structures, and a real compute line item on a large, fast-changing corpus. Anyone adopting this pattern owes their users a compile timestamp they can see, because "the document changed Tuesday; the evidence was compiled in October" is a failure mode that looks exactly like a correct answer until it isn't.

Third, the verbatim check proves less than it appears to. It guarantees the quoted words exist in the source. It does not guarantee the extractor picked the sentence that matters, or that a true sentence answers the question being asked. Extraction here can run on a small model, which keeps indexing cheap; it also means the quality ceiling of the whole store is set by a component nobody demoed. The sufficiency gate guards the answer side of that problem. Nothing guards the extraction side except testing the compiled store the way you'd test any other index: with real questions, before users do.

And buy it for the right reason. By the team's own measurement, compilation did not make answers more accurate under a strong harness. It made them cheaper and easier to trace. A team whose problem is accuracy has a different problem, and spending its budget on compilation will leave that problem exactly where it was.

None of this is an argument against compiling. It is an argument for compiling the corpora that earn it: heavily queried, slow to change, and expensive to read — policy libraries, product documentation, regulatory collections — and leaving the rest to search. The interesting shift in this release is not that one vendor added a feature. It is that the unit of retrieval is changing, from a passage a model must interpret under time pressure to a checked fact it can simply use. Systems built around the second unit will be designed differently from the ingestion pipeline outward, and most production RAG stacks were not.

Work with us

If your retrieval stack pays full reading costs on every question, the same documents understood from scratch, run after run, we can help you work out which of your corpora would earn compilation and which should stay raw. Start with Trida AI's intake and bring the question your users ask most often; that is where the arithmetic begins.

Top comments (0)