多模态检索找不到图表内容时先检查哪一层索引

多模态检索找不到 PDF 里的图表时，先查“抽取层”，不要一上来重建向量索引。图表可能根本没有被抽取，也可能已经抽取却按纯文本 embedding，或者查询时选错了 collection；只有这些都正常，才轮到检查视觉 reranker。按“抽取 → 模态 → 集合/检索 → 重排”的顺序定位，通常能把问题收敛到一个配置层。

先查抽取层：图表是否真的进了索引输入

把问题分成两半：PDF 是否产生了图表元素，产生后是否被保存并向量化。抽取日志或中间结果至少要能回答三个问题：目标页有没有 table、chart 或 image；元素有没有页码和文档标识；元素内容有没有在对象存储或结果目录中留下可追踪记录。

如果只看到正文段落，说明故障在抽取层。此时先打开表格、图表和图片抽取开关，再看结果；不要先换向量库，也不要用“提高 top-k”掩盖输入缺失。对于复杂排版，文本抽取成功不代表结构化元素也成功。

# 让 ingestor 同时保留正文、表格和图表的抽取结果
export APP_NVINGEST_EXTRACTTEXT="True"
export APP_NVINGEST_EXTRACTTABLES="True"
export APP_NVINGEST_EXTRACTCHARTS="True"
export APP_NVINGEST_EXTRACTIMAGES="True"
# 修改后要重启 ingestor-server，避免旧容器继续使用旧环境变量
docker compose -f deploy/compose/docker-compose-ingestor-server.yaml up -d

先用一个只有一张表和一张折线图的短 PDF 做回归。记录文件名、页码、元素类型和提取结果，比直接拿整套生产文档反复试更容易判断是哪一层丢了数据。

再查模态层：表格和图表按什么方式向量化

抽取结果存在，不等于检索一定能理解视觉内容。NVIDIA RAG Blueprint 的多模态 embedding 可以处理文本、PDF 页面、表格、图表和图片元素；结构化元素可以保持文本模态，也可以设置为图片模态。两种方式的排障重点不同：文本模态依赖 OCR、表格转写和图表描述是否完整，图片模态则依赖对象存储、VLM embedding 和图片数据是否可读。

如果要把表格和图表作为图片向量化，关键配置应在 ingestor 侧保持一致：

# 只把结构化元素切到 image 模态，正文仍按 text 处理
export APP_NVINGEST_STRUCTURED_ELEMENTS_MODALITY="image"
export APP_NVINGEST_IMAGE_ELEMENTS_MODALITY=""
export APP_EMBEDDINGS_MODELNAME="nvidia/llama-nemotron-embed-vl-1b-v2"
# 让配置在 ingestor 和 nv-ingest runtime 中生效
docker compose -f deploy/compose/docker-compose-ingestor-server.yaml up -d

整页当作图片是另一条路径，适合视觉布局很重的 PDF，但官方文档把它标为实验性配置，并提示这种模式下部分生成和搜索 API 的引用能力受限。排障时不要同时切换“整页图片”和“结构化元素图片”，否则很难知道召回变化来自哪一个开关。

确认 collection 和索引层：召回的到底是哪类 chunk

进入向量检索层后，先确认查询明确指定了目标 collection。多模态查询即使请求格式正确，没有选中的知识库也不会返回相关结果。随后查看 top-k 原始候选的元数据：文档名、页码、元素类型、模态和对象存储键至少要保留四项。只返回 text chunk 时，说明图表可能没有入库，或过滤条件把 structured、image chunk 排除了。

async def ask_chart(rag, question, collection):
    # 用固定 collection，避免请求落到默认空知识库
    return await rag.generate(
        messages=[{"role": "user", "content": question}],
        use_knowledge_base=True,
        collection_names=[collection],
        enable_reranker=True,
    )

这段调用只能证明查询路径指定了集合，不能证明集合里已有图表 chunk。真正的检查要落到检索响应或服务日志：候选是否来自目标 PDF、页码是否命中图表页、元素类型是否从纯文本扩展到了结构化内容。若集合中没有目标元素，应回到抽取或 ingestion 重跑，而不是在查询端继续加提示词。

最后查重排层：确认视觉 reranker 收到了图片

当图表 chunk 已经召回，却总被文字相似度更高的正文压在后面，才检查 VLM reranker。模型名要走 rerank-vl 路径，同时开启图片输入；否则模型即使是视觉语言模型，也可能只收到候选文本。

# 让 rerank-vl 同时读取候选 chunk 的文字和图片
export APP_RANKING_MODELNAME="nvidia/llama-nemotron-rerank-vl-1b-v2"
export ENABLE_RERANKER="True"
export ENABLE_VLM_RERANKER_IMAGE_INPUT="True"
# 修改后重启 rag-server，确认对象存储地址可达
docker compose -f deploy/compose/docker-compose-rag-server.yaml up -d

这里有一个容易误判的边界：用户查询本身带图片时，NVIDIA RAG Blueprint 的图片查询路径会直接使用多模态向量检索并绕过 reranker。此时不要用“reranker 没有日志”证明配置失效，应改查向量召回、collection、单页限制和图片元素是否存在。

按故障层选择最小修复

抽取层缺元素，就修抽取配置并重跑 ingestion；模态层不匹配，就统一 embedding 模型和结构化元素的 modality；集合层没有候选，就核对 collection、过滤条件、对象存储和索引构建；只有候选已存在且排序不理想时，才调整 VLM reranker。每次只改一层，用同一个 PDF、同一个问题和同一个 collection 回归，记录返回的页码与元素类型。

常见问题

只开启 VLM embedding 就一定能找到图表吗？

不一定。抽取开关、结构化元素模态、collection 和对象存储任一层缺失，都会让后续检索看不到图表。

应该把整页 PDF 都设为图片吗？

不建议作为第一步。整页图片属于实验性路径，先使用表格和图表的结构化抽取，能更清楚地定位问题并保留引用边界。

图表已经召回但回答仍然不准怎么办？

先确认候选图片确实传给了 VLM reranker；如果查询带图片，则改查向量召回，因为该路径可能绕过 reranker。

提高 top-k 能修复抽取失败吗？

不能。top-k 只改变已入库候选的数量，不能生成缺失的表格、图表或图片 chunk。