最近一周我的信息流里同时被三个词刷屏超长上下文、Agentic检索、LLM Wiki。乍一看是三个独立方向但越读越觉得它们都在回答同一个问题——大模型怎么知道该知道的事。尤其是LLM Wiki这种把知识库做成“活记忆”的思路配合RAG、GraphRAG这些老概念一起看很多以前模糊的地方反而清晰了。这篇就把我逐个分析的过程和结论写下来供同样在选型的人参考。1. 三个方向扎堆出现争的其实是同一块“知识入口”先说个背景判断这三者都不是凭空冒出来的新玩具而是“RAG落地到一定阶段后必然长出来的三个分支”。大家在做检索增强生成时遇到的痛点足够多于是有人往“塞更多上下文”走有人往“让检索更智能”走还有人干脆往“重建知识组织方式”走。殊途同归目标都是提高LLM输出的事实密度和可信度。1.1 超长上下文动了RAG的“喂料”逻辑传统RAG的逻辑是“先检索再生成”先从知识库捞出若干片段拼成上下文喂给模型。超长上下文的出现本质上是想跳过“检索”这个环节——既然窗口足够大能不能把整本手册、整个代码仓库直接塞进去这个想法很诱人尤其是看到100k、200k甚至1M参数的窗口规格时第一反应确实是“那我还要检索干嘛”。但实际用下来会发现窗口变大解决的是“能不能装下”而不是“装下之后模型能不能用好”。这个问题后面详细展开。1.2 Agentic检索动了RAG的“匹配”逻辑传统RAG的另一个命门是“相关性匹配”——一句query打过去top-k召回命中就万岁没命中就白搭。Agentic检索想改变的是这个交互过程不再是一锤子买卖而是让检索变成一个可规划、可执行、可验证的多步流程模型根据自己的判断决定下一步检索什么。所以Agentic检索不是在优化“召回率”而是在改造“检索这个动作本身的性质”。这也是为什么我会把它单独拎出来分析——它跟超长上下文解决的问题不一样但跟超长上下文组合起来有化学反应。1.3 LLM Wiki动了RAG的“记忆”逻辑LLM Wiki则更激进它不满足于“从已有文档里检索”而是想维护一个由LLM持续整理、归纳、更新的知识库结构。你可以把它理解为——把散落的文档加工成一本不断再版的百科全书而不是一个只能搜原文的数据库。有意思的是这个方向的讨论里经常带着“本体RAG”和“GraphRAG”一起出现因为它们都在尝试一件事给知识加上结构。但LLM Wiki的结构不是预先画好的知识图谱更像是一个随着对话和应用逐渐长出来的wiki站。这个差异很关键。2. 超长上下文——窗口变大了但问题没有消失只是换了位置先从超长上下文说起。因为它是表面上看“最不需要解释”的方向但也是我实测后落差最大的一个。2.1 从“塞不进去”到“塞进去也没用”长文本的真实瓶颈很多人对超长上下文的预期是把整个项目文档丢进去问什么都能答。但实际跑过一轮之后会发现能装1M token和能在1M token里找到所需信息是两回事。我自己的实测场景是拿某开源项目的完整开发文档约60万字做了个超长上下文问答。单看窗口容量完全没压力但问细节问题时明显感受到几类问题中间部分的信息容易被忽略。这就是被反复提到的“Lost in the Middle”现象——模型对开头和结尾的内容利用率远高于中间部分。文档越长中段信息就越像不存在。注意力被无关内容稀释。上下文里塞了大量背景介绍、历史版本说明、边缘案例真正回答问题的信息可能只有几百字但模型要把所有内容都过一遍注意力计算关键信息反而没那么突出。KV Cache的内存成本涨得很离谱。长上下文不是免费的推理时的KV Cache随着输入token数近似线性增长1M窗口的部署成本比想象中高得多高并发场景基本不太现实。还有一个反直觉的点超长上下文在单论“单次回答准确率”上并不一定优于“检索后拼装上下文”。我拿50个问题做过A/B对比超长上下文直接全量输入 vs 先做top-8检索再输入后者命中率反而高出几个点。原因也简单检索相当于给模型划了重点而长文本是在考验模型的注意力分配能力。2.2 该用什么姿势使用超长上下文不是说超长上下文没用而是得用对场景。根据我这段时间的测试适合直接全量塞进窗口的情况有这么几类代码仓库级别的理解任务。比如把整个微服务项目的核心代码塞进去问“订单状态的流转逻辑”模型能直接跨文件关联出答案检索方案在这里反而容易漏。需要全局一致性的分析。比如“这份300页合同里有没有对甲方不利的条款”需要同时扫全篇检索模式会被top-k截断视野。日志与链路追踪的排查。把一段长时间段的日志全量丢进去让模型找异常模式这个场景下前后文连续性比精确命中更重要。但如果是“面对持续更新的知识库做问答”——比如企业内部的FAQ、产品文档、售后案例这些内容长期积累总量远远超过任何窗口规格且更新频繁全量塞入既不经济也无法保证即时性。这种场景还是得回到检索。2.3 我的判断超长上下文是“底盘”不是“替代品”读了那么多讨论自己也做了实测我对超长上下文的态度已经稳定为八个字够用就好别当万能药。最大价值在于它允许我们省掉一层“过度检索”直接把原始材料交给模型减少因检索环节丢失信息带来的“答非所问”。但它替代不了检索系统的原因还有一个——成本。同样一次问答超长上下文全量输入的token消耗是“检索拼接”方案的一个数量级差距还要算上更长的首字延迟。对生产环境来说不存在某个方案“绝对更好”只存在“这个场景下哪个更划算”。所以我对超长上下文的理解是它是整个RAG链路的一个前置增强器而不是终结者。你可以少做几轮检索召回但检索这层还是得有。3. Agentic检索——从“一次命中”到“反复逼近”把检索当推理来做相对超长上下文的“靠窗口硬扛”Agentic检索的思路完全反过来窗口仍然有限那就让检索过程自己“聪明起来”。3.1 传统RAG在复杂问题上的几类翻车现场先讲传统RAG哪里不行才知道Agentic在补什么洞。最典型的场景是多跳问题。比如问“A公司收购的B公司现在还在B公司任职的高管是谁”。这个问题的真实链路是先得知道A收购了B再查B现在的管理层再判断哪些是从收购前就在任的。传统RAG的embedding检索是对整句query做相似度匹配它不擅长把一个问题拆成多个子问题再逐步逼近所以经常会召回一些“包含相同人名但没有回答到点子上”的片段。第二个常见翻车是“关键词不重叠但语义关联”的情况。数据库里写的是“薪资结构包含基本工资与绩效奖金”用户问的是“每个月到手能有多少”。字面不匹配、语义关联又不强embedding在这种场景下时灵时不灵。还有就是需要多源交叉验证的问题。传统RAG是“召回即信任”没有“这个说法在另一份文档里有没有佐证”的概念所以单源检索得到的答案可能完整但不可靠。3.2 检索代理是怎么工作的Agentic检索的核心改动是把“检索”当作一个可执行的工具由LLM来驱动循环。一套比较常见的流程是这样的规划LLM看到问题后先拆解成若干子任务。比如上面那个“高管是谁”问题会拆成“查收购关系”、“查任职高管”、“查任职时间线”。执行对每个子任务发起检索调用可以是embedding检索也可以是关键词检索、SQL查询、API调用甚至包括网页搜索。验证拿到结果后LLM自己判断这些材料是否足以回答问题。不够就继续够了就合成答案。迭代每次检索的结果都会成为下一步检索的输入条件形成递归逼近。这个过程中LLM不是被动接收top-k结果而是像人一样一次搜不到就换关键词看到了A公司收购了B公司再顺着B公司的名字去检索它的高管名单。我测试过一个“某供应商报价是否合理”的复杂查询传统RAG需要我把问题拆好再分别检索Agentic检索直接怼一个整问题过去它能自己走完“找历史报价→找该供应商服务质量→对比行业均价”的完整链路过程的透明度还很高。3.3 Agentic检索的代价和适用边界单看效果确实香但Agentic检索不是没有代价的。最直接的是延迟。一次单轮RAG可能1到2秒出答案Agentic检索动辄要5到10秒——因为要跑好几个子任务、好几轮检索。对实时对话场景这个延迟是体验上的硬伤。再是token成本。规划、验证、迭代每一步都会产生模型调用费用一次复杂查询的推理开销可能是传统方案的5到10倍。我见过有的团队把Agentic检索上线后月度模型账单直接翻倍。还有一个容易忽略的问题错误传播。检索计划本身就是LLM生成的如果第一步规划就歪了后面每一步都在错误方向上越走越深。传统RAG至少是“召回不相关”的单次错误Agentic犯错了很有可能是连环错误。所以我的判断是Agentic检索适合“调研型”、“分析型”、“一次性深度问答”这类场景不适合“用户反复问基础问题”的高频低成本场景。如果你做的是一个退货政策问答机器人没必要用Agentic一轮检索加一个明确的判断逻辑就足够了但如果是给投研、咨询、法务这种角色做一个深度问答助手Agentic的价值极其明显。4. LLM Wiki——把知识库从“检索库”变成“会维护的记忆”第三个方向LLM Wiki是我分析完觉得最有意思、也最容易被低估的。它的重点不在“怎么读取知识”而在“知识是怎么组织的”。4.1 为什么有人开始弃RAG拥抱WikiRAG的两个尴尬传统RAG看似简单好用但有两个绕不开的尴尬。第一个尴尬是知识碎片化。RAG的存储单元是切好的文档片段模型回答问题时只能基于这些孤立的片段拼接。对于“某个概念为什么这样设计”这类需要归纳总结的问题RAG只能把原文相关段落找出来不能站在更高的抽象层给出答案因为抽象层在文档里根本不存在。第二个尴尬是只存原话不沉淀结论。企业内部的知识很典型最初是一堆会议纪要、方案PPT、聊天记录这些是原始材料而不是知识本身。真正的知识是“我们最终定了什么方案、为什么这么定、边界条件是什么”。RAG像档案馆你问什么它给你什么原文但档案馆不会自动写出一本《组织内最佳实践手册》。GraphRAG曾经让人看到希望——它把文档里的实体和关系抽出来建成图谱多跳能力确实强于纯向量检索。但GraphRAG的成本也很现实建图需要投入大量LLM调用图的质量还高度依赖抽取效果很多团队试了之后发现投入产出比并不理想。4.2 LLM Wiki实操上到底在做什么LLM Wiki这个方向的操盘思路更有意思它把知识库维护成一个可以持续更新、交叉引用、层级组织的Wiki站点LLM既负责撰写页面内容也负责维护页面之间的链接关系。我在测试一个类Wiki方案时落地起来大致有这几个步骤无需预设schema的页面创建LLM从文档里发现一个值得沉淀的主题比如“退换货流程”自动创建一个Wiki页面内容包括定义、流程步骤、注意事项。来源引用与更新链路每个页面内容都挂靠在原始文档或对话记录上当新的原始材料出现时LLM来判断已有页面是否需要更新、扩充或修正。交叉链接和层级归类比如“退换货流程”和“售后时效政策”两个页面之间自动建立关联形成比GraphRAG更接近人类使用的知识导航结构。最关键的区别在于——Wiki页面可以存结论RAG只能存证据。RAG里你搜“退款到账时间”只能拿到某个文档片段LLM Wiki里这个信息早就被整理成一个明确的词条“退款到账时间1-3个工作日大促期间顺延”回答时可以一键引用。4.3 与RAG、GraphRAG、本体RAG的对比为了把这几个概念理清我拉了一张对比表维度传统RAGGraphRAG本体RAGLLM Wiki知识组织方式原始文档片段实体关系图谱预定义本体schemaLLM动态维护的wiki页面建造成本低高实体抽取图构建高需要专家设计本体中需要持续维护策略可解释性中引用原始片段低图谱链路晦涩中本体约束较清晰高页面内容可直接阅读多跳能力弱强强中到强依赖链接质量结论沉淀能力无弱弱强更新维护成本低重新切片即可高需要重构图谱高schema变更成本大中需设计增量更新策略这表里最关键的两列是“可解释性”和“结论沉淀能力”。GraphRAG虽然多跳能力强但它生成的答案是沿着图谱路径推理而来的用户很难验证路径是否正确本体RAG思路清晰但前置成本太高对知识专家和时间的要求都很重。LLM Wiki在落地性价比上反而显得平衡。4.4 LLM Wiki不是要代替RAG而是包一层“整理层”我看不少人讨论LLM Wiki时喜欢把它和RAG对立起来。但以我自己的测试体验来说LLM Wiki更像是跑在“检索”之上的一个整理层——它仍然需要底层有检索能力只不过最终用户拿到的不再是“检索到的碎片”而是“整理成型的知识页面”。所以我把这个方向定位成“知识库的运营层”RAG负责回答Wiki负责沉淀。一句话说就是——RAG管“用”Wiki管“养”。5. 逐个分析完我个人的取舍与组合建议三个方向都分析完了文字也都比较长。可能你会觉得一切都“看场景”没有直接结论。那这一节我收敛一下给出我在实际项目里的选择逻辑。5.1 先看任务类型再选技术别让技术选任务我的习惯是把知识问答类需求分成三角色一次性任务、深度调研、长期复用。一次性任务比如“把这500页PDF看一遍并总结重点”直接超长上下文硬喂不做检索省时省力。深度调研比如“分析这个竞品的定价策略变化”上Agentic检索让它自己去多轮查证。长期复用比如企业内部FAQ、产品手册、项目决策记录上LLM Wiki持续整理、持续沉淀。这三个角色不是互斥的。实际项目里常常是一个系统同时承担三种任务区别在于路由逻辑——用户进来先判断任务类型再决定底层走哪条链路。5.2 我推荐的落地组合打法如果让我设计一个生产环境的方案我会按下面这个三层结构来做底层超长上下文做“工作台”。用户发起复杂任务时允许把一份较大的上下文一次性载入而不是死板地限定在“先检索再拼装”。中间层Agentic检索做“入口路由”。对复杂问题让检索代理自主拆解、多轮召回对简单问题直接走轻量单轮检索控制算力成本。顶层LLM Wiki做“知识沉降”。每次高质量问答完成后把答案中可复用的结论、边界条件、来源链接沉淀回Wiki页面让系统越用越聪明。这套组合里最核心的其实是第3层。因为前两层的收益是一次性的第3层才是复利。我也确实见过一些团队做了不错的RAG系统但因为缺少沉淀层同样的问题隔两个月还会被重新问一遍、重新检索一遍、重新答一遍——等于所有成本都重复支出。5.3 落地前容易踩的坑最后提几点我在实际操作中踩过、或者看别人踩过的坑别迷信“越大越好”的上下文窗口。我自己踩过的一个坑是为了直接用超长上下文省掉检索结果模型常常引用文档中段的不相关内容。后来老老实实加了一层快速检索做粗筛准确率立刻上来了。Agentic检索一定要设停止条件。不加迭代上限的话遇到模糊问题模型会无限子查询延迟和账单都很失控。我的做法是设置最大子查询次数5次以内、总延迟预算60秒超了就兜底返回“检索到部分信息”的降级答案。LLM Wiki的“维护策略”比“建站策略”更重要。页面建出来不难难的是让它不陈旧、不矛盾、不冲突。我建议一开始就设计好“更新触发机制”每次检索命中某个Wiki词条且用户给出了反馈就重新评估该词条是否需要修订。没有这个闭环Wiki会慢慢变成一本过期刊物。评估指标别只盯着命中率。RAG类项目的上线评测除了常规的“回答正确率”至少还得看三个维度引用覆盖率回答内容是否都在引用材料中有支撑、忠实度回答是否忠实于引用内容有没有脑补、检索效率平均每轮提问触发了几次检索、多少成本。我遇到过命中率很高、但忠实度很低的情况——模型把相关片段找对了但答案却Provider了片段里没有的细节这种系统上线非常危险。最后一个我自己的体会逐个分析完这三个方向我最大的感觉是它们不是竞争关系而是分别补上了相同链条的不同缺口。超长上下文补的是“容量”Agentic检索补的是“路径”LLM Wiki补的是“沉淀”。如果把RAG比作一个人的工作方式超长上下文是“让他能一次看很多材料”Agentic检索是“让他会自己查不清楚的线索”LLM Wiki则是“让他把查到的内容写成笔记本下次不用再查一遍”。我现在的个人倾向已经比较明确新项目会默认采用“轻量检索 超长上下文扩展 Wiki沉淀”的组合Agentic检索按需启用。做这个判断不是因为哪个方向更酷而是因为我手里的大部分知识库项目真正的问题不是“单次问答不够准”而是“知识没有积累、重复劳动多”。当然如果你手头的场景是重调研、多跳、长链路分析Agentic检索的优先级应该上调。技术选型从来不是比参数大小而是比和问题的匹配度。如果你也在评估这三个方向我的建议是别听名词先去动手——拿自己的业务问题各跑一轮看哪个方向解决的是你最痛的那个环节。那往往就是你要重点投入的方向。 
长河君 · 2026/11/2 4:17:32 · 阅读 1.2k 超长上下文、Agentic检索与LLM Wiki：RAG落地的三条演进路径
最近一周我的信息流里同时被三个词刷屏超长上下文、Agentic检索、LLM Wiki。乍一看是三个独立方向但越读越觉得它们都在回答同一个问题——大模型怎么知道该知道的事。尤其是LLM Wiki这种把知识库做成“活记忆”的思路配合RAG、GraphRAG这些老概念一起看很多以前模糊的地方反而清晰了。这篇就把我逐个分析的过程和结论写下来供同样在选型的人参考。1. 三个方向扎堆出现争的其实是同一块“知识入口”先说个背景判断这三者都不是凭空冒出来的新玩具而是“RAG落地到一定阶段后必然长出来的三个分支”。大家在做检索增强生成时遇到的痛点足够多于是有人往“塞更多上下文”走有人往“让检索更智能”走还有人干脆往“重建知识组织方式”走。殊途同归目标都是提高LLM输出的事实密度和可信度。1.1 超长上下文动了RAG的“喂料”逻辑传统RAG的逻辑是“先检索再生成”先从知识库捞出若干片段拼成上下文喂给模型。超长上下文的出现本质上是想跳过“检索”这个环节——既然窗口足够大能不能把整本手册、整个代码仓库直接塞进去这个想法很诱人尤其是看到100k、200k甚至1M参数的窗口规格时第一反应确实是“那我还要检索干嘛”。但实际用下来会发现窗口变大解决的是“能不能装下”而不是“装下之后模型能不能用好”。这个问题后面详细展开。1.2 Agentic检索动了RAG的“匹配”逻辑传统RAG的另一个命门是“相关性匹配”——一句query打过去top-k召回命中就万岁没命中就白搭。Agentic检索想改变的是这个交互过程不再是一锤子买卖而是让检索变成一个可规划、可执行、可验证的多步流程模型根据自己的判断决定下一步检索什么。所以Agentic检索不是在优化“召回率”而是在改造“检索这个动作本身的性质”。这也是为什么我会把它单独拎出来分析——它跟超长上下文解决的问题不一样但跟超长上下文组合起来有化学反应。1.3 LLM Wiki动了RAG的“记忆”逻辑LLM Wiki则更激进它不满足于“从已有文档里检索”而是想维护一个由LLM持续整理、归纳、更新的知识库结构。你可以把它理解为——把散落的文档加工成一本不断再版的百科全书而不是一个只能搜原文的数据库。有意思的是这个方向的讨论里经常带着“本体RAG”和“GraphRAG”一起出现因为它们都在尝试一件事给知识加上结构。但LLM Wiki的结构不是预先画好的知识图谱更像是一个随着对话和应用逐渐长出来的wiki站。这个差异很关键。2. 超长上下文——窗口变大了但问题没有消失只是换了位置先从超长上下文说起。因为它是表面上看“最不需要解释”的方向但也是我实测后落差最大的一个。2.1 从“塞不进去”到“塞进去也没用”长文本的真实瓶颈很多人对超长上下文的预期是把整个项目文档丢进去问什么都能答。但实际跑过一轮之后会发现能装1M token和能在1M token里找到所需信息是两回事。我自己的实测场景是拿某开源项目的完整开发文档约60万字做了个超长上下文问答。单看窗口容量完全没压力但问细节问题时明显感受到几类问题中间部分的信息容易被忽略。这就是被反复提到的“Lost in the Middle”现象——模型对开头和结尾的内容利用率远高于中间部分。文档越长中段信息就越像不存在。注意力被无关内容稀释。上下文里塞了大量背景介绍、历史版本说明、边缘案例真正回答问题的信息可能只有几百字但模型要把所有内容都过一遍注意力计算关键信息反而没那么突出。KV Cache的内存成本涨得很离谱。长上下文不是免费的推理时的KV Cache随着输入token数近似线性增长1M窗口的部署成本比想象中高得多高并发场景基本不太现实。还有一个反直觉的点超长上下文在单论“单次回答准确率”上并不一定优于“检索后拼装上下文”。我拿50个问题做过A/B对比超长上下文直接全量输入 vs 先做top-8检索再输入后者命中率反而高出几个点。原因也简单检索相当于给模型划了重点而长文本是在考验模型的注意力分配能力。2.2 该用什么姿势使用超长上下文不是说超长上下文没用而是得用对场景。根据我这段时间的测试适合直接全量塞进窗口的情况有这么几类代码仓库级别的理解任务。比如把整个微服务项目的核心代码塞进去问“订单状态的流转逻辑”模型能直接跨文件关联出答案检索方案在这里反而容易漏。需要全局一致性的分析。比如“这份300页合同里有没有对甲方不利的条款”需要同时扫全篇检索模式会被top-k截断视野。日志与链路追踪的排查。把一段长时间段的日志全量丢进去让模型找异常模式这个场景下前后文连续性比精确命中更重要。但如果是“面对持续更新的知识库做问答”——比如企业内部的FAQ、产品文档、售后案例这些内容长期积累总量远远超过任何窗口规格且更新频繁全量塞入既不经济也无法保证即时性。这种场景还是得回到检索。2.3 我的判断超长上下文是“底盘”不是“替代品”读了那么多讨论自己也做了实测我对超长上下文的态度已经稳定为八个字够用就好别当万能药。最大价值在于它允许我们省掉一层“过度检索”直接把原始材料交给模型减少因检索环节丢失信息带来的“答非所问”。但它替代不了检索系统的原因还有一个——成本。同样一次问答超长上下文全量输入的token消耗是“检索拼接”方案的一个数量级差距还要算上更长的首字延迟。对生产环境来说不存在某个方案“绝对更好”只存在“这个场景下哪个更划算”。所以我对超长上下文的理解是它是整个RAG链路的一个前置增强器而不是终结者。你可以少做几轮检索召回但检索这层还是得有。3. Agentic检索——从“一次命中”到“反复逼近”把检索当推理来做相对超长上下文的“靠窗口硬扛”Agentic检索的思路完全反过来窗口仍然有限那就让检索过程自己“聪明起来”。3.1 传统RAG在复杂问题上的几类翻车现场先讲传统RAG哪里不行才知道Agentic在补什么洞。最典型的场景是多跳问题。比如问“A公司收购的B公司现在还在B公司任职的高管是谁”。这个问题的真实链路是先得知道A收购了B再查B现在的管理层再判断哪些是从收购前就在任的。传统RAG的embedding检索是对整句query做相似度匹配它不擅长把一个问题拆成多个子问题再逐步逼近所以经常会召回一些“包含相同人名但没有回答到点子上”的片段。第二个常见翻车是“关键词不重叠但语义关联”的情况。数据库里写的是“薪资结构包含基本工资与绩效奖金”用户问的是“每个月到手能有多少”。字面不匹配、语义关联又不强embedding在这种场景下时灵时不灵。还有就是需要多源交叉验证的问题。传统RAG是“召回即信任”没有“这个说法在另一份文档里有没有佐证”的概念所以单源检索得到的答案可能完整但不可靠。3.2 检索代理是怎么工作的Agentic检索的核心改动是把“检索”当作一个可执行的工具由LLM来驱动循环。一套比较常见的流程是这样的规划LLM看到问题后先拆解成若干子任务。比如上面那个“高管是谁”问题会拆成“查收购关系”、“查任职高管”、“查任职时间线”。执行对每个子任务发起检索调用可以是embedding检索也可以是关键词检索、SQL查询、API调用甚至包括网页搜索。验证拿到结果后LLM自己判断这些材料是否足以回答问题。不够就继续够了就合成答案。迭代每次检索的结果都会成为下一步检索的输入条件形成递归逼近。这个过程中LLM不是被动接收top-k结果而是像人一样一次搜不到就换关键词看到了A公司收购了B公司再顺着B公司的名字去检索它的高管名单。我测试过一个“某供应商报价是否合理”的复杂查询传统RAG需要我把问题拆好再分别检索Agentic检索直接怼一个整问题过去它能自己走完“找历史报价→找该供应商服务质量→对比行业均价”的完整链路过程的透明度还很高。3.3 Agentic检索的代价和适用边界单看效果确实香但Agentic检索不是没有代价的。最直接的是延迟。一次单轮RAG可能1到2秒出答案Agentic检索动辄要5到10秒——因为要跑好几个子任务、好几轮检索。对实时对话场景这个延迟是体验上的硬伤。再是token成本。规划、验证、迭代每一步都会产生模型调用费用一次复杂查询的推理开销可能是传统方案的5到10倍。我见过有的团队把Agentic检索上线后月度模型账单直接翻倍。还有一个容易忽略的问题错误传播。检索计划本身就是LLM生成的如果第一步规划就歪了后面每一步都在错误方向上越走越深。传统RAG至少是“召回不相关”的单次错误Agentic犯错了很有可能是连环错误。所以我的判断是Agentic检索适合“调研型”、“分析型”、“一次性深度问答”这类场景不适合“用户反复问基础问题”的高频低成本场景。如果你做的是一个退货政策问答机器人没必要用Agentic一轮检索加一个明确的判断逻辑就足够了但如果是给投研、咨询、法务这种角色做一个深度问答助手Agentic的价值极其明显。4. LLM Wiki——把知识库从“检索库”变成“会维护的记忆”第三个方向LLM Wiki是我分析完觉得最有意思、也最容易被低估的。它的重点不在“怎么读取知识”而在“知识是怎么组织的”。4.1 为什么有人开始弃RAG拥抱WikiRAG的两个尴尬传统RAG看似简单好用但有两个绕不开的尴尬。第一个尴尬是知识碎片化。RAG的存储单元是切好的文档片段模型回答问题时只能基于这些孤立的片段拼接。对于“某个概念为什么这样设计”这类需要归纳总结的问题RAG只能把原文相关段落找出来不能站在更高的抽象层给出答案因为抽象层在文档里根本不存在。第二个尴尬是只存原话不沉淀结论。企业内部的知识很典型最初是一堆会议纪要、方案PPT、聊天记录这些是原始材料而不是知识本身。真正的知识是“我们最终定了什么方案、为什么这么定、边界条件是什么”。RAG像档案馆你问什么它给你什么原文但档案馆不会自动写出一本《组织内最佳实践手册》。GraphRAG曾经让人看到希望——它把文档里的实体和关系抽出来建成图谱多跳能力确实强于纯向量检索。但GraphRAG的成本也很现实建图需要投入大量LLM调用图的质量还高度依赖抽取效果很多团队试了之后发现投入产出比并不理想。4.2 LLM Wiki实操上到底在做什么LLM Wiki这个方向的操盘思路更有意思它把知识库维护成一个可以持续更新、交叉引用、层级组织的Wiki站点LLM既负责撰写页面内容也负责维护页面之间的链接关系。我在测试一个类Wiki方案时落地起来大致有这几个步骤无需预设schema的页面创建LLM从文档里发现一个值得沉淀的主题比如“退换货流程”自动创建一个Wiki页面内容包括定义、流程步骤、注意事项。来源引用与更新链路每个页面内容都挂靠在原始文档或对话记录上当新的原始材料出现时LLM来判断已有页面是否需要更新、扩充或修正。交叉链接和层级归类比如“退换货流程”和“售后时效政策”两个页面之间自动建立关联形成比GraphRAG更接近人类使用的知识导航结构。最关键的区别在于——Wiki页面可以存结论RAG只能存证据。RAG里你搜“退款到账时间”只能拿到某个文档片段LLM Wiki里这个信息早就被整理成一个明确的词条“退款到账时间1-3个工作日大促期间顺延”回答时可以一键引用。4.3 与RAG、GraphRAG、本体RAG的对比为了把这几个概念理清我拉了一张对比表维度传统RAGGraphRAG本体RAGLLM Wiki知识组织方式原始文档片段实体关系图谱预定义本体schemaLLM动态维护的wiki页面建造成本低高实体抽取图构建高需要专家设计本体中需要持续维护策略可解释性中引用原始片段低图谱链路晦涩中本体约束较清晰高页面内容可直接阅读多跳能力弱强强中到强依赖链接质量结论沉淀能力无弱弱强更新维护成本低重新切片即可高需要重构图谱高schema变更成本大中需设计增量更新策略这表里最关键的两列是“可解释性”和“结论沉淀能力”。GraphRAG虽然多跳能力强但它生成的答案是沿着图谱路径推理而来的用户很难验证路径是否正确本体RAG思路清晰但前置成本太高对知识专家和时间的要求都很重。LLM Wiki在落地性价比上反而显得平衡。4.4 LLM Wiki不是要代替RAG而是包一层“整理层”我看不少人讨论LLM Wiki时喜欢把它和RAG对立起来。但以我自己的测试体验来说LLM Wiki更像是跑在“检索”之上的一个整理层——它仍然需要底层有检索能力只不过最终用户拿到的不再是“检索到的碎片”而是“整理成型的知识页面”。所以我把这个方向定位成“知识库的运营层”RAG负责回答Wiki负责沉淀。一句话说就是——RAG管“用”Wiki管“养”。5. 逐个分析完我个人的取舍与组合建议三个方向都分析完了文字也都比较长。可能你会觉得一切都“看场景”没有直接结论。那这一节我收敛一下给出我在实际项目里的选择逻辑。5.1 先看任务类型再选技术别让技术选任务我的习惯是把知识问答类需求分成三角色一次性任务、深度调研、长期复用。一次性任务比如“把这500页PDF看一遍并总结重点”直接超长上下文硬喂不做检索省时省力。深度调研比如“分析这个竞品的定价策略变化”上Agentic检索让它自己去多轮查证。长期复用比如企业内部FAQ、产品手册、项目决策记录上LLM Wiki持续整理、持续沉淀。这三个角色不是互斥的。实际项目里常常是一个系统同时承担三种任务区别在于路由逻辑——用户进来先判断任务类型再决定底层走哪条链路。5.2 我推荐的落地组合打法如果让我设计一个生产环境的方案我会按下面这个三层结构来做底层超长上下文做“工作台”。用户发起复杂任务时允许把一份较大的上下文一次性载入而不是死板地限定在“先检索再拼装”。中间层Agentic检索做“入口路由”。对复杂问题让检索代理自主拆解、多轮召回对简单问题直接走轻量单轮检索控制算力成本。顶层LLM Wiki做“知识沉降”。每次高质量问答完成后把答案中可复用的结论、边界条件、来源链接沉淀回Wiki页面让系统越用越聪明。这套组合里最核心的其实是第3层。因为前两层的收益是一次性的第3层才是复利。我也确实见过一些团队做了不错的RAG系统但因为缺少沉淀层同样的问题隔两个月还会被重新问一遍、重新检索一遍、重新答一遍——等于所有成本都重复支出。5.3 落地前容易踩的坑最后提几点我在实际操作中踩过、或者看别人踩过的坑别迷信“越大越好”的上下文窗口。我自己踩过的一个坑是为了直接用超长上下文省掉检索结果模型常常引用文档中段的不相关内容。后来老老实实加了一层快速检索做粗筛准确率立刻上来了。Agentic检索一定要设停止条件。不加迭代上限的话遇到模糊问题模型会无限子查询延迟和账单都很失控。我的做法是设置最大子查询次数5次以内、总延迟预算60秒超了就兜底返回“检索到部分信息”的降级答案。LLM Wiki的“维护策略”比“建站策略”更重要。页面建出来不难难的是让它不陈旧、不矛盾、不冲突。我建议一开始就设计好“更新触发机制”每次检索命中某个Wiki词条且用户给出了反馈就重新评估该词条是否需要修订。没有这个闭环Wiki会慢慢变成一本过期刊物。评估指标别只盯着命中率。RAG类项目的上线评测除了常规的“回答正确率”至少还得看三个维度引用覆盖率回答内容是否都在引用材料中有支撑、忠实度回答是否忠实于引用内容有没有脑补、检索效率平均每轮提问触发了几次检索、多少成本。我遇到过命中率很高、但忠实度很低的情况——模型把相关片段找对了但答案却Provider了片段里没有的细节这种系统上线非常危险。最后一个我自己的体会逐个分析完这三个方向我最大的感觉是它们不是竞争关系而是分别补上了相同链条的不同缺口。超长上下文补的是“容量”Agentic检索补的是“路径”LLM Wiki补的是“沉淀”。如果把RAG比作一个人的工作方式超长上下文是“让他能一次看很多材料”Agentic检索是“让他会自己查不清楚的线索”LLM Wiki则是“让他把查到的内容写成笔记本下次不用再查一遍”。我现在的个人倾向已经比较明确新项目会默认采用“轻量检索 超长上下文扩展 Wiki沉淀”的组合Agentic检索按需启用。做这个判断不是因为哪个方向更酷而是因为我手里的大部分知识库项目真正的问题不是“单次问答不够准”而是“知识没有积累、重复劳动多”。当然如果你手头的场景是重调研、多跳、长链路分析Agentic检索的优先级应该上调。技术选型从来不是比参数大小而是比和问题的匹配度。如果你也在评估这三个方向我的建议是别听名词先去动手——拿自己的业务问题各跑一轮看哪个方向解决的是你最痛的那个环节。那往往就是你要重点投入的方向。