几千页的产品文档，怎么让 AI 帮我们查？
全发过去？发不下——上下文窗口有上限。让模型"背"下来？那是微调，又贵又难更新，文档改一个字都得重来。
还有一个办法——不背，去查。答题之前，先把相关的几页翻出来摆在桌上，然后照着答题。这就是开卷考试。
正规叫法是 RAG（检索增强生成）。这篇把它的全流程拆开：书是怎么编上索引的，考场上书是怎么翻的，坑都在哪。
一、总览：两步走
开卷考试要做两件事：考前把书编好索引，考场上按题翻书。RAG 也是这两步。
建库是"离线"的——做一遍就够，慢慢来；答题是"在线"的——每次提问都要跑一遍，要快。
二、建库：把书编上号
先看建库。这一步做一次，之后每次答题都受益。
原始文档先过一道切块：一篇长文塞不进任何一张"桌子"，得拆成一段段小纸片。怎么切有讲究——按标题切、按段落切、按固定字数切；每块多大、块与块之间要不要留点重叠，都是要调的参数。
然后向量化：每块纸片过一遍 embedding 模型，变成一串数字——像在"语义地图"上标了个坐标。意思相近的段落，坐标也挨得近。这一步，是"查意"的本钱。
最后入库：坐标和原文绑在一起存好——坐标管"找"，原文管"用"。
三、答题：按题翻书
问题进来，也先过一遍 embedding，落进同一张地图；然后找离它最近的几个邻居，把对应的原文取出来——这就是检索，通常取前 3 到 10 块。
取出来的块，和问题一起拼进提示词，交给模型。模型看到的不是整座图书馆，只是桌上这几页——但它答得踏实，因为材料就在眼前。
四、每一步都有坑
流程不复杂，但每一步都有坑：
- 切得不好——一段完整的意思被拦腰切断，谁也读不懂；
- 找得不准——你问"退款"，文档里写的是"退货"，对不上；
- 塞得太多——翻出一堆似是而非的段落，把真正有用的淹没，模型反而晕了。
还有个常被忽略的事实：RAG 治不好幻觉。有审计发现，法律领域的 RAG 系统，幻觉率依然两位数——检索只是把材料放到桌上，答卷还得靠模型自己，读跑偏的照样跑偏。
五、找的两种思路
上一节说"找得不准"是个坑。那"找"这个环节，到底靠什么找？两种思路：
- 查字——拿关键词对字面，对上了算命中（grep 那一路）；
- 查意——按语义相似度找，"能折的手机"能对上"可折叠的 iPhone"（向量检索那一路）。
口诀很直白：知道想要什么字，用查字；知道想要什么意思、但不知道原文怎么写，用查意。
找版本号、找配置、找错误码——查字又快又准；"我们没有带娃上班的政策吗"这种问法——只能靠查意。谁也不是万能的，场景说了算。
有趣的是最近的实验：把 grep 放进几套真实的 Agent 环境里和向量检索对照——多数组合里，grep 的准确率反而更高。作者自己补了句公道话：环境的影响，比检索方式的影响还大。
于是这两年，中小规模的知识库开始流行一种朴素做法：直接放文件里。文档写成 markdown 放进 git 仓库，agent 自己翻——目录树就是索引，README 就是导览图，git 顺手把版本管理也解决了。
有团队把 94 篇文档的知识库，从 RAG 换成了纯文件检索：单问题耗时从 48 秒降到 17 秒，答案从"每次可能不一样"变成"每次一样"，跨文档关系类的问题反而能答了——因为 agent 会顺着文件之间的引用一路读过去，而不是在相似度碎片里拼图。
当然，前提是对得上：几百到几千页、结构化、自己人写自己人用——文件就够了。大到几十万条、来源杂乱、还要语义泛化的时候，向量检索仍是主路。不是推翻谁，是各回各的赛道。
开卷考试，考的从来不是记性，是找资料的本事。
RAG 也一样——八成功夫在"找"：找得快，是索引的事；找得准，是切块和检索的事。剩下的，才轮到模型作答。