在 AI 技术狂飙的今天,大模型看似无所不能,却在垂直领域迟迟无法进入深水区,差的可能是一个优质的数学模型?
数学建模乍看是高岭之花,实则在大模型技术飞速发展的当下,已经成为大模型工程师的必备技能、思维。
数学建模到底是什么?
数学建模和大模型之间怎么配合?
如何将现实问题抽象成数学问题,最后帮助解决实际问题?
都在招大模型工程师,数学建模这个能力能帮助到开发者吗?
带着这些问题,我们找到了一位国企人工智能技术负责人、公众号“数学建模岛”主理人——Fanstuck 熊文韬。作为一个数学建模与人工智能爱好者与实践者,熊文韬从个人的项目经历出发,解释了这些关于数学建模的问题。
以下为采访实录。
数学建模与 LLMs
数学建模是通过数学语言和方法描述、分析并预测现实中的各类问题与现象。核心是将实际生活遇到的问题进行抽象化与简化处理,并将这些抽象结果转化为数据化的方法体系,进而输入给大语言模型使用。
本质上,大语言模型本身也是一种复杂数学模型,但传统数学建模通常依赖人工构建且具有显式表达式,而大模型属于机器学习领域,通过海量数据和算法自动生成的数学模型。
两者本质上是互补关系——数学建模提供基础思路与方法论,而大模型则是数学建模思想在人工智能领域的实际应用体现。
比如一个可能比较常见的场景,一家奶茶店,想要预测每天的销量。如果用传统数学建模方法,核心流程包括:收集过去数月的数据,例如天气、节假日、社交活动等,通过回归模型或时间序列预测模型构建销量预测数学模型,输出每日销量预测值。然后再将预测数据输入大模型,基于预测销量动态优化奶茶库存管理与人员调度方案。
最终是用大模型快速结合背景知识,生成决策建议——这种结合模式本质上是将数学建模的理论框架与大模型的快速推理能力相融合,形成方法论与智能推荐的协同应用。
因为通用大模型在初始阶段缺乏垂直领域的专业数据、术语体系及合理性判断能力,而这类能力又无法通过通用训练直接获得,所以需要借助数学建模方法对细分领域的复杂问题建立标准化评判体系。
数学模型在整个过程中承担的就是“人工标注替代”功能:通过设定数学规则,如阈值判定、特征加权等,自动生成标准化标签,再将标签数据输入大模型进行微调训练。通过这种协同机制,大模型逐步学习垂直领域的核心判定逻辑,例如医疗诊断标准或法律条款解读,最终实现“数学模型提供领域规则基准,大模型扩展规则解释与场景泛化能力”的双向增强闭环。

我之前做过很多垂类领域项目,就是用大模型去解决细分行业的定制化问题,例如图标文件合规性审核与招投标中得非标项目的风险量化建模。
这类场景中,大模型难以直接理解依赖人工经验的主观判断逻辑,例如如何界定合同中的模糊责任条款,因此需要结合机器学习与数学建模。比如对于非标项目的风险量化模型,因为当面对含数十项法律条款的招标文件时,通用大语言模型难以满足需求,它缺乏对专业术语体系的结构化解析能力,更无法处理风险因子的数学关系建模。
所以需要我们先构建领域知识图谱,通过命名实体识别 NER 提取条款中的法律主体、权责关系、约束条件等核心要素,形成结构化特征集。随后采用熵权法与层次分析法进行多准则决策建模:基于历史非标案例数据,量化各条款的风险贡献度,最终输出非标风险指数模型,给出风险的评分,最终帮助大模型进行判断。
建模也可以用来提升大模型的安全性。大模型的合规风险主要源于其黑箱特性——我们无法洞悉其内部决策逻辑,导致问题溯源困难。这种不可解释性导致监管机制难以有效实施。但在实际项目落地中,我们通过引入数据建模工具实现透明化控制。
核心方法论包含两个层面。第一是部署可解释性分析工具,如基于博弈论的 SHAP 算法,通过量化特征变量对预测结果的贡献度来解析模型决策路径。例如在信贷审批场景中,若模型拒绝贷款申请,SHAP 可解析出年龄因子贡献值为-0.4、收入因子为-0.3等关键负面指标。
二是构建代理模型系统,通过训练决策树或规则模型来拟合原始模型的输入输出映射关系。该方法可适配多种场景,无论是传统业务模型还是大模型,均可生成人类可理解的决策规则链,从而满足监管审计要求。
反过来,大模型对于数学建模来说,也可以理解为一种反向辅助工具,其核心价值在于帮助我们解决数据建模中的痛点。具体来说,传统数据建模过程中通常会面临以下挑战:首先是专业知识壁垒和建模思维局限,其次是分析方法的选择困难,以及总结能力不足等问题。而大模型在这些方面展现出显著优势:
-
首先,它具备跨领域的知识储备系统。当我们需要了解建模背景或项目背景时,大模型既能调用内置知识库,又能通过联网能力整合相关学术论文、行业报告等多元信息源,为项目提供多维度的参考依据。
-
其次,在获得数据后,大模型能够进行深度逻辑推理与分析。其强大的自然语言处理能力不仅体现在精准理解用户需求,更表现在辅助数学建模的整个流程中,包括但不限于参数优化、算法选择等关键环节。
-
最后,在成果总结阶段,大模型可生成富有启发性的结构化建议。这种智能化的输出不仅能有效提升文档质量,更能通过创新性观点激发研究人员的灵感,形成良性的人机协作模式。
找到核心问题,抽象成数学语言
有一个流传甚广的观点是"所有AI问题最终都是数学问题",其实作为人工智能领域的实践者,我认为这句话在本质上是对的,但表述并不完全准确,合理性和局限性都很明显。
从合理性的维度来看,该观点的底层逻辑确实成立。无论是经典机器学习、深度学习还是强化学习框架,如混合专家模型 MoE 等核心技术,本质上都是数学算法在特定场景下的组合实现。从 AI 技术实现的核心流程来看,其合理性确实植根于数学基础。数据处理、特征工程、模型训练与评估等关键环节的优化,本质上都需要数学方法的支撑。因此从技术原理的底层视角而言,"所有 AI 问题都是数学问题"的论断具有理论自洽性。
但这句话也存在明显的认知局限性:首先,数学语言难以完整描述伦理道德、社会影响及人类心理等非结构化要素。这些涉及价值判断的复杂维度,无法通过纯数学形式化体系进行有效表征。其次,AI 项目的实际落地过程涉及多维度的复杂性——商业价值转化、用户体验设计、法律合规框架以及组织内部协同等要素往往超出数学模型的解释范畴,更多属于商业逻辑与管理科学的交叉领域。
因此更准确的表述应为:AI 系统的底层架构确由数学原理构筑,但实际应用场景中的问题本质上属于数学与多元社会因素共同作用的复合型命题。
而在数学建模中,非常重要的一步是将显示问题抽象成数学问题。
抽象能力的本质在于从现实场景中精准识别核心要素,并建立数学模型,就是要剥离次要干扰因素,运用数学语言进行本质特征的概括与重构。
我们需要将复杂问题拆分成若干个具有指向性的问题,并且确定每个子问题的目标,是属于优化、预测,还是决策性质?然后对每个子问题去提取核心要素,确定哪些因素是必须要考虑到的?哪些是可以暂时忽略的?
比如针对外卖小哥送餐路径做优化,首先可以对问题进行拆解,比如配送时间如何优化可以最快速完成全部订单?第二又可以设立一个问题——如何优化用户满意度?根据这两个问题确定下一个目标,比如送餐时间达到最短需要识别哪些核心因素,比如送餐速度、餐厅位置、客户位置、路况,非核心因素比如价格情绪、餐厅品牌等等。那么再通过抓核心、放非核心的原则,就可以快速抽象我们遇到的现实问题,去做数据建模。
其实数学建模的本质思维也可以无处不在。我的工作更多地聚焦在做各种 API 接口提供给企业上下游使用,前几天我做了一个 MCP Server,我发现它实现起来还是比较容易的,MCP Server 更多地是作为一个数据调用的中转站,通过大模型访问 MCP Server,然后 MCP Server 又去访问不通的 API 端口获得数据,最后再返还给大模型,极大减少了大模型数据处理的压力。MCP 其实就相当于一个 USB 转接口,一个扩展盘可以插五六个街口。甚至于它可以理解成是一个数学建模的模型,仅做中转结合,将所有 API 返回的数据通过统一的数据预处理和清晰,得到结果返回给大模型。
从校园里的建模竞赛到企业级落地,数学思维如何进化成开发者的“生存技能”?
我的本科专业是大数据工程,主攻数据挖掘方向。涉及到分布式计算框架,如 Hadoop、Spark 软件的学习,还有数据清洗与特征工程等核心技术模块,同时涉及大量机器学习和深度学习的建模实践。
2018年左右,大模型研究还没爆发成熟阶段,当时主要聚焦于传统机器学习与深度学习算法的工程化应用。从技术演进视角来看,早期研究的卷积神经网络、循环神经网络等模型架构,本质上与当前大语言模型共享着相同的数理基础,就是将数学原理转化为可编程的算法逻辑。虽然在2018年学术界尚未形成如今的大模型范式,但当时在时序预测、图像分类等领域积累的特征工程方法论,在大模型时代仍具有迁移价值。
学生时代,因为参加全国大学生数学建模竞赛,我开始逐渐深入研究数学建模。这种以实际问题为导向的跨学科训练,要求参赛者在限定时间内构建数学模型解决现实问题,这种从问题定义到解决方案落地的完整闭环,极大提升了我的结构化思维能力和算法实现水平。例如我之前做过一个城市交通流量预测项目,通过时空序列建模将现实路网抽象为图神经网络的可计算对象,这种将物理世界映射到数学空间的思维方式,对我影响也很深刻。
我也开了一个公众号,主要发布以数据建模为主的文章,也会发一些对人工智能的看法和总结。工作之余我也比较喜欢写文章、打比赛。我经常在做完一个项目后,系统梳理技术实现细节与创新点,将思考成果发布在技术社区。通过读者多维度的反馈,能有效发现项目盲点并形成优化闭环。我也经常参与一个 AI 竞赛,竞赛排名带来的显性成果可量化技术能力,这种即时反馈机制能持续激发学习动力。

针对极端天气事件和财产保险可持续性的模型建立的解决思路,来源「数学建模岛」公众号
文章
如果从职业发展角度来说,我觉得数学建模很难作为一个职业去进行衡量,因为很少有和数学建模非常相关的职业,它更多的是和不同领域做结合。比如我们会把数学建模放到某个具体的垂直领域中,结合大模型做垂类问题的分析解答,那么这时候数学建模就是一个大模型工程师必备的技能和思维。比如将其应用于金融领域,则转化为量化工程师必备的建模能力。
关键在于通过数学语言实现领域问题的结构化表达,进而形成特定行业的解决方案设计能力,所以这个技能的应用前景还是比较广的,特别是大模型技术普及后,这种将数学建模与行业知识耦合的能力,已成为跨领域验证技术方案可行性的关键支撑。