RAG 的现状、老问题，以及那条「像素方案」
「RAG 已死」这种标题这两年轮着上：先是长上下文说要取代它，后来 Agent 说要吸收它。但把噪音去掉，真实情况更像一句评价：RAG 没死，它长大了——从「一条流水线」长成了「一个分层能力」。
这篇聊四件事：传统 RAG 的结构性毛病 → 2026 年的现状与主流解法 → 一个被低估的问题（解析损失） → 最近很热的「像素方案」（视觉/像素级 RAG）到底是什么、什么时候值得用。
文中行业数据来自公开资料（论文、厂商博客、技术评测），统计口径与时点不一，已尽量标注；相关结论请以原文为准。本文也会连到本站已有的 agent / 协议系列。
一、传统 RAG：一条流水线，三个结构性毛病
老配方大家都熟：
文档 → 解析成文本 → 分块（chunk） → 向量化（embedding） → 向量检索 Top-K → 塞进提示词 → 生成
它在「FAQ 式单跳问答」上很好用，但一到企业深水区就露怯：
| 毛病 | 表现 |
|---|---|
| 全局视野缺失 | 只能召回 Top-K 个孤立片段，问「这批文档整体在讲什么趋势」就废了 |
| 多跳推理无能 | 向量余弦相似度表达不了拓扑关系，问「A 的供应商里谁也给 B 供货」很难 |
| 一次检索定终身 | 单向管道，没有自我评估与查询重写：检索错了，后面全是幻觉 |
再加两个工程现实：延迟与成本（向量检索 + 重排不可避免，长上下文也很贵）、「像」不等于「对」（向量库只判断相似度，不承载结构化关系与时序）。
二、现状（2026）：四条主线和一条底线
底线：长上下文没有取代 RAG
百万 token 上下文确实能「把整本书塞进去」，但成本不划算（有评测称用大模型直接做检索任务，成本可比专用 embedding 模型高三个数量级），而且慢。结论是互补：能用检索毫秒级过滤出「真正决定决策的少量 token」，就别用冗余数据灌满模型。
主线一：把检索质量做扎实（混合检索 + 重排 + 压缩 + 路由）
工程共识是按需叠加，而不是全上：
| 层 | 解决什么 | 什么时候加 |
|---|---|---|
| 检索 | 召回 | 永远的基础（稠密 / 稀疏 / 混合） |
| 重排 | Top-K 精度 | 噪声大、查询有歧义、准确率要求高 |
| 压缩 | token 成本 | 上下文贵、召回片段冗长 |
| 路由 | 多数据源/多策略 | 多源、多跳、意图差异大 |
有调研称「混合检索 + 重排」的架构可把问答准确率提升 30%+（来源见文末）。另一条值得记的是 Contextual Retrieval（Anthropic）：给每个块补「上下文说明」再索引，公开数据称检索失败率降低约 49%，叠加 Contextual BM25 + 重排后约 67%。
主线二：GraphRAG（从「像不像」到「连不连」）
用「实体—关系」知识图谱 + 社区摘要（Leiden 聚类）补上全局视野与多跳推理。公开实测对比很醒目：多实体关系推理场景 GraphRAG 85%–92%，传统 RAG 45%–60%。但代价也明确：索引与维护成本是传统方案的 2–3 倍，且需要持续实体对齐。单跳问答别上它——那是杀鸡用牛刀。
主线三：Agentic RAG（RAG 变成循环）
把「检索」从流水线里的一个模块，变成 Agent 循环中的一次决策：分解 → 路由 → 检索 → 反思 → 重规划 → 再检索。好处是自主决定「检索几次、检索哪儿」，坏处是延迟与成本上升（用缓存、小模型路由、并行检索来压）。
注意措辞：不是 Agent 干掉 RAG，而是 Agent 把 RAG 吸收成了自己的能力——这正是本站 LangGraph 这类编排框架的主场。
主线四：往「记忆」和「上下文工程」走
RAG 正在从「外部知识补丁」变成 AI 认知结构的一部分：长期记忆分层、上下文压缩（有研究称上下文工程方法可减少 19%–53% 的 token）等。这一层的竞争对手不是别的框架，而是你系统的整体设计。
三、被低估的老问题：解析损失（Parser Loss）
上面说的是「检索层」的问题，但还有一层更靠前、更隐蔽：你的文档真的被读对了吗？
传统流程里，PDF 要先被解析成文本：OCR、版面检测、表格还原、分块——每一步都可能丢信息：
- 表格变成一坨错位的文本；
- 图表/示意图直接消失；
- 版面对语义的贡献（哪个数字属于哪一行、脚注挂在哪）被压平。
有研究（Berkeley / Princeton / EPFL / Databricks 的联合工作）在 Wikipedia 1,000 题基准上发现：超过三分之一的 RAG 失败可以追溯到解析损失。ColPali 论文也直说了：OCR + 版面检测 + 结构重建这套索引流程「可能很慢、容易传播错误，且难以考虑页面里更多的视觉元素」。
关键推论：如果你的数据源是「版面本身承载信息」的文档（财报、技术手册、带图表的论文），那么在检索之前，信息就已经丢了——后面再怎么调 embedding、加重排，都补不回来。
四、像素方案：直接检索「页面图像」
于是有了一条思路很直接的路：别把文档压成文本，直接把页面当图像来检索。
三条路线的差别（很关键）
| 路线 | 做法 | 优点 | 失败模式 |
|---|---|---|---|
| ① 先生成 Caption 再索引 | 用视觉模型给每张图写「描述文本」，复用现有文本管道 | 最省事、可读、易调试 | 静默遗漏：Caption 没提到的信息，永久检索不到 |
| ② 联合嵌入（CLIP 系） | 图像与文本映射到同一空间，文本查询直接打图像 | 适合商品目录、图库等「照片型」语料 | 图中文字盲区：内容以文字为主时，它按整体视觉语义匹配，而不是按句子 |
| ③ 直接对页面图像检索（ColPali 类） | 页面切图块，视觉模型输出逐图块向量，查询按 token 匹配图块 | 对文档语料通常最强，原生保留版面/表格/图表 | 存储与查询成本高；纯关键词精确匹配不如 BM25 |
ColPali 的机制（一句话版）
- 把每一页当成一张图，用视觉语言模型（PaliGemma-3B，SigLIP-So400m 视觉编码器 + Gemma 2B）编码成一组逐图块（per-patch）向量；
- 查询同样编码成逐 token 向量；
- 用 ColBERT 式的晚期交互（late interaction） 打分：每个查询词找最匹配的图块，分数求和；
- 因此匹配能定位到页面某个区域，而版面、图表、表格「从未被压平成文本」，自然保留；
- 为省存储，向量投影到 128 维；配套基准是 ViDoRe。
代价：把存储算清楚（这决定它能不能上）
这是像素方案真正的门槛。按公开的配置（每图块 128 维、约 1030 图块/页）：
| 方案 | 每页向量 | 每页存储 | 10 万页 |
|---|---|---|---|
| 单一稠密向量 | 1 × 1024 维 | fp32 约 4.1 kB / fp16 约 2.0 kB | 约 200 MB（fp16） |
| 逐图块晚期交互 | ~1030 × 128 维 | fp16 约 264 kB | 约 26 GB |
200 MB 和 26 GB 是两种基础设施决策。所以常见工程做法是：把晚期交互当「重排阶段」用——先用便宜的检索召回候选页，再用像素级模型精细打分；或者像 PixelRAG 的实现那样走单向量 + 交叉编码器重排的路线（同样语料单向量约 200 MB，用重排器补精度），并配合二值量化 / 池化把体积压下来。
另有厂商（Morphik）报告在金融文档基准上做到 95.56% 准确率，而其它端到端方案最高约 67%——这类数字要按语料看待，别当通用结论。
什么时候该用、什么时候别用
适合：
- 财报、技术手册、带图表的论文——版面本身承载语义；
- 需要对「某区域」定位（比如「Q3 营收那个数字旁边的趋势图」）。
不适合：
- 需要可复用的干净文本（复制法律条款、把表格导回 Excel）；
- 需要精确字面匹配（查序列号、错误码）——纯文本 BM25 往往更准也更省。
实践建议（这段最值钱）
- 按证据类型路由，而不是二选一：文本优先、视觉优先、混合，各自解决不同问题；不要直接混不可比的原始分数，先按证据类型路由再融合排名；
- 保留坐标：页级命中对生成太粗，要能细化到「页面内的哪个区域」；
- 先评测检索，再评测回答：没被召回的证据，再强的 VLM 也救不回来；
- 所有模态都是不可信输入：文本、OCR、Caption、像素里都可能藏 Prompt Injection；建议保存「原始资产 → 派生单元」的证据链，带归一化坐标、hash 与解析器版本；
- 记住它没解决的那部分：像素方案治的是「解析损失」，不治多跳推理、时效性、全局聚合——那些还是 GraphRAG / Agentic RAG 的活。
五、一张选型表（把这篇收口）
| 你的问题 | 先考虑 |
|---|---|
| 单跳 FAQ、语料是干净文本 | 混合检索 + 重排（别过度设计） |
| 检索结果噪声大 | 加重排（Cross-Encoder / BGE-Reranker / Cohere Rerank） |
| 需要多跳、全局聚合、可审计推理链 | GraphRAG（先评估维护成本） |
| 检索时机不确定、要自主决策 | Agentic RAG（RAG 被 Agent 吸收） |
| 文档版面承载信息、解析总出错 | 像素方案（视觉 RAG） |
| 长文档一次性理解、预算充足 | 长上下文（当补充，别当替代） |
六、一句话总结
- RAG 现在的正确问题不是「用不用」，而是「每个 Agent 在推理的哪一步、用哪种检索、在什么预算下」；
- 解析损失是被长期低估的一环——三分之一以上的失败可能在检索之前就注定了；
- 像素方案不是万灵药：它用存储与成本换版面保真，适合视觉文档，不适合要干净文本和精确匹配的场景；
- 最实际的架构是混合：文本检索打底、像素检索补版面、重排提精度、Agent 决定何时检索。
关联
- LangGraph 系列：Agentic RAG 的编排底座（状态图 + 条件边 + 记忆）
- Zod / MCP：工具与协议的 schema 层（检索结果进模型前的那道闸）
- Coze 对话流 vs 自主规划：确定性编排 vs 模型自主决策——RAG 的 Agentic 化是同一个问题的另一面
- Deep Agents：把「检索 + 读写文件 + 子任务」打包成中间件的思路
参考
- The New RAG Method that Searches Pixels instead of Text（Dutch Startup TV）
- ColPali: 利用视觉语言模型实现高效文档检索（Hugging Face 中文博客）
- Multimodal RAG: Retrieving Over Images and Text（Multigrid）
- 多模态 RAG：生产级架构、检索与评测指南（QubitTool）
- Graph-RAG 到 Agentic RAG：2026 年知识检索四大新范式与选型指南
- 2026 年 RAG 技术栈分层指南：检索、重排、压缩、路由何时该加（RadarAI）
- RAG Isn't Dead, It Just Grew Up（Paradigma Digital）
声明：本文为公开资料整理 + 个人判断，无厂商合作。文中性能/成本数字来自上述来源，口径与时点不一（尤其准确率类指标强依赖语料），选型前请自行在自己的数据上评测。