0. 这篇文章解决什么问题？
过去一年，关于“当大模型能一次读取百万字上下文时，还需要检索增强（RAG）吗？”的讨论此起彼伏。有人认为只要扩大模型上下文窗口，把全部文档拼进去就够；也有人指出 RAG 更像一个工具链，未来仍有发展空间。
这篇文章不只是给出“需要/不需要”的结论，更想通过具体分析告诉你为什么长上下文不能替代 RAG，如何用现代化方法改造 RAG，使其在 2025 年以后的研发和应用中继续发挥核心作用，并且怎么做才能在真实项目里把这些理论落地。这也是在我们调研了大量资料并跟踪了企业实践后写下的总结与展望。
我们将从以下几个方面展开：
- 现实约束：为何长上下文不能解决所有问题。
- 失败案例复盘：天真 RAG 为什么常常翻车。
- 五件套方案：新一代 RAG 工程解决方案概览。
- 深入探讨：GraphRAG 与检索感知训练的原理与做法。
- 落地路线：如何在受限环境（如国产服务器）下部署 RAG 解决方案。
- 改进与展望：下一代 RAG 应该如何进化。
1. 为什么“更大的上下文”不是终点？
从 Gemini 1.5 到 Claude 3.0，模型的上下文窗口飞速增长，有的甚至达到了百万 token。乍看之下，这似乎意味着“再也不用检索了”。但工程现实却提醒我们：更大的背包不等于更好的旅程。
1.1 成本与延时：你的“预算包”是有限的
如果把每次对话都当作一次“输入输出”交易，那么模型处理的 token 越多，花费的成本和计算延时就会叠加。企业内部调研发现，将 2 万字整篇文档塞进 32k 或更高 token 窗口，一次推理的费用可能是原来的 5 倍以上；当并发请求多时，P95 延迟也会从不到 1 秒飙升到数秒甚至十几秒。这对于交互敏感的应用（客服机器人、故障诊断系统等）来说不可接受。
1.2 时效性：知识更新远快于参数更新
企业知识库每天都在更新。有的场景如金融、舆情监测甚至需要秒级、分钟级刷新。如果把知识写进模型参数，你不得不频繁微调模型才能纳入新的信息，不但成本高，而且风险大。相反，RAG 将知识放在外部存储中，通过检索实时“查库”，可以随时更新，而不必动模型参数。
1.3 合规与可审计：来源可信比答案漂亮更重要
在监管严格的行业（如核工业、电力、水利、金融），不仅要求回答正确，更要能溯源：答案出自哪份文档、哪条条款、哪次发布？如果全部资料都塞进上下文，模型生成的文本可能掺杂了多个版本甚至不再可追踪。而 RAG 自带检索链路，记录了每次调用外部知识库、引用的文档片段、版本号等信息，可以形成可靠的审计日志并支持事后复盘。
1.4 隐私与分域隔离：不同密级的知识不能混用
大型企业的知识往往划分多个安全级别。把所有内容塞进上下文窗口等于让模型同时访问所有数据，既不安全也不合规。RAG 可以针对每个请求在不同的权限层级检索知识源，保证敏感数据隔离和访问控制。
小结：长上下文意味着更大的背包，能让模型“装得更多”；而 RAG 意味着一张会不断更新的地图，让模型“找得更准”。真正的工程实践需要二者结合，而不是简单替代。
2. 天真 RAG 为什么会翻车？— 失败案例的“复盘”
很多团队第一次做 RAG 会这样：把 PDF 切成等长块 → 向量化 → 执行 KNN 搜索 → 取最靠前的几段拼接 → 投喂模型。这在原型阶段可能凑合用，但在大多数真实场景下会出现严重问题。下面通过几个真实案例来说明。
2.1 案例 1：只用向量相似度忽略结构
某工程团队将设备说明书切块后，只用向量搜索匹配问题。用户询问“B 阀门的检修周期是多少”，结果检索返回“阀门尺寸对照表”，看似语义相关，但完全答不上“检修周期”的问题。原因为：检索器没有理解“检修周期”这类数字性或表格性信息需要专门的表格或时序型检索方式。
2.2 案例 2：粗暴切块导致信息碎片化
另一个团队将 3 万字的 SOP（标准作业指导书）按照固定长度切块，导致关键定义恰好横跨两个块。例如，“设备 A 的安全操作条件：①压力≥0.35 MPa ②温度 35–55 ℃”被截成“①压力≥0.35 MPa”与“②温度 35–55 ℃”。于是检索器选了 A 块，生成端只看到了“压力≥0.35 MPa”，漏掉了第二个条件。
2.3 案例 3：上下文堆砌带来的噪声
不少团队尝试“召回 10~20 个段落一起喂模型”，以为“多给点材料总没错”。结果模型注意力被噪声拖走，越来越偏离问题本身。例如，在工业报警解析任务中，检索返回了太多“报警原理”与“报警历史”段落，真正的“处理步骤”被埋在第 15 段，模型最终生成了含糊的解释而没有给出操作建议。
2.4 其它问题：新鲜度、重排与可审计
- 新鲜度缺失：检索索引没有增量更新，导致法条、公告等信息过期；版本切换策略不明，模型引用了旧版本条例。
- 重排缺失：只有 KNN 召回而没有交叉编码重排，导致“看起来相关”却“不够回答问题”的段落排在前面。
- 不可审计：回答没有包含任何证据链信息，监管部门无法回溯。
问题不在检索本身，而在于用错方法。 要把检索、证据组织、生成与校验拆开设计，才能发挥 RAG 的真正价值。
3. 新一代 RAG 五件套：骨架、翻书、工具、新鲜度与适度注入
经过调研与实践，我们发现 2025 年的成熟 RAG 方案基本收敛为“五件套”，每一件都对应解决天真 RAG 的一个痛点：
| 组件 | 作用 | 场景 | 挑战 |
|---|---|---|---|
| 结构化检索 (GraphRAG) | 构建知识骨架 | 多文档跨跳、法规、SOP | 图谱抽取与维护 |
| 检索感知训练 | 学会何时检索 | 问答与摘要任务 | 训练成本与样本 |
| 代理式编排 (Agentic RAG) | 调用工具做决策 | 多步骤计划、查询计算 | 安全与效率 |
| 新鲜度管理 | 实时更新索引 | 新闻、行情、高时效场景 | 监控与版本策略 |
| 参数级更新 (可选) | 写进模型少量固定知识 | 模板化回答、术语释义 | 幻觉与覆盖风险 |
接下来我们将逐一详细解释这些组件的原理与工程落地方法。
4. 结构化检索 (GraphRAG)：搭建骨架，让 RAG 走稳
结构化检索并不是一个全新的概念，但直到最近两年它才真正大规模应用。它的核心思想很简单：在非结构化文本（血肉）之外，引入一个结构化“骨架”，通常是知识图谱或实体关系网。很多复杂的问题，如法规条款解释、生产流程、设备故障排查，实际上是沿着实体与关系的路径跳转才能找到答案。
4.1 图谱搭建：从文本到“骨架”
切块与抽取：以标题、小节或自然段为切块单位，并添加滑动窗口，让跨段的信息能完整覆盖。接着使用命名实体识别（NER）和关系抽取（RE）模型，从文本中提取实体和它们的关系，并建立轻量级的图结构。这里建议把实体类型、关系类型设定在 2~3 类关键关系，如“条款→术语→适用范围”或“设备→部件→故障模式”，以减少初期复杂度。
消歧与归并：同名不同义、不同名同义的情况很常见，例如“泵站 A”和“A 泵站”。我们需要通过指纹相似度（比如 Jaccard、Cosine）和规则（如行政区划、设备编号）做消歧与合并，以保证图结构整洁。低置信度的抽取结果则放入离线审核队列。
4.2 多路召回与重排：分别听专家意见
GraphRAG 依然需要做文档召回，只是策略更成熟：
- 多路召回：同时使用倒排索引（BM25）和向量检索（如 OpenAI embeddings、BGE、E5 等）召回候选段落。BM25 负责抓住关键词命中，向量检索负责捕捉语义相似，二者互补。
- 交叉编码重排：对召回的前 K 个候选，使用更强的交叉编码器（如 “bge-reranker-base”）逐一比较问题与段落，给出精确得分。这个步骤可以极大减少“似是而非”的干扰。
4.3 路径搜索：让“问答”变成找“路线”
在召回的候选中，我们还会用图谱搜索拓展候选。例如，问题涉及“设备 A 的启动条件”，我们可以沿图谱寻找与设备 A 相关的部件、启动操作、互锁条件对应的条款；然后再到文本里检索这些条款具体描述。这就是“先图后文”的策略，反过来“先文后图”也可以：先用文档抽取出的实体补边形成新的图路径。
4.4 证据包：整合“路径 + 原文”并打包
与传统做法不同，GraphRAG 返回的不再是几段无序文本，而是一个清晰的证据包（Evidence Pack）：包含路径（实体和关系）、原文片段（段落或表格）、来源（文档 ID 或 URL）、版本号、时间戳和段落位置 (offset)。生成端不会无目标地使用所有材料，而是按照证据包逐一引用并作答。这大幅减少冗余信息，并且形成了清晰的溯源链路。
举例：法规问答中，如果问题是“某条法规在哪些情况下适用？”，GraphRAG 可能会沿图谱找到“条款 → 适用范围 → 子条款”路径，分别拉取对应段落，然后在答案中列出条件并引用证据。
5. 检索感知训练：教模型学会“翻书”而不是死记硬背
在传统 RAG 中，模型往往被动接受外界喂来的上下文，对其中的噪声与有用信息一无所知。检索感知训练（Retrieval-Aware Training）试图改变这一点，让模型主动意识到“何时需要检索、该检索什么、如何引用”。
5.1 Self-RAG：自检索、自反思
Self-RAG 提供了一种让模型在推理过程中“自我评价”的循环：模型先生成一个草稿答案，然后对答案进行自我评分并检索更多证据，再更新答案，直到达到预设的置信度或步数上限。这种方法有助于开放域问答与长文生成，但推理链较长，需要在工程上限制迭代次数和费用。
5.2 RAFT：在训练中显式标注“干扰与引用”
RAFT（Retrieval-Augmented Fine-Tuning）会在训练数据中明确指出哪些检索段落是干扰项，哪些是有用信息，并要求模型在生成答案时引用正确的来源。例如，对于一个问题，向模型展示 5 段文本，其中只有 2 段是真正需要引用的，模型在训练过程中必须选择正确的段落并在答案中标注出处。这样训练过的模型在推理时就会更倾向于忽略噪声，引用正确证据。
5.3 RA-DIT：让检索器和生成模型“双向交流”
RA-DIT 不仅训练 LLM 学会引用，还训练检索器更懂得模型需要什么类型的段落。该方法分两个阶段：先微调模型学会引用，再使用模型的输出指导检索器权重（如向量召回的温度、BM25 的阈值），使检索器更符合模型偏好。这种端到端的训练通常带来最明显的性能提升，但需要更多计算资源。
5.4 实践建议：先从指令级或小规模微调做起
如果你有自己的标注数据集，可将问题-答案-证据列表录入，先进行 RAFT 样式的微调。若标注资源有限，可以采用两阶段策略：先用生成模型在合成数据上自动标注证据，然后再人工审核一小部分，最后用这些数据训练 LLM。对于 RA-DIT 需要的检索器微调，可在检索召回与重排模块做渐进式调参而不必一次做完。
6. 代理式编排 (Agentic RAG)：用“多步规划 + 工具调用”解决复杂任务
日常工作中的许多查询并不是“一问一答”，而是需要多步操作和跨多种工具。比如，诊断一次故障可能需要：查询设备手册 → 获取最近传感器数据 → 计算是否超出阈值 → 对照维护计划 → 给出处置步骤。RAG 本身只解决“知识查找”问题，如何管理工具调用和决策需要引入 Agent。
6.1 工具目录与路由：让 Agent 知道有哪些“工具”
代理式编排要求你把系统中可用的工具（SQL 查询、日志检索、表格计算、外部 API 调用等）注册成统一的“工具目录”。每个工具说明其输入格式、输出格式和权限限制。Agent 根据问题意图决定调用哪一个或多个工具，并在调用后把结果再交给检索组件或 LLM 进一步加工。
6.2 安全阈与预算：控制成本、步数和风险
为了避免 Agent 无限循环或误调用，必须设定一些硬阈值。例如：最多允许调用 4–6 个工具，超过则返回部分信息并提示用户补充；每次问答的预算上限为 0.50 元人民币，超出则自动降级到文本检索；P95 延时不得超过 5 秒，超过则采用“只读证据”的保守答案。
6.3 缓存和回放：提升效率与可复现性
在高频场景中，许多问题会反复出现。可以建立缓存键（如意图摘要 + 证据哈希），若命中则直接用缓存结果，跳过检索与生成。如果系统调用了 SQL 或执行了计算，也要记录输入参数与输出结果。这样既能提升效率，也便于日后的问责与审计。
7. 新鲜度和流式索引：让知识库“活起来”
知识过期是 RAG 系统的大敌。为了避免生成含糊或错误的答案，需要建立起完整的新鲜度管理机制。
7.1 CDC 与增量嵌入：快速更新索引
CDC（Change Data Capture）是一种捕捉数据库变化的方式。你可以用它实时或定期读取新增、修改和删除的文档信息，并立即对这些文档做切块、嵌入和索引更新。对于新闻、行情、舆情等高速变化领域，可以设置每小时或更短时间的增量更新。
7.2 TTL 与版本策略：明确“保质期”和“优先级”
不同类型的文档需要不同的 TTL（Time-To-Live）。例如，法规可以设置 3–6 个月的 TTL，到期后优先召回最新版本；标准作业指导书可能每年更新一次，可以更长；新闻与行情则需要更短的 TTL（按天）。同时需要提供版本策略，如“最新优先”“稳定优先”“历史版本复查”三种模式，根据业务需求切换。
7.3 流式评测与监控：快速发现和修正问题
对于热点问题（如最近的公告、热点故障），可以建立一套滚动的离线评测集，每周或每日更新。监控指标包括召回命中率、重排 NDCG、P95 延迟以及单问成本。当发现某个问题的答案波动或过时时，及时查找原因（比如是否文档缺失，或 TTL 配置不当），并修正。
8. 参数级知识更新（可选）：微调和模型编辑的双刃剑
当知识重复度很高、答案格式固定、且几乎不会变更时，把这些知识注入模型参数内可能更经济。但请注意以下几点：
- 使用轻微调（LoRA/Adapter）：只调整几个增量参数，不改变模型主体，让模型学会特定语气、格式或步骤。
- 极少数使用模型编辑：仅对个别事实（如名称更正）做外科手术式编辑，需谨慎使用，因为可能影响其他知识。
- 永远遵循“证据优先”原则：即使参数内有知识，生成时仍应引用外部证据确保准确性，防止过度自信。
9. KBLaM 的启示：如何在受限环境中构建“可信 RAG”
在国产服务器或无法访问外网的场景中，企业往往需要遵循更严格的数据安全和合规要求。这与 KBLaM 的研究背景类似：该模型通过预先编码知识库和矩形注意力将外部知识嵌入到模型中，免去了在线检索模块的依赖。不过，KBLaM 并不适用于所有任务，尤其是那些需要多模态检索或实时知识更新的情况。我们可以借鉴其工程思想，构建一个可信、可控、可解释的 RAG 管线，既满足内网约束，又能发挥检索增强的优势。
9.1 为什么要借鉴 KBLaM？
KBLaM 强调“知识是一等公民”，所有知识条目在离线阶段被编码为固定长度的键值向量，并配合矩形注意力高效融入模型。虽然 RAG 依然需要检索模块，但从 KBLaM 可以学到三件事：
- 统一知识层：文本、表格、图像描述和知识图谱的数据源应统一管理，记录向量表示和元数据（来源、版本、时间戳、密级），便于多模态检索和后续审计。
- 证据链构建器：每条回答都要附带一个完整的 Evidence Pack，其中包含原文片段、版本号、时间戳、实体路径、检索得分等信息。这既是给模型生成答案的依据，也是提供给用户或监管部门的溯源链路。
- 审计与回放：所有问题、检索路径、证据包、生成答案、校验结果和成本开销应写入审计日志，方便事后复盘和性能监测。
9.2 统一知识层与证据链
统一知识层旨在把各种知识载体融汇到同一检索体系中：文本段落、结构化表格、图像中的文字说明、实体关系及其元数据均存储在同一知识索引里，使用多模态嵌入模型将它们编码到统一向量空间。这样，当用户提问时，无论问题涉及哪一种数据类型，都可以通过统一检索接口召回候选证据。
在此基础上，证据链构建器会把检索结果按照固定格式打包为 Evidence Pack。例如，每个证据条目可以包含以下字段：
- source_id：原文档或数据表的唯一标识；
- url 或内部访问路径；
- version：文档或数据的版本号；
- timestamp：数据采集或生效时间；
- offset：在文档中的起止位置，便于高亮显示；
- path：实体关系或图谱路径（如果使用 GraphRAG）；
- scores：检索得分（BM25、向量检索、重排得分等）。
这些字段既便于 LLM 在生成答案时“按图索骥”，也便于用户在阅读时点击编号直接跳转原文，还为审计系统提供了完备的链路信息。
9.3 更易读的 RAG 流程伪代码
下面给出一个重新整理过的 RAG 流程示意伪代码，借鉴了 KBLaM 的工程思想但保持 RAG 的检索特点。与文章前半部的复杂表达相比，这段代码包含清晰的文档注释，帮助读者理解每一步的作用与输入输出：
from typing import List, Tuple
class Evidence:
source_id: str # 原文档或数据条目的唯一标识
version: str # 文档版本号
timestamp: str # 文档采集或发布的时间
offset: Tuple[int, int] # 在文档中的起止位置（起始索引, 结束索引）
path: List[str] # 图谱中的实体关系路径（可选）
scores: dict # 检索和重排分数，如 {"bm25": 12.7, "dense": 0.83, "rerank": 0.91}
def rag_answer(question: str) -> Tuple[str, List[Evidence]]:
"""
用 RAG 流程回答用户问题，并返回答案文本和证据列表。
参数:
question: 用户提问的自然语言字符串。
返回:
answer: LLM 生成的回答文本，内部引用了证据列表中的条目（用 [1][2] 形式标记）。
evidences: 一个证据对象列表，其中每个元素记录了原文段落、版本号、时间戳、位置和检索得分等信息。
流程说明:
1. 分类: 根据问题内容识别其类型（如法规、设备流程、FAQ）和敏感级，决定是否允许调用图谱等高级模块。
2. 检索路由: 根据意图选择合适的检索器组合（文本库、图谱、表格、代码库等）。
3. 多路检索: 使用 BM25 与向量检索从知识层召回候选片段，并用重排模型筛选出 2–3 段最相关证据。
4. 图谱搜索 (可选): 若需要多跳推理，沿知识图谱搜索相关实体路径，将其对应的原文片段并入候选集合。
5. 证据打包: 按 Evidence 定义打包候选片段，包含来源、版本、时间、offset、路径和检索得分。
6. 答案生成: 将问题与证据包一并送入 LLM，采用抽取式模板生成答案，并在正文中用 [n] 标注引用编号。
7. 结果校验 (可选): 对答案中涉及的数值或逻辑调用规则引擎、SQL 或计算器进行校验，若未通过则重新检索或提示人工处理。
8. 审计日志: 将问题、证据包、生成答案、校验结果以及推理成本记录在日志系统，便于后续复查与评估。
"""
# 第 1 步: 问题分类
intent = classify(question)
# 第 2 步: 选择检索路由（文本、图谱、表格等）
retrieval_route = select_route(intent)
# 第 3 步: 多路召回并重排
candidates = retrieve_candidates(question, retrieval_route)
ranked_candidates = rerank(candidates)
# 第 4 步: 若需要图谱信息，沿图谱检索额外证据
if intent.requires_graph:
graph_paths = search_graph(ranked_candidates, question)
ranked_candidates = merge_with_graph(ranked_candidates, graph_paths)
# 第 5 步: 打包证据
evidences = pack_evidence(ranked_candidates)
# 第 6 步: 抽取式生成答案（引用 evidences）
draft_answer = generate_with_evidence(question, evidences)
# 第 7 步: 如果需要，对答案进行校验并必要时修正
if need_verification(draft_answer):
final_answer = verify_and_refine(draft_answer, evidences)
else:
final_answer = draft_answer
# 第 8 步: 记录审计日志
log_audit(question, final_answer, evidences)
return final_answer, evidences
这段伪代码并不涉及 KBLaM 的“矩形注意力”机制，而是聚焦于 RAG 流程中每一个必须处理的环节：意图识别、检索路由、候选召回与重排、图谱补充、证据打包、抽取式生成、结果校验及审计落库。通过详细注释，它提供了一个易于理解且可执行的框架，读者可以根据具体业务需求替换内部函数的实现。
10. 成本模型和案例：算明白账，才能决策
为了让大家对“直塞上下文”与“证据包 RAG”的成本差有个直观认识，我们做了一个示例计算。
10.1 输入 token 数量是关键
假设要回答的问题需要用到一份 3 万字的 SOP 文档。如果采用“直塞上下文”方式，将整份文档和模板全部放入模型，输入 token 可能超过 30k；如果采用“检索+证据包”，通常只需要 1~~3 段关键段落，每段大约 500~~700 token，总共约 1.5k~2.1k token。这意味着输入 token 减少了至少 10 倍，在同样的模型计费方式下，费用和延时也会近似线性下降。
10.2 多一步检索等于多一点成本，但回报更高
有人担心检索和重排也需要成本。实际情况是：文本检索（无论 BM25 还是向量检索）对硬件要求低，成本远低于模型推理；重排用的交叉编码器模型比主干 LLM 小很多，也可以在 CPU 或小 GPU 上运行。因此，整体来看，“先检索后生成”在大多数场景里都是更省钱更稳定的。
10.3 能力与成本的折中
真正需要在直塞和 RAG 之间做取舍的，是一些特殊场景，比如必须引用大量长文本、或需要生成大段自由文本的内容创作。在这些场景下，可以先试试混合策略：先用 RAG 提供精确的事实支撑，再把部分自由发挥留给大上下文窗口。关键是算清楚每种策略的 token 数量、调用次数和对应费用，再根据业务需求决定。
11. 实施清单：从原型到生产
如果你希望快速在公司内部部署一套可信的 RAG 系统，可以参考以下实施清单：
- 数据治理：对现有文档做脱敏、按密级分级；记录来源和版本。
- 切块策略：以小节为单元切块，辅以滑窗，避免“跨块断句”。
- 检索基线：搭建 BM25 + 向量检索 + 重排；针对表格、代码、图表设计专项检索器。
- 证据包标准：包含
source_id、url、version、timestamp、offset、path等字段，并生成唯一answer_id用于审计。 - 生成模板：以“依据 [1] … [2] …，得到结论 …”的形式输出，确保引用证据并用自然语言串联。
- Agent 管理：列出可调用工具和条件，设定步数/预算阈值；缓存常见查询结果。
- 新鲜度管理：启用增量抓取和嵌入；设置 TTL 和版本策略；构建滚动评测集。
- 监控与回放：建立仪表盘监控召回率、重排得分、P95 延时、单问成本；提供问题→证据→答案→工具轨迹的回放功能。
- 灰度发布：新模型或策略上线前，先在一小部分用户或请求中试点；对比指标，与基线版本差异显著时再逐步放量。
- 团队协作：检索、图谱构建、模型训练、工程部署各司其职，建立问题反馈和快速修复流程。
12. 下一站：RAG 的改进方向与前沿思路
正如 KBLaM 项目总结中提到的，虽然 RAG 体系已经基本成型，但仍有很多值得探索的前沿工作。我们结合社区的最新研究与我们的实践，提出以下方向供参考。
12.1 动态检索与门控机制
当知识库规模从几千条增长到几十万条或更多时，盲目检索会消耗可观资源。可以引入类似 ExpertRAG 的动态门控机制：模型首先判断自身内部知识是否足以回答，如果不足才检索；检索时仅激活与问题最相关的“专家”或知识块，用稀疏门控策略选择分区。这样的门控可以是可学习的，也可以根据查询关键词规则构建。
12.2 层次化或混合检索
针对长文档或多跳任务，采用“粗筛–精排”的二阶段检索。先用稀疏检索或关键词匹配在文档级别选出候选文档，然后在候选文档内部用向量检索挑选段落，再送给重排器。HiRAG 提供了这种思路，并在多跳问答中取得不错效果。
12.3 保留结构信息的知识编码
现有许多图谱或 KB 结构被压缩为一个向量，这会丢失词序、数值大小、关系方向等信息。可以尝试拆分三元组，让头实体、关系、尾实体各自编码为不同 token；或为实体构建邻域子图，用图神经网络生成结构化嵌入；在生成阶段，用 chain-of-thought (CoT) 将图中的路径串联起来。此外，还可以引入数值编码，让数字与日期以标量或字符级方式参与注意力计算。
12.4 自适应压缩与知识选择
KBLaM 的论文提到可以通过调整向量压缩率控制显存开销；下一步可以让模型自己学习为哪些知识赋予更大的向量空间。方法包括引入重要性评分网络，依据知识条目的访问频次、置信度或领域价值分配向量维度，甚至直接丢弃对任务无关的知识令牌。这类似于混合专家模型 (MoE) 的动态路由。
12.5 多语言与跨语言检索
随着业务国际化，RAG 需要在不同语言知识库之间进行检索与推理。研究表明，跨语言检索的难点主要在于“推理链路”，而非简单的文本翻译。可采用多语种嵌入模型（如 gtr-xxl 或 multi-qa-mpnet）将不同语言映射到统一空间，同时在检索与生成阶段标注语言标签或添加门控层，帮助模型选择正确语言生成。
12.6 引入外部校验与链路自洽检查
即使有知识令牌，模型仍可能幻觉或引用错误条目。可以为 RAG 系统增加后端校验：例如在模型回答后，对涉及的实体关系调用图数据库进行核查；若存在矛盾或缺失信息，则触发重新检索或拒答。也可以在图谱层检查被选择的知识令牌之间是否存在合理路径；若缺乏逻辑连接则提示检索器再次挑选。甚至可以结合传统 RAG，再到外部网页交叉验证，降低误用风险。
13. 结语：RAG 的未来——地图不会过时，行囊只会更大
回顾本文，我们尝试回答“长上下文会让 RAG 过时吗？”这个问题。答案是否定的：RAG 解决的是“找资料和引用资料”的问题，这与上下文窗口大小无关。长上下文带来了便利，但它无法解决成本、时效、审计与隐私等现实约束；也无法在多步推理或结构化任务中帮助模型规划路径。
2025 年的 RAG 已经呈现出一套“骨架 + 翻书 + 工具 + 新鲜度 + 适度知识注入”的五件套范式。GraphRAG 让复杂问题有迹可循，检索感知训练让模型学会“翻书”，代理式编排让多步任务井然有序，新鲜度管理保证知识不会过期，必要的参数级更新则让模板化知识更省。KBLaM 给出的统一知识层、证据包与审计链路思想，为高合规场景提供了落地范式。
未来，随着动态检索门控、层次化检索、结构化知识编码、自适应压缩和多语言协同的进一步研究，RAG 将继续演进，甚至与像 KBLAM 这样的知识注入模型深度融合。无论未来如何发展，有一点可以确定：在有限预算和复杂场景下，检索仍然是大型语言模型的最可靠伙伴。请记得，带一张会更新的好地图，再大的行囊也不怕沉。
参考文献（推荐阅读）
- Akari Asai et al., Self-RAG, arXiv, 2024.
- Microsoft Research, GraphRAG, 2024.
- Naman Bansal, Best Open‑Source Embedding Models Benchmarked and Ranked, Supermemory Blog, 2025.
- Haoyu Huang et al., HiRAG: Retrieval‑Augmented Generation with Hierarchical Knowledge, arXiv, 2025.
- Esmail Gumaan, ExpertRAG: Efficient RAG with Mixture of Experts, arXiv, 2025.
- Hang Luo et al., Causal Graphs Meet Thoughts: Enhancing Complex Reasoning in Graph‑Augmented LLMs, arXiv, 2025.
- Wei Liu et al., XRAG: Cross‑lingual Retrieval‑Augmented Generation, arXiv, 2025.
阅读完上述论文和报告，你可以更深入理解本文提到的技术和趋势。在未来，RAG 与知识库融合将继续发展，欢迎持续关注并尝试在自己的项目中实践改进。