一、Why RAG
LLM 自身的知识有三个根本性限制：训练截止日期之后的事它不知道；私有数据它没见过；它无法溯源。这些限制不是模型能力问题，是机制问题——知识被固化在训练好的权重里，推理时不变化，每次回答既无法引用来源，也无法即时更新。
针对这三个痛点，2020 年 Patrick Lewis 等人在 Meta FAIR 提出的 Retrieval-Augmented Generation（RAG） 给出了一套解决方案：不修改模型权重，而是在推理时把”相关的外部知识”动态注入到 context 中。模型读到这些被检索来的内容，基于它们生成回答。从工程上看，RAG 把模型的知识分成了两部分：参数化记忆（权重）+ 非参数化记忆（外部数据库）。前者负责语言能力，后者负责具体事实。
RAG 之所以成为生成式 AI 应用的事实标准，是因为它同时解决了三个根本问题。知识时效性：训练截止后的信息可以通过外部索引实时注入；私有数据接入：企业内部文档无需进入训练流程就能被模型使用；幻觉与可溯源性：模型回答可附上引用，便于追溯和验证。这三件事任何一件单独成立都足以让 RAG 成为必备能力，三件事叠加在一起就成了所有企业 AI 应用的基础设施。
要理解 RAG 在工程上由哪些环节组成、为什么 embedding 和 indexing 是它的两大支柱、为什么经典 RAG 已经不够用、为什么 Anthropic 和 Microsoft 走出了三种不同的演进路线，前提是搞清楚：一段外部文档如何被预处理、如何被检索、如何被注入到 context 中。
二、RAG 与 Context 的关系
RAG 本质上是 context 管理的一种工程手段。RAG 是其中专门用来解决”跨会话长期记忆”和”超出 context 容量的大知识库”的方案。它跟其他方案的关系不是替代，而是互补——长会话场景用 Compaction 压缩历史，跨会话场景用 RAG 检索相关内容，工具调用密集场景用 Subagent 隔离。
理解这一点之后，RAG 的所有设计都能从 context 视角解释。为什么要分块（chunking）：因为整篇文档塞不进 context；为什么要做语义检索：因为只能塞几个最相关的块，必须挑准；为什么要 rerank：因为粗筛回来的候选还有噪声，挑得不够准会浪费 context 预算；为什么要 contextual retrieval：因为分块切断了原文的语境，光看孤立块连相关性都判断不准。整套 RAG 就是围绕”如何用最少的 token 把最相关的知识塞进 context”展开的工程优化。
三、RAG 的工作流总览
一套完整的 RAG 系统在工程上分为两个独立子流程：离线索引（Indexing） 与 在线查询（Retrieval + Generation）。两者在时间、成本、性能要求上完全不同——离线索引可能耗时数小时甚至数天，但只做一次；在线查询必须在数百毫秒内完成，且每次提问都触发。这是 RAG 系统设计的核心时间约束。
有一条硬性约束必须明确：离线与在线必须使用同一个 embedding 模型。不同模型生成的向量位于不同的几何空间，互相之间没有可比性。一旦切换 embedding 模型，所有历史索引必须重新生成。这是 RAG 工程中常被低估、但代价极高的一条铁律。
四、Embedding：把语义变成可计算的向量
RAG 的整个工作机制建立在一个核心数学操作上——把文字变成可以比较的数字。这个操作叫 embedding。理解 embedding 是理解 RAG 的前提。
4.1 直觉
LLM 处理文字时，从来不是直接读字符。文字必须先转换成数字才能被神经网络处理。但更进一步的问题是：如何让数字之间的”距离”反映文字之间的”语义相似性”？
举一个具体例子，下面三句话：
- A：「我喜欢猫」
- B：「我爱小猫咪」
- C：「今天股市大跌」
人类直觉立刻能判断 A 和 B 语义接近、A 和 C 几乎无关。但要让计算机做同样判断，必须找一种数学表示，使 A 和 B 对应的”东西”在数学上很接近、A 和 C 对应的”东西”在数学上很远。
Embedding 就是这种表示。每段文字被映射为一个固定长度的浮点数列表（叫向量），向量之间的几何距离反映文字的语义距离。例如这三句话的 embedding 大致如下（实际维度通常 1024 或 1536，这里简化为 5 维）：
A: [0.21, -0.45, 0.88, 0.12, -0.33]B: [0.23, -0.42, 0.85, 0.15, -0.30] ← 跟 A 数值非常接近C: [-0.61, 0.32, -0.17, 0.91, 0.44] ← 跟 A 数值差很远得到向量之后，“语义相似度”就变成了向量之间的几何距离问题——纯数学。
4.2 两种”Embedding”，不要搞混
这里要立刻澄清一个被严重混用的术语。AI 圈说的”embedding”实际指代两件完全不同的东西。第一种是 LLM 内部的 token embedding——LLM 输入层有一张巨大的查找表（embedding matrix），把每个 token ID 映射为一个向量，这是 O(1) 的查表操作，几乎不消耗算力，存在于 LLM 内部不可单独使用。第二种是 RAG 使用的 sentence/text embedding——它是一个完全独立的小型神经网络，输入一段文本，输出一个表示整段语义的向量，是要跑完整前向传播的真实模型，消耗算力、按 token 收费。RAG 中说的 embedding 指第二种。两者唯一的共同点是产物都叫”向量”，但生成机制、用途、成本完全不同。
| 维度 | LLM 内部 Token Embedding | 独立 Embedding 模型（RAG 用） |
|---|---|---|
| 本质 | 一张查找表 | 一个独立神经网络 |
| 输入 | 1 个 token ID | 一段文本 |
| 输出 | 1 个向量（每 token 一个） | 1 个向量（整段压缩） |
| 操作 | O(1) 查表 | 完整前向传播 |
| 算力 | 几乎为零 | 真实消耗（远小于 LLM） |
| 是否可独立使用 | 否 | 是 |
后面讲的 embedding 模型、训练方式、cosine similarity，全部指第二种。
4.3 Embedding 模型
负责把文字转成向量的，是一个独立的小型神经网络，叫 embedding 模型。
它跟前面提到的 LLM 是两个完全独立的模型——不要混淆。LLM 的任务是”读完一段输入预测下一个字”，输出是文字；embedding 模型的任务是”读完一段文字输出一个能代表语义的向量”，输出是数字。两者训练目标、模型结构、API 调用、计费方式都独立。
| 维度 | LLM | Embedding 模型 |
|---|---|---|
| 任务 | 生成下一个 token | 把文本压成一个向量 |
| 输出 | 文字 | 浮点数组 |
| 大小 | 几十亿到万亿参数 | 几千万到几亿参数 |
| API 调用 | chat.completions | embeddings.create |
| 计费 | 输入输出 token 分别计费 | 仅按输入 token 计费 |
主流商用 embedding 模型：OpenAI 的 text-embedding-3-small（输出 1536 维向量）与 text-embedding-3-large（3072 维）；Voyage AI 的 voyage-3（1024 维，Anthropic 官方推荐）以及代码、金融、法律等领域专用版本；开源方向有 BGE、E5 系列。成本极低——OpenAI text-embedding-3-small 大约 $0.02 / 百万 tokens，几万页文档才花一美元。所以在 RAG 的总成本中，embedding 这部分小到可以忽略。
4.4 Embedding 模型如何”学会”
Embedding 模型的训练原理是 对比学习（contrastive learning）。训练时把数据组织成成对的形式：
- 正样本对：「猫睡在沙发上」和「沙发上的猫在打盹」 → 训练目标是让两者向量靠近
- 负样本对：「猫睡在沙发上」和「股市今天大跌」 → 训练目标是让两者向量远离
跑几亿对这种数据，模型自然学会”什么叫语义接近”。注意这里学到的”语义”完全是统计性的——模型没有任何人类意义上的理解，它只是发现「猫」「打盹」「沙发」这些词高频共现，所以认为它们语义接近。这套思想可以追溯到 2013 年 Mikolov 等人在 Google 提出的 Word2Vec——他们最早证明了”语义关系在向量空间中具有线性结构”（著名的 king − man + woman ≈ queen），这一发现奠定了后续所有 embedding 工程的基础。
4.5 如何比较两个向量：Cosine Similarity
得到向量之后，比较”相似度”用的最常见公式是 余弦相似度（cosine similarity）。它的核心思想是：只看两个向量的方向是否一致，不看长度。
- 方向完全一致 → cosine = 1（最相似）
- 完全垂直 → cosine = 0（无关）
- 方向相反 → cosine = -1（语义对立）
为什么用 cosine 不用直线距离？因为文本长度不应影响语义判断——“猫”这一个字和”我家有一只可爱的小花猫”应该被判定为相关，但它们的向量模长差异可能很大。Cosine 自动忽略长度差异，只比较”方向”，正好符合需求。
整个 RAG 检索的数学本质，就是算用户问题的向量和库内每个文档片段向量的 cosine，取分数最高的几个。这一对比环节在工程上叫 similarity search，向量数据库内部用 HNSW、IVF 等 ANN（近似最近邻）算法实现，能在毫秒级从百万级向量中找出 Top-K。
4.6 把 Embedding 在 RAG 中的位置标清楚
回到 RAG 视角，embedding 出现在两个时刻：
注意一条硬性规则：建库与提问必须用同一个 embedding 模型。不同模型生成的向量位于不同的几何空间，互相之间没有可比性。一旦切换 embedding 模型，所有历史索引必须全量重新生成。这是 RAG 工程中常被低估、但代价极高的一条铁律。
4.7 Embedding 的局限
虽然 embedding 是 RAG 的核心，但它有几个根本性的弱点必须明确。
第一，否定词容易被稀释——「我喜欢猫」和「我不喜欢猫」的 cosine 相似度通常很高，因为「不」这个字对整段向量影响有限。这导致 RAG 在精确性场景下天然脆弱。
第二，精确字符串匹配能力弱——产品代码、错误码（如 0x80070005）、人名、SKU 这类信息会被压进”通用区域”，向量检索难以命中。
第三，跨领域迁移弱——通用 embedding 模型在医疗、法律、代码等垂直领域表现明显下降，因此有 voyage-code、voyage-finance 等领域版本。
第四，有损压缩——把一段千字内容压成 1024 个数字，必然丢细节，embedding 擅长抓”主题与整体语义”，但精确事实、数字、专有名词容易被压糊。
这些弱点决定了 embedding 不能单独用，必须搭配其他检索手段。这就引出了下一个关键名词——BM25。
4.8 BM25：基于关键词的另一条检索路线
BM25 是一种基于关键词匹配的检索算法，全称 Best Matching 25，1994 年由 Stephen Robertson 提出，是 Elasticsearch、Lucene、OpenSearch 等传统搜索引擎的底层默认评分函数。它跟 embedding 完全是两套思路。
BM25 的工作原理一句话概括：统计查询中的每个关键词在文档中出现的频率，结合文档长度做归一化，给出相关性分数。它不理解语义，只看字面匹配。例如用户查询 ACME 2023 Q2 营收，BM25 会扫描所有文档，找出同时包含 “ACME”、“2023”、“Q2”、“营收” 这些字面词的文档，按出现频率打分排序。
BM25 的强项正是 embedding 的弱项：
- 精确专有名词：错误码、SKU、人名、产品名——字面命中即可
- 罕见词：训练语料里少见的术语，embedding 没学好，BM25 直接字面匹配
- 数字、日期、代号：embedding 容易把它们压进通用区域，BM25 字面匹配
BM25 的弱项正是 embedding 的强项：
- 同义改写：用户问”加速训练”，文档写”提升收敛速度” → BM25 完全失效
- 跨语言：用户用中文问，文档是英文 → BM25 完全失效
- 概念性查询：用户问”如何优化性能”，需要语义理解
两者的盲区互补，这就是为什么实战 RAG 一定要同时跑 embedding 和 BM25 两条路线。这种做法叫 hybrid search（混合检索）。WANDS 电商基准测试显示，单独 BM25 与单独向量检索的检索质量几乎相同，但两者合并后整体提升约 7.4%，因为它们各自捞回的结果有大量互补。
到这里，embedding、cosine similarity、BM25、hybrid search 几个核心名词都有了基础，下一节讲它们如何被组装成完整的索引和检索流程。
五、Indexing：把文档预处理好放进库里
RAG 不是把整篇文档原封不动塞进数据库就完事了——文档必须经过一整套预处理流程才能被高效检索。这套流程叫 indexing（建索引）。
5.1 三个概念的关系再次澄清
- Embedding 是一种技术——把文字变成向量
- Indexing 是一个工程动作——把文档预处理后存进数据库
- RAG 是一种应用范式——检索 + 生成
三者层层包含：RAG 使用 indexing 的成果；indexing 使用 embedding 作为工具之一。但三者并不是绑定关系——indexing 不一定只用 embedding（关键词索引也是 indexing），embedding 也不只用于 RAG（推荐、聚类、异常检测都能用）。
5.2 Indexing 的四个步骤
Indexing 在工程上分为四步，每一步都有独立的工程权衡。
Step 1 — 解析为纯文本。原始文档可能是 PDF、Word、Markdown、HTML，要先转成纯文本字符串。对结构化内容这一步特别麻烦——PDF 中的扫描页需要 OCR、表格需要结构还原、双栏排版需要识别阅读顺序。这是 RAG 系统最容易掉链子的环节。主流工具：unstructured、docling、Azure Document Intelligence。这一步消耗 CPU 但不消耗 LLM token，成本极低。
Step 2 — Chunking（切块）。把长文本切成小块（chunk），这是 RAG 工程中最被低估的环节。原因很简单：模型 context 装不下整篇文档，必须切成小块按需取用；同时 embedding 模型本身也有输入长度上限。但切多大才合适？这是个权衡：
- chunk 太小（< 100 tokens）→ 单块语义不完整，孤立看不明所以
- chunk 太大（> 1000 tokens）→ 单块包含多个主题，向量会”模糊”
- 业界经验值：200–800 tokens 区间，叠加 10–20% 滑窗重叠
不同类型内容有不同切块策略。普通文本可以按段落或固定长度切；代码必须按函数 / 类边界切，跨边界会破坏语法结构；表格整张表必须作为一个 chunk，按行切会失去列头语境；Markdown 应该按 # ## 等标题层级切。这一步同样不消耗 token，纯字符串操作。
Step 3 — 生成向量（Embedding）。每个 chunk 喂给 embedding 模型，得到一个向量。这一步是真实的神经网络推理，消耗 token，但 embedding 模型便宜——按百万 tokens 计的成本只有几美分。
Step 4 — 写入数据库。chunk 文本和对应向量必须一起存——向量用于检索，文本用于注入到 prompt 中。如果只存向量，检索到了也不知道对应的原文是什么。同时如果走 hybrid search 路线，还要把 chunk 文本写一份进 BM25 倒排索引（这是 Elasticsearch / OpenSearch / Lucene 这类传统搜索引擎的标准能力，几乎零成本）。
5.3 向量数据库简介
存向量的数据库叫向量数据库（vector database）。它跟传统数据库的关键差异是：传统数据库擅长精确查找（“找出 ID = 123 的记录”），向量数据库擅长相似度查找（“找出与这个向量 cosine 最高的 20 个记录”）。后者在百万级数据上做暴力计算需要几秒到几十秒，向量数据库内部用 ANN 算法（Approximate Nearest Neighbor，近似最近邻） 把这一过程压到毫秒级。主流 ANN 算法有 HNSW、IVF，原理不展开——使用者不需要懂，调用 API 即可。
主流向量数据库：Pinecone、Qdrant、Weaviate、Chroma（独立产品）；pgvector（PostgreSQL 扩展）；Azure AI Search、Vertex AI Vector Search（云服务托管）。选型主要看托管成本、可扩展性、是否需要自部署，技术能力上各家差异不大。
5.4 Indexing 的成本结构
Indexing 阶段的成本以 embedding 模型调用为主，但因为 embedding 极便宜（百万 tokens 仅 $0.02），对几百万 tokens 量级的知识库做一次全量 indexing 通常只需几美分到几美元。Indexing 这个动作本身——切块、入库、查表——完全不消耗 token，是纯 CPU/IO 操作。所以 RAG 成本优化的重点从来不在 indexing 上，而在运行时的主 LLM 调用上。
5.5 Indexing 之后：库里到底有什么
一次完整的 indexing 完成后，数据库里存的东西大致是这样：
向量库（用于 embedding 检索） ┌─────────────────────────────────────────────────┐ │ chunk_001 → 向量 [0.21, -0.45, ...] │ │ ↳ 原文 "公司的收入比上一季度..." │ │ chunk_002 → 向量 [0.18, -0.42, ...] │ │ ↳ 原文 "本季度推出了新产品..." │ │ ... │ └─────────────────────────────────────────────────┘
BM25 倒排索引（用于关键词检索） ┌─────────────────────────────────────────────────┐ │ 词 "ACME" → 出现在 [chunk_001, chunk_015, ...] │ │ 词 "营收" → 出现在 [chunk_001, chunk_008, ...] │ │ 词 "Q2" → 出现在 [chunk_001, chunk_022, ...] │ │ ... │ └─────────────────────────────────────────────────┘注意两个库存的是同一批 chunk 的两种不同视图——一个按”语义指纹”组织，一个按”出现的关键词”组织。提问时两路都要查，再合并结果。这就是 hybrid search 的物理基础。
六、经典 RAG 的根本缺陷：上下文丢失
到这里为止讲的是 2024 年之前所谓的”经典 RAG”。
这一方法在 2024 年遭遇了严重的挑战——Anthropic 在 9 月发布的博文 Introducing Contextual Retrieval 中明确指出了它的系统性缺陷：传统 RAG 在编码信息时移除了上下文，导致系统无法从知识库中检索到本应相关的信息。
Anthropic 给出的经典例子是这样的：某金融知识库中存在一个 chunk，原文是「公司的收入比上一季度增长了 3%」。当用户查询「ACME 公司在 2023 年第二季度的收入增长是多少？」时，这个 chunk 既不会被向量检索命中（embedding 里没有 ACME、2023、Q2 这些语义信号），也不会被 BM25 命中（关键词零重叠）。但从整篇文档角度看它显然就是答案——只是分块时切断了 chunk 与上下文的关联，让它失去了识别度。
这是经典 RAG 的系统性问题。任何长文档分块后都会出现大量”丢上下文”的 chunk——技术报告里写”该方法相比 baseline 提升了 5%“，但具体是哪个方法、哪个 baseline 在前文；财报里写”营业利润同比增长 12%“，但具体是哪家公司、哪个季度也在前文。分块切断了这些信息，孤立的 chunk 就失去了被检索到的能力。
七、三种应对方法：chunk 层、query 层、context 层
针对这个问题，业界三家头部厂商给出了三种完全不同的应对方法。
Anthropic 的 chunk 层修复：Contextual Retrieval。在 embedding 之前，用 LLM 为每个 chunk 生成 50-100 tokens 的”上下文化前缀”，描述该 chunk 在全文中的位置与背景。原始 chunk「公司的收入比上一季度增长了 3%」会被改写为「本段来自 ACME 公司 2023 Q2 SEC 10-Q 文件的财务摘要部分；上一季度营收为 3.14 亿美元。公司的收入比上一季度增长了 3%」。上下文化后的 chunk 才进入 embedding 与 BM25 索引——这样 chunk 自带 ACME、2023、Q2 等关键词，向量也带上了这些语义信号。这一步要对每个 chunk 调一次 LLM 处理整篇文档加该 chunk，听起来昂贵，但通过 prompt caching（整篇文档只缓存一次，每个 chunk 只为变化部分付费），总成本可压到约 $1 / 百万文档 tokens。Anthropic 给出的实测数据是惊人的：Contextual Embeddings 单独使用让检索失败率降低 35%，叠加 Contextual BM25 降低 49%，再叠加 reranking 降低 67%。这是当前最具影响力的方案，已被业界广泛复现。注意：Claude 这里生成的”小型上下文”是一段普通文字，不是向量、不是 embedding，它只是给 chunk 补全了文字，后续才走标准的 embedding 流程。这是非常容易被混淆的一点。
Microsoft / Azure 的 query 层修复：Agentic Retrieval。不在 chunk 层做手脚，而是前置增强 query 的智能化——用 LLM 在查询前做 query rewriting、query decomposition、并行子查询。Azure AI Search 2025 年 5 月推出的 Agentic Retrieval 把这套做成了官方能力：LLM 分析复杂问题，分解为多个针对性子查询，跨知识源并行执行，再融合结果。复杂查询的相关性比经典 RAG 提升最高 40%。Copilot Studio 的 4 步流水线也是同样的哲学：用最近 10 轮对话上下文重写查询、从所有已配置知识源各取 Top 3、生成带引用的回答、内容审核。
Google 的 context 层跳过：超大窗口直接全文塞入。Gemini 2.5 Pro 支持 1M tokens 的原生 context，对于较小的知识库（百万 tokens 以内），Google 的建议是跳过 RAG，直接全文塞 context。这种做法完全无信息丢失、工程最简单，代价是受限于 context rot（前面讲过的”长 context 上模型悄悄变笨”）和容量上限。Anthropic 也认可这一方案：知识库小于 200K tokens 时可省略 RAG。
成熟的 RAG 系统往往三者并用。Azure AI Search 的 Agentic Retrieval 同时做 query decomposition 与 hybrid search；Claude Projects 在容量内时全文塞 context，超过时自动触发 RAG；企业级方案往往在 Anthropic 的 Contextual Retrieval 基础上叠加 query rewriting。
八、2026 年的标准 RAG 技术栈
把前面讲的所有改进组合起来，2026 年企业级 RAG 的事实标准已经形成：Contextual Chunks + Hybrid Search（BM25 + Vector） + RRF 融合 + Cross-encoder Reranking + Agentic Query Decomposition。任何企业级 RAG 项目都应以此为起点而非从经典 RAG 起步。各环节单独失效率降幅可叠加：Contextual Retrieval 降 49%、Reranker 再降 18%、Agentic Retrieval 再降相关性 40%——综合下来比 2020 年的经典 RAG 强出数倍。
下表总结各方案的特征：
| 方案 | 信息损失 | 实现复杂度 | 何时启用 |
|---|---|---|---|
| 经典 RAG | 高 | 低 | MVP / 小知识库 |
| Hybrid Search + RRF | 中 | 中 | 含专有名词 / 错误码场景 |
| + Reranker | 低 | 中 | 追求高精度场景 |
| + Contextual Retrieval | 极低 | 高 | 大型企业知识库 |
| + Agentic Retrieval | 极低 | 极高 | 复杂多步问题场景 |
九、Agentic RAG：从一次性检索到工具化检索
经典 RAG 是一次性的：“检索一次 → 拼装 prompt → 生成回答”。这在简单 Q&A 上有效，但在复杂任务上有明显局限：复杂问题需要多步检索（先查 A，根据 A 的结果再查 B）；检索结果可能自相矛盾需要澄清；单次检索的 chunk 可能缺失关键背景。
Agentic RAG 把检索本身视为 Agent 可调用的工具，由模型决定何时检索、检索什么、是否继续检索。代表实现是 Claude Code 的 Agentic Search——它不预先 embedding 代码库，而是让 Agent 用 grep / glob / read 等工具按需探索代码，每一步都是模型自主决策。GitHub Copilot Chat 走同样的思路：对 GitHub 仓库有远端 semantic code search index 兜底，但实际交互中大量依赖工具调用（grep、file search、find references、read），本质是 Agentic Search 而非经典 RAG。这是 2025-2026 年代码类 Agent 的核心转变。
OpenAI File Search、Anthropic Claude Projects、Microsoft 365 Copilot 也都在向 Agentic RAG 方向演进——检索从”一次性预处理步骤”转为”Agent 可重复调用的工具”。模型可以决定”我需要更多信息，再检索一次”，可以决定”这次检索结果不够用，换个角度再查”。
十、RAG 的真实成本结构
把 RAG 的所有环节成本放到一起对比，得到一张非常重要的全景图。假设 100 万 tokens 的文档库，不同方案的成本对照：
| 方案 | Indexing 一次成本 | 单次问答成本 | 检索质量 |
|---|---|---|---|
| 全文塞 context（不用 RAG） | $0 | $5（按 GPT-5 输入价） | 100% 但 context rot |
| 经典 RAG | $0.02 | $0.05 | baseline |
| Contextual Retrieval | $1 | $0.05 | 失败率 ↓ 49% |
| Contextual + Reranker | $1 | $0.06 | 失败率 ↓ 67% |
三个核心观察。
第一，indexing 成本随方案不同差 50-500 倍，但绝对值都很小——花一次性的小钱换长期检索质量提升，工程上完全划算。
第二，运行时成本主要由 LLM 决定，跟用不用 contextual retrieval 关系不大。
第三，主 LLM 推理（约 $0.05/次）远高于 indexing 任何阶段。结论是优化 RAG 成本先看主 LLM 的输入 token 怎么省——Top-K 减小、chunk 缩短、用更便宜的生成模型——indexing 阶段那点钱不用纠结。
十一、终端产品中的 RAG 实现
终端 LLM 产品在 RAG 上的策略差异非常大，分清楚有助于理解日常工具的真实行为。
Claude Projects 当 Project 的知识库逼近上下文窗口上限时自动切换到 RAG 模式，将容量扩展约 10 倍，无需用户配置。界面会显示 “Indexing” 提示告知当前模式。容量回落到 context 容量内时自动切回 in-context 模式。Anthropic API 层面则提供完整的 Contextual Retrieval 实现。
ChatGPT Projects 提供工作区语义的 RAG 体验——每个 Project 拥有独立的文件库、自定义指令、聊天历史。OpenAI File Search Tool 是其 API 层暴露：用户预先创建 vector store 并上传文件，OpenAI 自动完成解析、分块、embedding、索引，调用时模型决定是否检索、检索什么，返回结果包含 file citations 引用。OpenAI 的”上下文丢失”方案不做 chunk 层 contextual prefix，而是依赖语义化分块策略 + 混合检索 + 元数据 attribution。
Microsoft 365 Copilot 的 RAG 不依赖用户上传——它直接基于 Microsoft Graph + Semantic Index 检索企业现有数据（SharePoint、OneDrive、Outlook、Teams、日历、Planner、Loop、Viva、Graph Connectors 外部系统）。2026 年推出的 Work IQ 是组织智能层，超越了传统的文档式 RAG——它聚合带权限的工作信号而非原始文档（邮件模式、会议关系、文档协作模式、任务归属、非正式团队关系），构建持久化的工作记忆（个人沟通风格、重复工作流、常合作的同事、角色优先级）。Copilot Studio 在中间层提供四步 RAG 流水线（query rewriting、content retrieval、summarization、safety validation），底层是 Azure AI Search——它在 2025 年 5 月推出的 Agentic Retrieval 把”query 层修复”做成了产品能力。
Google Vertex AI 按抽象层级分三个产品：Vertex AI Search 完全托管，开箱即用语义+关键词混合搜索；Vertex AI RAG Engine 中等托管，提供 RAG 流水线编排；Vertex AI Vector Search 最底层向量数据库服务。Google 的 grounding 体系还包括 Grounding with Google Search——直接把 Gemini 回答 grounded 到实时搜索结果。
| 产品 | RAG 类型 | 自动激活 | 上下文丢失方案 |
|---|---|---|---|
| Claude Projects | 自动触发 RAG | 容量达上限时 | 内置 Contextual Retrieval |
| Anthropic API | 开发者自建 | 需手动实现 | Contextual + Hybrid + Reranker |
| ChatGPT Projects | 文件库式 RAG | 上传即生效 | 语义分块 + 混合检索 |
| OpenAI File Search API | 托管 vector store | 需手动建库 | 语义分块 + Hybrid Search |
| M365 Copilot | Graph-grounded RAG | 全自动 | Semantic Index + Work IQ |
| Copilot Studio | 多源 RAG | 配置后自动 | 4 步流水线 |
| Azure AI Search | 经典 + Agentic | 可选 | Agentic Retrieval（提升 40%） |
| Vertex AI Search | 高度托管 | 全自动 | 内置语义+关键词混合 |
十二、PDF 上传与 Copilot 问代码库的真实行为
把 RAG 知识应用到日常工具行为上，几个常见场景值得明确。
拖 PDF 进 chatbot 问问题的行为取决于文件大小。小 PDF（几十页内）会被全文塞 context，完全不走 RAG；大 PDF 自动触发 RAG，Claude.ai 切换时会显式显示 “Indexing”，ChatGPT 隐式切换不提示。判断当前模式的方法是问模型”统计全文 X 出现几次”——答得准说明全文塞入，答得近似说明走了 RAG。各家阈值不同：ChatGPT 大约 50-100 页内全文塞入，Claude 200 页内，Gemini 由于 1M context 几乎不需要触发 RAG。
VS Code 里 GitHub Copilot 问代码库用的是分层 fallback 机制。文件数 < 100 且 < 32K tokens 时全部塞 context；GitHub 仓库自动触发远端 semantic code search index（真正的经典 RAG，GitHub 服务端用专门的代码 embedding 模型预建索引，跨用户共享）；非 GitHub 本地仓库可选 local index 上限 2500 文件；Agent 模式组合 grep / file search / read 等工具按需检索，本质是 Agentic Search。
IntelliJ IDEA 里的 Copilot 是简化版——命令是 @project 而非 VS Code 的 @workspace，没有独立 embedding 索引，依赖 IDE 自身的 PSI 索引 + 文本搜索。对 md 文件的检索质量明显弱于 VS Code，实战中推荐用 #filename 或 #folder/ 显式指定上下文，绕过它薄弱的自动检索环节。这也是为什么主问答留在 VS Code、IntelliJ 只做 Java 开发是当前最务实的分工。