周三下午，一个工程师对着屏幕发呆。他的大模型把"公司创始人"答成了个不存在的人名——典型的幻觉现场。这不是模型不够聪明，是它根本没见过你硬盘里的那些PDF。
RAG（检索增强生成）就是来解决这个问题的。它不重新训练模型，而是让模型在回答前先"翻资料"。本文拆解RAG的完整工作流，以及我踩过的几个坑。
传统LLM的困局
你问模型一个问题，它只从训练记忆里找答案。三个麻烦随之而来：知识会过期，答案可能编造，完全碰不了你的内部文档。RAG的做法是：先把你的文档切成碎片、转成向量存进数据库；用户提问时，系统找到最相关的碎片，塞进提示词里再让模型作答。答案因此更准、有依据、还能针对特定领域定制。
为什么非得用RAG？
大模型很强，但有硬边界。幻觉——模型会一本正经地编造事实，比如虚构一个创始人名字。知识截止——它不知道你上周写的技术文档、刚更新的政策、私有代码库。RAG把"模型知道什么"和"你能提供什么"解耦了。
核心架构：8个组件串成一条流水线
1. 原始文档（TXT、PDF、Markdown、网页、代码库）
2. 分块系统——整本书直接嵌入效果差，切成小段落
3. 嵌入模型——每段文字变成向量，比如"RAG使用检索"变成[0.12, -0.77, 0.48...]
4. 向量数据库（Pinecone、Weaviate、Qdrant、Chroma、FAISS）
5. 检索器
6. 提示词构造器
7. 大语言模型
8. 最终答案
用户提问后的完整路径
问题先被转成向量，数据库做相似度搜索捞出最相关的块，这些块被格式化成"上下文"塞进提示词，模型基于这些 grounding 生成回答。整个流程的关键在于：检索到的片段质量决定了天花板，模型只是负责把片段组织成人话。
实施中的常见陷阱
分块策略比想象中重要。切太大，噪声多；切太小，语义断裂。嵌入模型的选择直接影响召回——同样一句话，不同模型生成的向量可能指向完全不同的邻居。向量数据库看着都差不多，但过滤功能、混合搜索、成本结构差异很大。
RAG不是万能药。它解决的是"模型没见过但你能提供"的场景，如果问题本身需要推理而非检索，或者文档质量极差，效果会打折扣。先想清楚你的知识边界在哪里，再决定要不要搭这套系统。
热门跟贴