很多團隊做文件 AI，第一個誤會都很像。

他們以為問題是「模型有沒有讀到字」，結果真正把專案拖慢的，常常不是字沒讀到，而是文件雖然被讀進去了，結構卻已經歪了。

一張請款單，欄位順序亂掉。
一份掃描合約，頁首頁尾和正文混在一起。
一張財務報表，表格數字都抓到了，但列與欄的對應關係壞了。
最後你不是得到一份可用資料，而是得到一份很像資料的殘骸。

這也是 Surya 值得看的地方。

它不是只做 OCR。更準確地說，它想處理的是文件理解裡最麻煩的前半段：文字辨識、版面分析、閱讀順序、表格辨識，而且要能跨多語、跨版型、跨掃描品質。對現在很多會把 PDF、圖片文件直接送進 RAG、agent 或抽取流程的團隊來說，這一層如果不穩，後面模型再強都只是把錯誤包裝得更自然。

English TL;DR

• Surya is an open-source document intelligence project focused on OCR, layout analysis, reading order, and table recognition, not just text extraction.
• Its real value is helping AI teams preserve document structure before data enters RAG, extraction pipelines, or workflow automation.
• It is especially useful for scanned PDFs, multilingual forms, reports, and documents where layout matters as much as text.
• But it is not a universal document solution. Native PDFs may not need it, hardware and runtime costs are real, table recovery is not perfect, and model-weight licensing needs careful review.
• Pragmatic takeaway: evaluate Surya when your bottleneck is document structure loss, not when plain text extraction is already enough.

現在很多文件 AI 專案，卡的不是辨識率，而是結構保存率

如果你今天只是把文件內容拿來全文搜尋，OCR 做到能看大意，也許就夠了。

但只要任務往前一步，變成欄位抽取、審核比對、報表解析、合約整理、知識庫問答，事情就完全不一樣。因為這時候模型需要的不是「大概知道這頁在講什麼」，而是要知道：

• 哪一塊是標題，哪一塊是正文
• 哪些字屬於同一段
• 閱讀順序到底是左到右，還是雙欄交錯
• 這張表裡的數字對應哪一列、哪一欄
• 圖片、頁眉、章節標頭是不是該被排除

Surya 的切入點很務實。它把文件處理拆成幾件真正會影響下游品質的事來做：OCR、layout analysis、reading order、table recognition，還有多語支援。最近的 Surya 2 更把 OCR、版面、表格整合到單一 650M 參數模型裡，這代表它不是單純把幾個小工具拼在一起，而是在嘗試讓文件理解的前處理變成一個比較一致的系統。

這件事的價值，不在模型名詞，而在導入後的錯誤型態會不會變少。

它最適合的，不是「任何文件」，而是三種很容易讓團隊翻車的文件工作

場景一，掃描 PDF 進 RAG，但你不想讓模型吃到亂序內容

很多團隊把文件接進 RAG 時，會先用最便宜的文字抽取方式試一輪。遇到 born-digital PDF 還行，可是一碰到掃描件、影印件、多欄文件、混合圖片與表格的頁面，品質就開始下滑。

Surya 在這裡的價值，不只是把字讀出來，而是盡量保住頁面的閱讀邏輯。對 FAQ 手冊、政策文件、投標文件、產品說明書這類長文件來說，這很重要。因為 chunking 之前如果內容順序就壞掉，後面再怎麼切段、再怎麼 rerank，都只是把歪掉的材料切得更整齊而已。

比較務實的看法是，Surya 適合拿來處理那些「純文字抽取已經不夠」的文件來源。

場景二，表單與報表自動化，但你真正要的是欄位關係，不是字串堆

財務、採購、營運、法務常碰到的文件，很多都不是連續文字，而是高度依賴版面關係的資料。

像請款單、報價單、報關文件、保單摘要、醫療表單、月報表，真正有價值的不是某個字被辨識出來，而是這個數值屬於哪個欄位、哪個客戶、哪個日期、哪個品項。

Surya 內建 table recognition 和 layout block 輸出，對這種任務就比單純 OCR 更有用。它不保證你一步到位拿到業務可直接入庫的乾淨結構，但至少補上了最容易爛掉的那段，讓後續規則抽取、LLM 抽取或人工覆核有比較好的基底。

如果你是要做半自動文件處理，這類能力通常比再換一個 prompt 更有感。

場景三，多語文件與非英文環境，不想每次都被英語中心工具拖累

Surya README 強調 90+ 語言支援，並且在 release 中提到 91 語 benchmark。這點很關鍵，因為很多文件流程不是英文世界。

台灣、東南亞、中東、歐洲的實際業務場景裡，文件常常混著中文、英文、數字、章節符號，甚至同一份表單裡就有多語欄位。你如果拿一個英語優化很重的 OCR 工具，常常會先撞到的不是模型不夠聰明，而是它根本不是拿來面對這種混合文件的。

Surya 的多語定位，讓它比較像一個可進評估清單的基礎零件，而不是只適合英文 demo 的研究展示。

Surya 真正補到的，是文件進模型前的那道工

我會把 Surya 看成「文件 AI 的結構修復層」。

很多團隊今天已經有後段能力了。
有向量資料庫，有 LLM，有欄位抽取 prompt，有 workflow，有人工覆核 UI。

但前段如果只是把 PDF 生硬轉成文字，整條流程其實很脆。因為模型不會自動理解你原本文件裡的視覺關係，它只會忠實接收你餵給它的順序。順序一亂，語意就跟著亂。

Surya 的輸出設計能看出這個思路。像是 block、html、label、reading_order、polygon、bbox 這些資訊，代表它不是只想吐一段純文字，而是希望你下游可以根據不同任務，決定要保留多少結構。

這對工程導入很重要。因為不同場景要的不是同一種輸出：

• RAG 可能偏好乾淨文字加段落順序
• 表單抽取需要 block 與位置資訊
• 文件審核需要把 bbox 疊回原圖給人看
• 報表處理需要表格與欄列關係

Surya 比較像是在提供一個夠厚的中介層，而不只是一個 CLI 工具。

最近值得重看的原因，是它還在快速往「可用」而不是只往「可看」的方向修

Surya 最近的訊號很不錯。

GitHub 上目前大約 20.5k stars，最近一次 major release 是 2026-05-27 的 v0.20.0（Surya 2），而且 repo 這幾天都還有更新。這不是那種停在漂亮 README 的專案。

更值得注意的是，Surya 2 不是小修補，而是整個推論架構重做。它把 OCR、layout、table recognition 整合到單一 650M 模型，並支援 vllm 與 llama.cpp 後端。這說明維護者的方向很明確，不是只追 benchmark，而是在追部署路徑與實際吞吐。

但這裡也有一個很現實的訊號。只要專案開始談後端、啟 server、硬體路徑、schema 變更，就表示它已經不是玩具。
同時也表示，導入成本一定會比「pip install 然後馬上萬事搞定」高。

不要把它神化，Surya 有幾個邊界要先講清楚

1. 它不是所有文件流程都需要的那一層

如果你的文件本來就是 native PDF，而且內嵌文字乾淨、結構規則明確，很多時候用簡單抽取器就夠了。這時候直接上 Surya，可能只是增加成本。

結論很直接，先分清楚你的文件痛點是不是來自掃描、版面、表格與多語混亂。如果不是，Surya 可能太重。

2. OCR 做得再好，也不代表欄位抽取就自動成功

很多人看到 layout 和 table recognition，就會直覺以為後面抽欄位應該很穩。更現實的是，它只是把前處理做好一大半，不是直接替你完成業務結構化。

像複雜跨欄表格、品質很差的掃描、手寫內容、蓋章遮擋、極端版型，還是會出錯。你通常仍需要規則層、LLM 層或人工覆核來收尾。

所以 Surya 的定位應該是「把垃圾率壓低」，不是「把人工從流程裡完全拿掉」。

3. 推論後端與硬體成本不能假裝不存在

Surya 2 需要 vllm 或 llama.cpp 這類推論後端。這對正式團隊不是壞事，但也代表它比傳統純 Python OCR 腳本更有部署門檻。

如果你是 CPU-only、小規模偶發處理，或完全不想碰 server lifecycle，導入體驗就不會那麼輕。README 甚至直接提到 server 啟停、keep_server、吞吐調校、DPI 與平行度，這些都說明它比較像一個可調的系統，不是零維運工具。

4. 授權不能只看 code license

這點很重要。

Surya 的程式碼是 Apache 2.0，但模型權重採用的是修改版 AI Pubs Open Rail-M，對研究、個人使用與特定規模以下新創比較友善，較廣泛商業使用則要看它的授權條件。
這不是小事，尤其如果你打算把它塞進商業文件流程、SaaS 產品或客戶交付方案裡。

很多團隊會在 PoC 很順之後，才發現權重授權才是真正卡點。這種事最好在評估前就講清楚。

替代方案怎麼看

如果你要的是比較傳統、較輕量的 OCR，Tesseract、PaddleOCR 這類工具仍然有位置，尤其在成本敏感、流程固定、語系單純的情況下。

如果你要的是更完整的文件理解平台，可能會去看更高階的商業 API，或搭配別的 document pipeline。那類方案往往部署更省事，但可控性、成本和資料主權未必比較好。

Surya 最有吸引力的區間，在於它站在一個中間位置：

• 比傳統 OCR 更重視版面與表格
• 比黑箱商業 API 更可控
• 比純文字抽取更適合進 AI workflow
• 但也因此，比最輕量方案更需要導入判斷

GitHub Star History

Star History 連結：https://www.star-history.com/#datalab-to/surya&Date

Repo：https://github.com/datalab-to/surya

採用判斷

Surya 值得現在看，不是因為 OCR 又成了熱門名詞。

而是 AI 團隊做文件流程做到後面，幾乎都會碰到同一個問題：模型沒有真的看懂文件，它只是接住了一份已經失真的文字輸入。

所以採用判斷可以很直接。

• 如果你們正在處理掃描 PDF、多欄文件、表格型文件、多語表單，Surya 很值得進評估清單。
• 如果你們的文件大多是原生文字 PDF，需求只是抽純文字，先不要急著上這麼重的一層。
• 如果你們期待它直接取代整個欄位抽取、驗證、人工覆核流程，那一定會高估它。
• 如果商業授權、部署後端、硬體資源無法先講清楚，也不要太早把它視為最終方案。

比較務實的結論是，Surya 不一定是每個文件 AI 團隊都要用的工具，
但只要你的痛點是文件結構在進模型前就先壞掉，它就是那種很容易把整條流程品質往上拉一級的基礎零件。