PDF明明写着答案,RAG为什么还是答错了?

很多知识库答错，不是大模型不会回答，而是文档转成文本时已经丢失了表格、图片和版面关系。PixelRAG尝试绕过这一步：直接检索网页截图，再让视觉语言模型读取证据。本文拆解它的工作方式、论文结果，以及企业落地时更现实的混合方案。

知识库已经收录了产品手册，用户问了一个明确的参数，它却答错了。

遇到这种情况，团队很容易把注意力放在最后一环：提示词是不是不够严谨？模型是不是不够大？要不要再加一个重排器？

可如果答案在文档进入系统时就被拆散，后面的模型再强，也无法把原页面完整还原。

一、一份写着答案的文档，怎么会被“读丢”

设想一个常见的售前场景。

客户正在确认设备选型，销售小周询问内部知识助手：“X200控制器在40℃环境下，最多支持多少路同时采集？”

答案就在产品手册第27页。页面上是一张双层表头：横向区分环境温度，纵向区分设备型号。人只要找到对应的行列交点，就能读出参数。

知识助手却引用了另一个型号的数据。

沿着RAG链路往前检查，问题可能出在文档解析。常见系统会先把PDF或网页转成文本，再分块、生成向量并建立索引。表格在转成连续文本后，表头与数值的对应关系可能消失；网页侧栏、正文和图片说明也可能混在一起。图片中的文字如果没有经过识别，甚至不会进入索引。

模型最后拿到的不是“第27页的规格表”，而是一串失去位置关系的型号和数字。

图1：原页面中的行列关系，在纯文本解析后可能被打散。

二、PixelRAG改的是文档入口

2026年6月，[PixelRAG论文](https://arxiv.org/abs/2606.28344)提交至arXiv。这项研究在Berkeley SkyLab、BAIR和Berkeley NLP完成，作者来自多所机构。

它提出的问题很直接：网页本来是二维视觉页面，为什么一定要先压成纯文本，再交给RAG？

PixelRAG把处理流程改成四步：

使用浏览器渲染网页，保留文字、表格、图片和排版；
把页面切成截图块，并生成视觉向量；
根据用户问题，从截图索引中召回相关页面；
由视觉语言模型读取截图并生成答案。

这样做以后，检索结果不再是一段被抽离出来的文字，而是一块保留原始版面的页面。视觉模型可以同时参考内容和位置：某个数字位于哪一列，标题与正文是什么关系，信息框是在侧栏还是正文区域。

“像素原生”也不等于完全没有预处理。系统仍要下载网页资源、清除非正文元素、渲染并切图。它绕过的是HTML转纯文本的过程，没有省掉数据工程。

>图2：PixelRAG从页面渲染、视觉检索到截图阅读的基本流程。

三、它为什么连纯文本问题也能提升

表格和图片适合视觉模型并不难理解。论文中更有意思的结果，是PixelRAG在Natural Questions和SimpleQA这类文本型测试中也超过了文本RAG。

实验统一使用Qwen3.5-4B作为阅读模型，每次读取3个检索结果。部分结果如下：

| NQ | 55.9% | 58.7% | +2.8个百分点 |

| NQ-Tables | 42.5% | 48.8% | +6.3个百分点 |

| SimpleQA | 71.6% | 78.8% | +7.2个百分点 |

| EVQA | 31.5% | 45.1% | +13.6个百分点 |

论文还拆解了SimpleQA中的文本检索失败样本：36.6%属于解析损失，答案在网页文本化时被删掉；55.2%属于排序损失，答案进入索引，却没排进前3；8.2%属于阅读损失，证据被召回后，模型仍读错了表格或列表关系。

这里有一个容易忽略的细节。网页信息框通常包含大量实体关键词，转成纯文本后，很容易因为词语相似度高而挤进检索结果。视觉检索还能看到它位于侧栏、有独立边框，从而把内容相似度与页面位置一起考虑。

上述数字只适用于论文的数据集、模型和配置，不能直接换算成企业知识库上线后的收益。它们的价值在于提醒团队：检索失败不全是向量模型的问题，文档表示方式本身也会影响结果。

四、不做OCR，成本会不会更高

会增加一些成本，尤其是存储和视觉模型调用。论文中的Wikipedia截图接近6TB，还没有算企业场景中的增量更新、版本管理和权限变化。

不过，只比较单次模型调用价格也不够。

论文中一张截图块约对应875个视觉Token，文本基线每块为1024个Token。在MoNaCo多步搜索实验中，PixelRAG累计使用约360万Prompt Token，文本方案约3750万。按照该实验配置计算，PixelRAG总成本约为其他方案的二分之一到四分之一。

原因并不神秘：一张页面截图可以同时保留文字、表格和位置，证据密度更高，系统可能用更少的检索轮次完成任务。

但这仍是论文环境中的结果。企业真正做成本测算时，需要把图片存储、离线渲染、索引更新、推理延迟和人工复核放在同一张表里。

五、企业知识库更适合从混合方案开始

如果现有文本RAG已经上线，没有必要把整套系统推倒重来。更稳妥的做法，是保留文本链路，再补一条视觉链路。

文档入库时，同时生成文本块和截图块。用户提问后，两套检索分别召回候选证据，再根据问题与文档类型决定由文本模型、视觉语言模型或两者共同阅读。

回到小周的场景：系统发现候选证据来自多层表头页面，于是优先走视觉链路，返回对应截图并标出行列交点。如果他问“这份手册适用于哪些设备”，纯文本已经足够，就不必支付视觉模型的成本。

这套方案会涉及几类人：销售和客服提供真实问题，运营整理高频错误，产品经理定义路由与验收指标，算法和工程团队建设视觉索引，业务负责人判断准确率提升能否覆盖新增成本。

改造前，销售发现答案可疑，往往要重新打开手册、翻页核对，再把结果复制给客户。加入视觉链路后，系统应当把答案、原页面、页码和命中区域一起返回。销售仍然负责最终确认，但复核对象从整份文档缩小到一块明确证据。

项目成本也不只是一笔模型费用。前期要整理测试问题和标准答案，工程侧要增加页面渲染、视觉索引与路由，运营要持续处理失败样本，使用者还需要了解哪些答案必须人工确认。文档数量不大时，试点可能由一名产品经理、算法和后端工程师共同完成；进入生产后，还要补上权限同步、增量更新、日志监控和模型费用控制。

收益则要落到业务动作上。售前场景可以观察查找一条参数需要多久、错误参数被引用了多少次、每次回答需要几分钟人工复核。试点没有跑完之前，不应提前写成“效率提升30%”，而要先建立基线，再看视觉链路能减少多少重复查找和错误引用。

试点可以先选解析失败率高的文档，例如规格表、扫描合同或图文混排手册。使用同一组真实问题，对比文本RAG、PixelRAG和混合RAG，至少记录四项指标：前K证据召回率、最终回答正确率、平均响应时间和单次任务成本。

>图3：结构简单的文档继续走文本链路，复杂页面再调用视觉能力。

六、PixelRAG目前还有哪些边界

第一，它依赖较强的视觉Embedding和视觉语言模型。企业如果只能部署较弱的本地模型，论文结果未必能够复现。

第二，截图不能天然保留可点击的超链接。URL、锚文本、权限、文档版本和有效期仍要作为结构化元数据保存。

第三，当前论文主要使用英文Wikipedia和英文新闻数据。中文网页、财务报表、扫描合同和企业产品手册，需要用自己的测试集验证。

图片内容的治理也更麻烦。文本可以使用关键词、规则和分类模型批量过滤，截图中的隐私与误导性内容更难检测。

最后，PixelRAG目前是arXiv预印本，还不是成熟的行业标准。文本解析也没有因此失去价值。结构清晰、更新频繁、对延迟敏感的知识库，文本RAG依然便宜且容易维护。

七、先检查证据，再考虑换模型

产品经理判断是否引入PixelRAG，可以先问两个问题：现有错误中，有多少来自解析和版面丢失？答案是否经常藏在表格、图表、扫描页或复杂排版里？

如果答案都很明确，再挑一批问题文档做小规模对照实验。先确认增量收益，再决定是否扩大视觉链路。

下次知识助手答错一张表时，不妨打开它真正召回的证据：表格还在吗？行列关系还在吗？图片和标题进入索引了吗？

如果这些信息已经丢失，继续修改提示词通常不会有太大帮助。

你所在的团队做知识库时，最常见的问题是文档解析丢失、检索没有召回，还是模型拿到证据后仍然答错？