晚上八点十分那会儿，有个患者在小红书上面刷到了咱们门诊发出去的科普笔记，直接发私信问了一句“你们这边能看胃病吗”。不过前台早就下班了，压根没有人去回复。第二天人家直接去了另一家。
像这样的咨询情况，一家中等规模的门诊一天怎么也得有个二三十条，下班以后提的问题能占到三成。以前这事儿只能依靠人工守着，要是守不住那就只能白白流走了。
我们前前后后花费了两年时间，才把这件事从“靠人守着”变成了“让系统接住”。前半程基本上都在开展知识整理的工作，选用的工具是 AISet；到了后半程才谈得上让 AI 去直接回复患者。中间还经历过一段挺难堪的日子，AI 明明已经上线了，算下来的账反而更贵。今天打算把整个过程完整地写一遍，也包括那些不太好看的部分。
一、先自己做半年客服
门诊的咨询工作最早全是依靠我自己来接。微信、电话、小红书私信还有大众点评留言，一共四个口子，一天弄下来得花费两三个小时。这个状态前前后后持续了大半年。
我劝所有想做 AI 客服的人，都先自己去接一段时间试试。你得亲手感受一下患者到底卡在哪里。哪些话你解释了三遍他还是搞不明白，哪些问题他真正想问的跟字面上问的压根不是一回事。这些可都是后面所有工作的原料。
中间我们也尝试过把咨询交给前台和兼职去弄，效果都不怎么样。前台一忙起来就开始敷衍，兼职又搞不懂医生专长上的区别，患者要是问“你们哪个大夫看胃病好”，她只能回一句“我们张医生和王医生都看”。这句话说出来等于没有回答。
半年之后规律就出来了。翻来覆去也就是那几件事，哪个医生擅长什么、需不需要排队、哪天出诊、怎么预约、这个检查得花费多少钱。高频问题基本上很稳定，要是继续让人一条一条去回，既浪费时间也没有办法持续下去。
有人可能会问，你们本来就是做 AI 的，怎么不一开始就把系统弄上去。原因其实很简单，那时候手里没有语料。这半年真实的对话攒下来，患者原话是怎么问的、我们过去又是怎么答的、哪些答案后来改过口，全都留着呢。这批东西才是知识库真正的地基。
第一版的能力边界划得特别窄。产品问题凭借知识来回答，故障和建议先登记下来再转给人工，闲聊就自然应对一下，答不上来的问题先留着后面再补。
医疗场景还得多划几条线出来。不能承诺疗效，不能说“吃了肯定好”；不能给出诊断结论，患者描述症状问“我是不是胃炎”，只能建议来院检查；不能在依据不够充分的时候硬答。
AI 客服最要命的地方就在于一本正经地胡说八道。患者才不会去管这是模型幻觉还是知识没检索到，他只会认定这家门诊给了错误的信息。在医疗场景里面，这个错误的代价比电商可大得多。所以第一版的原则定得特别死，宁可少回答，也绝不乱回答。信息不够那就继续追问，要是超出范围就直接转交给人工来处理。
二、知识整理这一步，没法偷懒
多数人做知识库的时候，最先关心的往往是模型选哪个、向量库选用什么。真做过就会体会到，最耗费时间的一定是把知识整理干净这一步工作。
门诊知识的来源主要包含两个。其中一个依靠人工进行整理，涵盖了出诊安排、医生专长、项目价格、检查前注意事项、中西药冲突禁忌，并且还包含明确不开展的服务范围。另外一个则是历史咨询记录，也就是微信里面留存的那几千条对话。
前者相对比较系统，不过没法覆盖患者真实的问法。你写上"脾胃调理"，患者问的却是"吃凉的就拉肚子能治吗"。后者倒是贴近实际，可内容极为散乱，同一件事前后能给出三个版本，同时还夹杂着大量针对某个人的特殊处理情况。
AISet 在这里可谓是帮了大忙。它本身是个本地 AI 写作知识库，我们借助它的聊天记录技能把微信咨询记录导出来，扔进原始资料目录，让它每十段会话提取一批有效问答，开展去重、合并工作，然后再按主题写成知识页。原来散落在几十个人手机里的东西，这样一来一周就理出了主干。
真正耗费时间的还在后面。同一个问题历史上给过不同的答案；某个项目去年不支持今年却上线了；前台为了让一位老患者消气，破例答应过一次免费复诊。这些都不能不加以分辨就直接变成正式知识。
最后必须由懂业务的人过一遍才行。他清楚哪句还有效，哪句必须修改，哪句只对特定情况成立。知识页上留下来源、适用范围和更新时间，将来要是两条知识打架，处理起来就会容易很多。
整理时还要提前把分块想好。我们选用 Markdown 按标题组织，再按层级拆分成知识块。这里最重要的一条，每一块必须能够独立看懂。要是写成"支持，操作和上面一样"，拆出来就是废的；只写"这个暂不支持"，不说明是哪个项目哪个版本，同样没法用。
有个坑我们踩过，也见别的团队踩过。有人为了提高召回率，让模型把一个问题改写成五个问法，再把五组"问法加答案"分别存进去。看着覆盖面变广了，结果患者一问，召回的前五条全是同一份答案，只是问法不同，分数还都挺高。真正有用的知识反倒被挤掉了。
要是仅仅去看有没有命中，可能会觉得效果还挺好。
把召回列表打开逐条进行查看，这时候才发现知识压根就没有找全。
多个问法是可以保留的，不过得把它们挂在同一条知识的下面，召回之后凭借知识 ID 来开展去重工作。
技术层面我们并没有去搞多么复杂的东西。
知识原文、分类、状态还有审核信息都存进数据库里面，向量索引则是单独存放一份，两边凭借 ID 进行关联。
检索的时候先拿到 ID，然后再回到数据库去把原文取出来。
原文跟索引分开来存放，这样一来以后要是想更换检索引擎也会比较方便。
知识一旦发生了修改，索引就必须得跟着进行修改。
要是后台显示已经改了、AI 却还在运用旧答案，这种事情只要发生一次，前台就再也不敢去相信这套系统了。
三、有了知识，AI 照样答错
知识整理完毕，客服并不会自动就变得准确。
患者这句话究竟是什么意思、应该去走哪个流程、拿哪几条知识来作答，这中间全都是问题。
我们最开始仅仅划分了两个类别，也就是咨询和闲聊。
很快便发现这样压根就不够用。
患者往往还会提出像是"你们那个报告怎么打不开"、"能不能加个周末门诊"之类的问题。
这些情况显然不能仅仅回复一句"感谢反馈"就草草了事，而是必须去收集相关信息、开展分类登记工作，并且还要转交给院办还有技术部门去进行处理。
于是我们把一级意图扩展到了三个类别，涵盖产品咨询、患者反馈以及闲聊。
咨询类借助知识检索来推进，反馈类则开展信息收集与登记工作，闲聊类就保持自然交流。
门诊场景下还是应当保留些许人情味，毕竟患者本身就容易紧张，要是给出硬邦邦的回答，只会使得他们变得更加犹豫不决。
仅仅给模型提供三个标签显然是不够用的。
我们又分别从业务侧还有患者视角梳理了一遍，进而合并得出了二级分类，像出诊安排、医生专长、价格、预约流程、报告解读、用药安全、投诉、故障、建议等，并且针对每一类都制定了明确的判断标准。
举个容易混淆的例子。
"怎么关掉复诊提醒"属于使用咨询，而"为什么一直没收到复诊提醒"就极有可能是故障。
这两句话虽然都提到了提醒，但后续的处理流程却完全不同。
另外还有指代消解的问题。
患者要是先问"你们张医生是看什么的"，紧接着又问"他周三在吗"。
要是直接拿第二句去执行检索操作，大概率是找不到结果的，真正应该去检索的其实是"张医生周三是否出诊"。
所以我们在意图识别前面增加了一步指代消解操作，凭借历史对话把"他""这个""那个"还原成为具体的对象。
要是前面出现过好几个医生实在难以判断出具体指代，那就继续追问，千万别替患者去猜测。
上下文究竟带多少同样是个让人头疼的麻烦事。要是带少了，前面提及的关键信息就会丢失掉；要是带多了，不仅响应速度会变慢、Token 消耗变多，还会把一大堆无关紧要的内容给混进去。我们采取的处理方式是把最近几轮的原文保留下来，至于更早的对话则异步压缩成摘要，仅仅保留事实、诉求以及尚未解决的问题。
不过挂号状态、缴费结果这类信息可不能仅仅依赖摘要。在需要办理业务的时候，必须去对系统开展查询工作。患者上次说没收到退款，并不代表现在依然还没到账。
检索不能仅仅依靠向量
向量检索确实擅长对语义相近的内容进行寻找。比如"对胃病有没有用"和"能不能改善胃部不适"，字面上看着差得远，但表达的意思其实是一回事。
可要是患者明确询问"你们的腹针"、"碳14呼气试验"时，专有名词就显得极为重要了。要是仅仅凭借语义相近性，极有可能把另一个项目的说明给捞出来。因此我们增加了一路关键词匹配，随后再把两路的结果进行合并。
检索路数一多，重复以及弱相关的内容也就跟着变多了，所以必须开展融合、去重以及重排操作。首先按照不同列表当中的排名来开展融合工作，接着运用重排模型对候选内容进行细排，最后再把真正需要的那两三条内容挑选出来。
这些组件各自都有其用处，但并非每一个问题都得把全流程走完一遍。患者要是问"周三几点开门"，直接查询就能给出回答，根本没必要先让模型去扩写出五条问题。步骤一旦加上去，效果未必会变得更好，但调用的费用却是实打实往上涨的。
这里还得提一件特别容易让人产生误解的事情，那就是置信度。向量相似度、重排分数，还有模型自己输出的 confidence，这三样东西的含义完全是两码事，没有任何一个能够被当作是"答案正确的概率"。我们早期选用过 0.5 的阈值，那仅仅只是当时的试验设置罢了，要是换一套模型和知识库，就得重新开展验证工作。谁要是把这个数字当成真理，谁就会在一堆错误的答案里表现得自信满满。
生成回答要有兜底
知识召回以后，我们让模型再进行一次判断，看看这些资料到底够不够用来对患者提出的问题进行回答。输出里面增加了一个字段，要是够就正常回答，不够就返回一个否定的结果，同时把这个问题送进待处理池里面。
模型做出的这个判断本身也是会出错的，但至少那些答不上来的问题被记录下来了，后面还能够开展复盘工作。
反馈和建议则是走另外一套逻辑。患者建议的功能要是已经有了，就告诉他们应该怎么运用；要是没有，再看看符不符合门诊的定位，属不属于明确不做的范围。可以评估的就进行登记，但是不承诺具体的时间。
故障处理方面也是一样的道理。得先询问清楚情况，然后再去建立相应的记录。只有后台确实写入成功了，才能够去告诉患者"已经记录并且反馈"。不能仅仅只是在回复文本里面把这个动作演一遍，系统里面却什么都没有。这种事情要是被患者发现一次，信任就彻底没了。
四、从回答问题到走完整套流程
前面说的这些都还只是问答环节。真正把成本降下来的，是让系统能够把一件事完整地办完。
患者真正问的话其实是长这样的。"我妈上周查出尿酸 520，你们能不能调？她一直在吃降压药，我怕冲突。"
这时候光找到"高尿酸调理"那条知识是远远不够的。系统得识别出这是在替家人询问，得知道母亲是不是已经建过档，得看看她正在吃的降压药和我们要开的方子有没有冲突，要对这个尿酸值属于观察还是需要干预来进行判断，然后再决定是继续追问、直接约号，还是转给医生。最后还得把预约真的写进排班系统里面去。
一个熟练的前台看似仅仅只回了三句话，背后却已经完成了信息理解、档案查询、用药核对、规则判断还有系统操作。
所以想要复刻这个前台，光把她过去的聊天记录导出来是远远不够的。还得知道她为什么查这些东西，为什么这样进行判断，什么时候会把问题推给医生。
这也是所有 AI 小工具往下走的时候一定会撞上的墙。AI 帮前台查询到了资料，生成了回复，然后呢。前台还是得看一遍，还是得进行判断，还是得打开后台把信息录入进去点击提交。每笔业务照样得等人去操作，整条流程的人效就不会有根本性的变化。
后来我们做的事情，是把完整的流程拆进系统里面，让前后的步骤能够接得上。
这种场景我们优先选用固定流程，而不是放开的智能体。哪些步骤必须做、缺什么信息继续问、满足什么条件才能够执行、失败了去哪里，全部由程序显式控制。模型负责理解患者千奇百怪的表达，程序负责已经写死的条件校验，工具负责查询和执行操作。不是每个节点都需要大模型重新思考一遍的。
为啥不直接上 Agent
不少人肯定会问，眼下通用智能体都已经这么厉害了，怎么不拿来运用呢。
自主规划这东西当然是有其价值的。可是对于路径早就明确的高频流程来说，要是每次都让模型重新去想一遍下一步该干什么，那只会带来调用次数的上升、延迟变长以及不确定性增加。在生产环境里面，我们其实更加看重稳定、成本还有可控性。要是业务压根不需要那种自主性，就没必要为了架构看起来漂亮而硬加上去。要是真碰上处理路径没法提前敲定的任务，到时候再引入带有边界的智能体，那也完全来得及。
我们在免疫检测那边做得还要更加彻底一些。早期的时候我们也尝试过把流程文档给拍平成向量，只要检索到一段内容便让模型去进行改写输出。但很快我们就发现，流程文档绝对不是普通文本，它自身是带着决策结构的。就拿一个检测结果出现异常的场景来举例说明，文档里面写的是先去核身，接着再去查看报告明细，要是样本质量问题那就走话术 A，临界值需要复检那就走话术 B，要是客户情绪激动了就触发转人工。像这种链路，单纯依靠检索的方式是没法把它给拍平的。你或许能够捞出来一段话术，然而却并不清楚前面还需要核身，也不知道后面该按照哪个字段去选分支，更无从知晓哪些词汇是绝对不能说的。
后来我们就改成把每一个场景都封装成一个能力包，一个包里面同时必须写明白这个场景究竟是什么、跟相邻场景该怎么进行区分、哪些表达应该被触发、哪些表达又必须排除掉、是否需要进行核身、去查哪些工具、工具输出的结果要填入到哪句话术里、分支条件是什么、哪些表达属于禁用范围、什么时候该升级去转人工。这绝对不是一块简单的知识碎片，这是一整包的业务决策。目前那个系统已经登记了 55 个这样的包，覆盖到了 11 个业务域。
至于选平台还是自己去写代码，也得视实际的需要而定。要是平台能满足了那就直接运用平台，要是需要进行深度定制再去写代码。我们自己来开展在线问答和知识加工的维护工作，凭借现成的工作流去清洗会话记录，就是这么分工的。
五、蜜月期，然后是 AI 独大
系统刚上线初期那会儿，我们并没有敢直接让它去面对患者。先是开展常见的咨询和查询，把答案推荐给前台，交由前台来决定到底用不用。随后才从百分之一的真实流量开始，小心翼翼地让它进行直接回复。
这个阶段的效果是极其容易就能够看见的。过去前台必须在十几份文件里面去翻找答案，现在几秒钟就有建议摆在那儿供参考了，反馈也还挺不错。
但只要问题牵涉到具体的患者档案、需要进行修改信息，亦或是出现了规则之外的情况，系统的不足之处便暴露出来了。所以我们保留了人工审核，AI 的回复先交由前台看一眼，确认没问题之后再发出去。
这也就是典型的副驾模式了，同时也是人和 AI 的蜜月期。
前台每一次的接受、修改、驳回，都留下了极具价值的样本。究竟是哪两条知识在打架，哪类问题缺少数据，哪些建议几乎每次都能直接拿来用，哪些场景总是要重新写，这些统统都能够从这里看出来。
不过麻烦也就随之而来了。以前前台自己判断自己回复，现在必须先去看 AI 的建议，判断到底靠不靠谱，有问题再去进行修改。等到 AI 表现不稳定的时候，审核反而把工作量给增加了。
于是乎 AI 就这么给推上线了，人力方面的成本并没有如愿降下来，反而还额外多出了一笔调用模型的费用开销。这可以说算是所有 AI 项目当中最为危险同时也最容易被大家伙嘲笑的一个阶段了。我们那阵子最为害怕听到的一句话便是“你这搞的还不如我自己来回弄呢”。
等到积累了一批数据以后，我们便开始凭借场景的风险程度以及成熟度来开展放权工作了。那些验证比较充分、规则也很明确的场景就把它们放进自动处理的白名单里面，而复杂的例外情况以及高风险的则继续交由人工来进行处理。
AI 也随之获得了两类新的能力。一类是查，也就是查看档案、排班、缴费以及报告进度；另一类则是写，也就是在权限允许的范围之内对一部分信息做出修改，借助调用接口的方式来触发预约。
在放权之前我们其实做过人机对照方面的测试。前台照常开展处理工作，AI 则在背后同步跑上一遍，仅仅留下日志却并不让其生效。这套影子系统主要是借助它来对能力进行验证的，真实的写操作必须得做好隔离工作。总不能前台刚提交了一次预约，AI 紧接着又去提交一次吧。
那段时间的感受可以说是非常直接了，Token 确实消耗了不少，可是效率并没有同步跟着涨上来。因为人和 AI 都在干活，AI 干的那一遍主要还是为了进行验证工作。
团队内部的关系也随之发生了改变。之前 AI 是在帮前台减轻负担，现在却开始接走工作了，大家对于岗位、考核以及责任自然都会产生不少的想法。负责人不得不花费大量的时间去进行解释以及协调工作。这些管理层面的成本，在做演示的时候是看不见的，可等到真正落地的时候全都是要还的。
有阵子不知道该干什么了
原本以为技术和管理方面的问题处理完毕之后，效率就该提起来了。结果团队却进入了一段迷茫的时期。AI 已经做了不少的功能，但是它究竟会些什么、不会些什么、下一步最值得去做些什么，却变得越来越说不清楚了。
于是我们重新整理出来了一张场景地图。
要是按照售前售中售后去分类那就太粗略了。挂号改期、报告解读、用药咨询、退费申请、投诉处理、复诊提醒，这些必须继续往下进行拆解才行。每个场景都得把患者意图、前置条件、所需数据、业务规则、要借助调用的工具、风险等级、成功标准以及转人工条件给写清楚。
等这张表一出来，团队这才又有了共同能够进行讨论的东西。本周去开展哪个场景，缺的到底是知识还是接口，做到什么样的程度就可以放量了，这些全都能说明白。
几个月的时间下来，系统已经覆盖了七成以上的客服场景，同时还承接了接近一半的真实流量。
这两个数字可千万不能把它们混在一块儿来用。
场景覆盖说的是能够去处理多少种类的问题，而流量接管说的则是实际承接下来了多少的请求。
至于这些请求里面究竟有多少是完全不需要人工介入、真正得以解决的，还得单独去开展评估工作。
场景的数量同样也代表不了业务量的大小。
几十个长尾场景加在一块儿，可能都没有一个高频场景的咨询量来得多。
所以后来我们就优先去做那些高频的、标准的、风险可控的，做完之后真正能够把人力释放出来的那些场景。
六、AI 还是比人贵
重新回到开头那个反常识的问题上来。
AI 干了这么多的活儿，为什么综合成本依然还要比人工来得高呢。
只要把账单摊开来看一看就明白了。
首先就是建设方面产生的费用。
产品设计、研发工作、知识整理、场景运营以及系统对接，全都需要人去完成才行。
传统前台流程已经跑了十几年了，成本早就摊薄了，而 AI 客服却还在补充基础设施，研发上的投入可是当下实打实正在花费出去的。
接下来要说的就是双重成本的问题。
许多场景目前还停留在审核以及接管的阶段，AI 先去理解、查询并且生成，然后人还得再去审核一遍。
这样一来就导致同一张工单会同时把模型和前台的时间给消耗掉。
绝对不能因为 AI 参与进来了，就觉得人已经退出这个环节了。
复杂的调用其实也没有想象当中那么便宜。
识别意图、补充信息、选用工具、读取结果、检查风险、生成回复，处理一笔业务可能要调用好几次模型才行。
上下文要是越长，工具越多，重试变得越频繁，那么费用自然也就跟着越高。
另外还有一点，省下来的工时并没有转化为省下来的支出。
AI 虽然接住了一部分流量，但排班、外包以及人员安排并没有发生相应的变化，账面上的人工成本也就不会自己降下来。
而且剩下那些交给人去处理的问题往往更难，同样不能按照流量比例去折算人力。
最后还得把持续维护的成本考虑进去。
价格会发生改动，医生会更换科室，流程要进行调配，指南也会更新，模型和提示词修改完毕后还得重新开展评测工作。
系统哪怕做成了，依然需要一支队伍来养着它。
我陪跑到了那个阶段，后来又去了解了具体情况，综合下来的成本依然没有完全优于人工。
这件事情其实是很难圆过去的。
负责人固然可以讲长期价值、讲发展趋势、讲扩展性，但当前成本高就是高。
账单里面除了前台的人力开销，又加上了产研、运营以及模型的费用。
不过这并不代表项目本身没有价值。
前台人数不再严格跟着咨询量一起涨，避免了扩招、减少了加班、把关键的人员从重复回答里面释放出来，这些统统都是收益。
但这些收益得分别去进行核算，绝不能全部包装成已经省下来的工资。
真要去进行比较的话，就得在业务量还有服务质量比较接近的前提之下，把建设分摊、运行费用、人工兜底以及返工统统都算进去，最后再来看每个真正得以解决的问题到底花了多少钱。
要是仅仅只盯着一次模型调用的价格，这笔账永远都算不清楚。
七、成本怎么降下来
从这些问题出发的话，我会先去查看整张工单，而不是急着去更换便宜的模型。
哪些地方该运用贵的模型、哪些地方选用便宜的，这本身就是要开展设计工作的。
先把人工的重复动作给找出来
患者发过来一句话，前台就得去看一次；AI 给出了一个结果，前台又要去确认一次；进入下一步，前台还得再去点一下。
整条链路要是都这样的话，模型哪怕便宜一点确实也省不了多少人工。
对于验证充分的场景，要逐步把不必要的逐条审核给取消掉，让系统能够把业务往下推进。
高风险的问题保留关键确认环节，信息收集、数据查询以及材料准备可以先交由系统去完成。
这里还得把任务状态记录下来。
现在正在处理的是哪位患者，已经收集到了什么信息，还缺什么，刚刚执行过哪个动作，下一步是什么，统统都要存下来。
要不然每次都从聊天记录重新去理解一遍，既费 Token，又非常容易导致重复追问、重复操作。
工具调用同样需要对结果进行检查。
创建预约要是超时了，不一定是没有创建成功，也有可能仅仅是结果没有返回来。
得先查清楚然后再决定要不要重试，千万别让同一位患者被约上两个号。
把不需要的调用给拿掉
针对那些十分明确的问题直接开展检索工作即可，没必要全部都去走多路改写的流程；要是查排班直接去查接口就行，不用围绕着同一个结果反复进行推理；至于固定的规则选用程序来进行判断就好，也不必每次都让大模型重新去解释上一遍。
比较稳定的项目说明确实可以进行缓存处理，但是一定要跟知识库的版本一块儿进行更新才行。而那些涉及患者档案以及相关权益的信息，绝不能够仅仅因为问法比较相似，就把原本属于别人的答案拿过来直接套用。
上下文的处理也是同样的道理。不管是意图识别、检索还是回答环节，都不需要每次都把一模一样的完整材料给带上去。当前这个节点到底要解决什么问题，就只给它提供相关的信息就够了。
模型怎么选
项目刚起步那会儿，我们一般都会先挑效果表现更出色的模型来开展验证工作，等分类标准、提示词还有整体流程都稳定下来了，再去考虑从成本角度进行替换。当时我们还拿国外最强的那几款模型做过效果参考，并且也对多款国产模型开展了测试，最后把效果跟成本综合起来考量，选定了中档位的一款模型。
像简单的分类任务、表达组织还有复杂的判断逻辑，其实可以运用不同的模型来进行处理。不过拆分得也不是越细就越好，要是拆成了一长串的串行节点，延迟情况还有调用的次数反而都会跟着往上涨。
换成便宜的模型之后，还得继续盯着人工接管率还有返工率这些指标。要是每次调用确实省下了几厘钱，却把更多的问题给推回给前台人员，那么总体的成本可能反而会变得更高。
人的分工也得变
当AI把标准化的业务接管过去以后，人的工作重心就会转向异常情况的处理、高风险环节的审核、知识的维护还有新场景的建设工作。这些活儿依然非常重要，并且同样也是需要花钱的。
团队得去看实际到底减少了哪些工作内容，排班该怎么去进行调整，有没有减少加班情况、减少外包投入或者避免了新增招聘名额。绝不能一边还保持着原先的所有安排，一边却又指望着账单能够自动变小。
而且也真没必要去追求什么百分之百的自动化。有些出现频率低、逻辑复杂、维护成本又很高的场景，直接交给人来处理反而更加合适。自动化的范围要是再扩大一点究竟要花掉多少建设成本、又能释放出多少人工来，这笔账必须得单独去算清楚才行。
八、看不见的地方最要命
AI客服比较麻烦的一点就在于，它可能并没有报错，并且正常给出了回复内容，但是患者的问题实际上并没有得到解决。要是只看最终给出的回答，真的很难分辨清楚到底是意图识别搞错了、知识没能成功召回、知识本身存在缺陷，还是模型明明拿到了正确的知识却没有运用对。
所以我们从早期阶段就开始把关键节点给记录下来。像患者的原话、指代消解的结果、意图的判断、问题的改写、召回的列表、重排的结果、最终选用的知识内容、模型的回复，还有每次调用所耗费的时间跟产生的费用，统统都要记下来。
等到了医疗业务当中，还得接着去记录查看了哪份档案、命中了什么样的规则、调用了哪个工具、执行到底成功没成功、为什么会转给人工、还有人工最后是怎么开展处理工作的。
凭借这些日志，团队才能够开展具体的讨论与拆解工作。这条需要进行知识的补充，那条需要对检索逻辑进行修改，还有一条其实是因为接口本身不具备相应的处理能力。要是没有这些依据，那么所有问题到最后都会变成一句"模型不够聪明"，这样一来也就只能来回不停地对提示词进行调试了。
答不上来的问题怎么留住
最初的知识库肯定是不完整的。我们会把那些检索匹配度不够或者模型判定资料不足的问题，全部都给送进待处理池里面去。
首先得开展标准化工作。患者要是讲"我在外地，医保是老家湖南的，能不能在你们这儿刷，不行的话我就回去看了"，咱们就得把它整理成"异地医保能否在本门诊直接结算"。要把口语还有那些无关紧要的内容去掉，不过会影响答案的条件得保留下来。
相似的问题得合并到一块儿，把出现次数记录下来，然后再让人去进行审核。得看看这算不算正常的业务问题，现有的知识有没有已经覆盖到，到底值不值得去进行补充，还有正式答案究竟是个啥。
AI 能够协助做整理工作、给个草稿啥的，但绝不能让它自己瞎编一个答案就直接弄进库里。等到审核通过了之后，再去补充正式知识、把索引更新一下，并且还要拿原来那个问题来验证上一遍。
也不是说所有的问题都值得留下来。乱输入的那种没啥必要留，时效性特别强的得把更新成本考虑进去，低频问题就得看风险咋样了，不能光因为问的人少就一律给丢掉。
这其实就是最初的知识循环，看着挺朴素的，但一定要有人持续去做才行。在门诊这个事儿上，咱们选用 AISet 承担了大部分工作。它把待处理池里面的那些问题按照主题给归拢起来，对照着已有的知识页把缺口给找出来，生成草稿等着人去终审，通过之后写回到知识库并且把索引更新好。前台只需要每个礼拜花上一个小时做判断就行，再也不用去手动搬资料了。
后来要补的不只是知识
系统碰到的那些失败情况，有的是缺业务数据，有的是缺规则，还有的是明明知道怎么处理却没有对应的工具。这些都应该进到一个待建设场景池里头，不能一股脑全塞回知识库。
团队得去判断这个场景的频率、价值还有风险，把缺的能力给补上，准备好正常、异常以及边界样本，借助评测之后，再去进行小范围放量。上线了之后还得接着看错误率、转人工率还有最终解决情况，要是有了问题就把权限收回来重新改。
到了这个阶段，大家才不会笼统地去讲"本周优化准确率"，而是能够说清楚本周到底要提升哪几个场景，每个场景缺了些啥，达到啥样的标准才能进行自动处理。
伴随着场景变得越来越多，提示词维护、数据清洗、调试回放、评测还有监控工具也会跟着逐渐长出来。最初靠着几张表就能管过来，到了后面每个场景都有了自己的规则、工具还有放量状态，就需要专门的系统来提供支撑了。
结语
沿着这些实践往回看，一套完整的门诊 AI 客服大致上需要七层能力来作为支撑。稳定的知识加工、准确的意图理解、混合检索加上兜底、能真正去执行的工具、凭借风险来分级的放权机制、贯穿全链路的日志，以及持续去进行补漏的知识循环。
转人工尤其不能光把对话转过去就算完事了。已经收集到的信息、做过的操作、失败的原因，都得一块儿转交给前台，这样一来就能避免患者重新讲一遍，也能避免人工把 AI 做过的事再去做一次。
医疗场景还有一条底线得守住。AI 干活，医生拍板。它可以帮忙整理资料、生成话术、提醒复诊、核对用药禁忌，但绝不能替代诊断。合规审核必须得放在验证流程里头，不能等出了问题再去进行补救。
顺带提一个反面的案例。我有个在放射科工作的朋友，他们科室三年前引入了一套 AI 阅片系统，用来协助医生开展肺结节筛查工作。起初大家挺激动的，觉得能够节省不少时间。后来却发现 AI 给出的结果需要医生逐条去进行确认，遇到可疑的还得医生自己去重新看一遍片子。时间方面并没有节省下来多少，反而是多出了一道复核的工序，AI 倒变成了增加额外工作量的源头。他跟我讲，要是结果能够直接进入到诊断报告里面，把可疑的地方标出来让医生重点去看，那样才算是真正有用。目前的系统还做不到这一点。
这个例子其实说明了一个事情，咱们缺乏的从来都不是更加聪明的模型，而是场景方面的融合。一个独立运行的 AI 就算能力再怎么强，要是没有嵌入到真实的工作流里面去，那就只能是起到锦上添花的作用，甚至于会变成一种额外的负担。
另外还有一件很容易被大家忽略的事情，那就是知识库是会慢慢烂掉的。医生调换科室了，收费价格进行调整了，沟通话术变得过时了，要是没有人去持续不断地进行更新维护，知识库就会变成一个摆设。很多项目最终走向失败，并不是因为技术层面不行，而是压根就没有人去开展运维工作。千万别指望着一次建设好就能永久使用下去。这笔维护所需要的成本必须在立项的时候就算进去，要不然上线的那一天也就是它开始腐烂的那一天。
所以说客服团队绝对不能全部裁减完毕。必须要保留下来一批对业务比较熟悉、并且愿意参与到建设当中来的人员，由他们持续不断地去处理各种例外情况、补充相关知识以及验证新的应用场景。
要说 AISet，它在这整套体系里头的角色定位是相当清晰的。它并不是那个直接跑去跟患者开展对话沟通的客服，它其实是给客服提供弹药支持的源头所在。那些四处散乱的咨询记录、早就过期的价格表，以及医生脑海里头那些很难讲明白的判断标准，全部都在这里被梳理整合成了能够单独看明白、带着来源依据、带着更新时间的知识内容，随后再打包封装成一个又一个可以直接开展调用的场景包。
数据这事儿真没有什么捷径可走。模型的能力一年比一年强大，价格同样也是一年比一年低廉，然而你自己的患者究竟会怎么提问、你的医生又会怎么回答、你的规则到底是怎么制定的，这些唯有你自己才能够整理出来。谁要是先把这一步的工作给做完做好，谁就可以率先获取到相应的收益。
