如果你正在追这个系列应该已经见过前面五篇我们把自然语言优化求解系统从最简陋的规则匹配一路做到了能处理线性目标加线性约束的小型可用版本。这一篇我想把视角从“能跑”转向“不乱跑”重点解决三件事第一给自然语言到数学模型之间加一层中间表示 IR让规则不再散落在正则表达式里第二把约束冲突检测补上让系统在模型不可行时能告诉你为什么不可行第三把求解和结果解释做成一个稳定组件方便继续往里加功能。这一篇是承上启下的一篇读完你会得到一个更能扛事儿的架构并且能直接拿去扩展新场景。1. 系统链路回顾我们到底在构建什么1.1 自然语言优化求解系统的大致链路先回顾一下整体流程。我们构建的系统最终目标非常简单用户用一句大白话描述一个优化问题比如“仓库里有200件A商品和150件B商品成本分别是30和40售价分别是45和60求最大利润并且A的数量不能少于B的两倍”系统要能自动抽出决策变量、目标函数和约束然后调用数学优化求解器算出最优解再用自然语言把结果说回给人听。链路我拆成了六段原始文本处理、意图识别、槽位填充、中间表示构建、模型映射、求解与结果解释。前五篇分别把文本分词、数字抽取、简单规则匹配、最小可行模型和求解器调用都跑通了。但当时的代码里有个很大的隐患规则直接散落在各个解析函数里一个正则匹配一个分支每加一种表达方式就要到处打补丁测试用例稍微复杂一点就开始互相干扰。我在这篇开头先明确一个观点小系统能跑靠的是灵光一现系统要能持续加功能必须靠结构化的中间表示。哪怕你只想处理三种优化问题也建议先把 IR 划出来后面省的时间远超当时多写的代码量。1.2 为什么第六篇要碰“中间表示”很多做自然语言处理的人一开始容易走极端要么觉得必须上大模型要么觉得纯正则最省事。我的实际结论是在一个目标明确、领域狭窄的优化求解场景里规则系统完全够用但规则不能是一盘散沙必须有一个统一出口。这个出口就是中间表示 IR。IR 可以把两件完全不同的事情彻底隔离左边是自然语言理解右边是数学模型构建。左边无论你怎么改同义词、改句式、改语气最后都输出同一套 IR 结构右边无论你换开源求解器还是商业求解器都只认 IR。这样两侧的改动互不牵连。比如用户说“最多能获得多少利润”和“利润最大是多少”它们自然语言形式不同但解析后都对应同一个 IR 目标片段sense 为 maximize变量系数分别为单位利润。只要这一步对齐了后面就完全不用关心用户到底怎么问的。同理求解器层只负责把 IR 转换成具体求解器输入的数学模型也不用关心中文表达里的弯弯绕绕。这是第六篇整个架构的方向。2. 核心设计自定义 IR给自然语言和数学模型之间加一层缓存2.1 不直接用规则翻译的痛点我第一版代码里是这种风格检测到“不少于”“至少”“不能低于”就直接把自然语言里的数字和变量替换成不等式然后拼一个求解器模型字符串。刚开始跑得很欢乐直到我遇到三个场景直接崩掉第一同一个语义的表达方式太多。“不少于”“至少”“不得少于”“最低要”“不能比…少”“比…多或者一样多”看起来是一堆规则实际上语义全是一样的。如果每个规则各自生成模型稍微改一个措辞就要新增一个分支。第二自然语言中的左右关系容易反。比如“A不能少于B”和“A不超过B”这两句话规则写错一个符号结果就完全错了。没有 IR 之前这种错误会藏在非常深的解析逻辑里排查成本极高。第三用户可能在同一个句子里既定义变量又给约束还夹带单位换算。比如“每小时生产50个零件一共生产8小时”这其实是一个 50*8400 的资源上限而不是直接给你一个数字。如果直接映射数字就会丢掉这个乘法关系。有了 IR 之后所有解析结果都变成结构化字段。测试时可以逐个字段断言出了问题一眼就能看到是变量名错了、系数错了还是符号反了。这种感觉就像从手写 SQL 换成了 ORM你仍然要关心底层逻辑但调试体验完全不同。2.2 IR 数据结构长什么样我使用的 IR 是一个 JSON 风格的字典结构分为三块变量、目标、约束。不搞复杂的类继承直接字典加 schema 校验就够了。下面这个例子是“求最大利润A的数量不能少于B的两倍A有库存200B有库存150”的 IR。{ variables: [ {id: x_a, name: A商品, type: integer, lb: 0, ub: 200}, {id: x_b, name: B商品, type: integer, lb: 0, ub: 150} ], objective: { sense: maximize, terms: [ {var: x_a, coefficient: 15}, {var: x_b, coefficient: 20} ] }, constraints: [ { name: c_ratio, terms: [ {var: x_a, coefficient: 1}, {var: x_b, coefficient: -2} ], sense: , rhs: 0, source: A数量不能少于B的两倍 } ] }这里的利润系数是售价减成本得到的 15 和 20。变量 x_a、x_b 是内部 IDname 字段保留中文实体名用于最终生成自然语言报告。source 字段非常关键它把约束和原始句子绑定报错的时候可以精准指出是哪句话出了问题。我建议每个变量都设置 lb 和 ub不要指望求解器自动推断。很多自然语言问题里用户没有给出所有变量上限但只需要认真分析原句会发现“库存”已经是天然上限。如果实在没有上限再给一个大数作为 lb 和 ub 也可能造成数值问题这一点在 4.1 节会说。2.3 从 IR 到求解器模型的映射规则IR 定下来以后模型映射就变成了一道纯粹的机械翻译题。变量节点映射成求解器的决策变量type 为 integer 时就是整数变量否则是连续变量。objective 的 terms 每个都是线性项拼成线性目标函数。constraints 里的 terms 和 rhs 拼成线性不等式。几次实操后我总结了三个必须注意的映射细节第一所有变量默认非负。如果用户没有明确表示“允许为负”一律把 lb 设为 0。优化问题里出现负数决策变量通常不是用户本意而是我们漏掉了符号条件。非负条件能避免大量无界和不可行问题。第二整数变量不要轻易放松。如果用户说“要生产多少个产品”这是整数问题。但求解整数问题可能更慢。我采取的策略是先按用户原意设整数变量求解如果超时再降级为连续变量求解并在结果里提示“当前结果为松弛解不是严格整数最优”。这个策略实测很实用。第三系数要避免过大的数值差异。自然语言里的数量级可能差很远比如库存上限是 1000000利润系数是 0.001模型矩阵条件数会非常差。对此我一定会做一步归一化把系数缩放到 0.001 到 1000 之间最后再把结果反向还原。这一步非常影响求解器稳定性。3. 从句子到槽位意图识别与关键信息抽取3.1 目标极值怎么识别词典加正则就够了目标识别是整个系统里最不应该复杂化的部分。我没用机器学习而是维护了一张目标倾向词典外加几个正则兜底。词典主要记录两类极值词最大化类和最小化类。分类触发词输出 sense最大化最大、最多、最高、利润最大、尽量多、越多越好maximize最小化最小、最少、最低、成本最小、尽量少、越少越好minimize特殊目标正好、恰好达到固定值目标需要额外解析这里有一个看起来很细但特别容易踩的坑“尽量多”和“越多越好”语法上是期望不是硬约束。用户其实想要一个最大化的目标但系统如果理解成“至少”就会把问题变成有下界的约束结果完全不同。我现在的策略是如果句子中同时出现目标词和约束词先按目标词处理只有当约束词出现在“要求”“必须”“不能”这类强条件动词之后才判定为约束。正则表达式也不是越多越好。我把复杂规则抽成了几个独立函数比如parse_greater_equal、parse_less_equal、parse_equal每个函数只负责一个符号语义内部再维护同义词表。这样新增同义词时只需要扩展词表不需要碰函数逻辑。3.2 数字、单位和量级归一化数字抽取是所有后续处理的基石。去掉明显的乱码数字不算难难在中文数字、小数、百分数、单位换算混在一起。我实际处理过的例子有“两百件”“1.5倍”“百分之二十五”“每件成本30元”“一共8小时每小时50个”。直接正则匹配可能拿到 30、8、50但不知道谁跟谁相关。我的做法分三步。第一步全角转半角去掉千分位逗号把“两百”这类中文数字先转成阿拉伯数字。第二步识别数字后缀的单位词件、箱、吨、小时、元、百分比等。第三步判断是否需要换算如果出现“每件成本30元”和“一共200件”系统要能自动生成乘法项表示总成本变量而不是把 30 和 200 直接当作两个独立数字。单位归一化我采用了一个单位换算表例如“千”是 1000“万”是 10000“半”是 0.5“两倍”是 2。句子中出现“两倍”时它并不是一个独立单位而是一个系数需要绑定到某个变量上。比如“A的数量是B的两倍”要解析成x_a - 2 * x_b 0而不是x_a 2这种错误形式。这个逻辑我会专门写一个bind_multiplier函数把倍数从数字流中抽出来单独绑定到变量关系上。3.3 变量定义与资源上限的槽位绑定槽位填充阶段要做的事情是把句子里的实体和数字装进预设好的语义槽里。我默认设计了四个槽位变量槽、目标系数槽、资源上限槽、比较关系槽。变量槽来自三类表达。第一类是“有”“存在”“设”“假设”之后的名词比如“A商品有200件”“A商品”就是变量名200 是它的初始库存或者最大库存。第二类是“生产”“购买”“出售”等动作的宾语比如“生产了A产品”。第三类是“每个”“每单位”后面的名词比如“每个A利润15元”这个 A 也会被识别为变量。这里特别需要注意的是同一样东西可能既出现在变量槽又出现在约束槽。比如“A的数量不能少于B的两倍”这句话并没有重新定义 A而是给 A、B 之间的关系增加约束。我的策略是如果某个实体之前已经出现在变量槽里后续再出现就默认追加约束如果没出现过就把它当成新变量。这个策略能避免大多数误判但同时要求变量槽的优先级非常高。资源上限槽的解析要区分“库存上限”和“可用总量”。用户说“仓库里最多放500件A”这是一个变量上界用户说“我们总共可以支配3000元预算”这可能是一个涉及多个变量的预算约束而不是某个变量的上界。区分方式很简单如果资源名和单个实体绑定比如“仓库里的A”“A的库存”就是变量上界如果资源名是总称比如“预算”“总时间”“总容量”就是独立约束。我把这个原则写成了build_resource_constraint函数每次解析资源时都要先问一句这是单个变量的事还是多个变量共享的事这一问能拦住很多错误。4. 约束冲突检测让系统把“不可行”说成人话4.1 必须先分清四类常见不可行与无界系统一旦接入真实用户输入不可行和错误就会频繁出现。第一版测试时我们经常拿到一个求解器返回的“infeasible”就傻眼了。后来我把问题整理成四类类型表现典型原因严格不可行没有任何解满足所有约束两个约束互相矛盾如 x ≥ 100 且 x ≤ 50目标无界目标可以无穷大最大化时变量没有上界且目标系数为正整数不可行连续松弛可行但整数解不存在约束把可行域切成无法取整的碎片数值困难提示状态异常或求解缓慢系数极差上下界跨度过大这四类问题需要不同的处理方式。严格不可行要查约束矛盾目标无界要检查变量上界是否缺失整数不可行需要额外分析割平面或建议放宽整数要求数值困难则需要做系数归一化。我建议在系统进入求解器之前先做一个轻量级预检查把明显无界的问题提前拦截而不是等求解器超时后才发现。预检查其实很简单对每个变量如果目标函数中它的系数与目标方向同号而它的上界是无穷大同时没有约束能限制它就可以直接判定无界。对于大部分生产排产、资源分配问题所有决策变量都应当有一个有限上界。如果用户漏了我会自动把上界设置成一个大数但不会设为无穷大。无穷大在求解器里往往导致数值灾难。4.2 用不可行性子集 IIS 做精准定位“模型不可行”这种笼统的报错对用户毫无价值。我们要的是找到到底是哪几个约束互斥。求解器通常提供一个可计算的不可行性子集也就是 IIS一个不可行的约束集合但是删掉其中任意一条约束后模型就变得可行。这个集合往往比全部约束小得多能精准指出矛盾出处。我的实现里IR 阶段的每个约束都保存了source字段这正好用于 IIS 输出映射。当求解器判定不可行后我调用 I I S 计算返回一组约束 ID通过 IR 反查原始句子拼接出类似这样的反馈当前模型不可行问题出在以下约束之间的冲突约束 A仓库里最多存放 500 件 A约束 BA 的数量不能少于 B 的两倍约束 CB 的库存至少 300 件 建议放宽其中任意一条限制再重新求解。这里我不直接给用户一个“错误”解而是把矛盾点交到用户手里。实际使用中用户看到这种反馈后通常能立刻意识到自己的限制条件确实没法同时满足。需要注意IIS 计算本身对大规模模型可能耗时不短。所以我只在求解器判定不可行时才调用并且设置了 3 秒的超时时间。超时了就退回到一个简单方案列出所有约束的松弛度按松弛度排序选取最可疑的前三条展示给用户。虽然不够精确但比报一个冷冰冰的异常强得多。4.3 自动松弛建议的实现思路定位冲突之后下一步是给用户提供修复方案。自动松弛不能乱来我不会直接修改用户原始输入而是生成“建议”由用户确认后再执行。具体做法是对所有约束计算当前点的违背量。比如约束是 A ≥ 2B而当前变量取值无法满足那违背量就是 2B - A。针对违背量大的约束我生成一条松弛建议右侧常数增大 10% 或者左侧系数减少 10%然后重新判定可行性。如果松弛后可行就给出提示已将约束“A 的数量不能少于 B 的两倍”的右侧从 0 调整为 -20 后模型变得可行。这套逻辑虽然简单但能覆盖大多数用户笔误和数据录入错误。更复杂的情况比如需要同时松弛多条约束我会把所有约束的松弛量作为决策变量加入模型以松弛总量最小为目标直接求一个“最小修复方案”。这样得到的结果比人工试错专业很多。5. 求解器接入与结果解释5.1 求解器抽象层设计与超时保护求解器不能直接散落在业务逻辑里否则以后换求解器会是一场灾难。我设计了一个求解器抽象层对外只暴露一个solve方法输入 IR 模型输出状态和解。这个方法内部负责将 IR 映射到具体求解器 API调用时统一设置超时时间、线程数和相对间隙。超时保护是必须做的。自然语言输入的不确定性太大用户可能随口说一个规模庞大的问题。我一般设定三种超时档位简单问题 5 秒普通问题 15 秒复杂整数问题 60 秒。如果超时后还没拿到最优解但已经找到可行解直接返回当前可行解并在报告里注明“达到时间限制返回当前最好解”如果连可行解都没找到就返回“该问题在有限时间内未能求解”。这里有一个细节求解器给出的状态码每一家不完全一样甚至不同版本之间也有差异。我在抽象层里把所有状态统一替换成五类OPTIMAL、FEASIBLE、INFEASIBLE、UNBOUNDED、TIMEOUT。上层代码永远只判断这五个状态这样换求解器几乎不用改业务代码。5.2 结果反解析从变量 ID 到自然语言报告求解器返回的是一堆变量 ID 和数值用户根本不关心这些。结果解释模块要做的是把这些数值填回到原始语义槽位中。我在 IR 里给每个变量存了name这个 name 就是自然语言报告需要的真实实体名。报告生成我分为三步。第一步把变量 ID 替换成中文名称。例如 x_a 替换成 A商品。第二步按目标方向输出核心结论比如“最大利润为 2600 元”。第三步列出关键决策变量的取值只列用户关心且有非零值的变量不要把所有变量都倒出来。如果某变量取值是 0除非用户明确要完整结果否则我倾向于不展示避免刷屏。如果原句中有单位报告会把数值和单位合并。比如原句“生产多少个A”报告就会显示“生产 40 件A”。这些单位信息我也存进了 IR 的变量节点具体字段可以在变量定义里加一个unit映射阶段不参与计算只用于报告。5.3 当模型不可行时给用户什么反馈这一节我还是想强调反馈质量决定这个系统能不能被真实使用。早期版本遇到不可行我就直接弹一个“模型不可行”的异常页面用户完全不知道哪里错了。后来加了 IIS 分析和松弛建议反馈才变得可用。我建议反馈文案分成三级。第一级结论比如“当前条件无法同时满足”。第二级原因列出冲突约束对应的原始句子。第三级建议给出 1 到 2 个修复方向可以是放宽库存上限也可以是去掉某条比例约束。每一级都用自然语言生成不要展示内部错误码。用户可能完全不懂数学优化但他一定懂“仓库存不下”和“销售要求太多”之间的矛盾。如果你要把这个系统接入线上务必把结果解释模块单独做成可以 mock 的纯函数输入 IR 和求解器状态输出报告字符串。这样测试时不需要真正调用求解器直接喂固定 IR 就能验证文案质量。我踩过的一个坑是早期把报告生成逻辑写在了求解器回调里导致每次调试都要花时间跑一遍模型白白浪费很多时间。6. 测试与排坑实录6.1 我们的测试语料库怎么建搞自然语言系统没有测试语料就是耍流氓。我建了一个按难度分级的测试集目前在本地跑一百多条用例每条用例都是一组“输入文本 期望 IR 期望报告片段”。难度数量覆盖内容L120单变量极值、直接上下界L240多变量利润、标准线性约束L330比例约束、单位换算、隐藏乘法关系L420整数变量、不可行问题、无界问题L1 测试最基础的“求最大利润每件利润 5 元最多卖 100 件”这类句子。L2 加入多个产品和库存上限。L3 重点测试自然语言的各种同义改写比如“A 至少是 B 的两倍”和“B 不能超过 A 的一半”。L4 专门放求解器状态相关的用例比如故意输入一个矛盾条件验证系统能否给出 IIS 反馈。测试执行时我并不是直接对比文本而是对比 IR 结构。IR 是一个字典直接深比较即可。报告部分只对比关键词是否出现比如“最大利润”和“2600”是否都在报告里。这个测试体系帮我重构了几次解析逻辑但回归时几乎都能一次通过。6.2 踩过的 5 个典型坑这个项目踩过的坑我挑最典型的五个记录在这里都是血泪教训。第一中文分词把“不少于”切错。早期用通用分词器切出来的是“不”“少于”正则匹配“不少于”就失败了。后来我把领域词典优先加到分词器里把“不少于”“不超过”“至少”“至多”都当成整体 token准确率立刻上来。第二解析“两倍”时丢掉关系。用户说“A是B的两倍”我一度解析成 A ≥ 2然后系统里根本没有 B 的参与结果模型完全脱离原意。正确写法是 A - 2B 0关键是要搞清楚倍数到底在谁和谁之间。第三整数变量和生产量不匹配。用户说“要生产多少件”变量设为整数是对的但如果同时给出“每天生产 8 小时每小时 50 件”这种单位换算直接把 8 和 50 当作两个变量会非常离谱。正确的做法是生成一个隐藏资源约束总生产量 ≤ 8*50。第四求解器超时时没有返回可行解。有些求解器在超时后会给出一个当前解但状态不是最优。如果不区分状态直接把结果当最优输出用户会被误导。我在报告里明确标注“当前为可行解非最优解”这很重要。第五模型初始化时把上界设成无穷大。最大化的目标下一个变量无上界就会导致无界解。后来我增加了一条默认规则凡是自然语言中能推断出库存上限或资源上限的一律设置有限上界实在推断不出就根据同批次数字的数量级自动补一个大数。6.3 一点性能调优心得我用的是开源混合整数规划求解器性能上不需要追求极端但一些基本优化还是必要的。最容易出现瓶颈的地方是正则表达式频繁编译。Python 里正则每次匹配都需要编译如果句子很长规则很多性能会明显下降。我把所有正则表达式在模块加载时统一用re.compile缓存速度提升非常明显。第二个常用优化是解析树复用。同一个 IR 的 source 字段可能对应多轮对话中的同一句话重复解析很浪费。我给每个解析结果加了一个轻量缓存以句子哈希为 key缓存 IR 子片段。如果句子没有变化直接读缓存。第三个优化是求解器实例复用。每次求解都新建求解器再释放对短小模型问题不大但面对大量并发请求时频繁创建对象会产生不必要的开销。我在抽象层里维护了一个求解器实例池通过并发安全的方式复用空闲实例。这里要注意同一个实例不能同时求解多个模型否则状态会互相污染。还有一个容易被忽略的点整数变量数量对求解时间影响极大。能合并的整数决策变量尽量合并比如多个相同单位的产品如果它们的约束完全对称就合并成一个计数变量求解速度会快很多。但这属于模型简化技巧需要根据具体业务做权衡不要盲目合并。结尾最后再说一个我实际用下来的经验这个系统的收益不是“完全取代人”而是把重复性的调度、分配、计划问题变成一种可复用的服务。你不需要把所有自然语言都理解得面面俱到只需要把领域内最常见的表达方式固化下来再配上一套好的冲突反馈机制用户就已经会觉得你很懂他。下一步我准备在这个 IR 基础上扩展非线性表达比如“运输成本随距离阶梯增长”这类分段线性问题思路还是这一篇的 IR 隔离先让自然语言解析输出分段点再映射成分段线性约束。你可以顺着这个方向先玩起来有问题随时回去看看前几篇的基础模块。
如果你正在追这个系列应该已经见过前面五篇我们把自然语言优化求解系统从最简陋的规则匹配一路做到了能处理线性目标加线性约束的小型可用版本。这一篇我想把视角从“能跑”转向“不乱跑”重点解决三件事第一给自然语言到数学模型之间加一层中间表示 IR让规则不再散落在正则表达式里第二把约束冲突检测补上让系统在模型不可行时能告诉你为什么不可行第三把求解和结果解释做成一个稳定组件方便继续往里加功能。这一篇是承上启下的一篇读完你会得到一个更能扛事儿的架构并且能直接拿去扩展新场景。1. 系统链路回顾我们到底在构建什么1.1 自然语言优化求解系统的大致链路先回顾一下整体流程。我们构建的系统最终目标非常简单用户用一句大白话描述一个优化问题比如“仓库里有200件A商品和150件B商品成本分别是30和40售价分别是45和60求最大利润并且A的数量不能少于B的两倍”系统要能自动抽出决策变量、目标函数和约束然后调用数学优化求解器算出最优解再用自然语言把结果说回给人听。链路我拆成了六段原始文本处理、意图识别、槽位填充、中间表示构建、模型映射、求解与结果解释。前五篇分别把文本分词、数字抽取、简单规则匹配、最小可行模型和求解器调用都跑通了。但当时的代码里有个很大的隐患规则直接散落在各个解析函数里一个正则匹配一个分支每加一种表达方式就要到处打补丁测试用例稍微复杂一点就开始互相干扰。我在这篇开头先明确一个观点小系统能跑靠的是灵光一现系统要能持续加功能必须靠结构化的中间表示。哪怕你只想处理三种优化问题也建议先把 IR 划出来后面省的时间远超当时多写的代码量。1.2 为什么第六篇要碰“中间表示”很多做自然语言处理的人一开始容易走极端要么觉得必须上大模型要么觉得纯正则最省事。我的实际结论是在一个目标明确、领域狭窄的优化求解场景里规则系统完全够用但规则不能是一盘散沙必须有一个统一出口。这个出口就是中间表示 IR。IR 可以把两件完全不同的事情彻底隔离左边是自然语言理解右边是数学模型构建。左边无论你怎么改同义词、改句式、改语气最后都输出同一套 IR 结构右边无论你换开源求解器还是商业求解器都只认 IR。这样两侧的改动互不牵连。比如用户说“最多能获得多少利润”和“利润最大是多少”它们自然语言形式不同但解析后都对应同一个 IR 目标片段sense 为 maximize变量系数分别为单位利润。只要这一步对齐了后面就完全不用关心用户到底怎么问的。同理求解器层只负责把 IR 转换成具体求解器输入的数学模型也不用关心中文表达里的弯弯绕绕。这是第六篇整个架构的方向。2. 核心设计自定义 IR给自然语言和数学模型之间加一层缓存2.1 不直接用规则翻译的痛点我第一版代码里是这种风格检测到“不少于”“至少”“不能低于”就直接把自然语言里的数字和变量替换成不等式然后拼一个求解器模型字符串。刚开始跑得很欢乐直到我遇到三个场景直接崩掉第一同一个语义的表达方式太多。“不少于”“至少”“不得少于”“最低要”“不能比…少”“比…多或者一样多”看起来是一堆规则实际上语义全是一样的。如果每个规则各自生成模型稍微改一个措辞就要新增一个分支。第二自然语言中的左右关系容易反。比如“A不能少于B”和“A不超过B”这两句话规则写错一个符号结果就完全错了。没有 IR 之前这种错误会藏在非常深的解析逻辑里排查成本极高。第三用户可能在同一个句子里既定义变量又给约束还夹带单位换算。比如“每小时生产50个零件一共生产8小时”这其实是一个 50*8400 的资源上限而不是直接给你一个数字。如果直接映射数字就会丢掉这个乘法关系。有了 IR 之后所有解析结果都变成结构化字段。测试时可以逐个字段断言出了问题一眼就能看到是变量名错了、系数错了还是符号反了。这种感觉就像从手写 SQL 换成了 ORM你仍然要关心底层逻辑但调试体验完全不同。2.2 IR 数据结构长什么样我使用的 IR 是一个 JSON 风格的字典结构分为三块变量、目标、约束。不搞复杂的类继承直接字典加 schema 校验就够了。下面这个例子是“求最大利润A的数量不能少于B的两倍A有库存200B有库存150”的 IR。{ variables: [ {id: x_a, name: A商品, type: integer, lb: 0, ub: 200}, {id: x_b, name: B商品, type: integer, lb: 0, ub: 150} ], objective: { sense: maximize, terms: [ {var: x_a, coefficient: 15}, {var: x_b, coefficient: 20} ] }, constraints: [ { name: c_ratio, terms: [ {var: x_a, coefficient: 1}, {var: x_b, coefficient: -2} ], sense: , rhs: 0, source: A数量不能少于B的两倍 } ] }这里的利润系数是售价减成本得到的 15 和 20。变量 x_a、x_b 是内部 IDname 字段保留中文实体名用于最终生成自然语言报告。source 字段非常关键它把约束和原始句子绑定报错的时候可以精准指出是哪句话出了问题。我建议每个变量都设置 lb 和 ub不要指望求解器自动推断。很多自然语言问题里用户没有给出所有变量上限但只需要认真分析原句会发现“库存”已经是天然上限。如果实在没有上限再给一个大数作为 lb 和 ub 也可能造成数值问题这一点在 4.1 节会说。2.3 从 IR 到求解器模型的映射规则IR 定下来以后模型映射就变成了一道纯粹的机械翻译题。变量节点映射成求解器的决策变量type 为 integer 时就是整数变量否则是连续变量。objective 的 terms 每个都是线性项拼成线性目标函数。constraints 里的 terms 和 rhs 拼成线性不等式。几次实操后我总结了三个必须注意的映射细节第一所有变量默认非负。如果用户没有明确表示“允许为负”一律把 lb 设为 0。优化问题里出现负数决策变量通常不是用户本意而是我们漏掉了符号条件。非负条件能避免大量无界和不可行问题。第二整数变量不要轻易放松。如果用户说“要生产多少个产品”这是整数问题。但求解整数问题可能更慢。我采取的策略是先按用户原意设整数变量求解如果超时再降级为连续变量求解并在结果里提示“当前结果为松弛解不是严格整数最优”。这个策略实测很实用。第三系数要避免过大的数值差异。自然语言里的数量级可能差很远比如库存上限是 1000000利润系数是 0.001模型矩阵条件数会非常差。对此我一定会做一步归一化把系数缩放到 0.001 到 1000 之间最后再把结果反向还原。这一步非常影响求解器稳定性。3. 从句子到槽位意图识别与关键信息抽取3.1 目标极值怎么识别词典加正则就够了目标识别是整个系统里最不应该复杂化的部分。我没用机器学习而是维护了一张目标倾向词典外加几个正则兜底。词典主要记录两类极值词最大化类和最小化类。分类触发词输出 sense最大化最大、最多、最高、利润最大、尽量多、越多越好maximize最小化最小、最少、最低、成本最小、尽量少、越少越好minimize特殊目标正好、恰好达到固定值目标需要额外解析这里有一个看起来很细但特别容易踩的坑“尽量多”和“越多越好”语法上是期望不是硬约束。用户其实想要一个最大化的目标但系统如果理解成“至少”就会把问题变成有下界的约束结果完全不同。我现在的策略是如果句子中同时出现目标词和约束词先按目标词处理只有当约束词出现在“要求”“必须”“不能”这类强条件动词之后才判定为约束。正则表达式也不是越多越好。我把复杂规则抽成了几个独立函数比如parse_greater_equal、parse_less_equal、parse_equal每个函数只负责一个符号语义内部再维护同义词表。这样新增同义词时只需要扩展词表不需要碰函数逻辑。3.2 数字、单位和量级归一化数字抽取是所有后续处理的基石。去掉明显的乱码数字不算难难在中文数字、小数、百分数、单位换算混在一起。我实际处理过的例子有“两百件”“1.5倍”“百分之二十五”“每件成本30元”“一共8小时每小时50个”。直接正则匹配可能拿到 30、8、50但不知道谁跟谁相关。我的做法分三步。第一步全角转半角去掉千分位逗号把“两百”这类中文数字先转成阿拉伯数字。第二步识别数字后缀的单位词件、箱、吨、小时、元、百分比等。第三步判断是否需要换算如果出现“每件成本30元”和“一共200件”系统要能自动生成乘法项表示总成本变量而不是把 30 和 200 直接当作两个独立数字。单位归一化我采用了一个单位换算表例如“千”是 1000“万”是 10000“半”是 0.5“两倍”是 2。句子中出现“两倍”时它并不是一个独立单位而是一个系数需要绑定到某个变量上。比如“A的数量是B的两倍”要解析成x_a - 2 * x_b 0而不是x_a 2这种错误形式。这个逻辑我会专门写一个bind_multiplier函数把倍数从数字流中抽出来单独绑定到变量关系上。3.3 变量定义与资源上限的槽位绑定槽位填充阶段要做的事情是把句子里的实体和数字装进预设好的语义槽里。我默认设计了四个槽位变量槽、目标系数槽、资源上限槽、比较关系槽。变量槽来自三类表达。第一类是“有”“存在”“设”“假设”之后的名词比如“A商品有200件”“A商品”就是变量名200 是它的初始库存或者最大库存。第二类是“生产”“购买”“出售”等动作的宾语比如“生产了A产品”。第三类是“每个”“每单位”后面的名词比如“每个A利润15元”这个 A 也会被识别为变量。这里特别需要注意的是同一样东西可能既出现在变量槽又出现在约束槽。比如“A的数量不能少于B的两倍”这句话并没有重新定义 A而是给 A、B 之间的关系增加约束。我的策略是如果某个实体之前已经出现在变量槽里后续再出现就默认追加约束如果没出现过就把它当成新变量。这个策略能避免大多数误判但同时要求变量槽的优先级非常高。资源上限槽的解析要区分“库存上限”和“可用总量”。用户说“仓库里最多放500件A”这是一个变量上界用户说“我们总共可以支配3000元预算”这可能是一个涉及多个变量的预算约束而不是某个变量的上界。区分方式很简单如果资源名和单个实体绑定比如“仓库里的A”“A的库存”就是变量上界如果资源名是总称比如“预算”“总时间”“总容量”就是独立约束。我把这个原则写成了build_resource_constraint函数每次解析资源时都要先问一句这是单个变量的事还是多个变量共享的事这一问能拦住很多错误。4. 约束冲突检测让系统把“不可行”说成人话4.1 必须先分清四类常见不可行与无界系统一旦接入真实用户输入不可行和错误就会频繁出现。第一版测试时我们经常拿到一个求解器返回的“infeasible”就傻眼了。后来我把问题整理成四类类型表现典型原因严格不可行没有任何解满足所有约束两个约束互相矛盾如 x ≥ 100 且 x ≤ 50目标无界目标可以无穷大最大化时变量没有上界且目标系数为正整数不可行连续松弛可行但整数解不存在约束把可行域切成无法取整的碎片数值困难提示状态异常或求解缓慢系数极差上下界跨度过大这四类问题需要不同的处理方式。严格不可行要查约束矛盾目标无界要检查变量上界是否缺失整数不可行需要额外分析割平面或建议放宽整数要求数值困难则需要做系数归一化。我建议在系统进入求解器之前先做一个轻量级预检查把明显无界的问题提前拦截而不是等求解器超时后才发现。预检查其实很简单对每个变量如果目标函数中它的系数与目标方向同号而它的上界是无穷大同时没有约束能限制它就可以直接判定无界。对于大部分生产排产、资源分配问题所有决策变量都应当有一个有限上界。如果用户漏了我会自动把上界设置成一个大数但不会设为无穷大。无穷大在求解器里往往导致数值灾难。4.2 用不可行性子集 IIS 做精准定位“模型不可行”这种笼统的报错对用户毫无价值。我们要的是找到到底是哪几个约束互斥。求解器通常提供一个可计算的不可行性子集也就是 IIS一个不可行的约束集合但是删掉其中任意一条约束后模型就变得可行。这个集合往往比全部约束小得多能精准指出矛盾出处。我的实现里IR 阶段的每个约束都保存了source字段这正好用于 IIS 输出映射。当求解器判定不可行后我调用 I I S 计算返回一组约束 ID通过 IR 反查原始句子拼接出类似这样的反馈当前模型不可行问题出在以下约束之间的冲突约束 A仓库里最多存放 500 件 A约束 BA 的数量不能少于 B 的两倍约束 CB 的库存至少 300 件 建议放宽其中任意一条限制再重新求解。这里我不直接给用户一个“错误”解而是把矛盾点交到用户手里。实际使用中用户看到这种反馈后通常能立刻意识到自己的限制条件确实没法同时满足。需要注意IIS 计算本身对大规模模型可能耗时不短。所以我只在求解器判定不可行时才调用并且设置了 3 秒的超时时间。超时了就退回到一个简单方案列出所有约束的松弛度按松弛度排序选取最可疑的前三条展示给用户。虽然不够精确但比报一个冷冰冰的异常强得多。4.3 自动松弛建议的实现思路定位冲突之后下一步是给用户提供修复方案。自动松弛不能乱来我不会直接修改用户原始输入而是生成“建议”由用户确认后再执行。具体做法是对所有约束计算当前点的违背量。比如约束是 A ≥ 2B而当前变量取值无法满足那违背量就是 2B - A。针对违背量大的约束我生成一条松弛建议右侧常数增大 10% 或者左侧系数减少 10%然后重新判定可行性。如果松弛后可行就给出提示已将约束“A 的数量不能少于 B 的两倍”的右侧从 0 调整为 -20 后模型变得可行。这套逻辑虽然简单但能覆盖大多数用户笔误和数据录入错误。更复杂的情况比如需要同时松弛多条约束我会把所有约束的松弛量作为决策变量加入模型以松弛总量最小为目标直接求一个“最小修复方案”。这样得到的结果比人工试错专业很多。5. 求解器接入与结果解释5.1 求解器抽象层设计与超时保护求解器不能直接散落在业务逻辑里否则以后换求解器会是一场灾难。我设计了一个求解器抽象层对外只暴露一个solve方法输入 IR 模型输出状态和解。这个方法内部负责将 IR 映射到具体求解器 API调用时统一设置超时时间、线程数和相对间隙。超时保护是必须做的。自然语言输入的不确定性太大用户可能随口说一个规模庞大的问题。我一般设定三种超时档位简单问题 5 秒普通问题 15 秒复杂整数问题 60 秒。如果超时后还没拿到最优解但已经找到可行解直接返回当前可行解并在报告里注明“达到时间限制返回当前最好解”如果连可行解都没找到就返回“该问题在有限时间内未能求解”。这里有一个细节求解器给出的状态码每一家不完全一样甚至不同版本之间也有差异。我在抽象层里把所有状态统一替换成五类OPTIMAL、FEASIBLE、INFEASIBLE、UNBOUNDED、TIMEOUT。上层代码永远只判断这五个状态这样换求解器几乎不用改业务代码。5.2 结果反解析从变量 ID 到自然语言报告求解器返回的是一堆变量 ID 和数值用户根本不关心这些。结果解释模块要做的是把这些数值填回到原始语义槽位中。我在 IR 里给每个变量存了name这个 name 就是自然语言报告需要的真实实体名。报告生成我分为三步。第一步把变量 ID 替换成中文名称。例如 x_a 替换成 A商品。第二步按目标方向输出核心结论比如“最大利润为 2600 元”。第三步列出关键决策变量的取值只列用户关心且有非零值的变量不要把所有变量都倒出来。如果某变量取值是 0除非用户明确要完整结果否则我倾向于不展示避免刷屏。如果原句中有单位报告会把数值和单位合并。比如原句“生产多少个A”报告就会显示“生产 40 件A”。这些单位信息我也存进了 IR 的变量节点具体字段可以在变量定义里加一个unit映射阶段不参与计算只用于报告。5.3 当模型不可行时给用户什么反馈这一节我还是想强调反馈质量决定这个系统能不能被真实使用。早期版本遇到不可行我就直接弹一个“模型不可行”的异常页面用户完全不知道哪里错了。后来加了 IIS 分析和松弛建议反馈才变得可用。我建议反馈文案分成三级。第一级结论比如“当前条件无法同时满足”。第二级原因列出冲突约束对应的原始句子。第三级建议给出 1 到 2 个修复方向可以是放宽库存上限也可以是去掉某条比例约束。每一级都用自然语言生成不要展示内部错误码。用户可能完全不懂数学优化但他一定懂“仓库存不下”和“销售要求太多”之间的矛盾。如果你要把这个系统接入线上务必把结果解释模块单独做成可以 mock 的纯函数输入 IR 和求解器状态输出报告字符串。这样测试时不需要真正调用求解器直接喂固定 IR 就能验证文案质量。我踩过的一个坑是早期把报告生成逻辑写在了求解器回调里导致每次调试都要花时间跑一遍模型白白浪费很多时间。6. 测试与排坑实录6.1 我们的测试语料库怎么建搞自然语言系统没有测试语料就是耍流氓。我建了一个按难度分级的测试集目前在本地跑一百多条用例每条用例都是一组“输入文本 期望 IR 期望报告片段”。难度数量覆盖内容L120单变量极值、直接上下界L240多变量利润、标准线性约束L330比例约束、单位换算、隐藏乘法关系L420整数变量、不可行问题、无界问题L1 测试最基础的“求最大利润每件利润 5 元最多卖 100 件”这类句子。L2 加入多个产品和库存上限。L3 重点测试自然语言的各种同义改写比如“A 至少是 B 的两倍”和“B 不能超过 A 的一半”。L4 专门放求解器状态相关的用例比如故意输入一个矛盾条件验证系统能否给出 IIS 反馈。测试执行时我并不是直接对比文本而是对比 IR 结构。IR 是一个字典直接深比较即可。报告部分只对比关键词是否出现比如“最大利润”和“2600”是否都在报告里。这个测试体系帮我重构了几次解析逻辑但回归时几乎都能一次通过。6.2 踩过的 5 个典型坑这个项目踩过的坑我挑最典型的五个记录在这里都是血泪教训。第一中文分词把“不少于”切错。早期用通用分词器切出来的是“不”“少于”正则匹配“不少于”就失败了。后来我把领域词典优先加到分词器里把“不少于”“不超过”“至少”“至多”都当成整体 token准确率立刻上来。第二解析“两倍”时丢掉关系。用户说“A是B的两倍”我一度解析成 A ≥ 2然后系统里根本没有 B 的参与结果模型完全脱离原意。正确写法是 A - 2B 0关键是要搞清楚倍数到底在谁和谁之间。第三整数变量和生产量不匹配。用户说“要生产多少件”变量设为整数是对的但如果同时给出“每天生产 8 小时每小时 50 件”这种单位换算直接把 8 和 50 当作两个变量会非常离谱。正确的做法是生成一个隐藏资源约束总生产量 ≤ 8*50。第四求解器超时时没有返回可行解。有些求解器在超时后会给出一个当前解但状态不是最优。如果不区分状态直接把结果当最优输出用户会被误导。我在报告里明确标注“当前为可行解非最优解”这很重要。第五模型初始化时把上界设成无穷大。最大化的目标下一个变量无上界就会导致无界解。后来我增加了一条默认规则凡是自然语言中能推断出库存上限或资源上限的一律设置有限上界实在推断不出就根据同批次数字的数量级自动补一个大数。6.3 一点性能调优心得我用的是开源混合整数规划求解器性能上不需要追求极端但一些基本优化还是必要的。最容易出现瓶颈的地方是正则表达式频繁编译。Python 里正则每次匹配都需要编译如果句子很长规则很多性能会明显下降。我把所有正则表达式在模块加载时统一用re.compile缓存速度提升非常明显。第二个常用优化是解析树复用。同一个 IR 的 source 字段可能对应多轮对话中的同一句话重复解析很浪费。我给每个解析结果加了一个轻量缓存以句子哈希为 key缓存 IR 子片段。如果句子没有变化直接读缓存。第三个优化是求解器实例复用。每次求解都新建求解器再释放对短小模型问题不大但面对大量并发请求时频繁创建对象会产生不必要的开销。我在抽象层里维护了一个求解器实例池通过并发安全的方式复用空闲实例。这里要注意同一个实例不能同时求解多个模型否则状态会互相污染。还有一个容易被忽略的点整数变量数量对求解时间影响极大。能合并的整数决策变量尽量合并比如多个相同单位的产品如果它们的约束完全对称就合并成一个计数变量求解速度会快很多。但这属于模型简化技巧需要根据具体业务做权衡不要盲目合并。结尾最后再说一个我实际用下来的经验这个系统的收益不是“完全取代人”而是把重复性的调度、分配、计划问题变成一种可复用的服务。你不需要把所有自然语言都理解得面面俱到只需要把领域内最常见的表达方式固化下来再配上一套好的冲突反馈机制用户就已经会觉得你很懂他。下一步我准备在这个 IR 基础上扩展非线性表达比如“运输成本随距离阶梯增长”这类分段线性问题思路还是这一篇的 IR 隔离先让自然语言解析输出分段点再映射成分段线性约束。你可以顺着这个方向先玩起来有问题随时回去看看前几篇的基础模块。
