长上下文下RAG与Agent落地教程

简介：本文面向开发者与架构师，讲解在长上下文模型普及后，如何判断RAG与Agent是否必需，并落地检索、压缩、读取的混合架构。读者将掌握知识切分、混合检索、上下文装配、权限过滤、评测验证与排查思路，构建更准确、可控、低成本的企业级智能问答系统。

一、教程目标

本教程围绕“RAG对Agent是不是必须”这一问题展开，但重点不是给出一个简单的“是”或“否”，而是帮助读者完成一套可落地的技术判断与工程实现路径。最终目标包括三点：

判断业务场景是否必须引入RAG。
掌握“检索—压缩—读取”的混合架构设计方法。
能够完成基础实施、验证、排查与优化。

适合阅读的人群包括后端开发者、AI应用工程师、平台架构师、运维负责人以及需要评估企业知识库方案的技术管理者。

二、核心结论：长上下文不会替代RAG，但会改变RAG的角色

随着大模型上下文窗口扩展到数十万甚至百万级，很多团队会产生疑问：既然可以直接把大量文档放进上下文，是否还需要检索？

结论并不绝对。

如果Agent只是完成实时查询、规则判断、工具调用或简单问答，未必必须依赖RAG。例如查询订单状态、调用内部接口、执行固定流程、根据明确参数生成结果，这类任务更依赖工具调用和结构化数据访问，而不是静态知识检索。

但如果Agent需要基于企业内部文档、制度、产品手册、代码说明、运维记录等私域知识进行准确回答，RAG通常仍然必要。原因不是“放不下”，而是以下四个工程问题无法仅靠长上下文解决：

找得准：长上下文里塞入大量内容，不等于模型能准确定位关键证据。
控得住：企业场景需要权限过滤、版本管理、审计追溯，不能把全部内容无差别送入模型。
省得下：上下文越长，推理成本、延迟和存储成本越高。
可解释：RAG可以给出引用来源，便于验证答案依据，降低幻觉风险。

因此，更合理的判断是：长上下文不会消灭RAG，而是要求RAG从“简单召回”升级为“精准检索、压缩与组织”。

三、适用场景

本教程适合以下场景：

企业知识库问答：员工查询制度、流程、产品文档、技术手册。
客服与售后助手：基于历史工单、FAQ、售后政策回答问题。
研发辅助：基于代码仓库、接口文档、架构说明进行检索增强。
运维助手：结合故障记录、值班手册、变更记录提供排查建议。
合规审计场景：需要引用原文、保留版本、追踪权限。
多轮Agent系统：需要记忆、工具调用、知识检索混合使用。

不适合直接套用本教程的场景包括：纯结构化数据库查询、强实时交易处理、完全依赖外部接口返回数据的任务，以及答案规则完全确定、无需私域知识的简单问答。

四、前置准备

在实施前，建议先准备以下内容：

明确知识源

梳理需要接入的文档类型，例如制度文件、产品手册、FAQ、工单、日志说明、接口文档等。需要记录每种文档的格式、更新频率、责任部门和权限级别。

明确权限模型

企业知识库不能只考虑“能不能检索到”，还要考虑“当前用户是否有权查看”。常见权限维度包括：用户身份、部门、角色、项目空间、文档密级、有效时间范围。

准备评测集

评测集是判断方案是否有效的关键。建议每个高频问题准备标准答案、参考文档和评分规则。评测集应覆盖：

简单事实查询。
多文档对比。
长尾问题。
权限边界问题。
无答案问题。
需要引用原文的问题。

准备基础组件

从通用架构看，通常需要对象存储、消息队列、日志服务、监控告警、数据库、身份认证、容器平台等基础能力。这里不绑定具体产品，只描述能力类别。

定义质量目标

建议从五个维度定义目标：回答准确率、引用正确率、召回率、平均延迟、单次问答成本。目标越明确，后续优化越容易。

五、实施步骤

步骤一：判断是否需要RAG

首先不要急着搭向量库，而是判断任务类型。

可以用以下规则做初步判断：

场景一：不需要RAG

答案来自实时接口。
答案来自结构化数据库。
任务规则明确，可由Agent直接调用工具完成。
知识量很小，可直接写进提示词。
对引用、审计、权限要求不高。

场景二：需要RAG

知识来自大量私域文档。
文档更新频繁。
需要引用原文。
需要按权限过滤。
用户问题表达多样，无法直接映射为数据库查询。
需要减少幻觉，提升可信度。

如果多个条件同时命中，通常建议采用RAG，或至少采用轻量检索增强。

步骤二：建设知识治理流程

知识质量决定检索上限。若文档本身混乱，再好的检索也难以稳定。

需要完成：

去重：移除重复文档、历史版本、无效附件。
清洗：去除页眉页脚、无意义空白、乱码、重复导航。
版本标记：为每篇文档增加版本号、更新时间、生效状态。
结构保留：尽量保留标题层级、列表、表格、代码块、章节号。
权限标签：为文档设置可见范围。
元数据设计：至少包括文档ID、标题、章节、来源、更新时间、权限标签。

注意：不要把整篇超大文档简单压缩成一个块。过度压缩会丢失关键上下文，影响后续检索精度。

步骤三：设计文档切分策略

切分是RAG质量的第一道关口。

常见原则是：块不能太大，否则噪声多；块也不能太小，否则语义不完整。

建议按结构切分，而不是只按固定长度切分。例如：

优先按标题层级切分。
每个块保留所在章节标题。
表格尽量保持完整。
代码示例尽量与说明文字绑定。
长段落可二次切分。
短段落不要过度合并。

通用经验值可以参考：

每个文本块长度可控制在数百字到一千字左右。
相邻块可设置少量重叠，用于保留上下文连续性。
对表格、代码、配置文件等特殊内容，建议单独建立解析规则。

配置风险：块过大时，检索结果容易混入无关内容；块过小时，可能丢失关键上下文；重叠过大时，索引冗余和成本会上升。

步骤四：建立向量索引与关键词索引

企业知识库中，单一向量检索往往不够。向量检索擅长语义相似，但对专有名词、编号、缩写、错误码、产品型号等精确匹配可能不稳定。因此建议采用混合检索。

混合检索通常由两部分组成：

向量检索：根据语义相似度召回候选内容。
关键词检索：根据词项、短语、精确匹配召回候选内容。

索引构建流程可以概括为：

文档解析 → 清洗 → 切分 → 生成元数据 → 生成向量表示 → 写入向量索引 → 写入关键词索引 → 建立版本映射。

注意：向量化不是目的，可召回、可解释、可过滤才是目的。因此每个文本块都应带有元数据，用于后续权限过滤和引用展示。

步骤五：设计查询改写与意图路由

用户问题往往不完整、不清晰，甚至包含口语表达。直接检索可能效果不稳定。

建议增加查询处理层：

查询改写：把用户问题改写成更适合检索的表达。
术语归一化：统一产品名、系统名、缩写。
意图识别：判断是知识问答、工具调用，还是闲聊。
路由选择：决定进入RAG检索、数据库查询、接口调用或直接回答。

Agent在这里的作用不是“无限生成”，而是决定调用哪种能力。

步骤六：执行多路召回与重排

召回阶段不要只追求数量，而要追求候选集质量。

推荐流程：

向量检索召回若干候选。
关键词检索召回若干候选。
合并候选并按文档ID、块ID去重。
根据权限标签过滤无权限内容。
使用重排模型或规则进行二次排序。
保留最相关的若干块进入压缩阶段。

配置说明：

召回数量不宜过小，否则容易漏掉正确答案。
召回数量也不宜过大，否则增加重排和压缩成本。
权限过滤应在召回前或召回后立即执行，避免无权限内容进入上下文。
对高敏感场景，建议采用硬过滤，而不是只靠提示词约束。

步骤七：压缩并组织上下文

长上下文的价值在于模型可以看到更多信息，但模型并不擅长从大量无关内容中稳定找关键信息。因此，在把内容交给模型前，需要压缩和组织。

压缩方式包括：

去重：移除重复段落。
截断：删除低相关段落。
摘要：对多个相关块生成短摘要。
结构化：保留标题、章节、引用编号。
分层：先给概览，再给细节。
预算控制：根据模型上下文限制设置最大输入长度。

上下文组织建议：

将最相关证据放在靠前或靠后的位置，降低中间信息被忽略的风险。
为每个证据添加来源编号。
明确告诉模型只能依据给定材料回答。
对无答案情况设置兜底策略。
避免把权限、版本、时间等元数据直接混在正文里，应结构化标注。

步骤八：设计Agent编排逻辑

Agent不是简单包一层提示词，而是需要明确角色、工具、记忆和安全边界。

一个通用Agent流程可以包括：

接收用户问题。
进行身份与权限校验。
判断是否需要检索知识。
如需要，执行查询改写。
执行多路检索。
执行重排与压缩。
组织证据并调用生成模型。
生成引用。
记录日志。
返回答案或进一步澄清问题。

伪代码示例：

function handle_request(user_id, query):
    trace_id = create_trace_id()
    permission = check_permission(user_id, query)
    intent = classify_intent(query)
    if intent == "tool_call":
        return call_tool(query, permission)
    if intent == "chitchat":
        return generate_simple_answer(query)
    if intent == "knowledge_qa":
        rewritten_query = rewrite_query(query)
        candidates = hybrid_search(rewritten_query, filters=permission)
        filtered = filter_by_permission(candidates, permission)
        reranked = rerank(rewritten_query, filtered)
        context = compress_to_budget(reranked, max_tokens=budget)
        answer = generate_answer(query, context)
        log(trace_id, query, context, answer)
        return answer
    return clarify_or_fallback(query)

该伪代码只描述通用逻辑，不绑定任何具体产品或接口。

步骤九：权限过滤与合规控制

企业场景下，权限不是附加项，而是基础项。

建议：

身份认证前置：未认证用户不得进入知识检索。
权限标签随文档块写入索引。
检索时按用户身份过滤。
对敏感字段进行脱敏。
对生成结果进行引用校验。
对审计日志保留查询语句、召回结果、使用版本、回答内容。
对过期文档设置失效策略。

特别注意：不能只在生成阶段用提示词要求模型“不要回答无权限内容”。提示词不能替代权限控制。正确做法是在检索层完成硬过滤。

步骤十：结果验证

验证应分为离线评测和在线验证。

离线评测指标：

召回率：正确文档是否进入候选集。
精确率：进入上下文的块是否真正相关。
引用正确率：回答引用是否来自给定材料。
答案正确率：人工评分或规则评分。
无答案识别率：对不知道的问题是否能拒答。
权限正确率：无权限内容是否被过滤。

在线验证方式：

小流量灰度发布。
对比新旧策略的答案质量。
收集用户反馈。
记录失败案例。
监控延迟和成本变化。
对高频问题做专项优化。

六、配置说明

以下是通用配置项及其含义，不涉及具体产品参数。

chunk_size

表示文本块长度。较大块保留更多上下文，但噪声可能增加；较小块更精准，但可能破坏语义完整。

overlap

表示相邻块之间的重叠长度。适度重叠有助于保留跨段信息，但会增加冗余。

top_k

表示每路检索返回的候选数量。数量太小容易漏召回，数量太大增加后续处理成本。

rerank_top_n

表示重排后保留的候选数量。该值决定最终进入压缩阶段的材料数量。

max_context_tokens

表示可送入模型的最大上下文长度。应结合模型能力、成本预算和延迟目标设置。

min_relevance_score

表示最低相关度阈值。低于阈值的内容可以不进入生成阶段，以减少噪声。

cache_ttl

表示缓存有效期。适用于高频问题、热门文档或稳定答案场景。

permission_filter

表示权限过滤策略。建议在索引查询阶段强制执行。

配置建议：

开发环境可以优先追求召回覆盖，方便发现问题。
生产环境需要平衡召回、延迟、成本和权限。
对高准确场景，可提高重排数量并加强引用校验。
对低成本场景，可启用缓存和摘要压缩。
对强合规场景，应优先保证权限过滤和审计完整。

七、常见问题与排查

问题一：回答答非所问

可能原因：

查询改写不到位。
检索召回不足。
切分块语义不完整。
向量索引质量差。
关键词与用户表达差异大。

排查思路：

查看召回列表是否包含正确文档。
检查原始问题是否被错误改写。
检查切分是否破坏关键段落。
增加混合检索或术语归一化。
对高频失败案例建立专项评测集。

问题二：模型生成幻觉

可能原因：

检索结果不相关。
上下文噪声太多。
提示词没有限制“只依据材料回答”。
模型被要求回答没有证据的问题。
生成结果未做引用校验。

排查思路：

检查生成前上下文是否包含错误来源。
提高重排阈值。
强制要求引用来源编号。
对无答案问题设置拒答。
增加输出后校验，例如引用匹配、关键实体核对。

问题三：关键内容被漏召回

可能原因：

查询与文档术语不一致。
只使用单一向量检索。
表格、编号、缩写未被正确索引。
文档解析丢失结构。

排查思路：

增加关键词检索。
对专有名词建立同义词或别名词典。
检查解析器是否正确处理表格和代码。
提高召回数量并观察候选集。
对重要文档做人工标注测试。

问题四：权限泄露风险

可能原因：

索引中没有权限标签。
检索阶段未做用户过滤。
缓存复用了不同用户的上下文。
日志中保留了敏感内容。

排查思路：

在索引阶段补齐权限字段。
查询入口强制校验身份。
缓存键必须包含用户权限维度。
日志脱敏并限制访问。
对敏感知识库启用硬隔离。

问题五：成本持续上升

可能原因：

上下文过长。
每次请求都全量检索。
重排数量过大。
高频问题未缓存。
所有任务都使用高成本模型。

排查思路：

设置上下文预算。
对稳定问题启用缓存。
对简单问题走轻量模型。
降低召回与重排数量。
增加摘要压缩，减少输入长度。

问题六：知识更新后回答仍使用旧版本

可能原因：

索引未增量更新。
文档版本号未校验。
旧版本未标记失效。
缓存未清理。

排查思路：

建立文档版本机制。
检索时优先选择生效版本。
更新后触发索引重建或增量刷新。
对高频问题缓存设置失效时间。
在回答中展示引用版本和时间。

八、优化建议

采用混合检索

不要只依赖向量相似度。企业文本中常有专有名词、错误码、编号、缩写，关键词检索能补足精确匹配能力。

引入重排机制

召回解决“有没有”，重排解决“准不准”。在候选集较多时，重排通常能明显提升上下文质量。

做好上下文预算

不要把所有召回内容一次性塞给模型。应按相关度、权限、版本、时效进行排序，再压缩到合理长度。

建立分层记忆

Agent系统可区分短期记忆、长期记忆和知识库检索。短期记忆保存当前会话，长期记忆保存用户偏好，知识库检索负责私域事实。

设置工具调用优先级

能实时查询的优先实时查询，能结构化获取的数据不要强行塞进文档检索。RAG不是万能层，而是知识组织与证据提供层。

建立反馈闭环

将用户点踩、人工纠正、低引用率答案、无答案问题纳入优化队列。持续迭代比一次性调参更重要。

加强可观测性

建议记录查询改写、召回结果、重排结果、上下文摘要、生成答案、引用编号、耗时和成本。只有可观测，才能持续优化。

控制成本

可采用多级模型策略：简单问题使用轻量模型，复杂问题使用高能力模型；稳定答案启用缓存；长文档先摘要再检索。

九、总结

回到最初的问题：RAG对Agent是不是必须？

答案是：不绝对必须，但取决于任务是否需要私域知识、精确证据、权限控制和可追溯性。

在长上下文时代，RAG的价值不再只是“把资料塞进模型”，而是帮助企业做到：

找得准：通过混合检索和重排提升相关性。
说得对：通过压缩、引用和约束降低幻觉。
管得住：通过权限、版本和审计控制风险。
用得起：通过预算、缓存和分层策略控制成本。

因此，更成熟的架构不是“长上下文替代RAG”，也不是“无脑堆RAG”，而是采用“检索—压缩—读取”的组合方式：先用检索找到可能相关的证据，再用压缩降低噪声和成本，最后让模型基于高可信上下文生成答案。

对于开发者而言，落地关键不是追求复杂组件，而是先明确业务目标，再逐步建设知识治理、切分、索引、检索、重排、压缩、权限、评测和监控闭环。只要这条链路清晰，Agent在长上下文时代依然可以稳定、可控地发挥价值。

长上下文下RAG与Agent落地教程

最热文章