InterOPT：让 LLM 在动手建模前，识别出运筹题里没说清的业务规则

2026 年 9 月，一篇来自上海交通大学与杉数科技（Cardinal Operations）合作的论文《Ask Before You Optimize: Dynamic Pre-Formulation Clarification for Interactive Optimization》挂在 arXiv 上 Ask Before You Optimize。这篇工作的核心判断很直接：现在用 LLM 把运筹题从自然语言翻成数学规划的整条流水线里，最大失败不是算错，而是「过早建模」。一个看起来很强、能写出漂亮 solver 代码的智能体，可能在核心业务事实还没问到时就自信地声明 ready，然后用没凭据的默认把缺的填上——而且这种失败目前的评估范式根本测不出来。 InterOPT

围绕这一判断，论文做了三件事：把「建模前该不该追问、追问什么、何时停下」形式化成一个有公共描述 + 隐藏槽位 + 模拟用户 + 有限轮次 + 审计停止的评测协议 OR-Clarify；推出 InterOPT 两阶段框架，把「我缺什么」和「下一步该问什么」解耦；并用实验证明 Choice 协议下大幅领先、Open 协议下仍具竞争力。 NL2OPT Chain-of-Experts CLAM

运筹题请求为什么几乎从不一次说清

一个根本错位贯穿在今天所有的 NL2OPT 工作里：现实里的运筹请求几乎从不一次说清，而现有评估范式却假定它说清了。这条错位正是这篇论文要拆掉的靶心。下面用一段递进的证据把这条主语立稳——先用一条路线例子让你在脑子里看见错位的后果，再看它在真实工业题库里有多普遍，再把它翻译成一个能落地的研究问题，最后指出这种错位恰好是现有评测范式的系统性缺口。 ORLM

先看一个具体例子。下面这段数字化的场景是教程为了便于讲解而构造的——论文原文（§1）只在 vehicle-routing 上下文中用「open tour vs closed tour」一句话点到为止，并没有给出具体车辆数、客户数或出发时间。某物流公司向 LLM 描述：「我们有 8 辆车、23 个客户位置、每辆车早 8 点从仓库出发，想规划今天的送货路线。」这就是论文里在 §1 用到的 vehicle routing 例子。LLM 接住这个请求，可以输出两种数学规划里结构完全不同的形式：如果车送完最后一位客户必须回到仓库，是经典的 VRP closed tour；如果允许车直接停在最后一位客户处下班，则是 open tour。两个问题共享大部分变量和约束，但「车是否回起点」这一条差异直接改写可行域、目标函数里关于返程时间的部分、甚至求解器的算法分支。

如果用户没说车要不要回来，LLM 怎么办？它大概率会 silently assume 一种——论文里把这个例子下的默认假设指向 closed tour，于是规划出了一份要求所有车辆都返回仓库的路线。但用户其实想要 open tour，因为下午的接驳车还要复用这批司机。LLM 给出的方案在它以为的题目上是正确的，对用户真正面对的业务却是错的。更糟糕的是，LLM 在给到这份方案时往往显得很 confident——「好的，我已经规划好。」这就是论文在第一节里点名的核心失败模式：premature formulation，过早建模。

图注：宽幅概念图，左侧是一段局部描述的业务请求（business brief），右侧是基于它应当产出的数学规划，中间用箭头标注 formulation gap——这一 gap 不只是文字上的省略，而是会让目标函数与可行域跟着改写的业务规则差异；图中以 routing open/closed tour 为例，用 check-mark/cross 标注两种情况下的建模分支（来源：arXiv:2609.05258）。

这种「差一句就改写数学规划」的情况不是个例，它在真实运筹请求里非常普遍。论文里给出 100 个源-grounded 案例的统计：平均每个题有 1.78 个这样的隐藏业务规则，94% 的题目至少有一个会改变数学规划结构的关键规则。这告诉我们一个让人不安的事实：LLM 面对运筹题时，几乎不可能第一次就拿到完整信息，错把没确认的当 established 用了。

这就把一个研究问题推到台面上：能不能让 LLM 在动手建模之前，先识别出哪些关键业务事实没说清、并主动追问？追问什么？问到什么时候该停？这就是论文标题里那三个词的含义——Ask Before You Optimize。

那么为什么这条问题之前没被认真研究过？因为现有 NL2OPT（自然语言到运筹建模）评估范式都默认「输入完整」。下面这条对照能直观看到这一点。

图注：OR-Instruct 的半自动数据合成 pipeline，以工业 seed cases 为起点，经 expansion + 三种 augmentation 操作闭环生成训练样本（来源：ORLM: Operations Research 2025）。注意 pipeline 的起点是已经「完整」的真实案例与合成样本，关注的是「完整 NL → 完整代码」的下游段，并不评估「NL 不完整时模型怎么反应」。这种把完整当默认的范式，正是 OR-Clarify 想要打破的。

把图 1 和图 2 拼起来读，论文的核心张力就立起来了：现实运筹请求几乎从不一次说清，而主流 NL2OPT 范式把「完整」当默认——这两件事并排放着，意味着 LLM 最容易翻车的那一环，恰好是从评测里漏掉的那一环。

现有 NL2OPT 评估为什么测不出「会不会问」

把 NL2OPT 现状画成一张谱系图，可以分出三条主流路径。

第一条是训练派，代表是 ORLM。它做的是「用开源 7B 模型端到端训练做运筹建模」，配合 OR-Instruct 半自动数据合成（686 个工业 seed cases，每轮 20K 次 GPT-4 expansion + 三种 augmentation 各 6K 次，两轮后得 32,481 条样本）和 IndustryOR 100 道工业基准题，最终用 COPT/Gurobi 等 solver 跑出最优值做 execution accuracy 评测。训练派把建模正确率做得很成熟——ORLM-LLaMA-3-8B 在 NL4OPT 上 85.7%、MAMO-EasyLP 82.3%，逼近专家水平。

第二条是多 agent 派，代表是 Chain-of-Experts (ICLR 2024)。它用一个 Conductor 调度 12 个异构专家（Terminology Interpreter / Modeling Expert / Programmer / Evaluator 等），用 forward thought construction + backward reflection 协作完成建模与代码生成，下游通过外部执行反馈触发反向修正。在 ComplexOR 37 题和 LPWP 1101 题上分别达到 25.9% / 58.9% 的 Acc。

图注：Chain-of-Experts 多角色协作示意——Conductor 在顶部接收输入问题，向下依次调度 Terminology Interpreter / Modeling Expert / Programmer / Evaluator 等专家节点，并通过 forward pass (黑) 与 backward reflection (红/绿) 反复修正（来源：ICLR 2024 proceedings）。注意它的前向流是 Problem Input → Final answer 的单向闭环，不存在回头追问用户的环节——无论问题描述是否完整，agent 都会按既定流程把建模做完。

第三条是对话派，代表是 Drossman et al. 的 SFUSD 学校排课案例。它用 LLM 模拟 436 个 stakeholder decision agent（每个有自己的 utility function + 角色 + 沟通风格）来评测对话式优化：full conversation 的 pooled success rate 65.1%，远超 baseline one-shot 的 16.7%——证明「对话 > 一次提交」。它的核心洞见是 utility function 作为 assessment anchor，让评测可复现。

但这三条路径有一个共同盲区：它们的「interactive」要么发生在「已经决定建模后」的迭代里（多 agent reflection 对的是 solver 执行反馈，不是用户没说清的事实），要么发生在「已经得到建模输出后」的 refine 循环里（Drossman 的多轮对话聚焦 stakeholder preference elicitation，而不是建模前业务规则缺失）。OR-Clarify 主张的 pre-formulation clarification——把澄清提前到「还没决定建模前」——在所有这三条路径里都没有被单独衡量过。

这不是新点子就没人想过。ORPilot（arXiv:2605.02728）就明确把「no modeling before interview complete」作为设计原则，让 interview agent 在建模前完成对 objective / decision variables / constraints / parameters / indices 的澄清，再推进到下游。但 ORPilot 是工程系统，solver 端到端跑通才是它的目标，clarification 能力没有被 isolated 评估。OR-Clarify 想做的，正是把这种「建模前澄清」从工程直觉里抽出来，变成一个可量化的研究问题。 ORPilot

OR-Clarify：把「建模前澄清」做成可测量的研究问题

要把这个问题做成 benchmark，需要回答四件事：题目是什么结构、信息边界怎么划、用户怎么模拟、交互怎么收敛。

第一个问题：题目结构。OR-Clarify 把每道题建模成 public–private tuple (b, F, H)。b 是公开给 agent 的业务简报，F 是评测方持有的私有事实集，H 是结构化的 hidden slot 集合——也就是这道题里「用户没说但建模必须知道」的业务规则，按结构化条目拆好。每个 hidden slot 都配 supporting evidence、simulated-user 答案、acceptable-question 示例和 recovery rule。

第二个问题：严重度分层。100 道题共 178 个 hidden slot（平均 1.78 个 / 题），按对数学规划的影响分三档：P0 是 blocking 级（如开放 vs 闭环路径），P1 是重要建模条件（如未满足需求的惩罚），P2 是次要边界条件（如车辆调度的日界划分）。分布是 75 P0 + 83 P1 + 20 P2 = 178。94 of 100 题至少有一个 P0/P1 槽位（构成 Core-Exact 评估的 I_core 子集）。

第三个问题：controlled information boundary。Agent 只看得到 b 和对话 transcript，看不到 F 和 H；simulated user 只在被问时回答且只能从 F 抽；post-hoc judge 用冻结的 hidden-slot rubric 审计最终 transcript。整张评测流程图就长这样：

图注：OR-Clarify 的评测流程与信息流。横向 pipeline：左侧 Public brief → 中间 Tested agent → 右侧 Simulated user + Passive monitor → 最右 Post-hoc judge；红色虚线 information boundary 把 agent 与 private fact set / judge 严格隔离——hidden slots 只在 simulator、judge 与 rubric 之间流动，从不进入 agent（来源：arXiv:2609.05258）。

把 agent / simulator / judge 三方用 information boundary 切开，是 OR-Clarify 在方法论上最关键的设计。这条边界保证了：评测的是「在限定信息下 agent 能不能识别出还缺什么并主动追问」，而不是「agent 能不能看到答案」。

第四个问题：两种交互协议。Open / FreeQA：agent 用自然语言追问；Choice / MC-D：agent 提出问题并给三个候选选项 A–C，加一个固定 option D 允许 free-form correction。这种 split 是论文的核心实验设计——同一组 agent 在两种协议下跑出截然不同的结果。

这套评测范式不是 OR-Clarify 发明的。τ-bench 在 2024 年就用 LM-simulated user + agent + 有限交互评测数据库写入的最终一致性，把客服场景的可复现评测搭好了。OR-Clarify 是把这套骨架——POMDP 风格的部分可观测 + fact-bounded user + 最终状态审计——搬到了 OR 配方恢复任务上。 τ-bench

图注：τ-bench 的 agent ↔ DB API tools ↔ LM-simulated user 流程图。左边 (a) 显示 Database / Agent / User 三方边界与 policy 通过 system prompt 注入；右边 (b) 是一段 τ-airline 多轮对话轨迹（用户想改 basic economy 航班 → agent 拒绝并提议 cancel + rebook）（来源：τ-bench: ICLR 2025）。这张图与上面 OR-Clarify 的评测流程在结构上同构——agent 看不到的部分由 LM-simulated user 守门，最终状态由外部 rubric 审计。区别只在评测对象：τ-bench 测的是 DB 写入是否一致，OR-Clarify 测的是 hidden slot 是否恢复。

有了评测协议，还需要一组能讲清「成功」的指标。OR-Clarify 用五个指标覆盖三件事：

这套指标里有一个关键设计：Core Exact 的成功定义是「所有 P0/P1 全 exact」，partial recovery 不算成功。这意味着 agent 不能靠「问对一半」蒙混过关——必须把关键槽位一个不漏地追到。配合 Silent/run 把「错把没确认的当 established 用了」单独拎出来作为失败模式，评测同时压住「该问的都问了」和「不该用的别用」两条线。

InterOPT 两阶段框架：用 gap ledger 把诊断与行动解耦

评测协议搭好了，下一步是用一个 framework 去解题。InterOPT 给出的是一个两阶段循环：

左侧 Stage 1 维护一个 persistent public-evidence gap ledger M_t，覆盖六类 gap：objectives and trade-offs、decision scope、operational constraints、time boundaries、relationships among entities or decisions、hard-versus-soft policies。每轮至多新增三条；ledger 不存答案，只记「还缺什么」。右侧 Stage 2 从 ledger 的 open 子集 O_t 生成停止决策 d_t 加上三个候选 state-question 对，由 selector 按优先级选一。候选问题被发出后才把对应 gap 从 Open 移到 Asked——记住，是 queried 而不是 resolved，queried 不等于「已经知道答案」，还得等用户回答。

图注：InterOPT 两阶段循环的全景图。左侧 Stage 1 (Dynamic Gap Search) 是 feedback block，从 public brief + transcript + 上轮 ledger 更新 gap ledger M_t；open 子集 O_t 流入右侧 Stage 2 (Gap-Guided Action Search) 生成 stopping decision d_t + 三个候选 state-question 对，selector 选一后，gap 从 Open 移到 Asked 送入 simulated user（来源：arXiv:2609.05258）。注意 ledger 是 open gaps 的记忆，不是答案的记忆——它只回答「我还缺什么」，不回答「我已经知道什么」。

把诊断（我还缺什么）与行动（下一步该问什么）解耦，是 InterOPT 最关键的工程智慧。它带来两条不变量：

第一条：open 子集非空不阻塞 READY_TO_MODEL。Stage 2 永远可以选 Ask，也可以选 Stop；即使 ledger 里仍有 open 槽位，agent 仍然有权在判断「剩下的不确定性只关于 notation / raw-data collection / 下游 solver 细节」时声明 ready 推进建模。这避免了 agent 被「还差一个 gap」卡死、永远不敢动手。

第二条：open 子集为空不强制 READY_TO_MODEL。Stage 1 可能漏检一个 gap（比如某个业务事实藏在某段话的隐含语义里），所以 ledger 为空并不意味着万事俱备——停止决策始终在模型手里。

把这两条放在一起读，InterOPT 的设计哲学就清楚了：停止决策是模型的责任，ledger 是辅助诊断的工具，不是硬约束。这是从监控—控制视角（论文引用 Nelson 1990 的 metamemory 文献）来的：monitoring 维持「还缺什么」的记忆，control 据此分配「继续问」或「停下」的搜索——但「停下」这件事本身不能被监控的输出自动触发。

Stage 2 的 selector 优先级也值得一提：objectives > business constraints > decision scope > silent assumption risk > 数学细节。这条优先级把「差一个业务事实就改写数学规划」这一动机直接编码进了选择器——目标是「代价函数变了就完全不同」的层面，约束是「可行域变了」的层面，scope 是「决策变量增减」的层面，silent assumption 是「没问到就用默认填了」的风险，最后才轮到数学记号、数据收集、求解器细节。InterOPT 把对数学规划结构影响最大的 gap 排在最前。

实验结果：Choice 大幅领先，Open 仅 competitive——不对称才是核心发现

InterOPT 在两组 protocol 下的表现完全不同，这是论文最值得讲的工程发现。

先看 off-the-shelf LLM 在 OR-Clarify 上的 baseline（Table 1）：Open 协议下最强的 Opus-4.8 拿到 Core Exact 0.583、Silent/run 0.424、Avg Q 3.504；Choice 协议下同样 Opus-4.8 拿到 Core Exact 0.583、Silent/run 0.456、Avg Q 2.906。没有任何一个通用模型超过 60% Core Exact——这说明「建模前澄清」这件事对前沿 LLM 来说本身就难，不是某个模型没训好的问题。

再看 training-free 方法对比（Table 2），把基线按 Open 协议和 Choice 协议分两块：

Open 协议下，ORPilot adapter 反倒 Core Exact 最高 0.583，InterOPT 居中 0.538；Choice 协议下 InterOPT 大幅领先（0.675 vs MC-D 0.506），但 turns 高达 10.7，是 MC-D 的 3 倍多。这组不对称是关键证据：结构化选项放大了 ledger + selector 的指导价值——Choice 协议下三个候选选项让 Stage 2 能利用 ledger 信息做更精准的选择；Open 协议下自由追问时 ledger 漏检一个 gap 就不会被任何机制兜底。

Table 3 的消融进一步验证这条判断。Open 协议下，去掉 Stage 2 时 silent assumption 从 0.560 暴跌到 0.254，但 turns 翻倍（5.49 → 9.51）——说明 Open 下 Stage 1 主导 recovery、Stage 2 主导交互长度。Choice 协议下两阶段都贡献：去掉 Stage 1 Core Exact 掉 11.1pp（0.675 → 0.564），去掉 Stage 2 掉 6.0pp（0.675 → 0.615）——两阶段在 Choice 下都有不可替代的价值。

最反直觉的发现藏在 Section 6.6 的协议诊断里。Open 协议下 InterOPT 看着很「自信」：98.8% 的 run 都声明 ready，但其中 40.6%（203/500） 被 post-hoc judge 审计为 premature stop。这条数据直接戳穿了 Open 协议的核心难题：agent 会问，但不知道什么时候问够了。Open 下 InterOPT 每 run 平均问 4.824 个原子问题 / 4.502 轮，其中 6.4% 的轮次包含多问题，而用户的多 slot disclosures 仅 0.116/run——意味着 agent 几乎从不一次性把多个隐藏槽位都触出来。

Choice 协议下则是另一种「错」。MC-D 在 1,129 个被审计的 choice event 中有 132 次 no-match，全部 invoke D 让用户做 free-form correction——选项不够时退回自由语言。Silent/run 数字更说明问题：InterOPT 0.366、ReadyGate 0.614、MC-D 0.692——同样是「把没确认的槽位当 established 用」，MC-D 做错 0.692 次，InterOPT 只做错 0.366 次。这条数字翻译成直觉：跑一次 InterOPT 平均 0.366 次把没确认的当已确认，跑一次 MC-D 平均 0.692 次。

把 Choice 和 Open 拼起来读，coverage–cost trade-off 这条曲线就出来了：Choice 协议下 InterOPT 在预算增加时持续提升 exact recovery，而 MC-D 和 ReadyGate 趋于平台；Open 协议下 InterOPT 受限于 stopping 漏检，难以稳定。这就是为什么论文把它命名为 selective completeness decision——该问的问、不该问就停、剩下的显式标出缺失，而不是追求「绝对完备」。

范式重构、三个局限，以及它在更大的图里

把整篇论文的判断压成一句：OR 助手这个品类，从「一次性建模」转向「选择性完备性决策」——clarify when needed, stop when ready, quantify what remains missing。

这不是凭空提出的。「选择性澄清」是 NLP 主线里一条已经活跃的研究脉络。CLAM (OATML @ Oxford, 2022) 在 QA 任务上首次把「模型是否应该问用户、何时问、问什么、什么时候停」系统化为四阶段流程——Step 1a 接收问题、Step 1b 二分类器判断 ambiguous/not ambiguous、Step 2 若 ambiguous 生成 disambiguating follow-up、Step 3 用户回答、Step 4 给最终答案。

图注：CLAM 的四阶段选择性澄清流程。顶部 Step 1a 接收用户问题，橙色菱形 Step 1b 分类器把问题判为 ambiguous / not ambiguous；Not ambiguous 一路跳过 Step 2/3 直接进入 Step 4；Ambiguous 一路经过 Step 2 生成追问 → Step 3 用户回答 → Step 4 最终答案（来源：CLAM: arXiv:2212.07769）。CLAM 在 QA 领域证明了一件事：模型对「什么是模糊」已经有判断能力，缺的是把它转化成「要不要打断用户去问」的策略层。

AskBench (ACL Findings 2026) 把这条思路做成 modern benchmark——AskMind 测 intent-deficient queries、AskOverconfidence 测 false-premise correction；用 rubric-guided RLVR (GRPO) 训 Qwen2.5-7B-Instruct；frozen judge (Qwen3-30B-A3B) 同时承担 final-answer 评分、checkpoint coverage 审计和 user simulation。 AskMind

图注：AskBench 的 evaluation loop。candidate model 与 LLM judge 交替输出；judge 决定当前 reply 是 final answer 还是 clarification request、是评分还是模拟 user follow-up；最后一 turn 强制 final answer，避免无限追问（来源：AskBench: ACL Findings 2026）。OR-Clarify 的 controlled information boundary 与这张图同源，二者都用 fact-bounded LM-simulated user 守门一侧信息：OR-Clarify 在第 3 章里由 simulated user 仅在被问时从 private fact set F 中抽取作答，AskBench 的 judge 同样承担 user simulation 角色。两者的差异不在「有没有 user simulator」，而在评审／审计流程：OR-Clarify 由独立的 post-hoc judge 按冻结的 hidden-slot rubric 做最终状态审计，AskBench 则把评分与 user 模拟合并在同一轮 judge 输出里。

InterOPT 不是凭空提出「何时问何时停」，而是把这条 NLP 主线里活跃了数年的「selective clarification」思想搬到 OR 配方重构任务上：把 ambiguous 换成「建模关键缺口」、把 classification 换成「六类 gap ledger」、把 final answer 换成「READY_TO_MODEL」。同构，但专门化。

但论文自己也诚实标出三个局限。第一，Choice 协议下 InterOPT 大幅领先，但 turns 高达 10.7——在成本敏感场景下要权衡 coverage 与 cost。第二，Open 协议下 stopping 仍 imperfect——40.6% 的 run 被审计为 premature stop，「不知道什么时候问够了」这个问题还没解决。第三，依赖 prompt-level policy（Stage 1 + Stage 2 都不需要额外训练），意味着上限受限于 base model 的 intrinsic 能力——如果换成 ORLM-LLaMA-3-8B 那种专门训过的建模 LLM，是否会得到不同的曲线是未知的。

论文自己点名的三个未来工作方向也很具体：扩大 benchmark（目前 100 题 178 slot）、改进 question efficiency（Choice 协议下 turns 太多）、改进 stopping calibration（Open 协议下 premature stop 太多）。这三个方向里，每一个单独拎出来都够做一篇新论文。

最后用一句话把这篇论文放进读者的视野：它论证的不是「NL2OPT 应该改成对话式」，而是「对话式 NL2OPT 应该把澄清提前到建模前」——而现有评估范式根本没在测这件事。读完这篇论文，读者应该能用一句话向同行解释：pre-formulation clarification 不是一个 NL2OPT 的子步骤，它是 NL2OPT 必须先回答才能开始子步骤的前置问题；衡量它的核心指标不止恢复率，还包括静默假设率与交互成本——因为一个会问但不知道何时停的 agent，和一个不会问的 agent 一样糟糕。

想深入可以读原文：Ask Before You Optimize: Dynamic Pre-Formulation Clarification for Interactive Optimization — arXiv:2609.05258

参考文献

• Ask Before You Optimize — 锚论文，arXiv:2609.05258，Sihan Ge 等，2026-09-04 提交。
• ORLM — ORLM: A Customizable Framework in Training Large Models for Automated Optimization Modeling，arXiv:2405.17743，Chenyu Huang 等，Operations Research 2025 接收。
• Chain-of-Experts — Chain-of-Experts: When LLMs Meet Complex Operations Research Problems，ICLR 2024，OpenReview forum=HobyL1B9CZ。
• Drossman et al. — Let's Have a Conversation: Designing and Evaluating LLM Agents for Interactive Optimization，arXiv:2604.02666，Joshua Drossman 等，2026-04-03 提交。
• ORPilot — ORPilot: A Production-Oriented Agentic LLM-for-OR Tool for Optimization Modeling，arXiv:2605.02728，Guangrui Xie，2026-05-04 提交。
• CLAM — CLAM: Selective Clarification for Ambiguous Questions with Generative Language Models，arXiv:2212.07769v2，Kuhn / Gal / Farquhar，OATML @ Oxford。
• AskBench — When and What to Ask: AskBench and Rubric-Guided RLVR for LLM Clarification，arXiv:2602.11199，Zhao / Fang / Cheng，ACL Findings 2026。
• τ-bench — τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains，arXiv:2406.12045，Shunyu Yao 等，ICLR 2025。