这套 FAQ 系统在 2018 年上线，服务一家年 GMV 12 亿元的电商企业。迁移前，它每天要承接 5000 多次客服咨询，对标准问法的命中率却不到一半。用户把两个条件放进一句话，例如“退货超时还没退款”，系统通常只回“请转人工”。客服接手后，还得再翻一遍知识库。
维护也早已失序。原系统维护者离职两年，新增商品细则由运营手工写进 XML；迁移盘点时，三个月没有更新的 SKU 条款占 30%。
5 月，团队用三周切换到 RAG+Agent。迁移记录里，模型参数排得很靠后，前面全是旧数据和文档边界问题。下文涉及的命中率、完整回答率和成本均来自该项目内部记录，只代表这次迁移。
先从 3400 条旧问答里删东西
旧库共有 3400 条问答，盘点后发现：
- 重复或近义问法约占 20%，“怎么退款”和“退款流程”甚至指向不同答案；
- 过期政策超过 15%，2024 年的包邮规则仍被当作现行规则；
- 30% 的答案含有死链接或内部系统代号。
项目组参考了腾讯云《企业级 RAG 深度指南》中的处理路线，先将 PDF、Word 和 XML 统一解析为 Markdown，再用正则整理字段，并调用大模型处理近义内容。
项目记录显示，这条清洗链路使用了阿里云百炼的数据清洗 API，并以 Qwen2.5 做语义去重。“退款多久到账”和“退款到账时间”可以归到同一组，运营只需保留一份有效答案。百炼知识库的产品能力可参考阿里云帮助文档。
全量处理前，团队先抽了 100 条数据试跑。检查重点之一，是模型会不会把“包邮规则”和“免运费政策”误合并。这两个说法听起来接近，适用品类却不同。最终，它们仍作为独立条目保留，只在检索阶段做同义词扩展。
一周后，3400 条旧问答剩下 2600 条有效数据。每条内容都补上了场景、品类和时效性标签。后续分块与检索能否稳定，很大程度上取决于这一步。
768 token，先保住完整操作步骤
旧 FAQ 的答案平均 600 字，最长的“跨境退货完整流程”有 1800 字。直接按 512 token 固定切片，一个操作步骤很容易被截成两段，后半段单独进入检索后，常常失去前提。
团队把标题、列表和段落边界设为优先切点，再用长度兜底。工具仍是 LangChain 的 RecursiveCharacterTextSplitter，但分隔顺序改成章节标题、列表、自然段优先，而不是只依赖空行、句号和空格。
最后保留的参数是：
- 块大小从 512 调到 768 token，项目抽样中，一个完整操作步骤平均接近 650 token；
- 测试过约 20% 的重叠比例，超过 25% 后重复召回明显增加，最终固定为 128 token；
- 表格和代码块作为完整单元保留，不做中间切分。
每轮分块后，团队都会用百炼平台的分块可视化工具检查边界。第一次检查时，“退货运费险”被切成了两段，原因是原文中间夹着一段 NVlabs 免责声明。后来，这段声明被单独放进元数据，不再进入正文分块。
这项工作用了三天，最终生成 3800 个语义块。旧方案按固定长度切出了 5000 多个碎片；按内部 A/B 测试口径，新分块让检索命中率提高了 17 个百分点。
用户少说一个型号，检索就可能跑偏
用户问“手机壳有货吗”，向量检索可能找到“手机壳库存不足”，却不知道对方要查哪个手机型号。项目组因此加入 BM25，与向量召回一起工作：
- 向量检索使用 text-embedding-3-small，1536 维，按余弦相似度计算；
- 关键词检索使用 BM25，并做词干化和停用词过滤；
- 综合得分中，向量权重为 0.6，BM25 权重为 0.4。
这组权重来自网格搜索。在 1000 条内部测试集上，它对应的 F1 得分最高。
混合检索解决了不少首轮召回问题，但“对比过去三季各品类退货率”仍需要拆成多次查询。单次返回的 top-5 文本块，很难同时覆盖指标定义、季度数据和品类差异。Meta Intelligence 的 Agentic RAG 架构文章也提到了单次检索的信息瓶颈，并援引 Gao 等人在 2024 年发表的 RAG 综述。
项目组在检索器前增加了一个基于 Qwen2.5-7B 的轻量 Agent。它只负责三类判断：
- 当前问题是否需要拆开并多次检索；
- 信息不足时是否追问，例如先确认用户所指的品类；
- 是否调用订单系统 API，读取实时订单状态。
每次决策平均消耗 150 token。按项目内部定义，复杂问题的完整回答率从 62% 提高到 91%。
Agent 的追问阈值设为 0.7：检索置信度低于该值时，优先补问用户。最大迭代次数限制为三轮，避免重复检索。这两个参数用 500 条真实对话日志标定，并不适合作为其他知识库的默认值。
系统提示词里还写明了回答边界：“只处理售后政策相关问题。”这条限制用于阻止 Agent 跑去推荐商品，或回答知识库未覆盖的内容。
上线第二周，四个指标一起看
| 指标 | 旧 FAQ（上线前一周） | RAG+Agent（上线第二周） |
|---|---|---|
| 用户自助解决率 | 47% | 89% |
| 平均响应时间 | 12 秒 | 2.3 秒 |
| 客服转接率 | 41% | 19% |
| 用户满意度评分 | 2.8/5 | 4.3/5 |
2.3 秒是检索与生成的端到端延迟。知识块提前完成向量化，并存入 pgvector。按这组数据计算，客服转接率相对下降约 54%。
一线客服的反馈更直白：“以前用户问我‘退款到哪了’，我得查三个后台。现在系统直接给出进度节点，我只负责确认订单号就行。”
返工来自三件小事
旧数据没有时间戳。 清洗程序无法判断政策是否过期，运营只能逐条补上“有效期截止”字段，额外用了两天。
自助渠道变活跃后，Token 账单也涨了。 日调用量从 5000 增至 8500，月 Token 成本增加 2800 元。团队随后给重复率超过 60% 的高频查询加了缓存，缓存命中率为 37%，最终把相关成本压回旧系统的 1.2 倍。
有些文本块丢了前置条件。 例如“跨境订单需提供身份证号”，完整规则还包括“仅适用于金额超过 2000 元的订单”。条件没有一同召回，答案本身正确，用户仍会误解。
团队后来给 Agent 增加了一条规则：检索结果出现“仅”“需先”“如果”等条件词时，必须继续查找并呈现完整约束，不能只摘取操作结论。
记忆功能可以晚一点
当前系统运行在阿里云百炼上，向量存储使用 pgvector，Agent 框架使用 LangGraph。下一步计划加入记忆能力，例如记录用户经常查询数码品类，并在后续检索时优先匹配对应知识库。
在此之前，更值得复用的是那批 100 条真实对话日志。先用它们建立召回率基线，再决定是否全量迁移。3400 条旧问答最终只有 2600 条进入新库，这个差额已经说明问题：Agent 可以安排检索、追问和工具调用，却不会替过期政策补上有效期，也无法凭空找回被切掉的前置条件。
