客服知识库中的 AI. 客服知识库中的 AI 是一个内部检索工具，客服人员用大白话向它提问。它一次查询就搜遍历史工单、产品文档和政策，返回一个答案，并附上来源出处。它坐在客服人员背后，客户始终在和真人对话。
你的客服人员有一半的班次花在翻文档上。这是你在自己团队里值得留意的抱怨。答案总在某个地方：一张旧工单里，一份产品规格里，或一份自一月起就没人打开过的物流政策里。找到它，如今成了工作本身。
为什么我的客服人员有一半时间都在翻找文档？
因为答案分散在互不相通的系统里。退款规则在一份政策 PDF 里，打破这条规则的例外情况埋在 2023 年一张已结案的 Zendesk 工单里，产品行为写在一位已离职产品经理留下的 Confluence 页面里。客服人员遇到一张复杂工单，得查三个地方，猜哪个是最新的，然后祈祷猜对了。
客服知识库中的 AI 具体做什么？
它对你的工单、产品文档和政策建立索引，让客服人员用大白话提出一个问题，得到一个答案。答案会链接到它出处的具体文档和段落，客服人员点一下就能核实。它是内部工具，客户永远接触不到，也依然和真人对话。
有出处的答案才是关键。一个没有来源的答案，只是客服人员还得再核实一遍的猜测。一个链接到出处段落的答案，客服人员点一下就能确认成事实，再复制粘贴进回复里。我们把每一个答案都绑定到它的出处文档，原因就在这里。
首次响应时间会有什么变化？
为便于说明，假设有一支中型电商客服团队，并非真实客户。一个能用一次查询检索过往工单、产品文档和物流政策的检索工具，对难处理的工单帮助最大，也就是客服人员过去要打开六个标签页才能动笔的那种。处在这种位置的团队，会在上线前后分别衡量复杂工单的首次响应时间。
简单工单本来就很快，比如重置密码、查询订单在哪。拖慢速度的是那些需要政策特例和过往处理记录的复杂工单。缩短这类工单的检索时间，平均值就会动。客服使用场景页面有这套设计的完整形态。
如果你从自己的客服主管口中听到这句话，那就先从检索层入手，再考虑任何回复工具。
这不就是一个面向客户的聊天机器人吗？
We are
我们构建的检索层坐在你的客服人员背后，由真人阅读附有出处的答案、核实它，再用自己的语气写出回复。
We aren't
我们不构建那种自己独立回答、指望在已经不高兴的客户面前把政策答对的面向客户的聊天机器人。
面向客户的机器人把模型放在了你的品牌和一位生气的客户之间，一个错误的退款答案在那里就是一次公开的失误。检索工具则退后一步：客服人员拿到附有出处的答案，客服人员做判断，客服人员回复。风险最高的环节始终由真人把关，模型只负责那些单调乏味的翻找工作。
客服人员看到的是什么
- 一个用大白话提问的搜索框，不是关键词填空。
- 一个答案，同时取自工单、文档和政策。
- 每个答案都附有出处，链接到来源段落。
- 客户永远接触不到它，这是一个辅助客服人员的工具，不是聊天机器人。
这套工具直接读取你未经整理的历史资料——一份 PDF 格式的发货政策，一条以对话串形式存在的已结案工单，一页 wiki 形式的产品文档。它不需要你先把这些内容清理或重新整理一遍。这正是检索工具相对于手动搭建另一套知识库、再永远维护它保持最新的优势所在。我们在期刊里写了更多类似的构建案例。
如果你的客服人员翻找的时间比回答的时间还多，我们应该先摸清你的知识究竟藏在哪里，再谈要不要构建什么。预约一次 30 分钟摸底通话，我们会一起过一遍你的工单、文档和政策，然后告诉你检索层能在哪里改善首次响应时间，在哪里起不了作用。
