<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Ocr</title><link>https://www.communeify.com/tw/tag/ocr/</link><description>Communeify - Your Community Platform</description><generator>Hugo</generator><atom:link href="https://www.communeify.com/tw/tag/ocr/" rel="self" type="application/rss+xml"/><item><title>OpenBMB MiniCPM-V 4.7 官方技術解析：35B-A3B MoE 與 1B 端側多模態模型架構、效能與部署指南</title><link>https://www.communeify.com/tw/blog/openbmb-minicpm-v-4-7/</link><guid isPermaLink="true">https://www.communeify.com/tw/blog/openbmb-minicpm-v-4-7/</guid><pubDate>Thu, 15 Oct 2026 00:05:00 +0800</pubDate><description>文章摘要：清華大學自然語言處理實驗室（THUNLP）與面壁智能（ModelBest）於 2026 年 10 月 12 日正式開源 MiniCPM-V 4.7 多模態大模型系列，採用 Apache-2.0 授權協議。本次更新同步推出系列首款混合專家架構模型 MiniCPM-V-4.7-35B-A3B 與輕量級稠密模型 MiniCPM-V-4.7-1B，延續單圖、多圖、文件解析與影片理解能力，並結合自研前瞻專家調度（LES）、精細層級量化與 DSpark 投機取樣技術，讓 35B 級 MoE 模型在行動裝置端流暢運行。本文完全依據官方開源倉庫與模型卡資料，整理兩款模型的技術細節、實測數據、推論參數與完整官方連結。
MiniCPM-V 4.7 系列核心定位與雙規格概覽根據 OpenBMB/MiniCPM-V 官方 GitHub 倉庫與官方中文技術指南，MiniCPM-V 4.7 針對不同算力與記憶體條件的端側與本地場景，提供兩種規格：
MiniCPM-V-4.7-35B-A3B：這是 MiniCPM-V 系列首款混合專家（MoE）模型，總參數量為 35B，單次激活參數為 3B。官方測試指出，透過自研的前瞻專家調度（LES, Lookahead Expert Scheduling）技術、精細層級量化與 DSpark 投機取樣，該模型在 iPhone 17 Pro Max 上僅需 3 GB 記憶體即可達到每秒 13 個 Token 以上（13+ tokens/s）的解碼速度，且不犧牲模型原有的路由精度。在 Instruct 模式下，35B-A3B 以更短的推論時間取得高於 Qwen3.6 35B-A3B 的綜合評測得分。 MiniCPM-V-4.7-1B：針對輕量級端側部署設計的 1B 級稠密（Dense）模型（Hugging Face 模型頁標籤顯示包含視覺模組之總參數規模約 2B），體積小巧，可完整常駐於行動裝置記憶體中。根據 1B 官方模型卡，1B 版本在 Instruct 模式下持續提升前代 MiniCPM-V 4.6 的基礎能力，並在綜合評測得分與推論效率上顯著領先 Qwen3.5 0.8B。 全系列程式碼與模型權重均採用 Apache-2.0 授權協議，支援 iOS、Android 與 HarmonyOS NEXT 作業系統，並於發布首日支援瑞芯微（Rockchip）、後摩智能（Houmo）、Intel、AMD 與 Arm 等晶片平台。</description></item><item><title>騰訊開源 5B 全模態解析模型 Youtu-Parsing-Omni：統一架構處理文件、圖表、音訊與影片</title><link>https://www.communeify.com/tw/blog/youtu-parsing-omni/</link><guid isPermaLink="true">https://www.communeify.com/tw/blog/youtu-parsing-omni/</guid><pubDate>Sat, 10 Oct 2026 00:05:00 +0800</pubDate><description>騰訊開源 5B 全模態解析模型 Youtu-Parsing-Omni：統一架構處理文件、圖表、音訊與影片騰訊優圖實驗室發布 50 億參數規模的全模態結構化解析模型 Youtu-Parsing-Omni，主打單一編碼器與統一 OmniSchema JSON 輸出格式。模型能直接解析一般文件、複雜圖表、幾何圖形、音訊以及視訊內容，並同步完成感知標註與語意摘要。本文整理該模型的技術架構、官方評測數據、部署注意事項與授權限制。
企業在建立知識庫或檢索增強生成（RAG）系統時，經常面臨跨模態資料格式不一致的困境。一份專案資料可能同時包含掃描合約、會議錄音、簡報投影片與產品展示影片，以往需要分別呼叫光學字元辨識、圖表分析與語音轉文字等多套專用工具，再由工程團隊手動拼接輸出欄位。針對這類繁瑣的資料前處理流程，騰訊優圖實驗室推出了 5B 規模的開源權重模型 Youtu-Parsing-Omni，嘗試以單一模型處理多種媒體格式，並將結果輸出為標準化的 JSON 資料。
什麼是 Youtu-Parsing-OmniYoutu-Parsing-Omni 是騰訊優圖實驗室推出的輕量級全模態解析模型，參數量約為 53 億（5.33B BF16）。根據開發團隊在 Hugging Face 專案頁面 與 GitHub 技術報告路徑 所公布的資訊，該模型能接收文件頁面、照片、統計圖表、流程圖、幾何圖案、音訊檔案以及影片，並針對不同任務輸出統一格式的 JSON 結果。
傳統的多模態解析工具通常只輸出 Markdown 文字，但 Youtu-Parsing-Omni 將解析目標擴展為感知（Perception）與認知（Cognition）兩層結構。在感知層面，模型會偵測版面元素的位置座標（Bounding Box）、識別文字內容、轉換數學公式為 LaTeX、將表格轉為 Markdown 或 OTSL，並標記語音說話者與時間戳。在認知層面，模型則會根據整體輸入產出全域摘要、說明文字或結構化分析報告。
模型依據任務提示詞（Task Prompt）切換解析模式，涵蓋以下七大解析家族：
文件頁面（document）：解析文字段落、表格、公式、流程圖與閱讀順序。 自然圖像（natural_image）：標記實體邊界框、物件標籤、局部描述與全域場景說明。 統計圖表（graphics_chart）：將長條圖、折線圖或圓餅圖還原為 Markdown 表格與文字說明。 流程圖（graphics_flowchart）：將圖形關係轉譯為 Mermaid 流程圖語法。 幾何圖形（graphics_geometric）：識別幾何點、線段、圓弧與尺寸標註數據。 音訊片段（audio）：區分語音與非語音區間，輸出時間戳、說話者標籤、語音轉文字（ASR）與聲學事件描述。 視訊內容（natural_video 與 textrich_video）：針對自然影片記錄動作、鏡頭移動與聲音事件，針對演講或教學影片則同步進行畫面 OCR 與語音辨識，產生整段影片的結構化總結報告。 單一編碼器與感知層音視頻融合機制多數現行的全模態系統習慣採用雙塔架構，也就是影像與聲音分別透過兩個各自預訓練的模型進行編碼，直到進入大型語言模型（LLM）解碼器時才進行特徵交會。Youtu-Parsing-Omni 則選擇不同的技術路線。
共享權重的 Youtu-Omni-Encoder研發團隊設計了 Youtu-Omni-Encoder，以文字語言模型作為權重初始化的基礎，以此強化模型對符號與排版結構的先驗理解能力。輸入端透過輕量化的模態專用通道（Stem），將影像像素轉換為視覺 token，同時將音訊的 log-mel 頻譜圖轉為音訊 token。
進入核心的雙向 Transformer 時，所有模態的特徵都會被放入同一個張量中進行計算。由於影像、音訊與影片共用絕大部分編碼器參數，模型在感知階段就能直接對不同訊號建立關聯，減少雙塔架構在特徵轉換時產生的資訊耗損。
時序座標對齊與感知層內部融合在處理影片輸入時，視訊影格與音訊切片會依照時間順序交錯排列。Youtu-Parsing-Omni 採用統一的三維座標系統 (t, h, w) 進行位置編碼。</description></item><item><title>開源視覺文件解析新選擇：LightOnOCR-3-4B 架構特點與應用解析</title><link>https://www.communeify.com/tw/blog/lightonocr-3-4b/</link><guid isPermaLink="true">https://www.communeify.com/tw/blog/lightonocr-3-4b/</guid><pubDate>Sat, 10 Oct 2026 00:05:00 +0800</pubDate><description>開源視覺文件解析新選擇：LightOnOCR-3-4B 架構特點與應用解析法國人工智慧團隊 LightOn 正式開源 LightOnOCR-3-4B 模型，採用 Qwen3.5 視覺語言架構與 Apache 2.0 授權，提供整頁文字轉錄與精準視覺定位雙模式，能直接將複雜文件轉換為結構化 Markdown、圖表資料與座標標籤，有效降低企業打造文件處理流程的維護成本。
傳統光學字元辨識工具在處理包含多欄排版、複雜表格、手寫註記與統計圖表的文件時，往往需要串接多個獨立模型與啟發式規則。這種多階段管線除了提高部署與除錯難度，不同模組之間的誤差也容易累積放大。針對這項實務瓶頸，LightOn 推出了第三代開源光學字元辨識模型系列，其中最大規格的 LightOnOCR-3-4B 結合了文字轉錄與版面理解能力，提供開發者更簡潔的端到端解決方案。
LightOnOCR-3 系列規格與核心設計LightOnOCR-3 全系列均以開源形式釋出，涵蓋三種不同參數量級，方便開發者依據運算資源與辨識精度需求進行選型。
在模型架構方面，0.8B 與 4B 版本改採 Qwen3.5 視覺語言架構，相較於前代架構能更有效整合現有的推論引擎生態。1B 版本則保留 LightOnOCR-2 的專屬模型結構，適合希望直接平滑升級現有系統的使用者。全系列皆採用寬鬆的 Apache 2.0 開源授權，允許學術研究與商業系統自由使用。
模型版本參數規模架構特點適用情境 LightOnOCR-3-4B4.0BQwen3.5 視覺語言架構系列中辨識精度最高，適合各類複雜排版與圖表解析LightOnOCR-3-0.8B0.8BQwen3.5 視覺語言架構運算資源受限但要求高處理效率的邊緣或高通量環境LightOnOCR-3-1B1.0BLightOnOCR-2 專屬架構現有 LightOnOCR-2 部署架構的直接升級替代方案 轉錄與定位雙模式：彈性應對不同下游需求LightOnOCR-3-4B 透過簡單的文字提示詞即可切換輸出型態，大幅簡化系統整合門檻。</description></item><item><title>Jina OCR v1：將文件解析成結構化 Markdown</title><link>https://www.communeify.com/tw/blog/jina-ocr-v1/</link><guid isPermaLink="true">https://www.communeify.com/tw/blog/jina-ocr-v1/</guid><pubDate>Fri, 25 Sep 2026 17:06:10 +0800</pubDate><description>Jina OCR v1：把文件轉成可用的 Markdown將 PDF、掃描檔或複雜版面交給 OCR，真正困難的往往不只是辨識文字，還包括表格、公式、段落與閱讀順序。Jina AI 開源的 Jina OCR v1 是一款端到端（Page-to-Markdown）的文件解析模型，旨在兼顧高品質輸出與高效推論，直接將文件頁面轉化為結構化的 Markdown。
模型架構與技術重點Jina OCR v1 採用輕量化與混合專家（MoE）架構設計：
模型規模：總參數量為 3.4B，但前向傳播每個 Token 僅需激活約 570M 活躍參數，兼具小模型的推論成本與大模型的容量。 視覺與解碼器架構：繼承 DeepSeek-OCR 架構，包含約 380M 參數的 DeepEncoder（將 1024×1024 圖像壓縮為 256 個視覺 Tokens），以及 12 層的 DeepSeek-3B-MoE 解碼器（64 個 Routed Experts 與 2 個 Shared Experts，Top-6 路由）。 FastMTP 投機解碼（Speculative Decoding）：透過遞迴共享單一密集草稿模組（K=3），並結合貪婪驗證（Greedy Verification），實現無損（Lossless）的解碼加速，產出與傳統自回歸完全一致的文字。 多語言與頁面處理：預訓練語料覆蓋約 100 種語言（支援多達 108 種語言）；預設會過濾重複的頁首與頁尾（Headers/Footers），並自動將公式轉為 LaTeX（$ / $$）、表格轉為 HTML &amp;amp;lt;table&amp;amp;gt; 格式。 評測表現與速度（標示測試條件）在官方報告的實測基準中，Jina OCR v1 展現出極高的推論吞吐量：
OmniDocBench v1.6 評測：整體得分 91.14（公式 CDM 達 93.28、表格 TEDS 達 84.68）。 olmOCR-Bench 評測：整體得分 83.4（Base 基礎文本達 99.9、表格 88.8、多欄排版 85.5；但在嚴重損毀的舊掃描檔 OldScans 僅 42.6，建議難度極高的歷史檔案仍需人工覆核）。 吞吐量與速度測試：在單張 NVIDIA A100 (SXM4 40GB, 併發 32) 條件下，達到 2.57 pages/s 的吞吐量（平均每頁產生 1,085 Token）；在單張 NVIDIA L4 (Batch Size 1) 環境下，開啟 FastMTP (K=3) 可將解碼速度從 42.7 提升至 83.1 tokens/s（約 1.95 倍加速）。 如何開始與部署選項使用者可根據需求選擇雲端服務或地端部署：</description></item><item><title>百度 Unlimited-OCR 深度解析：恆定 KV 快取、R-SWA 與 32K 長文本 OCR 部署實戰</title><link>https://www.communeify.com/tw/blog/baidu-unlimited-ocr-r-swa-kv-cache-optimization-deployment/</link><guid isPermaLink="true">https://www.communeify.com/tw/blog/baidu-unlimited-ocr-r-swa-kv-cache-optimization-deployment/</guid><pubDate>Mon, 29 Jun 2026 14:19:00 +0800</pubDate><description>標題：告別碎片化掃描：解析百度 Unlimited-OCR 的恆定 KV 快取與單次部署實戰 處理數十頁的長篇 PDF 總讓伺服器記憶體崩潰嗎？本文全面解析百度於 2026 年釋出的 Unlimited-OCR 開源專案，探討 R-SWA 注意力機制、恆定 KV 快取技術，並提供完整的 SGLang 高併發部署實戰指南，幫助開發團隊輕鬆達成 32K 權杖的單次解析任務。
處理長篇幅文件一直是一場技術噩夢。當開發團隊試圖將一份五十頁的財務報表或是結構複雜的技術手冊送入模型時，伺服器的記憶體往往會毫無懸念地被撐爆。這時候工程師通常只能摸摸鼻子，寫一堆腳本把文件切成無數個小碎片。結果呢？表格被硬生生截斷，前後文的邏輯關聯徹底消失，最後還要寫更複雜的程式碼把這些破碎的資訊拼湊回來。
老實說，這種妥協讓人非常沮喪。
不過，這種無奈的局面出現了轉機。百度在 2026 年 6 月 22 日正式對外公開了 Unlimited-OCR 專案，主打「迎接單次處理長視野解析」。這套開源方案的出現，直接瞄準了過往光學字元辨識技術中最棘手的記憶體限制問題。專案一上線就迅速在 GitHub 累積了超過 550 顆星與 43 次 Fork。今天就來徹底拆解這項技術背後的邏輯，看看它究竟施了什麼魔法，能讓模型一口氣吞下高達 32,000 個權杖。
記憶體不再是怪獸：恆定 KV 快取的神奇之處許多剛接觸這個專案的開發者常問，這款模型跟傳統的全流程方案究竟差在哪裡？答案其實就藏在記憶體管理機制裡。
傳統模型在生成長序列資訊時，鍵值快取（KV Cache）會隨著輸入長度呈現線性甚至是幾何級數的增長。這就像是一個人在背誦一長串數字，背到後面大腦就當機了。系統為了防止崩潰，只能強制降低併發量，或是限制輸入的長度。
Unlimited-OCR 拿出了「恆定 KV 快取」這個殺手鐧。透過極度優化的快取管理策略，模型在解碼過程中硬是將記憶體的消耗鎖死在一個幾乎恆定的範圍內。這代表什麼？這代表不管今天丟進去的是十頁的合約，還是一百頁的規格書，單次請求佔用的顯示卡記憶體資源都維持在穩定狀態。伺服器不再因為突如其來的長文件而無預警停機，系統穩定性得到了飛躍性的提升。
模擬人類閱讀：R-SWA 參考滑動視窗機制要達成超長文本的單次解析，光靠壓縮記憶體是不夠的，模型還必須「看得懂」前後文。這裡就不得不提 R-SWA（參考滑動視窗注意力機制）這項底層技術突破。
想像一下人類是怎麼閱讀厚重原文書的。讀到第五十頁的某個專有名詞時，讀者通常會用手指夾住前面的目錄或名詞解釋頁面，一邊看細節一邊參考全域架構。R-SWA 就是在做一模一樣的事情。
傳統的滑動視窗機制雖然省了運算資源，卻很容易患上「失憶症」，看完後面就忘了前面。R-SWA 巧妙地替換掉基準模型解碼器中的傳統注意力層，它在滑動視窗處理局部細節的同時，保留了全域的參考權杖。因為這個機制的介入，模型在解析末頁的數據時，依然能緊緊抓牢首頁的脈絡，徹底解決了脈絡斷層的痛點。
站在巨人的肩膀上：技術的傳承與融合業界其實已經有不少優秀的視覺解析模型。研發團隊這次並沒有打算閉門造車，而是選擇將前沿模型的寶貴思維揉合在一起。
這套架構的基礎多模態理解能力，大量汲取了 Deepseek-OCR 與 Deepseek-OCR-2 的養分，特別是在複雜排版識別的精準度上獲益良多。同時，團隊也借鑒了自家 PaddleOCR 在工業級場景下久經考驗的穩定性。整合這些優勢後，才成功孕育出這個能單次處理 32K 權杖的怪物級應用。
實戰演練：從 Huggingface 到 SGLang 的高併發部署聊完了理論，該來點硬核的實作了。好消息是，這套強大的模型採用了極度友善的 MIT 開源授權條款，任何人都能自由下載並應用於商業專案。</description></item><item><title>PP-OCRv6 開源 OCR 登場：34.5M 參數超越千億 AI 模型，文字辨識更精準</title><link>https://www.communeify.com/tw/blog/pp-ocrv6-34-5m-open-source-text-recognition-model/</link><guid isPermaLink="true">https://www.communeify.com/tw/blog/pp-ocrv6-34-5m-open-source-text-recognition-model/</guid><pubDate>Mon, 15 Jun 2026 08:54:46 +0800</pubDate><description>開源文書處理利器 PP-OCRv6 報到：僅 34.5M 參數，文字辨識精準度超越千億級視覺大模型如今 AI 模型動輒破百億、千億參數，大家似乎習慣了「體積越大，能力越強」的定律。你知道嗎？PaddleOCR 團隊最新推出的 PP-OCRv6 通用文字辨識方案 卻用極度優雅的方式打破了這個迷思。這款模型向世人證明，專業文字辨識領域的極致輕量化，不僅能帶來飛快的運算速度，準確度甚至能把龐大的視覺語言大模型（VLMs）遠遠甩在後頭。
大衛戰勝歌利亞：34.5M 參數擊退千億巨獸PP-OCRv6 最讓人跌破眼鏡的地方，絕對是它驚人的運算性價比。這款模型採用全新設計的 PPLCNetV4 統一骨幹架構。聽起來有點硬核對吧？簡單來說，開發團隊結合了 MetaFormer 的設計理念，把模型體積壓縮到了極致。
以中型（Medium）版本為例，參數用量僅僅只有 34.5M。連普通手機都能輕鬆跑起來的輕量級身軀，在文字辨識準確度上竟然一舉超越了參數高達 2350 億的 Qwen3-VL-235B，甚至贏過 GPT-5.5 這種頂級巨獸。這背後的原因非常有趣。大型視覺語言模型常常會自作聰明。遇到模糊或拼錯的字，它們很容易根據過往的語言習慣去猜測，甚至自動修正。業界將這種情況稱為幻覺現象。專業的 OCR 系統就像個一板一眼的老實人。它只會忠實且精準地還原圖片上真正寫出的每一個字母，絕不瞎猜。
真正的語言大師：單一模型搞定 50 種語言處理跨國合約或多語系表單時，最頭痛的狀況就是文件中夾雜各國語言。過去遇到這種情況，系統工程師往往需要手動切換不同的語言模型，費時又費力。
PP-OCRv6 的中型與小型模型實現了一項重大突破。它們直接用單一個模型完美覆蓋高達 50 種語言的辨識能力。不管是繁體中文、簡體中文、英文、日文，還是多達 46 種的拉丁語系文字，通通難不倒它。對於需要建構龐大資料處理管線的企業來說，這絕對是提升工作效率的絕佳工具。
工業場景的救星：專治各種疑難雜症字體想像一下，拿著手機掃描發票上的點陣字體，或是工廠儀表板上的數位顯示螢幕。螢幕上常常只會跳出一堆亂碼。那種崩潰感相信許多人都經歷過。這些邊緣場景正是傳統通用大模型極度不擅長的領域。
研發團隊怎麼解決這個問題？PP-OCRv6 透過擴大感受野（Receptive Fields）的設計，搭配全新的損失函數（DiceBCE Loss），將這些棘手狀況迎刃而解。這套機制能夠精準解析包含輪胎壓印、點陣字、數位螢幕甚至旋轉藝術字體等複雜的工業場景。它踏踏實實地填補了大型視覺語言模型在真實世界中的巨大盲區。
針對不同硬體量身打造的三種層級為了滿足不同開發者的硬體條件與部署需求，官方貼心地規劃了三個層級的版本，涵蓋 1.5M 到 34.5M 的參數範圍。
微型版 (Tiny)： 專為邊緣運算與物聯網 (IoT) 裝置打造。在 NVIDIA A100 上跑一張圖只要 0.13 秒。如果在 Apple M4 晶片上執行，速度比上一代激增 6.1 倍。 小型版 (Small)： 專注於行動裝置與桌機端。維持高準確率的同時，確保極低的運算延遲。 中型版 (Medium)： 專為伺服器端設計的火力全開版本。準確度最高，且 GPU 推論速度依然比上一代 PP-OCRv5 提升了 2.37 倍。 豐富的開源資源與開發者指南無論是需要為公司導入穩定文件解析系統的工程師，還是單純想在專案中加入強大文字辨識功能的開發者，這套方案都準備了極度友善的開源資源。大家可以直接前往 PaddleOCR 官方 GitHub 儲存庫 尋找支援自訂資料集訓練與微調的工具。如果習慣使用社群主流工具，開發團隊也提供了 Hugging Face 的無縫整合支援。只要確保 transformers 套件版本大於等於 5.8.0，就能直接呼叫這款強大的模型進行辨識實作。</description></item><item><title>開源文件處理新標準！NuExtract3 視覺語言模型實測與部署解析</title><link>https://www.communeify.com/tw/blog/nuextract3-document-extraction-review-parsing-efficiency/</link><guid isPermaLink="true">https://www.communeify.com/tw/blog/nuextract3-document-extraction-review-parsing-efficiency/</guid><pubDate>Tue, 26 May 2026 08:54:46 +0800</pubDate><description>開源文件處理新標準：解析 NuExtract3 的雙效合一與推論技術處理繁雜的文件，往往是日常開發與企業應用中最讓人頭痛的環節。滿是皺褶的收據照片、排版奇特的 PDF 檔案，或是跨頁的複雜表單，要把裡面的關鍵資訊精確抓取出來，從來都不是件輕鬆的事。大家一定都有過這種與資料苦苦奮戰的經驗。不過，現在有了一個極具吸引力的新選擇。
根據官方的 NuExtract3 發布消息 指出，NuMind 團隊帶來了一款基於 Qwen3.5-4B 架構的 40 億參數視覺語言模型（VLM）。它採用完全開源的 Apache-2.0 授權，並把企業界最需要的兩大核心功能完美揉合在一起。若開發團隊之前體驗過 NuMarkdown 的優異表現，那麼這次的全面升級版絕對會讓人眼睛一亮。
將結構化數據與 OCR 完美綁定要打造一個順暢的資料處理流程，往往需要拼湊多種工具。傳統的現代文件處理通常被硬生生拆分成兩個世界。
一邊是負責把文件轉成 JSON 格式的結構化數據提取工具。這項技術對銀行、保險公司來說特別重要，因為將姓名、金額這些欄位自動輸入系統，能省下極大的人力與時間成本。另一邊則是負責處理內容提取的 OCR 技術。它的任務是把整份文件的內容與排版，原封不動地轉換成 Markdown 格式。這可是讓企業內部文件順利餵給 AI 助手，或是建立 RAG 系統的重要基石。
這兩項工作本質上都在做「理解文件」這件事。那為什麼要分成兩個模型來跑呢？這正是 NuExtract3 想要解決的核心痛點。開發團隊成功將結構化提取與 OCR 內容提取整合進單一模型中。這項創新設計大幅簡化了企業的部署流程。工程師只需維護一套系統，就能同時滿足這兩種截然不同的業務需求。
聰明又精打細算的推論本領遇到充滿手繪表格或跨頁重疊儲存格的掃描檔，就算是目前市面上參數極大的通用模型，也常常會看得一頭霧水。為了解決這類複雜排版的陷阱，NuExtract3 導入了極具實用價值的「大聲思考」推論能力。
在給出最終答案前，模型會先仔細觀察。它會從文件的整體架構開始分析，一步一步推敲到具體的欄位名稱，藉此預判並避開可能的排版錯誤。你知道嗎？這種類似人類解題的邏輯，正是它能夠精確抓取資料的秘密武器。
但這裡有個無可避免的現實考量。思考是需要付出代價的。一般模型一旦開啟這類推論功能，往往會產生大量的思考 token。有時候，這些思考 token 的數量甚至會是最終輸出結果的十倍以上，導致運算成本與等待時間瞬間飆升。
為了兼顧預算與效能，NuExtract3 在訓練階段就特別透過強化學習針對這點進行了最佳化。它能將思考 token 的生成數量控制在與輸出 token 差不多的水準。平均下來大約只需要三百多個 token 就能完成推論。這在提取品質、運算成本與處理延遲之間，找到了一個非常完美的平衡點。更棒的是，開發者可以根據當下的任務需求，隨時自由開啟或關閉這項推論功能。
讓工程師不再頭痛的自訂指令與欄位控制把資料抓出來只是第一步。後面無盡的資料清理，往往才是真正折磨人的地方。為了大幅減少繁瑣的後置處理手續，這次的升級特別強化了對資料類型的精準掌控。
相較於上一代僅有少數幾種基礎設定，最新版本一口氣將支援的結構化提取欄位類型擴增到 20 種。不管是 ISO 8601 格式的日期與時間、國家代碼、多國貨幣，還是電子郵件、電話號碼，甚至連歐洲常用的 IBAN 與 BIC 格式，都能直接要求模型精準輸出。這點對於需要處理跨國合約或財務報表的開發者來說，絕對是一大福音。
過去為了引導模型抓對資料，工程師常常得絞盡腦汁進行「範本工程」。有時候甚至得把欄位名稱寫得超級長，例如標註「右下角的卡片存取碼」，只為了讓模型看懂。現在完全不需要這麼辛苦了。
新系統正式導入了自由形式指令（Freeform instructions）的支援。使用者可以直接在範本中加入一段白話文的指示。例如告訴模型：「存取碼是由 6 個數字組成，通常會出現在這張卡片的右下角」。模型看完指示後，就能準確無誤地完成任務。這種貼近人類日常對話的溝通方式，不僅直覺，也大幅提升了資訊抓取的精確度。
設備門檻超親民，輕鬆搞定本地部署聽到擁有 40 億參數，加上卓越的推論能力，很多人可能會先倒吸一口氣，擔心手邊的硬體設備根本跑不動。大家其實多慮了。
雖然開發團隊當初動用了 8 張 H100 頂級顯示卡，耗費了整整 3 天的時間來訓練這款模型，為的就是讓它具備極強的長篇內容理解力。但對於想要親自動手測試的終端使用者來說，硬體門檻可是出乎意料的低。</description></item><item><title>0.9B 參數挑戰 SOTA！智譜 GLM-OCR 開源：讓文檔解析快 10 倍</title><link>https://www.communeify.com/tw/blog/zhipu-ai-glm-ocr-opensource-0-9b-document-parsing/</link><guid isPermaLink="true">https://www.communeify.com/tw/blog/zhipu-ai-glm-ocr-opensource-0-9b-document-parsing/</guid><pubDate>Tue, 03 Feb 2026 08:54:46 +0800</pubDate><description> 智譜 AI 開源 GLM-OCR 模型，僅 0.9B 參數卻在複雜表格與公式識別上達到 SOTA 水平。性能直逼 GPT-5.2 與 Gemini-3-Pro，推理成本僅為傳統 OCR 的十分之一。立即了解如何部署這款輕量級文檔解析神器，實現 Markdown 與 JSON 結構化直出！
說實話，過去幾年的 AI 發展似乎讓人產生了一種迷思：只要模型參數量夠大，就能解決所有問題。各家科技巨頭爭相推出數百億、甚至千億參數的多模態大模型。然而，當開發者與企業真正要將這些巨無霸落地應用時，高昂的算力成本和令人崩潰的延遲往往成了最大的攔路虎。
難道沒有更輕便、更聰明的解法嗎？
智譜 AI 最新推出的 GLM-OCR 正好打破了這個僵局。這款輕量級專業 OCR 模型，參數規模僅有 0.9B。仔細想想看，不到 1B 的體積，聽起來似乎微不足道。但根據權威榜單 OmniDocBench V1.5 的最新數據，這款「小尺寸」模型卻以 94.62 分登頂，甚至在許多核心場景中超越了閉源大模型 GPT-5.2 與 Gemini-3-Pro。
這不單純是一次技術更新，而是一次效率的全面重塑。
以小博大：極致性價比與速度要衡量一款工具的實用性，速度絕對是硬指標。在相同的硬體環境與單副本測試條件下，GLM-OCR 展現了驚人的吞吐量。處理 PDF 文檔時，它能達到每秒 1.86 頁的速度，處理單張圖片也能達到每秒 0.67 張。這樣的表現顯著優於同類模型。
更重要的是部署的靈活性。由於參數量僅 0.9B，它完美支持 vLLM 和 SGLang 等主流框架部署。這意味著企業可以在本地伺服器，甚至算力有限的邊緣設備上運行這套系統。根據智譜官方的技術文檔顯示，這種輕量化設計讓推理延遲與算力開銷大幅降低，整體的運行成本大約只有傳統 OCR 方案的十分之一。
專攻「難啃」的文檔，連手寫公式也不放過傳統 OCR 工具面對工整的印刷體時表現尚可，但一旦遇到真實業務場景中混亂的版式，往往就束手無策了。不管是傾斜的掃描件、蓋滿印章的發票，還是手寫的數學公式，向來都是文檔解析的重災區。
GLM-OCR 針對這些複雜場景進行了專門的優化。在包含代碼文檔、複雜表格、印章等元素的測試中，它的識別準確度依然出色。以最讓人頭痛的數學公式識別為例，在 UniMERNet 基準測試中，GLM-OCR 拿下了 96.5 的高分，甚至超越了 GPT-5.2 的 90.5 分。</description></item><item><title>DeepSeek-OCR 2 重磅登場：機器終於學會像人類一樣「跳著讀」的視覺邏輯</title><link>https://www.communeify.com/tw/blog/deepseek-ocr-2-visual-causal-flow-human-reading-logic/</link><guid isPermaLink="true">https://www.communeify.com/tw/blog/deepseek-ocr-2-visual-causal-flow-human-reading-logic/</guid><pubDate>Wed, 28 Jan 2026 08:54:46 +0800</pubDate><description>DeepSeek 團隊最近又在開源社群丟下了一顆震撼彈。這次他們帶來的 DeepSeek-OCR 2，不僅僅是把 OCR（光學字元辨識）的準確率刷高了幾個百分點那麼簡單。這款模型觸及了一個長期以來被忽視、卻又至關重要的核心問題：機器看圖的方式，其實一直都是錯的。
如果你仔細觀察過現有的視覺模型，會發現它們都有一個「壞習慣」。無論圖片內容是什麼，它們總是死板地從左上角掃描到右下角（Raster-scan）。但這真的是閱讀的正確方式嗎？想想看你在讀報紙、看複雜圖表或者是瀏覽網頁的時候，視線是怎麼移動的？你的眼睛會根據標題、欄位、圖片的邏輯關係「跳躍」移動，這才是人類的閱讀直覺。
DeepSeek-OCR 2 的核心突破，就在於它試圖教會機器這種**「視覺因果流（Visual Causal Flow）」**。
為何傳統的「掃描式」閱讀已經過時？這是一個很有趣的現象。目前的視覺語言模型（VLMs）大多把 2D 圖像強行壓扁成 1D 的序列，而且順序是固定的。這種做法在處理簡單圖片時沒問題，但一遇到複雜的文檔佈局，比如多欄排版的學術論文、巢狀表格或者是圖文穿插的雜誌，模型就會「暈頭轉向」。
因為空間上的相鄰，並不代表語意上的相連。
DeepSeek 的研究人員發現，要解決這個問題，不能只靠堆疊參數量。他們提出了一個全新的概念：讓編碼器（Encoder）具備推理能力。這就是 DeepSeek-OCR 2 的秘密武器 —— DeepEncoder V2。它不再是那個只會被動接收像素的攝像頭，而更像是一個懂得先「整理思緒」再進行閱讀的大腦前額葉。
DeepEncoder V2：用語言模型的腦袋來看世界這部分的技術細節非常值得玩味。通常，視覺模型的編碼器會使用像 CLIP 這樣的架構。但 DeepSeek 這次做了一個大膽的嘗試：他們把編碼器換成了一個語言模型（LLM）。
具體來說，他們使用了 Qwen2-0.5B 作為視覺編碼器的底座。你沒看錯，用一個語言模型來處理視覺訊號。這裡的邏輯在於，語言模型天生就擅長處理序列和因果關係。
這個「混血」架構是如何運作的？ 視覺標記化（Vision Tokenizer）： 首先，圖像會經過一個輕量級的 Tokenizer（基於 SAM-base），這一步主要是為了壓縮資訊，把龐大的像素數據變成模型能消化的小塊。 視覺因果流（Visual Causal Flow）： 這是最精彩的部分。模型引入了一組**「可學習的查詢（Learnable Queries）」。這些查詢 Token 不會死板地按位置排列，而是採用了因果注意力機制**。這意味著，每一個查詢 Token 在讀取資訊時，都會參考之前的上下文，主動地去圖像中「抓取」下一個邏輯上應該出現的內容。 簡單來說，這個過程就像是模型在說：「好的，我讀完了標題，根據邏輯，接下來我應該去找第一段的文字，而不是旁邊那張無關的廣告圖。」
效能與成本的極致平衡：劍指 Gemini在 AI 領域，效能強大通常意味著算力昂貴。但 DeepSeek-OCR 2 在這方面展現了極佳的控制力。
透過這種新的架構，DeepSeek-OCR 2 能夠在保持極高壓縮率的同時，提升理解能力。論文中提到一個非常具體的數據：輸入給 LLM 的視覺 Token 數量被控制在 256 到 1120 個之間。
為什麼是 1120？這並不是隨機選的數字。這正是 Google 的 Gemini-3 Pro 模型的最大視覺 Token 預算。DeepSeek 顯然是有備而來，他們希望在相同的資源限制下，證明開源架構也能達到、甚至超越頂級閉源模型的效率。</description></item><item><title>騰訊開源 HunyuanOCR 模型：1B 參數如何挑戰 OCR 辨識極限</title><link>https://www.communeify.com/tw/blog/tencent-hunyuan-ocr-opensource-1b-model-challenge-limits/</link><guid isPermaLink="true">https://www.communeify.com/tw/blog/tencent-hunyuan-ocr-opensource-1b-model-challenge-limits/</guid><pubDate>Wed, 26 Nov 2025 08:54:46 +0800</pubDate><description> 騰訊最新發布的 HunyuanOCR 以僅 10 億（1B）參數的輕量化設計，在 OmniDocBench 等多個權威測試中擊敗 GPT-4o 與 Gemini。本文將深入解析這款原生多模態模型的架構優勢、實測數據表現及其在文檔解析、場景文字識別與翻譯上的應用潛力。
說實話，提到 OCR（光學字元辨識）技術，大多數人腦中浮現的可能還是那些笨重、偶爾失靈的老舊掃描軟體。或者，我們會直接把圖片丟給 ChatGPT，期待它能看懂那張模糊的收據。但如果告訴你，有一個僅有 10 億參數的「小模型」，在看圖認字這件事上，竟然比那些龐大的通用模型還要精準，你敢信嗎？
這就是騰訊混元團隊最近帶來的驚喜——HunyuanOCR。
這不僅僅是一個新的開源專案，它展示了一種趨勢：在特定領域，精巧的專用模型往往能展現出驚人的爆發力。不需要動輒千億參數的算力怪獸，只要架構對了，小模型照樣能打。
輕量級與高效能的平衡藝術我們習慣了「越大越好」的思維模式。但在 AI 的世界裡，效率有時候比規模更重要。
HunyuanOCR 的核心亮點在於它採用了原生多模態架構（Native Multimodal Architecture）。這聽起來有點饒舌？簡單來說，它不是把一個視覺模型和一個語言模型硬湊在一起，而是從一開始就是為了「看懂圖文」而生的。
為什麼 1B 參數很重要？HunyuanOCR 只有 1B（10 億）參數。對於開發者或企業來說，這意味著極低的部署成本。你不需要租用昂貴的 H100 伺服器集群，甚至在一些邊緣設備上都有運行的可能。
儘管體積小，它卻是一個端到端（End-to-End）的專家級模型。傳統的 OCR 流程往往是「先偵測文字位置、再切割、最後辨識」，這中間只要一步出錯，結果就歪了。HunyuanOCR 則是直接看圖說話，這讓它在處理複雜排版時更加得心應手。
數據會說話：HunyuanOCR 在基準測試中的宰制力光說不練假把戲。讓我們來看看官方釋出的 OmniDocBench 評測數據，這張圖表透露了很多有趣的細節。
文檔解析能力 (Parsing)在 OmniDocBench 這個針對文檔解析的測試中，HunyuanOCR 拿下了 94.10 的高分，穩居第一。
請注意看排在後面的名字：
PaddleOCR-VL：92.86 GPT-4o：75.02 Marker-1.8.2：71.30 這是一個非常有趣的現象。GPT-4o 雖然是目前地表最強的通用模型，但在這種需要極度精確還原排版、識別細微文字的專業任務上，反而輸給了專精於此的 HunyuanOCR。這就好比你讓一個博學多聞的教授去參加拼字比賽，他不一定能贏過專門訓練拼字的選手。
複雜場景文字識別 (Spotting)在 Multi-Scenes（多場景）測試中，挑戰的是「野生」圖片——路牌、招牌、混亂背景下的文字。
HunyuanOCR 取得了 70.92 的 NED 分數（Normalized Edit Distance，分數越高越好）。相比之下，Baidu-OCR 只有 61.90，而 PaddleOCR 則在 53.38。這顯示出 HunyuanOCR 在處理自然場景、光影變化或模糊文字時，具有更強的魯棒性。</description></item><item><title>AI 如何提升日文漫畫文字辨識？一個新 OCR 模型的應用</title><link>https://www.communeify.com/tw/blog/ai-japanese-manga-ocr-new-model-application/</link><guid isPermaLink="true">https://www.communeify.com/tw/blog/ai-japanese-manga-ocr-new-model-application/</guid><pubDate>Fri, 07 Nov 2025 08:54:46 +0800</pubDate><description> 對於許多漫畫讀者和開發者來說，準確辨識漫畫中的文字一直是一項挑戰。最近，一個專為日本漫畫微調的 AI 文字辨識（OCR）模型，將辨識準確率從 27% 提升至 70%，為漫畫翻譯和相關應用提供了新的可能性。
對於喜歡直接閱讀原文漫畫的讀者來說，語言隔閡往往是第一個挑戰。而對於想透過工具輔助閱讀或進行翻譯的人來說，如何讓電腦準確「讀懂」漫畫中的文字，則是一個重要的技術問題。
這背後的核心技術，稱為光學字元辨識（Optical Character Recognition, OCR）。雖然現今的 OCR 技術在處理標準文件時已相當成熟，但一旦應用場景換成漫畫，就會面臨許多困難。
為什麼辨識漫畫文字這麼困難？漫畫的文字呈現方式與一般文件有很大的不同，這為 OCR 技術帶來了幾個主要的挑戰：
多變的字體風格： 漫畫家常會使用各種藝術字體來傳達角色的情緒或聲音的張力，這些非標準化的字體對電腦來說難以辨識。 不規則的排版： 對話框內的文字可以是直書、橫書，甚至傾斜排列，增加了定位和辨識的複雜度。 複雜的背景干擾： 文字經常疊加在豐富的畫面或效果線上，不像白紙黑字那樣清晰分明。 特殊的漫畫符號： 大量的擬聲詞和效果字是漫畫獨有的表達方式，通用型的 OCR 模型通常沒有針對這些內容進行訓練。 因為這些因素，大多數通用的 OCR 工具在處理漫畫時，辨識結果的準確率並不理想。
專為漫畫設計的 PaddleOCR-VL-For-Manga 模型為了解決這個問題，有開發者針對日本漫畫的特性，推出了一個名為「PaddleOCR-VL-For-Manga」的特製 AI 模型。
這個專案的基礎是百度 PaddlePaddle 團隊所開發的視覺語言模型 PaddleOCR-VL。為了讓它能更好地適應漫畫場景，開發者進行了所謂的「微調」（Fine-tuning），也就是用特定領域的資料對模型進行額外訓練。
訓練資料主要來自 Manga109-s 資料集，並輔以 150 萬個額外生成的合成樣本。透過這些專門的漫畫資料，模型得以學習如何辨識漫畫中各種特殊的文字風格和版面配置。
關於 Manga109-s 資料集
Manga109 是一個由學術機構彙編、包含 109 部日本漫畫的研究用資料集。其中的 Manga109-s 子集特別授權可用於商業開發，為相關應用的研究提供了寶貴的資源。
辨識成果：準確率從 27% 提升至 70%經過這次專門的微調，模型的表現有了顯著的提升。
根據開發者公布的資訊，原版模型在漫畫上的完整句子辨識準確率約為 27%，而經過微調的「PaddleOCR-VL-For-Manga」模型，準確率則提高到了 70%。這項進展意味著，模型能更完整地辨識出對話框中的句子，而不僅僅是零碎的單詞。
新模型在處理漫畫對話泡泡和風格化字體方面表現不錯。不過，開發者也指出，模型在區分「全形」與「半形」字元時仍有改善空間。儘管如此，這依然是漫畫 OCR 技術領域一個值得關注的發展。
如何使用這個模型？這個模型是開源的，對這項技術感興趣的開發者可以在 Hugging Face 平台上找到它。
使用者可以透過 Transformers、PaddleOCR 或其他支援 PaddleOCR-VL 的程式庫來調用這個模型。開發者建議，若要處理有固定版面的文件，可以嘗試將其與 PP-DocLayoutV2 佈局分析工具結合使用，但同時也提醒，漫畫的版面配置與標準文件存在差異。</description></item><item><title>文件處理的遊戲規則改變者？PaddleOCR-VL 深入解析：輕巧、強大，還支援109種語言</title><link>https://www.communeify.com/tw/blog/paddleocr-vl-multilingual-document-processing-109-languages/</link><guid isPermaLink="true">https://www.communeify.com/tw/blog/paddleocr-vl-multilingual-document-processing-109-languages/</guid><pubDate>Wed, 22 Oct 2025 08:54:46 +0800</pubDate><description> 你是否也曾深陷在處理 PDF 報告、掃描文件和充滿圖表的論文中，為了手動複製貼上而耗費大量時間？現在，一個名為 PaddleOCR-VL 的新工具或許能徹底改變這一切。它不僅擁有頂尖的辨識準確率，更兼具輕量化與高效率的特點，甚至能在沒有網路的環境下運行。本文將帶你深入了解它的獨到之處。
你的文件處理流程，是不是也卡關了？在日常工作或研究中，我們總會遇到各種非結構化文件——可能是掃描的合約、多欄位的 PDF 研究報告，或是充滿複雜表格的財務報表。要把這些資料變成電腦可以處理的結構化格式（例如 JSON 或 Markdown），過程往往痛苦不堪。
傳統的 OCR（光學字元辨識）工具在處理純文字時或許還行，但一碰到表格、數學公式，甚至是手寫字跡，辨識結果就常常慘不忍睹。你可能需要花費更多時間去校對和修正，效率不升反降。
但如果說，現在有一個模型，它不僅看得懂文字，更能理解整個文件的「版面佈局」，精準地抓出文字、表格、公式和圖表，你會不會覺得這聽起來太棒了？這就是 PaddleOCR-VL 誕生的使命。
PaddleOCR-VL 的核心秘密：一個輕巧卻強大的「視覺語言模型」PaddleOCR-VL 最令人驚豔的地方，在於其核心架構。它並不是一個龐大笨重的巨獸模型，而是一個專為文件解析量身打造的視覺語言模型（Vision-Language Model, VLM），參數規模僅有 0.9B（9億）。
讓我們用一個簡單的比喻來解釋。大型語言模型如 GPT-4o 或 Gemini 2.5 Pro 就像是知識淵博的通才，你可以跟它聊天、寫詩、做摘要。而 PaddleOCR-VL 則像是一位專門研究古籍和文件的考古學家，他對於「解析文件」這項任務有著極深的造詣。
它的厲害之處在於兩個關鍵整合：
NaViT 風格的視覺編碼器： 它能動態調整解析度，像人眼一樣，看到複雜區域時會「湊近一點」看清楚，簡單區域則「快速掃過」。這讓它在處理高解析度文件時，既能保持精準，又不會浪費運算資源。 輕量級的 ERNIE-4.5 語言模型： 擁有 0.3B 參數的 ERNIE 語言模型負責「理解」視覺編碼器傳來的資訊。它就像模型的大腦，能高效解讀圖像內容，並轉化為我們需要的結構化文字。 這樣的組合，讓 PaddleOCR-VL 在保持頂尖辨識能力的同時，大幅降低了對硬體資源的需求。這意味著什麼？這意味著它非常適合在企業內部網路，甚至在邊緣裝置上進行大規模部署，而不用擔心高昂的計算成本。
不只是說說而已：看看數據怎麼說空口無憑，性能才是硬道理。在 OmniDocBench 這個權威的文件理解評測基準上，PaddleOCR-VL 的表現確實讓人眼睛一亮。
從上方的圖表可以看到，PaddleOCR-VL 在「整體（Overall）」評分中拿下了 90 分的高分，超越了許多知名的模型和解決方案。更值得注意的是，它在幾個關鍵項目上的表現：
文字分數 (Text Score): 處理一般文字的能力是基本功，它在這方面表現穩健。 公式分數 (Formula Score): 這通常是 OCR 的一大痛點，但 PaddleOCR-VL 在數學公式的辨識上表現突出，遠超許多對手。 表格 TEDS (Table TEDS): 對於需要將表格完美還原的場景來說，它的表格結構辨識能力同樣名列前茅。 閱讀順序 (Reading Order Score): 在處理多欄位排版的複雜文件時，正確判斷閱讀順序至關重要，而它在這方面也展現了優異的理解能力。 這些數據證明了 PaddleOCR-VL 不僅能「辨識」文字，更能「理解」文件的結構，這對於實現真正自動化的文件處理流程至關重要。</description></item><item><title>Chandra OCR 模型：不只是文字識別，更是智慧文件處理的新革命</title><link>https://www.communeify.com/tw/blog/chandra-ocr-ai-model-smart-document-processing-revolution/</link><guid isPermaLink="true">https://www.communeify.com/tw/blog/chandra-ocr-ai-model-smart-document-processing-revolution/</guid><pubDate>Wed, 22 Oct 2025 08:54:46 +0800</pubDate><description> 厭倦了傳統 OCR 的不準確和限制嗎？來認識一下 Chandra，這款開源 OCR 模型不僅能精準轉換圖片和 PDF，更能完整保留原始排版，支援手寫字跡、表格和複雜文件。探索 Chandra 如何為開發者和企業帶來文件處理的全新可能。
你有沒有過這樣的經驗：拿到一份掃描的 PDF 文件或圖片，想把裡面的文字複製出來，結果貼上的卻是一堆亂碼？或是表格整個跑掉，得花大半天手動重新整理？這大概是許多人在處理數位文件時，都曾遇過的惡夢。
傳統的光學字元辨識（OCR）技術雖然行之有年，但在處理複雜排版、手寫字跡，或是包含大量表格和圖表的文件時，常常力不從心。辨識結果不準確、格式全失，後續的人工校對和整理，往往比直接手打一份還累。
但如果說，現在有一款 OCR 模型，不僅能精準辨識文字，還能像個智慧助理一樣，完美解析文件的結構，將其轉換成你需要的格式，聽起來是不是很吸引人？
今天的主角，就是這樣一個強大的工具——Chandra。
Chandra 是什麼？它不只是又一個 OCR 工具Chandra 是一個由 datalab-to 開發的高精度開源 OCR 模型。它最核心的理念，不僅僅是「讀懂」圖片或 PDF 裡的文字，而是「理解」整個文件的結構和排版。
想像一下，你給 Chandra 一份包含標題、段落、表格、圖片和註記的複雜報告 PDF。它回饋給你的，不是一大段混亂的純文字，而是一個結構化的 HTML、Markdown 或 JSON 檔案。標題還是標題，表格依然是表格，甚至連圖片和圖說的位置都幫你標記好了。
這就是 Chandra 與眾不同之處。它不只是文字的搬運工，更像是一位專業的排版師，將視覺化的文件內容，有條不紊地轉換成機器可讀的結構化資料。
Chandra 的神奇之處：不只是說說而已Chandra 的強大功能，來自於它對各類文件元素的深度支援。讓我們來看看它有什麼真本事。
handwritten-text-recognition, form-reconstruction, table-extraction令人驚豔的手寫辨識能力
手寫字跡的辨識，一直是 OCR 技術的一大挑戰。每個人的書寫風格都不同，字跡潦草、連筆更是家常便飯。Chandra 在這方面表現出色，對於常見的手寫內容有很好的支援度。無論是會議記錄、手寫筆記還是問卷調查，它都能大幅提高辨識的準確性，減少人工校對的麻煩。
精準的表單重建
處理表單是另一個常見的痛點。傳統 OCR 可能只能抓出表單上的文字，但對於欄位、選項（尤其是核取方塊）的對應關係卻難以掌握。Chandra 能夠準確地重建表單結構，包含文字欄位和勾選的核取方塊，這對於自動化資料輸入、問卷分析等應用場景來說，簡直是天大的福音。
複雜表格和數學公式？沒問題！
對於金融報表、學術論文或技術手冊中常見的複雜表格和數學公式，Chandra 同樣應付自如。它能維持表格的行列結構，將其轉換為乾淨的 Markdown 或 HTML 格式，甚至能處理 LaTeX 數學方程式。 這意味著，你不再需要為了整理表格資料而焦頭爛額。
圖片和圖表也能智慧擷取
一份文件除了文字，通常還包含許多圖片和圖表。Chandra 不僅能將這些視覺元素從文件中抽取出來，還能智慧地辨識圖片的標題（captions），並將其與圖片本身關聯，提供完整的結構化資料。
支援超過 40 種語言，部署彈性高全球化的今天，處理多語言文件是基本需求。Chandra 支援超過 40 種語言，涵蓋了世界主要語系，讓它的應用範圍更加廣泛。</description></item><item><title>DeepSeek-OCR橫空出世：用「看圖」徹底改變AI處理文字的方式</title><link>https://www.communeify.com/tw/blog/deepseek-ocr-ai-image-to-text-revolution/</link><guid isPermaLink="true">https://www.communeify.com/tw/blog/deepseek-ocr-ai-image-to-text-revolution/</guid><pubDate>Tue, 21 Oct 2025 08:54:46 +0800</pubDate><description> 人工智慧新創公司 DeepSeek 近日發表了一款名為 DeepSeek-OCR 的開源模型，提出「上下文光學壓縮」的創新概念。它不再逐字閱讀，而是將大量文字轉換為圖像，讓AI用「看圖」的方式來理解，大幅降低了處理長文本的運算成本。這項技術不僅在壓縮率和準確率上表現驚人，更在多語言、圖表、化學式等多樣化場景中展現了強大的應用潛力，為解決大型語言模型（LLM）的長文本處理難題開闢了一條全新的道路。
你有沒有想過，對AI來說，閱讀一篇長篇大論，可能比看一張圖還費力？這聽起來有點違反直覺，但卻是當前大型語言模型（LLM）面臨的現實困境。隨著文本長度的增加，運算成本呈指數級增長，這極大地限制了AI處理複雜文件的能力。
為了解決這個問題，來自杭州的新創公司 DeepSeek 提出了一個堪稱「異想天開」的解決方案：DeepSeek-OCR。這款模型的核心思想，是將文字「光學化」，把成千上萬的文字Token壓縮成數百個視覺Token，讓AI從「閱讀者」轉變為「看圖者」。
一個顛覆性的想法：上下文光學壓縮這項被稱為「上下文光學壓縮」（Contexts Optical Compression）的技術，旨在利用視覺這種媒介來高效壓縮文字資訊。簡單來說，它先把長篇的文字內容渲染成一張或多張圖片，然後再讓模型來「讀取」這些圖片。
你可能會問，這樣做的意義何在？答案是：效率。
實驗數據顯示，在10倍的壓縮率下，DeepSeek-OCR的解碼準確率高達97%，幾乎是無損壓縮；即便是在接近20倍的極限壓縮下，準確率仍能維持在60%左右。 這意味著，一篇1000個單詞的文章，可以被壓縮成僅需100個視覺Token就能代表的圖像，而模型依然能準確理解其內容。
這項突破為解決LLM的長文本挑戰提供了一個極具潛力的方向，同時也為AI的記憶與遺忘機制研究帶來了新的啟發。
DeepSeek-OCR 的核心架構：雙引擎驅動DeepSeek-OCR 的強大能力，源於其精心設計的雙組件架構：DeepEncoder 和 DeepSeek3B-MoE 解碼器。
DeepEncoder（深度編碼器）：作為核心引擎，它專為高解析度、高壓縮率的文件處理而設計。它巧妙地結合了兩種注意力機制：基於SAM的「窗口注意力」用來捕捉局部細節，而基於CLIP的「全局注意力」則負責理解整體視覺知識。 這種設計確保了在高解析度輸入下，模型能保持低活躍度，並產出極少量的視覺Token，從而有效控制運算資源。
DeepSeek3B-MoE 解碼器：這是一個擁有5.7億活躍參數的「專家混合」（Mixture-of-Experts）模型。 它的作用是將DeepEncoder壓縮後的視覺Token，精準地還原成原始的文字內容。MoE架構讓模型在處理特定任務時，只會「喚醒」一部分專家網路，從而在保證強大表達能力的同時，維持了極高的運算效率。
性能超越主流模型，重新定義OCR標竿在實際測試中，DeepSeek-OCR 的表現令人印象深刻。在權威的 OmniDocBench 文件理解基準測試中，它僅用100個視覺Token，就超越了需要256個Token的GOT-OCR2.0模型；並且，使用少於800個視覺Token，其性能就超過了平均需要近7000個Token的MinerU2.0。
這些數據充分證明，DeepSeek-OCR不僅是一個實驗性的概念，更具備了強大的實際應用價值。在生產環境中，僅需單張NVIDIA A100-40G GPU，每天就能生成超過20萬頁的訓練數據，為大規模文件理解和多模態模型訓練提供了堅實的基礎。
不只是文字識別：「深度解析」開啟無限可能DeepSeek-OCR 的能力遠不止於簡單的文字提取。它擁有一項被稱為「深度解析」（Deep Parsing）的殺手級功能，能夠透過二次模型調用，深入解析文件中的複雜圖像內容。
這意味著，無論是財報中的圖表、論文裡的化學式，還是教科書上的幾何圖形，DeepSeek-OCR都能準確識別，並將其轉換為結構化的數據格式，例如HTML表格或SMILES化學式。 這在金融、科研和教育等領域具有不可估量的應用價值。
此外，得益於其在超過100種語言的大規模數據集上的訓練，DeepSeek-OCR 還具備強大的多語言處理能力，能夠輕鬆應對全球化的文件處理需求。
未來的展望：通往無限上下文的道路DeepSeek-OCR 的出現，不僅僅是一款新模型的發布，它更像是一種對未來AI架構的探索。 這種將歷史對話或舊有資料渲染成圖片，並根據時間遠近調整其解析度和Token佔用的方式，模擬了人類的記憶曲線——新記憶清晰，舊記憶模糊。
這項技術有望為實現「理論上無限的上下文架構」鋪平道路，讓AI能夠在保持高效運算的同時，兼顧資訊的長期記憶與保留。
目前，DeepSeek-OCR的模型權重已在 Hugging Face 和 GitHub 上開源，供開發者和研究人員探索。這項技術的潛力才剛剛開始被挖掘，它將如何改變我們與資訊互動的方式，值得我們共同期待。</description></item><item><title>Nanonets-OCR2 全面解析：不只是 OCR，更是新一代文件智慧處理引擎</title><link>https://www.communeify.com/tw/blog/nanonets-ocr2-next-gen-document-intelligence-engine/</link><guid isPermaLink="true">https://www.communeify.com/tw/blog/nanonets-ocr2-next-gen-document-intelligence-engine/</guid><pubDate>Wed, 15 Oct 2025 08:54:46 +0800</pubDate><description> 探索 Nanonets 最新開源的 OCR2 模型套件。從自動轉換 LaTeX 數學公式、智慧描述圖表，到精準處理手寫文件與複雜表格，Nanonets-OCR2 正在重新定義文件處理的極限。本文將深入解析其強大功能、背後技術，以及如何徹底改變您的工作流程。
你有沒有想過，如果電腦能像人一樣「讀懂」一份文件，那會是什麼樣子？不只是辨識文字，而是真正理解文件的結構、內容，甚至是圖表和簽名背後的意義。過去這聽起來像是科幻小說，但現在，Natornets 最新發布並開源的 OCR2 系列模型，讓這一切變得觸手可及。
這不僅僅是Nanonets-OCR-s 的一次小升級，而是一場徹底的革新。Nanonets-OCR2 是一套先進的模型，專為將複雜的影像文件轉換為結構化 Markdown 而設計，並加入了強大的視覺問答 (Visual Question Answering, VQA) 功能。 想像一下，無論是學術論文、財務報表，還是手寫的合約，你都能將其瞬間轉化為機器可讀、易於處理的格式。
這套模型系列包含了 Nanonets-OCR2-Plus、Nanonets-OCR2-3B 與 Nanonets-OCR2-1.5B-exp 三個版本，能滿足不同場景下的需求。 這一切的背後，是基於強大的 Qwen2-VL 模型進行微調的成果。 其中，3B 版本在超過 300 萬頁的真實世界文件中進行了訓練，涵蓋論文、財報、合約、病歷、稅表、收據，甚至是多國語言和手寫文件，確保了其在複雜場景下的驚人準確性。
讓我們一起來看看，這個被譽為「文件處理神器」的工具，究竟藏了哪些黑科技。
不再只是文字辨識，而是真正的「文件理解」傳統 OCR 工具的任務很單純：把圖片裡的文字抓出來。但 Nanonets-OCR2 的野心顯然不止於此。它追求的是對文件的「語義理解」，能夠辨識並標記文件中的各種元素，使其不僅可讀，更能被大型語言模型 (LLM) 進一步處理和分析。
數學公式也不怕：LaTeX 方程式自動轉換對於學術圈或工程領域的朋友來說，處理文件中的數學公式一直以來都是個頭痛的問題。傳統 OCR 遇到複雜的方程式時，往往只能輸出一堆亂碼。
Nanonets-OCR2 徹底解決了這個痛點。它能自動將文件中的數學方程式和公式，轉換為格式正確的 LaTeX 語法。 更聰明的是，它還能區分行內公式（用 $...$ 包圍）和獨立展示的公式（用 $$...$$ 包圍），完美還原文件的學術格式。
讓圖片會說話：智慧圖像描述一份報告或論文中，圖表往往承載了最核心的資訊。Nanonets-OCR2 能夠智慧地描述文件中的各類圖片，包括標誌、圖表、曲線圖等，並將描述內容放入結構化的 &amp;amp;lt;img&amp;amp;gt; 標籤中。 這不僅僅是簡單的標記，而是詳細說明圖片的內容、風格和上下文，讓大型語言模型也能「看懂」這些視覺資訊。
合約文件處理利器：簽名與浮水印精準提取在處理法律或商業文件時，簽名和浮水印的處理至關重要。Nanonets-OCR2 能夠精準地辨識文件中的簽名，並將其與其他文本分開，獨立輸出於 &amp;amp;lt;signature&amp;amp;gt; 標籤內。 同樣地，它也能偵測並提取文件中的浮水印文字，並將其放入 &amp;amp;lt;watermark&amp;amp;gt; 標籤中，確保重要資訊不被遺漏。
表單處理的救星：智慧核取方塊處理處理問卷、表單時，你是否曾被各種樣式的核取方塊搞得暈頭轉向？Nanonets-OCR2 能將表單中的核取方塊和圓形按鈕，轉換為標準化的 Unicode 符號 (☐, ☑, ☒)，確保了資料處理的一致性和可靠性。</description></item><item><title>dots.ocr：地表最強多語言文件解析神器？小模型也能顛覆大世界</title><link>https://www.communeify.com/tw/blog/dots-ocr-multilingual-document-processing-ai/</link><guid isPermaLink="true">https://www.communeify.com/tw/blog/dots-ocr-multilingual-document-processing-ai/</guid><pubDate>Sun, 10 Aug 2025 08:53:46 +0800</pubDate><description> 還在為複雜的文件辨識和資料擷取感到頭痛嗎？全新推出的 dots.ocr 以其僅 1.7B 的輕巧模型，在多語言文件解析領域展現了驚人的 SOTA 效能，不僅統一了版面偵測與內容辨識，更在速度和簡潔性上完勝許多大型模型。
你是否也曾被文件淹沒？坦白說，我們每天都在跟各種文件打交道。無論是掃描的 PDF 合約、充滿圖表的報告，還是夾雜著複雜數學公式的研究論文，光是把裡面的文字和資料好好「弄出來」，就足以讓人一個頭兩個大。傳統的 OCR（光學字元辨識）工具在處理單純文字時還算可以，但一旦版面變得複雜，或混雜了多種語言，效果往往差強人意。
這就是文件解析（Document Parsing）技術至關重要的原因。它不只是「讀字」，更要理解文件的結構——哪裡是標題、哪裡是表格、文字的閱讀順序是什麼。過去，要做到這點，往往需要一套複雜、由多個模型組成的系統，不僅笨重，而且效率低落。
但如果現在有一個工具，既能精準理解各種複雜文件，又支援多國語言，而且架構簡單、速度飛快呢？聽起來是不是有點太美好了？今天我們要介紹的主角 dots.ocr，似乎就是為了解決這些痛點而生的。
什麼是 dots.ocr？一個模型搞定所有事簡單來說，dots.ocr 是一個功能強大的多語言文件解析器。但它最酷的地方在於，它將版面偵測（Layout Detection）和內容辨識（Content Recognition）這兩件原本需要分開處理的任務，整合到了一個單一的視覺語言模型（Vision-Language Model, VLM）中。
這代表什麼？想像一下，傳統方法就像一個工廠的生產線，你需要先用一台機器（偵測模型）找出文件裡的表格和段落，再把這些部分送到另一台機器（辨識模型）去讀取內容。過程繁瑣，而且任何一個環節出錯，結果都會亂七八糟。
dots.ocr 則像一位全能管家，你看著整份文件，直接告訴他：「幫我把這份報告裡的表格和結論整理出來。」他就能一步到位，完美搞定。這種統一且簡潔的架構，是它顛覆傳統的第一步。
為何 dots.ocr 如此引人注目？不只是說說而已口說無憑，dots.ocr 的強大之處展現在各種評測數據和實際應用上。它主要有四大亮點，讓它在眾多模型中脫穎而出。
驚人效能：小而強大，不容小覷別看 dots.ocr 的基礎模型只有 1.7B 參數，比許多動輒數十億、甚至上百億參數的巨無霸模型小得多，但它的表現卻是頂尖水準。
從上方的評測圖表可以清楚看到，在端到端的評估中：
英文（EN）： dots.ocr 拿下了 87.5 的高分，領先所有對手。 中文（ZH）： 獲得 84.0 分，表現同樣出色。 多語言（Multilingual）： 以 82.3 的分數證明了其跨語言處理能力，再次奪冠。 更值得一提的是，在權威的通用文件解析基準測試 OmniDocBench 上，dots.ocr 在文字、表格和閱讀順序方面都達到了最先進（SOTA）的水平。即使是面對像數學公式這種極度複雜的辨識任務，它的表現也足以和 Doubao-1.5、gemini2.5-pro 這類規模大上許多的模型相媲美。這證明了，模型大小並非決定效能的唯一標準。
跨越語言藩籬：真正的多語言支援許多 OCR 工具都號稱支援多語言，但常常在處理非英語系，特別是那些資源較少的「低資源語言」時顯得力不從心。dots.ocr 則在這方面展現了決定性的優勢。
它不僅在中、英文等主流語言上表現優異，在內部進行的多語言文件基準測試中，無論是版面偵測還是內容辨識，都展現了極其穩健的解析能力。這對於需要處理國際文件、或是研究冷門語言文本的使用者來說，無疑是一大福音。圖表中的多語言分數就是最好的證明。
極簡架構：告別複雜，擁抱簡潔正如前面提到的，dots.ocr 的最大創新之一就是它的單一模型架構。傳統方法依賴複雜的多模型管線，不僅維護困難，也容易出錯。
dots.ocr 徹底改變了這個遊戲規則。使用者需要做的，僅僅是透過更改輸入的提示詞（Prompt），就能在不同任務之間自由切換。想辨識表格？給它辨識表格的指令。想擷取摘要？換個指令就行。這不僅大幅簡化了開發和使用流程，也證明了 VLM 在偵測任務上，完全有能力挑戰像 DocLayout-YOLO 這類傳統的專用偵測模型。
高效快速：魚與熊掌兼得在追求強大效能的同時，我們往往得犧牲速度。但 dots.ocr 打破了這個迷思。
它建立在一個輕巧的 1.7B 參數語言模型之上，這讓它的推理速度（Inference Speed）遠超那些基於龐大基礎模型建構的競爭對手。這意味著什麼？這代表使用者可以在更短的時間內處理更多的文件，同時也降低了對硬體資源的要求，無論是對於企業級的大量處理，還是個人開發者的快速驗證，都極具吸引力。</description></item><item><title>Google 又出招！LangExtract 開源函式庫登場，文字資料處理不再是惡夢</title><link>https://www.communeify.com/tw/blog/google-langextract-opensource-text-data-processing/</link><guid isPermaLink="true">https://www.communeify.com/tw/blog/google-langextract-opensource-text-data-processing/</guid><pubDate>Mon, 04 Aug 2025 08:53:46 +0800</pubDate><description> Google 最新開源的 Python 函式庫 LangExtract，利用 Gemini 等大型語言模型的強大能力，將雜亂無章的文字資料轉化為結構化資訊。本文將帶您深入了解這項工具如何顛覆醫療、商業等領域的資料處理方式。
你有沒有想過，那些散落在病歷、研究報告、新聞報導裡的龐大文字，如果能像整理好的 Excel 表格一樣清晰明瞭，會是多麽驚人的事？過去，這可能是資料科學家和開發者們的惡夢，但現在，情況可能要改變了。
Google 最近正式發布了一款名為 LangExtract 的全新開源 Python 函式庫。簡單來說，這是一個能幫你從非結構化文字中，高效提取出結構化資訊的超級工具。它背後的核心驅動力，正是像 Gemini 這樣強大的大型語言模型（LLM）。
這項工具的問世，無疑是為所有需要處理大量文字資料的人，提供了一把鋒利的瑞士刀，讓複雜的文字轉換工作變得前所未有的簡單。
所以，LangExtract 到底強在哪？你可能會想，市面上提取資訊的工具也不少，LangExtract 究竟有什麼特別之處？嗯，這就要從它幾個核心功能說起了，這些功能組合起來，確實讓它在眾多工具中脫穎而出。
精準到嚇人的溯源能力 這點真的非常關鍵。LangExtract 提取出的每一筆資料，都能精準地對應回原文的具體位置。更棒的是，它還支援互動式的高亮視覺化呈現。這代表什麼？當你在審核結果時，可以直接點擊，系統就會標示出這筆資料是從原文哪句話、哪個詞抓出來的，大大提升了驗證資料的準確性和效率。再也不用大海撈針般地來回比對了。
穩定可靠的結構化輸出 你只需要給它幾個簡單的範例（這在術語上叫 a few-shot learning），告訴它你想要的輸出格式，LangExtract 就能結合 Gemini 這類模型的強大生成能力，穩定地輸出你預設好的 JSON 格式。這確保了資料的一致性，對於後續的分析和應用至關重要。
長文檔處理？小菜一碟！ 處理幾百頁的報告或論文，常常會遇到「大海撈針」的窘境——重要的資訊就藏在其中一小段。LangExtract 針對這個痛點，設計了智慧分塊和平行處理的策略，甚至能透過多輪提取來提高召回率，確保不會遺漏任何關鍵細節。
一鍵生成視覺化報告 這大概是最貼心的功能之一了。只需一個指令，LangExtract 就能產生一份精美的 HTML 報告。你可以在瀏覽器中直觀地查看所有提取結果和它們在原文中的對應位置，讓整個審核過程變得輕鬆愉快。
模型支援超靈活 無論你習慣使用雲端模型（像 Google 自家的 Gemini），還是偏好在本地端透過 Ollama 運行開源模型，LangExtract 都能支援。這份彈性讓它能滿足不同開發者和企業在安全性、成本和客製化方面的多樣需求。
LangExtract 的應用：不只是工程師的玩具說了這麼多，這項技術到底能用在哪裡？它的應用場景遠比你想像的要廣泛，幾乎可以賦能所有需要處理文字資料的行業。
醫療領域：臨床決策的得力助手在醫療領域，LangExtract 有一個名為 RadExtract 的子專案，專門用來處理放射學報告或臨床筆記。醫生和研究人員可以利用它，快速從報告中提取出藥物名稱、使用劑量、診斷結果等關鍵資訊，並生成結構化的數據。
試想一下，醫院能將堆積如山的非結構化病歷，輕鬆轉換為包含關鍵實體的 JSONL 檔案，這對於臨床決策支援、藥物研究分析有多大的幫助？
文學研究：看透《羅密歐與茱麗葉》的人物關係你沒看錯，文學研究者也能從中受益。過去需要耗費數月甚至數年的人工閱讀和標記，現在可以交給 LangExtract。例如，研究人員可以利用它來分析莎士比亞的《羅密歐與茱麗葉》，提取出所有人物之間的關係和情感互動，甚至產生視覺化的網絡圖，從一個全新的數據視角來深入探討文本的內涵。
商業情報：在資訊戰中搶得先機在商場上，資訊就是金錢。企業可以利用 LangExtract 從每日成千上萬的新聞報導、社群媒體貼文或市場分析報告中，自動提取競爭對手的公司名稱、新產品資訊、市場趨勢等關鍵實體。這不僅能大幅節省人力，更能幫助企業快速做出反應，制定更精準的競爭策略。
最棒的是，LangExtract 讓使用者可以透過簡單的提示詞（Prompt）和少量範例來自訂提取任務，完全不需要耗時耗力的模型微調，大大降低了使用的技術門檻。
LangExtract 的推出，為我們處理非結構化文字開啟了一扇新的大門。無論你是哪個領域的專家，只要你的工作與文字相關，這款工具都有可能成為你手中最強大的武器。
對這個專案感興趣嗎？你可以到他們的 GitHub 頁面了解更多詳情：https://github.com/google/langextract</description></item><item><title>Nanonets-OCR-s：不只是 OCR！開源模型讓你輕鬆將圖片轉為完美 Markdown，連 LaTeX、表格都搞定</title><link>https://www.communeify.com/tw/blog/nanonets-ocr-s-image-to-markdown-latex-tables-opensource/</link><guid isPermaLink="true">https://www.communeify.com/tw/blog/nanonets-ocr-s-image-to-markdown-latex-tables-opensource/</guid><pubDate>Fri, 13 Jun 2025 10:07:46 +0800</pubDate><description> 隆重介紹 Nanonets-OCR-s，一款強大的開源 OCR 模型，能將文件圖片精準轉換為結構化的 Markdown。從複雜的 LaTeX 方程式到表格、簽名、浮水印，它都能完美處理。開發者與研究人員必備！
身為開發者、研究人員，或是任何需要處理大量文件的人，你一定遇過這種頭痛的狀況：看到一份掃描的 PDF 或圖片檔，裡面的內容明明很重要，但你卻只能一個字一個字地手動打出來。傳統的 OCR (光學字元辨識) 工具或許能幫上點忙，但結果往往是一團亂碼，格式全跑掉，特別是遇到表格或數學公式時，簡直是場災難。
說真的，那種挫折感我們都懂。
但如果現在有一款工具，不只看得懂文字，還能理解文件的「結構」和「語境」呢？今天，我們要介紹的就是這樣一個改變遊戲規則的開源模型：Nanonets-OCR-s。
這是一個功能強大且輕量級 (3B) 的視覺語言模型 (VLM)，它的唯一使命，就是將各種複雜的文件圖片，轉換成乾淨、整齊、結構化的 Markdown 格式。你沒看錯，它懂得表格、能解析數學方程式，甚至連簽名、核取方塊這些小細節都不放過。
不只是文字，連數學公式都看得懂 (LaTeX 辨識)還在手動抄寫論文裡的數學公式嗎？那種痛苦的日子過去了。
Nanonets-OCR-s 最令人驚豔的功能之一，就是它對 LaTeX 數學公式的超高辨識度。它能夠智慧地區分行內公式 (inline-level math) 和獨立區塊公式 (block-level math)，並分別用 $...$ 和 $$...$$ 的標準格式輸出。
這意味著，無論是物理學論文、學術報告還是工程筆記，你都能將裡面的複雜公式一鍵轉換，直接貼到你的 Markdown 編輯器或研究筆記中，格式完美無缺。
圖片裡的圖片？沒問題，幫你寫好描述當文件中包含圖表、Logo、或任何嵌入式圖片時，一般的 OCR 工具通常會直接忽略它們。但 Nanonets-OCR-s 更聰明，它會使用結構化的 &amp;amp;lt;img&amp;amp;gt; 標籤來描述這些視覺元素。
想像一下，當你將辨識後的 Markdown 內容交給大型語言模型 (LLM) 進行下一步處理時，LLM 能夠透過這些描述，理解「這裡有一張公司的 Logo」或「這是一張銷售趨勢的長條圖」。這為自動化文件摘要、分析和報告生成打開了全新的可能性。
合約文件救星：自動偵測簽名處理合約或官方文件時，簽名是最重要的元素之一。過去，我們只能手動截圖或標註。
現在，Nanonets-OCR-s 能自動在掃描文件中找到簽名，並將其隔離在一個 &amp;amp;lt;signature&amp;amp;gt; 區塊中。這不僅讓文件數位化的過程更完整，也方便後續的歸檔和驗證工作。
重要資訊不遺漏：浮水印也能抓出來許多官方文件或草稿都會加上浮水印 (Watermark) 來標示其狀態或來源，例如「機密」、「草稿」等。這些資訊雖然不是文件主體，卻極其重要。
Nanonets-OCR-s 能夠精準地提取這些浮水印文字，並將其存放在 &amp;amp;lt;watermark&amp;amp;gt; 標籤內。這對於確保文件的可追溯性和完整性非常有幫助，避免了因忽略浮水印而導致的誤解。
問卷、表單處理變簡單了！智慧核取方塊辨識這聽起來可能只是個小細節，但對於需要處理大量問卷、申請表或清單的人來說，這簡直是福音。Nanonets-OCR-s 能夠辨識文件中的核取方塊 (Checkbox) 和選項按鈕 (Radio Button)，並將它們轉換成標準的 Unicode 符號，例如：</description></item><item><title>輝達出手，地表最強文件處理 AI？Nemotron Nano VL 登場，從此告別手動輸入！</title><link>https://www.communeify.com/tw/blog/nvidia-nemotron-nano-vl-ai-document-processing/</link><guid isPermaLink="true">https://www.communeify.com/tw/blog/nvidia-nemotron-nano-vl-ai-document-processing/</guid><pubDate>Tue, 10 Jun 2025 08:56:46 +1000</pubDate><description> 每天還在為處理成堆的報告、發票和掃描檔而頭痛嗎？英偉達（NVIDIA）最新發表的 Llama Nemotron Nano VL，可能就是你的救星。這款僅 8B 參數的輕量級視覺語言模型，卻在權威的 OCRBench v2 測試中一舉奪冠。它到底有多強？又將如何徹底改變我們與文件互動的方式？本文帶你深入了解這個小而強大的 AI 新星。
你有沒有過這種經驗？面對一疊厚厚的財務報表、掃描得歪七扭八的合約，或是充滿圖表的技術手冊，光是把裡面的資訊手動輸入電腦，就得花上大半天。這過程不僅枯燥乏味，還很容易出錯。老實說，誰不想要一個能「看懂」這些文件，並自動整理好重點的智慧小幫手呢？
好消息是，這個願望離我們越來越近了。繪圖晶片巨擘輝達（NVIDIA）在 2025 年 6 月初，正式推出了一款名為 Llama Nemotron Nano VL 的模型，它就像是專為解決上述煩惱而生的文件處理專家。
等等，Nemotron Nano VL 究竟是何方神聖？聽起來很厲害，但這串名字到底是什麼意思？讓我們把它拆解一下。
簡單來說，Llama Nemotron Nano VL 是一款「視覺語言模型」（Vision-Language Model, VLM）。你可以想像它是一個既會讀書（語言），又會看圖（視覺）的超級大腦。它不僅能讀懂文件上的文字，還能理解表格的結構、圖表中的數據關係，甚至是照片裡的內容。
這款模型厲害的地方在於它的「輕巧高效」。它基於 Meta 公司強大的 Llama 3.1 架構，並結合了輕量級的視覺編碼器。整個模型的參數規模只有 8B（80 億）。在動輒數千億參數的 AI 世界裡，8B 聽起來或許不大，但這正是它的優勢所在。
這代表什麼？
這代表你不需要一座龐大的數據中心來運行它。透過輝達的量化技術，它甚至可以在一台高階電競筆電（配備單張 NVIDIA RTX GPU）或是一個小巧的邊緣運算裝置（如 Jetson Orin）上順暢運作。這大大降低了企業或個人部署 AI 的門檻和成本。
更重要的是，它支援高達 16,000 個 token 的上下文長度。這意味著它可以一口氣「讀完」一份很長的文件，進行複雜的來回推理，而不是讀一句忘一句。
不只是讀懂文字，它還看懂了「版面」一個 AI 模型強不強，不能光靠自己說，得拿出真本事。Nemotron Nano VL 就在業界公認的「OCRBench v2」基準測試中，拿下了冠軍寶座。
這個測試可不簡單。它包含了超過一萬個由人工驗證過的問答題，涵蓋金融、醫療、法律、科學等多種領域的文件。考驗的不只是光學字元辨識（OCR）的準確度，更重要的是對表格、圖表和文件版面的綜合理解能力。
Nemotron Nano VL 的表現如何？</description></item><item><title>Llama-OCR：革新影像辨識技術，將文件完美轉換為Markdown格式</title><link>https://www.communeify.com/tw/blog/llama-ocr-revolutionizing-image-recognition-converts-documents-to-markdown-flawlessly/</link><guid isPermaLink="true">https://www.communeify.com/tw/blog/llama-ocr-revolutionizing-image-recognition-converts-documents-to-markdown-flawlessly/</guid><pubDate>Sat, 16 Nov 2024 10:52:46 +0800</pubDate><description>文章摘要 探索最新推出的開源OCR工具Llama-OCR，這款基於Llama 3.2 Vision的智慧影像辨識系統，不僅能夠精準辨識各類文件，更能直接輸出Markdown格式，為開發者和技術愛好者帶來全新的文件處理體驗。
為什麼選擇Llama-OCR？傳統的OCR工具在處理複雜版面時常常力不從心。Llama-OCR採用先進的視覺AI技術，特別在以下方面展現優勢：
表格識別準確度高 收據等複雜格式處理更優 混合格式文件的處理能力強 npm套件整合便利性高 核心功能特色1. 快速上手的整合體驗 極簡的安裝流程 基礎設定便能開始使用 npm套件提供完整文件 友善的開發者介面 2. Markdown格式輸出優勢 自動轉換為結構化文本 保留原始文件格式 適合文件系統整合 支援多種排版樣式 3. 未來功能展望 PDF文件支援 JSON格式輸出 擴充文件格式相容性 持續優化辨識準確度 技術原理解析Llama-OCR運用視覺模型進行文件分析，具備以下特點：
上下文理解能力強 結構化信息處理準確 AI驅動的智慧辨識 版面配置自動調整 快速入門指南 訪問 llamaOCR.com 體驗在線服務 透過npm安裝套件：npm install llama-ocr 參考官方文件進行基礎設定 開始使用影像轉換功能 常見問題解答（FAQ）Q1：Llama-OCR適合什麼場景使用？A：特別適合需要將圖片轉換為結構化文本的場景，如文件數位化、資料整理、文件管理系統等。
Q2：與其他OCR工具相比有什麼優勢？A：主要優勢在於直接輸出Markdown格式，以及對複雜版面的優異處理能力。
Q3：是否支援中文辨識？A：目前支援多種語言辨識，包括繁體中文在內的主要語言。
未來發展展望Llama-OCR團隊規劃了豐富的功能更新：
擴充文件格式支援 提供更多輸出選項 優化辨識準確度 增加API功能擴展 技術應用建議對於經常需要處理文件掃描的開發者來說，Llama-OCR提供了：
更高效的文件處理流程 更靈活的整合方案 更準確的辨識結果 更便捷的開發體驗 通過這些優勢，Llama-OCR正在重新定義OCR技術的應用範疇，為文件數位化處理帶來新的可能性。
可以前往來看影片範例</description></item></channel></rss>