Proxy-Pointer RAG：一种无需语义预编译的新型时间推理技术

企业级检索增强生成（RAG）在过去一段时间里发展得非常快。最初的RAG范式设计思路很直接：从语料库中检索最相关的文本块，然后用它们来回答问题。对于很多以文档为中心的查询来说，这个办法确实有效。可一旦问题超出了单篇文档的边界，或者问题本身带有时间属性——比如追踪某个实体数年来的演变轨迹——那这套方法就开始力不从心了。

举几个例子就明白了：

• 过去十年我们收购了哪些公司？
• 自2018年以来，我们的人工智能战略是如何演变的？
• 往年年度报告中承诺的可持续发展目标，哪些最终兑现了？
• 管理层的资本配置理念这些年发生了怎样的变化？

最近，一种名为LLM-Wiki的新架构模式，为这些挑战提供了一个有趣的解法。它的思路不是每次检索时都去原始文档里翻找，而是在数据摄入阶段进行大量的语义处理，构建一个由规范页面组成的持久知识库，这些页面之间通过索引相互关联。未来的查询，主要就从这个编译好的知识库中获取答案，而不再需要频繁访问原始文档。

想法很精巧，但它也引出了一系列重要的架构问题：

• 企业的知识，有必要在用户提问之前就全部进行语义编译吗？
• 能不能避免为整个大型文档库（比如卷帙浩繁的年度报告、合同等）支付这种摄入成本？毕竟这些内容中的大部分可能永远都不会被查询到。
• 规范页面里到底该放什么内容，才能确保几乎所有的未来查询都能不依赖原始文档就给出答案？如果一个规范页面被过度设计，它本身可能就会变得非常冗长，甚至随着时间的推移，比源文档本身还庞大，最终导致更高的检索延迟和成本。

在本文中，我们将把LLM-Wiki与Proxy-Pointer（PP）架构进行对比。PP是一种结构感知的检索框架，它从根本不同的角度来处理同一个问题。它不是在摄入阶段就急切地编译语义知识，而是保留文档的结构组织形式，只在查询需要时才进行语义合成。这种“懒加载”式的语义分析思路，与Proxy-Pointer的核心前提一脉相承：在精准交付结果的同时，避免支付那笔沉重的“摄入税”。

下面，我们用一个真实的场景来对比这两种方法。

LLM-Wiki 的方法

LLM-Wiki通过将大量推理工作转移到摄入阶段，来捕捉时间维度的上下文。它不再把文档当作孤立的工件，每一篇进入系统的文档都会由大语言模型进行处理，提取出其中的概念、实体、关系和事实。这些提取出的信息被整合进一系列规范页面中，这些页面代表了关于该组织持久的、结构化的知识。

举个例子，多份年度报告会共同更新诸如“收购”、“人工智能”、“云战略”、“可持续发展”、“产品组合”、“供应链”等规范页面。每一份新的年度报告都会为这些页面贡献新的知识。

与这些规范页面配套的，系统还维护着一个索引，用来为未来的查询定位到正确的页面。从概念上看，这个架构大致是这样的：

当用户问：“过去十年我们收购了哪些公司？”，系统会先去搜索索引，找到与收购相关的规范页面，然后直接从这些编译好的知识中给出答案。原始文档作为不可变的数据存储仍然存在，但在理想情况下，它们已经不再是常规查询路径的一部分了。从架构角度看，这是一种典型的知识编译。

如何构建这个Wiki？

假设输入是一份200页的年度报告。为了优化计算成本，我们希望一次性提取与所有规范页面相关的信息，并更新对应的页面。这就意味着要同时让大语言模型执行几十项提取任务：

看看这几项：检测收购信息、产品信息、AI举措、云战略、可持续性、地缘整治风险、合作关系、供应链、监管变化、客户、诉讼、投资、子公司、组织重组、技术趋势……

随着语义目标数量的增加，模型的注意力被分散到各个目标上。它必须不断判断哪些信息属于哪个规范页面，是否需要创建新的页面，以及新发现的事实与已有知识之间是什么关系。当提示词变得复杂，要求模型同时优化众多目标时，大语言模型就会出现“高维信息提取能力退化”的问题。尤其对于篇幅较长、内容密集的文档，这可能会导致召回率降低、遗漏信息，甚至错过那些不那么显眼的内容。

更根本的问题是，系统面临着一个困难重重的预测难题。它必须在摄入阶段就做出决定：哪些信息值得被物化到规范知识库中？这意味着系统得像预言家一样，预先想好用户未来可能会问的所有问题。

比如：“自收购以来，子公司X的收入贡献是如何演变的？”

回答这个问题所需的证据，可能散落在好几份年度报告里，深深嵌入在详细的财务报表、脚注或分部报告表格中。如果要把每一个潜在相关的财务数据项都物化到规范页面里，知识库的规模和维护成本将急剧膨胀。反过来，如果省略了这些细节，那就意味着将来有些查询还是不可避免地要回到原始文档去找答案。

这就揭示出预判式语义编译的根本性权衡：系统必须持续在完整性、可维护性和摄入成本之间寻找平衡，但它根本不知道今天文档里的哪些内容，对于明天用户提出的问题来说是必要且充分的。

Proxy-Pointer 的方法

Proxy-Pointer从完全不同的方向来解决同一个问题。

它不是在摄入阶段就构建一个预判式的语义知识库，而是为每篇文档构建一个结构化的表征（骨架树）。这个过程纯粹基于正则表达式，完全不使用大语言模型，因此摄入成本为零。真正的语义编译被推迟到了检索阶段，实现一种“即时”的推理和响应。看看它是怎么工作的：

Proxy-Pointer利用标准的向量索引，但做了重要的修改。文本块严格按章节边界切分，绝不允许跨章节。每个文本块都会被标记上元数据，指明它来自哪个章节以及对应的行号边界，以方便检索。当用户查询到来时，会通过“向量搜索+大语言模型重排器”流程，选出最相关的top-k个章节作为上下文。

上述流程的设计初衷，就是利用复杂文档本身固有的章节/子章节结构，将其作为一张语义地图，从而精准地找到回答用户问题所需的内容。正如文章开头提到的实践案例所展示的，这个检索流程在处理复杂查询时，展现出了外科手术般的精准度。

它能应对跨文档查询吗？

我们来考虑这个查询：“过去十年我们收购的那些公司，后来都怎么样了？”

答案并不存储在某一篇单独的文档里。它必须通过关联多份年度报告中分散的并购信息来构建。一家2016年被收购的公司，可能在随后几年被反复提及，最终随着它完全融入母公司，从后期的报告中消失。

对于LLM-Wiki方法，它已经在过去十年摄入每份年度报告时，创建了一个记录所有并购信息的规范页面。因此，它可以把那个页面作为上下文提供给大语言模型。

而Proxy-Pointer会这样推理：这个查询需要过去十年公司的年度报告。由于向量索引中每个文本块的元数据都包含了年份信息（通过结构化的痕迹进行元数据过滤，比如年份：2024 > 章节：并购），流程可以从每份报告中找到与并购相关的top-k个章节。

假设 k=5，那就会产生50个章节。如果这超出了大语言模型的上下文窗口，可以分组分析这些文档来提取并购信息，然后将结果作为上下文提供给最终生成响应的大语言模型调用。

与LLM-Wiki方法的关键区别

最明显的区别，正如前面提到的，就是没有前期摄入成本——除了创建一个标准的向量索引。语义编译和分析被推迟（懒加载）了；只有当查询需要时才会发生。

第二个区别是，即使在检索阶段，上面例子中对查询的分析也只需要处理50个章节。这比LLM-Wiki方法中为了创建规范页面而提前分析10份、每份200页的年度报告，要高效得多。

第三个区别是，Proxy-Pointer利用结构树作为语义地图，这使它能够根据用户查询来减少需要分析的章节数量。而LLM-Wiki则是对整篇文档进行穷举分析，以提取实体和关系，来构建用户想要存储的知识库，其中大部分内容可能永远也不会被问到。

最后，用户也无需在前期就为“未来可能有哪些查询”这种难题做出艰难的设计决策。构建一个能准确组织事实、概念、关系等信息，并期望它能回答几乎任何问题而无需引用源文档的编译器，这本身就是一个极具挑战性的命题。

大型企业通常维护着包含数百万页文档的资料库，包括年度报告、监管文件、工程规范、政策、合同、技术手册等等。其中只有很小一部分会被用户真正查询。大多数查询都集中在当前和最新版本的报告和政策上。即使是在用户提出的查询中，时间维度的查询也只占很小一部分。

Proxy-Pointer只会在需要的时候，分析需要的内容，这有可能大幅降低成本。 对于一次性的时间维度查询，它只分析问题所需的章节；而LLM-Wiki在摄入阶段就已经分析完了所有年度报告。如果类似的查询重复出现，合成的响应（或中间摘要）可以被缓存和复用，这样Proxy-Pointer就能摊销语义推理的成本，而无需对每篇文档都进行前置语义编译。

响应结果的可解释性

企业级AI系统越来越多地在受监管的环境中运行，在这些环境下，可解释性与正确性同等重要。对于用户来说，“答案是什么？”这个问题，总是伴随着“我凭什么相信它？”。

Proxy-Pointer直接在源文档的章节上进行推理，溯源能力天然得到保留。在推理过程中使用的证据，可以随时被调取出来进行审查。

LLM-Wiki可以通过引用源文档和页码来保证可解释性，但其响应结果的主要推理过程发生在编译后的表征之上。随着这些表征通过反复更新而演变，它将成为系统中另一个需要被持续维护和验证的方面。

结论

LLM-Wiki和Proxy-Pointer之间的争论，核心其实不在于检索本身。它关乎的是语义理解应该在何时进行。

LLM-Wiki的假设是：企业的知识非常有价值，值得在摄入阶段就进行编译，这样一来，未来的查询成本就很低了。Proxy-Pointer则持相反的观点。它认为，大多数企业内容根本就不会被查询，因此语义推理只应该在一个问题明确表明有这个计算需求时才去执行。

对于那些拥有稳定语料库、并且查询类型高度重复的组织来说，维护一个编译好的知识库可能会很有价值。而反过来，对于那些文档不断变化、查询需求难以预测、偶尔需要进行时间维度分析的大型企业资料库来说，将语义编译推迟到检索阶段，或许是更明智的选择。

这个问题的启示，其实超出了这两种架构本身。随着企业AI系统从文档检索演进到知识推理，架构师们越来越需要在成本与价值之间做出权衡。知识是否应该被编译，只因为它“某一天可能会用到”？还是说，只有当用户真正提出请求时，才去合成所需的答案？

Proxy-Pointer做出了一个清晰的架构选择。与其去预测明天的问题，不如让明天的问题来决定，今天需要创造什么样的知识。

开源仓库

Proxy-Pointer完全开源（MIT许可证），你可以在Proxy-Pointer Github仓库找到它。

克隆仓库，尝试用例。欢迎分享你的想法。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：Proxy-Pointer RAG：一种无需语义预编译的新型时间推理技术要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题