知识库答非所问，问题出在哪一层

上线 AI 客服之后，最常听到的反馈是："它回答的好像是对的，但又不是客户问的。"
客户问"今天能发货吗"，AI 回答"我们的发货时间是工作日上午 9 点到下午 5 点"——单看这句话没错，但客户其实想问的是"我的订单今天能不能发出去"，需要的是订单状态查询，不是发货时间说明。
这种"答非所问"不是 AI 不够聪明，而是知识库从"文档"到"答案"的链路中，有三个环节任何一个出问题都会导致结果偏离：
文档切分 → 向量召回 → 答案生成
每个环节解决不同的问题：

  • 文档切分决定知识库是否把信息切成了可检索的单元。切得太粗，一个段落里混杂多个信息点，难以精准匹配；切得太细，完整信息被拆散，检索时找不到上下文。

  • 向量召回决定知识库是否能从海量文档中准确找到和问题相关的片段。召回策略不精准时，匹配到的可能是相似但不相关的内容。

  • 答案生成决定大模型是否基于召回的正确内容生成回答。缺乏约束时，模型可能自由发挥、补充了不在知识库里的信息，或者把 A 产品的能力安到了 B 产品上。

知识库.png

下面逐一拆解这三个环节的优化方法。

一、文档切分：回答准确性的起点

知识库的底层是文档。但把一份完整的 PDF 或 Word 文档丢进知识库，不等于 AI 就能理解它。系统需要先把文档切成若干片段，再为每个片段建立索引，才能在检索时匹配到相关内容。
文档切分方式直接影响回答质量。 常见的切分方式有三种：
切分方式
做法
优点
风险
固定长度切分
按字符数或 Token 数切段
实现简单，通用性强
一个段落被切断，语义不完整；答非所问高发
语义切分
按段落、标题、章节边界切分
保持语义完整，匹配准确率高
需要理解文档结构，实现成本略高
混合切分
先按语义边界切分，对长段再按层级拆分
兼顾语义完整和检索粒度
配置复杂度增加
实操建议：

  • 优先按语义边界切分。 文档中的标题、段落、列表项本身就是天然的分割线。把每个二级标题下的内容作为一个独立知识单元，比按固定 512 字切一段效果更好。

  • 保留上下文元信息。 每个知识片段应该携带来源文档名、章节标题、段落编号。这样当 AI 引用该片段时，可以追溯到原文位置，方便运营人员验证和修正。

  • 对 FAQ 类型知识做单独处理。 FAQ 的"一问一答"是最适合知识库的格式——问题天然是检索索引，答案是召回目标。一份 FAQ 的命中率和准确率通常远高于长篇文档切分。

  • 避免"信息混装"。 如果一个段落里同时包含价格、参数、保修政策三个信息点，建议拆为三个独立知识单元。否则当客户问"保修多久"时，AI 可能匹配到整个段落，然后把价格和参数也一起输出。

二、向量召回：让 AI 找到对的文档片段

切分完成后，系统需要把用户问题与知识库中的文档片段做匹配。这个过程叫召回。
召回的常见问题：

  • 语义相似≠答案正确。 "退款流程"和"退货流程"语义相似，但答案完全不同。如果召回到的片段是"退货流程"，而客户问的是"退款流程"，AI 就会答非所问。

  • 关键词匹配的局限。 客户用口语化表达时（如"退票"），知识库里的正式表述可能是"取消订单"，关键词不匹配就召不到。

  • 返回片段过多。 召回 Top5 或 Top10 片段传给大模型，其中可能混杂了不相关的内容，大模型在多个片段中选择了错误的那一个。

优化方法：

  • 混合检索模式（关键词 + 向量）。 纯向量检索在语义相似场景下效果好，但容易忽略精确匹配。纯关键词检索可以精确匹配"退票"这样的核心词，但无法理解"我不想要这张票了"这种表达。混合检索同时使用两种方式，取两者结果的交集或加权排序，是目前召回效果最好的方案。

  • 问题改写。 客户的问题可能是碎片化的、口语化的、甚至带错别字的。在检索前，先让大模型把客户问题改写成标准表述，再用改写后的表述去检索知识库。比如"这票能不能退"改写为"退票政策查询"，召回效果明显提升。

  • 知识分类与检索范围限定。 不是所有问题都需要搜索全部知识库。把知识按业务分类（产品 A、产品 B、售后政策、物流说明），在意图识别阶段就确定检索范围，可以大幅减少不相关内容的干扰。

三、答案生成：控制大模型别"自由发挥"

召回正确的内容之后，大模型需要基于这些内容生成答案。这一阶段最常见的两个问题是：幻觉和信息遗漏。
幻觉的表现：

  • 知识库里没有的信息，AI 自己编造了。

  • 知识库里明确禁止的表述，AI 忽略了。

  • 知识库里的信息有多个版本，AI 选择了错误的那一个。

信息遗漏的表现：

  • 客户问了三个问题，AI 只回答了其中一个。

  • 知识库片段中有明确的限制条件（如"仅限 VIP 会员"），AI 没有引用。

优化方法：

  • 设置严格的引用约束。 在 Prompt 中明确要求：只基于提供的知识片段回答；如果知识片段中没有相关信息，直接回答"暂未查到相关信息，建议转人工咨询"；不补充知识片段以外的信息。

  • 引用来源可见。 在回复中标注引用来源（如"根据《退换货政策》第 3 条"），一方面让客户知道答案有依据，另一方面便于运营人员追踪和验证。

  • 多轮对话中的上下文管理。 在连续对话中，AI 可能把上一轮的信息带到了下一轮。需要设定每轮对话的检索范围，避免跨轮次信息混淆。

  • Badcase 回流机制。 每一次答非所问的案例，都应该被记录、分类、分析，然后反哺到知识库或 Prompt 优化中。答非所问不是终点，而是下一次优化的起点。

从"答非所问"到"持续优化"：知识库运营的四个阶段

知识库的准确性不是一次配置就能解决的，而是需要持续运营。可以把知识库的优化过程分为四个阶段：
第一阶段：基础搭建。 把 FAQ、产品手册、服务流程等文档导入知识库，采用语义切分方式，设置基本的检索和答案生成规则。这一阶段的目标是让 AI 能回答 60%-70% 的标准咨询问题，答非所问率控制在 10% 以内。
第二阶段：迭代优化。 收集上线后的答非所问案例，按"切分问题/召回问题/生成问题"分类，逐一修复。每修复一个类型的问题，就更新知识库对应部分。这一阶段的目标是让答非所问率降至 5% 以下。
第三阶段：知识运营。 建立知识更新机制——业务政策变化时同步更新知识库；从质检和 VOC 中发现高频错误和知识缺口；根据客户反馈补充缺失的知识点。知识库从"静态文档集合"变成"动态运营资产"。
第四阶段：智能反哺。 利用质检分析、VOC、服务小结等数据，自动识别知识库中的问题点，推荐需要更新或补充的内容。这一阶段需要知识库与质检、VOC 系统的联动，让 AI 客服的准确率随着运营时间的增长而持续提升。
在知识库运营的各个阶段，合力亿捷的悦问知识库提供了一套从知识导入、语义切片、向量检索到 RAG 问答和引用依据的完整链路，支持知识分类、知识更新、生命周期管理、知识命中分析和知识缺口识别，并与质检 VOC 联动，根据高频问题、错误回答和 Badcase 补充或修正知识。其核心价值不是"存 FAQ"，而是让企业文档成为 Agent 可检索、可引用、可运营的知识底座。

检查清单：回答前的自查

在把知识库投入生产环境之前，建议用以下清单做一次自查：

  1. 文档切分：是否按语义边界切分？FAQ 是否单独处理？是否存在"信息混装"的段落？

  2. 检索策略：是否同时使用关键词和向量检索？是否需要问题改写？是否需要限定检索范围？

  3. 答案生成：是否设置了引用约束？是否要求标注来源？是否明确告诉 AI 不知道时该怎么做？

  4. 运营机制：是否有答非所问案例的记录和分类流程？知识更新是否有专人负责？质检数据是否反哺知识库？

这份清单不是一次性的，建议在每次知识库更新后重新检查一遍。按合力亿捷多个知识库项目的交付经验，知识库准确率的提升不是靠单次优化，而是靠"使用-发现-修正-验证"的持续循环——每一次答非所问的案例，都是下一次优化的起点。