垂直领域文档智能问答：一定要微调吗？RAG 落地思路与选型

手里有一批产品说明书、操作手册或内部流程文档，想做一个问答机器人：用户提问，模型只依据这些资料作答，最好还能说清楚答案出自哪一页。很多人第一反应是「把这些文档喂给模型训练一下」，于是想到 fine-tuning（微调），接着又冒出一串疑问：调用 API 做这件事够不够？用便宜的第三方密钥能不能微调？除了微调还有没有别的路？

核心结论先说：绝大多数「依据指定文档回答」的需求，用检索增强生成（RAG）比微调更合适。微调不是把文档「灌进」模型的手段，它改变的是模型的输出风格和任务模式，而不是可靠的知识库。下面把两条路的分工、落地步骤和常见坑拆开讲。

微调和 RAG 到底在解决什么

微调改变的是「习惯」，不是「资料库」

微调通过在大量「输入—期望输出」样本上继续训练，让模型更倾向于某种回答格式、语气或领域表达方式。它有几个天然限制：

• 知识被压进参数，无法精确溯源，也容易被「记串」；
• 文档一更新就得重新准备数据、重新训练；
• 需要几百到几千条高质量问答对，标注成本远高于想象；
• 模型仍可能编造文档里没有的内容。

RAG 是「先查资料，再回答」

RAG 的流程是：把文档切块并转成向量存入检索库；用户提问时先检索出最相关的若干片段；把这些片段拼进提示词，让模型基于片段生成答案。它的优势是知识外置、随改随生效、可以附出处、可以明确拒答。

两者并不互斥：常见做法是先用 RAG 解决「答得对」，等输出格式或语气仍不满意时，再用少量样本做微调。

垂直文档场景为什么优先选 RAG

说明书类内容有两个特点：数量不大但要求精确，且会随版本迭代。RAG 正好匹配：

• 参数、步骤、单位这类细节必须一字不差，检索原文比模型「回忆」可靠；
• 新版本手册上线只需替换文档，不用重训；
• 用户追问「哪一章写的」时能给出引用；
• 问题超出文档范围时可以明确说「资料中未提及」，而不是编一个答案。

用第三方低价密钥的几个现实风险

很多人想用转售或共享的便宜 API 密钥来压成本，需要提前想清楚：

1. 是否支持微调：微调通常需要账号级别的训练权限，训练产出的模型标识与账号绑定，中转层很难完整透传。多数低价密钥只开放基础的对话接口，微调基本用不了。具体能力以服务方官方最新说明为准。
2. 稳定性：这类密钥可能随时限速、失效或触发风控，线上服务会直接中断。
3. 数据安全：RAG 需要把公司文档片段随请求发出，等于把内部资料交给来源不明的中转方，这在企业项目里往往是硬性红线。
4. 合规：买卖、共享账号本身可能违反服务条款，出问题没有申诉渠道。

务实做法是：练手阶段可以用低成本渠道验证流程，生产环境切回官方渠道；敏感文档优先选择支持私有化部署的模型或本地推理。

一套最小可用的 RAG 落地步骤

第一步：界定边界

先写清楚「能答什么、不能答什么」。只答文档内容，超出范围统一回复固定话术。这条约束比模型选型更影响体验。

第二步：文档预处理与切块

• PDF 先转文本，清掉页眉页脚、水印、目录页码；
• 按标题层级切块，单块 300–800 字，相邻块保留 10%–20% 重叠，避免答案被切断；
• 每块附带元数据：文档名、章节、页码、版本号。

第三步：向量化与入库

选择与查询语言匹配的嵌入模型，把文本块转成向量写入检索库。数据量小的时候，本地向量库甚至带向量扩展的关系型数据库就够用；数据量大再考虑专用向量数据库。

第四步：检索与重排

先取较高的召回数量（例如 3–8 条），有条件再加一层重排，或把关键词检索与向量检索结果合并。召回不准时，先怀疑切块粒度，而不是急着换模型。

第五步：提示词约束

你是产品说明书问答助手。只能依据下面提供的【资料片段】回答。
规则：
1. 资料中没有的信息，回答「文档中未提及」，不要推测。
2. 回答末尾列出引用的片段编号与文档名。
3. 涉及参数、操作步骤时逐条列出，保留单位。

【资料片段】
[1]（文档名 / 章节）……
[2]（文档名 / 章节）……

【用户问题】
{question}

第六步：建立评测集

准备 30–50 条真实用户问题，配标准答案，每次调整后重跑。把失败案例分三类：检索没召回、召回但答错、文档本身没写。三类问题的修法完全不同，混在一起调只会越调越乱。

第七步：持续迭代

补文档、调切块、改提示词、换嵌入模型，按上面的分类逐项优化，不要一次性全改。

不想写代码：平台化方案

项目周期短、只是练手时，可以直接用现成的知识库问答平台：上传文档、配置分段规则和提示词、选模型即可跑通。这类平台的取舍在于可定制性和私有化能力——对格式特殊、需要深度改检索逻辑的场景，后期往往还是要回到自建。文档涉及内部资料时，先确认能否私有化部署。

什么情况下才值得考虑微调

• 输出必须是严格的结构化格式（固定 JSON 字段、固定工单模板）；
• 客服话术、品牌语气需要高度统一；
• 有稳定的标注数据来源，且已有 RAG 基线；
• 领域术语太多，检索与提示词都压不住表达偏差。

即使微调，样本质量也比数量重要：几百条覆盖真实提问方式的样本，通常优于几千条机器生成的问答对。

检查清单

• 是否明确了「无依据不答」的边界话术
• 文档是否清理过页眉页脚并保留了来源元数据
• 切块是否按标题层级、带重叠
• 检索条数与重排策略是否验证过
• 是否准备了 30 条以上的评测问题
• 密钥来源是否合规、敏感数据是否出网
• 是否有版本更新后的重新入库流程

小结

「只依据垂直文档回答」这类需求，默认答案应是 RAG，微调作为格式与风格的补丁。低价第三方密钥适合验证流程，不适合承载生产流量，微调能力也基本指望不上。文档量不大、更新频繁、需要出处的场景，把力气花在切块质量和提示词约束上，收益通常比换更大的模型更明显。若索引构建、批量重算这类任务需要长时间挂着跑，而本地机器又不太稳定，把这类后台任务放到一台长期在线的远程机器上执行也是可选项，避免本地休眠导致任务中断。