1. 为什么“传统算法大模型”才是工业界的真实解法这两年做大模型落地的人都有一个共同感受Demo 惊艳上线拉胯。你在本地用 Ollama 跑个 7B 模型问它几个问题感觉“这玩意儿要取代一切了”可真把它塞进一条业务流水线延迟、幻觉、成本、稳定性四座大山立刻压下来。我所在的团队从 2023 年开始做工业质检和文档智能两条线前后踩了十几个坑最后沉淀下来的架构没有一个是“纯大模型”的全部是传统算法和大模型各管一段、互相兜底。先把结论摆在这儿传统算法负责“确定性、可解释、低延迟、可复现”的部分大模型负责“语义理解、模糊匹配、开放域生成、长尾兜底”的部分。这不是妥协而是分工。工业场景里一个环节只要能用规则、统计、几何、信号处理稳定解决就绝不该交给大模型——不是大模型不行是它在这个环节上性价比太低、方差太大。这篇文章面向三类人一是正在做 AI 应用开发、纠结“哪些模块该上大模型”的工程师二是被老板要求“全面 AI 化”但心里没底的技术负责人三是对大模型有兴趣、想搞清楚它在真实系统里到底扮演什么角色的学习者。我会把分工的判据、典型架构、参数取舍、踩坑记录全部摊开讲尽量让你看完就能对照自己的项目做一次“分工体检”。需要提前说明的是文中涉及的具体模型选型、部署方式、参数配置都是基于我们团队和同行常见实践的合理补充不是唯一答案。工业落地没有银弹只有适配。2. 分工的底层判据什么该给传统算法什么该给大模型2.1 四个维度决定一个模块的归属判断一个子任务该用传统算法还是大模型我一般看四个维度按优先级排序确定性要求输出是否必须可复现、可审计比如金额计算、坐标定位、合规校验错一次就是事故这类必须传统算法。延迟预算单次调用能否容忍几百毫秒到几秒传统算法常在毫秒级大模型推理尤其是本地部署动辄几百毫秒起步长文本更久。输入的结构化程度输入是规整的数值、图像坐标、日志字段还是自然语言、模糊描述、多模态混合前者传统算法占优后者大模型占优。长尾覆盖率规则能覆盖 80% 还是 60%剩下那部分是不是“千奇百怪、写不完的 if-else”如果是大模型兜底。我习惯用一个简单的打分表来决策团队内部叫“分工四象限”维度偏向传统算法偏向大模型确定性必须可复现、可审计允许一定概率性输出延迟毫秒级硬约束秒级可接受输入结构结构化、数值、几何自然语言、多模态长尾规则可覆盖 80%长尾极长、规则写不完一个模块如果前三项都偏左哪怕第四项偏右也应该“传统算法为主、大模型为辅”。反过来如果前三项都偏右那就大胆交给大模型但一定要加校验层。2.2 一个反直觉的结论大模型最擅长的是“翻译”不是“计算”很多人第一次用大模型做业务最容易犯的错是让它做计算和精确匹配。比如让模型从一段文本里算出总价、比对两个编号是否一致。实测下来这类任务大模型的错误率远高于你的预期尤其是数字位数多、格式不统一的时候。大模型真正强的是语义翻译把非结构化的人类表达翻译成结构化的、传统算法能吃的输入。比如把“客户说下周三之前要但语气很急”翻译成{deadline: 下周三, priority: high}把一张模糊的工单照片翻译成字段化的 JSON。翻译完之后的计算、比对、校验全部交回传统算法。这个“翻译层”定位是我认为大模型在工业系统里最稳、最值钱的位置。2.3 成本账要算清楚别被“免费大模型”迷惑热搜里经常出现“免费大模型”“本地部署大模型”这类词很多人以为本地跑就零成本。实际算一笔账一张 8G 显存的卡跑 7B 量化模型吞吐有限并发一上来就排队要撑起生产级并发要么堆卡要么上 vLLM 这类高吞吐推理框架做批处理。电费、硬件折旧、运维人力都是钱。而传统算法呢一个精心写的规则引擎单核每秒能处理几万次请求服务器成本几乎可以忽略。所以在“能用规则解决”的地方硬上大模型本质是拿最贵的算力做最便宜的事。我见过一个项目用大模型做日志分类单条延迟 800ms后来改成关键词正则轻量分类器延迟降到 2ms准确率还涨了 3 个点。这就是分工没做好的典型代价。3. 典型工业架构三层分工怎么落地3.1 分层架构总览我们最终稳定下来的架构大致分三层从上到下语义层大模型负责把自然语言、多模态输入翻译成结构化意图处理长尾和模糊表达。决策层传统算法规则引擎、状态机、优化求解、统计模型负责确定性决策和计算。执行层传统算法工程数据库操作、坐标变换、信号处理、硬件控制要求绝对可靠。大模型只在第一层出现且它的输出必须经过第二层的校验才能进入第三层。这个“大模型不直接碰执行”的原则帮我们挡掉了绝大多数线上事故。3.2 语义层的设计要点语义层的核心任务是把“人话”变成“机器话”。这里有几个实操要点强制结构化输出不要让模型自由发挥用 JSON Schema、函数调用function calling或约束解码把输出锁死成固定字段。我们内部要求所有语义层输出必须是可校验的 JSON。置信度与兜底让模型对每个字段给出置信度低于阈值的字段走人工或规则兜底。别指望模型永远对。提示词版本化提示词就是代码必须进版本管理。我们吃过亏有人线上直接改提示词结果整个流水线输出格式变了下游全崩。3.3 决策层的传统算法选型决策层用什么取决于业务。常见的有规则引擎Drools、自研 DSL适合合规校验、风控。状态机订单流转、工单状态天然适合状态机。优化求解排产、路径规划用 OR-Tools、线性规划。统计/机器学习模型XGBoost、轻量神经网络适合分类、回归、异常检测。这些组件的共同点是输入输出确定、可测试、可回滚。它们和大模型之间用严格的数据契约连接契约变了要同步改两边。3.4 一个真实案例文档智能流水线我们做过一条合同审核流水线早期想“全大模型”结果准确率 82%延迟 3 秒成本高得离谱。改成分工后大模型只做“条款抽取”把合同段落翻译成结构化条款传统算法做“条款比对”和标准模板逐条比对命中规则库规则引擎做“风险判定”比如金额超限、期限异常。改造后准确率 96%延迟 400ms成本降了七成。关键变化就是大模型不再做判断只做翻译。4. 实操过程从零搭一条分工流水线4.1 第一步任务拆解与归属标注拿到一个需求先别写代码拿张纸把流程拆成原子任务每个任务标注“传统/大模型/混合”。拆解粒度建议到“一个函数能完成”的程度。比如“审核合同”拆成读取文件、OCR、段落切分、条款抽取、条款比对、风险判定、生成报告。其中 OCR 和段落切分是传统条款抽取是大模型比对和判定是传统报告生成可以混合模板大模型润色。4.2 第二步定义数据契约每个任务之间用 JSON 契约连接字段名、类型、必填项、取值范围全部写死。契约一旦确定上下游并行开发。这一步是分工能落地的前提契约不清分工就是空谈。{ clause_type: payment, content: 甲方应在验收后30日内支付全款, confidence: 0.93, source_span: [120, 145] }4.3 第三步大模型侧的实现与约束大模型侧我们一般用本地部署选型看场景。7B 级别适合抽取和分类14B 以上适合复杂推理。部署方式上vLLM 适合高并发批处理Ollama 适合快速验证。提示词里必须包含角色定义、输出格式、字段说明、few-shot 示例、边界情况处理。输出用 JSON Schema 约束解析失败直接重试或兜底。4.4 第四步传统算法侧的实现与测试传统算法侧要写单元测试覆盖率尽量高。规则引擎的每条规则都要有正例和反例。统计模型要有离线评估和线上监控。这一层的稳定性直接决定整个系统的下限。4.5 第五步联调与灰度联调阶段重点看两件事大模型输出的分布是否稳定传统算法对异常输入的容错是否足够。灰度上线时先让大模型输出只记录不生效对比传统算法的结果观察一段时间再切换。5. 常见问题与排查技巧实录5.1 大模型输出格式漂移现象昨天还好好的 JSON今天多了个字段或少了引号。原因提示词被改、模型版本变了、输入触发了模型的“自由发挥”。解决输出强约束解析失败重试版本锁定。我们内部规定模型版本和提示词版本必须一起发布。5.2 传统算法规则爆炸现象规则越写越多维护成本飙升。原因把长尾硬塞进规则。解决把长尾交给大模型兜底规则只保留高频、高确定性的部分。规则数量控制在可维护范围内。5.3 延迟不达标现象端到端延迟超预算。排查先看大模型调用次数和输入长度再看传统算法是否有性能瓶颈。常见优化大模型批处理、缓存、输入截断、传统算法换更高效的数据结构。5.4 大模型“一本正经胡说”现象抽取的字段看似合理实则错误。解决置信度阈值交叉校验人工抽检。关键字段必须由传统算法二次校验比如金额字段用正则从原文再抽一遍比对。5.5 并发上不去现象QPS 一高就排队。原因大模型推理是瓶颈。解决vLLM 批处理、请求队列、降级策略高并发时切到规则兜底。传统算法侧一般不是瓶颈除非有锁竞争。问题根因解决格式漂移提示词/版本变动强约束版本锁定规则爆炸长尾硬塞规则长尾交大模型延迟超标大模型调用过多批处理缓存截断幻觉模型概率性输出置信度交叉校验并发瓶颈推理吞吐不足vLLM降级6. 我踩过的坑和几条硬经验第一条别让大模型碰钱和坐标。金额、坐标、ID 这类字段错一位就是事故必须传统算法兜底。第二条提示词进 Git。我们曾经因为线上改提示词导致格式崩了排查了半天。现在提示词和代码一起 review、一起发布。第三条大模型输出永远当作“不可信输入”。下游必须做校验就像对待用户输入一样。第四条先跑通传统算法基线再叠大模型。没有基线你根本不知道大模型是帮忙还是添乱。第五条监控要覆盖大模型的输出分布。字段缺失率、置信度分布、重试率这些指标比准确率更早暴露问题。这套分工思路我们用了两年从质检到文档到客服基本都能套。核心就一句话让确定的归确定让模糊的归模糊中间用严格契约连接。你如果正在纠结某个模块要不要上大模型不妨先问自己那四个维度的问题答案通常就出来了。