如何建设人人都能训的大模型技术氛围
在大模型算法快速迭代演进的背景下，业务研发人员负责工程、算法研究人员负责模型优化的协作模式，已经无法满足大模型产品快速创新、模型效果快速迭代的业务需求，业务团队需要建设自有的大模型优化能力。如何建设一个人人都能训大模型的技术氛围，已成为加速大模型业务落地、推动组织创新与发展的关键。 2025 年 4 月，在 InfoQ 举办的 QCon 全球软件开发大会（北京站） 上，科大讯飞消费者 BG 大数据研发部总监吕昕分享了“如何建设人人都能训的大模型技术氛围”，他从平台基础设施、大模型思维、协作文化 3 个角度，阐述如何建设“人人能用、人人会训”的大模型文化，有效提升组织效能，进而推动业务的持续成长。 预告：2026 年 QCon 全球软件开发大会（北京站）策划了「AI 时代的“超级团队”」专题，将探讨如何弥补人与 AI 的能力鸿沟，重构产品与技术的协作关系，并建立一套适应 AI 时代的全新管理与度量体系，打造高适应性、高产出的“超级团队”。如果你也有相关方向案例想要分享，欢迎提交。 以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。 大模型时代创新的必要性在于，无论是 C 端还是 B 端业务，直接使用大模型完成工作都存在困难，需要进行优化。每个业务线或单元都有必要自己训练大模型，我的分享一方面可以帮助小团队或业务线从 0 到 1 建设大模型训练能力，另一方面能让想转大模型的工程人员了解如何转型。 从业务优化需求来看，C 端业务场景零散但可划分到特定场景优化，业务线要求高且效果优化永无止境，核心是围绕用户场景建立数据和快速优化能力。B 端业务以解决方案为主，对效果要求相对有限，主要是满足国产化和安全要求，达到可用即可。 大模型优化模式与传统机器学习有所不同。传统机器学习中，算法需求由算法研究人员或团队主导，业务线研发主要负责部署上线和维护。而在大模型时代，特征工程基本不存在，但出现了两种新的合作模式：一种是以算法研究人员为主，业务线辅助定义需求、标数据等；另一种是以业务线为主导，算法人员辅助问题定义与选型、模型训练。DeepSeek 等技术的出现，使得业务线或产品线有可能自己优化大模型训练效果，不再依赖算法辅助。 从组织架构角度，各个业务线更希望业务线自己训练大模型。因为大模型技术发展迅速，战略需灵活调整，组织活力需进一步激活，以实现敏捷创新和更好的信息拉齐与穿透。传统的算法团队与工程团队分开的模式已不能满足业务发展需要，每个业务线或团队都需要具备从 0 到 1、端到端优化大模型的能力。 在大模型时代，DeepSeek 的出现既带来了危机也带来了机遇。它在基础模型方面表现出色，一些场景直接使用深度探索就能取得不错的效果。同时，开源生态的成熟，包括训练框架、推理框架和智能代理框架，降低了训练基础设施的建设成本。通过蒸馏深度探索，可以快速构建高质量数据，如思维链数据，节省了大量人工标注成本。此外，模型优化范式也在变革，从之前的底座模型训练和监督微调（SFT），转变为现在的知识蒸馏，并且广泛采用 GRPO 来优化效果。 业务线如果想自己从 0 到 1 建设大模型的优化能力，会面临诸多挑战。首先是基础设施的缺失，包括算法、算力、平台、数据，以及训练框架和推理框架。其次是缺乏算法优化经验，不清楚如何选择模型、技术方案，如何评估和优化效果。最后是人才短缺，不清楚需要什么样的人才、到哪里找以及需要掌握哪些技术栈。 在大模型时代，对研发岗位的要求也发生了变化。核心岗位包括大模型算法工程师和大模型测试工程师。大模型算法工程师相比传统搜索、广告、推荐算法工程师，门槛降低，需要调的参数少，但需要更好的业务感知能力，将业务需求转化为大模型优化场景，并具备创新思维和前沿跟进能力。大模型测试工程师相比传统测试工程师，需要更高的自动化测试要求，能够基于业务感知能力自动化构建大模型测试样本和制定测试标准。除了这两个核心岗位，还有其他岗位，如提示词工程师因天花板低和深度探索出现后需求减少而不再热门；大模型平台架构师、大模型平台开发工程师和大模型应用开发工程师这些岗位和传统软件开发岗位基本没有太大区别。 在研发和测试的协作方面，之前让团队野蛮发展，未重视项目管理，导致模型训练完成、上线前测试环节出现问题，训练样本与业务未对齐，浪费了大量时间。因此，我增加了样本评估环节，要求在训练前与业务线对齐样本，确保样本能满足业务需求。同时要求每次算法上线时提供详尽的自测报告和提示词文档，明确参数设置等细节，以避免因参数错误导致的测试问题，因为大模型训练结果是黑盒，测试时不易发现问题。 基于我对整个平台架构设计的理解，基本分为三层。最底层是基础设施，公有云可以解决 90%，甚至 100% 的问题。因为业务线的训练样本数和情况一般不支持训练 32B 以上的模型，32B 的全参训练是上限。此时租用几十张显卡基本能解决大部分训练问题，大部分业务场景 7B 模型也能搞定。所以公有云租卡基本能解决 90% 的训练和部署问题。在训练的第二层是训练工具。这里使用了公司内部已有的星火训练平台，同时也基于开源搭建了相关工具，开源生态的成熟对此帮助很大。再往上是大模型应用开发的三个工程：数据工程、模型工程和 Agent 工程，也可称为大模型的应用开发。核心需要自己扩建设的资源主要是数据资源和应用开发资源。数据资源方面，要掌握如何通过调用 API 构建样本，如何蒸馏 Deepseek，公有云的 API 基本能满足需求。应用开发方面，主要涉及 Agent 和 RAG。Agent 的开源项目众多，star 超过 1000 的都有 50 个左右，可以基于开源搭建自己的 Agent 和 RAG 平台。如果想低成本建设从 0 到 1 的基础设施，利用公司内部资源复用和拥抱开源，基本能解决所有问题。 有了基础设施后，简单介绍一下开源技术栈。之前没显卡时还考虑过 Qlora，但后来发现 32B 模型的 Lora 训练，16 张显卡基本都能搞定，没必要再用 Qlora。在模型选型上，简单模型用 7B、14B、32B 基本都能满足，复杂一点的长文本和复杂任务，32B 模型也能差不多应对。使用开源模型进行部署和训练基本没什么太大问题。 在数据管理平台方面，我看了所有开源项目并梳理了公司内部所有数据相关平台后，得出结论是必须由业务线自建，因为没有任何两个业务的数据管理需求是一样的。其核心有两点：一是 Badcase 驱动，Badcase 管理非常重要，我每次训练时核心任务是修复 Badcase；二是要进行模型样本管理，避免引入脏数据，出问题时能追溯模型来源，所以要建设模型溯源能力，而不仅仅是数据管理能力。 如何培养全员训练大模型的思维和能力，重点在于提升能力，尤其是让普通研发人员快速掌握大模型训练，建设他们的算法能力。大模型训练流程包括问题定义、提示词设计、样本构建、微调（蒸馏、强化学习）、评估和上线。模型优化能力由四个能力叠加而成：模型问题定义能力、样本构建能力、训练能力和评测能力。最初认为模型训练能力最难，但实际上最容易，一周内所有人都能学会调参，且调参不超过 3 个。研发团队最需要提升的是问题定义和评测能力。 我将自己最近半年工作中的教训和经验总结，把所有训练过的大模型场景做了拆分，发现大部分大模型场景都能映射到下表几个类别中。每次模型训练时，思考一下可以放到哪个类别，然后按照相应的优化方式去做，基本都能取得不错的效果。以写作类为例，这是最常用的大模型优化场景，现在 DeepSeek 效果较好，大家开始广泛使用。以前不敢碰写作类，因为需要构建样本，难度较大。但现在通过 DeepSeek 蒸馏和强化学习（GRPO），基本能取得较好的效果。要素抽取类场景中，公有云模型准确率能达到 90%，自身优化空间不大。问答类场景中，大模型能力很少单独训练，大家主要做 RAG 和搜索插件，因为底层工程化可以提升更多效果。还有 API 调用类场景，训练大模型时将其抽象到某个场景，再看每个场景的优化方式。无论是写作还是交互，最核心的是要有一套快速构建样本训练的链路能力，从业务驱动出发，快速构建样本训练，再快速进行评测和 Badcase 修复，以及与之相配合的平台能力。 大模型测试曾是我最不关心的环节，但后来发现它对模型优化迭代效率影响最大。首先，数据来源很重要。如果线上有 Badcase，建议直接使用 Badcase 作为优化数据。性能测试方面，大模型性能测试与普通性能测试存在差距，可能会考虑 GPU 并发等因素。但我认为，同样 Token 长度和 Size 模型性能差异不大，不要投入过多精力。最核心的是找一个测过的开源的数据源，拿来即用。效果测试很关键，就是理解模型效果并进行测试。我的感受是，合作的业务线中，是否有优秀的测试人员对最终模型效果影响很大。优秀的测试人员可以从业务需求出发，将业务标准和测试标准转化为测试用例，自动化生成样例，并用大模型自动评测。一个这样的测试人员对于团队能力的提升，相当于三个以上的大模型算法人员，而那些配合较差、反复优化效果不好的业务线，往往缺少这样的人。因此，我在公司内进行大模型测试能力评估，尽管自己做算法工作，但感觉没有优秀的测试人员，工作开展会很困难。 我最早做搜索时，用户输入多轮搜索结果，需要多轮改写来理解用户意图。之前使用传统方法和一些大模型，都无法很好地理解几轮对话之间的关系，上下文无关和上下文有关的内容都识别不出来。DeepSeek 出现后，发现其 R1 效果非常好，因为它有思维链，能思考上下文关系。于是尝试用 R1 做蒸馏，结果效果也很好。这个实验有几点结论：一是使用 DeepSeek 后，提示词简化了很多，这也是提示词工程师现在市场不大的原因；二是蒸馏时仍需要底座模型，像 1.5B 的底座模型较弱，学不到东西；三是思维链加入后，可以做一些以前做不到的事情。举个例子，用户在搜索中要求生成双色球下期中奖号码，以前在 Query 理解上做了很多尝试，但都无法解决。DeepSeek 给出的回复是“双色球号码不靠谱，远离赌博，珍爱生命”，这让我觉得自己之前的尝试很愚蠢。这个案例说明，当新技术如 DeepSeek 出现后，要勇于探索和尝试，会得到超出预期的惊喜，也能让团队成员感到开心。 写作场景以前是我不敢碰的，因为构建样本难度大。DeepSeek 出现后，针对政府公文写作场景，直接使用 DeepSeek，通过公文反推生成大纲，再基于大纲生成要素，然后进行写作。这个过程中有几点分享：一是 DeepSeek 可以帮助做样本构建，节省大量工作量，甚至可以做样本评测；二是用多轮改写的成功经验来训练和蒸馏 COT，发现写作类加 COT 后效果更差，说明之前的经验证到新技术面前可能需要更多实验来验证；三是写作类模型优化并非一次生成文章即可，大部分写作类模型优化是先生成大纲，再基于大纲写作，这样才能取得较好效果，即使使用 DeepSeek，直接一步生成的效果也不如两步走（先生成大纲再生成文章）的效果好；四是通过尝试新技术，即使之前在该领域没有积累，基于 DeepSeek 等最新开源成果，也能实现技术跨越，从原来 30 分的能力提升到 75 分。 在推动工程人员转向大模型工作时，会遇到一些疑虑。例如，一位有五六年的软件开发经验的同学对转向大模型工作非常抵触，他提出了两个疑虑：一是自己不会深度学习理论技术怎么办，我对此解释是大模型工作不需要这些，只要会搞样本、调参数、写 Python 代码就行；二是大模型优化与写代码差距太大，我展示了一个在 QCon 学到的关于工程师文化的图，就是李云老师在 2024 年 QCon 上海演讲分享的 《AI 时代团队管理的不变与变》 中的一张图，该图将工程师文化的关键项总结得很好，指出工程师的工程能力包括设计能力和工程能力两块，之前做工程开发可能是 30% 时间设计、70% 时间工程，而大模型优化可能是 80% 时间设计、20% 时间写代码，本质上仍是工程师工作，只是比例变化，底层活动也一样，都是设计、文档化、写代码以及敏捷开发等。 如果有人担心自己的效果比不上专业的研究团队，那是因为缺乏经验，存在知识壁垒和技术孤岛。解决方法是打破壁垒，通过开源和分享打破技术孤岛，大家团结起来共同成长。遇到问题时，可以找人问、开分享会、开会研讨。 我在做多轮搜索时，面临模型合并、样本合并问题，如果每个模型都单独训练，最后需要维护几百个模型，这是无法维护的，所以把相似数据放在一起同时训练，但这样导致准确率下降很多，当时不知所措，于是向研究院同学请教，对方建议把多轮与单轮的 promot 差异加大，尝试后发现有效；又向工程同学请教，对方说 VLLM 支持动态的 Lora 加载，每个模型训练一个 Lora，然后动态加载即可，这两种方式都能解决问题。 在写作场景中，出现前面写得正常，后面突然出不来标点符号的问题，当时甚至想用强化学习设置 Reward 来解决，但训练底座大模型写作的人说把 decay 的惩罚从 0.6 设到 0.1，尝试后发现可以解决。现在回看去年做的事，觉得当时犯了低级错误，但认为这不是黑历史，而是成长之路，想跟大家分享的是遇到问题找别人会得到帮助，能力是逐渐积累的。 我在公司负责一些工程师文化建设工作，梳理出工程师文化最核心的几点是技术过硬、专业靠谱和开放共享。在大模型时代，我个人最认同的是开放和乐于分享，整个团队、公司或组织需要有更开放共享的文化心态。 从组织氛围或组织变革角度看，训练大模型很简单，只要有平台、有业务 Sense 就能做起来。大模型基础平台可以低成本建设，有众多开源资源可复用。大模型场景就那几类，按流程优化就行。要拥抱开源，避免闭门造车。 最后是致敬：一是 QCon 上一位老师的分享，他讲的“优化算法最好的办法就是找 bug”这句话对我后续工作影响很大，认为在大模型时代，找 bug 和 review 数据比调参更有用；二是 Hugging Face，感谢它提供很多优秀的开源模型和数据，每个公司都需要有自己的类似 Hugging Face 的共享平台，用于模型数据、训练方法论和经验的共享，打造开放共享的团队氛围。 嘉宾介绍 吕昕，负责科大讯飞消费者 BG 大数据和大模型技术平台相关工作，先后负责建设了讯飞 C 端用户数据中台、大数据分析平台和大模型应用开发平台等，目前负责多个 C 端产品的大模型效果优化工作。 在大数据平台、个性化推荐、广告算法、商业分析、大模型算法领域有多年经验。 会议推荐 从基础设施、推理与知识体系，到研发与交付流程，再到前端、客户端与应用体验——AI 正在以更工程化的方式进入软件生产。2026 年 QCon 全球软件开发大会（北京站）将以 「Agentic AI 时代的软件工程重塑」 作为大会核心主线，把讨论从 「AI For What」，走向真正可持续的 「Value From AI」。大模型时代组织创新的必要性
大模型算法优化的几种模式
大模型吋代的 BLM 模型
从 0 到 1 自建大模型优化能力面临的问题
大模型效果优化团队的协作与流程
建设人人能训大模型的基础设施
大模型优化平台的建设
开源模型的技术选型
数据管理平台
培养全员大模型思维与能力
大模型的应用场景和优化方式
大模型测试
大模型优化案例 1 一多轮改写
大模型优化案例 2 一公文写作
构建开放共享的协作文化
一些解决遇到的大模型优化问题的经验
工程师文化建设
总结与展望
展开列表
