ModelScope Open-Sources Sirchmunk, an Index-Free Dynamic Retrieval Framework

The static knowledge base paradigm carries an implicit premise—that knowledge is stable. The source points out that once a question involves complex context or time-sensitive scenarios, a static knowledge base expires rapidly: an answer that was correct yesterday may become a hallucination today. This is the starting point Sirchmunk tries to respond to, and the key to understanding its design trade-offs.

The traditional RAG pipeline is to parse documents, split text, compute embeddings, write into a vector store, and at query time use the question to recall top-k segments. When the corpus is stable, this route is mature and efficient; the problem appears when data keeps changing: every time a file is added, modified, or deleted, the system must synchronously re-parse documents, update chunks, delete old vectors, and ensure the index is the same version as the raw files; more seriously, when the embedding model is upgraded, all historical indexes need to be rebuilt.

Thus the index turns from a component serving retrieval into a data pipeline that requires long-term maintenance. Sirchmunk takes a different approach: it treats the current dynamic raw files directly as the starting point, and at query time searches, reads, and verifies, concentrating compute on the hot regions most likely to contain the answer. The most direct benefit is shortening Time-to-First-Query—once a file enters the directory, it can be queried without waiting for a full round of processing.

Sirchmunk's core algorithm is called LENS, short for Latent Evidence Navigation and Search. Its algorithmic architecture can be summarized as five actions: receive the question and the raw documents at the current moment; use keywords, path structure, summaries, and historical experience to form low-cost priors; repeatedly propose candidates, read the original text, and update judgments within budget; merge evidence to generate an answer with sources; and save successful experience as reusable knowledge to feed back into future queries.

The so-called "latent evidence space" refers to the search space formed by all contiguous segments in a document that could potentially serve as evidence. LENS treats any contiguous segment (d,s,e) in a document as a potential evidence window, without fixing the segmentation method in advance; the system decides at query time which segment to read and how far to extend the boundaries outward. The example the source gives is a 500-page maintenance manual, where the user asks "why does fault code E217 trigger during low-temperature startup"; the answer may be scattered across three places—the fault code description, the low-temperature limit, and the startup procedure—and pre-cut fixed chunks may not exactly cover them.

For each factual requirement, LENS pursues a "minimally sufficient" evidence window: the goal is not the shortest, but as compact as possible without losing context, to reduce noise and make it easy to return to the original text for verification. Retrieval is also constrained by cost, including the cost of searching and reading files, the cost of model judgment and tool loops, and the cost of context tokens, with B being the total budget for this query. The problem thus transforms into: within budget, locate sufficiently reliable evidence for each necessary fact.

Structurally, LENS has two layers. The first layer uses multiple low-cost signals such as keyword hits, directory structure, document summaries, hierarchical indexes, or historical evidence to build a possibility map; the second layer follows a Propose→Observe→Update loop, adjusting the next action based on newly read evidence. The source emphasizes that tree indexes, summary indexes, and directory listings are only optional accelerators; when missing or outdated, search can still fall back to the raw files.

The stopping condition looks at both evidence and budget: it stops when the evidence reaches the sufficiency level required by the question type; when the budget is exhausted, it must also stop and preserve uncertainty, rather than forcing out a seemingly complete answer. The threshold differs by question: explicit fact lookup can be relatively loose, while date comparison, numerical calculation, and multi-hop questions are stricter.