7 分钟了解 10 种 RAG 策略：先做可靠基线，再处理复杂问题

本文根据该视频的内容摘要整理，旨在梳理其中的技术策略与适用边界，不替代针对具体数据集的评测。

长上下文越来越大，RAG 是否还有必要？这支视频给出的答案是否定的：长上下文和 RAG 不是非此即彼的替代关系。

把全部资料塞进模型上下文，确实减少了检索系统的搭建工作；但资料规模一旦增长，成本、响应延迟和上下文稀释都会成为问题。模型即使能接收百万级 Token，也不等于它能以稳定、低成本且精确的方式利用其中每一段信息。RAG 的任务，仍然是在回答之前为模型找出少量、相关且可信的上下文。

RAG 的两段流程

一个典型 RAG 系统可以分成准备和检索两个阶段。

准备阶段负责把原始资料变成可检索的知识：清洗文档、切分文本、生成向量嵌入，并建立索引。检索阶段则在用户提问后处理查询、召回候选内容、筛选排序，再把结果交给模型生成回答。

不同策略大多落在这两段流程上。没有哪种技术天然更高级，重要的是它是否解决了当前数据和问题的实际瓶颈。

分块决定了检索系统的最小知识单元。固定字数或固定 Token 的切分实现简单，但容易把一个完整定义、条件或结论截断，让检索到的片段缺少必要上下文。

视频更推荐两类做法：

两者的共同目标是保留语义完整性。切分粒度仍要结合文档结构、问题类型和上下文预算来验证，而不是只追求越细越好。

Embedding 决定了文本在向量空间里的表示方式，也影响语义召回的上限。对于一般产品文档、知识库文章或常见业务问答，通用 Embedding 模型通常足以作为可靠起点。

但法律、医学、金融等有大量专业术语和细粒度概念的领域，通用模型不一定能正确拉近真正相关的内容。这时值得考虑领域专用 Embedding 模型，并使用真实查询集评测召回效果。是否更换模型，应该由检索质量和业务风险决定，而不是由模型名称决定。

如果没有非常特殊的数据形态，视频推荐把“混合检索（hybrid search）加重排序（re-rank）”作为默认方案。

混合检索同时使用两类信号：向量检索擅长理解近义表达和语义相关性；关键词检索擅长命中产品名、编号、条款、代码符号和罕见专有词。二者结合，可以避免只靠语义导致精确术语漏召回，也能避免只靠关键词错过表达方式不同但含义相近的内容。

之后再用重排序模型对候选结果做更精细的相关性判断。这样通常比一开始就用复杂架构更容易获得可观的提升，并且成本与延迟相对可控。

当文档的价值主要来自实体之间的复杂关系时，例如合同条款之间的交叉引用、人物与事件的多跳关联，GraphRAG 可能比普通文本片段检索更合适。它可以显式建模实体、关系和路径，帮助系统回答需要跨多段资料推理的问题。

但这也意味着更高的构建成本、更新成本和维护难度。关系抽取不准会把错误结构化，图谱过期也会直接影响回答。因此，GraphRAG 应该用于“关系就是核心问题”的场景，而不该在普通 FAQ 或文档搜索中默认引入。

传统 RAG 更像一条固定流水线：查询、检索、生成。Agentic RAG 则允许模型根据中间结果决定是否继续检索、换关键词、调用其他工具或修正答案。它更适合需要多轮探索和复杂推理的问题。

代价同样明显：更多模型调用意味着更长的延迟、更高的成本，也更难预测和调试。一个更务实的方案是自适应路由（adaptive routing）：先使用轻量分类器或规则判断问题难度，让简单、明确的问题走普通 RAG；只有多跳、模糊或高风险问题才进入 Agent 流程。

这避免了把所有请求都交给最昂贵的系统，也让工程复杂度与用户问题相匹配。

对大多数团队而言，可以先按下面的顺序建设：

RAG 不是一套过时的固定配方，而是一组让模型在有限上下文中获得正确信息的策略。先让检索结果稳定、可评测、可解释，再为复杂场景增加复杂度，通常比一开始就追逐最重的架构更有效。