AI客服RAG系统实战指南：从查询改写到效果评估的完整流程
基于近两年的实践经验，企业中最常见的AI需求可以归纳为以下四个主要类别：
一、工作流类AI应用
这类应用能有效解决具体问题，但AI技术含量相对较低，通常不足20%（大多在10%左右）：
二、简单AI知识库：AI客服场景
这是最为常见且真正能为企业体系实现降本增效的应用类型，多数情况下实现难度并不高：
三、简单AI知识库：AI内容生成应用
这也是一种相对普遍的项目类型，例如协助撰写公文，即依据现有模板生成符合规范的内容：
四、AIGC：文生图与文生视频
自今年下半年以来，文生图、文生视频相关需求日益增长，甚至已超越AI客服类需求，该领域蕴含巨大的商业机遇，例如AI漫画创作便具有较高的收益潜力：
每种项目类型都具备其固有的方法论、成本结构和技术瓶颈。其中，简单AI知识库构成了一套完整体系（其核心逻辑大同小异），即我们通常所说的RAG系统。然而，目前许多从业者对RAG概念仍感困惑，这包括我的一些学员。
他们在学习时似乎明白，但脱离学习环境后便感到茫然，然而一旦回归实际工作场景，又必然会遇到RAG系统。因此，我们有必要再次将RAG系统拉出来进行深入剖析！
RAG的效果问题
首先，这是必须反复强调的部分：许多同学使用RAG的方式过于粗暴。例如，他们直接将知识库文档丢进Coze或Dify等平台进行自动切片，随后花一下午简单调整提示词，便快速构建出一个聊天机器人。这种做法的效果若能出色，反倒令人意外。
我们这里讨论的是简单AI知识库，甚至可称之为AI搜索。此类产品的特性属于一锤子买卖，其核心衡量标准在于是否输出了期望的内容：
用户提问 -> 检索操作 -> 返回结果。如果检索返回的都是不相关的无效信息，整个流程即宣告失败；即便返回了部分所需内容，但其中混杂大量垃圾信息，同样不能视为成功。
决定这次搜索成败的关键因素有两点：
- 第一是用户输入，这具有不可控性，因此用户的问题或者说用于检索的关键词必须经过转写和优化；
- 第二是在确保输入（即用于搜索的关键词）无误的前提下，必须能获得正确的结果，这部分高度依赖最初的数据处理流程；
这里我们先探讨为何要改写用户查询，过程中将逐步涉及最令人头疼的数据入库处理环节：
查询改写
无论是Agent的工具调用，还是构建RAG系统，都会面临相同挑战：这也是稳定工作流难以彻底解决的环节——用户语言过于模糊，常包含多重意图，且泛化能力要求极高，只有模型能够妥善处理。
重申一个核心观点：用户无限的意图需要被有限的工具所收敛，用户无限的问题也需要被知识库设定边界。
例如，用户的一句话可能包含多个问题，但我们只能处理知识库中已有答案的问题，若问题超出范围则无需处理。
综上所述，重写查询相当于在检索前进行一轮语义收束，这将大幅提升检索精度。当前常见的策略包括查询分解，偶尔也会用到HyDE：
查询分解的核心思想是分而治之，将复杂或多意图查询拆分为独立的原子子问题；
HyDE（假设文档嵌入）属于先脑补，后检索策略，即让大语言模型基于问题生成一份“假设答案”，利用其丰富的语义信息进行检索；
大家可能尚未完全理解，此处我们通过一个案例详细展开说明：
案例详解查询改写
用户提问：我入职 8 个月了，想请 3 天病假，需要走什么流程？病假工资怎么算？
该问题同时包含了请假流程和病假工资计算两个意图。每个子问题对应一个明确的意图：
子问题1：“需要走什么流程？”——询问病假请假流程的意图。
子问题2：“病假工资怎么算？”——询问病假工资计算方法的意图。
这里涉及输入查询整理前的第一个关键知识点：问题分类表。
问题分类表（Intent）
模型不可能当场理解业务细节，因此稳定的检索不能仅依赖模型能力。在构建RAG之前，必须明确一件事：你的系统究竟需要解决哪些问题。例如，我在构建个人课程销售AI客服时，就设计了一套问题分类体系：
这种问题分类即我们之前所说的收敛过程：将无限的问题收敛为有限的类型。只要问题与我们预设的解决范围相关，无论用户如何表述都无需过度关注。
回到用户关于HR规则的询问，我们需要为每个意图指定一个问题类型（Intent），以指导后续流程：
- Intent 1: 请假流程咨询。用户询问请病假的具体流程和手续。
- Intent 2: 病假工资计算咨询。用户询问病假期间工资如何计算。
这应映射到HR领域的一张问题分类表（其作用在于收敛问题范围）：
| 问题类型 | 示例 |
|---|---|
| 请假管理 ： 请假与休假办理、审批规则、证明材料、销假/续假；考勤记录与异常更正（补卡/漏打卡）、迟到早退等出勤异常处理。 | 1）我想请病假/年假，怎么申请？ 2）请 3 天病假需要什么证明？ 3）我忘记打卡了，怎么补卡？ |
| 薪资规则 ： 计薪口径与发放周期；扣款/补发规则；补贴、加班费、绩效奖金发放；与出勤/请假相关的计薪规则（如病假工资）。 | 1）病假工资怎么算？会扣多少？ 2）这个月工资少了，扣的是什么？ 3）加班费怎么算？周末和节假日一样吗？ |
| 社保公积金 ： 参缴条件、基数比例、增减员；断缴/补缴/转移；商业保险与福利报销类事项的办理要求。 | 1）社保公积金什么时候开始缴？基数怎么算？ 2）社保断缴了怎么办，能补缴吗？ 3）商业保险怎么报销，需要什么材料？ |
| 入职、转正 ： 入职手续与资料；试用期与转正流程；工龄口径；员工信息变更；在职/收入等证明开具。 | 1）我什么时候转正？流程怎么走？ 2）工龄怎么计算？影响年假吗？ 3）在职证明/收入证明怎么开？ |
| 离职 ： 离职申请与通知期；交接要求；离职证明；最后工资/补偿结算；社保公积金停缴/转移；未休假期结算。 | 1）离职流程怎么走？要提前多久提？ 2）离职证明怎么开？什么时候能拿？ 3）最后一个月工资怎么结算？ |
| 制度查询 ： 制度入口与版本；条款解释与适用范围；例外情形；违纪处理；保密/竞业等合规边界说明。 | 1）公司制度在哪里看？最新版是哪份？ 2）某条规定怎么解释，有没有例外？ 3）这个做法合规吗？有红线吗？ |
数据处理
在清晰理解用户的查询输入后（用户的问题会被模型尽可能地引导至相应的问题类别），因此在执行知识检索时，更多是在进行简单的语义识别，甚至在此环节可以不用向量数据库，而采用小模型也能胜任：
这也是最常见的微调应用场景。我们通常对小模型进行微调后，用于处理问题类型判断，最终抽取问题类别（intent）标签。
因为只要确定了问题类别，相关知识就一定能够被检索出来。这也终于触及到我们的知识库究竟该如何构建的问题。
如上所述，由于收敛方式以问题类别为主导，因此知识库的排布也需要遵循此原则。这里给出一个简单案例：首先，每份文档前需添加一段**“摘要”**，之后才是具体内容：
module_id：如HR.Payroll
覆盖范围：能回答哪些问题
先决信息（Required Context）：回答前通常需要的关键背景（不是全量槽位，强调“最小关键”）
缺失追问（Clarifying Questions）：缺关键背景时，问用户的 1–2 句追问模板
检索提示（Retrieval Hints）：该模块常用关键词、优先命中的制度文档名称/章节
版本与适用范围：制度分地区/分用工类型时怎么处理
为了方便各位进一步理解，这里提供一个模型判断问题类别及具体知识库文档结构的样例：
你是一个专业的HR助手，负责对用户问题进行意图分类。
请严格按照下面的分类体系进行分析：
## 问题分类表
1. **请假管理**：请假与休假办理、审批规则、证明材料、销假/续假；考勤记录与异常更正
......
6. **制度查询**：制度入口与版本；条款解释与适用范围；例外情形；违纪处理
## 处理规则
1. 只识别上述6类问题，其他问题回复"抱歉，这个问题超出我的处理范围"
2. 一个问题可能涉及多个类别，输出所有相关类别
3. 具体处理流程...此处省略1000字...
4. 输出格式：{"intents": ["类别1", "类别2"], "reasoning": "简要分析原因"}
## 示例
用户：我入职8个月了，想请3天病假，需要走什么流程？病假工资怎么算？
输出：{"intents": ["请假管理", "薪资规则"], "reasoning": "问题包含请假流程（请假管理）和病假工资计算（薪资规则）两个意图"}
以下是一个具体的文档案例：
# 模块ID：HR.Leave.Medical
# 版本：xxx
# 适用范围：省事员工
## 摘要
本模块涵盖病假申请全流程及相关政策，包括：
1. 病假申请步骤（线上系统操作、材料要求）
2. 病假期间工资计算规则（基于司龄和当地政策）
3. 常见问题（证明材料、审批节点、异常处理）
## 覆盖问题范围
- 如何请病假？
- 病假需要什么证明材料？
......
## 先决信息（Required Context）
- 员工司龄（影响病假天数上限和工资比例）
- 所在地区（影响最低工资标准）
- 请假天数（影响审批层级）
## 缺失追问模板
1. "请问您的司龄是多久？这将影响病假工资的计算比例。"
2. "您计划请几天病假？不同天数的审批流程不同。"
......
## 检索提示（Retrieval Hints）
关键词：病假、医疗期、病假工资、医疗证明、病假申请、病假流程
相关文档：《员工手册-考勤篇》第3章、《薪酬福利制度》第5.2节
常用别名：医疗假、带薪病假、病休
## 具体内容
### 一、病假申请流程
1. **线上申请**
- 登录HR系统 → 请假申请 → 选择"病假"
- 填写：起止时间、病因简述、上传证明材料
- 提交至直接上级审批
......
这套逻辑本身是可靠的，但数据整理过程确实繁琐。例如，若想将自己所有的零散文章（如公众号内容）整理成此类知识库，将耗费大量精力。
HyDE（假设文档嵌入）
在简单的业务场景下，上述逻辑已相当清晰：先进行意图路由（收敛）→ 再到对应模块检索，这种方式的准确率非常高。
然而，在稍复杂的业务场景中，收敛只能解决“去哪里搜索”的问题，却无法确保“搜索得精准”。因为即便在同一类别下，也可能存在大量内容。最典型的场景是某个类别的文件特别长，被切割成数十个片段，而每个片段的摘要可能相似，导致检索出大量冗余内容。
更常见的情形是，即便我们将问题收敛到“请假管理”这个意图，知识库中可能包含：
- 病假申请流程（包含3种不同情况）
- 年假申请流程
- 事假规定
- …
用户询问“病假流程”，但知识库中可能存在：
- 《员工手册》第3章：通用请假流程
- 《考勤制度》附件2：病假特殊规定
- …
甚至不同条款间的內容可能存在冲突，例如后续条款覆盖了先前条款，特殊规定覆盖了普通规定等。
综上所述，意图收敛仅是第一层筛选，后续仍需进行精确匹配。
于是，HyDE在此处的作用得以凸显。对于意图2（病假工资计算），HyDE可以生成类似以下的假设答案：
根据公司规定，员工病假工资计算通常基于司龄、基本工资和当地最低工资标准。
对于司龄不满1年的员工，病假期间工资按基本工资的60%发放，但不得低于当地最低工资标准的80%...
这个“假设答案”包含了：
- 关键变量：司龄、基本工资、最低工资标准
- 具体数值：60%、80%
- 专业术语：基本工资、当地最低工资标准
使用这个向量进行检索，更容易精准命中《薪酬制度》中具体的计算条款，而非泛泛的薪酬介绍。这里再提供一个案例：
用户原问：我有点不舒服，想休息几天，工资怎么算？
意图识别：请假管理+薪资规则（可能存在歧义）
查询改写（HyDE）：
子查询1：“轻微不适短期休息请假流程，是否需要医生证明”
子查询2：“短期病假工资计算规则，非住院病假待遇”
查询效果评估
接下来进入一个关键环节：如何评估每次查询的质量。这也是一个非常经典的面试问题。常见的评估指标包括：
- 检索召回率（Recall@k）：改写后的查询，能否在 top-k 个检索结果中命中正确答案的文档；
- 查询意图保持度：通过人工抽样检查，判断改写是否歪曲了用户原意；
- 下游任务准确率提升：最终答案的准确率是否因查询改写而显著提高；
也有一些更通俗的评估角度：
- 没召回（入库/切分/索引问题）
- 召回了但没选对（重排问题）
- 选对了但答歪了（提示词/生成约束问题）
- 本来就不该答（范围外问题/需要工具调用/需要人工处理）
然而，每次我以为已经解释清楚时，仍有同学感到困惑，因此这里需要进一步细化说明：
首先，评估查询质量需要细化到每个处理链条，依次包括：
- 路由正确性 - 问题是否被分配到正确的意图模块；
- 召回可靠性 - 关键证据是否被成功检索到；
- 排序合理性 - 正确的证据是否排在前列；
- 回答可验证性 - 答案是否严格基于检索到的证据；
- 边界清晰度 - 对于不应回答的问题是否进行了恰当处理；
接下来便是具体的评估标准，这并非一蹴而就，而是一个逐步强化的过程：
弱标准
弱标准成本较低，甚至通过普通测试即可做出判断。它只需评估整体好坏，几乎依赖直觉，适合在项目初期进行快速验证。
具体操作是仅标注答案正确与否、是否需要追问、是否存在胡言乱语等。需要注意的是，每个处理环节都需要有对应的测试数据集。
过渡标准
通常在系统即将上线时需要进行此类测试，此时需要业务专家参与判断，一般测试工作仅作为辅助。
业务专家需要标注问题对应的正确文档，相当于他们提供文档级别的标准答案，例如：病假流程问题 → 《员工手册》第3章 + 《考勤制度》附件2。
此时必须构建成测试数据集，以便未来每次都能运行自动化脚本，检验类似问题的处理是否正确。
强标准
从这个阶段开始，要求变得更高：需要专家精确标注到具体段落，偶尔还需定义错误处理策略，例如冲突处理规则。
由于成本较高，实际操作中通常只对高频和高风险问题进行强标注，毕竟20%的问题往往决定了80%的用户体验。
数据集构建挑战
实际上，在进行模型评估时，存在两个主要难点：
- 第一是确立评估点，即到底哪些环节需要进行评估；
- 第二是每个环节的数据集如何获取；
按照之前的做法，可以在上线前请专家准备一部分数据，上线后则需妥善记录日志，并从日志中提取数据，例如：每周从线上日志中抽取100-200个真实问题。
需要注意的是，除了错误案例，还应收集一些正确案例，这对数据集的多样性大有裨益。
对专家依赖是无法避免的，但应尽量减轻其负担，例如让其直接做选择题（如判断对错、选择对应文档），最好为此设计一套专用系统供其使用。
最后提供一个简单的案例表，供大家参考：
| 错误类型 | 常见现象 | 修复策略 |
|---|---|---|
| 路由错误 （去哪搜错了） | 意图漏标/多标；多意图未拆分；路由到错误模块导致检索空间错误 | 调整意图体系与描述；补充训练样本/难例；优化阈值与多标签策略；增加澄清追问；路由后实施“兜底检索” |
| 搜不到 （召回缺失） | top-k 结果中完全无证据；同义词/别名未能命中；长文被切碎导致证据分散 | 优化chunk策略（大小/重叠/结构化切分）；将标题/摘要/条款号入库；应用元数据过滤；采用混合检索（BM25+向量）；构建同义词与别名表 |
| 搜到但没排上来 （排序问题） | 正确证据在 top-k 中但不在 top-3；冲突条款被旧版本压制；相似chunk重复占位 | 使用重排模型/规则重排；设置版本优先级与适用范围加权；实施去重与聚合；扩展top-k并进行二次检索 |
| 证据对但回答错 （生成失真） | 引用到证据但结论计算错误/漏答；多个chunk拼接错误；冲突条款未声明冲突 | 强化“只基于证据”的生成约束；采用逐条引用/引用-断言绑定；应用冲突处理模板（列出差异并请求确认）；对计算/规则类内容进行结构化解析或工具化处理 |
| 边界处理错误 （该不该答） | 不该答却回答了；该答却拒绝回答/过度追问；缺失关键槽位时不追问直接编造答案 | 明确边界定义与范围外处理策略；制定缺槽追问模板；设定拒答阈值；明确转人工条件；对“可答但信息不全”的问题设置最小追问集 |
结语
今天又投入了5小时来梳理这些内容，唯恐有哪里阐述不清，至今仍不确定是否已将简单AI知识库（RAG）为何困难、难点何在以及该如何实施讲透彻。
RAG是企业必定会面对的课题，要将其做好需要一条完整的处理链路，而非简单地将数据一股脑儿导入。事实上，构建高质量的RAG系统成本相当高昂：
好了，文章篇幅已经很长，就不再赘述，希望以上内容对各位有所助益。