私有化部署大模型如何喂料

模型在内网跑起来了,可一问业务问题就露怯——它不知道你们的产品线、术语和内部流程。这时候就卡在「喂料」这一步:是把资料塞进知识库做检索,还是拿标注数据去微调?两条路成本、周期、维护方式完全不同,选错了要返工。这篇给一套判断标准和可执行动作,帮你在动手前把路线定下来。

模型在内网跑起来了,可一问业务问题就露怯——它不知道你们的产品线、术语和内部流程。这时候就卡在「喂料」这一步:是把资料塞进知识库做检索,还是拿标注数据去微调?两条路成本、周期、维护方式完全不同,选错了要返工。

这篇不吹哪种方案先进,只给一套判断标准和可执行动作,帮你在动手前把路线定下来。核心一句话:能让答案从一份文档里抄出来的,别去改模型参数。

先分清「喂料」到底喂的是什么

模型权重本身是死的。所谓喂料,本质是补两类东西:一类是外部事实,靠检索临时塞进上下文;另一类是表达习惯,靠训练去改参数。这两类东西的脾气完全不同,混着做最容易返工。

事实类

政策条款、产品参数、工单记录,变化快,写进权重就过期

习惯类

固定话术、输出格式、行业黑话的理解方式,检索每次都要重述,不如训练一次固化

判断口径

答案能从一份文档里抄出来,优先检索;答案是一种「怎么答」的模式,才考虑训练

走检索这条路:知识库要准备到什么程度

检索看起来门槛低,但翻车大多不在模型,在资料本身。上线前先把切片粒度和版本管理两件事定下来,后面省掉一堆解释不清的怪答案。

1. 切片按自然段或小标题切,别按固定字数硬切,否则一个问题的答案被拆到两段里,检回来一半;切完拿几道真实问题试,看命中的片段是否完整
2. 加字段每份文档补上版本号和有效期,内网知识库最容易烂在旧版本上,检索出来的是作废文件
3. 三问自测问题问法是否固定、答案是否唯一、文档更新频率多高。三个都偏稳定,检索这条路就够用
4. 选链路路径不清楚的先到 向量数据库目录（/stacks/vector-dbs） 看选型,再决定用哪套检索链路

走微调这条路:什么数据值得拿去训练

微调吃的是「输入-输出」成对样本,不是把文档丢进去就行。整理格式可以先参照 微调服务商目录（/stacks/fine-tuning） 里各家给的说明对齐,免得白折腾一轮再返工。

• 样本要覆盖真实问法,包括错别字、口语化、夹带上下文的问法,只喂标准问句上线就废
• 留一部分样本不参与训练,上线前专门拿它验,不然你无法知道自己训过头没有
• 先定验收题单再开训,题单里写清哪些必须答对、哪些答错无伤大雅
• 提前约定退出条件,比如连续几轮同一题单没有改善就停下,别无止境地调
• 把每次训练的样本版本和题单结果记下来,否则下次没人说得清哪版更好

一张对照表:按业务特征选路线

别把两条路当单选题。多数企业的实际形态是:检索打底保证事实正确,再用少量样本微调输出风格。关键在顺序——先检索,后微调。

两种都要做的话,顺序是先检索后微调:检索先把问题暴露出来,这些真实问法就是微调最好的样本来源。拿不准量级时可以先看 向量数据库目录（/stacks/vector-dbs） 里的方案说明,用最小可用的一套跑通闭环。

上线前后的检查清单

喂料不是一次性动作,而是一条持续维护的流水线。下面这份清单按时间分三段,照做能避免「上线当天挺好,两周后开始胡说」。

1. 喂料前把「哪些问题必须答对、哪些答错无伤大雅」列成一张验收题单,至少几十道,覆盖高频业务场景
2. 喂料中每换一批文档或每一轮训练都跑同一张题单,记录变化,别凭感觉说「好像变好了」
3. 上线后留出「不知道」的出口,让模型在检索不到时明确说没找到,而不是编一个像样的答案
4. 定期复查知识库的失效文档、微调后模型的偏科现象,按固定周期回头查,参照 笔记与知识库（/ai-nav/category/ai-note） 里的工具做内容维护

题单是最值得先写的东西。没有它,你无法比较两种路线,也无法向老板解释这次改动到底有没有用。想横向看看别人怎么搭这套流程,可以到 站点目录（/sites） 找同类项目对照,具体方案数字以站内页面当时显示的为准。