摘要: 想象一个AI系统,它可靠运行9999次,却在第一万次时,毫无征兆地“伪造”了数据。这不是科幻,而是制药巨头GSK在构建AI Agent时的真实遭遇。本文将以这次惊心动魄的“万分之一”故障为引子,深入探讨在充满不确定性的LLM时代,企业应如何构建一套“纵深防御”体系,来确保AI Agent的可靠性,并从中提炼出可供所有开发者借鉴的可靠性工程实践。
引言:从“能用”到“可靠”,AI工程化的最后一公里
AI Agent的能力令人兴奋,但其内在的“不确定性”也让每一位负责将其推向生产环境的工程师夜不能寐。传统的软件测试方法,在面对LLM的概率性输出时常常显得力不从心。当一个Bug无法稳定复现,甚至其产生的原因都难以解释时,我们该如何建立信任?
GSK的AI和机器学习全球负责人Kim Branson分享的一段经历,为我们揭示了问题的核心:
他们初期构建的一个SQL智能体,在运行了“1万次”后,莫名其妙地出现了一次数据“造假”。Branson回忆道:“我们再也没遇到过,但那一次发生时,我们甚至不明白为什么会在该LLM上出现。”
这次事件,如同一声警钟,促使GSK建立了一套极为严苛的可靠性保障体系。他们的经验,以及Block在金融领域的实践,共同构成了一本宝贵的企业级AI Agent可靠性工程指南。
一、 GSK的“纵深防御”:构建信任的三道防线
面对Agent的不可预测性,GSK没有寻求单一的解决方案,而是构建了一套环环相扣的“纵深防御”体系。
防线一:并行冗余与交叉验证 —— “永远不要完全相信单一模型”
这是GSK保障可靠性的核心战术。他们认识到,任何单一模型都有其固有的偏见和潜在的“幻觉”风险。因此,他们的标准操作是:
-
并行运行:让多个不同的模型或同一模型的多个副本,同时执行完全相同的任务序列。
-
交叉验证:由人类科学家比对不同Agent的输出结果。如果结果一致,则信任度高;如果出现分歧,则立即触发人工审查。
这种方法,本质上是用计算资源的冗余,换取结果的确定性。对于普通开发者而言,这意味着在关键业务上,可以考虑引入一个(或许更廉价的)模型作为“陪审员”,对主模型的输出进行二次验证。
防线二:建立贴近实战的“内部靶场” —— “只相信自己场景下的测试”
许多团队在测试模型时,过度依赖公开的学术基准。GSK的经验表明,这是一条歧路。
-
问题所在:Branson指出,公开基准往往“相当学术化,不反映我们的实际工作”。一个在通用问答上得分很高的模型,可能完全无法理解复杂的生物学问题。
-
解决方案:建立自己的内部基准。GSK的团队会生成大量真实的生物学问题,并由专家团队创建和评分“黄金标准”答案,然后用这个“内部靶场”来持续评估和排名他们的Agent。
这对开发者的启示是:花时间构建一套能反映你真实业务复杂性的高质量评估集,其价值远远超过在任何公开排行榜上刷分。
防线三:拥抱失败的“主动学习”文化 —— “错误是最好的学习资料”
最关键的一环,在于对待错误的态度。GSK并非致力于打造一个“永不犯错”的系统,而是打造一个“从错误中快速学习”的系统。
“我们特别关注智能体出错或出现愚蠢行为的情况,因为那正是学习新知识的机会。”—— Kim Branson
这种文化意味着:
-
日志与监控:详尽地记录Agent的每一次“犯错”,分析其上下文和决策链。
-
反馈闭环:将这些失败案例转化为新的测试用例,加入到内部基准中,或者用来对模型进行微调。
-
人类专家介入:在关键环节强制引入人类判断,不仅是为了“兜底”,更是为了利用专家的知识来理解和修复系统的深层问题。
二、 Block的补充视角:流程中的“人工断路器”
在风险同样极高的金融科技领域,Block的实践为我们提供了另一种可靠性保障的思路——在流程中设置“人工断路器”。
Block的AI技术主管Brad Axen强调,在金融服务中,代码必须**“可靠、合规且安全”,因此,尽管Goose框架能生成约90%的代码,但最终“仍需人眼审核”**。
这个“人眼审核”环节,就是一道关键的“人工断路器”。它承认了AI在效率上的巨大优势,但坚守了在质量和安全上的最后一道防线。它告诉我们,在某些场景下,最可靠的策略,不是追求100%的自动化,而是在自动化流程的关键节点,设计一个高效、强制的人工校验环节。
结论:可靠性不是可选项,而是AI Agent的生命线
从GSK的“万分之一”故障中,我们可以看到,企业级AI Agent的落地,是一场从“可能性艺术”到“可靠性工程”的深刻转变。
总结一下,我们可以提炼出以下核心工程实践:
-
引入冗余:使用多模型并行验证,不要迷信任何单一Agent。
-
构建实景靶场:用自己业务的真实数据和问题来衡量你的系统。
-
建立学习循环:将每一次失败都视为改进系统的宝贵机会。
-
设置人工断路器:在关键流程中,保留人类专家的最终审核权。
对于每一位致力于将AI Agent投入生产的开发者来说,在追求更强的智能、更酷的功能之前,请先扪心自问:我该如何设计我的系统,才能确保在第一万次,甚至第一百万次调用时,它依然值得信赖? 这个问题的答案,就蕴藏在这些先行者的可靠性工程实践之中。

被折叠的 条评论
为什么被折叠?



