引言
大多数测试人工智能客户支持功能的公司都会遇到同样的瓶颈。系统最初能正常运行数周，随后却会向某位客户给出一个看似自信却完全错误的答复——可能是关于退款时限的，也可能是关于上季度刚变更的政策。一旦有高层注意到这一问题，原本计划覆盖大部分待处理请求的部署，便会在仅处理了其中一小部分后悄然搁浅。
行业数据印证了这种模式的普遍性。OpenText、Capgemini和Sogeti联合发布的《2025年世界质量报告》显示，对于60%的受访组织而言，可靠性和“幻觉”问题是阻碍AI应用的首要障碍。Gong的另一项研究发现，58%的企业已暂停AI项目，且近一半的计划AI投资因信任问题而非预算问题而受阻。 这些工具本身是行之有效的，但人们对它们的信心却滞后了。
一个错误答案背后的数学原理
客服工作具有某种不对称性，这种特性使得将“平均准确率”作为评估指标会带来负面影响。一个正确答案可能只节省几分钟时间，而一个错误答案却可能批准本不该发放的退款、编造出根本不存在的政策，或是做出未经任何人授权的承诺。当一个错误带来的负面影响超过一百个正确回答带来的正面效益时，以平均情况为优化目标就完全是错误的。
还有一种更隐蔽的代价。一旦客服主管发现AI出错一次，此后就会对所有内容进行复核，这会抵消掉本应节省的大部分时间。信任并非按每次对话来评判的。它要么逐渐积累，要么彻底崩塌；一旦崩塌，即使系统大多数时候都是正确的，团队也会停止信任它。
“幻觉”不会消失，只能加以管控
即便是最强大的语言模型，在特定条件下也会编造内容，而实际数据比大多数人想象的要高。在基于上下文的摘要生成任务中——这本质上与根据自身帮助文档回答问题相同——Vectara的幻觉率排行榜显示，顶尖模型的幻觉率约为3%，而众所周知的旗舰模型则集中在6%至15%之间。 一些推理密集型模型在同一任务中的幻觉率甚至超过 20%，因为更深入的推理使它们有更多空间提出源文本从未提及的论点。若让模型处理缺乏依据的开放式问题，数据表现会更糟。斯坦福大学的研究人员发现，当未提供源文档时，领先模型在绝大多数具体法律问题上都会产生幻觉。
这并不意味着任何特定模型表现不佳。这意味着，任何单一模型若单独使用，其可靠性都不足以在没有监督机制的情况下直接服务于付费客户。
智能与控制背道而驰
单个模型无法独立解决这一问题，这背后存在结构性原因。随着系统在处理模糊或陌生案例方面的能力增强，其行为也变得更难完全预测——因为正是那种使其能够处理未被预先编写脚本的案例的推理能力，有时也会将其引向不该去的地方。 能力更强的模型并不一定意味着更安全。正是这种权衡关系，使得可靠性必须作为一层保护机制围绕模型构建，而非单纯指望模型自身就能提供。
Aissist采用四层技术而非单一方法来应对这一挑战。提示工程（Prompt Engineering）设定了每个任务都必须遵循的基础规则，这在代理系统中尤为重要——在该系统中，单个客户请求可能会扩展为十多个子任务，而所有子任务都必须遵守相同的防护规则。 “增强”步骤会将不确定的决策多次运行，并保留大多数代理一致认可的答案，尽管这会消耗额外的计算资源。“自我检查”环节要求系统在任何结果传递给客户之前，先审查自身的输出，或将其交由扮演不同角色的第二个模型进行复核。而位于所有层之上的“分层治理”层，会在输出或行动发布前检查其是否符合政策，其功能与其说是过滤器，不如说是整个系统的监督者。
正是这种组合，使该平台将AI错误率控制在1%以下——这一数字值得关注，主要是因为该领域的供应商中，几乎没有哪家会公布这一数据。
判断何时不应作答
客服代理最宝贵的特质并非正确回答更多问题，而是能够识别哪 些问题不应独自尝试解答。一个能尽早将棘手的账单纠纷上报并附上完整背景信息的系统，造成的损害远小于那个贸然猜测并强行推进的系统。这也正是“仅描述解决方案”的客服代理与“实际执行解决方案”的客服代理之间的区别——后者会调取订单、进行修改，并向客户确认结果。
可靠性需要持续维护，而不仅仅是建立起来
一个在上线当天准确无误的系统，若无人持续监控，其准确性便无法长久维持。产品会变化，政策会更新，客户提出的问题也会随之发生变化。持续监测能将这种变化作为数据捕捉，而非等到投诉浪潮涌来才应对；而严谨的评估、测试和发布周期则能不断弥补发现的漏洞，且在任何变更真正生效前，仍需由人工最终审核确认。
在信任供应商之前，究竟该检查什么
任何声称其人工智能绝不会出错的供应商都应引起怀疑，因为这通常意味着没有人进行足够细致的监测来验证其准确性。值得认真对待的供应商会公布错误率，详细说明如何在客户察觉之前发现错误，并坦诚说明系统在何种情况下会将任务移交给人工处理，而不是让系统凭猜测行事。这与“相信人工智能”的宣传口号截然不同，也是当实际工单量激增时真正经得起考验的做法。
