我先说个真实到有点扎心的场景。某天业务负责人发来一段话“接下来6天每天安排2个人值班组里4个人每个人至少值1天最多值4天甲在第1天和第2天不能值班尽量让大家值班天数均匀一点。”做过排班调度的人看到这种需求都会心一笑——这还算是描述清楚的更多时候是“你看着排”“别老让一个人扛”“新人先别上夜班”这种充满了指代和模糊信息的表达。传统做法是把这些大白话翻译成需求文档再让算法工程师转成约束清单和数学模型最后扔进求解器里跑。整个链条里最费时间的根本不在求解而在“翻译”。我当时就想能不能把整个链条反过来让一个系统直接读这段话自己把“每天需要2个人”抽成约束把“尽量均匀”抽成目标函数自动建好模型求解后直接给出一份可以用的排班表。这个想法就是“自然语言优化求解系统”的起点。简单说它的输入是一段大白话输出是一个已经求解完成的可行方案。这篇是这个系列的第0-1篇目标只有一个打通“自然语言 → 优化模型 → 求解器 → 人类可读方案”的最小闭环。适合正在做企业流程自动化、想把大模型能力接进运筹优化场景、或者单纯对“让机器听懂调度需求”感兴趣的读者参考。1. 为什么要把“人话”交给求解器那个被来回翻译的问题1.1 传统“需求→模型”链路到底慢在哪做过排班、调度或产能分配的人都清楚一件事业务方说出来的话和算法工程师写出来的模型中间隔着一整条翻译链。业务方的语言是自然语言充满了省略、指代和隐性前提比如“尽量均匀”“按老规矩来”“老王比较特殊”这类表达信息密度极高但机器完全无法直接处理。算法工程师拿到需求后需要做几件事把“每天安排2个人”变成覆盖约束把“每个人至少值1天”变成变量下界把“甲在第1天不能值班”变成布尔变量的固定取值把“尽量均匀”变成最小化最大最少值班天数之差的目标函数。这个过程听起来不难但一旦问题规模变大、约束变多需求方和建模人之间就得反复确认每次调整都要重新对齐一遍。最麻烦的是有些约束冲突要到求解阶段才能暴露而业务方通常没法直观理解“为什么这几个条件不能同时满足”。真正的瓶颈是求解器算得再快也架不住翻译环节反复改、反复沟通。至少要有一层东西能够把自然语言直接带到数学模型面前哪怕只是先做到“约束能对上号”整个效率就会完全不同。1.2 哪些问题最值得做成“自然语言求解”不是所有优化问题都适合自然语言入口这点我在项目立项之初就划清了范围。适合做自然语言求解的问题通常有三个特征有明确的决策变量、约束能够结构化、目标可以用数值衡量。典型场景包括排班排程、产线调度、仓库库位分配、运输路线安排、库存补货策略。这些场景有一个共同点业务人员习惯用日常语言描述限制条件但这些条件在本质上又非常结构化。比如排班里的“每天需要几个人”“谁不能上夜班”库位分配里的“A类货靠近门口”“通道宽度不能低于两米”都是可以转成约束表达的。还有一个更实际的理由这类问题的语言表达比较固定。排班场景里翻来覆去就是“几天”“几个人”“谁不能”“尽量均匀”库存场景里无非是“最低库存”“到货量”“仓储上限”。这意味着即使不依赖大模型一套规则模板也能兜住大部分常见表达这对0-1版本的稳定性极其有利。1.3 能力边界这个系统不打算做什么建系统最忌讳的是什么都想做。我这版明确划了几条不做的事非线性复杂优化不做大规模组合爆炸问题不做需要实时流式数据的动态决策不做通用数学建模语言也不做。原因很简单。0-1版本的核心目标是验证链路而不是解决所有优化问题。自然语言优化求解系统在一个狭窄的范围内能做到“识别准确、约束成立、结果可解释”就已经比“什么都能聊但什么都算不准”的泛化方案有价值得多。换句话说这个系统的身份是“翻译官”不是“求解器替代品”真正的计算能力仍然来自底层数学求解器系统要做的是把自然语言翻译成求解器听得懂的精确表达。2. 系统骨架先定下来NLU、建模、求解三层各干各的2.1 为什么不能“提示词直出答案”很多人听到“自然语言优化求解系统”的第一反应是直接用大模型生成排班结果不就行了我在前期试验里踩过这个坑结论是非常不可靠。让大模型直接回答“这6天怎么排”它确实能给出一个像模像样的表但仔细检查会发现三个致命问题。第一数值约束无法保证。它给出的排班表很可能违反“每人最多值4天”这种硬约束因为大模型的本质是根据概率预测文本不是进行数学求解。第二没有全局搜索能力。排班问题看起来简单但搜索空间非常大大模型只能凭“经验”猜一个局部合理的方案根本不能保证目标最优。第三输出不稳定。同一句话问两次它可能给出两完全不同的排班这在生产环境中不能接受。但大模型也不是没用问题在于使用姿势。它最适合干的活不是“算”而是“听”——把自然语言翻译成结构化表达。把“听懂”和“算对”这两件事彻底分开是我在这篇文章里最想强调的架构决策。2.2 三层职责NLU层、建模层、求解层整套系统我拆成了三层外加一个输出解释模块。NLU层负责把自然语言转成中间表示输出一份结构化的JSON里面包含对象列表、时间范围、硬约束、软目标。建模层接收这份JSON把它映射到一个具体的求解模型上比如OR-Tools的CP-SAT模型。求解层负责实际计算调用求解器求出可行解和目标值。最后再有一个输出解释模块把求解结果回译成人类能直接看懂的文字和表格。这个分层设计最关键的地方在于中间表示。它不是直接生成求解代码而是生成一份“人和机器都能读”的契约。调试的时候打开JSON一看立刻就知道系统“听懂了多少、听错了什么”这比直接看一堆求解日志高效得多。2.3 技术选型为什么是OR-Tools加JSON中间层技术选型上我做了几次对比最终定下“规则模板大模型抽取”双轨做NLU、JSON做中间表示、OR-Tools的CP-SAT做求解器。OR-Tools的CP-SAT求解器处理排班这类问题非常顺手。这类问题里有大量逻辑约束比如某人某天是否值班、每天必须覆盖几个人、人员总天数上限等CP-SAT都表达得很自然Python API也简单中小规模问题求解速度非常快。JSON做中间表示则是因为它容易校验、容易可视化也方便后续替换底层求解器——今天可以用CP-SAT明天想切换到线性规划求解器只需要改建模层的映射逻辑NLU层的输出完全不用动。大模型在这里的角色是“覆盖变体”规则模板是“保证下限”。规则模板只能识别固定的说法但大模型可以把“老王周一周二别安排”“尽量平均点”这种变体表达也抽出来。两个手段配合才能既稳定又灵活。3. 从一句话到一条约束NLU层的第一版实现3.1 先定义“人话”里面到底有什么写抽取器之前我先把输入里可能出现的信息维度列了一遍。排班类需求无论怎么表达最后都逃不开这几类信息对象列表也就是谁参与排班时间范围一共排多少天资源需求每天需要几个人硬约束必须满足的边界比如某人某天不能值班、每天覆盖人数固定软目标用户说“尽量”“最好”“不希望”的那些诉求。把这几个维度定义清楚抽取任务就变成了“归类填空”。一句话进来先判断它属于哪个维度再填进对应字段。比如“甲在第1天和第2天不能值班”核心就是两个信息对象是甲约束类型是禁止值班作用天数是第1和第2天。至于“不能”这个词就是触发禁止约束的关键信号。这套思路撑起了整个NLU层的骨架。3.2 规则模板先抓最稳定的表达0-1版本我先写了一套手写规则提取器。不要小看这步规则模板的价值在于行为完全透明、输出确定、容易调试。比如“每天需要X个人”这种极常见的表达用正则就能稳定抓住。这类固定模式是规则的舒适区但规则的问题也显而易见——有多少规则才能覆盖多少说法。我在实际测试中写了几十条正则覆盖了“每天需要”“每人最多”“每人至少”“不能值班”“尽量均匀”等常见说法但对于“周日那天人手别太紧”“老带新比例控制一下”这种表达就完全无能为力。所以我的策略是规则模板只用来抓最固定的量剩下不确定的表达全部交给大模型补位两边汇合后做归一化。3.3 大模型抽取提示词里给schema比给自然语言有用调大模型抽取的那段时间我最大的体会是与其在提示词里长篇大论描述什么是排班问题不如直接给结构化格式。我最终用的提示词模板包含四块内容任务定义说明要从用户输入中提取排班问题的结构化要素输出格式强制要求输出JSON字段固定少样本示例给一两个正面和反面例子字段约束明确每个字段的取值范围。少样本示例是最关键的一步。模型一旦看到“输入什么就输出什么”的示例输出的稳定度会提升非常明显。我给了两条示例一条带硬约束一条带软目标模型基本就能把“尽量均匀”正确地归到软目标字段而不是当成硬约束写死。大模型抽取之后的输出差不多长这样{ people: [甲, 乙, 丙, 丁], horizon: 6, daily_demand: 2, hard_constraints: [ {type: forbidden, person: 甲, day: 0}, {type: forbidden, person: 甲, day: 1}, {type: min_work_days, person: 甲, value: 1}, {type: min_work_days, person: 乙, value: 1}, {type: min_work_days, person: 丙, value: 1}, {type: min_work_days, person: 丁, value: 1}, {type: max_work_days, person: 甲, value: 4}, {type: max_work_days, person: 乙, value: 4}, {type: max_work_days, person: 丙, value: 4}, {type: max_work_days, person: 丁, value: 4} ], soft_objective: { type: balance } }这份JSON就是整条链路的“中间表示”。注意系统没有让大模型直接输出排班代码而是让它输出数据。代码由我们自己写这样最可控。3.4 中间表示必须加一道校验器大模型的抽取结果不能直接拿去建模。我在实际测试中发现它偶尔会抽错对象名可能把“甲”写成“假”会把“至少三个人”的运算符抽反还会把“第6天”抽到horizon之外。这种错误如果直接落到求解器里轻则建模失败重则产生一个完全错误的“最优解”。所以我加了一个轻量校验函数做三件事检查horizon和对象列表是否合理比如天数不能超过30、人数不能为0检查取值是否越界比如某人的禁止值班日期必须在horizon范围内检查硬约束之间是否有明显的矛盾比如“每天需要3个人”但对象一共只有2个人这种低级冲突。校验失败直接返回“哪句话没听懂”而不是把错误数据丢给求解器。这一步非常值。4. 把约束翻译成求解器听得懂的语言建模层设计4.1 为什么中间表示不直接生成求解代码我在早期原型里走过一个弯路直接让NLU层输出OR-Tools的Python代码想着省掉一层转换。结果调试起来非常痛苦——抽取结果稍微变一点代码就得重新生成而且生成的代码里一旦混入错误变量名排查成本特别高。改成JSON中间表示之后整个逻辑顺了很多。JSON的好处有三个人类可读可改调试的时候能直接看到系统“认为”的约束是什么可以独立编写映射逻辑把JSON转换成任意后端求解模型后续如果要做对话式修改只需要改这份JSON不需要重新跑一遍NLU抽取。你可以把JSON理解成自然语言和数学表达之间的“契约层”NLU和建模各自面向契约编程互不污染。4.2 从中间表示到CP-SAT的映射规则建模层的核心是一张映射表每种JSON字段对应一类模型操作。这张表也是整个系统最值钱的部分。中间表示字段模型操作people定义对象集合horizon定义时间索引daily_demand每天值班人数加和等于需求值forbidden对应BoolVar固定为0min_work_days个人值班天数加和大于等于给定值max_work_days个人值班天数加和小于等于给定值soft_objective.balance添加min/max辅助变量目标为最小化两者之差每条映射的“为什么”都很明确。比如说daily_demand用户说的是“每天需要2个人”这是一个覆盖约束意味着每天值班的BoolVar之和必须等于2既不能少更不能多否则排班表就缺岗或冗余。再比如forbidden“甲在第1天不能值班”直接把对应变量固定为0这就是硬约束的本质。min和max同理分别对应不等式约束的下界和上界。4.3 从JSON到CP-SAT一个可运行的映射函数把映射规则落成Python代码之后整个建模层就非常薄了。下面是我这版的核心建模函数重点展示如何把JSON里的约束逐条翻译成CP-SAT模型from ortools.sat.python import cp_model def build_model(ir): model cp_model.CpModel() people ir[people] days range(ir[horizon]) x {} for p in people: for d in days: x[p, d] model.NewBoolVar(fx_{p}_{d}) # 每天必须正好有 daily_demand 个人值班 for d in days: model.Add(sum(x[p, d] for p in people) ir[daily_demand]) # 统计每个人总值班天数套用硬约束 work {} for p in people: work[p] sum(x[p, d] for d in days) for c in ir[hard_constraints]: if c[person] p and c[type] min_work_days: model.Add(work[p] c[value]) if c[person] p and c[type] max_work_days: model.Add(work[p] c[value]) if c[type] forbidden: model.Add(x[c[person], c[day]] 0) return model, x, work这段代码只做了“配置”工作没有任何业务逻辑。无论未来是排班还是库位分配只要中间表示的字段定义不变建模层就始终是这个套路。这也是我坚持“JSON契约层”的原因建模层越薄越稳定。4.4 软目标怎么做把“尽量”变成数学表达式自然语言里最特殊的一类表达是“尽量”“最好”“不希望”。它不像硬约束那样必须满足而是希望在满足硬约束的前提下尽量达成。这就要引入软目标的概念。以“尽量让每个人值班天数均匀”为例我把它建模成最小化“最大值班天数与最小值班天数之差”。当这个差值为0时说明每个人值班天数完全一致无法做到0时求解器会尽量把它压到最小。具体做法是创建两个辅助整数变量min_work和max_work把每个人的总值班天数分别约束为大于等于min_work、小于等于max_work然后把目标函数设为最小化max_work减min_work。软目标处理的关键是抽取阶段就要把“尽量”这类词识别出来放进objective字段而不是当成硬约束。系统求解完还要把结果回显给用户时注明“这条是尽力而为的如果和硬约束冲突会被牺牲”。这样的透明度能避免很多使用上的误解。5. 端到端跑通第一个小Demo把排班问题走完一遍5.1 测试用例一段看起来很普通的“人话”我这里选了一个非常典型的排班输入包含对象、时间范围、资源需求、硬约束和软目标接下来6天每天需要2个人值班项目组有甲、乙、丙、丁4个人。每人最多值班4天至少值班1天。甲在第1天和第2天不能值班。尽量让每个人的值班总天数均匀。这段输入在业务场景里极具代表性。它同时包含了“必须满足”的硬约束和“尽量做到就行”的软目标如果把软目标理解成硬约束模型会直接无解如果漏掉“甲不能值班”这条排班结果就会出现实际业务中的冲突。这一条用例能同时验证NLU抽取、建模和求解三个环节。5.2 完整代码可以直接跑的最小版本下面这段代码我把NLU层简化成了直接给一份JSON中间表示因为这一篇的重点是打通链路大模型抽取在上一篇已经验证过。实际工程中这个位置就是接大模型输出的入口。# pip install ortools from ortools.sat.python import cp_model ir { people: [甲, 乙, 丙, 丁], horizon: 6, daily_demand: 2, hard_constraints: [ {type: forbidden, person: 甲, day: 0}, {type: forbidden, person: 甲, day: 1}, {type: min_work_days, person: 甲, value: 1}, {type: min_work_days, person: 乙, value: 1}, {type: min_work_days, person: 丙, value: 1}, {type: min_work_days, person: 丁, value: 1}, {type: max_work_days, person: 甲, value: 4}, {type: max_work_days, person: 乙, value: 4}, {type: max_work_days, person: 丙, value: 4}, {type: max_work_days, person: 丁, value: 4} ], soft_objective: {type: balance} } model cp_model.CpModel() people ir[people] days range(ir[horizon]) x {} for p in people: for d in days: x[p, d] model.NewBoolVar(fx_{p}_{d}) for d in days: model.Add(sum(x[p, d] for p in people) ir[daily_demand]) work {} for p in people: work[p] sum(x[p, d] for d in days) for c in ir[hard_constraints]: if c[person] p and c[type] min_work_days: model.Add(work[p] c[value]) if c[person] p and c[type] max_work_days: model.Add(work[p] c[value]) for c in ir[hard_constraints]: if c[type] forbidden: model.Add(x[c[person], c[day]] 0) min_work model.NewIntVar(0, 4, min_work) max_work model.NewIntVar(0, 4, max_work) for p in people: model.Add(work[p] min_work) model.Add(work[p] max_work) model.Minimize(max_work - min_work) solver cp_model.CpSolver() status solver.Solve(model) print(solver.StatusName(status)) if status in (cp_model.OPTIMAL, cp_model.FEASIBLE): for d in days: print(f第{d 1}天: .join(p for p in people if solver.Value(x[p, d]) 1)) print(目标值(最大值班天数-最小值班天数):, solver.ObjectiveValue())这段代码就是整个0-1版本的精髓从中间表示到模型、从模型到求解、从求解到可读输出全部浓缩在几十行Python里。5.3 运行结果与观察在我本机跑出来的结果如下第1天: 丙 丁 第2天: 乙 丁 第3天: 甲 乙 第4天: 甲 丙 第5天: 甲 丁 第6天: 乙 丙 目标值(最大值班天数-最小值班天数): 0逐个检查每天都是2个人值班满足覆盖约束甲只在第3、4、5天出现第1、2天确实没排四个人的总值班天数分别为甲3天、乙3天、丙3天、丁3天完全均匀目标值为0这已经是最优情况。整个过程求解速度极快几乎是一瞬间就出了结果。这个Demo虽然简单但完整地验证了整条链路的可行性。排班问题在一段时间里一直是运筹优化领域很常见的测试场景就是因为它的约束类型足够丰富、结果容易验证同时又非常贴近真实业务。5.4 把结果“回译”给人看的一步我最初只输出排班表后来发现实际使用中远远不够。业务人员不关心“谁在第几行”他们想看到的是“第1天谁值班”“甲这周一共值了几天”“有没有人值班天数明显偏多”。所以我在输出模块里加了一个回译模板把求解结果重新组织成普通人能直接读的表述。回译的内容包括两部分按天展示值班名单按人统计值班总数。这样一来用户不用读懂CP-SAT的任何概念只需要看一张表就知道系统给出的方案是什么。0-1版本先做这种简单的模板回译后续版本才考虑生成“为什么这样排”的完整解释。6. 这版实现的经验与局限以及0-2要补的功课6.1 踩过的坑NLU层最容易翻车的地方第一个坑是日期表达不统一。“第1天”“下周一”“后天”这些表达在同一个输入里混着出现时抽取器很容易把时间范围理解错。0-1版本里我干脆把所有测试用例统一成“第1天到第N天”把日期归一化的问题留到0-2处理。这个取舍很实际先把主干链路跑通再处理分支细节。第二个坑是“至少”和“最多”的运算符混淆。“每天至少3个人”和“每天最多3个人”在输出JSON里对应完全不同的不等式方向但大模型偶尔会把方向搞反。我后来在提示词里专门加了对比示例并且在校验器里检查这两种约束是否同时出现且数值矛盾。第三个坑是软目标和硬约束的混淆。“尽量均匀”这种话如果被当成硬约束处理问题大概率变成无解。所以我在NLU抽取规则里把“尽量”“最好”“不希望”“优先”等语气词认定为软目标信号绝不落入硬约束列表。6.2 调优经验提示词给schema结果出奇地稳实际操作下来我总结了三条比较实用的经验。第一给模型输出格式时与其用文字描述JSON不如直接给一个JSON结构示例和反例模型照着样例填字段的成功率会高很多。第二抽取任务中的“负面表达”要单独列出来“不能”“不要”“禁止”“不得”都要映射到同一个forbidden类型避免模型自己发明字段。第三校验规则要写双向的既写在大模型提示词里告诉它取值范围也写在代码里做硬校验两边同时生效才能挡住大部分脏数据。这些经验说出来不多但都是反复试错之后留下来的有效做法比调大模型本身的参数更管用。6.3 当前局限与0-2方向这版0-1系统的边界非常明确。它目前只支持布尔变量和整数变量只支持线性约束和逻辑约束。如果输入里出现“成本随人数增加呈阶梯式上涨”这类非线性描述我的做法是直接拒绝而不是硬建模。非线性问题的自然语言表达边界本身就模糊0-1版本不做是对用户负责。它还不支持多轮对话式修改。用户如果说“这个方案里甲值太多了重新排一下”当前系统只能重新跑一遍完整流程没法记住上次调整的上下文。0-2版本我计划把中间表示改造成可编辑对象让用户基于上一轮结果做增量修改。求解后端目前也只有CP-SAT一条路。如果未来要处理几千人规模的大排班问题CP-SAT这种精确求解器可能撑不住到时候我的思路是把同一份JSON中间表示映射到本地搜索求解器或线性规划后端做大规模启发式求解。这个扩展路径正是当初坚持JSON契约层的回报。这套0-1版本做完我自己最大的体会是自然语言优化求解系统的难点根本不在求解而在“让系统准确知道自己听懂了多少”。中间表示就是这个“听懂”的度量衡它能把系统的理解过程暴露给开发者看也能把错误拦截在任何误算发生之前。下一篇0-2我会重点补两块内容一是多轮对话式约束修改让方案可以基于反馈迭代调整二是约束冲突的自动解释让系统在没有可行解时能直接告诉用户问题出在哪句话上。这个方向把大模型的泛化能力和运筹求解的精确性捏在一起值得慢慢打磨。
我先说个真实到有点扎心的场景。某天业务负责人发来一段话“接下来6天每天安排2个人值班组里4个人每个人至少值1天最多值4天甲在第1天和第2天不能值班尽量让大家值班天数均匀一点。”做过排班调度的人看到这种需求都会心一笑——这还算是描述清楚的更多时候是“你看着排”“别老让一个人扛”“新人先别上夜班”这种充满了指代和模糊信息的表达。传统做法是把这些大白话翻译成需求文档再让算法工程师转成约束清单和数学模型最后扔进求解器里跑。整个链条里最费时间的根本不在求解而在“翻译”。我当时就想能不能把整个链条反过来让一个系统直接读这段话自己把“每天需要2个人”抽成约束把“尽量均匀”抽成目标函数自动建好模型求解后直接给出一份可以用的排班表。这个想法就是“自然语言优化求解系统”的起点。简单说它的输入是一段大白话输出是一个已经求解完成的可行方案。这篇是这个系列的第0-1篇目标只有一个打通“自然语言 → 优化模型 → 求解器 → 人类可读方案”的最小闭环。适合正在做企业流程自动化、想把大模型能力接进运筹优化场景、或者单纯对“让机器听懂调度需求”感兴趣的读者参考。1. 为什么要把“人话”交给求解器那个被来回翻译的问题1.1 传统“需求→模型”链路到底慢在哪做过排班、调度或产能分配的人都清楚一件事业务方说出来的话和算法工程师写出来的模型中间隔着一整条翻译链。业务方的语言是自然语言充满了省略、指代和隐性前提比如“尽量均匀”“按老规矩来”“老王比较特殊”这类表达信息密度极高但机器完全无法直接处理。算法工程师拿到需求后需要做几件事把“每天安排2个人”变成覆盖约束把“每个人至少值1天”变成变量下界把“甲在第1天不能值班”变成布尔变量的固定取值把“尽量均匀”变成最小化最大最少值班天数之差的目标函数。这个过程听起来不难但一旦问题规模变大、约束变多需求方和建模人之间就得反复确认每次调整都要重新对齐一遍。最麻烦的是有些约束冲突要到求解阶段才能暴露而业务方通常没法直观理解“为什么这几个条件不能同时满足”。真正的瓶颈是求解器算得再快也架不住翻译环节反复改、反复沟通。至少要有一层东西能够把自然语言直接带到数学模型面前哪怕只是先做到“约束能对上号”整个效率就会完全不同。1.2 哪些问题最值得做成“自然语言求解”不是所有优化问题都适合自然语言入口这点我在项目立项之初就划清了范围。适合做自然语言求解的问题通常有三个特征有明确的决策变量、约束能够结构化、目标可以用数值衡量。典型场景包括排班排程、产线调度、仓库库位分配、运输路线安排、库存补货策略。这些场景有一个共同点业务人员习惯用日常语言描述限制条件但这些条件在本质上又非常结构化。比如排班里的“每天需要几个人”“谁不能上夜班”库位分配里的“A类货靠近门口”“通道宽度不能低于两米”都是可以转成约束表达的。还有一个更实际的理由这类问题的语言表达比较固定。排班场景里翻来覆去就是“几天”“几个人”“谁不能”“尽量均匀”库存场景里无非是“最低库存”“到货量”“仓储上限”。这意味着即使不依赖大模型一套规则模板也能兜住大部分常见表达这对0-1版本的稳定性极其有利。1.3 能力边界这个系统不打算做什么建系统最忌讳的是什么都想做。我这版明确划了几条不做的事非线性复杂优化不做大规模组合爆炸问题不做需要实时流式数据的动态决策不做通用数学建模语言也不做。原因很简单。0-1版本的核心目标是验证链路而不是解决所有优化问题。自然语言优化求解系统在一个狭窄的范围内能做到“识别准确、约束成立、结果可解释”就已经比“什么都能聊但什么都算不准”的泛化方案有价值得多。换句话说这个系统的身份是“翻译官”不是“求解器替代品”真正的计算能力仍然来自底层数学求解器系统要做的是把自然语言翻译成求解器听得懂的精确表达。2. 系统骨架先定下来NLU、建模、求解三层各干各的2.1 为什么不能“提示词直出答案”很多人听到“自然语言优化求解系统”的第一反应是直接用大模型生成排班结果不就行了我在前期试验里踩过这个坑结论是非常不可靠。让大模型直接回答“这6天怎么排”它确实能给出一个像模像样的表但仔细检查会发现三个致命问题。第一数值约束无法保证。它给出的排班表很可能违反“每人最多值4天”这种硬约束因为大模型的本质是根据概率预测文本不是进行数学求解。第二没有全局搜索能力。排班问题看起来简单但搜索空间非常大大模型只能凭“经验”猜一个局部合理的方案根本不能保证目标最优。第三输出不稳定。同一句话问两次它可能给出两完全不同的排班这在生产环境中不能接受。但大模型也不是没用问题在于使用姿势。它最适合干的活不是“算”而是“听”——把自然语言翻译成结构化表达。把“听懂”和“算对”这两件事彻底分开是我在这篇文章里最想强调的架构决策。2.2 三层职责NLU层、建模层、求解层整套系统我拆成了三层外加一个输出解释模块。NLU层负责把自然语言转成中间表示输出一份结构化的JSON里面包含对象列表、时间范围、硬约束、软目标。建模层接收这份JSON把它映射到一个具体的求解模型上比如OR-Tools的CP-SAT模型。求解层负责实际计算调用求解器求出可行解和目标值。最后再有一个输出解释模块把求解结果回译成人类能直接看懂的文字和表格。这个分层设计最关键的地方在于中间表示。它不是直接生成求解代码而是生成一份“人和机器都能读”的契约。调试的时候打开JSON一看立刻就知道系统“听懂了多少、听错了什么”这比直接看一堆求解日志高效得多。2.3 技术选型为什么是OR-Tools加JSON中间层技术选型上我做了几次对比最终定下“规则模板大模型抽取”双轨做NLU、JSON做中间表示、OR-Tools的CP-SAT做求解器。OR-Tools的CP-SAT求解器处理排班这类问题非常顺手。这类问题里有大量逻辑约束比如某人某天是否值班、每天必须覆盖几个人、人员总天数上限等CP-SAT都表达得很自然Python API也简单中小规模问题求解速度非常快。JSON做中间表示则是因为它容易校验、容易可视化也方便后续替换底层求解器——今天可以用CP-SAT明天想切换到线性规划求解器只需要改建模层的映射逻辑NLU层的输出完全不用动。大模型在这里的角色是“覆盖变体”规则模板是“保证下限”。规则模板只能识别固定的说法但大模型可以把“老王周一周二别安排”“尽量平均点”这种变体表达也抽出来。两个手段配合才能既稳定又灵活。3. 从一句话到一条约束NLU层的第一版实现3.1 先定义“人话”里面到底有什么写抽取器之前我先把输入里可能出现的信息维度列了一遍。排班类需求无论怎么表达最后都逃不开这几类信息对象列表也就是谁参与排班时间范围一共排多少天资源需求每天需要几个人硬约束必须满足的边界比如某人某天不能值班、每天覆盖人数固定软目标用户说“尽量”“最好”“不希望”的那些诉求。把这几个维度定义清楚抽取任务就变成了“归类填空”。一句话进来先判断它属于哪个维度再填进对应字段。比如“甲在第1天和第2天不能值班”核心就是两个信息对象是甲约束类型是禁止值班作用天数是第1和第2天。至于“不能”这个词就是触发禁止约束的关键信号。这套思路撑起了整个NLU层的骨架。3.2 规则模板先抓最稳定的表达0-1版本我先写了一套手写规则提取器。不要小看这步规则模板的价值在于行为完全透明、输出确定、容易调试。比如“每天需要X个人”这种极常见的表达用正则就能稳定抓住。这类固定模式是规则的舒适区但规则的问题也显而易见——有多少规则才能覆盖多少说法。我在实际测试中写了几十条正则覆盖了“每天需要”“每人最多”“每人至少”“不能值班”“尽量均匀”等常见说法但对于“周日那天人手别太紧”“老带新比例控制一下”这种表达就完全无能为力。所以我的策略是规则模板只用来抓最固定的量剩下不确定的表达全部交给大模型补位两边汇合后做归一化。3.3 大模型抽取提示词里给schema比给自然语言有用调大模型抽取的那段时间我最大的体会是与其在提示词里长篇大论描述什么是排班问题不如直接给结构化格式。我最终用的提示词模板包含四块内容任务定义说明要从用户输入中提取排班问题的结构化要素输出格式强制要求输出JSON字段固定少样本示例给一两个正面和反面例子字段约束明确每个字段的取值范围。少样本示例是最关键的一步。模型一旦看到“输入什么就输出什么”的示例输出的稳定度会提升非常明显。我给了两条示例一条带硬约束一条带软目标模型基本就能把“尽量均匀”正确地归到软目标字段而不是当成硬约束写死。大模型抽取之后的输出差不多长这样{ people: [甲, 乙, 丙, 丁], horizon: 6, daily_demand: 2, hard_constraints: [ {type: forbidden, person: 甲, day: 0}, {type: forbidden, person: 甲, day: 1}, {type: min_work_days, person: 甲, value: 1}, {type: min_work_days, person: 乙, value: 1}, {type: min_work_days, person: 丙, value: 1}, {type: min_work_days, person: 丁, value: 1}, {type: max_work_days, person: 甲, value: 4}, {type: max_work_days, person: 乙, value: 4}, {type: max_work_days, person: 丙, value: 4}, {type: max_work_days, person: 丁, value: 4} ], soft_objective: { type: balance } }这份JSON就是整条链路的“中间表示”。注意系统没有让大模型直接输出排班代码而是让它输出数据。代码由我们自己写这样最可控。3.4 中间表示必须加一道校验器大模型的抽取结果不能直接拿去建模。我在实际测试中发现它偶尔会抽错对象名可能把“甲”写成“假”会把“至少三个人”的运算符抽反还会把“第6天”抽到horizon之外。这种错误如果直接落到求解器里轻则建模失败重则产生一个完全错误的“最优解”。所以我加了一个轻量校验函数做三件事检查horizon和对象列表是否合理比如天数不能超过30、人数不能为0检查取值是否越界比如某人的禁止值班日期必须在horizon范围内检查硬约束之间是否有明显的矛盾比如“每天需要3个人”但对象一共只有2个人这种低级冲突。校验失败直接返回“哪句话没听懂”而不是把错误数据丢给求解器。这一步非常值。4. 把约束翻译成求解器听得懂的语言建模层设计4.1 为什么中间表示不直接生成求解代码我在早期原型里走过一个弯路直接让NLU层输出OR-Tools的Python代码想着省掉一层转换。结果调试起来非常痛苦——抽取结果稍微变一点代码就得重新生成而且生成的代码里一旦混入错误变量名排查成本特别高。改成JSON中间表示之后整个逻辑顺了很多。JSON的好处有三个人类可读可改调试的时候能直接看到系统“认为”的约束是什么可以独立编写映射逻辑把JSON转换成任意后端求解模型后续如果要做对话式修改只需要改这份JSON不需要重新跑一遍NLU抽取。你可以把JSON理解成自然语言和数学表达之间的“契约层”NLU和建模各自面向契约编程互不污染。4.2 从中间表示到CP-SAT的映射规则建模层的核心是一张映射表每种JSON字段对应一类模型操作。这张表也是整个系统最值钱的部分。中间表示字段模型操作people定义对象集合horizon定义时间索引daily_demand每天值班人数加和等于需求值forbidden对应BoolVar固定为0min_work_days个人值班天数加和大于等于给定值max_work_days个人值班天数加和小于等于给定值soft_objective.balance添加min/max辅助变量目标为最小化两者之差每条映射的“为什么”都很明确。比如说daily_demand用户说的是“每天需要2个人”这是一个覆盖约束意味着每天值班的BoolVar之和必须等于2既不能少更不能多否则排班表就缺岗或冗余。再比如forbidden“甲在第1天不能值班”直接把对应变量固定为0这就是硬约束的本质。min和max同理分别对应不等式约束的下界和上界。4.3 从JSON到CP-SAT一个可运行的映射函数把映射规则落成Python代码之后整个建模层就非常薄了。下面是我这版的核心建模函数重点展示如何把JSON里的约束逐条翻译成CP-SAT模型from ortools.sat.python import cp_model def build_model(ir): model cp_model.CpModel() people ir[people] days range(ir[horizon]) x {} for p in people: for d in days: x[p, d] model.NewBoolVar(fx_{p}_{d}) # 每天必须正好有 daily_demand 个人值班 for d in days: model.Add(sum(x[p, d] for p in people) ir[daily_demand]) # 统计每个人总值班天数套用硬约束 work {} for p in people: work[p] sum(x[p, d] for d in days) for c in ir[hard_constraints]: if c[person] p and c[type] min_work_days: model.Add(work[p] c[value]) if c[person] p and c[type] max_work_days: model.Add(work[p] c[value]) if c[type] forbidden: model.Add(x[c[person], c[day]] 0) return model, x, work这段代码只做了“配置”工作没有任何业务逻辑。无论未来是排班还是库位分配只要中间表示的字段定义不变建模层就始终是这个套路。这也是我坚持“JSON契约层”的原因建模层越薄越稳定。4.4 软目标怎么做把“尽量”变成数学表达式自然语言里最特殊的一类表达是“尽量”“最好”“不希望”。它不像硬约束那样必须满足而是希望在满足硬约束的前提下尽量达成。这就要引入软目标的概念。以“尽量让每个人值班天数均匀”为例我把它建模成最小化“最大值班天数与最小值班天数之差”。当这个差值为0时说明每个人值班天数完全一致无法做到0时求解器会尽量把它压到最小。具体做法是创建两个辅助整数变量min_work和max_work把每个人的总值班天数分别约束为大于等于min_work、小于等于max_work然后把目标函数设为最小化max_work减min_work。软目标处理的关键是抽取阶段就要把“尽量”这类词识别出来放进objective字段而不是当成硬约束。系统求解完还要把结果回显给用户时注明“这条是尽力而为的如果和硬约束冲突会被牺牲”。这样的透明度能避免很多使用上的误解。5. 端到端跑通第一个小Demo把排班问题走完一遍5.1 测试用例一段看起来很普通的“人话”我这里选了一个非常典型的排班输入包含对象、时间范围、资源需求、硬约束和软目标接下来6天每天需要2个人值班项目组有甲、乙、丙、丁4个人。每人最多值班4天至少值班1天。甲在第1天和第2天不能值班。尽量让每个人的值班总天数均匀。这段输入在业务场景里极具代表性。它同时包含了“必须满足”的硬约束和“尽量做到就行”的软目标如果把软目标理解成硬约束模型会直接无解如果漏掉“甲不能值班”这条排班结果就会出现实际业务中的冲突。这一条用例能同时验证NLU抽取、建模和求解三个环节。5.2 完整代码可以直接跑的最小版本下面这段代码我把NLU层简化成了直接给一份JSON中间表示因为这一篇的重点是打通链路大模型抽取在上一篇已经验证过。实际工程中这个位置就是接大模型输出的入口。# pip install ortools from ortools.sat.python import cp_model ir { people: [甲, 乙, 丙, 丁], horizon: 6, daily_demand: 2, hard_constraints: [ {type: forbidden, person: 甲, day: 0}, {type: forbidden, person: 甲, day: 1}, {type: min_work_days, person: 甲, value: 1}, {type: min_work_days, person: 乙, value: 1}, {type: min_work_days, person: 丙, value: 1}, {type: min_work_days, person: 丁, value: 1}, {type: max_work_days, person: 甲, value: 4}, {type: max_work_days, person: 乙, value: 4}, {type: max_work_days, person: 丙, value: 4}, {type: max_work_days, person: 丁, value: 4} ], soft_objective: {type: balance} } model cp_model.CpModel() people ir[people] days range(ir[horizon]) x {} for p in people: for d in days: x[p, d] model.NewBoolVar(fx_{p}_{d}) for d in days: model.Add(sum(x[p, d] for p in people) ir[daily_demand]) work {} for p in people: work[p] sum(x[p, d] for d in days) for c in ir[hard_constraints]: if c[person] p and c[type] min_work_days: model.Add(work[p] c[value]) if c[person] p and c[type] max_work_days: model.Add(work[p] c[value]) for c in ir[hard_constraints]: if c[type] forbidden: model.Add(x[c[person], c[day]] 0) min_work model.NewIntVar(0, 4, min_work) max_work model.NewIntVar(0, 4, max_work) for p in people: model.Add(work[p] min_work) model.Add(work[p] max_work) model.Minimize(max_work - min_work) solver cp_model.CpSolver() status solver.Solve(model) print(solver.StatusName(status)) if status in (cp_model.OPTIMAL, cp_model.FEASIBLE): for d in days: print(f第{d 1}天: .join(p for p in people if solver.Value(x[p, d]) 1)) print(目标值(最大值班天数-最小值班天数):, solver.ObjectiveValue())这段代码就是整个0-1版本的精髓从中间表示到模型、从模型到求解、从求解到可读输出全部浓缩在几十行Python里。5.3 运行结果与观察在我本机跑出来的结果如下第1天: 丙 丁 第2天: 乙 丁 第3天: 甲 乙 第4天: 甲 丙 第5天: 甲 丁 第6天: 乙 丙 目标值(最大值班天数-最小值班天数): 0逐个检查每天都是2个人值班满足覆盖约束甲只在第3、4、5天出现第1、2天确实没排四个人的总值班天数分别为甲3天、乙3天、丙3天、丁3天完全均匀目标值为0这已经是最优情况。整个过程求解速度极快几乎是一瞬间就出了结果。这个Demo虽然简单但完整地验证了整条链路的可行性。排班问题在一段时间里一直是运筹优化领域很常见的测试场景就是因为它的约束类型足够丰富、结果容易验证同时又非常贴近真实业务。5.4 把结果“回译”给人看的一步我最初只输出排班表后来发现实际使用中远远不够。业务人员不关心“谁在第几行”他们想看到的是“第1天谁值班”“甲这周一共值了几天”“有没有人值班天数明显偏多”。所以我在输出模块里加了一个回译模板把求解结果重新组织成普通人能直接读的表述。回译的内容包括两部分按天展示值班名单按人统计值班总数。这样一来用户不用读懂CP-SAT的任何概念只需要看一张表就知道系统给出的方案是什么。0-1版本先做这种简单的模板回译后续版本才考虑生成“为什么这样排”的完整解释。6. 这版实现的经验与局限以及0-2要补的功课6.1 踩过的坑NLU层最容易翻车的地方第一个坑是日期表达不统一。“第1天”“下周一”“后天”这些表达在同一个输入里混着出现时抽取器很容易把时间范围理解错。0-1版本里我干脆把所有测试用例统一成“第1天到第N天”把日期归一化的问题留到0-2处理。这个取舍很实际先把主干链路跑通再处理分支细节。第二个坑是“至少”和“最多”的运算符混淆。“每天至少3个人”和“每天最多3个人”在输出JSON里对应完全不同的不等式方向但大模型偶尔会把方向搞反。我后来在提示词里专门加了对比示例并且在校验器里检查这两种约束是否同时出现且数值矛盾。第三个坑是软目标和硬约束的混淆。“尽量均匀”这种话如果被当成硬约束处理问题大概率变成无解。所以我在NLU抽取规则里把“尽量”“最好”“不希望”“优先”等语气词认定为软目标信号绝不落入硬约束列表。6.2 调优经验提示词给schema结果出奇地稳实际操作下来我总结了三条比较实用的经验。第一给模型输出格式时与其用文字描述JSON不如直接给一个JSON结构示例和反例模型照着样例填字段的成功率会高很多。第二抽取任务中的“负面表达”要单独列出来“不能”“不要”“禁止”“不得”都要映射到同一个forbidden类型避免模型自己发明字段。第三校验规则要写双向的既写在大模型提示词里告诉它取值范围也写在代码里做硬校验两边同时生效才能挡住大部分脏数据。这些经验说出来不多但都是反复试错之后留下来的有效做法比调大模型本身的参数更管用。6.3 当前局限与0-2方向这版0-1系统的边界非常明确。它目前只支持布尔变量和整数变量只支持线性约束和逻辑约束。如果输入里出现“成本随人数增加呈阶梯式上涨”这类非线性描述我的做法是直接拒绝而不是硬建模。非线性问题的自然语言表达边界本身就模糊0-1版本不做是对用户负责。它还不支持多轮对话式修改。用户如果说“这个方案里甲值太多了重新排一下”当前系统只能重新跑一遍完整流程没法记住上次调整的上下文。0-2版本我计划把中间表示改造成可编辑对象让用户基于上一轮结果做增量修改。求解后端目前也只有CP-SAT一条路。如果未来要处理几千人规模的大排班问题CP-SAT这种精确求解器可能撑不住到时候我的思路是把同一份JSON中间表示映射到本地搜索求解器或线性规划后端做大规模启发式求解。这个扩展路径正是当初坚持JSON契约层的回报。这套0-1版本做完我自己最大的体会是自然语言优化求解系统的难点根本不在求解而在“让系统准确知道自己听懂了多少”。中间表示就是这个“听懂”的度量衡它能把系统的理解过程暴露给开发者看也能把错误拦截在任何误算发生之前。下一篇0-2我会重点补两块内容一是多轮对话式约束修改让方案可以基于反馈迭代调整二是约束冲突的自动解释让系统在没有可行解时能直接告诉用户问题出在哪句话上。这个方向把大模型的泛化能力和运筹求解的精确性捏在一起值得慢慢打磨。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
