目录

你已经理解了 什么是 RAG。但真正动手去搭建时，很多人会撞上一堵墙："大致能用，但关键的答案却偏了。" 原因几乎总是相同的——它依然是 "naive RAG"：把文档随意切碎，再做一次普通的向量检索。

2026 年的实用 RAG 已经明显走出了这个阶段。关键在于一条多阶段流水线："聪明的 chunking → 合适的 embedding → 混合检索（关键词 + 向量）→ reranking。" 作为第 030 篇文章的实现篇续篇，本文讲解每个阶段的具体做法、向量 DB 的选择（Chroma/pgvector/Qdrant/Pinecone/Weaviate/Milvus）、框架，甚至包括"在 1M-token 时代我们还需要 RAG 吗？"——这些更进阶实现的要点。

RAG · IMPLEMENTATION

现代 RAG 的 5 个阶段

— 从 naive RAG 到在生产环境可用的 RAG

① Chunk
聪明地切分
② Embed
用 embedding 向量化
③ Store
存入向量 DB
④ Retrieve
混合检索
⑤ Rerank
重排出最优

精度提升最大的两点：混合检索（BM25 + 向量）与 reranking。
仅仅加上这两项，就能大幅修复 naive RAG "答案偏了" 的问题。

* 工具名称、方法与基准数字基于官方来源及多家技术媒体（截至 2026 年）。该领域演进很快，最优选项会发生变化。基准数字来自各来源的报告，会随数据与条件而变化。请先用你自己的数据（见下文）评估再做选择。

1. 回顾：naive RAG 的局限

最小化的 RAG 就是 "切分文档 → 用 embedding 向量化 → 存入向量 DB → 把问题向量化并取出最近的若干 chunk → 交给 LLM 来回答。" 这就是 RAG 的基础。但这种 "naive RAG" 有典型的弱点。

  • 草率的 chunk：从句子中间切断，破坏了语义。
  • 仅向量检索：对产品名、型号这类精确词很弱（会抓取/漏掉那些语义相近但词面不同的内容）。
  • 原样传入 top N：真正最相关的条目反而被埋没。

2026 年的实用 RAG 用 "聪明的切分""混合检索"和"reranking" 把这三点逐一击破。我们按顺序来看。

2. 现代 RAG 流水线一览

一条生产级 RAG 的数据流分为两条轨道：准备阶段（索引）与查询时（检索与生成）。

两个阶段

准备（离线）：聪明地对文档做 chunk → 用 embedding 向量化 → 存入向量 DB（同时建立关键词索引）。

查询时（在线）：用混合检索（BM25 + 向量）取出 top 50-100 → 通过 reranking 收窄到少数几条 → 交给 LLM 生成答案。

与 naive RAG 的区别在于是否存在 "④ 混合检索" 与 "⑤ reranking"。这两个阶段把检索精度提升到了实用水平。

3. ① Chunking（最重要）

可以说 chunking 决定了 RAG 质量的一半。以下是主要策略。

策略做什么适用场景
recursive 512 tokens务实的默认选项。在 2026 年 2 月的一项基准中被报告为 7 种策略中的第 1 名拿不准时就用它
semantic在语义发生转变处切分，使每个 chunk 主题连贯密集的技术文档
structural尊重标题、代码块、HTML 章节文档与代码
parent-child（层级式）在小 chunk 上精确检索；在回答时返回周围的父 chunk在精度与上下文之间平衡

如果问题出在边界处的上下文丢失，Contextual Retrieval（为每个 chunk 附上整篇文档的上下文）或 Late Chunking 会有帮助。Anthropic 报告称 Contextual Retrieval + reranking 把 top-20 检索失败最多减少了 67%（来自报告的数字）。现实中的顺序是：先从 "recursive 512" 开始，若精度不足再加入 semantic / parent-child / Contextual Retrieval。

4. ② 选择 embedding 模型

embedding 模型把 chunk 转换为向量——它是检索精度的基础。

  • 稳妥的默认：OpenAI text-embedding-3-large。在检索质量与集成便利性之间取得良好平衡。
  • 其他选项：Cohere、Voyage、Gemini embeddings，以及各种 OSS 模型。
  • 重要：许多 OSS embedding 在与混合检索 + reranking 结合时对生产已经足够。不要只纠结于 embedding 本身。

要点是把 "embedding 当作整条检索流水线中的一个环节" 来看待。比起换用昂贵的 embedding，加上混合检索与 reranking 往往更具性价比。

5. ③ 选择向量 DB（对比）

向量 DB负责存储与检索向量。以下是 2026 年各具特色的主流选项。

DB特点 / 优势适合谁
ChromaAI-native、local-first、简洁的 Python API个人/PoC，最快地原型化 RAG
pgvector一个 Postgres 扩展。无需第二个 DB，具备事务一致性已经在用 Postgres 的团队
Qdrant低延迟（p50 约 4ms；据报告对比 Milvus 约 6ms / Pinecone 约 8ms）注重速度、面向生产
Pinecone全托管。零基础设施，仅凭一个 API key 即可起步希望省去运维、cloud-first
Weaviate混合检索冠军（一次查询中融合 BM25 + 向量 + 元数据）重度混合检索用户
Milvus企业级，可处理数十亿级向量超大规模

选型维度："规模、托管 vs 自托管、现有技术栈、预算。" 拿不准时——原型用 Chroma，有 Postgres 就用 pgvector，均衡的生产用 Qdrant/Pinecone，混合检索为主用 Weaviate。对大多数 RAG 工作负载而言，Pinecone / Weaviate / Qdrant 被认为是强有力的选择。

6. ④ 混合检索（BM25 + 向量）

修复 naive RAG 最大弱点——对精确词很弱——的，正是混合检索。它把 BM25（关键词/词面检索）与稠密向量检索融合在一起。

HYBRID SEARCH

融合词面 + 语义

BM25（词面）
对型号、专有名词等精确词很强
Vector（语义）
捕捉改写表达与意图
用 RRF 融合
无需调分数即可合并两种排名

据报告，用 Reciprocal Rank Fusion (RRF) 融合两者
能持续胜过单独使用任一方法（NDCG 更高）。

实践中，最省事的是使用像 Weaviate 这样一次查询即返回混合结果的 DB。把棘手的分数调优交给 RRF（基于排名的融合），就不会出错。结果就是：对精确词和改写表达都很强的检索。

7. ⑤ Reranking（retrieve-then-rerank）

2026 年的标准做法是 "两个阶段：先广泛检索 → 再收窄（rerank）。"

  • 阶段 1（retrieve）：用 bi-encoder（embeddings）快速取出 top 50-100。
  • 阶段 2（rerank）：用 cross-encoder 对（问题, chunk）联合打分，收窄到真正最相关的少数几条。

常用的 reranker 有 Cohere Rerank 3.5、Voyage rerank-2.5、BGE reranker-v2、Jina Reranker v2。Reranking 会增加约 50-200ms 的延迟与成本，但由于传给 LLM 的 chunk 变成了精选的少数几条，它往往能减少 LLM 的 token 消耗、降低总成本。在精度与成本两方面，reranking 正在成为一个 "没有理由不加" 的阶段。

8. 框架（LlamaIndex/LangChain）

使用框架比自己从头写一切更快。以下是 2026 年的分工。

  • LlamaIndex：检索导向。擅长文档索引、检索质量以及快速的 RAG 迭代。
  • LangChain / LangGraph：编排（控制）一侧。复杂工作流与 agent 协调。
  • 组合模式：实践中，许多人把 LlamaIndex 用作检索层，把 LangGraph 用作控制层。

需要注意的是，近来随着通过 MCP 实现工具标准化以及 Agent SDK 的兴起，出现了一种趋势：agent 不依赖重量级 LLM 框架就能即时搭建流水线。尽管如此，如果你要精雕检索质量，LlamaIndex 这一族依然很强。关于 agent 构建的总体方法，参见 如何构建 AI agent。

9. RAG vs 长上下文

"有了 1M-token 的上下文窗口，我不就能把所有内容塞进去、跳过 RAG 了吗？"——这是个常见问题。答案是 "不行，RAG 不会被取代。"

"全塞进去" 的陷阱

  • token 低效：每次都发送庞大、冗余的上下文，成本高昂。
  • lost in the middle：长文本中间的信息往往被忽略。
  • 干扰：无关信息越多，答案质量越低。

指导原则：对小型语料和快速迭代使用长上下文，对于稳定的重复上下文尽早加上 prompt caching，并在 "新鲜度、规模、来源可追溯" 成为需求的那一刻就加上 RAG。 "只管把它塞进上下文窗口" 就是新版的 "只管加个向量 DB"——并非万灵药。请把这一点与对上下文窗口的理解结合起来。

10. 生产化的注意事项

  • 先建立 eval："大致变好了" 是无法被改进的。用一组有代表性的问题 × 期望来源来量化检索精度，并在每次改动间做对比。
  • 监控：持续关注检索命中率、rerank 后的相关性以及答案的接地（grounding）。
  • 成本设计：费用来自 embeddings、reranking 与 LLM。通过 reranking 削减 LLM token 是标准的省钱手段。参见 token 节省。
  • 新鲜度与来源可追溯：要为反映数据更新（重新索引）做好设计，并始终为答案附上来源（出自哪份文档）——这是对抗幻觉的关键。
  • 机密数据：在把内部文档向量化并放置到外部时要格外小心。参见 企业 AI 使用准则。

总结

实用 RAG 已经从 naive 的 "切碎 + 向量检索" 演进为一条多阶段流水线："聪明的 chunking → embedding → 向量 DB → 混合检索 → reranking。" 精度提升最大的两点是混合检索（用 RRF 融合 BM25 + 向量）与 reranking（retrieve-then-rerank）——仅仅加上这两项，就能大幅修复 "答案偏了" 的问题。

向量 DB 方面：原型用 Chroma，有 Postgres 就用 pgvector，生产用 Qdrant/Pinecone，混合检索为主用 Weaviate。框架方面：检索用 LlamaIndex，控制用 LangChain/LangGraph。而且即使到了 1M token，RAG 也不会被取代——如果你需要新鲜度、规模与来源可追溯，那就是 RAG。最后还有一条必做项："先建立 eval 集。" 无法度量的东西就无法改进。守住这一点，你的 RAG 就能可靠地从 "大致能用" 演进到 "在生产环境可用"。

延伸阅读：什么是 RAG（基础）、什么是上下文窗口、如何构建 AI agent、Claude Agent SDK，以及 什么是 MCP。

FAQ

Q. 我的 RAG 精度很低，应该先改什么？
A. 加上两样东西——"混合检索" 与 "reranking"——是最有效的。单纯的向量检索对型号、专有名词这类精确词很弱，而且最相关的 chunk 会被埋没。用 BM25（通过 RRF）+ cross-encoder rerank 融合，可把检索质量提升到实用水平。如果这样还不够，就回头审视你的 chunking。

Q. 我该选哪个向量 DB？
A. 原型用 Chroma，已经有 Postgres 就用 pgvector 是轻松的起点。均衡的生产用 Qdrant（低延迟）或 Pinecone（全托管）；重度混合检索用 Weaviate；超大规模用 Milvus。按规模、运维偏好、现有技术栈与预算来选择。

Q. chunk 多大合适？
A. 用 recursive 切分、512 tokens 左右是务实的默认（在 2026 年的基准中被报告接近榜首）。技术文档用 semantic（按语义切分）；文档/代码用 structural（尊重标题/代码）；既要精度又要上下文用 parent-child。从 512 起步，边评估边调优。

Q. 有了 1M-token 窗口，RAG 不就没必要了吗？
A. 它不会变得没必要。 把所有内容塞进上下文，会因 token 低效、"lost in the middle" 与干扰而降低质量。对小型语料和原型用长上下文，而一旦新鲜度、规模与来源可追溯成为需求就用 RAG——这才是现实的分工。

Q. LangChain 还是 LlamaIndex——我该用哪个？
A. 要精雕检索质量就用 LlamaIndex；复杂的控制与 agent 协调用 LangChain/LangGraph。 实践中许多人把两者组合——"LlamaIndex 作检索层，LangGraph 作控制层"。近来也有用 Agent SDK 轻量化组装的趋势，所以按你的需求来选择。