超长上下文对比Agentic检索与LLM Wiki，企业知识库怎么选？

先说个背景。我最近在折腾企业内部知识库的落地，手头攒了几百份文档，正愁怎么让模型在消化这些材料的同时还能准确引用出处。那阵子超长上下文、Agentic检索、LLM Wiki这几个词在技术社区反复刷屏，我干脆把这三个方向都搭了个最小原型挨个试了一遍。这篇文章就是把这几周实测下来的思考整理出来——不是什么调研报告，纯粹是我自己踩坑之后的记录，如果你也在纠结知识库方案选型，应该能省不少事。

先统一一下我对这三个概念的理解：超长上下文指模型单次能处理的token数量被拉到百万级别；Agentic检索指把"检索"本身变成一个有规划、能调用工具、会自我修正的代理行为；LLM Wiki则是把文档转化成带语义关系的知识图谱，让模型回答时可溯源、可遍历。三者看起来都在解决"模型怎么更好利用外部知识"这个问题，但切入角度和适用场景差别很大，我逐个掰开说。

1. 三个热词一起刷屏，背后其实是同一件事的三个解题方向

在逐个拆细节之前，我想先把这三个东西放在同一张桌子上看。它们刷屏的时间点高度重叠，不是巧合，而是大家几乎同时撞上了RAG（检索增强生成）的两堵墙：一是检索质量上限，二是知识组织方式的粗糙。超长上下文、Agentic检索、LLM Wiki分别从不同方向试着拆墙。

1.1 从RAG的局限说起

传统RAG的流程大多数人都熟：先把文档切块、向量化、存进向量库，问答时拿用户问题去召回Top-K块，拼进Prompt丢给模型。这套流程的问题在于，切块粒度决定一切，块切大了语义混杂，切小了上下文断裂，而且召回阶段只看向量相似度，很难处理需要跨多个段落甚至多篇文档才能回答的问题。

我自己遇到过很典型的场景。有一份产品需求文档，功能描述分散在十几个章节里，用户问"这个权限体系和旧版相比有哪些变更"，向量召回召回的Top-K块要么只覆盖一个模块，要么撞上一堆无关的相似表述，模型最后给出的答案缺了关键的迁移说明。这不是模型能力问题，是知识组织方式的天花板。

1.2 三个方向的互补关系

超长上下文给的方向是：既然模型上下文窗口够大，那就别切块了，整篇文档甚至整个知识库塞进去。Agentic检索给的方向是：既然单次召回不够，那就让模型像人一样反复搜、反复判断，把检索变成一个多轮推理过程。LLM Wiki给的方向是：先把文档里的概念和关系抽取成结构化的图，回答问题时沿着图走，而不是靠向量相似度碰运气。

我的总体判断是：这三个方向不是替代关系，而是分别优化了知识使用的不同环节。但各自都有明显的短板，想要直接生产可用，光靠其中任何一个都远远不够。下面逐个说我的实测感受。

2. 超长上下文：能装下100万token，不等于能驾驭100万token

超长上下文是我第一个动手试的。原因很直接——如果模型真的能稳定处理超长输入，那我的知识库架构能瞬间简化一大半：不用切块，不用向量库，文档直接全量喂进去就完了。现实很快教育了我。

2.1 我被"目录即全文"骗过之后

第一次试验我拿了一份大约8万词的内部技术规范，加上目录、图表说明和若干附录，总token量大概在12万左右。模型处理起来确实很轻松，摘要结构清晰，单点问题回答准确率也足够。我一度觉得"切块时代结束了"。

但当我换成一整套产品线文档，总token量接近40万的时候，情况开始不对劲。模型对文档前10%的内容回答得非常精确，对结尾部分也还行，但对中间段的某些具体参数、公式引用开始出现张冠李戴——它把上文提到的一个阈值参数安在了另一个模块的配置说明里。这不完全是模型的错，因为我在Prompt里给的检索指引是"根据全文回答"，模型根本不知道哪些段落在哪个范围。

这个现象在文献里有个名字，叫"Lost in the Middle"，模型对超长上下文中段内容的注意力显著弱于首尾。我实测下来的体感是：一旦上下文超过某个量级（我这边大概是15万token左右开始明显），中间段信息虽然仍能被"看到"，但很难被"精确定位和引用"。

2.2 三个层面的真实瓶颈：成本、迷失、更新

我把超长上下文的问题拆成三个层面来看。

第一层是成本。百万token输入不是免费的，按目前主流大模型的定价，一次把百万token全量喂进去做单次问答，光输入费用就是一笔不小的开销。如果知识库里有上千份文档，每次问答都全额塞入，成本毫无收敛性。虽然有些方案提出"把文档缓存成KV Cache"，但缓存只对静态文档友好，文档一旦更新，缓存大面积失效需要重建——这在知识库场景里几乎等于每次更新都要重新付一次全量处理的钱。

第二层是迷失。上面提过的mid-context问题不是偶发，是很稳定的现象。我的经验是：超长上下文适合做"全文概览型"任务——总结、提炼、找出与某个主题相关的分散段落——但不适合做"精确取数型"任务。它知道有什么，但不知道精确在哪里。

第三层是更新。知识库是活的，文档每天都在变。超长上下文的输入依赖静态快照，模型对每个用户提问看到的都是同一份快照，没法感知"哪个段落是昨天刚改的"。在我做的企业知识库里，这个问题比成本更致命，因为很多问答本身就依赖时序信息。

2.3 我的实测结论和适用场景

超长上下文最终被我定位成"辅助层"而非"底座层"。具体用途我留了两个：一是做全局概览和交叉比对，让模型在超大上下文里找分散的共同点或冲突点；二是做离线分析任务，比如把整份季度报告一次性分析完。

但如果要用它承载多用户、高频、持续更新的问答系统，成本控制和中段迷失这两关过不去。这个判断在我后面设计组合方案时起了决定性作用。

3. Agentic检索：把"查一次资料"变成"像人一样查资料"

Agentic检索是我第二组实验的重点。和超长上下文那种"一次性投喂"的思路相反，Agentic检索的逻辑是"边查边想、查完再查"。我搭了一个轻量Agent框架，让它对接已有的向量库和外部搜索API，试图复现那种"资料查漏补缺"的行为。

3.1 普通RAG和Agentic检索的本质区别

普通RAG是一次性的：用户输入问题，系统召回Top-K，拼Prompt，出答案。Agentic检索则引入了一个"代理循环"：

1. 代理先分析用户问题，拆出需要查证的子问题；
2. 代理选择一个工具（向量召回、关键词搜索、数据库查询、代码执行等）去查；
3. 拿到结果后评估信息完整度：够不够？有没有冲突？缺什么？
4. 如果不够，改写查询词或换工具继续查；
5. 直到代理判定信息足够，才把整理好的材料交给模型生成最终答案。

这个行为模板本质上是把"检索策略"从系统工程变成了模型推理的一部分。带来的直接好处是，像"这个权限体系相比旧版有哪些变更"这类多跳问题，代理会主动拆成"先找权限体系说明、再找旧版说明、再找变更记录"三步，分别检索再合并，解决了我之前RAG一直搞不定的跨段落问题。

3.2 Agent的规划与终止：什么时候该停

Agentic检索最核心的机制不是"怎么查"，而是"什么时候停"。我在实验里给Agent设计了三类终止条件：

• 信息充分：所有子问题都找到了带来源的答案，置信度超过阈值；
• 检索耗尽：同一子问题连续N轮没有新增有用信息，强制停止；
• 成本上限：累计工具调用次数达到上限（我默认设成5次），停止。

这三个条件缺一不可。如果只看"信息充分"，Agent会陷入一种"总觉得还能查到更多"的无限递归里——我第一版只设了充分条件，结果有一次回答一个问题它调了11次搜索，最后给出的答案反而更混乱了，因为信息太多互相干扰。把轮次上限加上之后，成本和答案质量都稳定了不少。

3.3 稳定性与成本的现实问题

但Agentic检索在生产环境里有两个硬伤，我必须提醒想做这块的人。

第一是不可复现性。Agent的每一步都受前一步结果影响，同一个问题跑两次，中间走的检索路径可能完全不同。这在演示时很惊艳，但在企业知识库场景里是个大麻烦——用户会拿两次完全不同的回答来质疑你系统的可靠性。我后来给Agent加了"轨迹记录"和"固定种子策略"，可以让它在日志里完整回溯，但仍然没法保证输出的一致性。

第二是Token消耗的失控风险。Agent每轮都带着历史轨迹重新调用模型，一个简单问题如果Agent绕了两轮弯路，消耗的Token数可能是普通RAG的10倍以上。成本模型不做到按问题追踪、按预算熔断的话，上线后账单会非常难看。

我的结论是：Agentic检索适合处理"低频、高复杂、高价值"的问题，比如战略分析、方案对比、故障根因排查。但作为所有问答的默认模式，它又慢又贵又不可控。这个定位在后面组合设计时也很关键。

4. LLM Wiki：为什么它比GraphRAG更像"知识库"

第三个方向是LLM Wiki。说实话，这个是我测试前预期最低、测完后最感兴趣的一个。之前看过一点GraphRAG的材料，总觉得图增强生成的路子太繁重——又是社区检测又是分层摘要，构建成本高得离谱。LLM Wiki的做法简洁得多，但它解决的问题恰恰是我在知识库场景里最头疼的：可溯源、结构化和低成本的平衡。

4.1 它到底存了什么：带上下文的语义三元组

理解LLM Wiki的关键在于搞清楚它存的是什么东西。传统的知识图谱存的是"实体-关系-实体"三元组，比如"张三-任职于-某公司"，实体和关系都是规整的，但抽取过程会把大量语义信息丢掉——你不知道这个关系的上下文是什么，也不知道原始出处在哪里。

LLM Wiki的思路是：三元组照样抽，但每个三元组节点都额外携带两样东西——上下文片段（从原文里截取的支撑语句）和来源标识（原文位置或文档ID）。也就是说，图里的每个"概念节点"不只是"张三"这样一个光秃秃的字符串，而是"张三"这个实体在原文中出现的语义三元组、支撑它的上下文文本、以及它在哪些文档里有据可查。

我的理解可以简化成一句话：LLM Wiki存的不是"知识图谱"，而是"带原文依据的语义关系网"。

这一点带来的直接优势是回答时可溯源。用户问"为什么这个模块要这么设计"，系统顺着图走到"模块设计约束"这个节点，返回给模型的不只是一段抽象描述，还有从原始设计文档里截取的上下文和出处。这在企业知识库里几乎是刚需，因为很多使用场景不是为了看答案，而是为了验证答案靠不靠谱。

4.2 构建过程为什么比GraphRAG便宜且可追踪

GraphRAG构建知识图谱时，除了抽取实体关系，还需要对社区做检测（用Leiden这类社区发现算法），然后对每个社区生成多层次摘要。这个聚合过程有两个问题：第一，它需要大量LLM调用去生成摘要，成本随文档规模膨胀得很快；第二，社区检测和摘要生成都是非透明的中间过程，一旦某个回答出了问题，你几乎没法回溯是哪个社区摘要错了。

LLM Wiki绕开了社区聚合这层。它只做两件事：从文档中抽取出节点和关系边，以及维护一张统一的全局ID映射表。LLM调用次数基本就等于"文档数 + 抽取出的边数"，不额外生成任何中间摘要。这意味着：

• 构建成本可控，文档增量更新时只需要对新增文档做抽取，不需要重跑全局聚合；
• 可追踪性极强——每个节点和边都能直接对应到原文片段，不存在"黑盒摘要"。

我构建一个约200份文档的测试知识库时，用LLM Wiki方案全部抽取加建图，花了不到2小时，Token消耗大约是GraphRAG方案的1/4。这个差距在企业级文档规模上会被放大得更加明显。

4.3 回答的路径：语义入口+传递闭包+无环校验

LLM Wiki的查询逻辑也很有意思。它不是靠向量召回去找相关片段，而是先做语义匹配，找到用户问题对应的"入口节点"，然后利用图的传递闭包直接抓取整个相关子图。

我在测试里验证过的查询路径大概是这样：

1. 用户问题进来，先用文本或概念语义入口做匹配，定位到图中一个或多个起始节点；
2. 从起始节点出发，计算传递闭包，一次性取出所有可达的关联节点和边；
3. 检查这些路径是否形成循环。LLM Wiki在构建时就要求图是"无环有向图"，所以理论上这一步不会出现死循环问题，但查询时纳入校验更稳妥；
4. 把取出来的节点上下文、来源信息打包进Prompt，让模型基于这些材料组织答案。

这套路径有一个很关键的工程保障：无环校验。我在一开始搭建时没注意这个约束，结果构建出的图里出现了"模块A依赖模块B，模块B又依赖模块A"这种循环引用，回答引擎在顺着路径展开时直接卡死。后来建立了一套"反向边检查"逻辑：每次插入新边时检查是否有指向已存在祖先节点的边，如果有就强制拒绝并让LLM重新表述关系。加上这个约束之后图就干净多了。

4.4 一个可复现的最小构建流程

如果只想验证可行性，我给一个最小可复现的构建流程：

输入：文档集合（建议单篇控制在5000词以内，超过就按主题切分） 1. 逐篇喂给LLM，让它抽取结构化三元组：概念A -> 关系 -> 概念B 2. 每个三元组补上原文上下文片段和来源ID 3. 将抽取出的概念注册到全局ID映射表，同一语义概念合并到同一ID 4. 插入边之前做环检测：若发现新边会把图变成有环，拒绝或要求LLM拆分关系 5. 全部插入完毕后做一次全图校验，统计孤点、重边、缺失来源 6. 查询时：语义匹配入口节点 -> 传递闭包展开 -> 返回子图上下文

构建Prompt我踩过一个坑：一开始我只让LLM输出"概念和关系"，结果抽取出的三元组大量重复，语义对齐乱七八糟。后来改成"必须同时输出支撑上下文原文和来源ID"，质量问题立刻缓解了——因为上下文原文的存在约束了模型不能瞎编关系，它必须从原文里找到依据才能写出来。如果你自己搭，这个约束一定要写在Prompt里。

4.5 LLM Wiki的边界条件

LLM Wiki也不是万能的。我在测试中发现两类场景它表现不太好：

第一类是"数值计算与复杂聚合"类问题。比如"这个季度所有项目的预算总和以及超支率排名"，图结构能定位到所有项目节点，但计算本身还需要一个归约层去处理，单纯靠图展开并不能自动完成。

第二类是"跨领域模糊提问"。比如"我们的系统有哪些可以优化的点"，这个问题在图上找不到明确入口，语义匹配容易落到一个无关子图上。它本质上需要一个"开放入口"机制，把这类问题映射到多个候选簇上，再由模型聚合判断——这其实又回到了Agentic检索的路子。

5. 三者怎么组合：我给自己的项目开的"处方"

现在可以说结论了。三个方案我逐个分析完，最终的判断是：单用任何一个都是错，组合起来才是答案。我给自己项目的组合方式是这样的。

5.1 用LLM Wiki做底座

底座还是得用LLM Wiki。它对知识库场景的核心价值是"稳定可溯源的语义骨架"，这是其他两者给不了的。文档更新时增量维护图，问答时先走语义入口，再用传递闭包展开相关上下文——大部分常规问答用这一层就能解决，而且答案质量稳定、出处清晰，适合作为默认路径。

5.2 超长上下文和Agentic检索的定位

超长上下文被我用在"离线概览"场景：当用户问的是"这个文档库整体讲了什么""哪些模块之间存在风格不一致"这类需要全局视野的问题时，把关键文档全集喂给一次超长上下文的独立任务来做分析，绕开了图结构对"全局性问题"的颗粒度限制。

Agentic检索则被我用在"高复杂问题"场景：预先设计一个路由规则，当检测到用户问题包含多跳、对比、归因等特征时，才把问题转入Agent模式，让它调用LLM Wiki的图查询工具、向量库和外部API，多轮检索后汇总答案。这样既保留复杂问题的高智商表现，又不让Agent的Token消耗失控。

5.3 选型对照表与踩坑提醒

我把三者放在一张表里，方便你按自己场景快速判断：

踩坑提醒三件事：

第一，LLM Wiki的抽取Prompt里，上下文原文必须和三元组绑定，否则你会得到一堆无源可溯的"伪知识"。

第二，Agentic检索的终止条件必须先想到"成本上限"再想到"信息充分"，否则上线后被账单和超时折磨的是你自己。

第三，超长上下文适合"一次性分析"，不适合"实时问答入口"。如果你想让每个用户问题都从百万token里捞答案，我建议多准备一倍预算在你的成本预测模型里。

我个人实际操作后的体会是，这三个方案本质上对应了知识使用的三个不同维度：超长上下文管"装得下"，Agentic检索管"找得到并且知道该找什么"，LLM Wiki管"有据可查、结构可遍历"。对我这种天天跟文档打交道的场景来说，把三者按各自擅长的方式组合，比迷信任何单一热门方案都要靠谱得多。这套架构我目前跑了快两个月，稳定性和成本都在可接受范围，后面如果有进一步的数据和新的踩坑，我再来更新。