（来源：王源 运筹OR帷幄）

最近，大模型在运筹优化领域的应用无疑是最靓的仔。尤其是“用大模型进行自动建模”，已经成为一个很热的研究话题。这里我想结合自己的实践，谈一点关于这个方向在业界应用落地中的思考。

首先，我认为自动建模本身是非常有价值的。大模型给我们提供了一个很强力的建模工具。我自己现在也经常用大模型来辅助建立运筹优化模型。哪怕是一些比较复杂的业务问题，只要能用自然语言把决策变量、约束条件、目标函数说清楚，当前主流大模型已经可以比较稳定地给出质量很高的数学模型。很多时候，把数学模型放到 Cursor 里继续生成代码，几乎都可以做到一次跑通。但是反过来，我目前对“大模型自动建模”这个方向中的两个常见路线并不是特别看好。

第一个是：专门微调一个“面向自动建模的大模型”。

我并不是说微调完全没有价值。在一些私有化部署或者终端设备的场景下，微调是有意义的。但是，如果把“微调一个专门会建模的大模型”当成这个方向的主路线，我个人并不太看好。

原因很简单：对于很多数学建模任务来说，只要问题描述足够清楚，GPT、Claude、Gemini 等主流基础模型本身已经做得很好了。尤其是在 MILP、CP、SAT、网络流、排产调度、装箱、路径规划这些典型运筹优化问题中，大模型对“从自然语言到数学模型”的转换能力已经相当强。

更关键的是，主流基础模型的迭代速度非常快，现在一线大模型厂商在后训练中越来越强调对大模型 Agent 能力的后训练。你可能花了几个月时间，整理数据、设计样本、烧算力、微调出一个自动建模模型，结果下一个版本的基础模型一发布，通用模型在理解能力、推理能力和代码生成能力上又超过了你基于老版本微调出来的大模型。这样一来，微调模型很容易陷入一个尴尬局面：投入成本很高，但真正拉开的能力差距并不大。

第二个是：直接把“大模型自动建模”等同于“业界应用落地”。

我认为大模型自动建模对科研的影响会很大，它会显著提高科研的效率，但我对它的定位还是在 AI for Science 这个范畴内。这也就意味着单纯的自动数学建模并非业界落地项目的核心瓶颈。

因为这里有一个重要前提：只有当我们已经把业务逻辑说清楚之后，大模型才能比较准确地完成数学建模。换句话说，大模型自动建模做的是从清晰的业务逻辑描述，转换成数学模型、约束条件、目标函数和求解器代码。

但在真实企业项目里，最难的往往不是后半段，而是前半段：到底企业的业务规则是什么？哪些规则是显性的，哪些规则只存在于老员工经验里？哪些规则来自系统，哪些规则来自文档，哪些规则来自微信群和会议纪要？哪些规则是硬约束，哪些规则只是经验偏好？哪些异常情况需要人工审批，哪些可以自动处理？

业务建模和数学建模

聊到这里想要理解大模型在企业落地的关键，我们需要先区分的是两个概念：业务建模和数学建模。

业务建模，是为了描述企业真实业务是如何运转的。它关心的是业务对象、业务流程、业务规则、异常处理、审批逻辑、组织职责和系统数据之间的关系。

数学建模，是为了把已经明确的业务问题转化成可以计算、可以优化、可以求解的形式。它关心的是决策变量、参数、目标函数、约束条件和求解算法。

这两者看起来都叫“建模”，但它们解决的问题完全不一样。大模型自动建模解决的是已经有了业务建模的情况下，让大模型给出数学模型的问题。但是业务模型从哪里来依然是一个亟待解决的核心问题。为了更直观地说明业务建模和数学建模的区别，我们可以看一个最简单的例子：考勤系统。

一个具体的例子（以考勤系统为例）

假设一个企业有一套考勤系统，系统里记录了员工每天上班和下班的刷卡时间。比如每条记录包括员工 ID、日期、上班打卡时间、下班打卡时间、所属部门、岗位、班次、请假记录、外勤申请、加班申请等信息。

如果只是从数据层面看，考勤系统本身只是在记录事实：

某个员工，某一天，几点打卡上班，几点打卡下班。

我把考勤系统这种只作为记录作用的系统称之为“记录系统”，记录系统只记录了发生了什么，但记录系统本身并不会描述这些事情为什么发生，这些事情发生有什么规律，这些事情需要遵循哪些业务逻辑。记录系统在企业中大量存在，例如MES系统就是典型的记录系统。记录系统确实重要，但我们希望可以通过记录系统中的数据来反向推测出业务逻辑。这在以往来说是不太可能的事情，但是实际上目前大模型的能力给我们提供了这种可能性。

比如，大模型读取了大量打卡记录之后，发现大多数办公室员工都在 8:40 到 9:00 之间打卡，那么它可能可以推断出一条业务规则：

这家公司办公室员工的标准上班时间是早上 9 点。

这就是一个业务建模结果。它不是数学公式，而是一条自然语言描述的业务规则。

但是，真实的考勤规则通常远远没有这么简单。比如：

办公室员工 9 点上班，但生产线员工可能要求 8:30 到岗。

普通员工只需要满足打卡时间要求，但某些特殊岗位员工必须具备特定资质，例如安全员、设备操作员、叉车司机、消防值班人员等。这类人员不仅要判断是否迟到，还要判断某个班次是否满足资质覆盖要求。

法定节假日默认不需要考勤，但是如果企业安排了节假日值班，那么当天又要重新纳入考勤规则。周末通常不考勤，但是如果因为调休变成工作日，那么周末也可能需要考勤。

员工如果前一天晚上加班到很晚，并且系统里有审批通过的加班记录，那么第二天可能允许晚到。例如前一天加班超过 2 小时，第二天允许晚到 1 小时；如果加班到凌晨，第二天可以申请调休半天。

如果是销售人员或者市场部的人员，大部分的时候都在外边拜访客户，那么他们的打卡规则又和其他员工不一样。

员工如果有请假、外勤、出差、远程办公审批，那么当天的打卡规则也会发生变化。没有打卡不一定是旷工，迟到也不一定真的是迟到。

在公司里边并没有一个统一的文档，像法律条文一样把这些复杂的考勤规则逐条写的清清楚楚。我们期望做的是让大模型读取考勤系统已有的记录来推导出这背后的考勤规则，形成一套结构化的自然语言描述的考勤规则。

这些规则都属于业务建模的范畴。业务建模要回答的是：

谁需要考勤？ 哪一天需要考勤？ 每个人适用哪一种考勤规则？ 什么情况下算迟到？ 什么情况下不算迟到？ 哪些异常需要自动豁免？ 哪些异常需要人工审批？ 哪些岗位必须满足资质覆盖？ 这些问题没有搞清楚，后面的数学建模就无从谈起。

当业务规则被明确之后，才进入数学建模阶段。数学建模需要做的事情是 将上述用自然语言描述的业务规则转化为数学模型。

从例子说明业务建模和数学建模的区别

从这个例子可以看到，业务建模和数学建模的边界非常清楚。

业务建模负责回答：企业到底是怎么定义“迟到”“出勤”“调休”“节假日”“特殊岗位覆盖”的？

数学建模负责回答：在这些定义已经明确之后，如何用变量和约束把它们表达出来？

大模型现在很擅长把后一件事做好。只要你告诉它：“员工当天需要考勤时，打卡时间不能晚于上班时间；如果迟到，则 late 变量为 1；如果当天请假或节假日，则不判断迟到。”它可以帮你写出不错的约束表达式。

但真正困难的是前一件事：大模型如何从企业的考勤系统、制度文档、HR 说明、审批流程、历史数据、聊天记录和会议纪要中，自动抽取出这些业务规则，并判断哪些规则是正式规则，哪些只是个别人的经验说法，哪些规则之间还存在冲突。

这才是业界真正需要解决的问题。

因此，我认为大模型自动建模在产业落地中，不能只停留在“自动生成数学模型”这一层。更重要的方向应该是：

先用大模型辅助企业完成业务建模，再进一步把业务模型转化成数学模型、规则引擎或者优化模型。

也就是说，真正在整条链路中最核心的价值并不是：

自然语言描述 → 数学模型

而应该是：

企业系统、数据、文档、流程、会议记录、聊天记录

→ 业务对象识别

→ 业务规则抽取

→ 业务模型构建

→ 规则冲突检查

→ 数学模型生成

→ 求解器调用

→ 结果解释与审计

在这个链路里，数学建模只是其中一环。它很重要，但不是全部。对于企业来说，更大的价值在于把长期隐藏在系统、文档、经验和组织流程中的业务逻辑结构化、显式化、可解释化、可审计化。

总结

大模型未来在业界的应用的发展方向是“从企业真实业务资料中自动构建业务模型，再自动转化为数学模型和优化系统”，这样才可能成为企业智能化系统建设中的基础能力。