主导航

结合 LLM 与形式化求解器，实现可靠的 AI 决策

混合架构将 LLM 的灵活性与确定性求解器相结合，帮助企业做出可靠、可验证的决策。

大型语言模型（LLM）在理解自然语言、生成流畅回答以及打造全新的客户和员工体验方面取得了非凡进展。然而，LLM 本质上具有随机性，因此将其用于复杂的数值或逻辑推理时，很难保证输出合规或最优。例如：

  • 经理告诉 AI 规划助手：“在控制成本的同时，尽可能多地安排下周发货。”系统随即给出一份看似高效的激进方案，却暗中超出仓库容量，无法兑现交付承诺。

  • 协调员告诉 AI 助手：“重新调配工作人员，减少过夜住宿并尽量降低干扰。”模型生成了一份看似最优、成本更低的排班方案，却违反了强制工时或休息限制。

  • 财务运营 AI 助手必须按照严格的区域和风险限制审批交易，却为一笔可疑交易编造了听起来合规的理由并予以放行，违反了内部政策。

在运营要求严格的环境中，将 LLM 与形式化求解器相结合，有助于确保由自然语言驱动的决策始终处于既定边界内，避免产生不可行、非最优或不合规的结果。

我们的研发团队正在研究一种混合方法，将 LLM 的创造力与灵活性同 Z3、Pyomo 和 OR-Tools 等形式化数学求解器的严谨性、确定性保证和透明度相结合。我们还在构建可复用的形式化 AI 引擎，使这项能力成为企业技术栈的标准组成部分。该平台将帮助组织直接从现有系统中导入业务规则，持续依据这些规则验证决策，并在明确界定的边界内安全部署 AI 智能体。

我们的愿景是在加快大规模决策的同时降低运营风险。领导者可以根据自然语言输入更快做出符合政策的决策，组织则可自动处理排班、供应链资源分配、财务运营、政策验证乃至视频或 3D 设计中的临时变更。内置防护机制可防止不可行、不合规或不安全的结果进入生产环境。

在针对物流类优化问题和三个公共基准开展的对照实验中，我们的混合方法始终展现出：

  • 更高的准确率

  • 更强的可解释性与可审计性

混合架构

我们的方法颠覆了通常由“LLM 包办一切”的范式，转而采用以下设计：

示意图展示大型语言模型与确定性求解器如何结合自然语言理解和可验证优化。

该方法明确划分职责：LLM 从自然语言中提取规则和约束，OR-Tools、Z3 和 Pyomo 等确定性求解器则负责优化和验证。最终成果兼具两种方法的优势：

LLM

求解器

混合方法（LLM + 求解器）

理解不同领域的人类意图

✅ 出色

❌ 不具备

✅ 出色

确定性行为

❌ 否

✅ 有保证

✅ 是

在多重约束下进行数学推理与优化时可证明正确

⚠️ 不可靠

✅ 有保证

✅ 是

可审计性与可解释性

⚠️ 不可靠

✅ 清晰

✅ 清晰

抵御提示噪声与注入攻击

❌ 易受攻击

✅ 不受影响

✅ 强

实验路径 1：物流和人员分配

问题领域

我们首先研究了部分客户面临的一项挑战：

将自然语言请求转化为最优的实时资源决策，同时严格执行运营、政策和成本约束。

这项挑战是现代物流与供应链的核心，涵盖人员排班、资产分配、路线规划、履约规划和容量管理。这也正是 LLM 与形式化求解器必须协同工作，才能构建可信系统的领域。为开展评估，我们构建了受控测试场景、数据源和约束，并设计了 240 条合成查询。示例包括：

  • 请在订单取消后修改现有计划。目标设施必须在 2025 年 12 月 24 日前获得全部物资。条件允许时，请从附近仓库调拨库存，并经指定集运点配送。最早允许的开始日期为 2025 年 12 月 14 日。

  • 紧急请求：一位 VIP 将在三小时后抵达地点 A。我们需要相关工作人员在两小时内到位。请调整人员分配，同时尽量减少对现有排班的改动。

从这些查询可以看出，系统必须直接从自然语言请求中可靠地提取并执行硬约束和软约束：

  • 硬约束不容妥协，例如最早开始日期、合同条款和容量上限。违反其中任何一项都会使解决方案无效。

  • 软约束用于表达偏好，例如尽量减少延误、降低成本和控制改动范围。目标是在不突破硬性边界的前提下实现优化。

这些优化问题的某些方面无法完全预先定义。系统必须综合结构化业务逻辑、内部文档和运营数据中预定义的约束与目标，以及用户请求，对问题进行动态构建。

我们评估的方法

为了了解不同技术在这种场景中的表现，我们实施并比较了三种方法。

  1. 纯 LLM：最简单的方法是将所有相关数据和用户的自然语言请求传入一条 LLM 提示，要求其生成最优计划或分配方案。这种方法可应对小型或约束宽松的问题，但随着复杂度增加便会失效。模型可能忽略约束、优先考虑错误的目标，或生成听起来合理却不可行的方案，而且没有可靠的方法检测或防止故障。

  2. LLM + 代码解释器：在这种方法中，LLM 解释请求，并使用工具访问数据源和生成可执行的优化代码。这增强了灵活性和可观测性，但可靠性仍是问题。LLM 仍须将约束转化为正确代码，而微小的推理或编码错误也可能产生无效或非最优的结果，尤其是在约束规模扩大时。

  3. 混合方法：LLM → 结构化约束 → 确定性求解器：第三种方法将职责分离。LLM 从不“决定”结果，而是帮助对变量、约束和目标进行形式化。经过验证的优化求解器负责执行约束、保证可行性，并生成可验证、可审计的结果。LLM 的作用仅限于使用预定义模式，将自然语言请求转化为明确的结构化约束。这些约束会自动编译为 OR-Tools 等求解器的代码，由其以确定性方式计算出可行的最优解。

结果

我们使用多种 LLM 测试了这些方法，包括 GPT-5、GPT-5.1 和 GPT-5.2。不出所料，混合方法的表现优于其他方法：

方法

分配准确率

平均延迟

每次查询的 Token 用量

纯 LLM

70–78%

62–190 秒

约 175,000

LLM + 代码解释器

82–84%

62–140 秒

约 9,000

LLM → 求解器（混合）

95–97%

6–25 秒

约 2,000

我们的混合方法实现了准确率大幅提升、Token 效率提高 4 倍以上，并使延迟降低了一个数量级。

实验路径 2：通过自然语言进行通用优化

下一步，我们将构建一个通用、可复用的接口，把自然语言转换为结构化语义表示，再由后端将其转化为求解器就绪的代码。本次实验侧重于线性优化问题，并使用三个公共数据集（NLP4LP、NL4OPT 和 IndustryOR）评估了该方法。

我们评估的方法

  1. 独立 LLM

  2. 混合方法（LLM → 结构化规则 → 求解器 → 已验证输出）

混合工作流示意图，展示从自然语言请求到结构化约束、确定性求解和已验证输出的过程。

  • 使用 LLM 从输入中提取变量、约束和目标，并构建结构化优化问题。

  • 将结构化问题和原始请求传给 LLM 进行自我验证。

  • 将结构化问题转换为 OR-Tools 代码，以计算最优分配方案。

结果

我们使用专有前沿模型评估了该方法，包括 GPT-5.1、GPT-5 mini、GPT-5.1-Codex-Max 和 GPT-5.2，同时还使用了 Kimi K2、GPT-OSS 模型和 MiniMax M2 等开源模型。箱线图汇总了各种方法的结果。

图表对比独立大型语言模型与基于求解器的混合方法在各项优化基准上的表现。

在几乎所有受测底层语言模型中，混合方法都能持续生成比独立 LLM 基线更准确、稳定且可验证的结果。尽管不同模型的绝对表现有所差异，但混合方法带来的相对提升始终一致。这表明，改进源于将自然语言理解与形式化优化分离，而非依赖任何单一模型的推理能力。

准确率

NLP4LP 和 NL4OPT 主要由线性规划问题组成，混合方法在这两个数据集上实现了接近上限的准确率，优于独立 LLM 提示。混合系统不会生成“基本正确”的推理，而是能更稳定地生成有效且格式规范的数学表述。在更具挑战性的 IndustryOR 数据集上，两种方法的准确率均有所下降，但原因不同。许多 IndustryOR 问题涉及车辆路线规划、任务排序和人员分配等组合结构，超出了我们的求解器后端目前支持的线性优化能力。

对失败模式的分析显示，独立 LLM 经常违反必要约束，如下所示：

示例 1：

Plain Text

"A bodybuilder buys prepared meals: a turkey dinner and a tuna salad sandwich. The turkey dinner contains 20 grams of protein, 30 grams of carbohydrates, and 12 grams of fat. The tuna salad sandwich contains 18 grams of protein, 25 grams of carbohydrates, and 8 grams of fat. The bodybuilder needs at least 150 grams of protein and 200 grams of carbohydrates. Because turkey dinners are expensive, no more than 40% of the meals should be turkey dinners. How many of each meal should the bodybuilder eat to minimize total fat intake?"

独立 LLM 生成的方案总脂肪含量较低，但违反了火鸡餐不得超过餐食总量 40% 的要求。混合方法正确执行了这项硬约束，并返回有效答案。

示例 2：

Plain Text

"A hospitalized patient can take two pills: Pill 1 and Pill 2. Each Pill 1 provides 0.2 units of pain medication and 0.3 units of anxiety medication. Each Pill 2 provides 0.6 units of pain medication and 0.2 units of anxiety medication. Pill 1 causes 0.3 units of discharge, while Pill 2 causes 0.1 units. At most 6 units of pain medication may be provided, and at least 3 units of anxiety medication must be provided. How many of each pill should the patient receive to minimize total discharge?"

独立 LLM 再次生成了排放量更低的方案，但超过了止痛药用量的最高许可限制。混合方法正确执行了这项硬约束，并返回有效答案。

延迟与 Token 使用量

延迟和 Token 使用量数据揭示了一个重要区别。混合方法的平均延迟和 Token 使用量高于单次 LLM 提示，但这是架构选择所致，而非效率低下。

混合流程包括：

  1. 调用一次或多次 LLM，以提取结构化变量、约束和目标。

  2. 执行自我验证步骤，以发现内部不一致。

与单次提示相比，这些步骤会增加开销，但延迟仍然有限且可预测；问题正确建模后，求解器通常可以快速运行。这些额外工作会生成明确、可复用且可审计的中间表示。相比之下，独立 LLM 方法将推理压缩到一次不透明的生成过程中，把成本转移到了重试、人工检查和下游故障上。未来可通过以下方式减少这类开销：

  • 缓存已提取的模式。

  • 以增量方式更新约束。

  • 改进提示和调用编排。

透明度与可审计性

最后，即使两种方法都失败，其失败模式也有根本差异。

  • 独立 LLM 往往会悄无声息地失败：模型可能返回一个存在细微错误的结果。

  • 采用混合方法时，明确的问题表述会让故障一目了然，并帮助团队找出表述中导致错误的部分。

未来版本可以在界面中展示这些问题表述，让用户在求解器运行前进行审计或验证。这种透明度不仅能提高实测准确率，也让系统更易于调试和改进，而这对现实部署至关重要。

核心结论

在所有基准以及大多数受测底层模型中，结果都进一步印证了我们工作的一项核心结论：

LLM 擅长理解和转译意图，而要确保结果正确，确定性求解器不可或缺。

混合方法将自然语言从歧义来源转变为支持严谨数学决策的可靠接口，让企业 AI 更接近既智能又可信的系统。

下一步：为企业打造可复用的形式化 AI 引擎

企业约束很少以整齐的模式或表述完美的提示存在。它们分散在数据库、电子表格、内部政策和合同中。用户请求可能不完整、存在歧义，或与业务规则不一致。为了大规模应用这种方法，我们正在构建可复用的后端引擎，将这类复杂问题转化为可靠的企业能力。

企业形式化 AI 引擎示意图，包括业务规则、求解器转换和可审计的决策流程。

平台

该引擎的核心作用是成为 AI 驱动型决策系统的形式化支柱，提供：

  • 一个配备适配器的符号知识库，用于导入业务规则、约束、变量和目标。

  • 一个将模式编译为求解器代码的转换层。

  • 让团队能够检查、审计和修改约束的界面。

价值应用领域

尽管当前实验侧重于优化，但同一方法也可扩展到逻辑验证。潜在业务应用包括：

  • 在严格执行每项运营约束的同时，动态进行临时排班、路线规划和资源分配。

  • 生成始终遵守业务规则的答案和建议。

  • 设计并验证复杂的 3D 对象、视频和架构，在投入生产前发现不可行的设计。

结语

如今的 AI 功能强大，但企业需要的不只是强大能力，还需要正确性、一致性和可控性。我们的 LLM 与求解器混合系统正推动我们迈向一个这样的世界：

  • 智能体不会臆造规则或约束。

  • 逻辑推演和优化符合数学原理。

  • 自然语言成为确定性系统的通用接口。

作者

Peng Seng Ang