1. 为什么企业技术支持场景值得单独做一个 Agent企业技术支持这个场景看起来只是客服问答的一个变种但真正做过的人都知道它和面向 C 端的通用问答完全是两码事。C 端问答答错了用户顶多骂两句就走了企业技术支持答错了可能直接导致一个客户的生产环境停摆或者让一线工程师在错误的排查方向上浪费几个小时。这个差异决定了企业技术支持 Agent 的设计目标不是聊得像人而是答得准、答得稳、答不出来要老实说。我接手这个项目的时候团队里已经有一个基于通用大模型的问答机器人效果怎么说呢demo 演示的时候很惊艳真上线之后一线工程师用了两周就没人再打开了。原因很朴素它不知道我们内部的产品文档长什么样不知道某个报错码在哪个版本被修复过也不知道某个配置项在客户现场的实际约束。它唯一能做的就是拿着通用知识去猜而猜出来的答案在技术支持场景里是负资产。所以这个项目的核心命题从一开始就很明确让 Agent 在企业私有的知识体系里工作而不是在通用语料里工作。这就引出了 RAG检索增强生成这条技术路线。RAG 的本质其实一句话能说清——把模型脑子里记的换成模型现场查到的。模型本身不需要重新训练我们只需要在它回答问题之前把相关的企业知识片段检索出来塞进上下文让它基于这些真实材料来组织答案。标题里那句没 Token 能用有 Token 更聪明是我在项目复盘时总结出来的一句话也是整个方案设计的一条暗线。这里的 Token 有两层含义一层是大模型调用时消耗的 Token 额度另一层是访问企业知识库时需要的鉴权 Token。前者决定了成本上限后者决定了数据边界。这两层 Token 的处理方式直接决定了这个 Agent 是能跑起来还是能长期跑下去。这篇文章我会把整个实战过程拆开讲包括方案选型的取舍、知识库怎么建、检索怎么调、Agent 怎么编排、Token 怎么管、线上踩了哪些坑。适合正在做企业级 RAG 应用的工程师、技术负责人也适合刚接触 Agent 开发想找一个真实场景练手的朋友。我不会只讲应该怎么做更会讲我为什么这么做以及我踩过哪些坑。2. 整体架构设计与技术选型思路2.1 为什么是 RAG 而不是微调项目启动时团队内部有过一轮争论到底是走微调路线还是走 RAG 路线。支持微调的理由很直接——微调后的模型对领域知识的内化程度更高回答更自然不需要每次检索。但我们在评估之后还是选了 RAG原因有三个每一个都是实打实的约束。第一个约束是知识更新频率。企业技术支持的知识库不是静态的产品每两周发一个版本文档每周都在改客户现场的配置案例每天都在新增。微调一次模型的成本和时间根本跟不上这个更新节奏。而 RAG 的知识更新只需要重新索引文档分钟级就能生效。第二个约束是可追溯性。技术支持场景里工程师需要知道答案是从哪份文档来的因为客户会追问你依据的是哪个版本的说明。微调模型的回答是内化的你没法给它标注来源。RAG 天然带引用检索到哪段就引用哪段这个特性在技术支持场景里是刚需。第三个约束是幻觉控制。微调模型在遇到知识盲区时仍然会自信地编造答案因为它的训练目标就是生成流畅的文本。RAG 可以通过检索不到就拒答的机制把幻觉压到最低。这一点在技术支持场景里比什么都重要。提示如果你的场景知识更新慢、对可追溯性要求低、且预算充足微调是可以考虑的。但只要涉及频繁更新的企业知识RAG 几乎是唯一选择。2.2 分层架构把检索和生成彻底解耦整个 Agent 我拆成了四层每一层职责单一方便单独调试和替换。层级职责关键组件接入层接收请求、鉴权、限流API 网关、Token 校验编排层意图识别、检索决策、工具调用Agent 编排框架检索层向量检索、关键词检索、重排Embedding 模型、向量库、重排模型生成层基于上下文组织答案LLM 推理服务这么分层最大的好处是当检索效果不好的时候我可以单独把检索层拎出来做评估不用每次都跑完整的生成流程。实测下来RAG 系统里 80% 的效果问题都出在检索层而不是生成层。很多人一上来就换更大的模型其实方向错了。2.3 Embedding 模型怎么选Embedding 模型是 RAG 的地基选错了后面怎么调都费劲。我当时的选型标准有三条中文语义理解要过关、支持长文本、推理速度能接受。我对比了几个主流方案最后选了一个在中文语义上表现稳定的开源 Embedding 模型维度是 1024。为什么不选维度更高的因为维度越高向量库的存储和检索开销越大而实测下来 1024 维在技术支持这种垂直领域已经够用。维度不是越高越好够用就行。这里有个经验Embedding 模型一定要用你自己的业务语料做一次小规模评估。公开榜单上的排名只能参考因为榜单的语料和你的业务语料分布可能完全不同。我当时拿了 200 条真实的技术支持问答对人工标注了正确文档是否被检索到然后跑不同模型算命中率最后选出来的模型和榜单排名并不完全一致。2.4 向量库与关键词检索的双路并行只用向量检索是不够的。技术支持场景里有大量专有名词、报错码、版本号这些内容的语义相似度检索经常失灵。比如用户问ERR_5023 怎么解决向量检索可能召回一堆语义相近但报错码不同的文档。所以我在检索层做了双路并行向量检索负责语义匹配关键词检索负责精确匹配两路结果合并后做重排。这个设计看起来简单但效果提升非常明显。实测下来纯向量检索的 Top5 命中率大概在 62%加上关键词检索和重排之后Top5 命中率能到 89%。3. 知识库构建从原始文档到可检索片段3.1 文档清洗脏数据是检索效果的头号杀手企业内部的文档质量参差不齐。有 Markdown 写的规范文档有 Word 导出的带一堆格式的说明有从 Confluence 直接导出的 HTML还有工程师随手记的纯文本笔记。这些文档如果不做清洗直接切分检索效果会惨不忍睹。我做的清洗步骤包括去掉页眉页脚、去掉导航栏残留、统一标点符号、把表格转成结构化文本、把图片的 alt 文本提取出来。其中表格处理是最容易被忽略的。技术支持文档里有大量参数对照表如果直接按字符切分表格会被切得七零八落检索出来根本没法用。我的做法是把表格单独识别出来转成参数名-参数值-说明的三元组文本再参与切分。这样检索的时候用户问某个参数能精确命中对应的行。3.2 切分策略不是越小越好也不是越大越好切分Chunking是 RAG 里最玄学的一环。切太小上下文不完整模型拿到片段也答不出完整答案切太大检索精度下降因为一个片段里混了太多主题。我试过几种策略最后定下来的方案是按语义结构切分 滑动窗口兜底。具体来说优先按文档的标题层级切分一个三级标题下的内容作为一个基础块如果某个块超过 800 字按段落再切如果某个块小于 100 字和相邻块合并所有块之间保留 15% 的重叠避免边界信息丢失为什么是 800 字这是实测出来的。技术支持文档的一个完整知识点通常在 300 到 800 字之间。低于 300 字信息不完整高于 800 字主题开始发散。这个数字不是拍脑袋定的是拿真实问答对反复测出来的。注意切分参数一定要用你的业务数据测不要照搬网上的最佳实践。不同领域的文档结构差异巨大通用参数往往不是最优。3.3 元数据让检索能按条件筛光有文本片段是不够的每个片段我都附加了元数据来源文档、文档版本、适用产品型号、最后更新时间、文档类型。这些元数据在检索时可以当过滤器用。举个例子用户问的是某个老版本产品的问题如果不过滤版本检索可能召回新版本的文档答案就错了。加上版本过滤之后检索只在对应版本的文档里找准确率立刻上来了。元数据的另一个用处是排序加权。同样相关的两个片段更新时间更近的应该排前面。我在重排阶段给新文档加了权重实测下来对最新解决方案类问题的效果提升明显。3.4 索引构建与增量更新索引构建我分成了全量和增量两条链路。全量索引每周跑一次把所有文档重新处理一遍保证一致性。增量索引在文档变更时触发只处理变更的部分。这里有个坑增量更新时旧版本的向量必须删掉。我一开始没做删除结果同一个文档的新旧两个版本都在索引里检索时经常召回旧版本答案就过时了。后来加了文档 ID 去重逻辑同一个文档只保留最新版本。索引构建的耗时也要关注。全量索引第一次跑的时候几千份文档花了将近两个小时。后来做了并行处理把文档分片后多进程处理时间压到了 20 分钟以内。这个优化在文档量继续增长后会越来越重要。4. Agent 编排让检索和生成协同工作4.1 意图识别先判断要不要检索不是所有问题都需要检索。用户说你好、谢谢这种直接回复就行没必要走检索流程浪费 Token。用户问你们支持哪些产品这种走一次产品列表查询就行不需要向量检索。所以 Agent 的第一步是意图识别把请求分成几类闲聊、元信息查询、知识问答、需要工具调用。只有知识问答和工具调用才走完整流程。这个分流看起来简单但能省下大量不必要的检索和生成开销。意图识别我用的是小模型 规则兜底。小模型负责语义分类规则负责处理明显的模式比如包含报错码的肯定是知识问答。为什么不用大模型做意图识别因为意图识别这个任务本身不难用小模型又快又便宜没必要上大模型。4.2 查询改写把用户的话翻译成检索友好的形式用户的提问往往很口语化直接拿去检索效果不好。比如用户问我那个东西连不上了怎么办这里面没有明确的产品名、没有报错信息检索根本无从下手。查询改写这一步就是让 LLM 把口语化的问题改写成检索友好的形式。改写后的查询会补全产品名、明确问题类型、提取关键实体。实测下来改写这一步对检索命中率的提升在 15% 左右是性价比很高的一步优化。改写的时候要注意不要过度改写。我一开始让模型尽可能丰富查询结果模型加了一堆用户没提到的假设反而把检索带偏了。后来改成只补全用户明确提到的实体不添加任何假设效果就稳了。4.3 多轮检索一次不够就再来一次单次检索经常不够。用户的问题可能涉及多个知识点一次检索只能召回一部分。所以我做了多轮检索机制第一轮检索后让 LLM 判断现有材料是否足够回答如果不够它会生成一个补充查询再检索一轮。这个机制的关键是设置轮次上限。我设的是最多 3 轮超过就基于现有材料回答并明确告知用户信息可能不完整。不设上限的话遇到检索不到的问题会无限循环Token 消耗爆炸。4.4 生成阶段的 Prompt 设计生成阶段的 Prompt 我改了很多版最后定下来的结构是这样的你是企业技术支持助手。请严格基于以下参考资料回答问题。 参考资料 {retrieved_context} 用户问题{user_query} 回答要求 1. 只使用参考资料中的信息不要编造 2. 如果参考资料不足以回答明确说明根据现有资料无法确定 3. 回答时标注信息来源的文档编号 4. 涉及操作步骤时按顺序列出这个 Prompt 里最关键的是第 2 条。明确允许模型说不知道是控制幻觉最有效的手段。如果不给这个出口模型在检索不到的时候会硬编编出来的答案比不回答危害大得多。5. Token 管理成本与体验的平衡术5.1 上下文 Token 的预算分配每次调用 LLM上下文里塞的东西越多Token 消耗越大。我做过统计一个典型的问答请求如果检索 Top10 全部塞进去上下文能到 6000 Token 以上。但实际有用的可能只有前 3 条。所以我对上下文做了预算分配检索结果最多保留 Top5总长度控制在 3000 Token 以内。超过的部分截断优先保留重排分数高的。这个策略把平均上下文 Token 压到了 1800 左右成本降了一半多而效果几乎没有下降。5.2 缓存相同问题不重复检索技术支持场景里重复问题非常多。同一个报错码一周可能被问几十次。如果每次都走完整流程纯属浪费。我做了两级缓存查询级缓存和检索级缓存。查询级缓存直接缓存最终答案命中就返回检索级缓存缓存检索结果生成阶段还是要跑但省掉了检索开销。查询级缓存设了较短的过期时间因为知识库会更新检索级缓存的过期时间可以长一些。缓存命中率实测在 35% 左右这部分请求的 Token 消耗直接降到接近零。5.3 鉴权 Token 的生命周期管理这里的 Token 是访问企业知识库和内部服务的鉴权凭证。企业环境里这类 Token 通常有较短的有效期需要定期刷新。我踩过的坑是Token 刷新失败时的降级处理没做好。有一次鉴权服务抖动Token 刷新失败整个 Agent 直接不可用了。后来加了降级逻辑Token 刷新失败时先用缓存的知识片段回答同时告警。这样至少不会完全不可用。Token 的存储也要注意绝对不能硬编码在代码里也不能明文存在配置文件里。我用的是密钥管理服务运行时动态获取。这个在安全审计时是硬性要求。5.4 成本监控把 Token 消耗可视化不监控成本你永远不知道钱花在哪了。我搭了一个简单的监控看板按天、按请求类型、按用户维度统计 Token 消耗。监控之后发现一个有意思的现象20% 的请求消耗了 60% 的 Token。这些请求大多是复杂问题触发了多轮检索和长上下文。针对这部分我做了更激进的截断策略把长尾成本压了下来。6. 常见问题与排查技巧实录6.1 检索命中率低的排查思路检索命中率低是最常见的问题。我的排查顺序是这样的先看查询本身是不是口语化太严重需要改写再看切分是不是切得太碎或太大再看 Embedding 模型是不是和业务语料不匹配最后看向量库配置是不是距离度量选错了这个顺序是从成本低到成本高排的。很多时候问题就出在第一步改个查询改写策略就好了不用动后面的。6.2 模型答非所问的几种典型情况现象可能原因解决方向答案正确但答非所问检索召回了不相关文档优化重排加元数据过滤答案部分正确上下文被截断调整上下文预算答案完全编造检索为空但模型硬答强化拒答 Prompt答案过时召回了旧版本文档加版本过滤和去重6.3 并发扛不住的优化路径Agent 上线后遇到高峰期并发上不去的问题。排查下来瓶颈在检索层向量库的单次查询延迟在高峰期会明显上升。优化路径有几条加缓存是最直接的把高频查询的检索结果缓存起来向量库分片能提升吞吐异步化把检索和生成解耦检索可以并行跑多路。我最后是三条一起上把并发能力提升了大概 4 倍。6.4 几个我踩过的坑第一个坑是过度依赖向量检索。前面提过专有名词和报错码必须靠关键词检索兜底纯向量在垂直领域不够用。第二个坑是忽略文档版本。技术支持场景里版本极其重要不同版本的解决方案可能完全相反。元数据里一定要有版本字段。第三个坑是Prompt 里没给拒答出口。这个坑最隐蔽因为模型编出来的答案看起来很合理不仔细核对根本发现不了。上线前一定要做幻觉测试。第四个坑是缓存没设过期。知识库更新后缓存里的旧答案还在返回用户拿到的信息是过时的。缓存一定要有合理的过期策略。7. 上线后的效果与持续迭代上线三个月后我拉了一次数据。一线工程师的使用率从最初的 12% 涨到了 67%平均问题解决时间从 25 分钟降到了 8 分钟。这个提升主要来自两个方面一是检索准确率上来了二是 Agent 学会了不知道就说不知道工程师不再被错误答案误导。持续迭代上我主要做两件事。一是收集 bad case每周把工程师标记为答案有问题的请求拉出来分析归类后针对性优化。二是定期重跑评估集确保每次改动不会让整体效果回退。评估集是我从真实问答里挑出来的 300 条覆盖了各类问题。每次改检索策略或 Prompt都跑一遍评估集看命中率和准确率的变化。没有评估集的优化就是盲调这是我踩过的最大的方法论坑。最后分享一个小心得RAG 系统的效果提升80% 来自检索层的优化而不是换更大的生成模型。我见过太多团队一上来就上最大的模型结果检索召回的都是垃圾模型再强也白搭。把检索做扎实用小模型也能跑出好效果。这个顺序千万别搞反了。