治理输入以提升 AI 输出稳定性

模型没有变。证据没有变。我们也没有增加任何推理环节。我们改变的是模型所依据的受治理语义输入——在我们追踪的这个案例中，输出随之不再漂移。

这次失效看起来像是模型的问题

我们当时在评估针对一次企业交互的受治理分类。单独询问某一项判断时，模型给出了正确答案。而要求输出常规的完整结果集——同一次交互、同一个模型——那项判断却变了。

多年来我们屡见这种现象，也深知它引发的本能反应：归咎于模型。调整顺序、增加指令、换一条任务路由、拆分为推理步骤，或者干脆换模型。这些常规手段我们都试过。有几种带来了局部改善，但没有一种能在完整组合下站得住脚。

问题出在语义，而非模型

真正的解法，来自把提示词及其所要求的输出视为一个语义系统，而不是一堆彼此独立的指令。受治理的定义让同一份证据有了不止一个貌似合理的归属——当多个定义都能主张同一事实时，没有任何机制说明哪个定义具有权威性。

于是我们改变的是输入，而非提示词的措辞——将每个定义的含义及其相互关系明确表达出来，而不是留给模型自行推断，使同一份证据不再有多重归属。随后我们重新运行常规的完整输出路径。该案例连续三次运行全部通过，虚假判断也消失了。同一个模型、同样的证据，没有任何特殊机制。

输入与输出是同一个推理问题

这才是超越单个分类任务的关键所在。如今的企业级提示词层层叠加着系统指令、领域定义、示例、模式（schema）、输出字段、评分标准、工具描述和策略。我们分开撰写这些部分，模型却将它们合在一起阅读，并作为一个问题来求解。

因此，可靠性并不是一个措辞问题。你必须治理：每个概念被允许表达什么含义、哪个概念拥有某一事实、什么证据能够确立它、它可以和不可以蕴含什么，以及它所指向的对象是什么。所要求的输出也是这个系统的一部分——它们塑造了模型如何组织你提供的证据。

一个案例，一个模型。我们并不主张所有组合失效都源于语义，也不否认输出结构本身的影响——近期研究表明，模式与格式的选择无论如何都会影响模型行为。我们的论断更窄、也更有用：当语义治理不当时，它可能表现为看似模型不稳定的现象，而治理语义能从根源上解决问题，而不是给提示词打补丁。

为什么这是一个受治理智能的问题

如果这份智能至关重要，它的语义就不能只存在于提示词之内。提示词文本会变，模型会变，模式会变，运行时环境也会变。语义必须经受住这一切——这意味着它必须是一项有明确归属、受到治理的资产，而不是上周碰巧奏效的一句幸运措辞。

这正是我们打造 Metis 所要满足的需求。Metis 将企业智能定义本身视为受治理的工件：人或 AI 都可以提出语义定义，由独立的验收流程进行评估；被接受的语义可投射为提示词、模式、评估器或 SQL；由此产生的智能会依据证据加以验证，并连同溯源信息一并留存。

有必要与最接近的优秀工作做一对比。GROUND 依托经批准的语义层来治理企业级文本到 SQL 的转换——涵盖经批准的指标、维度、连接、粒度与安全策略——并在生成的 SQL 运行之前对其进行校验。这是一套扎实的分析架构。而 Metis 起步早一步、收尾晚一步：它治理的是语义定义本身的创建与验收过程（各类投射均由此派生），并将 SQL、提示词、模式和评估器统统视为同一持久定义的投射。本实验正处于那个更早的环节——在信任任何面向模型的工件之前，先检验组装后的语义是否自洽，再在推理之后对判断结果进行验证。

这对企业 AI 意味着什么

改变所要求的输出暴露了失效，治理语义输入则修复了它。此处的可靠性并非仅仅是模型的属性——它同时是我们输入给模型的语义系统以及我们要求它产出的输出的属性。这比又一轮提示词调优更有分量，因为修正落在智能的定义之中，而不是落在下一次模式变更就会失效的一次性补丁上。将输入与输出作为一个系统加以治理，把这份语义投射到你所需的各类工件中，并对返回结果进行验证。提示词只是一个执行界面，它不应成为你的企业语义的唯一权威。

下一步

我们正在通过NeoSavant Model Observatory在更多模型和工作负载上进行验证，并将在证据固化后发布结果。最初的发现并不依赖于这些运行——它们将告诉我们这一效应及其修正方法能推广到多远。