RAG 听起来像一套很重的系统，其实最小版本只有四步：把文档分成小段、为每段生成向量、找出和问题最接近的几段、把它们和问题一起交给模型。理解这条主线以后，向量数据库、重排模型和各种框架都只是可以按需替换的零件。
先把流程画成一条直线
练手时可以只选十几篇 Markdown 文档。启动阶段读取文件，切成段落，调用嵌入模型后把向量写入一个 JSON 文件。查询时把用户问题也转成向量，用余弦相似度找前三段。数据量不大时，直接在内存里遍历足够快，也更容易看懂。
文档 → 切片 → embedding → 本地 JSON
问题 → embedding → 相似度排序 → 前 3 段
问题 + 前 3 段 → 大模型 → 带引用的回答这个版本当然不适合几十万条资料，但非常适合验证“这些资料能不能回答目标问题”。如果内容本身不合适，先上数据库也不会变好。
切片先朴素一点
最简单的做法是按标题和段落切，每段控制在几百字，并保留少量重叠。不要一开始就追求精确 token 或复杂语义分段。真正重要的是不要把标题和正文拆散，也不要让一个切片混入多个完全无关的主题。
我会为每段保留 source、heading 和 text。这些元数据既能放进提示词，也能在界面上显示“回答来自哪篇文档”。引用可见以后，用户更容易判断答案是否可靠。
检索到内容后，别一股脑塞进去
相似度最高不代表一定有用。一个常见问题是三段结果来自同一篇文章、内容互相重复。可以先做一个很小的去重：相同来源最多取两段，文本高度相似的只留一段。然后给上下文加清楚的编号。
请只根据“参考资料”回答。
如果资料不足，明确说明不知道，不要补写事实。
回答末尾列出使用过的资料编号。这类约束不能完全消除幻觉，但会让输出更容易核对。对内部文档问答来说，“资料里没有”往往比一段流畅的猜测更有价值。
准备十个真实问题，比盯着演示更重要
RAG 很容易做出一个漂亮演示，却在真实提问时失败。建议从目标用户那里收集十到二十个问题，记录期望找到的资料，再分别检查检索结果和最终回答。检索错了就调整切片或查询，检索对但回答错了再调整提示词。
当本地 JSON 开始变慢、内容需要频繁增量更新，或者权限隔离变复杂时，再引入向量数据库和框架。那时每一个新增组件都有明确理由，维护起来也会轻松很多。