RAG原理解析：让AI用你自己的数据回答问题

通用大语言模型能写诗、能编程，却回答不了"我们公司的退款政策是什么"这类问题。原因很简单：它没见过你的内部文档。RAG（Retrieval-Augmented Generation，检索增强生成）正是为解决这个问题而生的技术架构。

为什么需要RAG？

大语言模型有三个先天短板，恰好构成了RAG的存在理由。

私有数据盲区。 通用模型不知道你的公司内部政策、产品手册或个人文件。你需要一种机制把这些信息喂给它。

知识过期。 训练数据有截止日期，模型无法自动获知最新变更。今天更新的定价策略，不在模型的"记忆"里。RAG 能从已更新的知识源中检索最新信息，前提是源头已同步更新并被正确索引。

幻觉问题。 模型会生成听起来合理但完全错误的答案。提供相关源材料有助于降低这种风险，但 RAG 并不能消除幻觉——模型仍可能误解检索到的内容或生成无依据的论断。

至于微调（Fine-tuning），它调整的是模型行为，并非让应用获取频繁变动事实信息的常规手段。如果你的核心需求是回答不断更新的文档问题，RAG 通常是更务实的起点。

RAG的工作流程

一个典型的RAG系统分为两个阶段：数据准备和问答生成。

数据准备阶段

提取文本。 从PDF、文档、产品手册、网站内容等来源中抽取可读文字。扫描版PDF可能需要OCR处理。

切分文本块（Chunking）。 为什么要切分？因为检索较小的语义单元比把整个文档塞给模型更有效。比如退款政策可以被切成三个独立的块：退款时限、排除条件、处理周期。块太小会丢失上下文，块太大则混入无关信息。没有万能的最优块大小，取决于文档特性、检索方式和具体应用。

生成Embedding。 Embedding模型将文本转换为数值向量。"退款期限是多久"和"我有多少天可以退货"措辞不同，但向量空间中距离很近——这就是语义检索的基础。

存储向量与原文。 向量数据库或支持向量搜索的数据库都可以胜任，如PostgreSQL配合pgvector、MongoDB Vector Search、Pinecone、Weaviate、Qdrant等。选型取决于现有基础设施、数据规模和过滤需求。关键是：只存向量不够，必须能取回对应的源文本。

问答生成阶段

用户提问"20天后还能退款吗？"，系统执行以下步骤：

1. 将问题转为查询向量
2. 在索引中搜索相关文本块（检索到"购买后30天内可申请退款"）
3. 把检索结果和问题一起构建成提示词发送给LLM
4. LLM基于提供的上下文生成回答

系统提示中会明确要求："仅使用提供的上下文回答，如果上下文信息不足，请说明不知道。"模型不需要在训练时记住你的退款政策——应用在查询时提供了相关信息。

检索的两种基本范式。 上述流程中的"搜索相关文本块"通常有两种实现路径。一是稠密检索（dense retrieval），即对查询和文档块分别编码为向量，通过近似最近邻（ANN）算法在向量库中快速找到最相似的若干块，代表算法有HNSW、IVF等。二是稀疏检索（sparse retrieval），如BM25，它基于词频和逆文档频率打分，对精确匹配、专有名词和数字最敏感。实际系统常把两者融合，称为混合检索（hybrid search），先用两路召回各自取Top-K，再用RRF等融合策略合并结果。此外，重排序（reranking）是提升精度的关键手段：先用快速的检索器召回几十个候选，再用一个更强大的交叉编码器模型逐一评估query与文档的相关性，保留前若干条。检索这一环的召回率和准确率往往对最终答案质量的影响大于LLM本身的选择。

RAG架构全景

完整流程可以简化为一条流水线：

文档/PDF/网站内容 → 文本提取 → 切分 → Embedding → 向量数据库/索引 → 用户查询 → 查询向量化 → 检索相关文本块 → 构建上下文+问题 → LLM → 有据可依的回答

文档摄入通常在用户提问之前完成，应用不需要为每个请求重新处理所有文档。文档变更时可以更新对应的索引条目。

常见误解：RAG必须用向量数据库？

不是。RAG是一种架构模式，不是特定的数据库技术。

可选的检索方式包括：向量搜索（基于语义相似度）、关键词搜索（基于文本匹配）、混合搜索（结合两者优势）、数据库查询（SQL等结构化检索）。

用户问"上个月总营收是多少"，SQL查询比向量搜索更合适。用户问"客户反馈中最常见的抱怨是什么"，语义检索配合分析则更有优势。根据问题选择检索方式，而不是因为某种技术流行就用它。

理解混合检索的价值，可以把它类比为图书馆的检索系统：向量搜索像"根据你描述的大意找相似主题的书"，关键词搜索像"按标题或ISBN精确找到某本书"。用户问"GPT-4的上下文窗口是多少"时，关键词匹配能精准命中写有"GPT-4"和"上下文窗口"的段落，而纯向量搜索可能返回语义相近但讨论的是Claude或Gemini的段落。反之，用户问"模型能记住多长的对话"时，原文可能没有出现"上下文窗口"这些字眼，只有向量检索才能跨越字面差异找到答案。混合检索正是为了兼顾这两种情形。

RAG vs 微调：解决不同问题

需求	RAG	微调
访问变化的文档	适合	非其固有优势
查询时使用私有知识	适合	知识可能无法可靠存储或回忆
定制回复风格	通过提示词可实现	有助于行为一致性
提供来源引用	可在检索管道中设计	不天然提供来源引用
更新事实信息	更新知识源或索引	可能需要额外训练

两者并非互斥。系统可以同时使用检索和微调后的模型。

为什么微调不适合承载频繁变动的事实。 微调通过在有标注或特定任务的样本上继续训练，会让模型的权重参数发生改变，从而影响其语气、格式、推理风格甚至领域用语习惯。但事实性知识在数十亿参数中是高度分布式存储的，既难以精确注入单条新事实，也难以在需要时可靠地"调用"出来——这被称为知识注入的不确定性。因此当退款政策、产品价格这类事实每周甚至每天变化时，每次都要重新微调既昂贵又迟缓。更务实的做法是：用微调塑造"怎么回答"（语气、结构、领域表达），用RAG解决"依据什么回答"（具体事实、可追溯来源）。两者组合，常能取得单靠任一方达不到的效果。

六个常见陷阱

构建基础RAG管道相对简单，但要让它持续输出准确答案就难得多。

切分不当。 如果切分把陈述和解释分开，检索到的文本可能缺乏足够上下文。对策：用代表性问句测试不同切分策略。

检索不相关。 系统可能返回听起来相似但不回答问题的内容。对策：评估检索质量，尝试混合搜索和重排序。

信息缺失。 相关内容未被索引或检索失败，LLM没有足够证据。对策：验证文档摄入流程，用已知答案的问题测试。

幻觉回答。 即使有相关文本，模型仍可能引入无依据的论断。对策：使用明确的 grounding 指令，要求答案对照来源评估。

信息过时。 文档已变更但索引未更新。对策：实施文档版本管理和更新工作流。

忽视权限控制。 系统可能检索到当前用户不应访问的机密信息。对策：在检索层实施授权。仅靠提示词指令不足以构成安全边界。

实际应用场景

RAG适用于任何需要基于外部信息集合回答问题的场景：客服助手从产品文档和故障排查指南中提取答案；内部助手帮员工在经批准的公司文档中查找信息；文档分析工具回答关于报告、合同、论文的问题；教育应用从课程材料中检索相关段落并生成解释；开发者文档助手使用API参考和工程指南回答问题。

每个场景对准确性、权限、时效性和评估有不同要求。RAG是有用的构建块，但不是完整的解决方案。

最值得记住的一点

RAG不会魔法般地让LLM变准确。它的效果取决于多个相互关联的组件：源文档质量、文本提取正确性、切分方式、Embedding质量、检索策略、上下文相关性、模型使用上下文的能力，以及围绕应用的评估和安全控制。

检索失败，再强的LLM也无法基于它从未收到的信息来可靠回答。检索成功但模型误读证据，最终答案依然可能出错。RAG的质量取决于整条管道，而非仅仅是LLM或向量数据库。

对于想学习AI工程的开发者来说，构建一个小型RAG应用是理解LLM、Embedding、数据库和后端系统如何协同工作的绝佳方式。从一个小项目开始，测试它回答真实文档问题的表现，再逐步引入更多组件。

背景补充

Embedding（嵌入）的工作原理。 Embedding模型通常是深度神经网络，它把任意长度的文本映射到一个固定维度的稠密向量空间（如768维或1536维）。训练目标是让语义相近的文本在向量空间中彼此靠近、语义无关的文本彼此远离。衡量两个向量接近程度的常用指标是余弦相似度（cosine similarity），它计算两向量夹角的余弦值，取值范围为-1到1，越接近1表示语义越相似。正因为Embedding捕捉的是语义而非字面，所以"退款期限是多久"和"我有多少天可以退货"即使没有一个共同的关键词，也能被检索系统判定为高度相关。这也是RAG能够超越传统关键词搜索的核心原因，但Embedding模型有其知识边界，对专业术语、多语言混排或极短文本的表现可能不稳定，选型时需用真实业务语料评估。