一、四个动作

切块：把文档剁成几百字一段。太长了检索不准，太短了答案会断。 向量化：把每一块压成一串数（向量）。意思相近的块，向量也相近。 检索：把问题也压成向量，跟所有块比相似度，取分最高的几块。

拼上下文：把这几块和问题一起塞进提示词，让模型照着答。 四步里第一步最容易被糊弄，也最影响结果。第 5.4 节会拿数把它量出来。

二、检索那一步在比什么

向量化之后，每块资料变成一个高维空间里的点。意思相近的点离得近。 检索就是算「问题那个点，离哪些块最近」。常用的算法叫余弦相似度——比的是两个向量的夹角，不是距离。 演示里用字面词频代替真正的 embedding。 这是个替身，得说清楚它差在哪：它抓得到「同一个词」，抓不到「同一个意思」。

所以演示里的「拖车」和「道路救援」算出来是 0.000——一个字都不重合。 真平台用 embedding 模型能抓住一部分这样的同义，但抓不全。

三、拼上下文那一步最容易坏

把三段资料塞进提示词，看似最简单，其实是故障最多的一步。 问题一，塞太多。 五段十段全塞进去，模型的注意力被稀释，反而容易抓错重点，token 也贵。 问题二，不标序号。 塞进去之后模型说「根据资料」，你没法核。 每段前面标 [1] [2] [3]，答复里带编号，才能追。

问题三，不说「没有就说没有」。 检索总会返回几段，哪怕是硬凑的。 提示词里不写这句，模型就会拿硬凑的那段硬答。 三条里第三条最致命。第 5.5 节那个案例，一半的功夫花在这句话上。

四、RAG 的四个优势

一、更新快。 改一份文档、重建索引，几分钟生效。不用碰模型。 二、有出处。 答复能指到第几段，人能核。这一条在企业里比准确率更要紧。 三、权限好管。 检索的时候按身份过滤，看不到的资料根本进不了上下文。

四、便宜。 不用训练，不用 GPU 集群，一年 token 钱不到两百块。 四条里第二条是 RAG 真正赢的地方。微调出来的模型答对了，你也说不出它对在哪。

五、它治不了的三种病

一、资料里没有的。 库里没写的东西，检索怎么都捞不出来。 二、要跨很多段才能答的。 「把去年所有投诉按类型分个类」——这不是检索能干的活， 这是数据库和代码节点的活。 三、要算的。 「两年半算哪一档」，料齐了还得推一步，这一步模型可能算错。

三种病对应三种补法：第一种补资料，第二种换节点（代码、数据库），第三种把算的那步写进代码。 RAG 不是万能药，它是「让模型看着资料说话」这一件事的工程化。别指望它顺手把别的事也干了。

六、一个最小实现长什么样

演示里三十行就能跑起来：切块十几行、检索五六行、拼上下文三行。 跑出来 top1 命中 4 / 4，top3 也是 4 / 4。 这个数看着漂亮，但别当真——只有五份文档、四个问题，样本太小。 真正该看的是另一列：检索把输入 token 省了 65%。三段一共 128 token，五份全文 362 token。 资料越多，这个比例越悬殊。

还有一处值得看：五份文档切出七块，最短一块只有 12 字。 那份文档最后被切成一个 60 字加一个 12 字的碎片——这就是切块切坏的典型样子。

七、动手 Demo：最小 RAG：切块、检索、拼上下文、生成

五份产品手册，切块、向量化、检索、拼上下文，四步都真跑。 四个问题，看 top1 和 top3 分别命中几个，再看省了多少 token。

blocks = []
for d in manual:
    blocks.extend(Q.chunk(d, size=60, overlap=10))   # ① 切块

hits = Q.retrieve(q, blocks, top=3)                  # ②③ 向量化 + 检索
ctx = Q.pack_context(hits, 3)                        # ④ 拼上下文

# 拼出来的样子：
# [1] 智能音箱 A1 支持 2.4G 与 5G 双频 Wi-Fi，首次配网需长按顶部按键…
# [2] A1 的固件每月推送一次，推送时间为凌晨 2 点到 4 点…
# [3] 蓝后在 App 里选择网络。不支持 5G 独立组网的路由器需先切到…

实跑输出：

--------------------------------------------------------------------
最小 RAG：切块、检索、拼上下文、生成
--------------------------------------------------------------------


  ① 先切块
  --------------------------------------------------------------------
  5 份文档，切成 7 块。
  最长块 60 字，最短块 12 字，平均 48.7 字。

  ② 检索：一个问题的三段召回
  --------------------------------------------------------------------
  1. 0.129  智能音箱 A1 支持 2.4G 与 5G 双频 Wi-Fi，首次配…
  2. 0.059  A1 的固件每月推送一次，推送时间为凌晨 2 点到 4 点。升级中…

  ③ 四道题：top1 与 top3
  --------------------------------------------------------------------

| 问题 | top1 分 | top1 | top3 |
|---|---:|---:|---:|
| 第一次配网怎么操作 | 0.129 | 中 | 中 |
| A1 保修多久 | 0.169 | 中 | 中 |
| 唤醒词最多几个字 | 0.281 | 中 | 中 |
| 音量超过 80% 低频被限制是故障吗 | 0.482 | 中 | 中 |

  top1 命中 4 / 4，top3 命中 4 / 4。

  ④ 上下文体积：塞三段 vs 塞全文
  --------------------------------------------------------------------
  三段召回拼起来 125 字，约 128 token。
  五份文档全文 325 字，约 362 token。
  检索省掉约 65% 的输入 token。资料越多，这个比例越悬殊。

  ⑤ 不检索会怎样
  --------------------------------------------------------------------
  ! 本沙箱没有模型，这一段只能用替换演示：把「检索到的那三段」换成「空」。
  问：第一次配网怎么操作
    有资料：长按顶部按键 3 秒
    没资料：模型会按「配网一般怎么做」的通用套路答——听起来对，但它不知道你家那台要长按 3 秒。
  ! RAG 的四个动作缺一不可：切块、向量化、检索、拼上下文。
  四步里最容易糊弄的是第一步——切得不好，后面三步全白搭。下一节量它。

①第一段报的是切块结果：五份文档切成七块，最长六十、最短十二、平均四十九。 最短那块只有十二字——那就是切坏的。 ②第二段是一个问题的召回。两块分数 0.129 和 0.059，第三块分数是零，被阈值滤掉了。 门槛留 0 的时候，毫不相干的块也会被捞上来。 ③四道题 top1 与 top3 都是 4 / 4。别当真：五份文档、四个问题，样本太小。 ④第四段是本节最实在的一个数：检索把输入 token 省了 65%。三段 128，全文 362。资料越多，比例越悬殊。 ⑤最后一段是替身声明：本沙箱没有 embedding 模型，用字面词频代替。它抓同一个词，抓不到同一个意思。

30 秒实验

1. 把你的一份文档按 300 字切一遍，数切出几块。切坏的（从句子中间断开的）有几块。
2. 给你现在的提示词加上「资料里没有就说没有」这一句，再看它还会不会硬答。
3. 数一下你的答复里有没有标 [1][2] 这样的出处。没有的话，人没法核。

常见误区

1. 「RAG 就是让模型变聪明。」它是让模型看着几段资料说话。资料里没有的还是答不了。
2. 「向量检索能理解同义词。」能抓一部分，抓不全。行业俗称、缩写、错别字照样翻车。
3. 「塞的资料越多越可靠。」塞太多会稀释注意力，还贵。三段是常用的起点。

原理清楚了，下一节看平台怎么把这四步做成按钮：上传、切分、向量化、召回。 还有一个能真跑的问题——分段长度到底定多少。

• ☐ （本篇完，下一篇 5.4 扣子知识库介绍）

相关笔记

• 大模型微调真的有必要吗：微调为什么不划算
• 为什么需要企业知识库：模型不知道公司昨天改了什么
• 15 数据库基础 · 索引
• 🐦 扣子开发 AI Agent · 索引