1. 项目概述当RAG不再是唯一答案最近和几个做AI应用的朋友聊天发现大家一提到“让大模型懂你的私有知识”第一反应就是RAG检索增强生成。这几乎成了行业里的标准答案就像一提到“数据库”就想到MySQL一样。但做项目久了尤其是处理一些复杂、动态或对精度要求极高的场景时你总会发现RAG这套“检索-喂给LLM-生成”的流程有时候会显得有点笨重甚至力不从心。比如你正在构建一个智能客服用户的问题可能涉及公司内部几十份不断更新的政策文档。用RAG你得先切分文档、向量化、建索引用户提问时再检索最相关的几个片段。但如果用户的问题是“对比一下A政策和最新修订的B政策在第三条上的差异”RAG检索出的片段可能只包含了A政策的第三条或者B政策修订前的版本而“最新修订”这个动态信息和“对比”这个复杂推理单纯靠检索几个静态片段很难完美解决。再比如开发一个辅助代码生成的工具需要模型理解整个项目的代码结构、模块间的调用关系这种“图”状的知识用传统的向量相似度检索效果也常常差强人意。这就是我们今天要深入探讨的核心在AI应用开发中除了RAG我们还有哪些技术选择这绝不是要否定RAG它的简单、有效、易于上手使其成为绝大多数场景下的首选。但作为一名开发者我们的工具箱里不能只有一把锤子。了解替代方案能帮助我们在面对特定难题时做出更优的技术选型。本文将结合我过去在复杂知识库、动态数据流和智能体应用中的实战经验为你拆解几种有潜力替代或补充RAG的技术范式包括超长上下文模型、智能体驱动的检索Agentic Retrieval以及新兴的LLM Wiki架构思路。无论你是正在为RAG的精度头疼还是在规划下一代AI应用架构相信这些内容都能给你带来新的启发。2. 核心思路解析为什么我们需要超越RAG在深入具体技术之前我们得先想明白RAG在哪些地方会“卡脖子”。只有诊断清楚痛点才能对症下药找到合适的替代或增强方案。2.1 RAG的经典流程与固有瓶颈标准的RAG流程可以简化为四步文档处理切分、向量化、索引构建、查询检索计算相似度、提示拼接与生成。它的核心优势在于将外部知识库通过“检索”这个动作动态地、按需地注入到大模型的上下文中解决了模型静态知识过时和幻觉问题。然而这套流程隐含着几个关键假设一旦假设不成立瓶颈就出现了“相似即相关”假设RAG严重依赖向量相似度来判定文本片段的相关性。但语义相似不等于逻辑相关。比如“苹果公司发布新手机”和“我今天吃了一个红苹果”向量可能很接近但对于一个商业问答系统后者是完全无关的噪声。更棘手的是多跳推理问题例如“张三的导师的同事发表了哪些论文”需要先检索“张三的导师是谁”再根据结果检索“该导师的同事”最后检索“这些同事的论文”。传统RAG的一次性检索很难串联这个链条。“静态片段”假设RAG处理的知识通常被预切分为固定长度的片段chunks。这破坏了文档的原始结构和连贯性。对于代码、法律条文、技术手册这种结构严谨、上下文依赖强的文本切分可能导致关键信息如函数定义和调用、法条的前后参照被割裂检索到的片段缺乏完整语境。“一次性交互”假设经典的RAG是“一问一答”模式。用户提问系统检索模型生成结束。但在复杂的任务中用户可能需要澄清、模型可能需要追问、或者任务本身需要拆解为多个步骤。这种多轮、主动的交互能力是传统RAG流程所不具备的。“上下文窗口限制”的妥协即使有了128K甚至更长上下文的模型我们依然倾向于使用RAG是因为把大量文档全部塞进上下文成本极高且可能引入无关信息干扰模型。RAG本质上是利用检索在“大海”里捞“针”只把最可能的“针”放入有限的上下文窗口。但如果“捞针”的算法检索器不够精准整个系统的基础就动摇了。2.2 替代技术的核心设计思想基于以上瓶颈新兴的替代或增强技术主要从以下几个思路进行突破思路一绕过检索直接容纳。如果模型的上下文窗口足够长长到能放下整个知识库呢这就是超长上下文模型的思路。它试图从根本上取消“检索”这个中间环节避免检索带来的信息损失和误差。思路二让检索变得更智能。如果检索不是一次性的、基于简单相似度的而是由一个大模型智能体来驱动进行多步、规划式的“思考”后再行动呢这就是智能体驱动检索Agentic Retrieval的核心。它把检索动作本身变成了一个可由LLM规划、决策、执行并迭代的子任务。思路三重构知识表示与访问方式。如果不把知识看成是一堆扁平的文字片段而是将其组织成结构化的、可相互链接的网络就像维基百科让模型学会像人一样在这个网络中“浏览”和“综合”信息呢这就是LLM Wiki这类构想背后的灵感。它改变了知识存储和访问的范式。理解这些不同的设计思想比记住某个框架的名字更重要。接下来我们就逐一拆解这些技术看看它们具体如何工作以及在实际项目中该如何应用和选型。3. 技术方案一超长上下文模型 —— 用“广度”换“精度”当Claude 3支持200K上下文GPT-4 Turbo支持128K国内一些模型也纷纷推出长上下文版本时“把整个知识库丢进提示词”成了一个诱人的想法。这听起来像是“暴力破解”但确实在某些场景下简单有效。3.1 工作原理与适用场景超长上下文模型的技术本质是极大扩展了模型单次处理的信息量上限。你不需要复杂的检索系统只需要做好知识库的预处理和提示词工程。它的工作流程极度简化知识库预处理清洗、格式化你的所有文档将它们拼接成一个连贯的、结构清晰的文本块。这一步的关键在于信息密度和组织逻辑而不是切分。提示词构建创建一个系统提示词明确告诉模型“接下来我将提供完整的知识库请基于此回答用户问题。”然后将拼接好的知识库全文和用户问题一起输入。模型推理模型利用其强大的长上下文理解能力自行在提供的海量文本中定位、提取、综合信息并生成答案。最适合超长上下文的场景通常满足以下特点知识库规模可控总文本量在模型上下文窗口的舒适区内例如预留足够空间给提示词和回答后还能容纳全部知识。通常适用于百万字级别的知识库。查询综合性强用户问题需要横跨多个文档、章节进行综合比对和总结。例如“对比我们公司过去三年所有产品白皮书中提到的安全策略演进”。信息关联度极高知识内部联系紧密任何切分都可能造成严重信息损失。例如一份复杂的软件API文档其中函数A的说明中引用了数据结构B而B的定义又在另一个章节。对延迟要求不苛刻由于输入文本极长模型的推理时间Token生成速度和API成本会显著增加。这适合对实时性要求不高如异步分析报告或成本不敏感的内部场景。注意并非模型宣称支持128K你就能塞满128K且获得好效果。模型对上下文中间部分的信息记忆和理解能力会弱于开头和结尾称为“中间丢失”问题。因此知识库的组织顺序把最重要的内容放在开头和结尾、结构化程度使用清晰的标题、列表、标记至关重要。3.2 实战配置与成本考量假设我们使用一个支持128K上下文的模型API如GPT-4 Turbo 128k来构建一个公司内部规章制度问答系统。步骤1知识库预处理我们不是切分而是“编织”。将所有规章制度文档转换为Markdown格式并按照一个清晰的目录结构进行组织# 公司规章制度全集 ## 一、人力资源制度 ### 1.1 考勤管理办法 正文内容... ### 1.2 薪酬福利体系 正文内容... ## 二、财务管理制度 ### 2.1 费用报销流程 正文内容... ...确保无格式错误章节链接清晰。最终合并的文本大小需控制在90K Token以内为提示词和回答预留空间。步骤2构建系统提示词系统提示词需要精心设计以引导模型高效利用长上下文你是一个专业的公司制度助手。你的知识来源是紧随本提示之后的《公司规章制度全集》完整文本。 请严格根据提供的制度文本来回答用户问题。 回答要求 1. 引用相关制度时请注明出处章节如“根据《1.1考勤管理办法》第三条规定”。 2. 如果问题涉及多个制度请先分别说明再进行综合解释。 3. 如果制度中没有明确规定请如实告知“制度中未找到明确规定”切勿编造。 现在请先阅读并理解接下来的制度全文步骤3调用与评估通过API发送请求输入内容为系统提示词 知识库全文 用户问题。你需要密切关注响应时间首次Token返回时间TTFT和整体生成时间评估用户体验。答案质量是否准确引用了正确章节综合问题的回答是否全面成本计算每次问答的输入Token和输出Token费用。如果知识库80K Token问题0.5K回答2K那么单次成本就是(80.52) * 单价。这对于高频问答场景可能是不可接受的。成本对比示例 假设某云服务上GPT-4 Turbo 128k的输入价格为 $10 / 1M tokens输出价格为 $30 / 1M tokens。RAG方案检索到3个相关片段总计6K Token加上问题提示共7K输入。成本约为0.007 * $10 $0.07。超长上下文方案每次输入整个80K Token知识库。成本约为0.08 * $10 $0.8。单次成本相差10倍以上。如果每天有1000次问答成本差异就是每天730美元 vs 80美元。这还不算更长的响应时间带来的间接成本。因此超长上下文模型是一个“用金钱换简单”的方案。它消除了检索系统开发、维护和调试的复杂性也避免了检索不准确带来的误差但代价是高昂的运营成本和潜在的延迟。它最适合知识库相对稳定、查询频率较低、但对答案完整性和准确性要求极高的“关键任务”型场景。4. 技术方案二智能体驱动检索Agentic Retrieval—— 为检索装上“大脑”如果检索本身是一个复杂任务为什么不交给一个“智能体”来完成呢Agentic Retrieval 不是替换RAG而是将RAG中的“检索器”升级为一个由LLM驱动的、具备规划、执行、反思能力的智能体。这是当前最活跃、也最能解决复杂问题的演进方向。4.1 从工具调用到自主规划传统的RAG中检索是一个被动的、一次性的函数调用。而在Agentic Retrieval范式中LLM成为了检索过程的“指挥官”。其核心思想是让LLM根据问题自主决定是否需要检索可能问题很简单模型自身知识就能回答检索什么关键词或问题原始问题可能模糊需要重写或分解去哪里检索可能有多个知识源向量数据库、传统数据库、搜索引擎、API检索一次够吗检索到的结果是否足够回答是否需要基于当前结果提出新的检索实现多跳检索这个过程通常通过ReActReasoning Acting框架或LangChain的Agent、AutoGen等多智能体框架来实现。一个典型的多跳问答Agentic Retrieval流程思考ReasonLLM分析用户问题“张三的导师的同事发表了哪些论文”并规划步骤“首先我需要找到‘张三’的导师是谁。然后我需要找到该导师的同事列表。最后我需要获取这些同事的论文列表。”行动ActLLM调用“检索工具”输入查询“张三 导师”。观察Observe工具返回结果“张三的导师是李四教授。”再思考ReasonLLM根据观察进行下一步规划“好的现在我需要检索‘李四教授 同事’。”再行动Act调用检索工具输入新查询“李四教授 同事”。再观察Observe工具返回结果“李四教授的同事包括王五、赵六。”最终思考与行动LLM规划“现在我需要分别检索‘王五 论文’和‘赵六 论文’。” 然后执行检索合并结果最终生成答案。可以看到智能体将复杂的检索逻辑内化为了自己的“思考链”而检索工具变成了它听话的“手脚”。这完美解决了传统RAG难以处理的多跳推理问题。4.2 架构设计与关键组件实现构建一个Agentic Retrieval系统你需要以下几个核心组件组件职责实现示例基于LangChain智能体Agent大脑。负责规划、决策、调用工具。使用create_react_agent函数配备一个LLM如ChatOpenAI和一系列工具。工具Tools手脚。执行具体任务如检索、计算、查询API。定义RetrieverTool背后连接你的向量数据库如Chroma、Pinecone。可以定义多个不同来源的工具。记忆Memory短期记忆。存储当前对话和多轮工具调用的历史。使用ConversationBufferWindowMemory让智能体记住之前的交互。执行器Executor运行引擎。驱动智能体循环执行“思考-行动-观察”直到结束。使用AgentExecutor可以设置最大迭代次数以防死循环。一个简化的代码框架示意from langchain.agents import create_react_agent, AgentExecutor from langchain.tools import Tool from langchain_community.vectorstores import Chroma from langchain_openai import ChatOpenAI, OpenAIEmbeddings from langchain.memory import ConversationBufferWindowMemory # 1. 准备检索工具可以是多个 vectorstore Chroma(persist_directory./chroma_db, embedding_functionOpenAIEmbeddings()) retriever vectorstore.as_retriever(search_kwargs{k: 4}) def retrieve_docs(query: str) - str: 一个检索文档的函数 docs retriever.get_relevant_documents(query) return \n\n.join([doc.page_content for doc in docs]) retrieval_tool Tool( nameKnowledgeBase Search, funcretrieve_docs, descriptionUseful for searching company internal knowledge to answer questions. ) # 2. 创建智能体 llm ChatOpenAI(modelgpt-4, temperature0) tools [retrieval_tool] # 可以加入更多工具如计算器、网络搜索工具 prompt ... # ReAct风格的提示词模板 agent create_react_agent(llm, tools, prompt) # 3. 配置记忆和执行器 memory ConversationBufferWindowMemory(k5, memory_keychat_history, return_messagesTrue) agent_executor AgentExecutor(agentagent, toolstools, memorymemory, verboseTrue, max_iterations5) # 4. 运行 result agent_executor.invoke({input: 请对比一下项目A和项目B在风险管理策略上的异同}) print(result[output])在这个例子中智能体可能会先检索“项目A 风险管理策略”再检索“项目B 风险管理策略”然后基于两份材料进行对比总结。整个过程是自动规划的。4.3 避坑指南与效能优化Agentic Retrieval功能强大但引入的复杂性也带来了新的挑战幻觉与循环风险智能体可能“幻想”出一个不存在的工具调用步骤或者陷入“检索-不满意-再检索”的死循环。对策严格限制最大迭代次数max_iterations通常5-10次足够在工具描述中清晰界定其能力和边界在系统提示词中强调“如果信息不足请直接告知用户不要编造”。延迟与成本每一次“思考”和“行动”都是一次LLM API调用。多轮交互意味着数倍于传统RAG的调用次数和延迟。对策优化提示词让智能体的“思考”更简洁高效对于简单问题可以设置一个“短路”逻辑先尝试用一次检索直接回答不行再启动智能体流程考虑使用更快的模型如GPT-3.5 Turbo作为智能体的“大脑”虽然推理能力稍弱但速度更快、成本更低。工具设计的艺术工具不是越多越好。工具功能重叠或描述不清会导致智能体困惑。对策每个工具应有单一、明确的职责和清晰的自然语言描述。例如将“检索员工信息”和“检索项目文档”设计成两个独立的工具比一个通用的“检索”工具更好。评估难度大传统RAG的评估相对直接检索召回率、答案准确性。智能体系统的评估则涉及规划路径的正确性、工具调用的合理性等更复杂。对策建立端到端的测试用例库不仅检查最终答案也记录和分析智能体的决策过程进行人工评估和调优。实操心得不要一开始就追求全自动的复杂智能体。可以从一个最简单的“检索-重写”智能体开始用户提问后智能体先判断是否需要重写查询词例如将口语化问题转为关键词然后用重写后的词进行一次检索。这个小改进往往就能显著提升传统RAG的效果是迈向Agentic Retrieval的稳妥第一步。5. 技术方案三LLM Wiki与结构化知识网络 —— 重新定义“知识库”如果说前两种方案还是在“检索”和“输入”的维度上优化那么LLM Wiki的思路则更加激进——它试图改变知识本身的组织形式。这个概念由一些前沿讨论提出如Karpathy提到的“LLM OS”中的知识层其核心是将知识库构建成一个机器可读且可写、高度结构化、相互链接的网络类似于维基百科但为LLM的访问模式而优化。5.1 理念从文档仓库到知识图谱传统RAG的知识库是一个“文档仓库”文档之间是孤立的。LLM Wiki设想的知识库是一个“知识图谱”或“超文本网络”。节点不再是随机的文本片段而是有明确语义的“知识单元”可以是一段定义、一个事实、一个代码函数说明、一条产品特性。边节点之间通过丰富的链接关系连接如“属于”、“引用”、“相反”、“依赖于”、“是……的实例”。元数据每个节点携带丰富的结构化元数据如创建时间、作者、置信度、来源、类型概念、流程、故障等。当LLM需要回答问题时它不再是进行模糊的向量相似度搜索而是可以执行更精确的“图查询”或“语义导航”。例如对于问题“函数calculate()在哪些模块中被调用”系统可以直接查询以calculate()函数节点为起点的“被调用”关系边快速定位所有调用它的模块节点。5.2 实现路径与当前实践完全实现一个成熟的LLM Wiki是长期愿景但我们可以借鉴其思想对现有RAG系统进行增强增强检索图谱与向量融合这是最实用的落地方式。在构建向量索引的同时利用NLP工具如实体识别、关系抽取从文档中提取实体和关系构建一个轻量级的知识图谱。当用户查询时向量检索快速召回一批相关文本片段。图谱检索识别查询中的实体在图谱中查找其关联实体。结果融合将两种检索方式得到的信息进行融合和重排序作为最终上下文提供给LLM。 例如使用Neo4j图数据库存储实体关系与Chroma向量数据库配合。查询时先在图谱中查找“iPhone 15”的“竞争对手”节点得到“三星Galaxy S24”然后将这两个实体及其相关描述文本作为增强条件送入向量检索能更精准地找到对比性内容。结构化切片与元数据注入改变简单粗暴的按长度切分文档的方式改为按语义边界切分。对于技术文档按“函数”、“类”、“API端点”切分对于法律文档按“法条”、“章节”切分。为每个切片添加丰富的元数据{ id: api_login_function, content: def login(username, password): ..., type: code_function, module: auth, related_entities: [User, Session], links_to: [api_logout_function, api_authenticate_doc] }在检索时不仅可以匹配内容还可以匹配元数据过滤器typecode_function AND moduleauth精度大幅提升。实现“浏览”能力在提示词中不仅提供检索到的片段还提供相关片段的“链接”信息。例如您查询的“用户登录流程”涉及以下部分核心函数login()当前片段相关配置关于SESSION_TIMEOUT的设置请参见片段config_security#L12-L25。错误处理登录失败的常见原因及处理请参见片段error_handling_auth#L5-L40。如果您需要了解以上任何相关部分请告诉我我可以为您获取。 这模拟了人类浏览维基百科时通过超链接跳转获取完整信息的过程。虽然需要多轮交互但能保证信息的完整性和准确性。5.3 挑战与展望构建LLM Wiki面临的主要挑战是构建成本高昂。自动化地从非结构化文本中提取精准的结构化知识实体、关系仍然是一个NLP难题通常需要大量的人工标注或领域特定的规则。对于中小型项目这可能得不偿失。然而在以下场景中投入是值得的领域知识高度结构化如软件SDK文档、药品说明书、金融产品条款本身就有良好的结构。知识关联性极强如学术文献网络、故障诊断知识库症状A可能导致问题B和C。对可解释性要求高需要清晰展示答案的推理路径和来源如图谱查询能直观展示实体关系。个人体会完全不必追求一步到位建成“Wiki”。可以从为你的文档切片添加几个关键的类型标签如概念、操作步骤、参数说明、故障代码开始。在检索时让用户可以通过下拉菜单选择“只搜索操作步骤”或“只搜索故障代码”这已经是一个巨大的体验提升也是迈向结构化知识库的坚实一步。6. 技术选型与融合策略面对这么多选择到底该怎么选没有银弹只有最适合你当前场景的权衡。6.1 决策矩阵对照你的场景做选择你可以根据以下几个维度来评估评估维度传统RAG超长上下文模型智能体驱动检索结构化知识增强实现复杂度低极低仅提示工程高中到高基础设施依赖需要向量数据库仅需大模型API需要智能体框架工具链可能需要图数据库/复杂ETL响应速度快检索快慢输入长推理慢慢多轮LLM调用中等检索图查询单次查询成本低极高高多次调用中等答案质量简单QA良好优秀上下文完整良好良好答案质量复杂推理差中等依赖模型能力优秀良好依赖图谱质量多跳推理能力无有模型自行处理优秀优秀图谱导航知识更新难度中需重建索引中需更新长文本中工具需更新高需更新图谱可解释性中可显示来源片段低黑盒中可展示思考链高可展示关系路径快速决策指南追求简单快捷知识库小10万字预算充足优先考虑超长上下文模型。快糙猛。处理复杂、多步骤的查询任务愿意投入开发成本智能体驱动检索是你的不二之选。知识高度结构化且查询经常涉及实体关系积极探索结构化知识增强图谱向量。以上都不是或者处于项目早期需要快速验证传统RAG依然是可靠、成熟的起点。6.2 混合架构现实世界的最佳实践在实际的大型应用中单一技术栈往往不够。更常见的是一种分层、混合的架构。一个电商客服AI的混合架构示例路由层用户问题进入后先由一个轻量级分类模型或规则引擎进行意图识别。如果是“订单状态查询”、“物流跟踪”需要查询结构化数据库直接路由到API查询工具由智能体调用。如果是“这件衣服的材质是什么”答案在商品详情页路由到传统RAG检索商品描述。如果是“我想买一台适合编程和偶尔玩游戏的笔记本预算8000左右请推荐并对比几款”复杂、多维度、需要推理路由到智能体驱动检索。智能体可能会先检索“编程笔记本推荐”再检索“游戏笔记本推荐”然后调用“比价工具”最后综合生成答案。如果是“把用户手册第三章念给我听”长文档、定位精确且手册不大可以考虑使用超长上下文模型直接获取。知识层底层知识库本身采用混合存储。商品详情、文章等文本存在向量数据库。商品分类、品牌、属性等结构化信息存在图数据库。用户订单、库存等实时数据存在业务数据库。执行层由智能体框架如LangChain Agent统一调度各种工具检索工具、API工具、计算工具。这种架构既保证了简单查询的效率又赋予了系统处理复杂任务的能力同时控制了成本。它要求前端有一个高效的“路由”或“编排”层这是设计中的关键。7. 未来展望与持续学习AI应用开发的技术栈正在飞速演进。RAG作为起点已经为我们打开了连接大模型与私有知识的大门。而超长上下文、智能体、结构化知识这些技术则是在这扇门后的不同路径上继续深挖。可以预见的是未来的趋势不会是某种技术完全取代另一种而是融合与专业化检索将更加智能和多样化融合语义检索、图检索、符号检索的“混合检索”将成为标配。智能体成为标准编程范式用自然语言编排复杂任务流Agentic Workflow会像今天写脚本一样普遍。知识表示标准化可能会出现更适合LLM理解和推理的中间知识表示格式或协议。评估体系完善针对这些复杂系统的评估标准、基准测试和调试工具会逐渐成熟。对于我们开发者而言最重要的不是追逐每一个新名词而是深刻理解这些技术背后的核心思想——如何更高效、更准确、更可控地将领域知识赋能给大模型。保持动手实践从小场景开始尝试这些新技术理解它们的优势和代价从而在你的具体项目中做出最明智的架构选择。技术的终点始终是更好地解决实际问题。当你下次被RAG的局限性困扰时不妨回过头来看看这张技术地图或许就能找到那条通往更优解的路径。 超越RAG：AI应用开发中的知识增强技术选型与实战
1. 项目概述当RAG不再是唯一答案最近和几个做AI应用的朋友聊天发现大家一提到“让大模型懂你的私有知识”第一反应就是RAG检索增强生成。这几乎成了行业里的标准答案就像一提到“数据库”就想到MySQL一样。但做项目久了尤其是处理一些复杂、动态或对精度要求极高的场景时你总会发现RAG这套“检索-喂给LLM-生成”的流程有时候会显得有点笨重甚至力不从心。比如你正在构建一个智能客服用户的问题可能涉及公司内部几十份不断更新的政策文档。用RAG你得先切分文档、向量化、建索引用户提问时再检索最相关的几个片段。但如果用户的问题是“对比一下A政策和最新修订的B政策在第三条上的差异”RAG检索出的片段可能只包含了A政策的第三条或者B政策修订前的版本而“最新修订”这个动态信息和“对比”这个复杂推理单纯靠检索几个静态片段很难完美解决。再比如开发一个辅助代码生成的工具需要模型理解整个项目的代码结构、模块间的调用关系这种“图”状的知识用传统的向量相似度检索效果也常常差强人意。这就是我们今天要深入探讨的核心在AI应用开发中除了RAG我们还有哪些技术选择这绝不是要否定RAG它的简单、有效、易于上手使其成为绝大多数场景下的首选。但作为一名开发者我们的工具箱里不能只有一把锤子。了解替代方案能帮助我们在面对特定难题时做出更优的技术选型。本文将结合我过去在复杂知识库、动态数据流和智能体应用中的实战经验为你拆解几种有潜力替代或补充RAG的技术范式包括超长上下文模型、智能体驱动的检索Agentic Retrieval以及新兴的LLM Wiki架构思路。无论你是正在为RAG的精度头疼还是在规划下一代AI应用架构相信这些内容都能给你带来新的启发。2. 核心思路解析为什么我们需要超越RAG在深入具体技术之前我们得先想明白RAG在哪些地方会“卡脖子”。只有诊断清楚痛点才能对症下药找到合适的替代或增强方案。2.1 RAG的经典流程与固有瓶颈标准的RAG流程可以简化为四步文档处理切分、向量化、索引构建、查询检索计算相似度、提示拼接与生成。它的核心优势在于将外部知识库通过“检索”这个动作动态地、按需地注入到大模型的上下文中解决了模型静态知识过时和幻觉问题。然而这套流程隐含着几个关键假设一旦假设不成立瓶颈就出现了“相似即相关”假设RAG严重依赖向量相似度来判定文本片段的相关性。但语义相似不等于逻辑相关。比如“苹果公司发布新手机”和“我今天吃了一个红苹果”向量可能很接近但对于一个商业问答系统后者是完全无关的噪声。更棘手的是多跳推理问题例如“张三的导师的同事发表了哪些论文”需要先检索“张三的导师是谁”再根据结果检索“该导师的同事”最后检索“这些同事的论文”。传统RAG的一次性检索很难串联这个链条。“静态片段”假设RAG处理的知识通常被预切分为固定长度的片段chunks。这破坏了文档的原始结构和连贯性。对于代码、法律条文、技术手册这种结构严谨、上下文依赖强的文本切分可能导致关键信息如函数定义和调用、法条的前后参照被割裂检索到的片段缺乏完整语境。“一次性交互”假设经典的RAG是“一问一答”模式。用户提问系统检索模型生成结束。但在复杂的任务中用户可能需要澄清、模型可能需要追问、或者任务本身需要拆解为多个步骤。这种多轮、主动的交互能力是传统RAG流程所不具备的。“上下文窗口限制”的妥协即使有了128K甚至更长上下文的模型我们依然倾向于使用RAG是因为把大量文档全部塞进上下文成本极高且可能引入无关信息干扰模型。RAG本质上是利用检索在“大海”里捞“针”只把最可能的“针”放入有限的上下文窗口。但如果“捞针”的算法检索器不够精准整个系统的基础就动摇了。2.2 替代技术的核心设计思想基于以上瓶颈新兴的替代或增强技术主要从以下几个思路进行突破思路一绕过检索直接容纳。如果模型的上下文窗口足够长长到能放下整个知识库呢这就是超长上下文模型的思路。它试图从根本上取消“检索”这个中间环节避免检索带来的信息损失和误差。思路二让检索变得更智能。如果检索不是一次性的、基于简单相似度的而是由一个大模型智能体来驱动进行多步、规划式的“思考”后再行动呢这就是智能体驱动检索Agentic Retrieval的核心。它把检索动作本身变成了一个可由LLM规划、决策、执行并迭代的子任务。思路三重构知识表示与访问方式。如果不把知识看成是一堆扁平的文字片段而是将其组织成结构化的、可相互链接的网络就像维基百科让模型学会像人一样在这个网络中“浏览”和“综合”信息呢这就是LLM Wiki这类构想背后的灵感。它改变了知识存储和访问的范式。理解这些不同的设计思想比记住某个框架的名字更重要。接下来我们就逐一拆解这些技术看看它们具体如何工作以及在实际项目中该如何应用和选型。3. 技术方案一超长上下文模型 —— 用“广度”换“精度”当Claude 3支持200K上下文GPT-4 Turbo支持128K国内一些模型也纷纷推出长上下文版本时“把整个知识库丢进提示词”成了一个诱人的想法。这听起来像是“暴力破解”但确实在某些场景下简单有效。3.1 工作原理与适用场景超长上下文模型的技术本质是极大扩展了模型单次处理的信息量上限。你不需要复杂的检索系统只需要做好知识库的预处理和提示词工程。它的工作流程极度简化知识库预处理清洗、格式化你的所有文档将它们拼接成一个连贯的、结构清晰的文本块。这一步的关键在于信息密度和组织逻辑而不是切分。提示词构建创建一个系统提示词明确告诉模型“接下来我将提供完整的知识库请基于此回答用户问题。”然后将拼接好的知识库全文和用户问题一起输入。模型推理模型利用其强大的长上下文理解能力自行在提供的海量文本中定位、提取、综合信息并生成答案。最适合超长上下文的场景通常满足以下特点知识库规模可控总文本量在模型上下文窗口的舒适区内例如预留足够空间给提示词和回答后还能容纳全部知识。通常适用于百万字级别的知识库。查询综合性强用户问题需要横跨多个文档、章节进行综合比对和总结。例如“对比我们公司过去三年所有产品白皮书中提到的安全策略演进”。信息关联度极高知识内部联系紧密任何切分都可能造成严重信息损失。例如一份复杂的软件API文档其中函数A的说明中引用了数据结构B而B的定义又在另一个章节。对延迟要求不苛刻由于输入文本极长模型的推理时间Token生成速度和API成本会显著增加。这适合对实时性要求不高如异步分析报告或成本不敏感的内部场景。注意并非模型宣称支持128K你就能塞满128K且获得好效果。模型对上下文中间部分的信息记忆和理解能力会弱于开头和结尾称为“中间丢失”问题。因此知识库的组织顺序把最重要的内容放在开头和结尾、结构化程度使用清晰的标题、列表、标记至关重要。3.2 实战配置与成本考量假设我们使用一个支持128K上下文的模型API如GPT-4 Turbo 128k来构建一个公司内部规章制度问答系统。步骤1知识库预处理我们不是切分而是“编织”。将所有规章制度文档转换为Markdown格式并按照一个清晰的目录结构进行组织# 公司规章制度全集 ## 一、人力资源制度 ### 1.1 考勤管理办法 正文内容... ### 1.2 薪酬福利体系 正文内容... ## 二、财务管理制度 ### 2.1 费用报销流程 正文内容... ...确保无格式错误章节链接清晰。最终合并的文本大小需控制在90K Token以内为提示词和回答预留空间。步骤2构建系统提示词系统提示词需要精心设计以引导模型高效利用长上下文你是一个专业的公司制度助手。你的知识来源是紧随本提示之后的《公司规章制度全集》完整文本。 请严格根据提供的制度文本来回答用户问题。 回答要求 1. 引用相关制度时请注明出处章节如“根据《1.1考勤管理办法》第三条规定”。 2. 如果问题涉及多个制度请先分别说明再进行综合解释。 3. 如果制度中没有明确规定请如实告知“制度中未找到明确规定”切勿编造。 现在请先阅读并理解接下来的制度全文步骤3调用与评估通过API发送请求输入内容为系统提示词 知识库全文 用户问题。你需要密切关注响应时间首次Token返回时间TTFT和整体生成时间评估用户体验。答案质量是否准确引用了正确章节综合问题的回答是否全面成本计算每次问答的输入Token和输出Token费用。如果知识库80K Token问题0.5K回答2K那么单次成本就是(80.52) * 单价。这对于高频问答场景可能是不可接受的。成本对比示例 假设某云服务上GPT-4 Turbo 128k的输入价格为 $10 / 1M tokens输出价格为 $30 / 1M tokens。RAG方案检索到3个相关片段总计6K Token加上问题提示共7K输入。成本约为0.007 * $10 $0.07。超长上下文方案每次输入整个80K Token知识库。成本约为0.08 * $10 $0.8。单次成本相差10倍以上。如果每天有1000次问答成本差异就是每天730美元 vs 80美元。这还不算更长的响应时间带来的间接成本。因此超长上下文模型是一个“用金钱换简单”的方案。它消除了检索系统开发、维护和调试的复杂性也避免了检索不准确带来的误差但代价是高昂的运营成本和潜在的延迟。它最适合知识库相对稳定、查询频率较低、但对答案完整性和准确性要求极高的“关键任务”型场景。4. 技术方案二智能体驱动检索Agentic Retrieval—— 为检索装上“大脑”如果检索本身是一个复杂任务为什么不交给一个“智能体”来完成呢Agentic Retrieval 不是替换RAG而是将RAG中的“检索器”升级为一个由LLM驱动的、具备规划、执行、反思能力的智能体。这是当前最活跃、也最能解决复杂问题的演进方向。4.1 从工具调用到自主规划传统的RAG中检索是一个被动的、一次性的函数调用。而在Agentic Retrieval范式中LLM成为了检索过程的“指挥官”。其核心思想是让LLM根据问题自主决定是否需要检索可能问题很简单模型自身知识就能回答检索什么关键词或问题原始问题可能模糊需要重写或分解去哪里检索可能有多个知识源向量数据库、传统数据库、搜索引擎、API检索一次够吗检索到的结果是否足够回答是否需要基于当前结果提出新的检索实现多跳检索这个过程通常通过ReActReasoning Acting框架或LangChain的Agent、AutoGen等多智能体框架来实现。一个典型的多跳问答Agentic Retrieval流程思考ReasonLLM分析用户问题“张三的导师的同事发表了哪些论文”并规划步骤“首先我需要找到‘张三’的导师是谁。然后我需要找到该导师的同事列表。最后我需要获取这些同事的论文列表。”行动ActLLM调用“检索工具”输入查询“张三 导师”。观察Observe工具返回结果“张三的导师是李四教授。”再思考ReasonLLM根据观察进行下一步规划“好的现在我需要检索‘李四教授 同事’。”再行动Act调用检索工具输入新查询“李四教授 同事”。再观察Observe工具返回结果“李四教授的同事包括王五、赵六。”最终思考与行动LLM规划“现在我需要分别检索‘王五 论文’和‘赵六 论文’。” 然后执行检索合并结果最终生成答案。可以看到智能体将复杂的检索逻辑内化为了自己的“思考链”而检索工具变成了它听话的“手脚”。这完美解决了传统RAG难以处理的多跳推理问题。4.2 架构设计与关键组件实现构建一个Agentic Retrieval系统你需要以下几个核心组件组件职责实现示例基于LangChain智能体Agent大脑。负责规划、决策、调用工具。使用create_react_agent函数配备一个LLM如ChatOpenAI和一系列工具。工具Tools手脚。执行具体任务如检索、计算、查询API。定义RetrieverTool背后连接你的向量数据库如Chroma、Pinecone。可以定义多个不同来源的工具。记忆Memory短期记忆。存储当前对话和多轮工具调用的历史。使用ConversationBufferWindowMemory让智能体记住之前的交互。执行器Executor运行引擎。驱动智能体循环执行“思考-行动-观察”直到结束。使用AgentExecutor可以设置最大迭代次数以防死循环。一个简化的代码框架示意from langchain.agents import create_react_agent, AgentExecutor from langchain.tools import Tool from langchain_community.vectorstores import Chroma from langchain_openai import ChatOpenAI, OpenAIEmbeddings from langchain.memory import ConversationBufferWindowMemory # 1. 准备检索工具可以是多个 vectorstore Chroma(persist_directory./chroma_db, embedding_functionOpenAIEmbeddings()) retriever vectorstore.as_retriever(search_kwargs{k: 4}) def retrieve_docs(query: str) - str: 一个检索文档的函数 docs retriever.get_relevant_documents(query) return \n\n.join([doc.page_content for doc in docs]) retrieval_tool Tool( nameKnowledgeBase Search, funcretrieve_docs, descriptionUseful for searching company internal knowledge to answer questions. ) # 2. 创建智能体 llm ChatOpenAI(modelgpt-4, temperature0) tools [retrieval_tool] # 可以加入更多工具如计算器、网络搜索工具 prompt ... # ReAct风格的提示词模板 agent create_react_agent(llm, tools, prompt) # 3. 配置记忆和执行器 memory ConversationBufferWindowMemory(k5, memory_keychat_history, return_messagesTrue) agent_executor AgentExecutor(agentagent, toolstools, memorymemory, verboseTrue, max_iterations5) # 4. 运行 result agent_executor.invoke({input: 请对比一下项目A和项目B在风险管理策略上的异同}) print(result[output])在这个例子中智能体可能会先检索“项目A 风险管理策略”再检索“项目B 风险管理策略”然后基于两份材料进行对比总结。整个过程是自动规划的。4.3 避坑指南与效能优化Agentic Retrieval功能强大但引入的复杂性也带来了新的挑战幻觉与循环风险智能体可能“幻想”出一个不存在的工具调用步骤或者陷入“检索-不满意-再检索”的死循环。对策严格限制最大迭代次数max_iterations通常5-10次足够在工具描述中清晰界定其能力和边界在系统提示词中强调“如果信息不足请直接告知用户不要编造”。延迟与成本每一次“思考”和“行动”都是一次LLM API调用。多轮交互意味着数倍于传统RAG的调用次数和延迟。对策优化提示词让智能体的“思考”更简洁高效对于简单问题可以设置一个“短路”逻辑先尝试用一次检索直接回答不行再启动智能体流程考虑使用更快的模型如GPT-3.5 Turbo作为智能体的“大脑”虽然推理能力稍弱但速度更快、成本更低。工具设计的艺术工具不是越多越好。工具功能重叠或描述不清会导致智能体困惑。对策每个工具应有单一、明确的职责和清晰的自然语言描述。例如将“检索员工信息”和“检索项目文档”设计成两个独立的工具比一个通用的“检索”工具更好。评估难度大传统RAG的评估相对直接检索召回率、答案准确性。智能体系统的评估则涉及规划路径的正确性、工具调用的合理性等更复杂。对策建立端到端的测试用例库不仅检查最终答案也记录和分析智能体的决策过程进行人工评估和调优。实操心得不要一开始就追求全自动的复杂智能体。可以从一个最简单的“检索-重写”智能体开始用户提问后智能体先判断是否需要重写查询词例如将口语化问题转为关键词然后用重写后的词进行一次检索。这个小改进往往就能显著提升传统RAG的效果是迈向Agentic Retrieval的稳妥第一步。5. 技术方案三LLM Wiki与结构化知识网络 —— 重新定义“知识库”如果说前两种方案还是在“检索”和“输入”的维度上优化那么LLM Wiki的思路则更加激进——它试图改变知识本身的组织形式。这个概念由一些前沿讨论提出如Karpathy提到的“LLM OS”中的知识层其核心是将知识库构建成一个机器可读且可写、高度结构化、相互链接的网络类似于维基百科但为LLM的访问模式而优化。5.1 理念从文档仓库到知识图谱传统RAG的知识库是一个“文档仓库”文档之间是孤立的。LLM Wiki设想的知识库是一个“知识图谱”或“超文本网络”。节点不再是随机的文本片段而是有明确语义的“知识单元”可以是一段定义、一个事实、一个代码函数说明、一条产品特性。边节点之间通过丰富的链接关系连接如“属于”、“引用”、“相反”、“依赖于”、“是……的实例”。元数据每个节点携带丰富的结构化元数据如创建时间、作者、置信度、来源、类型概念、流程、故障等。当LLM需要回答问题时它不再是进行模糊的向量相似度搜索而是可以执行更精确的“图查询”或“语义导航”。例如对于问题“函数calculate()在哪些模块中被调用”系统可以直接查询以calculate()函数节点为起点的“被调用”关系边快速定位所有调用它的模块节点。5.2 实现路径与当前实践完全实现一个成熟的LLM Wiki是长期愿景但我们可以借鉴其思想对现有RAG系统进行增强增强检索图谱与向量融合这是最实用的落地方式。在构建向量索引的同时利用NLP工具如实体识别、关系抽取从文档中提取实体和关系构建一个轻量级的知识图谱。当用户查询时向量检索快速召回一批相关文本片段。图谱检索识别查询中的实体在图谱中查找其关联实体。结果融合将两种检索方式得到的信息进行融合和重排序作为最终上下文提供给LLM。 例如使用Neo4j图数据库存储实体关系与Chroma向量数据库配合。查询时先在图谱中查找“iPhone 15”的“竞争对手”节点得到“三星Galaxy S24”然后将这两个实体及其相关描述文本作为增强条件送入向量检索能更精准地找到对比性内容。结构化切片与元数据注入改变简单粗暴的按长度切分文档的方式改为按语义边界切分。对于技术文档按“函数”、“类”、“API端点”切分对于法律文档按“法条”、“章节”切分。为每个切片添加丰富的元数据{ id: api_login_function, content: def login(username, password): ..., type: code_function, module: auth, related_entities: [User, Session], links_to: [api_logout_function, api_authenticate_doc] }在检索时不仅可以匹配内容还可以匹配元数据过滤器typecode_function AND moduleauth精度大幅提升。实现“浏览”能力在提示词中不仅提供检索到的片段还提供相关片段的“链接”信息。例如您查询的“用户登录流程”涉及以下部分核心函数login()当前片段相关配置关于SESSION_TIMEOUT的设置请参见片段config_security#L12-L25。错误处理登录失败的常见原因及处理请参见片段error_handling_auth#L5-L40。如果您需要了解以上任何相关部分请告诉我我可以为您获取。 这模拟了人类浏览维基百科时通过超链接跳转获取完整信息的过程。虽然需要多轮交互但能保证信息的完整性和准确性。5.3 挑战与展望构建LLM Wiki面临的主要挑战是构建成本高昂。自动化地从非结构化文本中提取精准的结构化知识实体、关系仍然是一个NLP难题通常需要大量的人工标注或领域特定的规则。对于中小型项目这可能得不偿失。然而在以下场景中投入是值得的领域知识高度结构化如软件SDK文档、药品说明书、金融产品条款本身就有良好的结构。知识关联性极强如学术文献网络、故障诊断知识库症状A可能导致问题B和C。对可解释性要求高需要清晰展示答案的推理路径和来源如图谱查询能直观展示实体关系。个人体会完全不必追求一步到位建成“Wiki”。可以从为你的文档切片添加几个关键的类型标签如概念、操作步骤、参数说明、故障代码开始。在检索时让用户可以通过下拉菜单选择“只搜索操作步骤”或“只搜索故障代码”这已经是一个巨大的体验提升也是迈向结构化知识库的坚实一步。6. 技术选型与融合策略面对这么多选择到底该怎么选没有银弹只有最适合你当前场景的权衡。6.1 决策矩阵对照你的场景做选择你可以根据以下几个维度来评估评估维度传统RAG超长上下文模型智能体驱动检索结构化知识增强实现复杂度低极低仅提示工程高中到高基础设施依赖需要向量数据库仅需大模型API需要智能体框架工具链可能需要图数据库/复杂ETL响应速度快检索快慢输入长推理慢慢多轮LLM调用中等检索图查询单次查询成本低极高高多次调用中等答案质量简单QA良好优秀上下文完整良好良好答案质量复杂推理差中等依赖模型能力优秀良好依赖图谱质量多跳推理能力无有模型自行处理优秀优秀图谱导航知识更新难度中需重建索引中需更新长文本中工具需更新高需更新图谱可解释性中可显示来源片段低黑盒中可展示思考链高可展示关系路径快速决策指南追求简单快捷知识库小10万字预算充足优先考虑超长上下文模型。快糙猛。处理复杂、多步骤的查询任务愿意投入开发成本智能体驱动检索是你的不二之选。知识高度结构化且查询经常涉及实体关系积极探索结构化知识增强图谱向量。以上都不是或者处于项目早期需要快速验证传统RAG依然是可靠、成熟的起点。6.2 混合架构现实世界的最佳实践在实际的大型应用中单一技术栈往往不够。更常见的是一种分层、混合的架构。一个电商客服AI的混合架构示例路由层用户问题进入后先由一个轻量级分类模型或规则引擎进行意图识别。如果是“订单状态查询”、“物流跟踪”需要查询结构化数据库直接路由到API查询工具由智能体调用。如果是“这件衣服的材质是什么”答案在商品详情页路由到传统RAG检索商品描述。如果是“我想买一台适合编程和偶尔玩游戏的笔记本预算8000左右请推荐并对比几款”复杂、多维度、需要推理路由到智能体驱动检索。智能体可能会先检索“编程笔记本推荐”再检索“游戏笔记本推荐”然后调用“比价工具”最后综合生成答案。如果是“把用户手册第三章念给我听”长文档、定位精确且手册不大可以考虑使用超长上下文模型直接获取。知识层底层知识库本身采用混合存储。商品详情、文章等文本存在向量数据库。商品分类、品牌、属性等结构化信息存在图数据库。用户订单、库存等实时数据存在业务数据库。执行层由智能体框架如LangChain Agent统一调度各种工具检索工具、API工具、计算工具。这种架构既保证了简单查询的效率又赋予了系统处理复杂任务的能力同时控制了成本。它要求前端有一个高效的“路由”或“编排”层这是设计中的关键。7. 未来展望与持续学习AI应用开发的技术栈正在飞速演进。RAG作为起点已经为我们打开了连接大模型与私有知识的大门。而超长上下文、智能体、结构化知识这些技术则是在这扇门后的不同路径上继续深挖。可以预见的是未来的趋势不会是某种技术完全取代另一种而是融合与专业化检索将更加智能和多样化融合语义检索、图检索、符号检索的“混合检索”将成为标配。智能体成为标准编程范式用自然语言编排复杂任务流Agentic Workflow会像今天写脚本一样普遍。知识表示标准化可能会出现更适合LLM理解和推理的中间知识表示格式或协议。评估体系完善针对这些复杂系统的评估标准、基准测试和调试工具会逐渐成熟。对于我们开发者而言最重要的不是追逐每一个新名词而是深刻理解这些技术背后的核心思想——如何更高效、更准确、更可控地将领域知识赋能给大模型。保持动手实践从小场景开始尝试这些新技术理解它们的优势和代价从而在你的具体项目中做出最明智的架构选择。技术的终点始终是更好地解决实际问题。当你下次被RAG的局限性困扰时不妨回过头来看看这张技术地图或许就能找到那条通往更优解的路径。