从自然语言到最优方案：构建稳定的优化求解闭环系统-平芜编程栈

这个系列写到第8篇，终于到了最激动人也最折磨人的阶段：把前几篇零散搭好的解析、建模、求解、解释模块串成一条完整的流水线，让系统真正达成“用户说人话，系统出方案”的闭环。前几篇解决的是环境、大模型接口、求解器接入和基础提示词设计，零件都已经能跑。但零件能跑和整机好用是两回事——这一篇不铺新功能，专心解决闭环稳定性和正确性，顺便把过程中最典型的坑和最有用的调优手记整理出来。如果你正在做类似的项目，这篇内容基本就是一份少走弯路的实操参考。

先交代一下我现在这套系统的样子：用户用自然语言描述一个优化问题，比如“三个订单在三台机器上排产，每台机器的可加工时间不同，希望总拖期最小”。系统内部把它翻译成一份结构化的中间表示，再交给一个约束求解器求解，最后把结果翻译回自然语言。整个过程被拆成理解、建模、求解、解释四个环节，每个环节都有独立的校验和兜底逻辑。第8篇要重点讲的就是这套闭环如何稳定跑通。

1. 为什么必须走“中间表示”这条路

很多第一次接触这个方向的人，直觉是“把问题直接丢给大模型，让它算出答案”。这个想法对小规模、纯常识类问题偶尔有效，但对真正的组合优化问题基本撑不住。我早期也试过直接让大模型给出最优解，几个变量还能蒙对，一旦规模上来，变量之间互相牵连，它给出的答案要么不可行，要么根本说不清“为什么这就是最优”。语言模型本质上是做概率预测，不是做数学证明，让它在指数级解空间里靠生成来搜索，方向就错了。

1.1 三条技术路线对比

我梳理下来的方案其实有三条，简单对比如下：

路线	做法	优点	致命问题
直接计算	让大模型直接输出最优解和方案	实现成本最低	规模稍大必翻车，无法证明最优性
生成求解代码	让大模型写调用求解器的代码，再执行	理论上通用	代码易错、执行有安全隐患、调用接口一变就挂
生成中间表示	让大模型输出结构化的建模语言DSL，再解析后交给求解器	正确率可控、可校验、可复用	需要多写一层解析和翻译

我最终选了第三条，核心原因是“可以校验”。大模型的输出是不可靠的，而求解器是可靠但需要精确输入的。中间表示就是两者之间的翻译契约：既足够结构化，让大模型不容易发挥过头；又足够贴近业务表达，让用户能看懂。有了这层契约，我可以在中间表示上做语法检查、语义检查、变量引用检查，把大量幻觉和笔误挡在求解器之前。

1.2 DSL 的边界与 schema 设计

中间表示设计成什么样子，直接决定整个系统的上限。我的经验是：DSL要尽量小。变量类型就几种——binary、integer、float；表达式操作符就限制在加减乘、求和、for all、min、max、绝对值；维度最多两层。为什么这么做？因为DSL越大，大模型出错的空间就越大。你让它在自然语言、调度语法、求解器API之间自由切换，它一定会到处犯错误；但你只让它填一个结构明确的JSON模板，错误率会低很多。

我目前用的schema大致长这样：

{ "rewrite": "把用户问题用中文复述一遍，把隐含条件显式化", "variables": [ {"name": "x", "type": "binary", "dim": [3, 2]}, {"name": "y", "type": "integer", "dim": [3, 2], "lower": 0, "upper": 100} ], "objective": { "sense": "min", "expr": "sum_{i=0..2, j=0..1} 8*x[i][j] + 2*y[i][j]" }, "constraints": [ {"name": "capacity", "expr": "for all i in 0..2: sum_{j=0..1} 5*x[i][j] + y[i][j] <= 50"}, {"name": "once_per_machine", "expr": "for all j in 0..1: sum_{i=0..2} x[i][j] == 1"} ] }

注意里面多了一个rewrite字段。这是我从踩坑里总结出来的关键点：用户很多话不是字面意思。比如用户说“尽量让每个工人加班时间均匀一点”，这句话听起来像约束，实际上要翻译成“最小化最长加班时间”的目标；用户说“最好不要超过十个”，这也不是硬约束，而是“超过十会产生惩罚”的成本项。如果大模型直接按字面翻译成DSL，大概率会把目标写成约束，导致系统认为“压根找不到可行方案”。加上rewrite这一步，让大模型先把模糊语句显式化，错误率会显著下降。

2. 解析与校验层：把大模型的幻觉挡在求解器之外

这一步是整个系统里我最坚持的部分。很多人在做类似项目时，从大模型拿到JSON就直接塞给求解器，跑通了很开心，直到某一天发现结果错得离谱。问题就出在“中间层没有把关”。

2.1 三层校验体系

我给校验层划分了三个层次，每一层解决不同的问题：

语法校验：JSON能否解析、字段是否齐全、variables是否非空、目标表达式是否有值。
语义校验：约束表达式里引用的变量是否都在variables中声明过、维度是否匹配、上下界是否有意义、sense是min还是max。
可行性预检：预先估算一下生成的模型规模，如果变量维度明显超出合理范围，直接提示用户“问题规模过大，需要拆分描述”。

这里最容易被忽略的是“维度匹配”的坑。大模型很可能写出x[i][j]，但在后面的约束里引用x[j][i]，检查出来并不算难；但要检查sum_{i=0..2, j=0..1} x[i][j]里每个索引是否真的对得上，就得写一个简单的表达式解析器，把所有索引变量收集起来，跟声明时的维度做比对。这部分属于纯代码逻辑，每次改DSL schema都要配套更新，属于看起来不起眼、但少了它必然出事的模块。

我实测下来，加了这三层校验之后，至少拦截掉了40%的模型输出问题。其中大部分是拼写错误和字段缺失，还有一部分是“用户没说清条件，大模型自行脑补了一个不存在的常量”。这种情况最隐蔽——模型生成的DSL语法完全正确，求解器也能跑，但约束变成了形如“某常量小于等于另一个常量”的无意义限制，最后解出来一个跟真实需求毫无关系的目标值。没有校验层，这种错误根本不会报警。

2.2 失败自愈与重试策略

校验不通过，我的处理不是直接报错，而是进入“重试-反馈-再重试”的循环。核心是：把具体的校验错误反馈给大模型，让它自己改。

def validate_and_repair(spec, max_retries=2): for attempt in range(max_retries): errors = validate_spec(spec) if not errors: return spec, True feedback = build_feedback(errors) spec = llm_call(repair_prompt(feedback)) return spec, False

这个循环里最重要的是反馈信息要具体，不能只说“JSON格式错误”。我会把错误描述成“约束 capacity 中引用了未声明的变量 z，请检查变量列表”或者“目标表达式里 x[3][1] 超出了声明维度 [3, 2]”。大模型看到这种信息，像人一样知道该怎么修正。实测加入具体反馈后，一次通过率从70%左右提升到了95%以上。

还有一个很常见的防御：即使你反复强调“不要输出markdown代码块”，大模型偶尔还会在JSON外面套一层```json。解析前一律先把文本里第一个{到最后一个}之间的内容截取出来，再去做JSON解析。这个操作虽然土，但能避免大量无意义的解析失败。

2.3 从Prompt端降低幻觉

重试只是补救，更有效的是让大模型从一开始就少犯错。我在解析阶段的Prompt设计上有几个固定原则：

温度设为0或者极低，关闭随机性。
一次输出完整JSON，不要开启流式输出，因为流式模式更容易截断。
给出2到3个完整示例，其中至少包括一个“带陷阱”的样例。比如用户说“尽量均匀”，示例里就要展示如何把它转成min最大值的表达式。
在Prompt末尾明确加上一句“如果没有可行方案，请输出空模型并说明原因”，防止模型自作主张编造答案。

这些原则总结起来就是：尽量让模型做的事情变得窄而具体。模型不会因为提示词漂亮就变聪明，但会因为你把选择范围缩小而少犯错。这也是整个系统里“大模型用量最小但效果最明显”的地方。

3. 求解适配层：翻译细节决定成败

经过校验和修复的DSL，理论上已经是一份干净的建模描述，但离求解器能跑还有一段路。求解器不认识x[i][j]这种带名字的变量，它只认整数索引；DSL里的for all和sum也需要展开成一条条具体的约束和表达式。这一层翻译如果不做好，前面所有的校验都白做。

3.1 求解器选型心得

我目前用的是开源约束求解器CP-SAT，没有上更复杂的商业求解器。原因很简单：自然语言描述出来的优化问题，大多数是组合优化类的，涉及排产、分配、选路、资源调度，这些场景天然需要布尔变量、all_different、累积资源、if-then约束。CP-SAT对这类问题支持很顺，写建模代码时几乎可以和业务语言一一对应。纯线性规划或大规模混合整数规划场景，可以再考虑换成更偏数值计算的求解器，但对于“自然语言转方案”这个业务目标，至少前80%的需求用CP-SAT已经足够。

这也意味着DSL的表达式语法要限制在加减乘、系数乘法、sum、min、max、abs这些范围内。乘除法和非线性表达式是约束求解器的短板。用户如果说单位成本随数量阶梯变化，我会引导模型拆分成分段线性近似，而不会让它在DSL里直接写乘法。

3.2 变量映射与模型构建

变量映射是这一层最容易出bug的地方。DSL里变量的名字是给人看的，求解器里必须换成数字索引。我习惯用一个统一入口的ModelBuilder来管理映射：

class ModelBuilder: def __init__(self): self._var_map = {} self._counter = 0 def declare(self, name, shape, lower, upper): indices = [] for coord in product(*[range(d) for d in shape]): var = solver.NewIntVar(lower, upper, f"{name}_{coord}") indices.append(var) self._var_map[name] = {"shape": shape, "indices": indices}

之后所有约束生成都通过这个ModelBuilder来引用变量，业务逻辑里不直接写数字索引。为什么要这么做？因为变量映射一旦复杂起来，手写索引几乎必错。特别是从DSL里解析出x[2][1]这样的坐标，再把它换算成扁平数组里的位置，中间一旦错一位，结果就是静默错误，不报异常、不影响运行，但答案就是不对。封装成builder之后，这个错误就变成了“类型错误”或“索引越界”，至少能被及时发现。

约束展开也是同样思路：DSL里的for all i in 0..2会在Python里循环展开成3条具体约束，每条约束内部再按索引逐项累加。展开后的约束数量可以直接打印出来做粗略评估，比如“这个模型一共生成了37个变量、18条约束”，一眼就能看出规模是否合理。

3.3 数值处理与最优性陷阱

这里有个特别值得注意的细节：CP-SAT是整数求解器，所有系数和变量值必须是整数。用户说“加工时间是0.5小时”，你直接写进DSL，模型要么报错，要么自作主张截断成0，最后得到一个错误的解。我的处理方式是在解析阶段做统一缩放：给所有浮点系数乘上一个公共放大因子，比如100，求解完成后在输出阶段再除以100还原。这个流程必须在进入求解器之前统一完成，不能一半变量放大一半不放大，否则目标函数量纲错乱，解出来的方案根本没意义。

此外还有一个我踩过的坑：目标方向写反。用户说“最大化利润”，但求解内部通常以最小化为主，需要把目标乘负号转换成最小化形式。这个转换在适配层代码里处理，而不是让大模型处理。大模型在DSL里写sense: "max"，适配层看到它以后自动取反生成求解模型，返回来解释结果时再取反还原。这样做的好处是，解释层永远对用户说“目标值最大化”，用户不会看到奇怪的负数。

4. 端到端流水线实现：一次完整闭环的代码走读

大概架构细化得差不多了，下面看完整流水线。目前系统的主流程大概是这样：

def solve_nl(user_input): spec = parse_to_spec(user_input) spec, ok = validate_and_repair(spec) if not ok: return fallback_ask(spec) model = build_solver_model(spec) status = model.Solve() if status != OPTIMAL: return explain_infeasible(spec, status) result = extract_results(spec, model) return explain_results(user_input, spec, result)

这段代码看着简单，但每一步背后都有不少讲究。

4.1 解析环节：一边输出DSL一边输出问题重写

parse_to_spec这一步，在我的实现里是让大模型一次性输出两个东西：问题重写rewrite和完整的DSL。问题重写的作用不仅是给用户看，更是让大模型自己先理一遍需求，相当于让它“想清楚再说”。我试过跳过rewrite直接生成DSL，约束遗漏率明显上升。有了rewrite，相当于给大模型加了一个“中间思考步骤”，虽然会增加一点token消耗，但换来的是解析质量的大幅提升。

我还做了一件很重要的事：解析完成后，把rewrite和DSL一起保存到操作日志里。这样当用户发现“结果和想的不一样”时，我能立刻回看系统当初是怎么理解这个需求的。很多问题根本不用改代码，看一眼日志就能定位到“模型漏掉了某个约束”还是“用户描述确实有歧义”。

4.2 解释环节：不要让大模型“自由发挥”

结果解释这一步也隐藏一个大坑。求解器返回的是一个目标值加一堆变量取值数组，比如x(0,0)=1这种。如果直接把这种数字丢给大模型去解释，它会往里面加很多自己的理解，甚至出现“图穷匕见式的编造”。我的做法是先把求解结果整理成一个结构化的中间结果表，包含每个变量的业务含义、取值、关键约束的满足情况，再连同用户的原始输入和问题重写一起发给大模型。

{ "question_rewrite": "在2台机器上安排3个任务，使最大完工时间最小", "objective_value": 17, "solutions": [ {"var": "x", "index": [0, 0], "value": 1, "meaning": "任务0安排在机器0"}, {"var": "x", "index": [2, 1], "value": 1, "meaning": "任务2安排在机器1"} ] }

这样大模型要做的只是把这个结构化结果组织成一段通顺的中文描述，它不需要知道求解逻辑，也不需要推理最优性，当然也就没有太多“自由发挥”的空间。这个方法让解释环节的幻觉率降到了相当低的水平。

4.3 一个完整示例

用一个简化案例走一遍：用户输入“有两台机器A和B，三个任务1、2、3，每个任务在不同机器上的加工时间不一样，任务1在A上要4小时在B上要6小时，任务2在A上要7小时在B上要3小时，任务3在A上要5小时在B上要5小时，安排任务给机器，使总加工时间最小”。

解析出来的DSL大概简化成这样：

{ "rewrite": "为三个任务分别指派一台机器，使得三台机器上的总加工时间之和最小", "variables": [ {"name": "assign", "type": "binary", "dim": [3, 2]} ], "objective": { "sense": "min", "expr": "sum_{i=0..2, j=0..1} time[i][j] * assign[i][j]" }, "constraints": [ {"name": "one_machine_per_task", "expr": "for all i in 0..2: sum_{j=0..1} assign[i][j] == 1"} ] }

适配层把这个DSL变成求解器模型，求解得到目标值21，方案是任务1给A、任务2和3给B。解释层最终输出类似：“最优方案是将任务1分配给机器A，任务2和任务3分配给机器B，总加工时间为21小时。该方案确保了每个任务恰被分配一次。”用户看到的是一个能直接理解并验证的答案，而里面发生的建模和求解过程完全被封装掉了。

5. 评测与回归：没有评测就是没有迭代

系统能跑通之后，最紧迫的问题其实是“我改了一个提示词，怎么知道系统是变好了还是变坏了”。这个问题不解决，后面所有优化都是盲人摸象。只要做自然语言驱动的系统，就绕不开评测和回归这一关。

5.1 问题集设计

我建了一个自有的测试问题集，分成三档难度：

简单档：2到3个变量、1个约束、目标单一。主要用于验证基础链路是否通畅、DSL schema是否兼容。
中等档：5到10个变量、两三个约束、带sum和for all。用来验证常见的排产、分配场景。
复杂档：带if-then约束、需要目标权衡、有隐含条件或语义陷阱。用来验证大模型对“用户没说透的话”的理解能力。

每个问题都要附带期望最优值和至少一种最优方案的参考答案。参考答案怎么来？我先用求解器离线跑一遍，确认模型确实可解，得到标准答案后固化到测试集里。这样后续每一次回归，都能拿系统输出和标准答案对比。

边界用例同样重要：比如“用户描述里没有明确目标方向”“用户说的是互相矛盾的约束”“用户给的规模超出处理范围”。这些用例未必都能成功求解，但系统至少不能静默崩溃，必须有合理的兜底输出。

5.2 三类核心指标

我主要看三个指标：

结构合法率：大模型输出通过三层校验的比例。低于90%说明Prompt或schema设计有问题。
求解成功率：合法模型里能求得最优解或可行解的比例。这里要特别留意，无解也可能是真实无解，不能一刀切认为是系统错误。
语义正确率：最终结果和参考答案一致，或者目标值差距在允许范围内的比例。这是最硬的指标，直接反映系统有没有真正理解用户。

第三个指标里最大的敌人是“无报错错误”：系统返回了一个看起来正常的目标值，但模型建错了，比如把“总利润最大化”理解成“总收入最大化”，漏掉了成本项。这种案例的数量级虽然不多，但每个都是真实事故。我的处理是在测试集里加入“目标函数抽查”，定期把解析阶段产生的DSL喂给一个小型的人工复核流程，检查目标表达式和约束是否与用户意图一致。

5.3 回归与一致性检查

评测不是为了追求100分，而是为了在每次改动后知道“影响面”。我现在每次换大模型版本、调整DSL schema、修改Prompt后，都会把整套测试集全部跑一遍，对比前后两个版本的指标变化。如果结构合法率上升但语义正确率下降，那说明模型“更听话了但没听懂”，问题多半出在schema约束过死，把某些合法的表达方式排除掉了。

另外，我在复杂用例上还保留了一个双模型交叉验证的选项：解析阶段用两个不同的大模型各生成一份DSL，如果两份DSL在关键结构上一致，就认为高置信，否则引入人工确认。这个做法会显著增加成本，所以只对真正复杂的场景启用，但作为兜底它非常有用。