这是《大模型学习记录》的第六篇。前五篇我把Transformer结构、Tokenizer、预训练、指令微调这些概念从理论上啃了一遍，也跑了不少开源模型做推理实验，但说实话，心里一直有一个坎：模型拿来聊天很顺，可真要让它在某个具体领域里替我干活，我总觉得隔着一层。这篇记录，就是跨过那层坎的过程——从零开始把一个开源基座模型，调成能回答垂直场景问题的问答助手。我验证的路线就是很多人纠结的那条：微调、检索增强生成（RAG）、推理部署，三者怎么配合落地。
这篇适合谁看？和我一样处在“模型能跑但不会用”的中间状态的人；想在垂直场景快速搭一个问答/客服/资料检索工具的人。如果你还在纠结“该微调还是该上RAG”、“LoRA参数到底怎么设”、“为什么部署时老爆显存”，那这篇里都有我踩过的真实答案。
1. 这个阶段到底在学什么：从“会聊”到“能干活”
1.1 搭好的底子有什么用
前几篇我啃完了不少概念：注意力机制里QKV怎么算、tokenizer的词表怎么影响效果、预训练和指令微调的loss差异、量化是怎么回事。说实话，当时学这些的时候有点泛，觉得“我知道这回事”但离“我会用”还有距离。直到这次真正动手做落地项目，我才发现这些底子全都能用上——看懂训练脚本里每一行的意义、判断loss曲线是否健康、定位显存爆炸的位置，靠的都是之前积累的框架性认知。
所以如果你想直接跳到这篇的操作步骤，我建议至少先弄明白三件事：Transformer的推理过程是逐token生成的（所以有延迟和显存的讲究）；我们说的“微调”基本是在已有基座上做适配，不是从头训练；大模型本质是“概率接龙”，它天然会编，只是编得好坏的区别。这三件事不理解，后面很多参数改了也不知道为什么。
1.2 第六篇给自己定的三个目标
这个阶段我不打算再铺新概念，而是定了三个非常具体的验收标准：
第一，让模型能回答某个垂直领域的问题，而不是泛泛空谈。第二，允许它说“不知道”，但尽量不乱编答案，把幻觉压到可控范围。第三，回答延迟控制在可接受的范围，至少不能让人等得不耐烦。
这三个目标分别对应了三种技术手段：领域数据微调解决“能回答”；检索增强生成解决“不乱说”；推理框架部署解决“快一点”。听起来不复杂，但真正串起来的时候，每一环都有不少细节坑。
1.3 选一个具体的磨刀场景
我给自己搭的练手项目，是一个模拟的某制造企业设备检修知识库。场景很典型：一堆设备操作手册、故障排查文档、维修记录散落在PDF和Word里，工人查资料靠翻文件夹，效率极低。希望做一个问答入口，让维修工直接问“这台设备报错E302怎么处理”，系统能够基于文档给出有依据的排查步骤。
为什么选这个场景？因为它同时覆盖了RAG的核心要素：资料多、格式杂、答案必须可溯源，而且对幻觉的容忍度极低——万一模型编出一个错误的检修步骤，那是可能出事故的。这种场景下，你才能逼自己把“可控性”做扎实，而不是只把demo跑通就完事。
2. 微调还是RAG：先想清楚再动手
2.1 两条路线的边界
开始调模型之前，我先花了两个晚上把“微调”和“RAG”的边界捋了一遍。我的判断标准很简单：知识是变还是不变，你要的是“风格”还是“事实”。
| 对比维度 | 微调（Fine-tuning） | 检索增强生成（RAG） |
|---|---|---|
| 知识更新 | 更新成本高，改知识要重训练 | 换文档就行，更新极快 |
| 幻觉控制 | 靠模型记忆，容易张冠李戴 | 答案有资料依据，大幅降低编造 |
| 句式风格 | 能显著改变模型表达习惯 | 基本保留基座模型本来风格 |
| 数据需求 | 高质量标注数据，量大才有效 | 只需要文档切块建索引，不需要标注 |
| 计算资源 | 需要GPU训练，成本不低 | 只做检索+推理，训练成本为零 |
| 适用场景 | 调整输出格式、语气、领域术语 | 事实性问答、文档密集的知识领域 |
这张表做完，结论已经很明显了：我的设备检修场景，知识基本都在文档里，而且文档还会持续更新，这恰好是RAG的强项。如果我只做微调，等于让模型死记硬背几千页操作手册，既慢又不准，万一文档更新了还得重训。但如果我只做RAG、完全不做微调，又会遇到另一个问题：模型输出格式不可控，你以为它在给答案，它却在那儿长篇大论地发散。
2.2 为什么我选了“RAG为主、微调为辅”
最终方案是：RAG提供事实依据，微调负责教会模型“怎么把依据用起来”。这句话听起来轻巧，实操里的分工其实很清晰。
RAG侧的活儿是：把几千页PDF拆成小段、转成向量、建索引，用户提问后先把最相关的几个片段捞出来，拼成上下文喂给模型。模型的任务就变成“基于给定资料回答问题”，而不是凭空想。这就像给模型配了一个随时能翻的资料库，它答完还会告诉你依据是从哪来的。
微调侧的活儿则是：用几百条精心构造的对话数据，让模型学会输出格式。比如，它必须先说结论再说步骤，资料不足时必须说“根据现有资料无法确认”，回答里要带上“资料来源：文档X”这样的引用标记。这些事用提示词也能做个七八成，但用微调去固定下来更稳定——实测下来，提示词偶尔还是会“漏掉”引用标记，微调后基本不会。
2.3 整套方案需要准备的组件清单
想清楚路线之后，我列了一个组件清单，接下来几周基本就是围绕这份清单逐个落地：
- 基座模型：选了某开源7B对话模型，中等规模，24G显存的卡能跑，效果也够用。
- LoRA微调脚本：自己用训练框架写了配置脚本，同时做了Q-LoRA降显存方案，方便在单卡上跑。
- 向量数据库：本地部署了一个轻量向量库，支持标量+向量混合过滤，不依赖外部服务。
- Embedding模型：某个针对中文优化的本地向量模型，维度1024，保证文档切块后能转成高质量向量。
- 重排序模型：用来对召回的候选片段二次打分，把真正有用的信息排到前面。
- 推理服务：部署一个支持连续批处理的推理框架，对外暴露标准Chat协议接口，方便应用对接。
3. LoRA微调的实操记录
3.1 训练数据怎么准备
我先说说微调数据。我的做法不是去网上找通用指令数据，而是完全基于自己的检修场景构造了600条对话对。数据量不大，但对垂直场景LoRA微调来说已经够了——很多时候质量远比数量重要。
数据格式用的是ChatML格式，这是基座模型支持的对话结构。简单说就是每条数据分成三段：system提示词、user提问、assistant回答。我给你看一条简化过的样例：
{ "messages": [ {"role": "system", "content": "你是设备检修助手。回答必须基于提供的资料，不得编造。如果资料不足，明确说无法确认。"}, {"role": "user", "content": "压缩机排气温度持续偏高，可能是什么原因？"}, {"role": "assistant", "content": "根据维护手册第3章，排气温度偏高常见原因有：1.冷却水流量不足，检查冷却塔进出口阀门开度；2.润滑油老化，取样化验并按周期更换；3.吸气过热度偏大，调整膨胀阀开度。资料来源：压缩机维护手册.docx。"} ] }构造数据的时候有一条重要原则：内容必须“有据可查”。我是从检修文档里挑出高频问题，把文档里对应的段落改写成回答，而不是让模型自己发挥。这样微调出来的模型，它学的是“怎么组织答案、怎么引用来源”，而不是学“编内容”。
清洗数据时我踩过一个坑：原始文档里有大量表格和特殊符号，直接塞进训练样本会导致tokenizer输出一堆无意义字符，loss还降不下去。后来统一做了处理：表格转成文字列表、去重、删除明显乱码段落、统一标点符号为中文格式。这一步看似琐碎，但对训练稳定性影响非常大。
3.2 关键训练参数是怎么定下来的
LoRA的核心概念不复杂：冻结原模型权重，在attention层旁边加一小部分可训练的低秩矩阵。需要调的核心参数就四个：r（秩）、alpha（缩放系数）、学习率、batch大小。
我这次用的配置如下，按我的经验解释一下每个值的直觉：
lora_rank: 16 lora_alpha: 32 lora_dropout: 0.05 learning_rate: 2e-4 batch_size: 4 gradient_accumulation_steps: 8 max_seq_length: 1024 epochs: 3r取16，意味着低秩矩阵的维度和原模型参数相比小得惊人，但因为加在注意力投影层上，依然能有效调整模型的输出行为。r太小（比如4）学不到东西，r太大（比如64）又容易过拟合，16是大多数LoRA实践里性价比很好的起点。alpha取32，也就是alpha/r=2，这是一个经验上效果接近“正常微调”的倍率。如果你把alpha调成和r一样，效果会打折扣。
学习率我试过5e-5和2e-4，前者收敛太慢，3个epoch下来还没进入稳定状态；后者是LoRA微调常用的区间，实测loss曲线下降平稳。batch_size是受显存限制定的4，配合梯度累积8等效于batch 32，这个等效批量在600条数据上表现不错。max_seq_length定1024，因为检修手册里的问答片段普遍不长，太长了显存扛不住，太短了会把答案截断。
3.3 训练中怎么判断模型学没学会
训练过程中我最关注两件事：loss曲线和验证集上的定性表现。先说loss，LoRA训练跑3个epoch，loss从2.x降到0.8左右是正常的。但千万注意，loss降得越低不代表越好——我有一次跑了5个epoch，训练loss降到0.3，模型却开始“背诵”训练数据，QA时只会原句复述，换个说法提问就傻了。这就是过拟合。LoRA在垂直领域的过拟合往往不是产生幻觉，而是死板。
所以我的判断标准是：训练集上loss下降是一回事，更关键的是留出50条没训练过的真实问题，每训练完一个epoch就跑一遍这些验证问题，人工看回答质量。比如上面那个压缩机的问题，我会变换说法再问一遍，看它是否还能定位到冷却水、润滑油、膨胀阀这几个点。如果第2个epoch就基本稳定，说明模型学得已经够了，第3个epoch只是强化格式能力，风险可控。
还有一个小技巧：训练时把system提示词和assistant回答的开头格式固定下来，这样模型能牢牢记住“回答要以‘根据资料’开头”。这算是格式微调里性价比最高的一招。
4. 知识库构建与检索链路
4.1 文档切块：chunk_size与overlap的取舍
RAG这端第一个坑就是文档切分。原始检修手册里，一段生产厂家写的技术文档可能有三四页，要是整段塞进知识库，检索时相关性会被大量无关内容稀释，而且embedding模型对过长文本的语义捕捉也会变差。但如果切得太碎，比如一句话一段，又会丢失上下文，导致模型拿到片段时不知道在讲哪个部件。
我最后用的配置是：chunk_size=256（token数量），overlap=32。这个数值不是拍脑袋定的，我在测试集上跑过不同配比，256+32这个组合在“答案召回完整度”和“上下文连贯性”之间最平衡。overlap的作用特别重要——它相当于让相邻切片有公共部分，这样如果答案恰好落在两个切片的边界上，至少有一个切片能包含完整的答案。
切完以后我犯过一个很低级的错误：把标题和目录也当成知识块存进去了。结果是模型经常回答“详见第X章”然后给不出实质内容。处理办法是写了一个简单脚本，把纯目录页、重复的页眉页脚、过于短的片段（少于50字符）全部过滤掉，这类噪声文档对检索质量的影响比你想象中大得多。
4.2 Embedding模型选型和落地
Embedding是整个RAG链路的翻译官，它把文本变成向量，让计算机能算“语义距离”。我对embedding模型的要求有三条：中文效果好、能完全本地部署、推理速度快。项目数据不能传到外部服务，这是硬前提，所以云端的embedding API直接排除。
本地部署我测过几款，最后选了某个针对中文优化的开源embedding模型，输出维度1024。实测它对中文技术文档的语义理解明显比通用模型好，比如“报错E302”和“高温报警代码302”这种表述不一致但语义接近的文本，它能给出比较高的相似度分数。这个能力在工业检修场景里非常重要，因为工人和工程师描述同一故障时用语差异特别大。
存向量时我用的是某个支持向量检索的本地数据库，结构很简单：每条知识块存三个字段，向量向量、原文文本、来源文件名。这样检索结果可以直接返回“原文+出处”，让模型回答时能引用来源。顺便说一下，构建索引时一定要做多线程批量写入，几千个文档逐个插入会慢到你怀疑人生。
4.3 检索命不中怎么办：重排序与混合检索
第一次上线测试的时候，我的检索命中率大概只有60%，经常找不到正确答案所在的片段。单纯靠向量检索，在小规模知识库里表现不够稳。后来我把检索链路升级成了“混合检索+重排序”两段式：
第一步，同时跑两个召回通道。通道一是BM25关键词检索，擅长精确匹配“E302”这种设备编号；通道二是向量语义检索，擅长匹配“压缩机温度偏高”这种语义表达。各自取前20个候选，合并去重。第二步，用一个重排序模型对这40个候选逐条打分，按相关性重新排序，最终取前5条作为上下文送入大模型。
这一套流程跑下来，命中率从60%提到了85%以上。重排序模型非常关键，它相当于在候选集里再筛一遍“到底哪些片段真正回答问题”。如果你对这套链路不熟，我建议不要两头都从零写，直接用成熟的检索框架搭，再挂一个rerank模块，性价比最高。
另外有一个检索侧的小习惯：问题进入检索前先做一次简单改写。比如用户问“E302怎么解决”，我会先在代码里映射成“报错E302的处理方法”再检索。这个小操作能同时提升BM25的精确匹配成功率和向量检索的语义匹配质量。
5. 推理部署阶段的各种坑
5.1 显存估算与量化水位
部署阶段的第一个问题是显存。7B模型，FP16精度下光权重就占14GB，加上KV cache和激活值，24G显存的卡勉强能跑但余量很小。我先把显存估算方法说清楚：
| 配置方案 | 模型权重大小 | 推理额外显存 | 实际建议 |
|---|---|---|---|
| FP16全精度 | 约14GB | 8GB以上 | 24GB卡勉强，32GB卡舒适 |
| INT8量化 | 约7GB | 6GB以上 | 24GB卡流畅运行 |
| INT4量化 | 约4.5GB | 5GB以上 | 16GB卡也能跑，质量有轻微损失 |
质量有没有损失？我拿测试集跑了对比，INT4在多数领域问答上质量下降不明显，但偶尔会出现逻辑不连贯的句子。考虑到检修场景对准确性要求极高，我最后选了INT8量化，保留更多信息量。
这里有个容易踩的坑：有些推理框架默认加载模型时不做任何显存优化，你得显式开启KV cache量化、设置最大序列长度、限制并发请求数。尤其max sequence length，如果你保持默认值65536，显存连响都不响就直接爆OOM。我部署时把这几个参数统一配置好，显存占用从峰值25GB降到了稳定16GB。
5.2 推理框架部署与接口对接
部署时我选了一个支持连续批处理的开源推理框架，它能显著提升并发吞吐。连续批处理的意思是，同一个GPU上多个请求的生成阶段可以交错进行，而不是必须等一个完整生成完才能处理下一个。实测8个并发请求同时进来，每个请求的首token延迟在500毫秒左右，比暴力排队快得多。
对外接口我是按标准Chat协议的HTTP接口暴露的，这样应用侧对接成本极低——传到应用层只需要把用户问题拼成对话格式POST过去，解析返回字段里的回答文本就行。上线测试时我顺手写了个脚本，连续发了200个问题去压测，发现只要并发数超过12，延迟就会明显上升，后来把服务层最大并发锁在8，响应时间就稳定了。这个“并发上限”必须实测出来再写死，不能靠猜。
5.3 上线后关注的性能指标
部署完不能只看“能回答就完事”，我用三个指标评估了系统状态：
首token延迟（TTFT），衡量用户输入问题到收到第一个字的时间，目标是控制在1秒内；单token生成速度，衡量整体回答速度，这个取决于显卡算力和量化程度；并发吞吐，考验服务在多人同时使用时的表现。
我最终线上稳定的数据是：首token延迟0.6秒、生成速度每秒32个token、8并发无压力。对一个内部检修问答工具来说，这个体验已经够流畅了。如果后续要支持更多并发，方向很明确：加一张卡做横向扩展，或者把模型量化到INT4换吞吐，但要在质量损失和性能之间再权衡一次。
6. 这一个阶段踩过的坑清单
6.1 训练侧问题排查
训练阶段我遇到了三个典型问题，整理成表格供你对照：
| 现象 | 可能原因 | 解决办法 |
|---|---|---|
| loss下降极慢或震荡 | 学习率过大或数据噪声过多 | 降低学习率到1e-4，重新清洗训练数据 |
| loss降得很低但回答变傻 | 过拟合，训太多epoch或数据量太少 | 减少epoch，增加数据多样性 |
| 生成结果总带无关符号 | 数据清洗不彻底，特殊字符干扰 | 预处理阶段统一转中文标点、去HTML标记 |
如果你照着我上一节的配置来跑，大概率不会遇到这些坑，但如果你改了大batch或加大r值，记得保持观察loss曲线的习惯，任何剧烈震荡都说明参数设置有问题。
6.2 检索侧问题排查
| 现象 | 可能原因 | 解决办法 |
|---|---|---|
| 检索结果和问题毫无关联 | chunk切分过大，语义被稀释 | 把chunk_size降到256，overlap保持32 |
| 答案信息不完整 | 答案被切块边界截断 | 增加overlap到50，或启动边界回溯 |
| 设备编号检索不到 | 向量模型对精确编号不敏感 | 加入BM25关键词通道，混合检索 |
| 用户换种说法就问不中 | embedding模型领域匹配度不不够 | 换成针对中文垂直领域优化的embedding模型 |
6.3 部署侧问题排查
| 现象 | 可能原因 | 解决办法 |
|---|---|---|
| 启动直接OOM | 默认未开启KV cache优化 | 开启量化、设置max_seq_len不要超过2048 |
| 并发一高就超时 | 单请求显存占用太高 | 限制最大并发数，或换成INT4量化 |
| 回答速度特别慢 | 热词匹配触发长上下文 | 检查是否把无关注释也灌入了上下文 |
| 偶尔返回空结果 | 检索层拿到空片段 | 增加兜底逻辑，把问题重新检索一次 |
说到部署，还有一个小而致命的问题：推理框架默认会加载整个模型词表，如果你给基座模型加了自己训练的自定义token（比如某些业务符号），在推理阶段tokenizer不匹配会导致回答乱码。我调了一晚上才发现是这个问题，最后把自定义token从微调配置里去掉，让模型老老实实用原词表解决问题。这类坑文档里基本不会写，但碰到了真的很折磨人。
这一步系统完整跑下来，我的感受是：大模型落地并没有某个“神之一手”的步骤，更多是把数据、微调、检索、部署各个环节都做到合格。微调和RAG不是对立关系，它们解决的是不同层面的问题——一个管“怎么说话”，一个管“知道什么”，两者配合才能在垂直场景里形成可控、可用的闭环。我自己在实操中的体会是，前期的数据准备和知识库构建要占到整个项目60%的精力，训练和部署反而相对顺畅；数据质量决定了效果上限，模型能力只是把这份质量释放出来。希望这篇记录能给你降低一点试错成本，如果你也卡在“模型能跑但不会用”这个阶段，按照这条链路一步步走，很快就能看到自己的垂直模型真正开始干活了。
