超长上下文、Agentic检索与LLM Wiki：大模型知识库技术选型实战

说实话，最近在研究大模型技术选型的时候，发现圈子里几乎被三个词刷屏了：超长上下文、Agentic检索、LLM Wiki。打开技术社区是它们，刷到行业分享是它们，连内部技术评审里大家也在争论到底应该站哪一边。

我花了两周时间，把这三条技术路线挨个扒了一遍——不是看概念PPT那种扒法，而是真的建了测试工程，用真实业务数据跑了一遍。这篇文章不打算给你讲那些别人已经讲烂了的概念定义，我只想从一个实际做项目的人的角度，聊聊这三个东西到底能解决什么问题，各自藏着什么坑，以及它们之间到底是什么关系。如果你也在纠结技术选型，或者在研究知识库方案，这篇应该能帮你省不少时间。

1. 超长上下文：先聊聊这个最热闹的军备竞赛

1.1 从8K到1M，窗口翻倍背后的技术推手

先回顾一下背景。大概在两三年前，主流模型的上下文窗口还停留在2K到8K，很多早期做长文档分析的人都被这个限制逼疯过——一份合同、一份研报根本塞不进去，只能做文本切片，然后被各种切坏语义的问题反复折磨。到了2024年之后，事情开始变得有点魔幻，128K成了标配，200K、1M甚至更长的上下文窗口开始出现在各家模型的能力列表里。

很多人以为这个窗口变长就是简单的"把门开大一点"，但实际上它牵扯到一系列底层改动。先说位置编码，Transformer本身是没有顺序概念的，靠的是位置编码注入位置信息。早期用的绝对位置编码在长序列上会很快失效，后面大家普遍转向了相对位置编码，像RoPE（旋转位置编码）这种方案，配合YaRN等缩放方法，才能把窗口从训练时的几K外推到上百K。再说注意力机制，标准Attention的计算量是序列长度的平方，1M token的全量注意力在工程上是不可接受的，所以各家都在做稀疏注意力、滑动窗口、FlashAttention这类优化，核心思路就是在不显著损伤效果的前提下，用局部注意力代替全局注意力。还有KV Cache的问题，1M上下文意味着KV Cache要吃掉大量显存，MQA、GQA这些多头参数共享机制就是为了缓解这个压力。

所以你现在看到的"1M上下文"，本质上是一系列工程妥协和算法优化叠加出来的结果，它不是模型真的对1M个token都一视同仁地"理解"，而是通过特定机制让模型在超长输入下不至于崩溃。这个认知很重要——它决定了你对长上下文该抱有多大期待。

1.2 长窗口的真实体验：不是越长越好

理论说完了，说说实际体验。我把一份接近500页的行业研究报告拆成PDF喂给了一个支持128K上下文的模型，然后设计了三组问题：一组问文档开头部分的信息，一组问中间部分，一组问结尾部分。结果很有意思——开头和结尾的信息召回率明显好于中间，尤其是文档第200到第300页的内容，模型经常给出模棱两可甚至张冠李戴的回答。

这个现象其实有个名字，叫"Lost in the Middle"，指的就是大模型对长上下文中间位置的信息遗忘更严重。学术界早有研究指出这是Transformer架构的固有问题：模型对序列开头和末尾的注意力天然更强，中间部分容易被"淹没"。我实际跑下来，这个现象比论文里描述得还要明显。另一个体感问题是延迟，在1M上下文下，哪怕只是做一个简单的问答，模型花在"重新阅读"整个上下文上的时间也非常可观，预填充阶段能明显感觉到等待时间变长。如果你把超长上下文嵌入到实时交互系统里，这个延迟可能直接把用户体验拖垮。

还有成本问题。目前API计费是跟着token数走的，上下文越长，每次请求的输入成本就越高。你在上下文里塞了1M token，不管问一个多么简单的问题，都要为这1M的"阅读量"买单。做过预算评估的朋友应该明白，这在规模化场景下是一笔相当大的开销。我算过一笔账，按常见价格估算，每秒处理接近几百个token的速度来算，如果全量看一眼1M token再回答，单次请求光输入部分的成本就非常可观，这在线上高频场景下基本不可持续。

1.3 超长上下文替代不了RAG的三个理由

有人在讨论里说，既然上下文能到1M了，RAG是不是该淘汰了？我测试了一圈之后，坚定地认为——在很长一段时间内，这个想法都站不住脚。

第一，成本模型上，RAG仍然是增效降本的。RAG的处理逻辑是按需取用，先检索再生成，喂给模型的只是和问题最相关的几万token；而超长上下文是全量投喂，成本是RAG的几十倍不止。多轮对话场景下差距还要放大，因为每轮都要重新处理全量上下文。第二，可追溯性上，RAG有天然的溯源优势。RAG可以明确告诉用户"我的回答来自哪份文档的哪一段"，这对法律、金融、医疗这些需要交代来源的场景几乎是硬要求。第三，更新效率上，RAG可以随时增删改索引库，秒级生效；而超长上下文方案如果想要纳入新知识，要么等模型重新训练，要么就得在每次请求里额外塞新的内容，运维成本不言而喻。

我做过的项目中，比较合理的做法是把超长上下文定位成"工作记忆"，用在单篇长文档精读、复杂代码库单次分析这类场景；把RAG定位成"长期记忆"，负责多文档、多轮次、可追溯的知识问答。两者互补，不是一个替代另一个的关系。

2. Agentic检索：把检索从"一次查询"变成"一个过程"

2.1 传统RAG卡在哪

说说Agentic检索。要理解它，得先知道传统RAG哪里不够用。经典RAG的逻辑是"召回—排序—生成"三步走：对用户问题做语义检索，从向量库里拉出top-k文档，拼进Prompt，交给模型生成答案。这套流程在小范围、弱关联的FAQ场景下表现不错，但一旦遇到复杂问题就露馅了。

我踩过一个很典型的坑。之前在做一个企业合同审查助手，用户会问"2023年我们跟A公司签的合同中，逾期违约金比例是多少？"这类问题。传统RAG把这个问题向量化之后去召回，因为问题里同时涉及公司名、年份、合同类型、违约金等多个约束条件，向量检索的结果经常缺胳膊少腿——要么召回了一份含"违约金"但年份不对的合同，要么单独把"2023年"的几份合同都召回了，但里面根本没有涉及A公司。最终答出来的结果自然是错的。

问题本质上出在两点：一是RAG只做一次检索，检索的好坏完全取决于切块质量和向量相似度计算的运气，查不到就查不到了；二是RAG不具备多步推理能力，复杂问题往往需要拆成多个子问题，分别检索，再汇总推理，传统RAG没有这个机制。

2.2 Agentic Retrieval的几种典型形态

Agentic检索的思路就是给RAG装上"大脑"，让它像人一样去查资料：先判断这个问题要不要查，再决定查什么、怎么查，查到结果后评估够不够，不够就换个关键词继续查，直到拿到足够的信息再给出答案。

目前主流形态大概有四类。第一种是Self-RAG，模型在生成过程中不断自我质疑，动态决定要不要检索、要检索什么，而不是预先固定一个检索动作。第二种是CRAG（Corrective RAG），它对检索结果先做一轮评估，如果觉得结果质量不行，就触发改写查询或者换一个检索源重查，相当于加了一道"质检"流程。第三种是Adaptive RAG，它先对问题进行路由分类，简单问题直接让模型回答，复杂问题才进入检索流程，避免杀鸡用牛刀。第四种是更广义的Agentic RAG，也就是把检索、代码执行、API调用等打包成工具，模型以ReAct循环的形式自主编排调用这些工具，边思考边行动。

这些形态差异很大，但内核一致：把"检索"这个单一动作，升级为"计划—执行—反思—再执行"的闭环。它不再是一次性的信息查询，而是一个可以自主推进的任务过程。

2.3 一个可落地的Agentic RAG实现示例

光说概念不好消化，我放一个自己实现过的简化版流程，用LangGraph做的，跑得很稳。整个流程由几个节点构成，核心是一个循环：路由、检索、评分、改写、再检索、生成。

第一步是路由节点，让LLM判断当前问题是需要外部知识还是可以直接凭模型知识回答。这一步就避免了Adaptive RAG里说的"杀鸡用牛刀"问题。如果判断需要检索，进入第二步检索节点，它根据原始问题生成检索关键词，去向量库召回top-10文档。第三步是评分节点，用一个类似CRAG的prompt让LLM给这10份文档逐条打分，评估它们和问题的关联度。注意这里不是用机器学习打分，而是直接让LLM做"阅读理解后评价"，虽然费一点token，但准确率明显更高。

关键的第四步来了——判断。如果打分结果整体偏低，触发改写节点，让LLM重新拆解问题，比如把上面的合同违约金问题拆成两个子查询："查找2023年与A公司签订的合同"和"提取该合同中的违约金条款"，分别重新检索。如果评分通过，就进入生成节点，把高分的几段内容拼进Prompt，输出最终答案，并在答案末尾附带引用来源。整个循环最多跑两轮，避免无限递归浪费资源。

这个流程我拿之前失败的"违约金"问题做测试，第一轮检索出来关联度不足触发了改写，第二轮就从一个旧的违约金模板文档里补到了缺失的信息，最终答案正确。相比传统RAG，这个方案准确率肉眼可见地提升了，代价就是每一次检索平均要多花几轮LLM调用，成本和延迟也随之增加。所以一定要在路由节点做好把控，别让所有问题都走完整流程。

2.4 代价与风险

Agentic RAG不是免费的午餐。首先最直接的代价就是成本和延迟：一次完整的Agentic检索可能涉及四五次甚至更多的LLM调用，token开销可能是传统RAG的十倍以上，响应时间也从"秒回"变成"可能等十几秒"。对于面向终端用户的产品，这个延迟需要精细设计交互方式来掩盖，比如流式输出、进度提示等。

第二个风险是错误累积。传统RAG只要检索本身不出错，结果基本可控；Agentic RAG多了改写过、评分、路由等环节，任何一步出现幻觉或误判，错误会沿着链路传导，而且因为链路复杂，出了问题还很难复现和调试。我自己调试这种链路时最头疼的就是——同一个问题，有时候能跑通，有时候在改写节点跑飞，有时候在评分节点把好文档判了低分。这个不确定性在需要稳定输出的生产环境里要格外警惕。

第三个隐性问题是对Prompt和模型能力要求更高。Agentic流程里的每个节点本质上都是在做"复杂的指令跟随"，如果基座模型能力不够，评分不准、改写跑偏、路由误判都会频繁出现。所以我的建议是：Agentic RAG至少要用当前第一梯队的模型，而不是随便拿一个小模型硬套框架。

3. LLM Wiki：知识库的下一形态长什么样

3.1 LLM Wiki到底是什么

聊完Agentic检索，说第三个词LLM Wiki。说实话，这个词比前两个要模糊得多。有人理解成"用LLM来自动写Wiki页面"，有人理解成"给Wiki装一个ChatGPT式问答入口"，还有人理解成"把私有知识库变成Wiki结构"。

我的理解是，LLM Wiki指向的是一种知识组织方式的升级——以LLM为引擎，从海量文档中抽取出结构化知识，以Wiki的形态（页面、条目、分类、链接）组织起来，并且这套知识库本身可以由LLM持续维护和更新。它不是简单的"文档+聊天框"，而是"文档—结构化知识—可交互问答—可自动更新"的完整链条。传统的RAG只是把文档切片之后存进向量库，检索出来的还是"原文片段"；LLM Wiki则是先让LLM把文档"读透"，提炼出实体、概念、关系，再把这些知识组织成类似Wiki的条目网络。你可以不把它当成一个搜索工具，而是当成一个"读过你所有资料、并且会做知识整理的数字同事"。

这个定义往下再挖一层，就自然牵扯到本体（Ontology）和GraphRAG。这两个词在近期的讨论中经常和LLM Wiki一起出现。本体解决的是"知识骨架"的问题——你定义了"公司""合同""违约金条款""合同有效期"这些概念以及它们之间的"签订""属于""约定"等关系，LLM在抽取知识时就有了明确的框架，抽出来的内容不再是零散的实体，而是一张有结构的知识网络。GraphRAG则是把这个网络落实下来的工程实现——用图谱存储知识，检索时沿着关系路径推理，而不是只做向量相似度匹配。

3.2 从RAG到GraphRAG再到LLM Wiki

为了把LLM Wiki的定位讲清楚，我给这三者画个比较框架。传统RAG是"点状知识服务"，它回答"基于这两段内容，这是什么"；GraphRAG是"网状知识服务"，它回答"这些实体在知识图谱中如何关联，推演出什么结论"；LLM Wiki则是"常驻知识管家"，它不光会回答，还会主动把新文档消化成知识条目，更新到Wiki体系里。

我实测过GraphRAG方案，它确实能解决传统RAG处理多跳问题时的那种无力感。比如问"上季度利润率下降，跟哪个供应商的合作变化有关"，传统RAG几乎无从下手，因为答案分散在财务报表和供应商合同中，需要跨文档追踪关系链；而GraphRAG可以通过图结构沿着"利润率—关联供应商—合同条款—交付变化"这条关系链跳转，找到因果线索。之前我们做完GraphRAG测试的第一个感受就是：这个查询的准确率从基线RAG的大约50%出头提升到了80%上下，效果非常明显。

但GraphRAG有个前置成本，就是图谱构建。不事先定义好实体类型和关系类型，抽取出来的图就会是一团乱麻。在我自己构建图谱的过程中，深有体会：之前抽取实体关系时没有定义"事件"和"时间"这两个本关系类型，结果图里每个节点都在疯狂扩展，一个"2024年涨价"的事实被拆成了"2024年""涨价""事件"三个孤岛，检索时完全连不上。后来重新设计了本体Schema，把时间属性内联成节点属性而不是单独的图节点，整个图谱的可用度才提上来。LLM Wiki理念上承接的正是这部分工作——让LLM我认为自动完成本体的设计、实体抽取和持续维护，让知识库从"需要人工维护的图"走向"自动生长的Wiki"。

3.3 构建LLM Wiki的关键环节

如果你也想构建一个LLM Wiki，我梳理了一套可以落地的流程。第一步是语料治理，把散落在PDF、Word、网页里的内容做清洗和格式归一。这一步决定了后续抽取质量的天花板，OCR质量差、格式混乱的文档，后面大概率抽取出一堆噪音。第二步是本体Schema设计，这是最关键的一步，在你让LLM开始抽取之前，先人工定义清楚核心概念和关系类型。比如在合同领域，你至少要定义合同主体、合同类型、签订日期、有效期、关联公司、违约责任条款、金额条款这些实体和关系；在学术领域，可能就是论文、作者、机构、引用关系、研究方法等。Schema不需要一次设计完美，但必须有一个骨架，否则LLM会"自由发挥"，产出结构混乱的图。

第三步是实体关系抽取，用LLM批量把文档中的实体和关系抽出来，这一步可以借助知识图谱工具比如Neo4j加上LangChain/LlamaIndex框架来做。第四步是知识入库与页面生成，把抽取结果去重、消歧之后，通过LLM自动生成Wiki页面。每个实体生成一个页面，页面上包括它的定义、属性、关联条目，以及来源。这一步是把"图数据"翻译成"人类可读的知识文档"，也是LLM Wiki和传统GraphRAG最直观的区别。第五步是增量更新，新文档进入系统时，只抽取新增和变更的部分，合并到已有Wiki中。增量更新是个大坑，稍后我会专门讲讲遇到的问题。

整个流程我用参考架构验证过：用Neo4j存图，用LLM做抽取，用向量库做全文检索兜底，前端用Wiki框架展示千兆的实体页面和关联关系，用户可以在Wiki页面上直接提问。综合体验下来，它比纯RAG多了一层"知识可视化"和"可解释性"，比GraphRAG多了"可阅读、可编辑、可持续演进"的维度。

3.4 我看好的点和担忧的点

先说我看好的。LLM Wiki最大的价值是知识资产的沉淀。传统RAG的索引是一堆切碎的向量文件，你既看不了也改不了，它像一个黑盒子，知识"进去"了但不再"可见"；而LLM Wiki把知识变成了结构化的、人类可见、可编辑的页面。这意味着企业可以把散落在各处的文档资产，逐步转变成一个活的、可视化的知识地图。这种可解释性是决定性的，当你的回答牵扯到敏感业务判断时，用户和审计人员都可以去Wiki页面自行验证，信任成本会低很多。

再说担忧。LLM Wiki最大的风险在维护成本。我前面提到的增量更新就是一场噩梦，新文档里的实体和旧Wiki里的实体经常对不上，一个"小明科技"和新来文档里的"小明科技有限公司"会被LLM判定为两个实体，然后Wiki页面上就会出现两条近似重复的条目标签。如果你不引入实体对齐、指代消解的机制，Wiki会随着内容增加而变得越来越混乱，最终又需要人来收拾。其次，本体Schema的维护本身是一个持续工作，而领域专家通常不愿意花时间做这件事。所以LLM Wiki在现阶段更适合知识密度高、数据量大、且愿意投入治理成本的组织，而不是一个开箱即用的玩具。

4. 三者怎么选：场景决定方案

4.1 对比与定位

看完前面三部分，你可能也在心里掂量它们的分量了。我用自己的话做一个总结对比：

这个表放在这里，不管选型时怎么纠结，对照它基本能锁定大方向。三个方案本质上不是并列的选项，而是三个不同层次的架构组件——超长上下文是底座能力，Agentic检索是交互范式，LLM Wiki是知识组织形态。它们各有各的最佳适用边界。

4.2 我的选型建议

在实际项目里，我更倾向于组合使用而不是单选。给一个我总结出的推荐组合：用LLM Wiki做知识底座，先把核心业务文档结构化沉淀为领域知识图谱和Wiki页面；再用Agentic RAG作为问答交互层，让用户通过自然语言提问，由Agent在这个知识底座上完成路由、检索、多跳推理；最后把超长上下文作为"特例通道"，遇到超大单文档、需要全局通读的任务时，不走Wiki通道，直接让模型读原文。

这套组合看似复杂，但每一层都在做自己最擅长的事。Wiki保证知识有结构、可解释，Agentic检索保证复杂问题拆解得开、找得准，超长上下文保证单篇超长内容不被切块切坏。我的经验是：别试图用某一个方案通吃所有问题，那样最后的妥协成本反而更高。

如果你是从零开始、预算有限，我建议这样渐进落地：先上传统RAG解决即时问答需求，同时用GraphRAG提取实体关系构建知识图谱，等到图谱质量稳定后，再增加Wiki页面展示层，最后再考虑是否引入Agentic检索。步子太快容易让团队在生产力和故障排查上疲于奔命，一步一步来反而更稳。

在决定每种技术是否适配自己业务时，我建议把三个技术栈分别独立做一个POC，拿几份真实业务数据，用一两个真实复杂问题去做效果对比，而不是听厂商或者KOL的推荐。我被各种"X技术将颠覆XX"的观点坑过太多次了，现在我只信实测数据。

5. 额外聊聊：我踩过的几个坑

5.1 切块参数不是玄学

无论你用哪种方案，文本切块这个前置环节永远是最大的隐性地雷。我见过太多人在RAG项目里拿默认切块参数（比如固定256字符）直接跑上线，然后被各种语义断裂问题折磨。

我的实操经验是两个方向：一是结合文档结构来切，优先按章节、段落、语义片段切，而不是硬按字符数切；二是嵌入模型的选择要和你切块粒度匹配，按句子切就要用更细粒度的嵌入模型，按段落切则需要更强的模型来保持语义完整度。切块大小和重叠度要针对你的语料类型做AB测试。我之前做了一个技术文档库，把chunk_size从256调到512、重叠度设成50之后，检索命中率提升了将近20%。但是同样的参数换到一个合同语料库就失效了——合同的条款边界非常清晰，按条款切才是最优解，而不是固定字数。所以切块这件事，一定要基于语料特点定制。

5.2 实体归一化是LLM Wiki的核心难题

前面提到了LLM Wiki的增量更新问题，我再展开说说体验。LLM在读取新文档时，几乎必然会把同一个实体以不同表述抽取出来，比如"腾讯""腾讯科技""腾讯计算机系统有限公司"在三篇文档里可能被抽成三个节点。

第一次跑增量更新的时候，我看着图谱里的实体计数暴涨，以为是自己加了更多文档导致的正常增长；直到我去查一个具体"目标公司"的关联页面时，发现它被拆成了七八个几乎一样的页面，才意识到问题的严重性。实体归一化（又称实体对齐、指代消解）做不好，图谱上的所有关系路径都会变得支离破碎，GraphRAG的多跳推理效果也会大打折扣。

解决办法目前没有银弹，我的实践组合是：先用基于规则的方法做同义归一，比如统一公司简称后缀；再用LLM做两两合并判断，让模型判断"A节点和B节点是否是同一实体"；最后配合向量相似度做一个兜底。这套方案能把重复节点的比例压到可接受的范围，但说白了，它仍然需要持续投入运维精力。如果你要上线LLM Wiki，一定得在预案里把"知识治理"的工时留出来，这不是一次性工作。

5.3 延迟与成本：不实测永远不知道

Agentic检索我刚落地的时候，还沉浸在"准确率提升"的兴奋里，直到测试同学报了一个bug——某个复杂问题的响应时间超过了30秒，页面一直转圈。

我回头一看链路日志，好家伙：路由1次调用、检索2个通道、评分2次调用、改写1次调用、再检索2个通道、生成1次调用，加起来是8次LLM调用，每次平均2秒钟，总延迟接近20秒；如果再遇到一次改写节点触发循环，那就妥妥超过30秒。我当时的体感就一句话："这玩意儿根本没法直接面向用户用。"

后来我做了三层优化：一是在路由阶段把简单直接的问题直接放行，只让少量复杂问题走完整链路，这叫漏斗收敛；二是给评分和改写节点用更小更快、推理成本更低的模型；三是每个节点都加了超时和最大循环次数，宁可返回"查不到"，也不能无限转圈。优化之后，20%的请求走完整Agentic流程，80%的请求走轻量级RAG通道，整体平均延迟压到了3秒以内。这个经验就一句话：Agentic检索不是让所有请求都变聪明，而是让需要聪明的请求变聪明，其余的保持轻快。

写在最后：技术选型的底气来自实测

这三条技术路线到底谁会胜出？我不想下结论。我能确定的是：超长上下文解决的是"单次读得完"的问题，Agentic检索解决的是"查得准、查得深"的问题，LLM Wiki解决的是"知识能不能沉淀下来、持续生长"的问题。三条线各有各的适用场景，不是谁淘汰谁的关系。

如果你现在正站在选型路口，我给的建议是：工具和框架不是最重要的，真正重要的判断依据，是你要解决的业务问题到底属于哪一层。先在3个或4个真实业务问题上做一轮对比测试，把效果、成本、延迟三个维度打在一个表格里，再回头看这篇文章，你会有自己的结论。

最后再分享一个小技巧：在测试任何RAG或者知识库方案之前，先把业务方最头疼的三个高频问题列出来，然后用这三条路线分别去跑一遍，把"追问一轮"也算进效果评估里。你会发现，很多概念型技术在最真实的问题面前，会立刻脱掉光环，露出它真正的实用程度。