垂类大模型从通用模型到业务落地通常要经历哪些训练和迭代步骤？｜美团产品面经解析

60 秒回答模板

我会把垂类大模型的落地理解成先定义业务任务，再用数据和评测不断压缩模型的不确定性。第一步不是训练，而是明确场景：服务谁、解决什么任务、输出什么格式、容错率是多少，比如客服问答、商家运营助手、履约调度分析，对准确性、时效性和可解释性的要求完全不同。第二步是做领域数据，包括业务知识文档、历史工单、用户对话、专家标注、接口结果、规则库等，然后进行脱敏、去重、清洗、切分、标注和质量分层。第三步是选技术路径：通用基座模型负责通用语言能力，SFT 学习业务标准回答和任务格式，LoRA/QLoRA 降低微调成本，DPO 等偏好优化让模型更符合业务偏好，RAG 适合高频变化、强事实性知识，工具调用适合实时状态和动作执行。第四步是评测和 badcase 迭代，建立离线评测集、人工评审标准和线上指标，包括准确率、召回率、幻觉率、拒答率、解决率、转人工率、延迟、成本和满意度。上线后通过灰度、日志采样和 badcase 归因，决定下一轮是补数据、调 RAG、改 prompt、继续 SFT/DPO，还是加规则或人工兜底。

考点 先讲任务边界

难度 真实面经题

回答目标 让面试官感受到你理解垂类大模型落地是一套产品、数据、算法和工程协同的迭代系统，而不是一次模型训练任务。

深入解析

先定义场景和任务边界

垂类训练的起点是产品问题，而不是模型参数。要先明确目标用户、业务流程、输入输出、成功标准和失败成本。例如餐饮商家经营诊断需要结构化建议和可解释依据，客服机器人需要稳定解决率和低误导率，内部运营助手则可能更看重检索覆盖和生成效率。任务越开放、上下文越复杂，越需要大模型能力；任务越标准化，可能规则、RAG 或小模型就足够。

领域数据建设决定上限

垂类模型的核心资产是领域数据，包括业务文档、FAQ、历史对话、专家 SOP、订单履约记录、商家知识、人工质检结果等。数据处理要覆盖脱敏、去重、清洗、切分、标注、难例挖掘和版本管理。产品经理要关注数据是否代表真实流量，是否覆盖高频和高价值问题，是否包含反例和边界条件，否则模型容易在演示场景表现很好，线上遇到真实长尾问题就失败。

训练、RAG 和工具调用要分工

基座模型提供通用理解和生成能力，SFT 让模型学习垂类任务格式和标准示范，LoRA 降低微调成本，DPO 等偏好优化让模型更符合业务评价标准。RAG 更适合频繁变化、强事实性和可追溯知识，工具调用适合查订单、查库存、算价格、执行动作。成熟方案往往是模型理解和生成、RAG 补知识、工具拿实时数据、规则守安全边界的组合，而不是把所有内容都塞进训练。

上线后靠评测和反馈闭环迭代

垂类模型上线不是终点，而是新一轮数据生产的开始。需要通过离线评测集、红队测试、灰度实验、线上日志和人工质检持续发现 badcase。每个 badcase 都要归因：是知识库没覆盖、召回错误、模型幻觉、提示词不清、训练样本偏差，还是业务规则缺失。不同原因对应不同修复手段，避免用继续训练掩盖产品流程或数据体系的问题。

易错点

把垂类大模型训练说成拿行业数据微调一下，忽略业务边界、数据治理和上线闭环。
把本题答成产品经理个人工作分工，漏掉领域数据、训练适配、评测和反馈迭代主线。
把实时知识、价格库存等内容训进模型，导致更新困难和事实错误。
只讲 SFT，不讲 RAG、工具调用、规则和人工兜底的分工。
没有评测集和 badcase 机制，无法证明效果提升，也无法发现新退化。
只关注准确率，不关注延迟、成本、合规和用户体验。

面试官追问

如果业务知识经常变化，还适合微调吗？

不适合把高频变化的事实知识主要靠微调解决。价格、库存、活动规则、配送范围、商家状态等应该通过 RAG、数据库查询或工具调用获取。微调更适合稳定的任务范式、表达风格、决策逻辑和输出格式。

如何判断一轮训练是否有效？

不能只看几个演示样例，要看固定评测集和线上灰度指标。离线看准确性、幻觉率、格式合规率、拒答率、复杂问题通过率；线上看解决率、转人工率、用户满意度、投诉率、延迟和单次调用成本。同时要做 badcase 对比，确认旧问题是否修复、新问题是否引入。

垂类模型一定要自己训练吗？

不一定。如果业务知识主要是文档型、更新频繁、风险可控，用强基座模型加 RAG 可能更快更便宜。只有当业务流程、表达方式、决策偏好或任务格式高度垂直，并且有足够高质量数据时，SFT 或偏好优化才更有价值。

上线后模型出错应该怎么定位？

可以按链路拆解：用户问题是否识别正确，检索是否召回正确知识，prompt 是否传达约束，模型是否遵循指令，工具调用是否成功，安全规则是否拦截。定位后再决定是补知识库、改检索、补训练样本、做偏好优化，还是增加人工兜底。