标签 GRPO 下的文章

你是否刷到过这样的短视频广告：如何在家躺着日赚几百块”、“通过手相预测未来姻缘”。在快手商业化广告素材审核过程中，快手商业化生态与体验团队每天也会拦截大量的风险素材。这些内容轻则破坏用户体验、损伤商业化生态，重则触及底线问题、危害整个商业化业务。团队的任务是通过技术手段将下述这些不同的风险都识别出来并拦截。
图片
图 1 风险素材案例

与传统的显性风险不同，商业广告的违规往往隐藏在跨模态的错位中——画面合规但口播违规、字幕合规但暗示性极强。这类“高风险、强对抗”的内容，对审核系统提出了极高的要求：不仅要判得准（准确性），还要说得清（可解释性），更要跟得上政策的快速迭代（政策对齐）。面对这一挑战，传统的“黑盒”判别模型或通用多模态大模型（VLM）往往力不从心：前者缺乏因果推理能力，后者难以适应细粒度的商业审核策略。

为解决这一痛点，快手商业生态与体验算法团队提出了 BLM-Guard，这是一个专为高风险短视频广告设计的可解释性多模态审核框架。该框架融合了多模态思维链（CoT）推理与策略对齐的强化学习（RL），通过模拟人类审核员的“观察-归因-判断”逻辑，提升了模型在商业化场景下的审核精度与推理一致性。

本研究相关成果《BLM-Guard: Explainable Multimodal Ad Moderation with Chain-of-Thought and Policy-Aligned Rewards》已被人工智能顶级会议 AAAI 2026（Main Track） 接收。
图片
图 2 BLM-Guard 两阶段训练框架示意图

核心亮点：

  • 【像审核员一样思考】 针对短视频广告违规隐蔽性强的问题，本文提出 ICoT（Interleaved-modal Chain-of-Thought） 流水线。通过规则驱动的数据合成，生成包含“视觉定位-风险筛查-因果分析-最终判决”的结构化推理链，解决模型“只知其一不知其二”的黑盒问题。
  • 【动态策略自适应】 面对不断变化的审核规则，创新性提出 SCA-R（Self-Adaptive Critique Reward） 奖励机制。基于动态原则对模型的推理过程进行打分，结合 GRPO 强化学习算法，确保模型在策略漂移下仍能保持高一致性。
  • 【首个多模态广告风控基准】 发布了 BLM-Guard Benchmark，这是业界首个包含三级风险分类体系（风险场景、违规类型、严重程度）的短视频广告数据集，涵盖非法内容、虚假营销、误导性操作等七大核心场景，填补了精细化广告审核评测的空白。

一、研究背景

随着短视频商业化深入，广告已成为平台核心支柱，但违规内容日益呈现“隐蔽化、协同化、对抗化”趋势。这种高风险、强对抗的业态对现有的审核体系提出了严峻挑战，主要体现在以下三个维度：

  1. 违规形态演变多模态协同欺骗生成式 AI 的普及使得违规手段从单一的显性违规（如敏感词、违规画面）升级为“多模态协同欺骗”。这类内容通常单模态看似合规，但通过跨模态的信息错位（如画面正常但口播违规）传递恶意意图，极大地增加了识别难度。
  2. 审核标准困境动态性与复杂性的多重矛盾商业广告审核面临政策、场景与风险的三重复杂性：
  • 政策漂移与规则适配： 法规（如《广告法》）与平台规范的动态更新，导致静态模型难以适应不断漂移的政策边界。
  • 场景差异与通用性： 医疗、金融、教育等不同行业审核逻辑迥异，通用模型难以兼顾细粒度的领域规则。
  • 风险分层与二元判决： 现有模型多为“通过/拦截”的二元判决，无法区分高风险（非法）、中风险（误导）与低风险（体验）内容，难以满足精细化运营需求。
  1. 行业落地诉求从“黑盒”到全链路可解释审核不仅是技术判别，更需服务于平台监管、商家整改与合规追溯的全链路。传统规则模型泛化差，通用大模型（VLM）虽有理解力但决策过程如“黑盒”，缺乏结构化的归因逻辑。商家无法获知具体违规点，监管难以追溯证据链，且行业缺乏针对多模态协同违规的高质量数据集。 

面对上述“违规识别难、规则适配难、结果落地难”的困境，本研究提出 BLM-Guard 框架。通过引入模拟人类审核逻辑的“多模态思维链（CoT）”与策略对齐的强化学习（RL），旨在实现对隐蔽违规的精准识别与动态政策适配，并构建业界首个精细化多模态广告风控基准，为短视频商业生态的安全与可持续发展提供技术支撑。

二、技术方案

BLM-Guard 采用了一种渐进式的“两阶段”训练范式，分别是第一阶段中规则锚定的 ICoT 冷启动（Rule-Anchored SFT）和第二阶段中基于 SCA-R 的强化学习（Self-Consistency RL），确保模型既能学到规则，又能灵活应用。

2.1 第一阶段：规则锚定的 ICoT 冷启动

这一阶段的目标不是简单地微调 VLM，而是解决“黑盒模型无法理解细粒度商业规则”的问题。

2.1.1 数据构造——自适应关键帧与 ICoT 生成

为了让模型“看懂”违规细节，采用了一套新的提取流程 ：

  1. 自适应关键帧采样 (AKS):
  • CLIP 相似度筛选： 计算每一帧图像嵌入\( v_i \)与预定义风险提示词（如"false marketing", "illegal content"）嵌入\( t_k \)的余弦相似度\( si​=maxk​(viT​tk​)  \)。
  • BIN+TOP 策略： 将视频划分为m个时间桶（BIN）选局部最优，若不足则补充全局最高分帧，确保既有时间覆盖又有语义显著性 。
  1. Patch 级区域定位： 使用 InternViT-6B 提取 Patch 特征，计算 L2 范数作为显著性分数 \( score_{i,p}=||H_{i}^{(p)}||_{2} \)，定位出关键图像区域（如字幕、产品特写） 。
  2. ICoT（交错模态思维链）生成：利用冻结的 InternVL-3-78B 作为教师模型，生成结构化的推理链：
    图片

2.1.2 训练目标——引入规则先验

在 SFT 阶段，BLM-Guard 修改了标准的 Cross-Entropy 损失，加入了 KL 散度约束 ：
图片

  • \( \mathcal{L}_{CE} \) ：保证最终判罚（Answer）的准确性 。
  • \( KL(p_{think} || p_{rule}) \)： 这是一个关键设计。\( p_{rule} \)是基于违规场景关键词构建的软分布。该项强制模型的<think>推理过程中的 token 分布向这些规则关键词靠拢，防止模型推理“跑偏”或产生幻觉 。

2.2 第二阶段：基于 SCA-R 的强化学习

SFT 模型虽然具备了初步推理能力，但在面对由于政策快速迭代导致的“策略漂移”时，泛化性不足。该阶段引入了 GRPO（Group-wise Relative Policy Optimization）算法进行优化。其中，混合奖励函数设计如下：为了平衡准确性、格式规范和逻辑一致性，奖励函数由三部分组成 ：
图片

  • \( r_{rule} \)（规则正确性): 离散奖励。如果场景和违规类型全对给 1.0，仅场景对给 0.5，否则为 0 。
  • \( r_{format} \)（结构约束)：强约束奖励，确保输出严格包含<think>和<answer>标签，便于后续解析 。
  • \( r_{scaR} \)（SCA-R: 自适应批判奖励):
  1. 动态 Critique: 引入一个 Guide Model（ GPT-4o），它不依赖静态标签，而是   根据当前的审核 Policy 和输入，动态构建评分原则\( r_{scaR} \)。
  2. 评分逻辑: Critic 针对推理链进行打分（0, 0.5, 1），计算加权和\( r_{scaR} \)。这解决了“判决对了但理由错了”的逻辑一致性问题。

2.3 总结

从技术架构角度看，BLM-Guard 的核心壁垒在于：

  • 显式因果建模： 通过 KL散度将规则“注入”到模型的隐空间推理路径中。
  • 抗策略漂移：利用 \( r_{scaR} \)动态奖励，使得模型不仅拟合数据分布，更是在拟合“审核逻辑”，从而适应不断变化的业务规则。

三、效果性能

3.1 核心指标

在构建的 BLM-Guard Benchmark 以及 UCF 等五个公开数据集上，BLM-Guard 均展现了 SOTA（State-of-the-Art）性能。

  1. 准确率提升：相比 Qwen2.5-VL、InternVL3-8B 等强力基线，BLM-Guard 在七大风险场景下的严格准确率（Strict Accuracy） 平均提升超过 20%，尤其在“虚假营销”和“误导性操作”等高难度场景表现突出。
  2. 推理一致性：通过 GPT-4o 进行的一致性评分显示，BLM-Guard 的推理逻辑得分达 0.845，超基线模型的 0.5-0.6 水平。这意味着模型不仅判得对，而且理由充分、逻辑自洽。
    图片
    图 3 BLM-Guard Benchmark 风险分类体系
    图片

3.2 消融实验

实验证明，“规则微调（Rule-SFT）+ SCA-R 强化学习” 的组合是性能提升的关键。仅依靠 SFT，模型容易产生幻觉；而加入 SCA-R 后，模型学会了在不确定时更加谨慎，提升了模型的泛化效果。
图片

四、未来展望

快手商业生态与体验研发中心始终致力于用技术守护快手广告的清朗。
未来，团队将继续深耕以下方向：
1.理解+生成 OneModel：探索理解+生成深度融合的 oneModel 新范式，进一步精准识别违规内容，同时引入营销视角生成高转化、有吸引力的修复建议，提升商家体验；
2.风控大模型基座 KwaiBLM：自主研发 KwaiBLM 风控大模型基座，作为风控领域的统一认知底座，支撑内容理解、风险识别、策略生成等多项核心能力，推动风控从经验驱动向数据智能驱动转型；
3.RiskAgent 智能体：构建多 Agent 协作的智能体系统，建设下一代人机协同的智能风控引擎 RiskMatrix，提升业务场景风险防控效率与防控效果；
4.Deepfake 攻防能力：针对 AI 生成内容带来的新型风险，构建 Deepfake 检测与对抗技术体系。通过多模态特征融合、内容理解等技术手段，提升识别 AI 生成的虚假素材、篡改内容、合成视频等，守护平台内容真实性；
5.动态图算法：探索融合图神经网络与 Attention 机制，将 Graph RAG 图表征能力与大模型 KwaiBLM 相结合提升识别能力，挖掘隐蔽关联风险。

一、推理模型⾯临的新挑战

随着 OpenAI o1 、 DeepSeek-R1 等大型推理模型（LRMs）的问世， AI 推理能力迎来了「测试时扩展」的新阶段。这些模型通过长链思维（Long Chain-of-Thought, CoT）在数学推理、代码生成、智能体任务等领域展现出强大能力。

然而，现有评测体系存在一个关键盲区：主流基准测试（如 MATH500 、AIME）主要关注独立的单一问题，每个问题相互隔离，模型只需「—问—答」即可。

但现实应用场景往往大相径庭：

  • 软件开发中需要连续处理多个关联代码模块
  • 数学证明需要基于前序推导逐步构建后续结论
  • 智能助手往往需要在多轮交互逐步完成复杂任务

这些真实场景要求模型具备跨任务的长链推理能力——不仅要解决单个子问题，更要在多个关联任务间保持推理—致性、合理分配计算资源、实现跨步骤的反思与纠错。

核心问题：当前大型推理模型的长链推理能力边界到底在哪里？

由于现有评测无法回答这—问题，传统训练数据也难以培养这种能力（如图所示，模型在长程推理场景下表现明显退化）。

图 1：R1  系列模型在长程推理场景下的理论准确率与实际准确率对比

复旦大学与美团 LongCat 联合推出 R-HORIZON——首个系统性评估与增强 LRMs 长链推理能力的评测框架与训练方法。

二、方法论：Query Composition 范式

核心创新

R-HORIZON 提出了问题组合（Query Composition）方法，通过构建问题间的依赖关系，将孤立任务转化为复杂的多步骤推理链。

以数学任务为例，该方法包含三个步骤：

1. 信息提取：从独立问题中提取核心数值、变量等关键信息
2. 依赖构建：将前序问题的答案嵌入到后续问题的条件中
3. 链式推理：模型必须顺序解决所有子问题才能获得最终答案

方法优势

  • 灵活扩展：可自由控制推理链长度（n = 2, 4, 8…）
  • 精确可控：可灵活设定问题间的依赖强度
  • 高效低成本：基于现有数据集构建，无需额外人工标注

基于此方法，我们构建了 R-HORIZON Benchmark 用于系统性评估 LRMs 的多步推理能力，同时生成了长链推理训练数据，通过强化学习（RLVR）提升模型性能。

图 2：R-HORIZON 方法流程——从单 — 问题到复杂推理链的转化及应用场景

三、评测基准：R-HORIZON Benchmark

数据集构成

基于 Query Composition 方法，我们构建了涵盖 6 个代表性数据集的 R-HORIZON Benchmark：

评测发现：性能断崖现象

我们评测了 20+ 个主流 LRMs（包括 o4-mini 、Claude-Sonnet-4 、 DeepSeek-R1 等顶级商业模型及开源模型），揭示了—个重要现象。

顶级推理模型在长链推理场景下均出现显著性能下降！

主要发现：

  • 普遍性能退化：所有模型随问题数量增加均出现明显性能下降。DeepSeek-R1 在 AIME25 单问题场景准确率达 87.3%，但在 5 个组合问题场景下骤降至 24.6%。
  • 规模效应：更大规模的模型对多步推理挑战表现出更强的鲁棒性。
  • 任务差异：代码生成任务相比数学任务表现出更陡峭的性能衰退；多数推理模型在网页搜索场景中丧失工具调用能力。

图 3：R-HORIZON Benchmark  评测结果—— 所有模型均出现显著性能衰退

四、机制分析：推理模型的三大瓶颈

为深入理解性能断崖的成因，我们进行了系统的机制分析，识别出当前 LRMs 的三个关键瓶颈：

瓶颈 1：有效推理长度受限

随着相互依赖问题数量增加，LRMs 难以维持原有性能水平。实际准确率与理论准确率之间的差距显著扩大。

深入分析显示：

  • 模型错误集中在特定上下文范围内
  • 7B 模型的主要错误范围在 (4-6K tokens)
  • 32B 模型将范围扩展到 (8-10K tokens)
  • 更大模型具有更长的有效推理边界

图 4：R1-Qwen-7B 和 R1-Qwen-32B  的准确率及错误位置分析

瓶颈 2： 反思机制高度局部化

对模型「反思」行为的分析发现发现：

  • 模型反思频率随问题数量增加而上升并趋于收敛。
  • 超过半数复杂任务 完全缺乏 长程反思 （跨越当前问题的反思）。
  • 当前 LRMs 的反思机制 高度局部化，无法支撑长链场景需求。

图 5：MATH500  数据集上的反思行为分析

瓶颈 3：思考预算分配失衡

最令人意外的发现：包括 DeepSeek-R1 在内的主流 LRMs 无法有效分配思考预算！

  • 模型倾向于过度分配 tokens 给早期推理阶段
  • 未能合理分配资源给后续关键问题
  • 这种失衡严重影响整体推理链的完成质量

图 6：不同组合问题数量下各模型的思考预算分配

五、 训练方案：突破能力边界

发现瓶颈后，我们进—步探索：能否通过长链数据的强化学习训练突破这些限制？

训练策略

我们基于 R-HORIZON 构建的长链推理数据，采用 GRPO 算法进行训练：

  • 算法：主流 RLVR 算法 GRPO
  • 数据： R-HORIZON 组合数据（n = 2, n = 4）
  • 实验：不同奖励函数的对比实验

训练效果：双重性能提升

实验结果显示：R-HORIZON 训练不仅显著提升长链任务表现，单问题性能也大幅增强！

核心数据

注：加粗数字表示该列最佳成绩

图 7：不同训练配置下的性能对比

关键发现

  1. 双重提升：使用 n = 2 组合问题训练，多步推理性能大幅提升（AIME24 n = 2 +17.4 分），单问题性能也显著增强（AIME24 单题 +7.5 分）。
  2. 可扩展性：增加组合复杂度（n = 4）增强了模型处理更多推理步骤问题的能力，在 MATH500 (n = 8) 上达到 50.6%。

训练带来的质变

R-HORIZON 训练带来了推理机制的深层改变：

  • 更高效的推理长度：显著改善组合任务性能，更好地泛化到更长推理链，同时缓解「overthinking」现象
  • 更合理的预算分配：学会在多步问题中进行更合理的 token 预算分配
  • 更长程的反思能力：促进了长程反思频率增加，直接改善长链推理性能

图 8：使用标准数据集和组合数据集进行强化学习的效果分析

六、结论与展望

R-HORIZON 标志着大型推理模型研究的范式转变——从「能解决什么问题」到「能走多远」。

技术贡献

  • 首个长链推理评测基准：系统性揭示 LRMs 的能力边界及三大瓶颈。
  • 可扩展训练范式：提供低成本、高效率的能力提升路径。
  • 深度机制分析：为未来推理模型改进指明方向。

在大模型算法快速迭代演进的背景下，业务研发人员负责工程、算法研究人员负责模型优化的协作模式，已经无法满足大模型产品快速创新、模型效果快速迭代的业务需求，业务团队需要建设自有的大模型优化能力。如何建设一个人人都能训大模型的技术氛围，已成为加速大模型业务落地、推动组织创新与发展的关键。

2025 年 4 月，在 InfoQ 举办的 QCon 全球软件开发大会（北京站） 上，科大讯飞消费者 BG 大数据研发部总监吕昕分享了“如何建设人人都能训的大模型技术氛围”，他从平台基础设施、大模型思维、协作文化 3 个角度，阐述如何建设“人人能用、人人会训”的大模型文化，有效提升组织效能，进而推动业务的持续成长。

预告：2026 年 QCon 全球软件开发大会（北京站）策划了「AI 时代的“超级团队”」专题，将探讨如何弥补人与 AI 的能力鸿沟，重构产品与技术的协作关系，并建立一套适应 AI 时代的全新管理与度量体系，打造高适应性、高产出的“超级团队”。如果你也有相关方向案例想要分享，欢迎提交。

以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。

大模型时代组织创新的必要性

大模型时代创新的必要性在于，无论是 C 端还是 B 端业务，直接使用大模型完成工作都存在困难，需要进行优化。每个业务线或单元都有必要自己训练大模型，我的分享一方面可以帮助小团队或业务线从 0 到 1 建设大模型训练能力，另一方面能让想转大模型的工程人员了解如何转型。

大模型算法优化的几种模式

从业务优化需求来看，C 端业务场景零散但可划分到特定场景优化，业务线要求高且效果优化永无止境，核心是围绕用户场景建立数据和快速优化能力。B 端业务以解决方案为主，对效果要求相对有限，主要是满足国产化和安全要求，达到可用即可。

大模型优化模式与传统机器学习有所不同。传统机器学习中，算法需求由算法研究人员或团队主导，业务线研发主要负责部署上线和维护。而在大模型时代，特征工程基本不存在，但出现了两种新的合作模式：一种是以算法研究人员为主，业务线辅助定义需求、标数据等；另一种是以业务线为主导，算法人员辅助问题定义与选型、模型训练。DeepSeek 等技术的出现，使得业务线或产品线有可能自己优化大模型训练效果，不再依赖算法辅助。

大模型吋代的 BLM 模型

从组织架构角度，各个业务线更希望业务线自己训练大模型。因为大模型技术发展迅速，战略需灵活调整，组织活力需进一步激活，以实现敏捷创新和更好的信息拉齐与穿透。传统的算法团队与工程团队分开的模式已不能满足业务发展需要，每个业务线或团队都需要具备从 0 到 1、端到端优化大模型的能力。

在大模型时代，DeepSeek 的出现既带来了危机也带来了机遇。它在基础模型方面表现出色，一些场景直接使用深度探索就能取得不错的效果。同时，开源生态的成熟，包括训练框架、推理框架和智能代理框架，降低了训练基础设施的建设成本。通过蒸馏深度探索，可以快速构建高质量数据，如思维链数据，节省了大量人工标注成本。此外，模型优化范式也在变革，从之前的底座模型训练和监督微调（SFT），转变为现在的知识蒸馏，并且广泛采用 GRPO 来优化效果。

从 0 到 1 自建大模型优化能力面临的问题

业务线如果想自己从 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 模型性能差异不大，不要投入过多精力。最核心的是找一个测过的开源的数据源，拿来即用。效果测试很关键，就是理解模型效果并进行测试。我的感受是，合作的业务线中，是否有优秀的测试人员对最终模型效果影响很大。优秀的测试人员可以从业务需求出发，将业务标准和测试标准转化为测试用例，自动化生成样例，并用大模型自动评测。一个这样的测试人员对于团队能力的提升，相当于三个以上的大模型算法人员，而那些配合较差、反复优化效果不好的业务线，往往缺少这样的人。因此，我在公司内进行大模型测试能力评估，尽管自己做算法工作，但感觉没有优秀的测试人员，工作开展会很困难。

大模型优化案例 1 一多轮改写

我最早做搜索时，用户输入多轮搜索结果，需要多轮改写来理解用户意图。之前使用传统方法和一些大模型，都无法很好地理解几轮对话之间的关系，上下文无关和上下文有关的内容都识别不出来。DeepSeek 出现后，发现其 R1 效果非常好，因为它有思维链，能思考上下文关系。于是尝试用 R1 做蒸馏，结果效果也很好。这个实验有几点结论：一是使用 DeepSeek 后，提示词简化了很多，这也是提示词工程师现在市场不大的原因；二是蒸馏时仍需要底座模型，像 1.5B 的底座模型较弱，学不到东西；三是思维链加入后，可以做一些以前做不到的事情。举个例子，用户在搜索中要求生成双色球下期中奖号码，以前在 Query 理解上做了很多尝试，但都无法解决。DeepSeek 给出的回复是“双色球号码不靠谱，远离赌博，珍爱生命”，这让我觉得自己之前的尝试很愚蠢。这个案例说明，当新技术如 DeepSeek 出现后，要勇于探索和尝试，会得到超出预期的惊喜，也能让团队成员感到开心。

大模型优化案例 2 一公文写作

写作场景以前是我不敢碰的，因为构建样本难度大。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」。