这两年有一个感受越来越明显国产大模型已经从“能用、能试、能发论文”的阶段走到了“真上生产、真扛流量、真省钱”的阶段。前两年我们聊大模型讨论最多的是幻觉、上下文长度、谁能跑通一个 Demo现在圈子里的高频词换成了推理成本、评测基线、Agent 稳定性、数据回流。这种变化本身就是阶段切换的信号。我长期做企业级 AI 落地前后接触过不少国产大模型项目也踩过大量文档里不会写的坑。这篇文章不打算重复“大模型是什么”这种基础知识而是想围绕“过去一阶段的成果沉淀”和“下一阶段该往哪使劲”这两件事把我实际观察到的、验证过的东西整理出来。无论你是技术负责人、算法工程师还是刚准备把模型放进业务流程里的产品经理这篇文章应该都能给你一些可复用的判断框架。1. 上阶段沉淀下来的几笔核心家底1.1 底座能力从“能聊会写”进化到“多步骤任务”前几年的国产大模型给人最深的印象是“对话还行干活不行”。问它一个开放性问题回答得头头是道让它按照指定格式输出一批结构化数据经常给你夹带私货。跑几个业务场景最常见的反馈是“看起来什么都行放进真实流程里处处不行。”但经过过去这一阶段的迭代底座模型的几个核心指标有了实质性变化。最明显的是指令遵循能力。同样是解析合同、抽取字段、改写文案这类任务现在的国产模型已经能把“从第几段提取什么字段、输出成什么格式、要不要包含原始引用”这类约束执行得相当稳定。很多团队把原来用规则加小模型凑合的环节直接替换成大模型准确率反而更高。另一个变化是长文本处理能力的可用性。早两年的所谓“长上下文”往往是模型能读进去但读到后半段就开始丢失关键信息。现在的国产模型在几十万字级别的上下文里做定位、摘要、问答已经能保持不错的一致性。这意味着大批“长文档分析”类需求比如招标文件比对、年报风险点提取、历史工单聚类可以不用提前切碎重拼直接整段丢进去。我这里没有点名具体某个模型是因为国产模型阵营里开源和闭源各有各的打法。闭源 API 在效果上限上通常更稳适合把质量放在第一位的生产场景开源权重模型则在私有化部署、数据不出域、成本可控这几个维度上有不可替代的优势。你把这两类都纳入选型池实际上是有议价空间和技术备份的。1.2 多模态与上下文长度让应用范围拓宽多模态是这一阶段另一个被低估的成果。早期大家默认“大模型文本模型”图像输入要走额外的识别链路音频还要再挂一套转写服务。现在不少国产模型已经原生支持图文混合输入能直接看截图、看表格、看扫描件还能把图像里的信息跟文字描述放在一起联合理解。我帮某公司做内部工单系统改造时原来处理流程是用户上传截图 → OCR 服务转文字 → 关键词匹配 → 人工复核。这一套链路长、误识别多、维护成本高。换用支持视觉输入的大模型后截图直接进模型由模型同时完成版面理解、信息提取和意图判断三步变一步。实测下来单据类的字段提取准确率比原来的 OCR 加规则方案高了大约 8 个百分点而且新增单据类型时不用再写规则。这种“多模态 文本理解”的组合在实际项目里比单纯拼写能力有用得多。因为企业里大量数据是以截图、PDF、报表、手写备注等形式存在的你能省掉一整套前置处理管线模型的价值就直接体现出来了。1.3 开源权重模型把这些能力带进了工程团队国产大模型这一阶段最有意义的成果我认为不是某个模型的单点成绩而是开源权重模型的大量出现。它让模型能力从“少数几家 API 厂商的垄断资源”变成了“任何有 GPU 的团队都能拿去部署的基础设施”。开源权重模型的意义不只在于省钱。更重要的是它给了工程团队一个调试入口。你用 API 时遇到输出异常只能调 prompt、调参数调来调去都是黑盒开源权重模型可以量化、可以微调、可以替换解码策略甚至可以把中间层的输出拉出来做分析。对我这种做企业落地的人来说这种可控性非常关键。举个实际例子某客户要求所有数据必须留在内网原则上不能调用外部 API。如果放在两年前这个需求基本无解只能找商用一体机或者私有化部署的高价方案。现在开源权重模型跑在普通的 GPU 服务器上配合向量库和一套检索增强流程已经能满足大部分内部知识问答和文档处理需求。虽然效果天花板和顶尖闭源模型还有差距但“私有、可控、够用”这三个词对很多行业来说优先级远高于“刷榜第一”。2. 真正跑起来的场景都满足同一个模式2.1 检索增强改造知识库最落地也最容易做歪如果你去问已经部署了大模型的团队做得最多的场景是什么很大概率是“知识库问答”。企业里有大量制度文档、技术手册、历史方案、客服话术过去只能靠搜索框加人工翻文档现在都想用一个问答入口替代。检索增强生成RAG是目前最主流的知识库方案也是我见过做歪最多的方案。做歪的典型表现是文档切得不讲究检索召回的片段跟问题对不上模型生成时又把错误背景混进答案里。很多团队跑通 Demo 时觉得“效果不错”一上真实数据就露馅原因就是拿通用文档库的切分策略套到了企业文档上。我的经验是RAG 项目的成败其实在检索链路不在生成模型。你需要针对文档类型设计切分规则制度类文档按条款结构切技术手册按章节层级切工单记录按对话轮次切。每一类切片要保留足够的上下文锚点比如文档标题、章节编号、原文来源这些信息在召回和引用时都非常有用。做完整链路后再定一个评分口径比如“回答是否引用了正确来源”和“引用片段是否真的支撑结论”用这个口径来驱动迭代而不是单看模型说得好不好听。2.2 结构化输出与工具调用模型真正进入业务流程的入口大模型要进业务流程不是“聊得顺”就行关键是要能稳定产出结构化数据。比如从简历里提取候选人信息、从订单里识别退款原因、从客服会话里打标签这些都是标准的抽取任务。模型一旦输出不稳定下游系统的入库逻辑就得不停兜底项目自然就会烂尾。现阶段国产模型在 JSON 结构化输出上已经做得比较成熟配合函数调用能力可以做出相当复杂的工具调度。比如一个智能助手可以自主判断“用户要查天气就调天气接口要订会议室就查日历要写周报就读取项目数据”这在早期是不可想象的。不过要注意工具调用的稳定性依赖模型的规划能力而规划能力在复杂多步任务上仍然会出现丢步、重复调用、参数幻觉的问题。我的建议是不要一上来就做全自主 Agent。先做“单轮工具调用”也就是模型负责解析意图并填写参数系统负责执行和返回结果跑稳定之后再加多步任务和反思机制。很多团队跳过这个渐进过程直接给模型一堆工具让它自己编排最后线上事故频发这锅真不该让模型单独背。2.3 从单模型变成多模型编排用到后期你会发现单一模型解决所有问题的思路是错的。不同场景对模型的要求不一样有的要快有的要准有的要便宜有的必须在特定领域内不犯错。生产环境里合理的做法是“多模型编排”简单任务走轻量模型复杂任务升级到强模型专有任务可能还要挂一个垂直微调的小模型兜底。多模型编排听起来高端实现起来其实就是一套路由逻辑。我在几个项目里用的是这样的标准流程先对输入做一次意图分类判断任务难度和类型简单分类、信息提取类任务路由到低成本小模型开放问答、复杂推理、长文总结类任务路由到高能力大模型涉及隐私的请求强制走私有化部署的模型节点所有模型的输出都进统一日志用于后续评测和路由策略调优。这套流程跑起来后整体推理成本能降到原来单一强模型方案的 1/3 甚至更低而用户体验基本不受影响。关键是路由准确率要在 95% 以上否则用户的问题被送到小模型那里答错比不用大模型更糟。所以我建议路由策略前期靠规则加人工校验积累一段时间数据后再用小模型本身来分类。3. 阶段切换时最容易踩的四个坑3.1 拿评测集当合同线上效果不是刷出来的很多团队选型时只看几个公开榜单和内部测试集上的分数。这个做法不能说错但远远不够。公开榜单的数据分布很固定模型很容易在类似题目上“背答案”而你真实的业务数据是完全不同的分布评测分数再高也未必代表线上表现。我见过某团队在内部评测集上把两个模型的相对优劣判断反了原因是评测维度太少当时的评测集只覆盖了“问答准确性”没有覆盖“输出格式稳定性”。结果上线的模型经常截断字段、漏输出逼着下游系统做了一堆兼容补丁。教训就是评测集必须针对业务场景构建至少覆盖准确性、格式合规性、拒答正确率、防御性就是面对无关或恶意输入时会不会乱说这几类指标。3.2 只调 prompt 不调链路模型背了太多不该背的锅Prompt 调优是现在最普遍的优化手段但很多人把 prompt 当成了解决一切问题的钥匙。模型回答质量不行的原因往往是上游给的信息就有问题或者下游对输出的校验太弱。比如一个 RAG 场景检索模块召回的内容根本不含正确答案你在 prompt 里写一百句“请根据资料回答”也无济于事。所以排查性能问题时我的习惯是“先链路、后采样、最后再调 prompt”。先看数据传到模型之前有没有缺失再看线上样本有没有系统性规律最后才尝试修改提示词。如果链路设计合理很多 prompt 微调其实并不需要换成更精细的检索和更强的后处理就能解决。3.3 上下文无限只是个数学概念现在很多模型宣称百万级上下文实际测试也确有长文处理能力但“能读那么长”和“长文本中关键信息不丢”是两码事。当输入长度增加模型的注意力分布会变稀薄检索和定位关键内容的难度随之上升。很多时候用户把一份几百页的文档全部塞进上下文指望模型自动找到关键段落结果答案反而含糊。我的建议是长文本场景仍然要配合结构化预处理。先对文档做拆分、过滤、定位把最相关的几个片段组装成精简输入再交给模型。这跟 RAG 的思路本质上是一样的区别只是由系统来保证“喂给模型的都是有效信息”。上下文长度是兜底能力不是让你放弃检索的理由。3.4 交付不是上线瞬间而是持续迭代的起点大模型项目的复杂度被严重低估尤其是上线之后。数据分布会变用户行为会变模型版本也在更替当初验证过的效果很可能在下个月就偏离。有些团队把项目做到“能上线”就高呼胜利结果线上问题一堆又没人愿意持续投入最后项目慢慢烂尾。我比较认可的做法是把大模型能力当作一个需要持续运营的内部产品建立监控指标、设立人工抽检流程、定期用线上新样本做回归评测。模型版本更新要像发软件版本一样有完整的验证流程不经过回归评测不允许上线。这些基建不起眼却是项目从“Demo 能跑”到“业务真用”之间最关键的一层。4. 下一周期更值得投入的技术方向4.1 智能体不再拼“会调用工具”拼记忆和反思进入下一阶段“Agent”大概率不再只是概念名词。现在的智能体大多数是“会调工具的对话机器人”给它一个任务它按顺序调用接口完成就结束。这样的智能体离真正的自主工作还有距离因为它在跨会话场景中几乎没有记忆也不具备对失败过程的反思能力。下一波真正有价值的投入方向是给智能体加两类能力。一类是结构化记忆把用户偏好、任务历史、执行结果写入可查询的记忆库让智能体在多轮任务中保持上下文连续另一类是反思机制在一个任务执行失败后能分析失败原因并调整策略而不是直接报错。这两件事在工程上都很难但一旦做出来智能体就从“接口封装”变成了“能干活的数字员工”。4.2 推理成本下降之后的重排机会过去很多场景不用大模型是因为成本算不过来。比如每天要对几十万条工单做分类和摘要如果每条的推理消耗都很大账单会非常吓人。但是现在算法、工程、硬件三个方向都在压推理成本尤其是轻量化模型和投机采样的成熟让大批量、高吞吐的场景开始变得划算。这是下一阶段的机会窗口。建议团队在盘点业务时重点找那些“规则做不了、人工做太贵、频率非常高”的场景比如日志错误归纳、客服会话质检、销售线索清洗、政策文件比对。这些场景原来是被人工成本压住的推理成本下降后大模型就可以用“批量分析”的方式进入重新计算投入产出比。4.3 端侧与本地化带来新体验端侧大模型也是一个被低估的方向。手机、PC、边缘设备上直接跑小参数模型好处是响应快、隐私好、离线可用。新一代国产小模型在参数量压缩后依然保留了不错的语言理解和指令遵循能力能承担摘要、分类、改写、简单问答这些任务。我在实际测试里发现端侧模型配合云端模型做分级处理体验提升非常明显。简单请求在端侧直接完成几乎零延迟只有复杂请求才上云。这种混合架构带来的成本节省和用户体验改善比单纯追求单模型效果更有工程意义。对于做 App、智能硬件、办公软件的团队端侧模型值得认真纳入技术规划。5. 给想换挡的团队几条实操建议5.1 先做模型能力盘点再定技术选型选型前先不要急着对比各家模型的 API 价格。先把你自己业务里最核心的 5 到 10 个任务抽象出来做成一个覆盖准确率、格式合规性、延迟、成本、稳定性五个维度的评测集。评测集样本要从真实业务数据里抽样打上标准答案和预期路径然后让不同模型在同一套评测框架下跑。我团队现在的做法是每个新模型候选进来先跑一通标准评测再挑一个最接近业务真实场景的试用模型做 10 到 20 个回话的定性检查。评测数据归档随时可以回溯。这个过程并不复杂但能避免大量“拍脑袋选型、上线就后悔”的情况。5.2 用灰度口径把模型迭代变成常态化大模型迭代不能搞“一刀切切换”。新版本效果可能在某些维度更好在另一些维度回退。比较稳的做法是灰度策略把一定比例的线上流量导向新模型版本用预设指标对比新旧两版的差异。指标可以是回答采纳率、人工修正率、用户投诉量、任务完成率。连续观察一段时间新版本综合指标优于老版本再逐步放量。灰度机制不是技术上的高门槛难的是组织上的习惯。团队要接受“模型效果没有一劳永逸”把迭代当作软件开发一样常态化。只要这个机制跑顺了后续无论是换模型供应商还是升级自家模型都只是流水线上的一道工序。5.3 把评测资产和真实反馈闭环沉淀下来最后一条建议可能是最容易被忽视的把每一次项目积累下来的评测样本、错误样本、用户反馈、人工修正记录都沉淀成团队的数据资产。这些东西比模型本身更值钱。模型可以换底盘数据才是你判断效果、训练小模型、定位问题的根本依据。我到项目后期发现手里最值钱的东西不是某个模型的调用经验而是几个业务领域的高质量标注数据集和回归评测集。拿着这些资产任何新模型一出来我都能在很短时间内判断它适不适合这个业务没有这些资产就只能被供应商牵着走。所以从第一天开始就把数据资产的沉淀当作项目交付物的一部分而不是可有可无的副产品。说到底国产大模型这波浪潮能走多远不取决于哪个模型又刷了多高的分而是取决于我们这些做工程的人能不能把模型能力扎扎实实地落进业务流程里。模型是发动机评测、数据、链路和持续的迭代机制才是底盘。下一阶段的能动性一定藏在那些肯在底盘的细节上下苦功的团队手里。
