
第一次搭建知识库时,最容易出现两个问题:资料没有整理就直接导入,或为了尽快覆盖全部问题而忽略边界。结果通常是条目很多,但AI仍然不知道该用哪一条。
下面按实际操作顺序拆解,从确定范围开始,到小范围上线和复盘结束。
一、用二十个高频问题启动
第一次搭建可以先选近一个月最常见的二十个问题。每题保留买家原话、最终正确答案、适用条件和人工边界。用另一批历史会话测试,不合格的问题先不上线。这样得到的是一个小而能用的知识库,而不是一批未经验证的文档。
二、搭建过程需要留下这些交付物
| 步骤 |
交付物 |
通过标准 |
常见返工原因 |
| 确定范围 |
首批场景和不处理清单 |
店铺 语言 商品范围明确 |
一开始想覆盖所有问题 |
| 整理资料 |
有效来源清单和版本 |
每条内容可追溯 |
直接导入旧话术和整份手册 |
| 拆知识 |
单一问题条目和适用条件 |
相近问题不冲突 |
一个条目塞入多个场景 |
| 测试上线 |
真实问法测试集和结果 |
正确回答 追问与转人工均符合预期 |
只用标准问题测试 |
资料整理和知识编写不要混成一步。先确认事实与版本,再把内容改写成买家问题和处理条件,能显著减少后期因为来源错误而反复返工。
三、确定首批上线范围
先选择一到两个答案稳定的场景,例如商品基础信息和常规发货说明。列出暂不自动处理的问题,尤其是退款、赔偿、争议和特殊价格。范围越清楚,后续测试越容易判断是否达到上线要求。
四、上线前核对这些设置
| 配置环节 |
具体做法 |
验收标准或边界 |
| 集中整理原始资料 |
收集商品页、政策文档、物流说明、FAQ和经过确认的客服话术。 |
删除重复文件,标记店铺、市场、商品和更新时间。无法确认来源的内容先放入待核实清单,不要因为过去有人使用就默认有效。 |
| 建立知识分类和字段 |
按照商品、物流、售后、活动和平台规则分类,并为每条内容设置适用对象、条件、答案、例外和更新时间。 |
分类服务于查找和维护,不宜按员工姓名或临时文件夹组织,否则人员变化后很难继续管理。 |
| 把长文拆成可判断条目 |
将一份政策拆成买家可能提出的具体问题,每条回答只处理一个主要意图。 |
条件和例外要与结论放在一起。若答案依赖订单状态或商品型号,应先要求系统读取数据或向买家追问。 |
| 配置检索和转人工边界 |
确认AI能够依据店铺、语言和问题类型选择正确知识。 |
对信息不足的问题设置追问,对高风险条件设置停止自动回复并转人工。兜底回复应说明下一步,而不是循环发送同一句无法处理。 |
| 建立真实问题测试集 |
从历史会话中选取标准问法、口语、错别字、多轮追问和异常场景。 |
记录预期答案、允许的表达差异和必须转人工的条件。每次更新后重复运行同一测试集,才能判断修改是否真正提升质量。 |
| 小范围上线并观察 |
先选择少量店铺或低风险问题上线,观察未命中、人工改写、重复追问和错误转人工。 |
发现问题后明确是知识、规则还是数据连接造成,再分别修正。不要在质量尚未稳定时同时扩展店铺和场景。 |
五、建立更新和下线机制
明确谁负责提交内容、谁负责复核,以及什么情况需要立即更新。商品停售、活动结束和政策变更时应下线旧知识。保留版本记录,方便出现争议时确认当时AI依据的是哪一版内容。
六、开始配置前先确认三件事
- 确定首批上线范围:先选择一到两个答案稳定的场景,例如商品基础信息和常规发货说明。
- 集中整理原始资料:收集商品页、政策文档、物流说明、FAQ和经过确认的客服话术。
- 建立知识分类和字段:按照商品、物流、售后、活动和平台规则分类,并为每条内容设置适用对象、条件、答案、例外和更新时间。
七、相关阅读