同一份掃描版采購(gòu)訂單，為什么布局識(shí)別全對(duì)，物料編號(hào)卻錯(cuò)得離譜？如果你正準(zhǔn)備把發(fā)票錄入系統(tǒng)、用合同表格跑自動(dòng)化流程，這場(chǎng)實(shí)測(cè)可能會(huì)讓你重新考慮技術(shù)路線(xiàn)。

2026年4月，LlamaIndex發(fā)布了一項(xiàng)名為ParseBench的文檔解析基準(zhǔn)測(cè)試，結(jié)論很吸引人：只要提示詞設(shè)計(jì)得當(dāng)，視覺(jué)語(yǔ)言模型在版面復(fù)雜的文檔上能吊打傳統(tǒng)OCR。消息一出，很多人覺(jué)得該立刻切到Gemini 3 Flash或者GPT-4o，用帶跨行跨列表格的HTML提示詞來(lái)解析PDF。我拿一份雜亂的2頁(yè)采購(gòu)訂單實(shí)地跑了一遍，結(jié)果和媒體標(biāo)題寫(xiě)的不太一樣。

你可以把這理解為一次“一圖讀懂”式的核心拆解：先把PDF表格提取這件事的底層邏輯鋪開(kāi)，再逐層對(duì)比基準(zhǔn)測(cè)試?yán)锏母叻旨记伞?shí)打?qū)嵉姆?chē)現(xiàn)場(chǎng)，最后聊聊當(dāng)模型從像素里“猜”編號(hào)時(shí)，究竟哪里會(huì)出問(wèn)題。

先看這張?zhí)摂M圖——左邊是掃描件上密密麻麻的物料編號(hào)、公差數(shù)字、跨頁(yè)拆分項(xiàng)；中間是視覺(jué)語(yǔ)言模型讀圖后生成的HTML表格，表頭層級(jí)正確、合并單元格一個(gè)不落；右邊同一份輸出里，物料編號(hào)悄悄變了幾個(gè)字符，公差毫米值憑空少了三位數(shù)。這就是整個(gè)故事的主干。

拆解第一層：任務(wù)到底難在哪兒？你的發(fā)票系統(tǒng)要讀取掃描的采購(gòu)訂單，會(huì)計(jì)平臺(tái)里躺著跨頁(yè)表格的合同。這些PDF里的文字必須變成結(jié)構(gòu)化數(shù)據(jù)，而不是一整面字墻，否則下游代碼根本沒(méi)法動(dòng)。傳統(tǒng)的專(zhuān)用解析器，比如AWS Textract、Google DocAI或者Azure文檔智能，在面對(duì)嵌套表頭、合并單元格、頁(yè)碼間被切分的行時(shí)，常常需要大量的后處理規(guī)則。基準(zhǔn)測(cè)試?yán)铮@些工具的得分在47.9到59.6之間，確實(shí)不夠看。

第二層，ParseBench到底測(cè)出了什么？它對(duì)比了14種解析方法，發(fā)現(xiàn)提示詞設(shè)計(jì)比模型大小重要得多。LlamaParse Agentic的方式拿到了84.9分，Gemini 3 Flash是71分，一下就把專(zhuān)用解析器甩開(kāi)。分?jǐn)?shù)的關(guān)鍵差別在于一個(gè)技巧：要求模型輸出帶colspan和rowspan屬性的HTML表格。這樣一來(lái)，合并單元格信息被直接編碼在標(biāo)簽里，而不是靠空格或縮進(jìn)去“暗示”結(jié)構(gòu)。這套提示的落地代碼長(zhǎng)這樣：系統(tǒng)提示讓模型“只輸出解析內(nèi)容”，將表格轉(zhuǎn)為使用表格標(biāo)簽的HTML，保留跨列跨行以維持合并單元格和層級(jí)表頭。調(diào)用時(shí)，把兩張掃描頁(yè)的Base64編碼傳進(jìn)GPT-4o，請(qǐng)求合并被切分的表格。

在我的測(cè)試?yán)铮瑹o(wú)論是GPT-4o-mini還是完整版GPT-4o，都給出了結(jié)構(gòu)正確的表格。布局這塊確實(shí)撐住了基準(zhǔn)測(cè)試的結(jié)論，看起來(lái)很美。然而第三層才真正要命：基準(zhǔn)測(cè)試沒(méi)壓測(cè)的地方，恰恰是落地場(chǎng)景的死穴——那些物料編號(hào)的逐字符精確度。

我用的這份2頁(yè)采購(gòu)訂單有7個(gè)行項(xiàng)目，帶有重復(fù)出現(xiàn)的收貨地址子表頭，其中第030號(hào)物料還被頁(yè)分隔符劈成兩半。物料編號(hào)像ALRD00882這樣的碼，屬于“輸錯(cuò)一個(gè)就發(fā)錯(cuò)貨”的關(guān)鍵字段。兩個(gè)視覺(jué)模型跑出來(lái)的結(jié)果里，這些編號(hào)全被重新發(fā)明了。GPT-4o-mini生成了看起來(lái)合理、但和原文檔對(duì)不上的碼；它還把表示公差的“12.700”毫米改寫(xiě)成了“12,700”，數(shù)量級(jí)直接差了三階，又把“3658 mm”看成了“356 mm”。GPT-4o完整版修掉了這些數(shù)字錯(cuò)誤，但物料編號(hào)依舊憑空捏造。

這不是提示詞寫(xiě)得不夠好。這是語(yǔ)言模型從像素生成文字時(shí)的底層行為模式：字母數(shù)字組合的編碼沒(méi)有語(yǔ)言學(xué)上的規(guī)律可循，模型會(huì)從自己見(jiàn)過(guò)的大量相似排版里抽取代換字符。它不是在“讀”編號(hào)，而是在“猜”一個(gè)看起來(lái)像編號(hào)的東西。對(duì)于公差數(shù)值，當(dāng)小數(shù)點(diǎn)被掃描噪點(diǎn)干擾時(shí)，生成過(guò)程也會(huì)用最像數(shù)字的序列來(lái)填空，結(jié)果就出現(xiàn)離譜的單位錯(cuò)誤。

所以回到那張?zhí)摂M圖：中間的結(jié)構(gòu)化表格是亮眼的84分，但右邊紅框標(biāo)出的出錯(cuò)單元，才是真實(shí)業(yè)務(wù)里的一票否決項(xiàng)。如果你的場(chǎng)景可以容忍編號(hào)被近似匹配，或者下游會(huì)用模糊搜索再校驗(yàn)一次，那視覺(jué)模型的布局還原能力的確省力；但如果系統(tǒng)要求百分百的標(biāo)識(shí)符一致性，目前這一代直接從像素生成HTML的做法，還是得搭配一個(gè)專(zhuān)門(mén)做字符級(jí)對(duì)齊的OCR通路。

整件事的啟發(fā)其實(shí)很樸素：基準(zhǔn)測(cè)試?yán)锏母叻植坏扔谏a(chǎn)環(huán)境的零事故，尤其當(dāng)你的評(píng)價(jià)指標(biāo)是“表格結(jié)構(gòu)分”而非“每個(gè)料號(hào)的精確匹配率”時(shí)。技術(shù)選型之前，先想清楚自己的真實(shí)容錯(cuò)邊界在哪里，比追新模型重要得多。