RAG 的原理、流程与落地要点
引言
检索增强生成（Retrieval Augmented Generation，简称 RAG）已经成了 AIGC 文本应用里最常见的一条路。它的思路不复杂：先从外部知识库里找资料，再让大语言模型（LLM）基于这些资料回答。对 AI 产品经理来说，RAG 不只是一个名词，更多是做知识型产品时绕不开的底层方案。理解它怎么工作、哪里容易出问题，基本决定了你后面做出来的东西能不能用。
RAG 的核心价值
简单说，RAG 就是把外部知识交给模型用，而不是指望模型'自己记得'。它和直接把一堆文档塞给模型不一样，RAG 更强调先检索，再生成。
它的价值主要在这几件事上：
- 把回答拉回可控范围：检索出来什么，模型就主要基于什么回答。这样能少一点幻觉，答案也更容易对齐业务口径。
- 补上模型不知道的新内容：预训练模型对垂直领域和最新信息总有缺口，RAG 可以把这些内容接进来，不用频繁微调。
- 省上下文窗口：长文档全塞进 prompt，贵，而且容易把模型注意力冲散。RAG 只取相关片段，成本和延迟都会更好看。
RAG 的实现流程
一个比较完整的 RAG 系统，通常会拆成两块：先建知识库，再做问答。真正麻烦的地方也在这里，很多效果问题不是模型本身，而是前面的数据和检索链路没处理好。
一、构建知识库
知识库这部分通常包含四步：内容解析、内容分片、Embedding 向量化、向量存储。
1. 内容解析
先把 txt、html、word、excel、pdf、markdown 这些格式提取成可处理的文本。复杂一点的文档，尤其是表格、公式、代码块，不能只图省事直接扁平化，不然结构信息丢得很快。像 PyMuPDF、Unstructured、LangChain Loaders 这类工具都能用，但实际效果还是得看文档类型。PDF 尤其麻烦，多栏排版、页眉页脚、扫描件，都会让解析结果变脏，所以清洗这一步通常比看上去更重要。
2. 内容分片
长文档不切片，后面检索基本没法做。常见做法有几种：
- 固定长度分片：按字符数或 token 数切，简单直接，但有可能把一句完整的话切断。一般会加 overlap，留 10% 到 20% 的重叠，避免关键信息刚好被切没了。
- 语义分片：按段落、标题、章节边界切，连贯性更好，适合结构比较清楚的文档。
- 递归分片：先按大结构切，再往下细分，层级感保得更完整。
分片大小没有绝对标准，200-500 tokens 是个常见区间，但还是要看文档类型。切太大，检索会带进很多噪音；切太小，上下文又容易断。
3. Embedding 向量化
Embedding 的作用，是把文本映射成向量，后面才能做相似度检索。常见模型有 OpenAI text-embedding-ada-002、BGE-M3、Sentence-Transformers 等。维度更高通常意味着表达能力更强，但计算和存储开销也会跟着涨。比如 OpenAI 的这个模型是 1536 维。
模型选型别只看'效果好不好'，语言覆盖、领域适配、推理速度都得一起看。中文场景里，有些英文表现不错的模型并不一定适合直接上线。
4. 向量存储
向量会被存进向量数据库，比如 pgvector、Elasticsearch、Chroma、Milvus、Weaviate 等。这里最好把元数据也一起存进去，比如文档 ID、章节索引、日期、作者。后面做过滤、排序、审计都能省很多事。
索引类型也不是随便选的。HNSW 更偏高精度、低延迟，IVF 更适合大规模数据。索引不是建完就不管了，数据一多、分布一变，定期重建或者重调参数都很有必要。
二、问答流程
用户提问后，RAG 一般会走下面这条链路：
- 问题 Embedding：先把用户问题转成向量。问题如果太模糊，通常要先做意图识别，或者改写一下，不然后面的检索会很飘。
- 检索相关知识：去向量库里找相似片段。常见会设一个相似度阈值，比如 0.7，再取 Top 5 之类的结果。实际项目里，混合检索往往比纯向量检索稳一些。
- 封装 Prompt：把检索结果和用户问题拼到 prompt 里，再交给 LLM。这里要把角色、任务、引用要求写清楚，不然模型很容易自由发挥。