魔搭开源动态检索新框架，无需预构建向量索引，知识库还能自己进化

最后这条反馈线最关键：历史知识能帮助定位，但不能替代对当前文件的读取。来源一旦变化，系统仍要回到原始数据重新核验。

不预切chunk，先把要检索的证据空间定义清楚

假设有一份500页的维修手册，用户问：“故障码E217为什么会在低温启动时触发？”

答案可能分散在故障码说明、低温限制和启动流程三处。预先切好的固定chunk未必正好把这三块都覆盖到。

LENS的出发点是：文档里的任何一个连续区间，都可能成为与问题相关的证据窗口。

设时刻t的文档集合为：

这些文档共同诱导出一个隐式证据空间（latent evidence space）：

其中（d,s,e）表示文档d从位置s到e的连续片段。

“隐式”的含义是：这些窗口本来就存在于原始文件中，只是没有被提前固定成某一种切分。问题到来后，系统再决定读取哪一段、边界向外扩展到什么位置。

光有相关还不够，还要覆盖问题所需的事实

给定问题q，系统先识别它的意图：

再列出回答该问题必须补齐的事实需求：

比如“A和B谁更早发布”，至少需要A的日期、B的日期，以及可比较的日期格式。只找到一篇介绍A的文档，即使主题高度相关，也还不足以回答。

对每个事实需求rⱼ，理想目标是找到尽量紧凑、又能支撑它的证据窗口：

窗口越紧凑，噪声越少，也越容易回到原文核验；但也不能短到丢失上下文。目标不是“最短”，而是“最小充分”。

真实系统还受到成本约束：

是搜索与读取文件的成本，是模型判断与工具循环的成本，是上下文token成本，B是本次查询的总预算。

问题因此转化为：在预算内，为每个必要事实定位到足够可靠的证据。

两层设计：先粗定位，再边读边调整

如果让模型从第一份文件逐页读到最后一份，索引确实省了，但代价通常难以接受。因此，LENS分成两层。

第一层：用低成本信号建立可能性地图

系统先估计哪个文件、哪个位置值得优先读取：

前一项判断文件是否相关，后一项判断文件中的位置是否值得先看。

这个先验由多路信号共同构成：

其中可以来自关键词命中、目录结构、文档摘要、层级索引或历史证据。单独任何一路信号都可能失效：文件名可能只是part-00017，关键词可能被同义表达绕开，历史经验放到刚改过的文件上也可能不再适用。

多路先验的目的不是直接给出答案，而是把庞大的证据空间压缩成一个值得优先探索的候选子空间：

树索引、摘要索引和目录清单都能帮助进一步缩小范围，但它们只是可选的加速器：缺失或过期时，搜索仍可回到原始文件。

第二层：新读到的证据会改变下一步

第t轮，系统根据问题和历史Hₜ提出一个动作zₜ：

动作可以是读取某个片段、调整关键词、追查新出现的实体，或扩大范围。读取原始数据后，系统得到观察oₜ：

再根据新证据更新下一轮策略：

以上就是Propose→Observe→Update的检索推理闭环。这条链路的特点在于，它会在中途自己调整方向。例如，第一段材料如果带出一个新的人名、版本号或项目代号，下一轮可以直接追查；两个日期都已找齐，就不必再扫描整个目录。检索因此从一次性的top-k，变成一条会自我修正方向的导航路径。

什么时候停止？

停止条件同时看证据和预算：

它包含两条规则：证据达到问题类型要求的充分程度时停止；预算耗尽时也必须停止，并保留不确定性，而不是强行给出一个看似完整的答案。

不同问题的门槛不同。明确的事实查找可以相对宽松；日期比较、数值计算和多跳问题更严格，因为缺少任一关键事实都可能改变结论。

从原理到工程：几个绕不过的坑

真实语料很快就会打破漂亮的算法假设。

首先是命名。大量文件没有可辨语义的名字：

wiki_00
part-00017
shard_293.jsonl

只看文件名，几乎等同于随机挑选。所以文件评分同时考虑路径和正文命中：

命中JSON、JSONL或没有扩展名的分片后，记录标题、编号和行位置，才能把读取范围从整块大文件收紧到其中一条记录。

另一个反直觉的点是：证据不是越多越好。

检索的成败与“信噪比”息息相关。10段相关的证据材料，常常比两段直接证据更难用。进入模型之前，系统要去掉重复、模板和低覆盖的片段，优先保留命中实体、关系、日期或数值要求的内容，同时保留来源位置。

再往下是底层工具的可靠性。文件转换可能卡住，搜索进程可能超时，并发请求的token记账也不能混在一起。限流、超时、进程回收、搜索后端回退和请求级状态隔离，这些不像算法创新，却决定系统能否长期稳定运行。

把搜索经验沉淀为可复用知识

一次高质量搜索留下的，不该只有一段答案。

问题怎么问、证据在哪里、哪些文件有用、结论如何被支撑——这些信息如果答完就丢弃，下一个相似问题只能重新找一遍。

Sirchmunk把满足条件的搜索结果沉淀为KnowledgeCluster：

与普通的答案缓存实现有所不同，KnowledgeCluster的问题、证据、来源和可靠性被放在一起，构成一个可复查的经验单元。复用也分级：高度一致时可以复用已验证的结果；只是部分相似时，只借用文件线索和搜索模式，不照搬旧答案。

从零散经验进化成结构化知识

新建或被复用的知识单元都会进入KnowledgeEvolver。演化过程与当前搜索的返回解耦，不会阻塞用户拿到答案。

△KnowledgeEvolver：运行时知识自进化机制

KnowledgeEvolver架构从上到下分三层：

• 上层是事件循环：检索产生或复用知识单元，系统缓存变化并识别事件类型。
• 中层是演化机制：左侧处理局部增量，右侧做周期性全局维护。
• 下层是持久化结果：演化后的知识图谱和可恢复状态，重新服务后续搜索。

知识演化的四个阶段：

前两个阶段响应新建和复用事件，适合频繁执行；后两个阶段随知识积累周期性触发，负责更大范围的整理和纠偏。

知识库的“自我成长”

静态图只能看到结果。为了观察结构如何随检索变化，团队做了一次时间序列回放。

演示基于SQuAD数据集，按可回答问题密度采样200条数据，涉及4篇文档，每篇50题。集中在少数文档上是有意为之：问题之间需要足够相似，连接、合并和社区形成才容易被观察到。

为了让回放更快，查询使用FAST模式和qwen3.8-flash，并调低合并、边刷新、元簇检测和全局更新的触发阈值。随后按顺序发起200次搜索，每次搜索后保存一份知识图快照，最后合成视频。

△知识图谱随检索演化的回放界面

视频中展现了两种有趣的演化：

• 局部演化：新节点不断出现并向已有单元靠拢，形成区域内强连接，标志着相似类型的知识在不断聚合。
• 全局演化：后期出现的大型节点（紫色节点），称为“Meta Cluster”，即超级节点。它们往往并非某一种具体的知识点，而是由KnowledgeEvolver进化出来的“方法论”，用于指导系统面对某一类知识时如何高效发起检索动作。

Sirchmunk快速上手

前提只有三样：Python环境、LLM配置，以及一个可搜索的目录。

pip install sirchmunk
sirchmunk init
sirchmunk search “系统鉴权策略如何设计？” /path/to/documents

模式切换：

• —mode FAST：使用贪婪检索策略。
• —mode DEEP：默认设置，会召回更加完备的证据链。

Python侧的最小调用如下：

from sirchmunk import AgenticSearch
searcher = AgenticSearch(paths=[“/path/to/documents”])
result = await searcher.search(
   query=”系统鉴权策略如何设计？”,
   mode=”DEEP”,
   response_format=”rich”,
)

适用边界与未来方向

Sirchmunk不是经典RAG系统的替代品，两者面对的场景不同：

真实系统可以混合使用：长期稳定的热语料交给向量索引承担高并发召回；频繁变化、需要即时核验的动态部分交给Sirchmunk。

Sirchmunk未来的演进：

• 让复杂多跳问题的中间证据更不容易丢失。
• 加强来源时效、冲突检测与知识生命周期治理。
• 支持更多模态的数据检索。
• 用更轻的先验压低首次定位时延。
• 进一步压低更新、存储和查询的全生命周期成本。

论文链接：https://arxiv.org/abs/2608.16185
代码仓库：github.com/modelscope/sirchmunk
项目文档：github.com/modelscope/sirchmunk-web