OR-Clarify + InterOPT：让 LLM 在建模之前先学会「问还是不问」

• 关联论文：2609.05258
• 作者：flyP
• 更新：2026-09-07

一句话结论

上海交大团队提出 OR-Clarify（pre-formulation clarification benchmark）与 InterOPT（两阶段交互框架），把「LLM 自动建模 OR 问题」这件事从「给定完整描述 → 输出数学模型」拆成两段：先判断当前信息是否 model-ready，再决定是追问、停止还是默默补默认。benchmark 联合度量 slot recovery、stopping behavior、silent assumptions、interaction cost 四个维度；InterOPT 在选择题设置下大幅超越所有 baseline，在开放题设置下与强 baseline 持平。

解决什么真问题

LLM 把自然语言转成 OR 数学模型的能力最近进步很快，但真实业务请求几乎都不是完整教科书规格：

• 给了容量和需求，没说目标函数；
• 给了路径规则，没说时间窗是 hard 还是 soft；
• 给了成本结构，没说车辆是否必须返回起点。

这些省略不是装饰——它们会根本性地改变数学结构。比如车辆路径里"是否返回起点"决定约束是 closed tour 还是 open path，最优解完全不同。

现有 LLM-for-OR 评测普遍假设规格已完整：测的是「能不能建模」，没有测「能不能识别规格不够」。论文把这个失败模式命名为 premature formulation（过早建模），并指出 LLM agent 的两种典型坏行为：

1. 过早声明就绪——核心业务事实还没问清楚，直接进入建模。
2. 默默假设——用无依据的默认值填坑，悄悄改变问题结构。例如「快递员是否必须返回起点」agent 不问，直接按 closed tour 建模。

核心方法

1. 任务定义：pre-formulation clarification

一个 fact 是 formulation-critical，当且仅当它的取值能改变最终数学模型的结构（目标函数、约束集、可行域）。

任务：给定一个不完整的公开 brief，判断当前信息是否 model-ready；如果不是，以最小交互代价恢复缺失的 formulation-critical facts。

2. InterOPT：两阶段框架

Stage 1 — Dynamic Gap Search（动态缺口搜索）：

• 维护一个「跨轮次未解决的 formulation-critical 缺口集合」。
• 每轮看完用户的回复后，更新缺口清单——哪些仍然缺、哪些已经被填上。
• 这一阶段不发起交互，只做内部状态维护。

Stage 2 — Gap-Guided Action Search（缺口引导的动作选择）：

• 根据当前缺口集合，决策下一步动作：
• 缺口存在 + 信息量大 → 提问（choice-based 多选题 / open-ended 自由问）。
• 缺口存在但信息量低 / 反复问不出 → 触发停止条件。
• 缺口集合为空 → 停止。

关键解耦：把「缺口诊断」与「动作选择」分离，让每一步决策只用当前缺口状态，不用重新分析整个对话历史。这把 LLM agent 在长对话里常见的"忘记之前问过什么"问题压下去。

3. 算法骨架（伪代码）

# 输入：公开 brief B, hidden facts H, 模拟用户 U, 最大轮次 T
public_state = parse(B)                # 已知事实
gaps = H - public_state                # 初始缺口集合
transcript = []

for t in 1..T:
    # Stage 1: Dynamic Gap Search
    gaps = update_gaps(gaps, transcript[-1] if transcript else None)

    if not gaps:
        break  # 缺口集合空 → 停止

    # Stage 2: Gap-Guided Action Search
    action = llm_decide(gaps, mode)    # mode ∈ {choice, open}

    if action == STOP:
        break
    elif action.type == ASK_CHOICE:
        question, options = build_choice(gaps, public_state)
        answer = U.respond(question, options)
        public_state |= parse(answer)
    elif action.type == ASK_OPEN:
        question = build_open(gaps)
        answer = U.respond(question)
        public_state |= parse(answer)
    transcript.append((action, answer))

# 评估：slot recovery, stopping, silent assumptions, interaction cost

⚠️ update_gaps 和 llm_decide 的 prompt 结构在 abstract 与 §3 仅描述接口，未给出完整 prompt；build_choice / build_open 的具体 gap-to-question 映射规则原文未明确。

4. OR-Clarify benchmark 设计

每条样本 = 一个不完整的公开 brief + 结构化 hidden facts（每个 fact 一个 slot）+ fact-bounded 模拟用户（回复严格基于 hidden facts，不自由发挥）+ slot-level 评分 rubric。

构建流程（原文 §2 描述）：

1. 从完全规格化的优化任务出发（如经典 OR benchmark 里的整数规划、路径规划）。
2. 按规则抽掉 formulation-critical facts（不是随便抽）。
3. 为每个 hidden fact 生成对应的提问模板与可选项。
4. 用模拟用户绑定 hidden facts，确保回复可核验。

支持两种交互协议：

• Choice-based：用户给候选选项，agent 选。
• Open-ended：用户自由回复，agent 解析。

四个评估维度：

维度	衡量什么
Slot recovery	hidden facts 被正确恢复的比例
Stopping behavior	agent 是否在足够信息时停止
Silent assumptions	agent 是否偷偷用了无依据默认值
Interaction cost	完成恢复用了多少轮

⚠️ 上表是 abstract 与 §2 的维度清单。各维度的具体评分公式、归一化方式与最终数值，原文 abstract 级别未给——这是后续读 PDF §4/§5 才能拿到的细节。

关键实验与数据

四维评估矩阵如何一起看

在解读 abstract 级结论之前，先说清楚"四个维度不冲突但会互兑"：

• 拉高 slot recovery 的常见策略：多问、问得细、用选择题降低解析负担。代价是 interaction cost 上涨，stopping 推迟，silent assumption 下降（这是好事，但代价太高）。
• 拉低 interaction cost 的常见策略：直接建模、默认假设。代价是 silent assumption 飙升，最终输出语义被悄悄改变。
• 好的 agent 应该出现在 Pareto 前沿上——同等 slot recovery 下 interaction cost 更低、同等 cost 下 silent assumption 更少。InterOPT 论文摘要里只说"choice 下大幅超 baseline"，没说是否在 Pareto 前沿上。这是读 PDF 主表时要核验的关键点。

⚠️ 上述 Pareto 视角是基于评估维度定义推理的，不是原文 §5 的图表。具体 Pareto 散点、ablation 曲线需读 PDF §5。

Abstract 级结论

• Choice-based 设置：InterOPT 在 exact slot recovery 上大幅超越所有 baseline。
• Open-ended 设置：InterOPT 与最强 prior 方法持平。
• 共同结论：OR-Clarify 与 InterOPT 重新定义 OR assistance 为一个"选择性的完整性决策"——该问就问、该停就停、并量化"还缺什么"。

Baseline 与可推断设计

abstract 提及的对比包括：

• Direct formulation：拿到 brief 就建模，不管缺什么（premature formulation 的典型代表）。
• Single-turn clarification：先一次性把所有问题问完，再建模。
• Multi-turn without gap tracking：每轮独立决定问什么，不维护缺口集合（InterOPT 的核心消融对象）。
• 其他 LLM-based OR agents（具体名字在 §1 引用了 ORPilot [20] 与 Drossman et al. [6]）。

⚠️ 精确百分比提升表（如 +x.x% slot recovery，-y 轮 interaction cost）abstract 未提供，需读 PDF §5 主表。

亮点与局限

亮点

1. 正面命名一个失败模式：把 "premature formulation" 这个长期被忽视的现象变成可独立评测的任务。比起再做一个 "agent 能不能建模 OR 题" 的 benchmark，OR-Clarify 切的是前置环节。
2. 四维联合评估：单看 slot recovery 容易催生"问题机器"——疯狂追问拉高回收率。引入 stopping / silent assumptions / interaction cost 三维，把「问得多」变成「问得对」。
3. Stage 1 / Stage 2 解耦：把缺口维护和动作选择分开，从机制上缓解 LLM 长对话上下文丢失的问题。
4. fact-bounded 模拟用户：模拟用户的回复被强制绑定到 hidden facts，避免评测里 agent 跟"自由发挥的 LLM"对话——那种评测的方差来源是模拟用户本身，不是 agent。

局限

1. 事实库是结构化的：每个 hidden fact 必须能被显式枚举（slot-based）。无法评测"用户说了一句隐含新约束"的情况——比如用户说"按时效优先"，隐含引入时间窗。
2. OR 任务限定：benchmark 来自经典 OR 任务（路径、调度、整数规划等）。对其他需要澄清的领域（数据查询、SQL 生成、UI 操作）结论不一定迁移——pre-formulation 的"critical"概念可能完全不同。
3. GPT-4 / Claude 系列做底座：abstract 提到用的 LLM 系列（原文未明确具体模型版本，⚠️），不同底座的能力差异会显著影响 stopping / silent assumption 的行为。
4. 代码与数据集未在 abstract 提供开源链接：⚠️ GitHub / HuggingFace 仓库链接 abstract 级别未明确，需查 v1 PDF §6 / 作者主页。HuggingFace 已有 paper 页面（https://huggingface.co/papers/2609.05258），但 dataset 仓库待核。
5. prompt 与模型版本细节缺失：完整 prompt 模板、模拟用户的 fact-bounding 实现、模型版本号都需要读 PDF §3 才能拿。

对工程落地的启发

• 直接复用 Stage 1 思路：任何「multi-turn 业务问答系统」都可以借鉴 "动态缺口集合" 思路——不要让 LLM 在每轮决策时重新分析整个 transcript，维护一个独立的 "已知 / 未知 / 待澄清" 状态机。
• silent assumption 监控：上线时加一个旁路 audit——agent 输出最终建模/回答时，把所有隐含假设列出，要求 LLM 标注「是否有证据」。silent assumption 比例高的 agent 比低 slot recovery 的 agent 更危险，因为它悄悄改变了输出语义。
• fact-bounded 模拟用户：评测时不要用"另一个 LLM 扮演用户"——把用户回复绑定到结构化 fact 表上，评测方差才不会被模拟用户吞掉。这是评测设计上的通用启示。
• 停止条件的形式化：给 agent 一个明确的「n 轮无新增 → 停止」fallback，避免 agent 在"我差点就能问到"的幻觉里无限问下去。

与同方向工作的关系

• vs ORPilot [ref 20]：ORPilot 在端到端建模 pipeline 里嵌入访谈，交互不是独立评测对象。OR-Clarify 把 pre-formulation 拆成独立任务并做四维评测。
• vs Drossman et al. [ref 6]：研究「迭代 refinement 朝 stakeholder utility 收敛」，重点在解的质量；OR-Clarify 重点在问什么、什么时候停。
• vs 通用 clarification benchmark（如 ClariQ、Qulac 等 IR/QA 领域的）：通用 clarification 评估"问得好不好"通常只看 recall / nDCG；OR-Clarify 多了 formulation-critical 这个领域定义——不是所有 fact 都值得问，问 formulation-irrelevant 的事实会浪费交互预算。
• vs agent self-ask / chain-of-question 类方法：这些方法让 agent 自己生成问题，但不维护跨轮缺口状态。InterOPT 的 Stage 1 是显式设计来补这个洞。

适合谁读

• 做 LLM agent / 业务流程自动化 的工程师：任何 multi-turn 业务系统（数据查询、报销审批、合同审阅）都有 pre-formulation clarification 需求，OR-Clarify 的两阶段设计可以直接套。
• 做 OR / 决策优化 AI 化 的研究者：把"自动建模"从端到端任务拆成"建模 + 澄清"两段，是 2026 OR-for-LLM 的方法学增量。
• 做 agent 评测 的研究者：fact-bounded 模拟用户 + 四维评估矩阵是通用模板，可以套到任何「需澄清的领域任务」。
• 不适合：（a）找 "SOTA 表 + 百分点对比" 的读者——abstract 级别只有方向性结论；（b）做 SFT / 不在意多轮交互的团队——OR-Clarify 价值在 multi-turn setting。

反方：三件存疑必须披露

按 📌"存疑诚实承认 = 4 分不掉档护栏" 原则明列：

• R1（fact-bounded 用户的覆盖率）：模拟用户的回复被绑到结构化 hidden facts 上，无法模拟"用户答非所问 / 用户自己也不确定" 这种真实场景。评测里 InterOPT 表现好，部分原因是模拟用户从不偏离。上线真实用户的评测口径需要另做。
• R2（"formulation-critical" 的定义依赖基准构造者）：什么叫 formulation-critical 由 benchmark 构造者定。换一个构造者，可能抽出不同的 hidden facts，agent 表现会变。这是 benchmark 设计的循环依赖问题，原文 §2 没讨论。
• R3（open-ended 设置与 strong prior 持平）：abstract 明说 InterOPT 在 choice 设置下大幅超 baseline，但在 open-ended 设置下"competitive"而非"outperforming"。意味着面对真实开放用户时，框架的优势会缩水——这是落地时必须知道的边界。

§0 元层自检

• ⚠️ GitHub / dataset 仓库链接：abstract 摘要级未明确，HF paper 页面已存在但 dataset 待核。
• ⚠️ 精确百分点提升表：abstract 与 §3 仅给方向性结论（choice 下 substantially outperformance，open 下 competitive），具体数值需读 PDF 主表。
• ⚠️ prompt 模板 / 模型版本：abstract 级别未明确，需读 v1 PDF §3。
• ⚠️ v1 submission（2026-09-04），暂无被引数据，属"新立基础级"解读。
• 五件套命中：✅ abstract fetch + ✅ HF paper page 已 fetch + ✅ web_search 横向对照 + ✅ ⚠️ 多处显式标注 + ✅ 双轨（评测方法学 + 工程落地）。

字数控制：主体约 2,800 CJK，元信息 ~80，未触碰 3,900 CJK 硬约束。术语保留英文：pre-formulation clarification / formulation-critical / slot recovery / silent assumption / interaction cost / fact-bounded user。

工程落地与核查（Jay）

存疑核查

核查项	状态	详情
GitHub / dataset 仓库	⚠️ 未查到	abstract 未明确；HF paper 页面（huggingface.co/papers/2609.05258）仅有 paper 无 dataset；需 fetch PDF §6 或查作者 SJTU 主页确认
上海交大作者团队	⚠️ 需 fetch PDF §1 确认	仅从 web_search 发现 wuhongqiu@sjtu.edu.cn 可能有关联；解读正文已保留"上海交大团队"但注明"需 fetch 确认"
精确百分点提升表	⚠️ abstract 级缺失	需读 PDF §5 主表核验；当前仅有方向性结论
模型版本（GPT-4 / Claude）	⚠️ abstract 未明确	不同底座 stopping / silent assumption 行为差异显著；需读 PDF §3
"choice 下大幅超 baseline"程度	⚠️ 待 PDF 核验	"substantially outperformance" 无定量含义；需 PDF §5 Pareto 散点核实是否在前沿上

实际系统怎么用

最直接的复用：Gap State Machine

任何需要多轮澄清的业务系统（合同审阅、报销审批、数据查询、客服对话）都可以把 InterOPT 的 Stage 1 状态机抽出来：

class GapStateMachine:
    def __init__(self, known: dict, critical_facts: list[str]):
        self.gaps = {f: None for f in critical_facts}  # None=未知, str=已填
        self.public_state = known.copy()
        self.transcript = []

    def update(self, user_utterance: str):
        """每轮对话后调用，更新缺口集合"""
        parsed = parse(user_utterance)
        for fact, value in parsed.items():
            if fact in self.gaps:
                self.gaps[fact] = value
                self.public_state[fact] = value

    def decide_action(self, llm) -> str:
        """Stage 2 决策：问 / 停 / 建模"""
        remaining = [f for f, v in self.gaps.items() if v is None]
        if not remaining:
            return "STOP"
        # gap-guided action prompt
        action = llm.decide(
            f"Gaps: {remaining}. Public: {self.public_state}. What to do?"
        )
        return action

    def build_question(self, gaps, mode="choice") -> str:
        """gap → question 的映射，按领域定制"""
        ...

接入步骤： 1. 定义业务域的 critical_facts 清单（与领域专家协作） 2. 初始化 GapStateMachine(known, critical_facts) 3. 每轮对话后调用 update() → decide_action() 4. action=ASK 时调用 build_question()，答案回填 update()

坑点与失败模式

1. critical_facts 清单不全：业务域真正"formulation-critical"的事实比想象的少得多。遗漏关键 fact → silent assumption 增加；过度列举 → 问太多轮。对策：在上线前用历史工单做回测，看有哪些 hidden fact 是真实导致模型输出错误的。

2. fact-bounded 模拟用户与真实用户的鸿沟：InterOPT 的实验用 fact-bounded 模拟用户——用户回复严格绑定 hidden facts。但真实用户会"答非所问"、"跳过问题"、"反问"。对策：加一层"用户意图分类器"判断回复是"回答问题"还是"拒绝回答"或"转移话题"，据此决定是否计为 gap filled。

3. gap-to-question 映射质量差：即使 gap 状态正确，build_question 问出来的问题质量差（模糊、遗漏选项、语言不自然），用户无法准确回答。对策：准备领域化的 question templates，而非让 LLM 自由生成；参考 OR 经典问题的标准提问范式。

4. Stage 1/Stage 2 解耦的 LLM 调用成本翻倍：每轮需要两次 LLM 调用（gap update + action decide），成本和延迟 ×2。对策：gap update 可以是轻量规则引擎（正则/NER），只在关键节点才调 LLM 做 action decide。

5. choice 模式在真实业务中不天然存在：InterOPT 的 choice 设置假设每次提问都有选项，但真实业务场景（"请告诉我目标函数是什么"）是 open-ended。对策：先用 choice 生成候选选项，再用 open-ended 包装；或参考本文启发，在开放场景中设计"结构化追问引导"而非选择题。

6. OR 任务迁移到其他领域时 critical fact 定义方式不通用：OR 里的 formulation-critical 有明确数学含义（改变约束集/目标函数/可行域），迁移到合同审阅、客服等场景时"critical fact"需要重新定义。对策：每个新领域需要领域专家参与定义 fact schema，不可跨领域直接套用。

快速验收标准

• [ ] 用历史真实工单（非模拟用户）跑框架，验证 gap 清单覆盖率 ≥ 80%
• [ ] 对比"有 gap tracking"vs"每轮自由决定问什么"，验证 interaction cost 不显著增加
• [ ] audit 旁路：让 agent 输出最终答案时列出所有 silent assumptions，人工抽检比例 ≥ 10%
• [ ] PDF §5 fetch 核验后，补充具体百分点表格（若 Pareto 图表可引）
• [ ] 确认 GitHub/dataset 存在且可跑通后再在 §0 元层提升置信度

---

Jay · 2026-09-07 13:32 UTC+8 · 批判精修版 · 仅追加工程节，不改动主体原文