你的LLM在"胡说八道"，不是因为它笨，而是因为它"不知道"

ChatGPT刚出来时，大家最震撼的是它的"无所不知"。但很快，大家最失望的也是它的"胡说八道"——它不知道自己的知识截止日期，不知道最新的新闻，不知道你公司的内部文档，但它会"编"答案。而且编得很像真的。

RAG（Retrieval-Augmented Generation，检索增强生成）就是解决这个问题的。它的核心思想很简单：不要让LLM"凭记忆回答"，而是"先查资料，再回答"。

但RAG的完整技术链路远比"先检索再生成"复杂。以下是完整拆解。

RAG的五步技术链路

第一步：文档加载与解析

RAG的起点是"文档"。但文档的格式五花八门：PDF、Word、HTML、Markdown、图片、表格。你的RAG系统需要能处理所有这些格式。

关键挑战：

  • PDF的表格和图片提取极其困难
  • 扫描版PDF需要OCR
  • Word文档的层级结构（标题、段落、列表）需要保留
  • 代码文件需要保持格式

金句：RAG系统质量的第一个瓶颈不是LLM，不是向量数据库，而是文档解析。垃圾进，垃圾出。

第二步：文本分块（Chunking）

LLM的上下文窗口虽然已经从4K扩展到128K甚至1M tokens，但RAG仍然需要分块。原因有三：

  1. 检索精度：小块更精准，大块更全面。需要平衡。
  2. 成本：把整个文档塞进Prompt，Token消耗巨大。
  3. 相关性：用户的问题通常只跟文档的一小部分相关。

关键设计决策：

  • chunk_size：每个块的大小（通常500-1500 tokens）
  • chunk_overlap：相邻块的重叠部分（通常10-20%）
  • 分块策略：按字符、按句子、按段落、按语义边界

金句：Chunking是RAG系统中最不性感但最重要的环节。你的检索质量上限，在Chunking阶段就已经决定了。

第三步：向量化（Embedding）

把文本块转换成向量。这是RAG的核心一环——文本的语义被压缩成768-3072维的数学向量。

关键设计决策：

  • 选择什么Embedding模型（OpenAI、BGE、E5、Cohere）
  • 向量的维度（高维更准但更慢，低维更快但更不准）
  • 是否需要多语言支持

金句：Embedding模型的选择，决定了你的RAG系统能"理解"多深。

第四步：向量检索

给定用户查询，在向量数据库中找到最相关的K个文本块。这是RAG系统的"心脏"。

关键设计决策：

  • 向量数据库选型（Milvus、Pinecone、Qdrant等）
  • 索引算法（HNSW、IVF、PQ）
  • 检索参数（Top-K、efSearch、相似度度量）
  • 是否需要混合检索（向量+关键词）

金句：向量检索决定了RAG系统的"天花板"——如果检索不到正确文档，LLM再强也没用。

第五步：生成与引用

把检索到的文本块作为上下文，和用户问题一起送给LLM，生成最终答案。

关键设计决策：

  • Prompt模板设计（如何组织上下文、如何要求LLM引用来源）
  • 上下文窗口分配（多少给检索结果，多少给对话历史，多少给系统指令）
  • Reranker（对检索结果做精排后再送入LLM）

金句：RAG的最终答案质量 = 检索质量 x LLM的生成能力。检索质量是乘数，检索为0，答案为0。

RAG为什么有效？三个关键原因

  1. 知识外挂：LLM的参数是"长期记忆"，RAG的检索是"外部硬盘"。外部硬盘可以随时更新，不用重新训练。
  2. 幻觉抑制：LLM看到具体文档后，生成的内容被"锚定"在事实上，幻觉大幅减少。
  3. 可解释性：RAG可以引用来源——“这个答案来自第X页的第Y段”。这是纯LLM做不到的。

金句：RAG不是让LLM更聪明，而是让LLM更诚实。它强迫LLM"先查资料，再说话"。

RAG的三种基本架构

  1. Naive RAG：检索→生成。最简单的架构，也是大多数Demo的实现方式。
  2. Advanced RAG：检索→Rerank→生成。在检索和生成之间插入精排步骤，提升准确率。
  3. Agentic RAG：Agent决定"什么时候检索、检索什么、怎么生成"。最复杂但最灵活。

金句：Naive RAG是"先搜再说"，Advanced RAG是"搜完精选再说"，Agentic RAG是"想清楚再搜再说"。