Dhivya Nagasubramanian，AI 转型和创新副总裁 – 采访系列

Dhivya Nagasubramanian 是一家主要的美国金融机构的 AI 转型和创新副总裁，她领导了生产级别的自治 AI 系统的设计、部署和治理。她是《Agentic AI for Engineers》（Apress/Springer Nature）一书的作者，这是一本关于构建可以在生产环境中被信任的自治 AI 系统的实用指南。自该书发布以来，它在 SpringerLink 上记录了超过 6,000 次机构访问，在全球 260 多个图书馆中有馆藏，并在各个大学中被采用。她是美国专利和商标局授予的应用机器学习专利持有者。她的研究兴趣包括构建能够抵抗对抗性 jailbreak 攻击的应用程序以及为开发更好的多文化安全和安全模型做出贡献。她是各个行业和学术会议中备受追捧的专家演讲者和小组讨论者。

您的职业生涯从企业咨询和数据科学发展到金融服务中的 AI 转型。这些经历如何塑造了《Agentic AI for Engineers》，以及您认为什么样的反复出现的差距 giữa AI 研究和企业部署说服您需要撰写这本书？

我从 2008 年开始，通过构建银行平台的投资组合核算和业绩衡量系统。其中一个项目是为金融机构开发了一个符合 GIPS 标准的时间加权回报率引擎，后来在 80 多个国家的金融机构中被使用。这个工作教会了我一个将在我整个职业生涯中发挥作用的经验。在受监管的金融领域中，最危险的失败是看似正确的错误数字。一个微妙地不正确的计算会被信任、报告和采取行动多年，因为看起来没有什么问题。

我后来又一次看到同样的模式。当我发现一个被广泛使用的营销归因模型的马尔可夫模型中存在结构性缺陷时。该框架被数十万用户使用，错误之所以能够存活这么久，是因为输出看起来合理。当我转入金融服务中的 AI 转型时，我看到自治系统以更高的赌注重复这种模式。一个代理不仅仅产生错误的结果，它会根据结果采取行动。

说服我撰写这本书的差距是，研究和企业部署关注的是不同的事情。研究通过基准衡量能力。企业依赖于系统在模糊性、不断变化的数据和对抗性压力下如何表现。大多数关于代理的写作都停留在演示阶段。我为需要在受监管的机构中部署系统的工程师撰写了《Agentic AI for Engineers》一书，他们必须对系统的行为负责，即使在有限的监督下运行。

您的书描述了从自动化到自治的转变是一种新的工程思维方式。真正区分自治 AI 代理和复杂自动化工作流程的因素是什么，以及组织最有可能在哪里混淆这两者？

我给团队一个简单的测试。你可以在运行系统之前列出系统可以采取的每条路径吗？如果可以，你有自动化。它可能是非常复杂的自动化，里面包含语言模型，但它仍然是自动化。如果系统在运行时根据上下文分解目标、选择工具并决定操作顺序，你就有自治。区别与使用的模型无关，关键在于决策的位置。

组织在两个方向上都混淆了这两者，但只有一个方向是昂贵的。将脚本化的 LLM 工作流称为代理主要是一个营销问题。代价高昂的错误是相反的。团队在为确定性自动化设计的治理下部署真正的自治决策。他们的测试假设可重复性，他们的监控假设已知的故障模式，他们的审计跟踪假设每个操作后面都有可追溯的规则。对于代理来说，这些假设都不成立。

这就是我在书中提倡的思维方式转变。对于自动化，主要问题是系统是否正确执行。对于自治，问题变成了系统是否做出了正确的决定。回答这个问题需要不同的仪表、不同的评估方法和更高的谨慎。

许多代理 AI 系统在演示中表现出色，但在面对真实用户、不断变化的数据和不可预测的工具时却苦苦挣扎。生产就绪的代理体系结构中应考虑哪些组件是强制性的？

诚实的答案是，生产需要演示可以跳过的一切。在演示中，环境是受控的。在生产中，这种控制被剥夺了。

在书中，我描述了一种七层次的参考架构，但以下组件我认为是强制性的。具有类型化输入和显式权限的工具合同，代理的范围由设计限制，而不是希望。可以在中断和故障后存活的状态管理。具有明确定义的升级路径的结构化故障处理。连续运行的评估工具，而不是仅在启动前运行一次。以及记录决策和决策背后的理由的审计跟踪，而不仅仅是采取的行动。

团队最常跳过的组件是运行时验证。这是一个检查每个操作是否与代理的声明目标和适用的策略相符的层。标准基础设施告诉你调用是否成功。验证询问是否应该进行调用。它永远不会在演示中证明其价值，因为在演示中没有什么需要被捕获。在生产中，它是你最希望拥有的第一件事。

您的书涵盖了安全性、对齐、反馈循环、测试、调试、评估和部署。工程团队应该如何将这些元素组合成一个连续的保证过程，而不是将安全性视为最终的预发布审查？

最终审查依赖于系统在审查时的状态不会改变的假设。对于代理 AI，这个假设以三种方式失败。底层模型会更新。代理依赖的工具和 API 会改变。代理操作的数据和环境会不断变化。一次性的安全审查描述了一个不存在的系统，几个月后就不再存在了。

连续保证意味着关闭循环。行为评估在 CI（持续集成）中运行，就像单元测试一样，并且每次对提示、工具和模型的更改都阻塞。运行时监控将生产跟踪反馈到评估集。我在书中描述了四种监控模式，因为没有单一模式可以涵盖整个故障表面。每个事件都会产生新的检查，就像每个 bug 都应该产生一个回归测试一样。对抗性测试也会定期运行，而不是仅在启动前运行一次。

组织方面与技术方面一样重要。安全性不能是一个单独的团队在最后出现，带着一个清单。构建代理的工程师应该拥有评估套件、不变量和升级设计的所有权，因为他们比任何人都更清楚系统的判断在哪里最弱。

您强调了代理工具调用的语义监控。语义监控揭示了什么，传统日志和可观察性工具无法揭示，如何检测代理在技术上运行良好但追求错误目标时？

传统的可观察性回答了一个问题：调用是否成功？它涵盖了状态代码、模式、延迟和错误率。但是，它无法回答代理最重要的问题，即调用是否应该发生。工具调用可以在技术上完美，但仍然是错误的操作。正确的格式、有效的凭据、成功的响应，错误的操作。

语义监控评估每个操作是否与代理的声明目标和适用的策略相符。在书中，我将其描述为在代理工具调用上定义语义不变量。这些是必须在代理采取的任何路径上保持的属性。研究一个客户案例的代理永远不应该访问该案例以外的记录。代理应该标记一个超过一定阈值的差异，而不是自行解决。当不变量被违反时，你在操作时捕获问题，而不是在季度审计中。

这也是检测目标漂移的方式，我认为这是代理系统的定义性故障。目标漂移看起来像一个代理，它按照日志正确完成每个步骤，但在不知不觉中朝着错误的目标努力。它永远不会出现在日志中，因为没有什么失败了。语义监控将意图作为直接测量的东西，并且意图是代理出错的地方。

当代理遇到模糊的指令、冲突的政策、不可用的工具或不充分的信心时，结构化的故障处理应该是什么样子？开发人员如何确保系统暂停、升级或恢复，而不是即兴发挥？

要设计的問題是，大多数代理只有一个结束任务的方式，即产生答案。当指令模糊或政策冲突时，代理即兴发挥。不因为模型鲁莽，而是因为即兴发挥是架构允许的唯一行为。结构化的故障处理意味着为系统提供更好的选择，并使其比即兴发挥更容易到达。

在实践中，这意味着拒绝和升级与成功一样经过精心设计和测试。我建议定义类型化的故障状态：模糊的指令、冲突的政策、不可用的工具、不充分的信心。每一个都映射到特定的行为。提出一个澄清问题。将上下文完整地交给人类。降级到只读操作。重新尝试更严格的限制。或者停止。信心阈值应与特定操作的风险相匹配。内部摘要的门槛和客户账户的门槛永远不应该是相同的数字。

两种做法使其成为现实。首先，在设计快乐路径之前设计升级路径。如果人类将接收到交接，决定他们将获得什么上下文以及他们将拥有什么权限，然后再编写第一个提示。其次，以与测试功能相同的方式测试故障。在分段中注入模糊的指令。禁用工具。在代理中注入冲突的政策。从未练习过故障的系统将在生产中第一次发生时毫无指导地运行。

金融机构必须在实验和严格的隐私、可审计性、模型风险和监管合规性要求之间取得平衡。人类批准应该保持强制性的地方在哪里，以及代理可以安全地被授予更大的操作自主权的地方在哪里？

我的规则是，人类批准应该保持对任何不可逆转的操作、移动资金或影响患者结果的操作、涉及具有监管重量的客户沟通的操作、为监管报告提供信息的操作或更改代理自身工具、策略或权限的操作的强制性。代理可以在读取和推理工作中承担更多自主权：研究、检索、文档分析、分诊、草拟和对人类审查员标记差异而不是解决它们的对账。

常见的错误是要求每一步都需要人类批准。这并不使系统更安全。这重现了手动流程，并在每一步添加了额外的步骤，并训练审查员对其进行核准。批准应该在真正的决策点，并且应该由真正有权说不的人员担任。批准不应该频繁出现，每个批准都应该由具有实际权威的人员担任。

另一个原则是，自主权应该是通过努力获得的，而不是被授予的。从狭窄的范围开始，随着系统在监控下证明自己而扩大。保存证据。在模型风险方面，控制环境应该让你能够向监管机构展示不仅代理做了什么，还有为什么你被证明有理由授予它这种程度的独立性。这种记录是真正的操作许可。

通过您的工作在人工智能保障和标准方面，您正在帮助为其能力不断演变的系统定义规则。哪些保障措施可以在今天标准化，哪些领域仍然过于依赖于上下文、行业或用例？

我们今天可以标准化的保障措施是结构性的。它们要求某些控制存在、被记录并且可以被检查。自治系统的能力和权限边界的文档记录。定义明确的人类监督和升级机制。事件检测和报告义务。评估方法和证据要求。系统生命周期中的明确责任制，以便当出现问题时，答案从来不是仅仅是 AI。这些可以标准化，因为它们关注的是控制的存在和质量，而不是具体的值。

我们还不能标准化的是设置本身。特定的信心阈值、危害分类法和适当的自主权水平严重依赖于上下文。用于营销内容代理的可接受故障容忍度和用于触及临床或财务决策的系统是不同的。它们属于不同的政权，受到领域、管辖权以及谁在故障时承担损害的影响。

金融控制是一个有用的模型。审计要求在全球范围内标准化，但重要性始终根据上下文判断。尊重这种区分的标准往往被采用。试图规定上下文相关值的标准往往被忽略，安全标准如果没有人遵守，就不会保护任何人。

您的最近研究探讨了多文化和对抗性鲁棒性在 AI 安全评估中的应用。西方中心或全球平均基准可能会错过哪些类型的模型故障，以及企业如何评估旨在多文化部署的系统？

仅查看平均基准可能会错过最重要的故障。模型可以在总体安全评分上表现出色，同时在特定语言、方言或文化背景下表现糟糕，因为这些故障会消失在平均值中。西方中心的评估增加了另一个盲点。它忽略了特定于文化的危害，例如成语、手势和宗教或区域背景下相同输出无害但在另一种文化中有害的上下文。它还低估了代码切换、音译和非西方名称和实体的测试。还有一个对抗性角度。攻击者不会针对平均性能。他们找到最弱的切片，对于大多数模型来说，这个切片是一个低资源语言或一个低估的文化背景。攻击者会找到这个切片并针对它。

这就是我被吸引到多文化 AI 安全基准研究的原因。核心发现很简单。跨文化评估安全性需要来自这些文化的评估数据和人类判断。您无法从发生的背景之外评估危害。

对于企业，我建议三个规则。评估您服务的每个细分市场。永远不要接受平均值作为证据。从实际客户群体中构建评估集。在客户使用的语言中运行对抗性测试。如果您为 40 个国家提供服务，但只在英语中评估，您已经为别人的部署衡量了系统的性能。

您还拥有美国专利和商标局授予的应用人工智能专利。您试图解决什么问题，专利过程教会了您关于将人工智能研究转化为实际创新的什么，并且您最感兴趣解决哪个未解决的代理人工智能挑战？

最近批准的专利解决了金融服务质量审查中的规模和一致性问题——传统的呼叫审查是手动的，因此人类审查员只能抽样一小部分呼叫，他们的评估也会因人而异。我的方法将每个质量和合规性问题路由到最适合回答它的方法，并记录每个决策以备审计。

您可以在整个采访中看到我一直在描述的相同主题。将每个任务路由到能完成它的最不强大的工具。保持人类在判断力很重要的地方的参与。并使每个自动化决策可追溯，因为在受监管的机构中，没有证据的答案就不是答案。

专利过程教会了我，学科的严谨性在于具体细节。你不能专利一个模糊的想法。你必须展示你的方法与众不同之处在哪里，以及它的应用范围。这种精确性使底层工作变得更好。

我现在最关心的未解决挑战是多代理系统的运行时验证。为单个代理定义语义不变量是可行的，因为我们在生产中这样做。但是，当代理将工作委托给其他代理时，行为变得出现象，故障转移到了交接处。指令在每个步骤都被稍微重新解释。一个政策适用于一个代理，但不适用于它招募的代理。验证代理之间的交互，而不仅仅是每个代理的操作，这就是我期待下一代沉默故障出现的地方。这就是我想下一步解决的问题。

感谢这次精彩的采访，读者也可以考虑订购她的书《Agentic AI for Engineers》Agentic AI for Engineers。