95%智能体部署失败原因揭秘，圆桌讨论揭示常见陷阱

机器之心编译

在硅谷近期举办的一个圆桌论坛里，有一位嘉宾给出了这样一个数字，那就是，“95%的AI智能体在被部署到生产环境中时，均遭遇了失败的情况。”。

此论坛是由（一个关于企业家、投资者的社区）予以组织的，来自Uber、、和的工程师以及ML负责人参与到了讨论当中。他们持有这样的看法，多数AI智能体在部署之际之所以遭遇失败，并非是由于模型欠缺足够的智能，而是由于环绕它们的基础框架、上下文工程、安全性以及记忆设计尚未发展到成熟的阶段。

关于组织的论坛，其名称为「the:,AI,and」，就这样表述，是这样的形式，是这样的情况。

他们更进一步地指出，真正存在的差距是在于上下文工程，“大多数的创始人认定自身是在打造AI产品，事实上他们所构建的却是上下文选择系统。”成功的团队并非是在对提示词进行优化，而是在构建语义层，构建元数据过滤，构建特征选择以及构建上下文可观察性。就如同论坛上的一个比喻所讲的那样：“基础模型属于土壤，上下文才是种子。”。

的确，技术方面的挑战并非全部情况。就算系统于功能层面展现得毫无瑕疵，要是不能够追溯输出的源头，不能依规遵循权限的管控，不能使用户切实地信赖它去处理敏感数据，那么部署依旧会遭遇失败。有一位参与会议的人讲述了他妻子拒绝运用特斯拉自动驾驶功能的事情，并非是因为其不好用，而是源于缺乏信任。此问题在企业的AI智能体里同样是存在的。成功实现部署的那5%的智能体都具备一个共同之处，也就是人机协作的设计方式，让AI扮演助手的角色而非自主进行决策的主体。

这篇文章是由论坛主持人Oana所撰写，它深入对这次圆桌论坛的核心洞见展开了探讨，这核心洞见涵盖了从上下文工程的最佳实践、记忆架构设计、多模型编排，再到治理框架和用户体验设计，假如你正在构建AI产品、基础设施或者智能体系统，那么这些来自一线工程师的实战经验，也许能够帮你避开一些失败陷阱。

上下文工程，不是提示词黑科技

这场讨论中，几位嘉宾不约而同地提到：微调往往并非必要。

于多数场景里面，有一种构建好的RAG（检索增强生成）系统，它已然颇为高效——然而实际的情况是，绝大多数的RAG系统是太过粗糙的。

它们常见的失败模式包括：

那么，「高级的上下文工程」究竟长什么样？

上下文层参考资料：

1、面向 LLM 的特征工程

一位嘉宾提出了一个极具启发的框架：

把上下文工程看作 LLM 的原生特征工程（ ）。

这般意味着，那种上下文，其决然不再呈现为“字符串拼接”的样式，而是摇身一变，成为了一种具备可予测试特性的，同时拥有可进行版本化特质的，并且还能够予以审计的数据工件。

2、语义层 + 元数据层的双层结构

一些团队分享了他们的「双层架构」实践：

这种设计，能够于混乱的数据源，这数据源包含PDF、日志、音频、指标等之间，去建立起秩序，借此确保检索得来的结果，并非单纯、只是那种简单的「相似内容」，而是实实在在、真正意义上的「相关知识」。

换句话说，它让 AI 能理解语义，也能尊重结构。

3、text-to-SQL 的现实检验

问观众，当场上问「有谁把text-to-SQL做到生产环境里」时，一个举手的都没有，原因不是问题小，而是把自然语言稳定、可靠地映射到业务级查询极为困难，自然语言本身模糊、歧义重，企业术语常常有上下文依赖，「营收」在不同公司、不同团队的定义可能完全不同，「活跃用户」也是如此。

团队若取得成功，便不会硬是把存在于数据库里的内容，原封不动地给到模型，而后寄希望于模型能够准确猜对。他们所开展的是具备工程化特性的抽象以及专门的保护举措，其中涵盖了：

能够随时间提升理解的反馈循环可参见：

为什么「信任」与「治理」是核心问题

安全、权限、数据溯源这些词，在现场被反复提到。

这些并非是合规清单里所列出的那种需要被打钩认定的项目，然而却是人工智能系统得以落地实施过程当中的关键阻碍因素。

垂直领域创业者要注意做到以下几点：

要是有两名员工问了同样一个问题，那么AI给出的答案应当不一样，这是由于他们的权限存在差异，并且上下文也不相同。要是不存在这样的访问以及策略控制，那么AI给出的答案或许在技术层面是正确的，然而在组织层面却是错误的，会导致信息泄露，还会违反合规要求。

领先团队所采用的做法是，于结构化以及非结构化数据的统一目录里，嵌入入访问策略，此访问策略在索引阶段生效，且也在查询阶段生效，此处有括号（）。

信任方面的问题，并非属于技术范畴的瓶颈，而是关乎人性层面的瓶颈。有那么一位嘉宾讲了一个相关事情 ， 就是他的太太拒绝允许他去开自动驾驶汽车。这并非是由于自动驾驶本身不好用 ，而是源于她内心不信任。要是AI想要去处理涉及金钱 、医疗或者安全之类的关联决策 ，那么就必须要先后去赢得这样一种信任。那些真正迈向成功行列的占比为5%的系统 ，都存在着一个共同特有的地方：人机协同。AI是被规划设计成为助手性质的 ，而不是作为决策者 ；它能够被实施监督 ，能够被予以纠正 ，能够被作出解释。

记忆，不是功能，而是系统结构

每组团队皆宣称想要针对AI增添记忆，然而，那些切实通晓系统的人明了，记忆并非单一的某样事物，它实际是一项关联到用户体验、隐私层面以及系统影响的设计方面的决策。

记忆有三个层面：

绝大多数初创公司把记忆硬编码于应用逻辑或者本地存储之中，然而顶尖团队会将记忆加以抽象，使之成为一个「上下文层 + 行为层」的组合，这个组合具备可版本化以及可复用的特性。

他们的定义是：

记忆即个性化

在应用层面，记忆服务于两个目的：

有一个团队，分享了在Uber构建对话式BI工具的经验，冷启动问题是什么是呢因为用户不知道该问什么，解决方案那便是从用户的历史查询日志中构建记忆，然后推荐相关问题作为对话起点，就如同是一个记得你上次聊天内容的人。

但问题在于：有用的个性化何时会越界成为令人不安的监控？

一位参与会议的人描述，他朝着对方询问适合全家一起观看的电影推荐，随后，对方给出了针对他孩子具体情况的个性化提议。他对这个答案并不中意，说出了「你究竟为何对我的儿子以及女儿了解得这般清楚？别去触碰我的隐私」这样的话。

在设计时，你需要考虑：

这里少了一个关键原语，它是一个安全且可移植的记忆层，能跨应用开展工作，供用户使用，并非被锁定在服务商内部。当下还没有谁真正攻克了这个问题。有一位与会者讲，如果他不做当下进行的创业项目，那么这将会是他接下来的目标。

多模型推理与编排模式

另一个新兴设计模式是模型编排。

生产环境里，并非对全部任务都能调用GPT - 4。团队这般运行模型路由逻辑，有着越来越多基于的相关因素：

以下是一些可能的情况：

相比于网页应用路由，这与编译器设计更为贴近。并非仅仅是「发送给 LLM」，而是于异构模型、工具以及验证之间，运行一个决策 DAG（有向无环图）。

这点为何会如此重要呢？倘若你的系统运用量愈增加，其速度便愈发迟缓，或者费用愈发高昂，那么这便是首先得重新予以审视的层面。要是你期望 AI 于用户而言感觉毫无缝隙，那么路由便绝不能始终依赖脆弱的手工调配。你需要的是自适应策略。

某团队分享了其方法，简单问题交予小型快速模型，复杂推理任务路由至前沿模型，此处关键为，借由追踪哪些查询于哪些模型上可成功执行，模型选择这一进程自身会随时间推进持续学习优化。

聊天界面究竟何时才适用？

并非每一个任务都会需用到聊天机器人，有一位观众以直接方式去挑战了该前提是这样的：她表明自己不能确定自然语言始终是比图形界面更具优势的，要是她本人想去叫一辆Uber车的话，她并不想要对着手机去说话，她只求通过点击手机屏幕的方式，车就能到来了。

的确，不是所有任务都适合自然语言交互。

达成的共识为，是专家小组给出的，即当对话能够把学习门槛予以降低之时，它才会具有实用价值。

传统上，商业智能（BI）仪表盘、数据分析这类需专业知识才可操作的复杂工具，自然语言能降低其使用门槛。然而，一旦用户获取所需答案，往往更倾向于运用图形用户界面控件，比如把饼图换成柱状图，全然无需额外输入文字。

混合模式的核心逻辑是：

一位与会者列举了自然语言处理的两个理想应用场景：

关键的深刻见解所处之处在于此，那便是，咱们理应去领会人们运用自然语言展开交互的深层次缘由究竟是什么，并且应该依据这一核心的意图来开展设计工作，而绝不是把所有的交互都强行地套入到聊天的模式当中。

仍存在的缺口

会上提出了几个方向，这些方向尚未得到充分探索，而它们又是亟待产品化的核心基础能力，是这样的情况：

1、上下文可观测性

什么输入能够持续让输出效果得以优化？何种上下文类型会致使模型出现幻觉？怎样如同测试模型提示词那般去测试上下文？当下，大多数团队都处于盲目摸索状态，他们欠缺系统方法用以衡量哪些上下文对模型性能切实具有帮助，哪些反倒会带来负面影响。

2、可组合记忆

能不能将记忆归属给用户，而不是应用程序，以此来达成可移植性以及安全性？并且设置有可供选择的权限层级吗，去区分组织层面、团队层面还有个人层面的记忆状态？

这一设计能解决两个核心问题：

这是当前技术栈中最关键的缺失的基础能力。

3、领域感知型 DSL

企业用户需求，大多有着结构化以及重复性的特征。既然这样，那我们为何还一直执着于把自然语言解析成稳定性非常差的结构化查询语言也就是SQL，而不是去定义更为高级、受到约束并且安全的领域特定语言也就是DSL呢？

有的团队给出提议，表示与其去开发将文本转化为结构化查询语言的工具，倒不如构建有语义特点的业务逻辑层面之处，就像「将第四季度营收予以展示」这样的需求情况，应该直接对应到已经得到验证的计算流程那里，而不是去生成最初样子的结构化查询语言代码。

4、延迟感知型用户体验（UX）

有一位身为专家组成员的人，提及了一款具备记忆增强功能的聊天机器人，这款聊天机器人，其响应速度虽说比较慢，然而却能够给用户带来令人惊喜的体验，之所以会这样，原因在于，它能够依据用户上周所提出的提问内容，给出一连串智能的后续跟进内容。

“这一设计给异步且主动式人工智能的用户体验开拓了新的可能性，其应用场景并不局限于聊天功能。”“想象这样的情景：智能体在你开会之前就准备好简报，在你打开文档之时呈现相关上下文信息，或者在你主动询问之前，便提醒你数据里出现的异常状况。”。

核心洞见所在之处为其，不同任务对于延迟的要求方面存有分歧。其中一个笑话所要的乃是立刻做出反应，而深度分析哪怕耗费10秒钟也是可以的，只要能够在当下展示出进展情形并且展现出智能特性就行。

值得持续关注的方向

作者声称，在参与了这场专家小组讨论之后，她愈发坚信，即将迎来一阵基础设施工具的浪潮，这其中涵盖了记忆组件、编排层、上下文可观测性工具等。从事后角度去看，这些工具的出现好像是自然而然的，然而当下它们依旧处于一种杂乱且尚未得到解决的状况之中。

生成式人工智能领域往后一个实实在在的竞争壁垒，并非源自模型访问权限，而是会来自下述四个方面：

假定你身为一位正投身于基础设施开发、应用程序开发或者智能体开发的创业者所提出的疑问那指的是在你的产品路线图里究竟有多少内容是确切地瞅准这极为明确的，由四个不同方向所构建而成的框架去着手开展并推进的呢？

创业者必看：5 个需直面的硬核问题

即使你正着手去构建上下文系统，或者是智能体，也不妨去问问你自己这5个问题？

对于我的应用程序，其上下文的预算到底具多少？（理想状态下，上下文窗口所对应的规模究竟该多大？另外，我又是通过怎样的方式去优化其中的内容构成的呢）我的记忆系统，其边界究竟处于何处？（哪些记忆分别归属于用户层面、团队层面以及组织层面？这些记忆的存储位置又在哪里？用户是否能够查看这些记忆内容呢）我是否能够追踪输出的溯源信息？（当面临需要调试大语言模型的响应结果这种情况时，我是否能够确切地知晓究竟是哪些输入内容引发了该输出呢）我所使用的是单一模型还是多个模型？关于依据任务复杂度、延迟要求或者成本预算去分配路由请求，我是怎样做的呢 有没有用户会乐意将资金或者医疗数据托付给我的系统呢 要是不愿意的话 我的安全机制或者反馈循环里头还欠缺哪些关键的环节呢。

原文链接：