当前时间： 2026-08-17 18:05:16
分类：办公文件
评论(0)
PDF RAG 别只抽文字,页面也要被搜出来第一页是封面，第二页是目录，第三页开始密密麻麻。文字倒是能 OCR 出来，可关键证据偏偏不在正文句子里：一张表的第三列，一个柱状图的蓝色条，一页财报脚注里的小字，一个架构图里从左下角绕出去的箭头。你把它丢进普通 RAG 系统，系统很认真地切 chunk、做 embedding、进向量库。问它“哪个 spec section 需要改”，它能翻到一段相关文字，却漏掉旁边那张图。问它“这份报表里异常在哪里”，它读到了一堆数字，却没看见图里的拐点。不是模型不会总结，也不是回答模型太笨。它一开始就没把那一页找回来。后面的 VLM 再强，也只能对着错误页面一本正经。NVIDIA 这次在 Hugging Face 上发的 Llama Nemotron VL RAG 模型，我觉得值得单独写一篇，不是因为名字又长了一点。它戳中的是一个很具体的问题：PDF RAG 不能只把页面拆成文字，页面本身也得进入检索链路。回答好不好，引用准不准，模型会不会瞎编。你最后看到的是一段答案，自然会把锅往生成模型身上放。如果查询是“低功耗状态会影响哪些 interrupt controller spec section”，系统先得把正确页面捞出来。那一页可能有文字说明，也可能有状态机图、表格、约束项、验证 collateral 的截图。只有文字 chunk 被找回来，画面里的关系还躺在 PDF 里，回答就会少一截骨头。NVIDIA 官方博客的说法很直接：multimodal RAG pipeline 会把 retriever 和 VLM 放在一起，让回答同时落在页面文本和视觉内容上。Embedding 控制哪些页面会被拿出来，reranker 决定这些候选页里谁更该排前面。第一个是 llama-nemotron-embed-vl-1b-v2。它负责把文档页变成向量。输入可以是文字，可以是页面图片，也可以是页面图片加 OCR/抽取出来的文字。模型卡写得很清楚，它支持含有 text、tables、charts、infographics 的页面图像，输出最多 2048 维 embedding。很多公司已经有向量数据库，有索引，有一套检索服务。单向量 dense embedding 的好处，是不用把整套存储推倒重来。页面可以继续被放进标准向量库，只是页面表示从“纯文字块”变成了“图片 / 文字 / 图文合一”。第二个是 llama-nemotron-rerank-vl-1b-v2。它不负责全库搜索。它是 cross-encoder reranker，拿 query 和候选页面对一起看，给相关性 logit，把前面召回的一批页面重新排序。模型卡也提醒了：拿 reranker 去扫整个知识库不可扩展，它该站在 embedding 后面，处理 top candidates。粗找要快，要能进向量库。细排要看得更深，尤其是图和文字缠在一起的页面。对 PDF RAG 来说，这比“又一个会看图的大模型”更接地气。因为企业文档系统里，麻烦常常卡在检索链路：怎么改，才能稳定上生产。官方博客给了 Visual Document Retrieval，也就是 page retrieval 的 Recall@5 表。评测平均覆盖 DigitalCorpora-10k、Earnings V2、ViDoRe V1/V2/V3。这里要留住两个词：page retrieval，Recall@5。它不是问答准确率，也不是“企业文档全场景胜率”。表里，llama-nemotron-embed-vl-1b-v2 在 image+text 模式下是 73.24%。上一代 llama-3.2-nemoretriever-1b-vlm-embed-v1 的 image+text 是 71.71%。再加上 llama-nemotron-rerank-vl-1b-v2 之后，image+text 到 77.64%。text 和 image 两列也都到 76.12%。这说明 rerank 那一步确实在抬 Recall@5。官方博客还说，VLM reranker 分别带来 7.2%、6.9%、6% 的提升，按 text、image、image+text 三种 modality 来看。因为它测的是找页，不是生成答案。它告诉你：把页面图片和文字都喂进检索，再用多模态 reranker 复排，正确页更容易进入前 5 个候选。很多 PDF 不是天然适合被切 chunk 的文本。财报里有表，有图，有 footnote。芯片规格书里有时序图、状态转移图、约束项。医学说明、保险合同、产品手册、PPT 导出的培训资料，往往是一页一页的视觉布局。一类是视觉对象本身。比如表格列关系、图表趋势、流程箭头、图注和主体之间的绑定。另一类是页面位置关系。哪个标题管哪张图，哪段脚注对应哪列数字，哪个 warning box 才是这一页的安全边界。所以 NVIDIA 这篇博客里专门解释了 image+text：页面图片和用 NV-Ingest 这类 ingestion library 抽出来的文字一起喂给 embedding model，让页面表示更准。是你终于承认了：PDF 页不是一串句子，它先是一张页面。如果你手里正好有一堆合同、报告、手册、科研 PDF，想试这种模型，我建议别上来就问“能不能替我做知识库”。第一段，ingestion。你的 PDF 是原生文本，还是扫描件？表格怎么抽，图怎么保留，OCR 错字怎么处理，页面图片和文字怎么绑定。这里一乱，后面模型只是在帮你把乱数据排得更认真。第二段，embedding。你是只存 text chunk，还是把 page image、page text、image+text 都试一遍。官方表里 image+text 表现最好，但你的场景未必一定如此。合同、报表、设计文档、PPT，差异很大。第三段，reranking。embedding 先把 top candidates 拉出来，再让 reranker 重排。别幻想 reranker 扫全库。它是精修候选，不是全场搬运工。第四段，generation。最后才轮到 VLM 或 LLM 组织答案。生成模型要看哪些页面、引用哪些证据、保留多少图片上下文，这一段要和检索指标分开验收。你可以拿同一批问题做一个很小的离线测试：只抽文字、只用页面图、图文合一，再加不加 reranker。别急着算“大模型回答多聪明”，先算正确页有没有进前 5。先是上下文长度。Embed 模型按 modality 设置 p_max_length：image 可用 2048，text 可用 8192，image+text 可用 10240。Rerank 也提到最大上下文 10240，超长输入会被截断。这意味着，长 PDF 页面不是随便一股脑塞进去。页面怎么切，OCR 文本保留多少，表格展开成什么格式，都会影响检索。Embed 模型卡提醒，vLLM 里要用正确 chat template，让 query: / passage: 前缀按 role 套上去。没有这个模板，前缀不生效，结果会错。Rerank 模型卡也专门说，vLLM serving 要提供 score template，否则 query-document pair 的 prompt 格式不会正确应用。它会给你一个“看起来能跑”的系统，然后结果 quietly bad。两个模型卡都写了 ready for commercial use，但不是一句“Apache 开源”就能带过。模型使用受 NVIDIA Open Model License Agreement 管辖，post-processing scripts 是 Apache 2.0，还叠了 Llama 3.2 Community Model License / Built with Llama。你要进企业生产，法务和合规要按这个看，不要把它简化成无限制商用。官方博客列了三个例子：Cadence、IBM、ServiceNow。Cadence 的例子是逻辑设计资产，像微架构、规格文档、约束、验证 collateral。工程师问“我要扩展 interrupt controller 支持低功耗状态，哪些 spec section 需要改”，系统要从一堆互相关联的 multimodal documents 里把相关要求捞出来。IBM Storage 的例子更像很多企业会遇到的日常痛点：长 PDF、产品指南、配置手册、架构图。它会把每一页当成 multimodal document，再用 reranker 把那些 domain-specific terms、缩写、产品名落在正确语境里的页面排到前面。ServiceNow 的例子是 Chat with PDF：组织内部很多 PDF 页面被索引，reranker 负责给每次 query 选更相关的页面，高分页面在多轮对话里继续留在上下文里。它们都不适合靠“把 PDF 转成纯文本再搜”糊弄过去。因为问题本身就牵着图、表、布局、专业术语和上下文走。我不想把这篇写成“1.7B 小模型打败大模型”。那太粗糙。Embed 模型大约 1.7B，Eagle-family VLM 架构，用 Llama 3.2 1B language model 加 SigLIP/SigLip2 400M vision encoder。Rerank 模型也大约 1.7B，是 cross-encoder，输出相关性 logit。它们是在回答一个更窄的问题：我怎样把正确的页面先找回来，再排到前面。这个位置很关键。因为企业 RAG 里，很多系统已经有向量库、有权限、有文档同步、有审计日志。你要替换掉整个系统很难。可你要在检索层多加一种图文 embedding，再在候选后面加 reranker，迁移成本就小得多。模型卡也写了风险边界：Embed 不保证每次都能找回正确 passage；Rerank 不保证每次都给出有意义排序。NVIDIA 还提醒，集成 foundation / fine-tuned models 到 AI 系统里，需要用具体场景数据继续测试和验证。你的企业 PDF，和官方 benchmark 里的页面，不是一回事。如果你准备把 Llama Nemotron VL RAG 放进测试池，我会先问这六件事。第一，你的问题到底在找文字，还是找页面？ 如果答案常常藏在表格、图、脚注、页面结构里，纯文本 chunk 会吃亏。第二，你有没有保留页面图像？ 只存 OCR 文本，后面就没法让 image 或 image+text 检索发挥作用。第三，你的 benchmark 是 Recall@5 还是最终回答正确率？ 两个都要，但不能混着吹。先看正确页有没有被召回，再看回答模型有没有用对证据。第四，reranker 加在什么位置？ 它应该处理 embedding 拉出的候选页，而不是全库重排。第五，模板和前缀有没有配对？ query:、passage:、score template、max_model_len，这些配置错了，结果会悄悄变差。第六，许可证和数据合规怎么过？ 模型可商用不等于所有部署细节都自动放行。内部 PDF、客户资料、扫描合同、财务报告，进索引前要先过权限和数据边界。问完这六个问题，你会发现，多模态 RAG 不是给旧系统贴一张“会看图”的标签。这次 Nemotron VL RAG 模型，我最看重的不是某一个百分比。是它把一个老问题重新摆回桌上：我们过去太习惯把 PDF 碾碎成文字渣，再让 RAG 去里面捞答案。人看 PDF，会扫标题，会看图，会顺着表格列往下找，会注意一个 warning box 盖住了哪段内容。你问一个专业问题时，脑子里找的是一页证据，不是某个孤零零的句子。• Hugging Face Blog：Small Yet Mighty: Improve Accuracy In Multimodal Search and Visual Document Retrieval with Llama Nemotron RAG Models https://huggingface.co/blog/nvidia/llama-nemotron-vl-1b• Hugging Face Collection：Nemotron RAG https://huggingface.co/collections/nvidia/nemotron-rag• Embed Model：nvidia/llama-nemotron-embed-vl-1b-v2 https://huggingface.co/nvidia/llama-nemotron-embed-vl-1b-v2• Rerank Model：nvidia/llama-nemotron-rerank-vl-1b-v2 https://huggingface.co/nvidia/llama-nemotron-rerank-vl-1b-v2
夜雨聆风
