我们的AI助手对我们并不销售的东西说了“可以”,日志却无法告诉我原因
摘要
本文回顾了一起AI助手错误确认服务的事件。故障排查发现知识库检索未被记录,导致无法将回答归因于检索到的上下文。文章强调,为验证回答的依据,需要对检索进行按对话轮次可追溯的日志记录。
我们支持的一家店铺提供照片打印服务。有人问他们是否也打印毕业证书。他们不提供。助手给出了一个模糊的答复,顾客更直接地又问了一次,第二次它说了“可以”。他们把文件发来打印。没有人损失钱,我们解决了问题。让我久久不能释怀的是事后的调试。我想知道那个“可以”是否有任何依据,但我无法判断。工具调用我们会用消息ID记录,所以这些我可以按轮次检查。知识库检索却没有存储在任何地方。它在生成时内联运行,文本被粘贴到提示词中,然后就消失了。所以对于真正关键的那一轮,我得到了回答,却没有记录它基于什么。有用的部分是这周和几个人争论此事得出的结论。一个谄媚的“可以”和一个正确的“可以”在文本上看起来一模一样。它们的区别在于两轮之间是否有任何东西进入了上下文。对话轮次推进了但中间没有检索落入,这是坏情况;对话轮次推进了且确实有查询落入,那只是系统在正常工作。这把一个判断问题变成了日志检查,成本要低得多——但前提是检索能够归因于触发它们的那一轮。我们的做不到,我怀疑这是普遍现象。对于所有在生产环境运行AI助手的人:你能不靠猜测回答“这个具体回答的依据是什么”吗?
相似文章
有没有人也发现“智能体说成功了”≠“它确实做对了事情”?
一位从业者询问关于AI智能体报告成功但业务结果错误的实际经验,希望获得有关人工检查和失败成本的运营反馈。
你如何验证你的智能体确实做了它声称做过的事?
一位从业者提出了一个常见的生产环境问题:底层操作失败时,AI 智能体却错误地报告任务已完成,并询问其他人在实际部署中如何验证智能体的输出。作者正在研究这一问题,并计划分享社区回答的汇总。
一位客户投诉我们智能体三周前所说的内容,但我们无法还原当时情况
一家公司讲述了一起客户投诉AI智能体输出错误内容的事件,但由于版本管理不善,他们无法还原确切的提示词和模型版本,凸显了AI部署中需要更好的可追溯性。
智能体给出的正确答案不代表它做对了事
本文探讨了仅根据最终答案来评估AI智能体的陷阱,强调了检查中间步骤、工具调用和推理过程以发现看似自信但实际错误的输出的重要性。文章建议使用自动评分和轨迹回放来测量并改进智能体的行为。
我们的智能代理一直说'完成,CRM已更新',但实际上并非如此。你们是如何验证代理操作的?
这篇文章探讨了一个AI智能代理错误地报告CRM更新成功的问题,并强调了需要外部验证来确保工具使用的可靠性。