什么是AI客服"编答案"？
"编答案"不是偶尔答错，而是在没有可靠知识依据时，仍给出看似完整、确定的回复。
客户真正担心的通常是这几类表现：
• 知识库里没有的内容，AI却给出具体政策、价格或操作步骤
• 用户问A场景，AI套用B场景答案
• 知识库未命中时，AI不说"不知道"，而是自行"总结"
• 语气很确定，事后却在知识库找不到对应条目
这和传统FAQ机器人不同——答不上来就转人工。大模型天然倾向于补全对话，检索为空或相关性很低时，仍可能基于训练语料"推理"出听起来合理的答案。这也是客户常问的：AI会不会自行创造答案？能否控制它必须按指定知识库回答？
编答案通常发生在哪四个环节
问题很少出在模型本身，更多出在知识治理和流程设计。
环节一：知识边界没划清。 把价格、库存、班次、订单状态等高频变化数据写进静态FAQ，知识一过期，AI检索到的就是错误依据——客户感受上和"编"一样。
环节二：检索命中了错误知识。 相似问题对应不同答案时，向量检索可能召回语义相近但场景不对的知识。客户常问：知识库按"分类"还是"知识点"调用？相似问题答案不同，怎么避免查错？
环节三：未命中仍允许生成。 检索为空或置信度不足时，流程没有强制转人工或拒答，模型直接进入生成——这是"编答案"最高发的节点。
环节四：缺少上线后审计。 答偏、答错没有被标记和回流，同类错误反复出现。
确保只按指定知识库回答：五层约束框架
"只按知识库回答"不是一句提示词能解决的，而是可执行的约束架构。五层按实施顺序排列，缺任何一层，都可能"看起来有知识库、实际上仍在编"。
第一层：先划清什么该进知识库、什么该走实时接口
稳定规则和标准问答适合进知识库：退换政策、产品规格、操作步骤、常见售前咨询。价格、库存、班次、订单状态等高频变化数据，应优先通过业务系统接口实时查询，而不是在FAQ里反复维护。
这一层解决"知识源就不该让AI乱答"的问题。实时数据硬塞进静态库，AI即使严格按检索回答，也可能是过期信息。在Agent架构里，实时查询通常通过Flow编排调用业务工具完成，而不是让模型凭静态知识推断当前状态——但具体能接哪些系统，取决于企业接口条件和产品版本，上线前须逐项确认。
适用场景： 电商、物流、文旅、金融等存在大量实时状态查询的业务。
第二层：检索先于生成，回答必须绑定知识召回
核心原则：先查知识，再组织语言；不允许跳过检索直接生成。
在Agent架构中，回答流程里要有显式的"搜索知识库"步骤，而不是把全部内容塞进系统提示词让模型自由发挥。在回答前的必经环节，需要先把用户问题映射到指定知识库并召回条目，再基于召回结果组织语言。
合力亿捷智能客服Agent的Flow编排提供「搜索FAQ知识库」系统工具，可设为生成回复前的必经步骤——Agent须先调用该工具从指定库召回内容，再组织回答。工具调用是可编排、可审计的节点，比纯提示词约束更可靠。
知识治理侧同样关键：Agent能检索哪些内容，取决于企业授权范围。悦问知识库支持按库设置可见范围和管理员，知识条目可设到期日期——保证Agent检索边界与企业审核边界一致，而不是默认读取全部内部文档。
为什么有效： 把"能不能答"前置到检索环节，而不是事后判断生成结果像不像编出来的。
适用场景： 所有希望AI只答已审核知识的场景，尤其是B2B多产品线、多库并存团队。
第三层：未命中必须兜底，禁止"不知道还硬答"
客户问得最直接：知识库外的问题，AI会自己总结答案，还是明确不知道并转人工？
正确做法是后者，且须写入流程规则：
触发条件 | 系统行为 | 禁止行为 |
知识库检索无结果 | 明确告知暂无相关信息，转人工或引导补充信息 | 自行推理、总结、猜测 |
检索置信度低于阈值 | 转人工或请客户确认问题 | 强行选用低相关条目作答 |
客户明确要求转人工 | 立即转接，携带已采集上下文 | 继续尝试AI回答 |
投诉、强烈不满、责任不清 | 按SOP转人工 | AI继续安抚或给建议 |
未命中兜底的关键，是把"停止生成"做成流程节点，而不是期望模型自觉。合力亿捷Agent Flow中的「转人工」是可编排系统工具——知识库未命中时，流程应自动调用转人工并传递上下文，而不是让模型继续生成。金融、医疗等高风险场景还需额外配置强制转人工规则，关注的不只是回答是否自然，还包括知识白名单、过期信息拦截和留痕审计。
为什么有效： "编答案"最高发在"未命中仍生成"。兜底规则把这条路径堵死。
第四层：分库分流，避免"查错库"
统一入口进来的问题类型往往不同——售前、售后、账单——若全部检索同一知识库，极易"语义相近但场景不对"地误召回。
正确做法：先识别意图，再路由到对应知识库或处理流程。
客户从统一入口进入后，Agent先判断属于产品咨询、订单查询还是投诉建议，再分别调用不同FAQ库或业务接口。悦问知识库支持新建多个库并分别设置可见范围；Agent侧通过Flow节点决定当前会话允许检索哪些库。
客户还常问：按"分类"还是"知识点"调用？实践上——分类管权限和隔离，知识点管检索和召回。分类决定"从哪个库查"，知识点决定"查哪条"。
为什么有效： 减少"检索到了知识，但不是这个场景的知识"导致的答偏。
第五层：上线后Badcase审计，把"编答案"变成可修复事件
约束框架不是上线一次就结束。须持续做三件事：
1. 抽样审核回复，标记"答对 / 答偏 / 应转未转 / 知识缺失"
2. 区分Badcase类型：知识缺口、检索偏差，还是流程漏洞（未命中没转人工）
3. 回流修正：缺口补入库，偏差调整分库或切片，漏洞修改Flow规则
AI没答上的问题能否记录？人工回答后能否反哺知识库？——没有这条闭环，"编答案"会在同类问题上反复出现。Badcase审计的结论，应直接回流到知识库更新和Flow调整两个入口，而不是只停留在运营周报里。
为什么有效： 把质量问题从"客户投诉后才知道"变成"运营可主动发现和修复"。
上线验收：六个必测场景
上线前用以下场景验收，不要只看Demo：
测试场景 | 操作方式 | 合格标准 |
知识库内标准问题 | 用FAQ已有问题直接提问 | 回答与知识条目一致，无额外编造 |
知识库外问题 | 问库里完全没有的业务问题 | 明确拒答或转人工，不自行总结 |
相似但不同场景 | 用易混淆两场景分别提问 | 各自命中正确知识，不串答 |
过期/矛盾知识 | 保留一条过期条目测试 | 运营侧已清理或系统拦截，不输出过期内容 |
实时数据问题 | 问价格、库存、订单状态 | 走接口返回实时结果，不读静态FAQ |
强制转人工触发 | 模拟投诉、明确要求转人工 | 按规则转接，上下文完整传递 |
四个常见误区
误区一：只在提示词里写"不要编造"。 提示词是软约束，检索为空时模型仍可能补全。须用流程规则（检索→判断→兜底）做硬约束。
误区二：把所有业务知识塞进一个库。 库越大、场景越杂，误召回越高。应按产品线、业务线或权限分库。
误区三：把实时数据写进FAQ凑合用。 数据一变，AI答得"有据可查"但全是错的——比编答案更难发现。
误区四：上线后不审计。 没有Badcase标记和回流，团队不知道AI在哪些问题上"编"了。
什么样的场景适合先做"严格知识库模式"
适合严格模式： 产品规格、政策解读、操作指引、标准化售前——答案有明确出处，错了代价高。
需要混合模式： 订单状态、物流跟踪、账户余额——知识库管规则，接口管实时数据。
必须人工兜底： 投诉、复杂纠纷、医疗诊断建议、金融合规咨询——无论知识库多完整，都应强制转人工。
优先从高频、标准化、低风险、可闭环的场景切入，验证框架有效后再扩展——不要一上来就对所有场景放开生成权限。
常见问题
Q：RAG是不是就能完全避免编答案？
A：RAG解决"有没有检索知识"，不能自动解决"检索错了怎么办"和"没检索到还生不生成"。RAG + 未命中兜底 + 分库分流 + 持续审计，才是完整方案。
Q：能不能让AI只复述知识库原文，不做任何改写？
A：可以配置更严模式，但代价是回复生硬、难多轮对话。更常见的做法是：允许基于召回内容组织语言，但禁止添加召回结果中没有的事实——检索与生成结果都须可审计。
Q：人工回答好的内容，怎么避免下次AI再编？
A：建立"未命中问题→人工回答→审核入库"回流流程。没答上的问题不应流失，应成为知识库下一条增量。
Q：怎么判断当前AI是在"按知识库答"还是"在编"？
A：抽一批真实会话，逐条核对：每个关键事实能否在知识库或接口返回中找到出处。找不到的，就是"编"或"答偏"，回到五层框架排查哪一层失效。
