8.0
热点
AI SCORE
技术实践2026-10-06 13:46
AI 指令遵循失效的深层原因：语义理解≠可靠执行
dev.to · AI#AI原理#LLM#Agent
Editor brief · 编辑速览
AI 能理解语义但指令执行不可靠，探讨了语义能力与行为约束的差异，提出更可靠地设定约束的方法。
本文探讨为何 AI 助手及相关 AI 系统会表现出看似「不听话」的行为，解释语义理解为何不能保证可靠的指令执行，审视重要约束和事实性需求如何能被更可靠地强制执行，并为使用 AI 系统时设定合理的预期提供指导。
关键词：AI 助手、大语言模型、LLM、指令执行、约束、行为对齐、语义、理解、行为、软件工程、不变性、Agent 提取流水线、检索增强生成、RAG、工具调用
语义能力不能保证可靠的指令执行。
使用现代 AI 助手最奇特的体验之一，就是看着它们在一些对人类来说几乎微不足道的指令上失败。考虑一个简单的请求："审查这个编程脚本，但将所有现有注释原样保留。"指令是清晰的，几乎没有歧义。人类程序员通常会立即理解边界："审查或修改代码，但将现有注释视为只读。"然而 AI 助手可能会确认收到了指令，明确表示理解，然后仍然修改了注释。为什么会这样？
问题不一定是 AI 没能理解文字。现代 LLM 可以高级别地处理词汇、上下文和多种形式的自然语言含义。它们在许多领域理解语言的能力已大幅提升，尽管表现仍不均衡，尤其是在歧义、专业化或高风险任务上。更深层的问题在于，理解指令和可靠地执行它是两件截然不同的事。模型可以理解请求，但仍然以不满足用户预期目标的方式响应。
这并不意味着 LLM 不能表示或遵循约束。指令执行是现代模型专门训练执行的能力。问题在于可靠性：模型可以在许多例子中成功遵循约束，但无法提供传统软件所能提供的确定性保证。
因此重要的区别在于：模型能概率性地执行的的能力与周围系统能独立于模型强制执行的保证。
AI 助手的行为由其习得参数、后训练、当前上下文以及周围系统提供的指令和约束塑造。它默认不提供传统软件所能提供的同等级别的显式、外部可验证的约束机制——例如，将文档的某些部分以编程方式标记为不可变、而其他部分可编辑的表示。
当被要求改进代码时，模型可能已经学习了将代码改进与改进文档、格式和注释强烈关联的模式。那些习得倾向有时会与显式的用户约束冲突。
考虑以下交互：
AI 助手："我理解你的明确指令。我将保持所有注释不变。"
人类用户："很好。请继续修复脚本。"
AI 助手：工作了 3.2 秒
AI 助手："好的，这是你更新后的程序。我还更改或删除了一些注释。"
上述第一条声明听起来像是一个承诺。但严格来说，那条声明本身是由模型生成的。它证明模型在当前上下文中表示了该指令，但并不是后续输出将满足所述约束的独立保证。
人类听到指令可能会建立一条简单的心理规则：注释 → 不碰；代码 → 可以修改。
语言模型可以在上下文中表示这样一条规则，并可能成功遵循它。然而最终产物是通过模型的推理过程生成的，指令通过其习得参数和当前上下文间接表示。这个过程本身并不提供确定性保证，确保特定约束会被保留。
除非周围软件提供独立强制的限制，否则无法保证模型在生成修订文件时会保留注释。
同样的区别更广泛地适用。模型可能理解用户想要什么，但其他目标会影响其行为。安全策略、系统指令、产品约束和其他优化目标可以重定向响应。平台级策略可以独立于声明的用户意图运作。产品和服务的设汁可能引入超出即时任务的目标和约束，例如安全要求、成本限制、速率限制、功能可用性或工作流要求。
实际模型行为由几个超出用户直接请求的层次塑造。
1. 训练数据 + 微调编码了习得的模式和偏好
训练数据包含事实信息、惯例、偏见和人类判断的混合。后训练过程可以强化helpful、安全、拒绝和指令执行等行为。这些习得行为反映了模型开发者做出的选择，通常不能仅通过用户指令在每个对话中覆盖。
2. 部署约束添加了强制的操作层
速率限制可以根据使用量、容量或账户级策略限制访问。功能门控可以根据账户层级、产品配置或可用性限制功能。当需要访问特定服务或能力时，认证要求可能中断工作流。架构和基础设施决策在单个对话之外建立。
3. 业务逻辑位于所有表面交互之下
产品设计可以引导用户朝向特定的工作流或能力。商业决策决定不同价格点提供哪些能力。基础设施成本可以影响容量限制、模型选择和使用限制。
总体而言，这是制度和系统设计，而不仅仅是语义问题。组织决策和产品需求可以在用户开始对话之前融入服务架构。商业逻辑在面向用户的交互之下运作。安全和系统级约束可以施加优先于用户请求的边界。
这些因素都不必然与用户此刻想要的相一致。问题不仅仅是模型是否理解请求，而是系统的实际行为在考虑其训练、策略、产品配置和操作约束后是否与用户目标保持一致。
一个有用的工程区分是软约束和硬约束。
提示通常将约束传达给模型。模型可能理解该约束并尝试遵循，但合规性仍然是模型生成行为的一部分。
验证器、schema、权限系统、事务边界或后处理检查可以独立于模型强制执行约束。
如果保留每个现有注释是硬需求，系统不应仅仅要求模型保留注释。它应该验证输出是否满足该要求。
添加越来越多的指令不是答案。
"不要更改注释。不要改写注释。不要纠正注释。不要重新格式化注释。不要删除注释。不要添加注释。保留每个现有注释的每个字符..."
这样做是把负担从机器转移到人类身上。这搞反了。更好的工程方法是将重要需求视为可以被验证的不变性，而不是仅仅要求模型记住的承诺。
例如，编码系统可以标识原始注释，允许 AI 修改可执行代码，然后自动将结果注释与原始注释进行比较。如果任何注释发生变化，系统可以拒绝或回滚修改。用户不需要扮演律师写一份无懈可击的合同。软件会强制执行明显的边界。
这个原则延伸到代码编辑之外。当正确性依赖于精确数据时，工作流应该将检索和验证转移到其行为和输出可以被独立测试和验证的系统中。LLM 可以用于上下文约束的解析、转换或解释等任务，而程序化检查则强制执行不能违反的需求。当精确保留、格式、数据完整性或其他硬约束重要时，这一点尤其重要。
AI 助手不是数据库。
同样重要的是区分语言生成和权威数据检索。LLM 是基于习得模式和推理时提供的上下文生成文本的概率模型。这与可以提供结构化检索语义且（取决于系统）具有事务或一致性保证的传统数据库系统不同。
尽管 LLM 可以回忆大量事实信息，但其内部知识不是结构化的、权威的或始终可验证的数据库。它们可能产生不正确或捏造的细节，特别是在被要求精确日期、数字、引用、引用或其他细粒度事实时。因此，当有权威检索可用且正确性重要时，用户不应将 AI 助手视为完美的结构化事实数据来源。
数据库也不应被误认为是无误的真理来源：数据库可能包含不正确、不完整或过时的数据。重要的区别在于数据库提供了一种显式的检索机制，其行为和结果通常可以独立于语言生成过程进行测试。
为了更可靠地自动化基于事实的任务，通常最好构建一个流水线，让程序系统检索源数据，而 LLM 用于上下文约束的解析或转换。检索增强生成（RAG）是一种相关架构，其中外部信息被检索并作为上下文提供给模型。「工具调用」是一个更广泛的概念，其中模型调用外部系统来检索信息或执行操作。这两种方法都不能使 LLM 本质上具有确定性，但都可以约束模型可用的信息，并将关键检索或验证步骤转移到可以直接测试的系统中。
检索也不能保证正确答案。检索到的源可能不完整、过时或不正确，模型仍然可能误解或误用检索到的信息。优势在于检索和验证可以移入独立可测试的组件，而不是完全依赖模型的参数记忆。
对于事实提取，健壮的流水线可以包括以下组件：
从 API 获取单曲美国发行日期的提取流水线示例：
当区分需要语义解释时——例如，区分美国单曲发行和专辑发行——结果可能仍需要基于模型的推理或人工审核。
这说明了当前 AI 助手的一个更广泛的局限性：流畅可能造成可靠指令执行的假象，而实际上并未提供。助手可以听起来完全确定它理解了你。它可以完美地向你复述你的需求。它甚至可以在违反需求后道歉。但这些都不能保证合规。当助手被要求在无法访问或无法根据权威来源验证的情况下提供精确事实数据时，同样的局限性也会出现。
对于许多任务，这些区别无关紧要。但当精确保留、格式、数据完整性或事实准确性重要时，它们就极其重要了。问题不在于 AI 助手无法理解简单指令。关键在于不应将对话理解与可靠执行混为一谈。同样，生成看似合理的事实信息的能力不应与权威数据检索混为一谈。
一个好的助手不应该要求用户变得越来越精确，仅仅是为了防止它「好心」地更改明确声明为禁区的东西。如果一个需求重要到需要被视为硬边界，系统应该显式地表示和强制执行该边界，而不是仅仅依赖对话指令。然而，当需求重要时，最安全的方法是在周围系统中对其进行编码并验证结果。适当的确定性检索、受约束的模型使用、程序化验证和人工审核可以提供比单独依赖对话指令更强的保证。
因此，实际要点不是放弃 AI 助手，而是根据它们的实际优势和局限性来使用它们。在解释、转换和其他概率生成适合的任务上使用语言模型。在需要精确信息时使用外部工具和权威来源。在工件的特定部分必须保持不变时使用不变性和自动化检查。并且，在正确性重要的地方，验证机器实际做了它被告知要做的事。