模型选型、微调与部署

模型生命周期不是“选一个最强模型，然后上线”。它从任务定义开始，经过数据处理、模型或 API 选择、评测、优化、部署、监控和版本回滚。每一环都可能把上一个环节的错误放大。

1. 先把任务写清楚

在选择模型之前，定义：

输入是什么：文本、图片、音频、结构化数据，还是多轮操作。
输出是什么：自由文本、分类、JSON、工具调用，还是文件。
成功标准是什么：正确率、引用支持、延迟、成本、可用性。
哪些错误可以接受，哪些绝对不允许。
数据能否离开部署环境，是否需要审计和删除。
使用者是谁，权限和风险边界是什么。

“回答得更好”不是可验证目标。需要具体评测样例，例如“在 300 道内部支持问题中，正确率达到 85%，引用能支持结论，p95 首 token 小于 800 ms”。

2. 能力、延迟与成本

模型选择是多目标取舍：

维度	要看什么
质量	领域正确性、指令遵循、格式、推理深度
上下文	最大 token、有效利用长度、长文召回
输出	多模态、结构化、工具调用、代码能力
延迟	首 token、完整响应、批处理吞吐
成本	输入/输出 token、调用次数、GPU/内存
部署	API 或自托管、地区、隐私、可用性
风险	数据使用、内容安全、版本稳定性

最大模型未必最合适。小模型在明确任务、短输出和高并发场景中可能更划算；大模型适合复杂推理、长上下文和低容错任务。可以用路由策略：简单请求走小模型，复杂请求升级。

2.1 延迟拆解

总延迟 = 排队 + 检索/预处理 + 模型首 token + 生成 + 后处理

首 token 延迟和完整响应延迟是不同指标。聊天界面需要快速首 token，批量摘要更关心总吞吐。上下文越长、输出越多、并发越高，成本和时间通常越大。

2.2 成本拆解

输入 token 与输出 token 数量。
检索、rerank 和工具调用成本。
重试、失败和无效调用。
自托管 GPU 利用率、空闲容量和运维人力。
数据存储、日志和评测成本。

不要只看单次 API 价格。高失败率和长上下文可能让“便宜模型”总成本更高。

3. 评测

评测集应来自真实任务，而不是只找几个漂亮示例。

3.1 数据划分

训练/开发集：调提示、微调和小规模实验。
验证集：模型和参数选择。
测试集：最终评估，避免反复调参污染。
回归集：历史事故和已修复问题。
对抗集：注入、越权、边界输入和恶意内容。

样本要覆盖正常、边界、无答案、冲突、长输入和多语言情况。标注指南要统一，否则不同标注者的“正确”并不相同。

3.2 指标

任务	指标
分类	准确率、精确率、召回率、F1、混淆矩阵
抽取	字段级精确率/召回率、结构合法率
生成	人工偏好、事实性、引用支持、格式合规
检索	Recall@k、MRR、NDCG、权限违规率
Agent	任务完成率、步数、工具错误率、成本
系统	首 token、p95 延迟、错误率、单位任务成本

离线指标必须和线上结果连接。可以记录用户是否采纳、是否修改、是否追问、是否回滚，但不能把点击率简单等同于质量。

3.3 LLM-as-a-judge

用模型做评审可以扩大评测规模，但评审模型也可能偏差：

偏爱长答案、特定格式或自己的风格。
对事实错误不敏感。
无法理解专业边界。
评分不稳定。

应使用人工标注校准，固定评审提示和版本，抽样复核，并保留原始证据。

4. 微调不是默认答案

微调改变模型参数，适合：

固定输出风格或格式。
学习领域术语和模式。
在大量稳定样本上提升小模型表现。
降低对长提示和超大模型的依赖。

它不适合：

频繁变化的知识。
需要引用和权限过滤的数据。
数据量很少、质量不稳定的任务。
仅靠提示就能解决的简单问题。

4.1 数据质量

训练样本要：

与真实输入分布一致。
有统一、可验证的标注。
去重并防止测试集泄漏。
覆盖边界和拒答。
符合隐私、版权和授权要求。

少量高质量样本通常比大量低质量样本更有价值。数据清洗、去重和错误标签会直接影响微调结果，不能只盯着训练参数。

4.2 SFT

监督微调用输入—输出样本训练模型模仿目标回答。它适合教格式、任务流程和风格，但不能自动保证事实正确。训练损失下降不代表任务指标提升，必须用独立验证集评估。

4.3 偏好优化

当“好回答”难以写成唯一答案时，可以收集偏好对，用 RLHF、DPO 等方法优化。偏好数据容易受标注者、长度和格式偏差影响，也要防止模型学会讨好而不真实。

4.4 LoRA 与量化微调

LoRA 冻结基础模型，只训练低秩矩阵，适合多任务适配和较低显存。量化微调进一步降低显存，但可能影响稳定性和质量。需要记录基础模型、适配器、训练数据版本和合并方式。

5. 压缩与推理优化

5.1 量化

把权重或激活从高精度降到低精度，减少显存和带宽，提高吞吐。常见 8-bit、4-bit 方法。量化可能改变输出分布，尤其是数学、代码和长上下文任务。

评测要比较：

任务质量。
输出稳定性。
首 token 与吞吐。
显存与并发上限。
不同输入长度下的退化。

5.2 蒸馏

用大模型或教师模型产生信号，训练更小的学生模型。学生能降低推理成本，但会丢失部分能力。训练数据质量、教师错误和任务范围决定上限。

5.3 编译与运行时

图优化、算子融合、KV cache、PagedAttention、连续批处理和专用推理引擎可以提高吞吐。优化必须基于 profiling，不要同时改量化、批处理和采样参数，否则无法判断收益来源。

5.4 批处理

在线请求和离线任务有不同目标：

在线追求低延迟和公平性，动态批处理需要在吞吐与排队之间平衡。
离线追求总吞吐，可以使用更大批次、异步任务和抢占。
长请求和短请求混跑会导致队头阻塞，可以拆队列或设置时限。

6. 部署方式

方式	优势	代价
托管模型 API	快速、少运维、能力更新	数据边界、价格、配额、供应商依赖
自托管推理	可控、可私有化、可定制	GPU、运维、扩缩容和安全责任
混合路由	简单请求本地、复杂请求外部	路由、一致性和成本监控
边缘/端侧	低延迟、离线、隐私	模型小、设备差异、更新困难

部署前确认网络、身份、配额、超时、重试、降级和数据保留。模型 API 不是普通字符串函数，它可能延迟数秒、返回部分内容或触发安全过滤。

6.1 服务接口

同步接口适合短回答；流式接口适合长文本和需要首 token 反馈的场景；异步任务适合批量生成和长流程。不同接口的错误语义不同：

流式开始后失败，客户端已经收到部分内容。
异步任务要能查询状态、取消和获取结果。
超时后请求可能仍在服务端执行，需要操作 ID。

6.2 自动扩缩容

GPU 实例启动和模型加载慢，扩容不能只看 CPU。需要预热、最小副本、队列长度和并发指标。缩容过快会打断请求，扩缩容过慢会积压。

7. 版本治理

一个模型系统至少有这些版本：

基础模型。
tokenizer。
适配器/微调权重。
推理引擎和量化参数。
系统提示和工具 schema。
检索索引和 embedding 模型。
评测集与评测代码。

版本要能一起回滚。只回滚模型而保留新提示，或只换 embedding 而不重建索引，都可能制造新的不一致。

发布策略：

影子流量：复制输入到新版本，不影响用户。
小流量灰度：比较质量、延迟、错误和成本。
人工审核：高风险任务先让新版本给建议，由人确认。
自动回滚：关键指标超过阈值时切回旧版本。

8. 运行监控

模型监控不只看服务是否在线：

请求量、并发、排队和超时。
首 token、总生成时间和 token 速度。
输入/输出 token、上下文截断和成本。
工具调用成功率、步数和循环次数。
拒答率、安全过滤率和格式校验失败率。
检索命中率、引用率和无答案率。
用户采纳、重试、投诉和人工修正。

记录输入输出时要注意隐私、访问控制和保留期。可以用哈希、长度、脱敏片段和采样 trace 平衡排查与安全。

9. 哪些情况需要重训或重新索引

变化	可能需要
文档内容更新	重新分块和索引，不一定重训
术语和固定格式变化	提示、示例或微调
权限和租户变化	更新元数据与检索过滤
embedding 模型更换	重建向量索引
任务分布明显变化	新评测集和再训练
基础模型升级	全链路回归和灰度
推理引擎/量化变化	质量与性能回归

不要因为“模型效果不好”就直接微调。先确认问题在检索、提示、工具、数据、模型还是产品交互。

10. 成本与容量

优化顺序通常是：

减少无效调用和重试。
缩短上下文，只保留必要证据。
按任务路由到不同大小模型。
缓存稳定前缀和重复结果。
控制输出长度和并发。
再考虑量化、蒸馏和自托管。

自托管不是自动更便宜。GPU 空闲、运维、电力和工程投入都要计算。若利用率低，托管 API 可能更经济；若访问稳定、数据不能外发且有规模，自托管可能更合适。

11. 上线前检查

任务、成功标准和失败边界是否定义。
评测集是否来自真实分布，是否覆盖无答案和攻击。
是否比较了提示、检索、微调和不同模型。
是否记录模型、提示、索引和工具版本。
流式、超时、取消和部分失败是否有语义。
是否支持灰度、回滚和旧版本数据兼容。
是否监控质量、延迟、成本和用户行为。
是否验证隐私、权限、内容安全和审计。
是否知道何时该重新索引，何时该重训。
是否能用评测证据说明“这次升级真的更好”。