01
通用模型在专业问题上答不准
行业术语、内部口径、专业判断反复出现错误,靠调整提问方式改善有限。
适用情况
下面这些信号出现时,专属模型通常能带来明确收益;反之,先考虑成本更低的路线。
01
行业术语、内部口径、专业判断反复出现错误,靠调整提问方式改善有限。
02
例如风险评估口径、技术方案取舍逻辑、审核判定标准——这些是需要稳定复现的能力,而不只是知识。
03
有真实的历史记录、标准答复或案例材料,能构成"输入 + 符合企业标准的正确输出"这样的样本对。
04
对外文书、报告格式、客服表达需要长期保持一致,且这种一致性很难靠提示词稳定维持。
技术路线
三种路线解决的是不同层面的问题。判断顺序应该是:能用提示词解决的不建知识库,能用知识库解决的不做微调。每往上一层,投入和维护成本都会明显增加。
| 路线 | 解决什么问题 | 什么时候选它 |
|---|---|---|
| 提示词工程 | 回答的语气、格式、角色与流程 | 问题只是表达不统一 |
| 知识库(RAG) | 模型不知道企业自己的信息 | 属于知识缺失,且知识更新频繁 |
| 微调本页方案 | 模型需要形成稳定的专业判断或表达风格 | 有标准答案样本,且能判断效果好坏 |
样本质量的作用远大于数量。几百条贴近真实业务场景的高质量样本,通常比几万条格式混乱的历史文档更有效。低质量数据混进来,模型学到的会是错误模式。
微调擅长固化的能力与风格,不擅长承载频繁变化的事实。产品参数、价格政策、活动规则这类内容仍应放在知识库里,改一份文档即刻生效。
恰恰相反。微调如果用了不准确的数据,会加重模型的自信错误。控制幻觉更有效的方式是知识库加引用约束——让模型基于检索到的资料回答并给出出处。
交付内容
除了模型本身,更重要的是让企业知道怎么判断它好不好、边界在哪里。
01
明确用哪些数据、怎么清洗、哪些需要人工标注,以及数据使用的合规边界。
02
把历史记录与标准答复整理成"输入 + 符合企业标准的输出"的成对样本。
03
一起准备有代表性、有人工判定的测试问题,并记录微调前的表现作为对比基线。
04
基于公共大模型完成训练与调优,产出企业专属模型。
05
微调前后在评测集上的表现对比,说明哪些场景变好、哪些没有明显变化。
06
适用边界、调用方式、与知识库的配合方式,以及后续如何继续迭代。
交付流程
模型训练的效果很大程度取决于样本与评测集的质量,这两件事都需要企业深度参与。
| 阶段 | 我们做什么 | 需要企业配合 | 阶段产出 |
|---|---|---|---|
| 场景与路线确认 | 判断问题类型,确认是否真的需要微调 | 说明业务目标与判断标准 | 技术路线建议 |
| 数据评估 | 评估现有数据能否支撑训练,识别缺口 | 提供数据、指定业务专家参与 | 数据整理与标注方案 |
| 样本与评测集 | 构建训练样本与测试问题集,记录基线表现 | 确认标准答案、参与评测判定 | 训练样本与评测集 |
| 训练与评测 | 完成微调并在评测集上对比效果 | 抽查实际回答质量 | 专属模型与效果对比报告 |
| 交付与迭代 | 交付模型与使用说明,持续优化 | 提供真实使用反馈 | 模型使用说明与迭代建议 |
各阶段的具体周期取决于数据现状与任务复杂度,会在场景确认阶段给出明确排期。
配套方案
不确定要不要做微调时,先做一次诊断把技术路线判断清楚。
了解方案把训练好的模型接入具体业务流程,做成可用的智能体应用。
了解方案专属模型可作为数字员工的专业能力来源,在多个岗位上复用。
了解方案常见问题
没有统一标准,取决于任务复杂度与数据质量。样本的"代表性"比数量更重要——能覆盖真实业务场景、且有明确标准答案的样本才有价值。我们会在数据评估阶段给出具体判断。
多数企业一开始都没有。常见做法是从历史记录、真实问答与业务文档中提取,再由企业业务专家确认标准答案,必要时组织小规模人工标注。这部分工作会在方案中明确分工。
靠评测集对比。我们会先记录微调前在测试问题上的表现作为基线,训练后再跑一遍同一套问题,并给出对比结果——包括哪些场景变好、哪些没有明显变化。没有评测集就只能是盲调。
训练数据往往涉及企业的核心资产。数据范围、使用方式与部署方案会在方案设计阶段明确并写入实施方案,涉及核心工艺或客户信息的场景会先确认边界。