一、为什么需要 RAG：大模型的三块短板
直接把问题丢给大模型，很快会撞上三堵墙：知识截止（训练数据有截止日期，问不了昨天的事）、幻觉（不知道也硬编，语气还特别自信）、私有数据进不去（公司内部文档模型从没学过）。微调（Fine-tuning）能补一部分，但把知识「烤」进权重成本高、更新慢、难溯源，还容易把模型「烤糊」（灾难性遗忘）。RAG 提供了另一条路：不动模型，改外挂知识库——回答问题前先去你的文档里检索相关材料，把它塞进 prompt，让模型「开卷考试」。既便宜、又能实时更新、还能给出引用来源，是企业落地大模型性价比最高的第一招。
信源：Lewis et al.《Retrieval-Augmented Generation》（NeurIPS 2020）、LangChain／LlamaIndex／Haystack 官方文档、向量检索与 ANN 论文（HNSW、ScaNN）、OpenAI／Anthropic 检索增强最佳实践（2024-2026）。
二、一条 RAG 流水线的六个环节
- 文档加载与清洗：PDF／Word／网页／数据库，把杂乱文本转成干净段落，去掉页眉页脚噪声。
- 切分（Chunking）：把长文切成适合检索的小块。切太大→检索噪声多，切太小→语义被割裂。实践中常用 300~800 token + 重叠窗口，并尽量按语义／标题边界切。
- 向量化（Embedding）：用嵌入模型把每个 chunk 编码成向量，存进向量数据库。
- 检索（Retrieval）：把用户问题也向量化，找出最相似的 Top-K 个 chunk。进阶做法是「混合检索」——向量语义检索 + BM25 关键词检索互补。
- 重排（Rerank）：初筛召回的多是「大致相关」，用 Cross-Encoder 重排模型精排出真正最相关的几条，大幅提升答案质量。
- 生成（Generation）：把问题 + 精选上下文拼进 prompt 交给大模型，要求「只根据给定材料回答并标注来源」。
三、生产环境里真正的难点（demo 与上线的差距）
一个残酷经验：RAG 的 demo 一下午就能跑通，但从 demo 到生产可用，80% 的精力都花在「检索质量」上，而不是模型本身。检索不准，再强的生成模型也只是把错误材料优雅地复述一遍。
1. 切分策略决定上限
表格、代码、FAQ、长文档要区别对待；把一张表格劈成三块，检索必然答非所问。结构化数据往往要用父文档召回、语义切分等特殊策略。
2. 查询改写
用户的口语提问（「这个能报销不」）和文档语言（「费用报销政策」）向量对不上。用查询扩展、HyDE（先让模型假设一个答案再去检索）、多查询路由来弥合「词」与「意」的鸿沟。
3. 上下文窗口 ≠ 越多越好
把 Top-50 全塞进长上下文，不仅贵，还会因「中间信息被忽略（lost in the middle）」降低质量。精调 Top-K + 重排，比堆数量更有效。
4. 评估体系
上线前必须建评测集：检索侧看命中率／MRR，生成侧看忠实度（是否只依据材料）、答案相关性、引用准确性。RAGAS／TruLens 这类框架可以把这些指标自动化，否则你永远在盲调。
四、2026 年的演进：GraphRAG、Agentic RAG 与长上下文之争
RAG 本身也在快速进化。GraphRAG 把语料抽取成知识图谱，擅长回答「跨多文档的关联性全局问题」，代价是索引构建昂贵；Agentic RAG 让模型自主决定「要不要检索、检索几轮、查哪个源」，把一次性检索变成多步推理循环，复杂问答能力更强；同时，百万级 token 长上下文的出现引发了一波「还要不要 RAG」的争论——但主流结论是：长上下文解决了「塞得下」，却没解决「成本高、注意力稀释、私有数据安全与溯源」，RAG 与长上下文更多是协同而非替代。
五、什么时候不该用 RAG
- 问题靠「常识/推理」而非「特定资料」——直接问模型即可，硬加检索反而引入噪声。
- 知识库极小且稳定——直接塞进 prompt（或做微调）更省事。
- 对延迟极度敏感的实时场景——多一次检索 + 重排会拉高 P99 延迟。
一句话收尾：RAG 的价值不在「用了向量数据库」，而在「把大模型的生成能力锚定在可核查的真实数据上」。决定成败的从来不是模型，而是检索质量、切分策略与评估闭环——这三样做扎实，普通模型也能给你可靠答案；这三样含糊，最前沿的大模型也照样一本正经地胡说。
六、一个可直接抄的「最小生产级」RAG 架构清单
把前文原则落成一张能开工的清单：
- 嵌入模型：中文场景优先选在中文语料上表现好的嵌入（如 BGE、text-embedding 系列），别默认用英文最优的模型——语种不匹配会让检索质量断崖下跌。
- 向量库：小规模起步用 pgvector（复用现有 Postgres，运维最省），量大再上千问 Milvus/Qdrant；不必一上来就追最新。
- 混合检索：向量（语义）+ BM25（关键词）双路召回后融合（RRF），对专有名词、型号、法条编号这类「必须字面命中」的查询提升明显。
- 必加重排：初召回 Top-20，用重排模型精排到 Top-3~5 再进 prompt，性价比极高的一步。
- 强制引用 + 拒答：prompt 里要求「仅依据给定上下文作答，找不到就明说不知道」，显著压幻觉。
- 建评测集：上线前用 RAGAS/自建 golden set 固化「检索命中率 + 忠实度」两个指标，之后每次改切分/模型都跑一遍，避免盲调。
七、成本与延迟账本：哪些钱花得值
RAG 的隐性成本常被低估。索引侧是一次性 + 增量：文档更新要重嵌、重建，语料越大越贵，务必只做「变化部分」的增量索引；查询侧每次请求都含「嵌入一次 + 检索 + 重排一次 + 生成」，重排模型和 embedding 都会加延迟。经验上：重排带来的答案质量提升通常值回那点延迟，而盲目扩大 Top-K、堆多轮 Agentic 检索则容易让 P99 失控。真正省钱的大头是「用更小更快的模型做检索/重排，只把最后的生成交给大模型」——分层用模型，而不是所有环节都上最贵的。把评测集和这两本账建起来，RAG 就从「玄学调参」变成了可运营的工程。
八、RAG 常见翻车现场与对症解法
把一线最常遇到的四类「答非所问」拆开，基本都能定位到具体环节：
- 「明明文档里有，却没检索到」：多半是切分把答案劈散、或查询与文档用词不匹配。解法是语义切分 + 混合检索（关键词兜底）+ 查询改写（同义扩展/HyDE）。
- 「检索到了但答错/编造」：上下文里混入了相互矛盾的旧版本，或模型无视材料自由发挥。解法是加重排把最相关的顶到前面、prompt 强制「只用给定材料 + 拒答」、并对文档做时效/版本清洗。
- 「回答很泛，没用到具体条款」：Top-K 太小或 chunk 太大导致关键句被稀释。解法是调 chunk 粒度、适当增大召回再用重排收窄。
- 「引用张冠李戴」：让模型生成引用却没把来源 ID 随 chunk 一起传入。解法是给每个 chunk 带可寻址的元数据（文档名/段落号），要求逐句标注。
这些坑的共同点是：表面像「模型不行」，根子却在「检索与数据工程」。所以判断一个 RAG 项目值不值得投入，别看它用了多大的模型，要看它有没有把语料清洗、切分策略、混合检索、重排和评测集这套「无聊但关键」的脏活做扎实——把大模型换成中等模型但检索做对，效果往往反超把检索做烂却堆最贵模型。这也是 2026 年 RAG 落地最反直觉、却最值钱的一条经验。
