为什么直接问模型效果差

把公司 wiki 导出丢给模型，问"我们的退款流程是什么"，大概率得到两种结果之一：一本正经地编一个流程，或者回答"我无法访问你的内部文档"。原因有三层：

  • 训练数据里根本没有：内部文档、私人笔记从未进入任何模型的训练集
  • 上下文塞不下：动辄几十万字的文档库，远超模型的上下文窗口
  • 就算塞得下也不可靠：长上下文里模型会"看漏"关键段落，而且幻觉是统计式生成的本性，不是修个 bug 就能解决的

RAG（检索增强生成）的思路是反过来：先从你的知识库里检索出相关段落，再让模型"看着资料回答"。事实来自检索，模型只负责组织语言——这正是它擅长的分工。

三件套：切块、Embedding、向量库

RAG 的离线部分由三个组件构成：

  1. 切块（Chunking）：把文档切成 300-500 字的段落，块与块之间保留 10%-20% 的重叠，防止关键句子被切断。切块大小没有万能值：问答类知识偏小块，需要通读上下文的长文档偏大块
  2. Embedding（向量化）：用 Embedding 模型把每个块变成高维向量——语义相近的文本向量距离也相近，这是"按意思搜"而不是"按关键词搜"的基础
  3. 向量库：存向量并支持相似度检索，个人轻量级用 FAISS、Chroma，团队级再考虑 Milvus 一类

切块是最容易被低估的一步。策略不必凭感觉定，直接拿真实文本做实验：把一篇文档粘进文本分割合并工具，按字数或自定义分隔符切几版，检查有没有把表格、条款从中间切断——检索质量的瓶颈通常在这里，不在模型。

搭建步骤：离线入库 + 在线问答

RAG 系统分两条流水线。

离线入库，文档变化时跑一次：

  1. 清洗文档：去掉页眉页脚、乱码和无效字符
  2. 按上面的策略切块
  3. 全部块过一遍 Embedding 模型算出向量
  4. 向量连同原文一起存入向量库，并给每个块附上元数据（来源文件、章节、更新日期）——有了元数据，检索时就能先按条件过滤再搜，比如只查 2026 年之后修订的制度文件

入库前用 Token 计数工具估一下总 Token 量：500 份文档、平均 5000 字，合计约 250 万字，折算成 Token 后再对比按量计费的 Embedding API 和本地部署模型的单价，哪个划算一目了然。文档后续更新时，只对改动部分重新切块入库、替换旧块即可——知识更新不需要碰模型，这正是 RAG"外脑"的意义。

在线问答，每次提问执行：

  1. 用户问题向量化
  2. 在向量库里检索最相似的 3-5 个块
  3. 把块拼进提示词，交给模型生成答案

核心提示词：“仅根据给定资料回答”

在线问答的质量，一半取决于检索，另一半取决于提示词。底版如下：

1
2
3
4
5
6

你是资料问答助手。仅根据【资料】中的内容回答【问题】，
禁止使用资料之外的知识。
如果资料不足以回答，直接回复"资料中没有相关内容"。
回答末尾标注引用了资料的第几段。
【资料】{检索到的3-5个块}
【问题】{用户的问题}

两个细节比模板本身更重要：一是明确允许模型说"不知道"，不给台阶它就会硬编；二是要求标注引用，让用户能点回原文核验。调好的版本存进 Prompt 提示词库——它覆盖写作、编程、翻译、学习、办公五类模板，支持变量占位填充与自定义、导入导出，团队里谁搭新知识库都能直接复用同一套提示词。

调优清单

调优前先建立基线：固定 20 个有标准答案的测试问题，每改一处就重跑一遍——凭感觉调，效果只会来回震荡。之后按这个顺序排查，从最常见的问题开始：

  • 检索不到 → 先人工确认资料确实入库了；再检查切块是否太大被稀释，或文档本身质量太差
  • 检索到了但答案不用资料 → 提示词约束不够硬，或 top-k 太多挤占了注意力，降到 3 个试试
  • 答案笼统 → 切块太小，单块信息量不够，加大到 500 字上下
  • 专业词搜不准 → 上混合检索：关键词匹配 + 向量检索双路召回再合并
  • 问题太口语导致检索不准 → 加一层查询改写：先让模型把用户的问题改写成适合检索的完整表述，再拿去搜
  • 答案存疑 → 保留引用标注让人能核验，这是抑制幻觉最实用的一招

常见问题

RAG 和微调到底选哪个？

知识频繁更新选 RAG——改文档就行，不用重训；要解决输出风格与固定格式选微调。两者不冲突：微调管"怎么说"，RAG 管"说什么"。微调的适用边界与完整流程见《LoRA 微调入门》。

不写代码能搭吗？

可以。笔记软件内置的"AI 问答"、各种低代码知识库产品，本质都是 RAG，原则完全相同：切块别太碎、提示词要限死"仅根据资料回答"。本文的调优清单照样适用。

能全程本地化吗？

可以。本地大模型（Ollama 等）加本地 Embedding 模型，文档和问题都不出网。硬件怎么选、模型怎么装，见《16G 内存 Mac 怎么跑本地大模型》。

小结

RAG 的本质是给模型配一个随时可更新的外脑：切块决定找得准不准，提示词决定答得实不实。先用几十份文档跑通最小闭环，再扩规模。本地跑大模型场景专题里收集了配套的提示词库与成本估算工具，搭建过程中随时用得上。