百度应用模型研发部：垂直领域专精模型落地之路

一、事件回顾：一次指向“应用深耕”的组织升级

2025年11月25日，百度宣布设立应用模型研发部（AMU），由贾磊负责，直接向百度CEO李彦宏汇报。与聚焦基础模型预训练的团队不同，这个新部门的定位非常清晰：面向业务应用场景所需的专精模型开展调优与探索，重点推动模型在金融、医疗、教育等垂直领域的落地。

对行业观察者而言，这一动作至少传递出两层信号。第一，大模型竞争的重心正在从“拼通用能力”转向“拼场景价值”：基础模型解决的是“能不能用”，而垂直专精模型解决的是“好不好用、敢不敢用”，后者才是商业价值兑现的关键环节。第二，应用模型研发部直接向CEO汇报，说明领域模型研发被放在了战略层级。专精模型的研发涉及数据、算力、标注、业务、合规等多环节协同，若缺乏高优先级的组织保障，很容易陷入“模型团队闭门造车、业务团队隔岸观火”的协作困局。

二、为什么通用大模型不够用：垂直场景的四道鸿沟

既然基础模型通用能力已经很强，为何还需要专精模型？从工程实践看，垂直场景与通用场景之间存在四道明显鸿沟。

1. 知识密度与时效性鸿沟。金融行情、诊疗规范、教材大纲等领域知识既高度专业化又快速更新。通用模型的知识来自大规模通用语料，长尾专业知识覆盖稀疏，且受训练截止时间影响存在时效性问题。

2. 错误代价鸿沟。闲聊场景的一处幻觉无伤大雅，但在金融报告中算错一个数字、在医疗建议中混淆两种禁忌，都可能造成实质性损失。垂直场景对事实一致性与数值准确性的要求近乎“零容忍”。

3. 表达口径鸿沟。每个行业都有自身的术语体系、报告格式与合规措辞。模型输出不仅要“对”，还要“像”，符合行业文书规范、能通过合规审校。

4. 任务形态鸿沟。垂直业务往往不是单轮问答，而是“检索—生成—校验—审校”的多环节流程，涉及结构化输出、多轮交互与人机协同，对模型可控性与工程化能力要求更高。

专精模型的价值，正是通过针对性的数据、训练与系统设计，逐一对齐这四道鸿沟。

三、应用模型研发的核心技术路径

3.1 数据工程：专精能力的第一性来源

模型能力的上限往往由数据决定，领域模型的数据工程通常包含四步：

• 语料采集与清洗：从行业文献、业务文档、专家问答等渠道收集语料，进行去重、脱敏与质量过滤，尤其要处理医疗、金融数据中的隐私信息；
• 术语与知识归一化：统一专业术语表述，构建领域词表，避免同一概念多种写法引入学习噪声；
• 指令数据构造：将真实业务任务改写为高质量“指令—回答”对，辅以专家标注与交叉校验。示意格式如下（JSONL为通用数据格式）：

{“instruction”: “基于给定背景资料回答问题，资料不足时须明确说明”, “input”: “背景：……\n问题：……”, “output”: “……（需标注依据来源）”}

• 数据配比实验：通用数据与领域数据按不同比例混合训练，在领域能力提升与通用能力保持之间取得平衡。

3.2 训练策略：在“专”与“全”之间寻找平衡

常见路径是“继续预训练 + 监督微调 + 偏好对齐”的分层组合：继续预训练让模型吸收领域语料的底层知识，监督微调对齐业务任务形态，偏好对齐注入领域专家的判断标准与安全红线。在算力受限场景下，参数高效微调（如低秩适配类技术）可在冻结主干参数的前提下，以远低于全量微调的成本逼近其效果。

必须警惕的坑是灾难性遗忘：过度聚焦领域数据可能损伤通用能力。工程上通常采用“领域数据 + 通用数据回放”的混合策略，并以通用能力评测集作为护栏指标加以缓解。

3.3 知识增强：让模型“外挂”最新领域知识

对时效性强的场景，把知识全部“写进参数”并不经济。主流做法是检索增强生成（RAG）：将最新领域文档、规则库放入向量检索系统，推理时先检索相关资料，再让模型基于资料作答。这样既保证知识可随业务更新，又能让答案附带出处、便于人工核查。此外，模型还可与计算引擎、规则引擎、结构化数据库等通用系统组件协同，将“模型擅长语言理解”与“系统擅长精确计算”的优势组合起来。

3.4 评测体系：让“专精”变得可度量

没有评测就没有优化。领域模型评测通常分三层，可用如下示意流程概括（伪代码）：

for case in domain_benchmark + business_cases:
pred = model.generate(case.prompt, temperature=0.1)
s_fact = fact_check(pred, case.references) # 事实一致性
s_form = format_check(pred, case.schema) # 输出口径与结构
s_safe = compliance_check(pred) # 合规与安全红线
if s_fact < THRESHOLD or s_safe == “FAIL”:
route_to_human_review(pred, case) # 转人工审校

第一层是领域基准集，覆盖典型专业任务；第二层是业务真实任务集，来自线上流量采样；第三层是上线后的持续监控，包括幻觉率、拒答率、合规命中率与人工复审率等指标。评测结果反向驱动数据补充与训练迭代，形成闭环。

四、三大垂直领域的落地要点

金融场景：核心挑战是数值敏感、时效敏感与合规敏感。行情、利率、监管规则频繁变化，模型须与实时数据源协同，输出需附带数据出处与风险提示，并嵌入“生成—校验—审校”流水线，确保关键数字可追溯。

医疗场景：核心挑战是术语体系庞大、错误代价极高且监管严格。实践共识是：模型定位为专业人员的辅助工具而非替代者，输出需引用权威来源，关键结论必须经专业人员复核，数据全流程脱敏以满足隐私保护要求。

教育场景：核心挑战是个性化与教育规律的平衡。好的教学不是直接给答案，而是分步启发、因材施教。模型需围绕知识点与学情数据做难度自适应，保证内容的准确性与价值导向，并与教师工作流深度集成。

五、组织启示：企业如何构建自己的应用模型团队

AMU的设立方式本身也值得企业借鉴。一个高效的应用模型团队通常需要四类角色：领域专家（定义“什么是对的”）、数据工程师（供给高质量燃料）、模型研发工程师（训练与调优）、评测与合规人员（守住质量与红线）。同时应与业务部门建立双向闭环：需求从业务真实痛点中来，效果回到业务指标上去验证。直接向最高决策层汇报的组织设计，本质上是为这种跨部门闭环提供优先级保障。

六、开发者行动清单

对希望构建领域模型能力的开发者，建议遵循四步节奏：第一步，用真实业务数据建立评测基线，弄清通用模型究竟差在哪；第二步，优先尝试检索增强，成本低于微调且见效快；第三步，针对评测暴露的能力缺口做定向微调；第四步，将线上反馈回流为训练数据，形成持续迭代的数据飞轮。全程谨记两条铁律：没有评测不要谈优化，没有合规审校不要直接面向用户。

结语

从通用到专精，是大模型产业走向成熟的必然路径。应用模型研发部的设立，可视为“模型即应用”时代的一个组织注脚：当基础能力趋于同质化，真正的竞争力藏在行业经验、数据工程与评测体系这些“慢功夫”里。对开发者而言，与其追逐参数规模，不如沉心打磨所在领域的专精能力，这才是垂直落地时代的核心竞争力。