一张产品规格表，左边是型号，上面是接口名称，单元格里写着“支持”或“可选”。把页面转成纯文本后，这些词可能都还在，却很难知道“可选”究竟属于哪个型号。问答系统即使检索到了正确页面，也可能把两个产品的参数拼在一起。
遇到这种错误，值得先保存检索结果，看看模型实际收到了什么。若关键行列关系在抽取时已经丢失，继续修改回答提示词往往收效有限。PixelRAG 提供了一条可以试验的路线：把页面渲染成截图片段，对图像进行检索，再让视觉语言模型阅读命中的片段。官方仓库
本文按 2026 年 9 月 23 日查阅的仓库与论文讨论选型和验证方法，没有运行完整模型与大规模索引。下面的产品表例子用于设计测试，不是项目实测成绩。
先区分两种看起来相似的失败
假设问题是“乙型号是否支持双显示器输出”。系统答错，至少有两种可能：检索阶段只找到了甲型号的页面；或者已经找到乙型号的表格，却把相邻列读错了。
第一种需要检查召回与排序，第二种需要检查提供给模型的证据及其阅读能力。若你只保存最后的答案，两种错误会混在一起，团队可能花很多时间调错环节。
文本方案也有改进空间。解析器可以保留表头、把每行转成带字段名的记录，或为跨页表格补上上下文。不能因为某次纯文本抽取失败，就推断所有文本 RAG 都无法处理表格。
视觉检索的试验价值在于：当图表、布局或图例确实参与表达含义时，保留页面图像是否能减少这类损失。若原始资料本来就是短段落与清楚的标题，现有文本索引可能已经足够。
从网页到回答，中间仍有几步需要检查
PixelRAG 的基本流程包括渲染、切分截图、生成视觉向量、建立索引，以及检索后交给阅读模型。论文使用经过截图数据适配的视觉嵌入模型，并在多组问答任务上与文本等基线比较。论文原文
截图保留了页面外观，但也保留了页面当时的问题。懒加载图片尚未出现、字体没有加载、登录提示挡住表格，都会进入后续索引。浏览器能打开网址，不等于截图已经包含你需要的资料。
切分也会影响答案。若表头在上一张图，数值在下一张图，模型仍需同时拿到两张。若脚注解释某个型号的限制，却被裁到片段之外，只看主表就可能过度承诺。为每张截图保留来源、位置和相邻片段关系，后续才有办法补充上下文。
最后，检索命中也不等于回答正确。模型可能把小字中的“0”看成“O”，忽略单位，或把“最高支持”理解为标准配置。返回答案时应让读者能看到对应证据，而不只是一个漂亮的结论。
用十几道有答案的问题开始
第一轮不必处理整个知识库。挑一小批你有权使用的资料，包含纯文字页面、规则表格、复杂图示和几份扫描质量一般的文件。每道问题都写下答案、所在页，以及判断时需要看的区域。
产品表可以设计几类问题：指定型号的一个参数；比较两个型号同一字段；需要结合脚注才能回答的限制；资料根本没有说明的能力。最后一类很有用，它能检查系统是否会把空白单元格或相似产品的信息当成答案。
例如资料只写“支持外接显示器”，没有说明数量，标准结果就应是无法据此确定双屏支持。不要在评分时奖励系统碰巧猜中产品实际规格，因为当前资料并没有提供这个依据。
测试集还应放入名称相近的旧版和新版页面。如果问的是新版，命中旧版即使参数相同，也要记录来源不匹配。视觉模型可以读清楚表格，却无法替你决定哪个版本应该进入本次回答。
三条路线要使用同一组资料
可以比较现有文本流程、视觉流程，以及合并两种结果的流程。保持问题和来源版本一致，尽量固定阅读模型与回答要求。若同时更换模型、资料和检索方式，看到提升后很难知道是哪项改变起作用。
每道题分别记录召回是否包含答案、回答是否正确、引用是否对应，以及耗时。答案错了，再归类为没有召回、图片不清、读错关系或越过证据猜测。这样才知道下一步该修渲染、调整检索，还是改阅读提示。
合并结果时也要去重。同一页面的文字与三张截图可能同时排在前面，占掉上下文，却没有增加有效信息。可以先按来源与位置聚合，再选能共同说明问题的片段。
权限过滤必须覆盖两条路线。用户不能读取的文档，也不能因为它被渲染成图片就出现在视觉搜索结果里。测试账号的权限不同，应得到不同候选集合；这一点最好在接入真实内部资料之前验证。
把渲染试验和建立索引分开
项目提供 pixelshot 用于渲染，也提供索引与服务命令。第一次评估时，可以先检查几页截图，确认表头、图例、脚注都清楚，再下载模型和建立向量索引。
官方仓库的自建示例需要明确配置输入来源、嵌入模型和输出目录。仅安装依赖后执行构建命令，并不能说明工具知道你要处理哪批文件。复制示例时，要把样例路径换成自己的测试目录，并确认目录中没有混入不该上传或索引的资料。
PDF 渲染与网页渲染所需的依赖也可能不同。按所选版本的说明安装对应组件，保留依赖版本和构建日志。出现空白页面时，先直接检查渲染结果，不要等检索失败后才怀疑模型。
官方示例还展示了下载大型预建索引，基础索引约 217G。这个数字描述的是特定预建数据集，不能当作处理几十份文档的最低磁盘要求。你自己的容量要按页数、截图数量、图像大小和向量格式估算，再留出重建时的临时空间。
存储之外，还要计算更新和阅读成本
如果一个网页每周更新，旧截图与向量也需要跟着处理。只新增而不淘汰旧版本，会让系统同时检索到相互矛盾的参数。可以为来源记录内容版本或抓取时间，在替换完成后再切换可查询版本。
成本测量至少覆盖首次构建、少量文档更新和一次正常查询。首次构建慢不一定影响日常使用；反过来，查询需要取回多张大图，即使索引很快，下载和视觉模型阅读也可能占据主要时间。
压缩图片可以减少传输和部分模型输入开销，但小字、细线与单位可能先变得难读。应拿实际问题逐档测试，不能只凭肉眼觉得缩略图“差不多”。论文中的压缩结果有自己的模型与实验设置，不能直接套用为业务预算。
如果使用托管演示或搜索服务，还要区分检索的是服务方预建语料，还是你自己的资料。一个公开百科问题答得好，并不能证明内部产品手册已经进入索引，更不能证明你的权限控制已经生效。
还有一种需要单独测试的情况：页面没有给出完整答案。让系统回答“资料没有说明”，并展示已查看的区域，通常比从相近图表中猜一个数值更符合检索用途。评估表应把这种正确保留未知的结果计入，否则团队可能无意中鼓励模型在证据不足时也给出确定答案。
怎样判断试验值得继续
试验结束后，把错误样本摊开看。如果原来的主要问题是表格行列关系丢失，而视觉路线能在同一批问题上给出可定位的正确证据，就有理由把它接入这类文档。
若错误来自过期资料、问句含糊或召回了错误产品，优先修版本过滤、问题澄清和候选选择。增加截图未必解决这些问题，反而可能扩大维护范围。
也可以只对特定文档启用视觉分支，例如产品规格表与流程图，普通说明段落继续使用现有文本检索。上线以后保留失败问题和证据截图，定期回放，观察资料更新是否改变结果。选择哪条路线，最终应由你需要回答的问题和可复查的证据来决定。