同一份3.9MB政府?dāng)?shù)據(jù)，兩個工具返回的token數(shù)差了5000倍

“9兆日元。”這是日本政府2026年度社會保障相關(guān)預(yù)算的規(guī)模。支撐這筆預(yù)算的,是堆積如山的PDF和CSV文件。但當(dāng)開發(fā)者試圖讓程序自動讀取這些文件時,一個3.9MB的政府公開數(shù)據(jù)文件,在兩種工具手里返回了截然不同的結(jié)果——一個吐出460萬token直接撐爆上下文,另一個只返回909個token外加一句“文件在這里,你自己處理”。

這場測試的發(fā)起者,是一個長期與日本政府?dāng)?shù)據(jù)打交道的工程師。他注意到一個問題:現(xiàn)有面向英語環(huán)境優(yōu)化過的網(wǎng)頁抓取工具,遇到日語網(wǎng)頁時頻繁翻車。Shift_JIS和EUC-JP編碼的頁面被讀成亂碼,單個長頁面連同導(dǎo)航欄、排序組件、廣告橫幅一股腦全抓下來,PDF和CSV鏈接要么返回原始字節(jié)流,要么直接下載16MB文件到本地就停了。他對amenbo多通道結(jié)構(gòu)化抓取服務(wù)器的開發(fā)人員說:“我不想再空口說‘我擅長處理日語’了,得用真實網(wǎng)址和真實工具測給你看。”

測試選擇了五款工具,用同一套JSON-RPC測試框架跑七個日語網(wǎng)址,涵蓋Zenn技術(shù)文章、維基百科重表格頁面、青空文庫1.2MB的Shift_JIS編碼小說、政府開放數(shù)據(jù)頁面、日語PDF、3.9MB的CSV文件,以及一個拒絕純HTTP請求的網(wǎng)站。所有文本token用同一個中日韓感知型估算器計算,圖片token采用Claude的寬×高÷750視覺token估算法。環(huán)境是macOS、Node v26、冷緩存,每個網(wǎng)址只打一次。

3.9MB的CSV文件展現(xiàn)了最極端的情況。把這種體積的表格直接塞給大語言模型毫無意義。amenbo的做法是返回表頭、簡短預(yù)覽和一條提示信息,告訴使用者這個文件有15.4MB,還有104個鏈接可以通過csv篩選器獲取,讓開發(fā)者自行用腳本聚合數(shù)據(jù)。Jina Reader則返回了全部4593027個token。同一份文件,消耗相差約5000倍。

編碼問題在青空文庫的小說上暴露得更徹底。那份1.2MB的Shift_JIS文件,amenbo正確解碼出“吾輩は貓である。名前はまだ無い。どこで生れたか…”;Jina Reader也能解碼,但保留了振假名內(nèi)聯(lián)標(biāo)注,返回“吾輩(わがはい)は貓である。名前はまだ無い…”;而某款官方抓取工具返回的是一堆UTF-8假設(shè)下的亂碼字符,完全不可讀。更關(guān)鍵的是token量級——在2026年7月12日重新抓取時,Jina把整本小說一次性返回,329380個token,振假名一字不落。Playwright MCP則為無障礙樹和像素截圖付出了453263個token,外加221個圖像瓦片消耗263819個視覺token。amenbo則去掉振假名,把小說切分成25頁,每頁控制在token預(yù)算內(nèi),第一頁7992個token,想要更多頁再單獨抓取。一次抓取就返回30到45萬token,無論平均值怎么算,都會直接擊穿上下文管理的預(yù)設(shè)。

PDF和CSV的處理方式揭示出更本質(zhì)的思路差異。日本公共部門的數(shù)據(jù)主要就是這兩種格式。amenbo提取PDF文本只花810個token,處理CSV時用909個token返回預(yù)覽。而某官方抓取工具面對PDF返回的是%PDF-1.7開頭的原始字節(jié)流,Playwright干脆無法對PDF做快照。測試倉庫里記錄了每一組詳細數(shù)據(jù)和抓取日志,所有數(shù)字都可交叉驗證。

這場測試給出的結(jié)論遠比5000倍這個吸睛數(shù)字更值得琢磨:當(dāng)抓取工具面對非英語、非UTF-8編碼、非HTML格式的政府公開數(shù)據(jù)時,通用方案往往不是在“出錯”就是在“過于用力”——要么讀不懂,要么讀太多。而那些懂得做漸進式信息披露的工具,選擇在入口處告訴開發(fā)者“數(shù)據(jù)在這里,結(jié)構(gòu)長這樣,你自己決定怎么取”,反而用更少的token換來了更可控的工作流。

這些日志和測試數(shù)據(jù)已經(jīng)公開在代碼倉庫中。對于需要處理多語言政府?dāng)?shù)據(jù)的開發(fā)者來說,與其等通用工具適配每種編碼和格式,不如在選型之初就測一遍:你的抓取工具,面對一份3.9MB的CSV,到底返回了什么。