#RAG 质量优化专题总览

很多团队第一次做 RAG，会把目标说成“让模型回答内部知识库问题”。这句话太宽了。

真实上线后，问题通常不是“有没有接向量数据库”，而是用户问了一个具体业务问题，系统在某一层失败：

• 知识库里有答案，但检索没有找出来。
• 检索找到了文档，但找的是相似而不相关的内容。
• 检索结果是对的，模型却没有使用，或者被其他上下文干扰。
• 答案看起来有引用，但引用并不能支撑结论。

这篇总览先把 RAG 质量问题拆成场景和失败类型，再给出从简单关键词到工程化优化的方案阶梯。核心观点很简单：RAG 质量不是一个“向量相似度”问题，而是一条从文档、检索、排序、上下文组装、生成到引用校验的链路质量问题。

#提出问题：客服知识问答为什么会失败

假设一个 B2B SaaS 公司给客服和客户成功团队做内部知识问答助手。

使用者是客服、实施顾问和客户成功经理。他们每天在工单、在线聊天和客户会议前查询产品限制、计费规则、集成步骤、故障排查和合同条款。

输入来自用户自然语言问题，例如：

企业微信集成失败，提示回调地址校验不通过。客户使用的是私有化部署，这种情况怎么排查？

期望输出不是泛泛解释，而是：

• 给出可执行排查步骤。
• 明确适用版本、部署形态和权限条件。
• 引用内部知识库、产品文档或故障案例。
• 在资料不足时追问或拒答。
• 让客服能把结果改写成对客户可见的回复。

当前没有 AI 时，客服会用站内搜索、飞书文档、历史工单和同事经验处理。平均一次复杂问题要查 5 到 15 分钟。最常见样本是产品功能说明和操作步骤，最容易失败的是版本差异、私有化客户、历史政策变更和多个文档互相冲突的情况。

这个场景的价值在于减少找资料时间、降低新人依赖资深同事、提高答案覆盖率。失败代价也很明确：错答会误导客户操作，引用不准会削弱信任，越权检索可能泄露内部资料。

#分析问题：RAG 不是单一检索问题

RAG 场景里通常同时包含检索、判断、生成和引用四类任务。

模型适合做语言理解和表达，但不应该独自决定能检索什么、能看什么、引用是否真实、冲突资料谁优先。权限、索引、来源、版本和引用校验都应该由工程系统显式控制。

#四类核心失败

#找不到

知识库里确实有答案，但系统没有召回。

常见原因包括 chunk 切得太碎导致上下文断裂，切得太大导致向量主题被稀释；用户问题和文档用词不一致；文档标题、产品线、版本、语言、权限等 metadata 没有进入索引；只用向量检索，漏掉订单号、错误码、接口名这类精确词。

例如用户问“回调地址校验失败”，文档里写的是“URL verification failed”。如果没有同义词、英文术语或历史工单样本，纯关键词可能找不到；如果只有向量，也可能被一堆“集成失败”泛化文档淹没。

#找错

系统召回了看起来相似但不适用的内容。

常见原因是语义相近但条件不同：公有云和私有化、旧版本和新版本、管理员和普通成员、国内版和海外版。向量相似度会把“主题相似”排在前面，但业务上真正重要的是适用条件。

例如检索到了“企业微信集成配置说明”，但那篇文档只适用于公有云；用户的问题来自私有化部署。答案如果直接采用，就会给出错误排查路径。

#找到了没用上

检索结果里有正确证据，但模型生成时没有使用，或者使用了错误片段。

常见原因是上下文里混入太多候选，正确片段排在后面；片段缺少标题、来源和适用条件，模型不知道哪个更权威；prompt 没有要求每个关键结论绑定引用；历史对话或用户猜测覆盖了检索证据。

这种失败最隐蔽，因为日志里看起来“检索命中了”，但最终答案仍然错。评估时只看 recall 会误判质量。

#引用不准

答案带了引用，但引用不能支撑句子。

常见表现包括引用了同一文档里的无关段落，多个结论共用一个泛化引用，引用只支持前半句不支持后半句，或者模型把文档中的“需要联系技术支持确认”改写成“可以直接修改配置”。

引用不准比没有引用更危险，因为它给用户一种“已经有依据”的错觉。

#收益/成本判断

RAG 质量优化的收益主要有四类：

• 降低人工找资料时间。
• 提升答案覆盖率，尤其是长尾问题。
• 让答案可追溯，方便复核和培训。
• 把知识更新从模型训练转移到文档和索引更新。

成本也不能低估：

• 文档解析、清洗、切分和索引维护。
• metadata 设计、权限过滤和版本治理。
• 检索、rerank、多路召回带来的延迟和费用。
• 评估集、标注、线上反馈和 trace 分析。
• 引用展示和人工复核 UI。

什么时候简单关键词或向量足够？

如果知识库小、命名规范、用户问题接近文档标题、失败代价低、使用者会人工点开原文复核，简单关键词搜索或单路向量检索通常可以起步。比如内部运营同学查活动模板、客服查固定话术、开发者查明确 API 名称。

什么时候需要工程优化？

如果问题包含版本、权限、部署形态、地区、套餐、错误码、合同条款或多文档综合判断，就需要更强的检索治理。只要答案会对外发送、影响客户操作、进入工单结论或被新人当作事实使用，就应该补齐评估、引用和可观测性。

#列举方案：从搜索到可评估 RAG

RAG 质量优化不应该一上来就堆所有技术。可以按失败类型逐步升级。

第一层是关键词搜索。适合错误码、接口名、产品名、政策编号等精确匹配问题。它便宜、可解释、容易调试。

第二层是向量检索。适合自然语言提问、同义表达、长文档语义匹配。它能提升语义召回，但容易找错适用条件。

第三层是 chunk 和文档清洗。把文档切成可回答问题的片段，并保留标题层级、表格、步骤、版本和来源。它解决“文档有答案但片段不可用”的问题。

第四层是 metadata 过滤。把产品线、版本、地区、套餐、权限、部署形态、更新时间和来源类型作为检索条件。它解决“主题相似但业务条件不适用”的问题。

第五层是 hybrid search。关键词和向量互补，适合既有精确词又有自然语言的问题。

第六层是 rerank。用更强的相关性判断在候选中重新排序，适合召回结果多、相似文档多、top-k 质量不稳定的场景。

第七层是答案引用绑定。让每个关键结论绑定证据，并检查引用是否真实存在、是否支撑结论。

第八层是 RAG Eval 和监控。用评估集和线上 trace 判断召回、排序、生成、引用各层是否退化。

本专题后续文章会沿着这条链路展开：

• 检索质量优化：覆盖文档处理、chunk、metadata、hybrid search 和 rerank。
• 引用与答案一致性（即将上线）：覆盖上下文组装、答案引用绑定、引用校验和权限过滤。
• RAG Eval：覆盖 retrieval、faithfulness、citation accuracy、样本集和回归门禁。

#决策判断：按失败代价选择复杂度

#反模式

第一种反模式：看到知识库就直接上向量数据库。

如果用户主要按错误码、API 名称、政策编号搜索，关键词可能比向量更稳定。向量数据库不能替代文档结构、metadata 和精确检索。

第二种反模式：只调 top-k。

top-k 变大可能提高 recall，也可能把更多噪声塞进上下文，导致“找到了没用上”。需要同时看召回、排序、上下文预算和生成引用。

第三种反模式：把文档原样入库。

很多文档是为人阅读写的，不是为检索切片写的。标题、表格、步骤、注意事项和版本说明如果切丢，模型拿到片段也无法回答。

第四种反模式：只看答案是否像样。

RAG 评估必须看链路：查询是什么、召回了什么、排序如何、哪些证据进入上下文、答案用了哪些证据、引用是否支撑。只看最终文案会掩盖根因。

第五种反模式：有引用就默认可信。

引用必须能支撑对应句子。引用一个长文档首页、一个无关段落，或者引用只支持部分结论，都不算合格。

#结论收束：上线前工程清单

• 场景边界：目标用户、知识范围、可回答问题和必须拒答的问题是否明确。
• 文档来源：知识库、工单、手册、合同、数据库和网页是否有来源、版本、更新时间。
• 权限控制：检索前是否按用户、租户、角色、客户和资料等级过滤。
• Chunk 策略：标题层级、表格、代码块、步骤、FAQ、版本说明是否保留。
• Metadata：产品线、版本、地区、套餐、部署形态、来源类型和更新时间是否可用于过滤。
• 检索策略：关键词、向量、hybrid、rerank 的组合是否和问题类型匹配。
• 上下文组装：是否控制 token 预算、去重、排序、来源展示和冲突资料。
• 生成约束：是否要求答案只基于证据，资料不足时追问或拒答。
• 引用校验：引用 ID 是否真实，关键结论是否能被引用片段支撑。
• 评估体系：是否有 retrieval precision/recall、faithfulness、citation accuracy。
• 可观测性：是否记录 query、候选、rerank 分数、上下文、答案、引用和用户反馈。
• 成本延迟：是否有缓存、分层检索、超时、降级和模型路由。

#小结

RAG 质量优化要从失败类型开始，而不是从技术名词开始。

找不到，通常要看查询理解、chunk、关键词和向量召回；找错，通常要看 metadata、权限、版本和 rerank；找到了没用上，通常要看上下文组装和生成约束；引用不准，通常要看答案和证据是否逐句绑定。

低风险、小知识库、用户会复核的场景，可以从关键词或单路向量起步。高风险、条件复杂、需要对外使用的场景，需要把 RAG 当成可评估、可观测、可迭代的工程系统。