当前时间: 1970-01-01 08:00:00
分类:办公文件
评论(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
基本
文件
流程
错误
SQL
调试
- 请求信息 : 2026-07-11 17:54:00 HTTP/1.1 GET : https://www.yeyulingfeng.com/a/847893.html
- 运行时间 : 0.112739s [ 吞吐率:8.87req/s ] 内存消耗:4,672.58kb 文件加载:145
- 缓存信息 : 0 reads,0 writes
- 会话信息 : SESSION_ID=037553c10510dbf28f30e45519fb1afc
- CONNECT:[ UseTime:0.000567s ] mysql:host=127.0.0.1;port=3306;dbname=wenku;charset=utf8mb4
- SHOW FULL COLUMNS FROM `fenlei` [ RunTime:0.000793s ]
- SELECT * FROM `fenlei` WHERE `fid` = 0 [ RunTime:0.000335s ]
- SELECT * FROM `fenlei` WHERE `fid` = 63 [ RunTime:0.000292s ]
- SHOW FULL COLUMNS FROM `set` [ RunTime:0.000492s ]
- SELECT * FROM `set` [ RunTime:0.000197s ]
- SHOW FULL COLUMNS FROM `article` [ RunTime:0.000519s ]
- SELECT * FROM `article` WHERE `id` = 847893 LIMIT 1 [ RunTime:0.000445s ]
- UPDATE `article` SET `lasttime` = 1783763640 WHERE `id` = 847893 [ RunTime:0.011616s ]
- SELECT * FROM `fenlei` WHERE `id` = 64 LIMIT 1 [ RunTime:0.000263s ]
- SELECT * FROM `article` WHERE `id` < 847893 ORDER BY `id` DESC LIMIT 1 [ RunTime:0.000448s ]
- SELECT * FROM `article` WHERE `id` > 847893 ORDER BY `id` ASC LIMIT 1 [ RunTime:0.000366s ]
- SELECT * FROM `article` WHERE `id` < 847893 ORDER BY `id` DESC LIMIT 10 [ RunTime:0.002103s ]
- SELECT * FROM `article` WHERE `id` < 847893 ORDER BY `id` DESC LIMIT 10,10 [ RunTime:0.001662s ]
- SELECT * FROM `article` WHERE `id` < 847893 ORDER BY `id` DESC LIMIT 20,10 [ RunTime:0.001421s ]
0.114433s