RAG 学习笔记：文档切分、向量检索和回答兜底

写在前面

RAG 是我补 AI 应用开发时重点学习的方向。它解决的问题很直接：大模型本身不知道我们的私有资料，所以需要先从知识库里检索相关内容，再让模型基于这些内容回答。

这篇文章不写“企业级架构”，只记录我现在对 RAG 的理解，以及做小项目时需要注意的几个点。

RAG 的基本流程

一个简化版 RAG 流程可以分成四步：

文档整理
  -> 文本切分
  -> 向量化并存储
  -> 根据问题检索相关片段
  -> 拼接上下文让模型回答

它的核心不是“把文档塞给模型”，而是让模型在回答前先拿到更相关的资料。

文档切分

文档不能直接整篇塞进向量库，通常要切成多个片段。

切分太大，会导致一个片段里混入太多无关信息；切分太小，又可能丢失上下文。

我目前会先用比较保守的方式：

• 每段控制在几百字左右
• 保留一定 overlap
• 尽量按标题、段落、列表边界切分
• 不把完全无关的内容切到同一个片段里

切分质量会直接影响后面的检索效果。

向量检索

用户提出问题后，需要把问题转成向量，再到向量库里找相似片段。

常见参数有：

• topK：返回几个片段
• similarityThreshold：相似度阈值
• embedding 模型：决定文本向量质量

如果 topK 太小，可能漏掉有用内容；如果太大，又会把无关内容塞进上下文，影响回答质量。

所以 RAG 项目里，检索参数需要根据数据集实际调试，不是固定一个值就结束。

Prompt 拼接

检索到片段后，需要把片段和用户问题一起放到 Prompt 里。

我比较喜欢这种结构：

请只根据以下资料回答问题。
如果资料中没有答案，请说明“资料中没有找到明确答案”。

资料：
{context}

问题：
{question}

这样可以尽量减少模型乱编。

回答兜底

RAG 最大的问题之一是：检索不到相关资料时，模型可能仍然编一个答案。

所以我会考虑这些兜底：

• 检索结果为空时，不调用模型，直接提示没有找到资料
• 相似度太低时，提示资料不足
• 回答里保留引用片段，方便用户判断来源
• 对关键问题避免让模型自由发挥

这部分很重要，因为知识库问答最怕看起来很流畅，但其实答错了。

和普通搜索的区别

RAG 不是简单搜索。普通搜索返回文档列表，RAG 是检索片段后再组织成自然语言答案。

它的优点是用户体验更好，但风险是模型可能加工过度。所以我更倾向于在回答里保留依据，让用户知道答案来自哪里。

我在项目里会怎么用

如果做一个课程资料问答或简历问答项目，我会这样拆：

1. 上传文档
2. 文档解析成纯文本
3. 按段落切分
4. 向量化存储
5. 用户提问后检索相关片段
6. 拼接上下文调用模型
7. 返回答案和来源

这个流程看起来简单，但每一步都有细节。比如 PDF 解析质量、标题层级、表格内容、片段长度，都会影响效果。

小结

RAG 对我来说是 AI 应用开发里比较实用的能力。它不是单纯调模型接口，而是结合了文档处理、向量检索、Prompt 设计和异常兜底。

我现在还在通过项目继续练习这部分，重点不是把概念写得多深，而是能把一个知识库问答流程从数据进入到答案输出讲清楚。