大语言模型驱动优化建模：双向数据合成框架解析与实战

1. 为什么LLM-OR方向卡在了“数据”这一步

1.1 优化建模：LLM在运筹学里最值得先做的事情

先聊个场景。你手里有一份仓储调度的业务描述——货品进库、出库、库存上限、运输车辆的时间窗、每辆车的载重约束，配送成本按照行驶里程计。过去要写出对应的混合整数规划模型，得靠运筹学工程师一点点梳理决策变量、目标函数和约束条件，和业务方反复确认口径。整个过程少则半天，多则一周。而LLM-OR（Large Language Model for Operations Research）想做的事情，就是让大语言模型直接把“自然语言业务问题”转译成“数学优化模型”，把这段最昂贵的专家劳动自动化。

OptMATH这个工作，瞄准的正是这条链路里的第一个、也是最关键的一个环节：优化建模（Optimization Modeling）。它提出的不只是一个数据集，而是一套可扩展的双向数据合成框架（Scalable Bidirectional Data Synthesis Framework），核心目的是解决“自然语言问题—数学模型”配对数据的规模化生产问题。如果你在研究LLM的数学推理能力、在做运筹建模自动化、或者需要大规模合成训练数据来微调模型，这篇内容值得细读。下面我按自己的理解，把框架的设计思路、数据质量管控、训练效果和实操坑位全部拆开讲。

1.2 现有数据集的三个痛点，逼出了这个框架

为什么需要专门做一套数据合成框架？因为手头现成的数据根本不够用。我自己的体感是，早期接触的NL4OPT、MAMO这些数据集，规模小、领域窄，覆盖的优化问题类型也就线性规划、整数规划、少量调度问题，远远撑不起一个大模型的微调需求。

更麻烦的是，这类“问题描述-数学模型”配对数据的标注成本极高。写一条质量合格的样本，需要懂运筹学的人先理解业务、再形式化建模、还要反复核对语义一致性，一条数据磨上十几分钟很正常。靠纯人工想堆到十万条，时间和资金都扛不住。

第三个痛点，也是很多人容易忽略的：主流合成方式都是单向的。也就是拿种子问题让LLM生成数学模型，一个问题只能派生出一个或少数几个模型。这样造出来的数据，数学结构多样性很差，模型训练完容易“偏科”——会做见过的题型，换一个业务外壳就蒙圈。

OptMATH设计的双向框架，正好戳中了这三个痛点：用正向和反向两条生成路径规模化造数据，用求解器和一致性校验管质量，同时靠双向生成把数据多样性拉上去。下面我逐个环节拆。

2. 双向合成框架的设计思路拆解

2.1 前向通道：从问题描述到数学模型

前向通道是最直观的一条路：给定一段自然语言优化问题描述，让LLM把它转化成数学模型，输出一组决策变量、目标函数和约束条件。

举个例子。输入是“某工厂生产两种产品A和B，每种产品消耗的机器工时和原料不同，利润也不同，现在要决定每天各生产多少件，使得总利润最大，同时机器工时和原料都不超过库存上限”。模型应该输出类似这样的形式：

决策变量

• (x_1)：产品A的日产量（单位：件）
• (x_2)：产品B的日产量（单位：件）

目标函数

• (\max Z = p_A x_1 + p_B x_2)

约束条件

• (a_{11}x_1 + a_{12}x_2 \le M)（机器工时限制）
• (a_{21}x_1 + a_{22}x_2 \le R)（原料限制）
• (x_1, x_2 \ge 0)，且为整数（如果这是整数规划）

这一步的关键不是让LLM“凭空创造”数学，而是让它学会从自然语言的业务语义里做形式化转译。谁来做这个转译？高版本的开源LLM（比如Llama-3-70B、Qwen系列）就可以。论文里用的是指令微调后的模型，我们在复现时也可以用GPT-4级别的商用模型来标注种子数据，再用开源模型做批量扩充，成本和质量的平衡会更好。

2.2 反向通道：从数学模型变出业务问题

反向通道是OptMATH最有意思的设计。它的方向正好反过来：拿一个数学模型，让LLM生成一段能对应这个模型的自然语言问题描述。

数学上两者是同一件事，但语言外壳可以千变万化。同样一个背包问题：

决策变量：(x_i \in {0,1})
目标：(\max \sum v_i x_i)
约束：(\sum w_i x_i \le C)

可以让LLM生成“旅行者要往背包里装价值最高的物品组合，背包承重有限”，也可以生成“广告位预算分配问题，在总预算约束下选曝光价值最高的广告位组合”，还可以生成“投资组合里选项目，预算有限，收益最大”。同一个数学结构，因为反向生成，一下子就能扩散出几十种业务场景。

这一步对数据多样性贡献非常大。因为前向生成受限于种子问题的覆盖范围，你能找到多少高质量问题描述，就只能生成多少模型的母本。而反向生成是从模型空间出发，LLM可以把同一个数学结构映射到仓储、制造、物流、金融、能源等各种行业语境。相当于你在主动把模型空间里的结构“翻译”成语言空间里更丰富的表达，数据覆盖率自然就上来了。

2.3 为什么“双向”是这套框架的灵魂

单看正向或单看反向，都能造数据，那为什么非要双向不可？关键在于三件事。

第一，数据多样性和均衡性。只做前向，数学结构种类受种子问题限制；只做反向，则可能出现大量数学结构相同、只是换了层语言皮的同质化数据。双向生成把两条路径的产物合并，既保证了模型覆盖度，又保证了语言表达多样性。

第二，可以互为校验。前向生成的模型，可以拿去做反向生成，看是否能得到语义相近的问题描述；反向生成的描述，也可以拿去做前向生成，看是否能还原原模型。对不上的样本，大概率存在语义漂移，直接丢弃。这个一致性闭环相当于一个免费的过滤器，能在规模化生成时自动筛掉大量低质量数据。

第三，为下游评测提供便利。双向一致性评测本身就是一种评测指标——把模型生成的数学模型再次转成文字，和原问题描述做语义相似度比对，可以更客观地判断“模型是真正理解了问题，还是在死记硬背题型”。

3. 数据质量管控：合成数据最容易翻车的地方

3.1 求解器合法性验证，一条都不能省

大模型生成数学模型的通病是“看起来像那么回事，但实际解不出来”。变量定义了没用上，约束左边用了未定义的参数，目标函数方向和业务语义相反（该最小化写成最大化），这些问题在合成数据里比比皆是。

OptMATH的应对方式是引入求解器做合法性验证。生成的模型会用HiGHS、SCIP这类开源求解器去求解，检查这几项：

• 模型是否有可行解，还是约束之间直接冲突；
• 是否有最优解，目标值是否在合理数值范围（不是NaN、不是Inf）；
• 决策变量和参数是否有明确定义，约束中是否存在未声明符号。

把求解器当成“数学语法的编译器”，过不了编译的样本直接淘汰。这一步大大提升了数据集的干净度。

我在实际复现中还会加一道规则化检查：写一个小的符号解析脚本，把模型里的变量、参数、约束里的符号全部提取出来做集合比对。符号集合不一致的，不给求解器浪费算力，直接过滤。这个脚本很便宜，但能挡掉至少一成的“幻觉样本”。

3.2 去重与多样性控制

大规模合成之后，一个很现实的问题是数据“看着多，其实都长得差不多”。反向生成容易凑出一堆同质样本：数学结构一样、业务场景近似、只是换了数字。这种数据对训练的增益很小。

处理方案分两层。第一层是浅层去重，用n-gram哈希或者MinHash对文本做近似去重；第二层是深层去重，对问题描述做embedding，用向量相似度阈值（比如cosine相似度高于0.85就视为重复）做聚类。两层都做，能明显拉高数据集的单位信息量。

这里我有一个心得：去重要有“度”，不能太激进。有些数学结构相同但表述角度不同的样本（一个从成本角度描述，一个从利润角度描述）其实是有价值的，因为模型在推理时需要学会识别不同表述下的同一个数学本质。阈值调太紧，把这类样本都去掉，反而会削弱模型的语义理解能力。

我自己在构建类似数据集时，习惯给每条样本加一个字段标记“数学结构指纹”，指纹相同但语言表达差异大的样本保留1~2条，指纹不同的一律保留。这样可以在“去重”和“保留多样性”之间取得一个相对平衡。

3.3 难度分层，给训练“配菜”

不是所有样本对模型的成长贡献都一样。OptMATH框架里也有一个值得注意的细节：按问题结构复杂度做难度分层。分层维度包括：

难度分层对训练的意义在于，你可以在不同训练阶段控制数据配比。比如早期用简单样本教会模型基本的“语义到数学”映射，后期加入困难样本提升上限。如果不分层一股脑灌进去，模型可能被简单样本主导，遇到复杂模型照样抓瞎。

3.4 人工抽检：自动化验证之后，还是得人看

先说明一下，这里讲的是我在复现类似框架时的经验，不一定就是论文里的原始做法。自动化验证再完备，也挡不住一类问题：模型在数学上是合法的，但语义上不对应原问题。比如目标函数确实是最大化了，可问题明明是让成本最小化。

这类错误求解器测不出来，规则脚本也查不出来。我的建议是，对每一批合成数据，抽检3%~5%的样本，让懂运筹学的人逐条核对“原问题描述 → 数学模型”的语义一致性。抽检比例不用高，但一定要坚持做，因为通过抽检能发现错误类型，知道当前的合成配置在哪一类问题上系统性出错，然后回去调prompt或加规则。只看自动化指标，很容易被“合法但不正确”的样本悄悄带偏。

4. 从数据到模型：训练、评测与效果分析

4.1 基座模型与训练配置

数据造出来不是堆在那里好看的，最终要喂给模型。OptMATH这类工作的标准做法是：用开源基座模型（Llama-3-8B、Llama-3-70B、Mistral系列都可以），在合成数据集上做监督微调。

训练时需要注意几个配置细节。学习率不能太激进，我建议用2e-5左右，如果模型参数量大可以再降一点。数据混入比例也要留心，纯使用优化建模数据训练，模型可能丢掉通用能力，最好按一个经验比例混合通用数学推理数据（比如Orca-MATH风格的推理样本）和优化建模数据，我自己习惯用7:3，效果比较稳。序列长度要照顾到数学公式的特殊token，至少留到2048，不然长约束表达式会被截断。

4.2 评测方法：不能只看“生成得像不像”

怎么知道模型真的学会了优化建模？最直观的方法是评测集里放一批模型没见过的自然语言问题，让模型生成数学模型，然后看生成结果。

但看什么指标，这里有讲究。只看格式对不对（是否输出了变量、约束、目标函数三段式）远远不够。我在评估时至少看三个维度：

• 合法性：生成的模型能不能被求解器正常求解，有没有未定义符号、矛盾约束；
• 忠实度：数学模型是否真实反映原问题的业务逻辑，目标函数方向对不对、约束是否漏项；
• 可解释性：变量命名和约束注释是否清晰，这对后续人工检查和落地使用很重要。

第三点常被忽略，但实际工程里特别重要。模型生成的数学公式不只要“对”，还要“能看懂”。变量名直接从问题里提取（用Warehouse_A_Output而不是列1、列2），约束附带一句注释，会节省大量下游排查时间。

4.3 数据规模与收益曲线：多少数据才够

很多人在数据合成时有个误区：觉得造的越多越好，直接冲上百万条。但我观察到的规律是，建模准确率随训练数据规模增长呈现边际递减：

这个曲线告诉我们，数据合成框架的核心价值不只是“能生产多少数据”，而是“在合理成本下生产多少高质量、多样化的数据”。OptMATH的思路就是通过双向生成，在20K~50K这个区间内把数据的多样性做足，而不是盲目追求百万级规模。

4.4 和Orca-MATH这类工作的关系

很多人会问，已经有了Orca-MATH这类数学推理数据集，为什么还要专门做OptMATH？这两者解决的问题其实不一样。

Orca-MATH解决的是“通用数学题推理”——让模型能读懂数学题、能算、能推导，侧重计算和解题。而OptMATH解决的是“优化建模”——让模型把业务问题转成数学规划模型，侧重形式化和结构搭建。一个是算数学，一个是写数学。两者可以形成搭配：用Orca-MATH类数据训练模型的数学推理性，用OptMATH类数据训练模型的形式化建模能力，最终让模型既能读懂业务问题，又能构建出可求解的数学模型。

我在微调时会把这两类数据混合使用，性能确实比自己单独只用一个要好。核心原因也简单：优化建模也需要模型理解数字关系、不等式的语义等基础数学推理能力，这些是Orca-MATH类数据打下的底子。

5. 实际复现时最容易踩的坑

5.1 生成模型里的“幻觉”防不胜防

这是我在整个框架里踩得最深的一个坑。即使加了求解器验证和规则检查，LLM在生成模型时仍然会时不时冒出定义不清晰的变量、用错了的指标上标。最典型的一种是：问题描述里说的是“小时产能”，模型生成的约束里却用的是“天产能”，数值量级完全对不上。

要解决这类问题，得三层防线配合。第一层，在prompt里强制模型先提取参数表再写模型，参数表里列清楚所有量的单位、量纲、物理含义；第二层，用规则脚本检查模型里使用的变量和参数是否都出现在参数表中；第三层，靠人工抽检兜底。三层都做完，这个坑基本能填平大半。

5.2 求解器版本的“玄学”问题

不同求解器对非线性规划、整数规划的支持能力差异很大。同一个模型在SCIP里能解，在HiGHS里可能就因为某类非线性约束报错。而你在数据合成的pipeline里，验证器是把它当“合格数据”还是“不合格数据”丢掉，直接影响最终数据规模，甚至影响模型对某些题型的覆盖。

我的建议是：在pipeline里固定一个主验证求解器，同时保持版本锁死。换求解器版本后，必须先跑一遍已有的合成数据子集，确认验证结论没有系统性变化，再继续批量生成。别小看这个操作，我遇到过升级SCIP版本后，一批原本被判为不可行的模型全部变得可行了，导致前后两批数据的质量标注标准不一致，模型训练效果受到很大影响。

5.3 合成成本：你以为很便宜，其实不然

合成数据的单位成本确实比人工标注低，但架不住量大。如果你全程调商用API，单样本成本几美分，20K条数据也要上千美元。更隐蔽的是，双向生成意味着每条数据至少调用两次大模型（一次正向生成模型，一次反向生成问题描述），实际成本是翻倍的。

控制成本的思路有三个。第一，种子数据用最强的商用模型做，批量扩充切换到开源模型跑本地部署，成本能降一个数量级。第二，加一层缓存：数学结构指纹相同的问题，不需要每次都反向生成，可以复用之前生成好的高质量业务描述。第三，并行流水线跑起来，别一次调一个API等同步返回，吞吐量上去以后时间成本和财务成本都能摊薄。

5.4 评测时容易“自欺欺人”的指标

最后提醒一个评测陷阱。模型的生成结果通过了解法性检查，不代表它做对了。我见过一个模型，生成的数学模型非常规范，求解器能解、目标函数方向正确、约束符号都定义清晰——但仔细一看，它把“每辆车的载重约束”漏掉了，整个模型比原问题少了一条关键约束。这种“合法但不完整”的错误，是评测时最容易漏掉的。

怎么防？我的方法是用双向一致性评测：把模型生成的数学模型反喂给强LLM（或者同一个模型），让它转成自然语言问题描述，再与原问题做语义相似度打分，加上关键信息点比对（比如约束条数、目标方向、变量范围）。双向对不上的样本，不管模型写得再漂亮，都要人工复查。这其实也是OptMATH框架里双向生成逻辑在评测阶段的一次“复利”。

6. 最后分享一点我的实际体会

如果你问我OptMATH这个框架给这个方向带来最大的启发是什么，我的回答不是“它能造多少数据”，而是它把“数据合成”这件事从一个单向的、纯粹靠量的生产过程，变成了一个可以自我校验、自我扩增的系统工程。

方向上，后续还可以往这几个方向延展：把双向生成从优化建模扩展到决策分析（比如生成对应的敏感性分析报告）；在反向生成时控制业务描述的风格分布，让数据在财务、制造、物流等行业的覆盖更加均匀；或者用多个强LLM投票来做生成结果的一致性校验，替代部分人工抽检。

我自己在实际操作中最深的感受是，合成数据的框架就像一门手艺活，管线搭起来不难，但每一道质量关卡都省不得。双向生成、求解器验证、结构去重、人工抽检，一道都不能漏。最后顺带分享一个小技巧：做反向生成时，固定数学结构不变，但在prompt里要求LLM每一次用完全不同的行业背景和业务叙事重新包装，这样产出的样本多样性会明显好于一版prompt反复调温度采样。这个技巧看起来不起眼，但在最终的数据多样性指标上，效果非常直接。