Mistral OCR 4 把掃描檔變可引用資料

我拆解 Mistral OCR 4 的結構化輸出，順手給你一份可直接貼進 RAG、搜尋與審查流程的模板。

我做文件管線做久了，最怕的不是 OCR 看不懂字，是它看懂了字卻沒看懂版面。你丟進去的是合約、掃描件、亂七八糟的 PDF，吐出來的是一坨文字。看起來沒問題，真的要拿去引用、搜尋、丟給 agent，整個就開始鬆掉。表格被攤平、標題跟內文黏在一起、簽名消失、信心分數也常常像裝飾品。我以前就是一邊接 OCR、一邊補 layout detection、一邊寫後處理，忙到像在幫模型擦屁股。

所以我看到 AI Daily Post 這篇講 Mistral OCR 4 的文章時，耳朵就立起來了。它講的不是單純文字抽取，而是把 bounding boxes、block 類型、逐字 confidence 一起吐出來，還提到支援 170 種語言、10 個語言群組，甚至能用單一容器在地部署。這種東西才是工程師真的會在意的，不是那種只有 demo 好看、上線就開始出事的簡報話術。

我在意的不是標題多響亮，我在意的是輸出長什麼樣。只要模型能把文字、版面、信心一起交給我，我就能把後面的髒活一次寫好，不用每個檔案都人工盯。

純文字 OCR 是很多管線爛掉的起點

“The new version tacks on bounding boxes, typed-block labels and per-word confidence scores, turning a page into a map of where each element lives and what it means.”

翻譯一下就是：OCR 4 不只給你內容，還想給你文件結構。這聽起來很合理，但如果你做過實際系統，就知道大多數 OCR 根本不是這樣玩的。它們回傳一坨 text，運氣好再附一點座標；接下來就輪到你自己當 parser、layout engine、清洗工，全部包了。

我之前做過一條掃描發票的 ingestion 流程，log 看起來都很漂亮，文字也像是有那麼回事。結果一拿去做搜尋，line item 全亂，金額跟欄位名稱分家。模型是讀了頁面，但它沒有理解頁面。這差很多，差到會讓整條 pipeline 失去可信度。

bounding boxes 的價值在於你可以把文字放回頁面上。typed blocks 的價值在於你知道這段是 heading、paragraph、table cell、signature，還是別的鬼東西。confidence scores 的價值更直接，因為它讓你可以做決策，不用瞎猜。哪個區塊不穩，我就丟人工；哪個區塊很穩，就直接往下走。

實操上，我會把 OCR 當成一層結構化抽取，不是單純的前處理。下游系統應該拿到 JSON 或 markdown，而且裡面要有座標、類型、信心分數。你如果只拿純文字，後面遲早還是得自己補結構，差別只是你把成本延後了而已。

• 保留原始頁面影像，不要只留文字。
• block 類型不要扁平化成一坨段落。
• 用 confidence threshold 決定自動通過還是人工複核。

170 種語言聽起來很大，但真正省事的是少寫分支

來源文章說 OCR 4 支援 170 種語言，分成 10 個語言群組。這數字當然漂亮，但我不會把它當成戰績牆來看。我在意的是：每多一種語言，通常就多一坨脆弱的特殊處理，最後整個 codebase 變成補丁農場。

我以前碰過多語系檔案庫，最煩的從來不是「它看不看得懂」，而是「英文、阿拉伯文、法文、日文混在一起時，管線能不能維持一致」。如果 OCR 可以把這些輸入收斂成同一種結構化格式，我就能刪掉很多 if/else。這才是重點，不是語言數字本身。

OCR 4 的價值如果真像文章寫的那樣，就是把多語系文件變成同一種輸出。這對 enterprise search 跟 RAG 特別有用，因為你的文件庫本來就髒。你不會想為每個語言家族各開一條 ingestion path，除非你很喜歡維護沼澤。

實操上，我會先定一個 canonical schema，再開始 ingest。語言特化只在 OCR output 真的需要時才處理，不要因為 parser 先爆炸就提早分岔。另外，語言 metadata 一定要跟著 document 和 block 走，不然搜尋品質很快就歪掉。

• 所有 OCR 輸出先收斂到同一份 schema。
• document 與 block 都保留 language metadata。
• 混合語言文件要提早測，不要等上線才補洞。

單一容器部署，這才是我會認真看的一點

文章提到 OCR 4 可以做成單一容器，而且能完全 on-prem 部署。這不是可有可無的細節，這是我會拿來跟產品、資安、法遵一起吵的地方。

cloud-only OCR 很方便，直到你碰到法務文件、醫療掃描、金融資料，或任何會讓資安同事眉頭一皺的東西。這時候「丟到 API」就不再只是技術問題，而是要去談資料駐留、網路邊界、存取控管。容器化部署至少讓故事清楚一點，文件留在你自己的環境，管線也比較好控。我看過不少案子卡住好幾週，就是因為 OCR vendor 想碰那些沒人敢外送的文件。

這也會改變你看待 latency 和 throughput 的方式。模型如果就在你環境裡，你可以像管理內部服務一樣去 batch、queue、scale、observe。這不代表它免費，只代表它可治理。老實說，大多數團隊要的也就是這個。

實操上，我會直接把 OCR 當內部服務來管。CPU、memory、queue depth、每頁 latency 都要量。不要看到「single container」就以為一定輕量，這兩件事根本不是同一件事。

如果你要對照部署模式，可以看 Docker、Kubernetes，以及 Mistral AI 本身的產品脈絡；如果你也在看文件理解與標註流程，Landing AI 的做法也值得一起比。

confidence 分數不是裝飾，是讓人工複核不崩潰

來源文章特別提到 per-word confidence scores，還說低信心區域可以送去給 human verifier。這段我覺得很實際，因為我看過太多系統把整份文件丟進 review queue，然後美其名曰 human in the loop。那不叫流程，那叫折磨。

比較像樣的做法，是 confidence-aware review。你知道哪些字、哪些 block 是不穩的，就只送那些片段給人看。其他的直接自動流過去。這樣 review 時間會少很多，人的工作也不會一直在重看那些完全沒問題的頁面。

我之前做過一個理賠文件流程，手寫註記跟褪色印章很常把 OCR 弄歪。後來我們只把低 confidence 區塊送審，團隊立刻少掉一堆重工。這種改善不華麗，但很有感。

實操上，我會用 confidence band，而不是只有 pass / fail。高信心 block 自動接受，中信心 block 做 spot check，低信心 block 直接人工修。座標一定要保留，審查者才知道問題到底在哪裡。

• 先定高、中、低三段 confidence 閾值。
• 盡量 review block，不要 review 整份文件。
• 把人工修正記錄下來，之後才看得到 drift。

RAG 要的是可引用，不是看起來像引用

AI Daily Post 把 OCR 4 放在 RAG、enterprise search、agentic workflow 的脈絡裡，我覺得這很合理。因為 RAG 最常死掉的地方其實很無聊：來源資料結構太差，最後答案雖然像真的，卻根本講不出自己是從哪裡來的。大家常把 citation 問題怪到 prompt，但通常不是 prompt 的鍋，是資料長得太爛。

結構化 OCR 的價值，就是讓 retrieval 不只拿到文字 chunk，還拿到 block type、座標、信心。這樣你可以引用真正的 page region，而不是被 splitter 切爛之後的某段字串。做 search 時，snippet 會更準；做 RAG 時，grounding 會更穩；做評估時，你也才知道模型到底有沒有用對區塊。

我以前看過一些 retrieval 系統，答案技術上沒錯，但完全沒辦法辯護。因為來源文字早被扁平化成一團，沒人知道模型引用的是標題、註腳，還是表格旁邊的小註解。這就是結構化 OCR 真正要減少的爛局面。

實操上，我會把 OCR output 存成 retrieval-friendly 的格式，每個 chunk 都要帶 page、block type、bbox、confidence。然後 generator 才能真的 cite provenance，不是靠一個模糊的 text offset 硬撐。你如果有用 vector database，metadata 不要丟掉，跟 embedding 一起存。

搜尋這邊可以參考 Pinecone、Weaviate、Elastic 這類工具；它們在 source payload 誠實的時候，才真的比較好用。

OCR 4 是 ingestion layer，不是裁決者

來源裡有一句我滿認同的話：OCR 4 是 document-understanding model，不是 decision-maker。我喜歡這種講法，因為它至少沒把模型吹成萬能。很多團隊最愛犯的錯，就是把抽取、分類、驗證、批准全塞給同一個模型，然後再假裝這叫簡化。

OCR 應該做的是抽取、分類、定位，不是判斷合約有沒有法律效力、發票能不能核准、文件是不是可信。那種工作應該留給後面的 validator、business rules、retrieval logic，必要時再加 human review。你如果把層次混在一起，最後只會得到一個比較漂亮的失敗模式。

我看過太多系統把 OCR 當成終點，結果上線後每個人都開始懷疑資料。問題不是模型不夠強，是你把它放在錯的位置。它應該是前門，不是法官。

實操上，我會把 pipeline 切成 extraction、normalization、validation、action 四段。OCR 4 放第一段。任何像 approval、rejection、policy enforcement 的東西都放後面。這樣才不會把責任全丟給一個本來就不該決定業務結果的元件。

如果要回頭對照原始說法，這篇我用的是 AI Daily Post 的整理，不是我自己硬掰出來的產品宣傳。

可抄的模板

## OCR ingestion schema for citation-ready documents

把 OCR output 先收斂成這個 shape，再丟進 search、RAG、review。

{
  "document_id": "doc_123",
  "source_uri": "s3://bucket/path/to/file.pdf",
  "file_type": "pdf",
  "language": "en",
  "language_group": "latin",
  "page_count": 12,
  "pages": [
    {
      "page_number": 1,
      "width": 2480,
      "height": 3508,
      "blocks": [
        {
          "block_id": "p1_b1",
          "type": "heading",
          "text": "Master Services Agreement",
          "confidence": 0.98,
          "bbox": [120, 88, 1410, 210],
          "words": [
            {"text": "Master", "confidence": 0.99, "bbox": [120, 88, 320, 210]},
            {"text": "Services", "confidence": 0.98, "bbox": [340, 88, 620, 210]},
            {"text": "Agreement", "confidence": 0.98, "bbox": [640, 88, 1410, 210]}
          ]
        },
        {
          "block_id": "p1_b2",
          "type": "paragraph",
          "text": "This agreement is entered into as of...",
          "confidence": 0.94,
          "bbox": [124, 260, 2200, 410]
        },
        {
          "block_id": "p1_b3",
          "type": "table",
          "text": "",
          "confidence": 0.91,
          "bbox": [120, 520, 2300, 1450],
          "cells": [
            {"row": 1, "col": 1, "text": "Invoice #", "confidence": 0.99, "bbox": [140, 540, 420, 620]},
            {"row": 1, "col": 2, "text": "Amount", "confidence": 0.99, "bbox": [430, 540, 720, 620]}
          ]
        }
      ]
    }
  ]
}

## Review policy

accept_if:
  block_confidence_gte: 0.95
  word_confidence_gte: 0.92
spot_check_if:
  block_confidence_between: [0.85, 0.94]
manual_review_if:
  block_confidence_lt: 0.85
  contains_types: [signature, stamp, handwritten_note, equation]

## Ingestion steps

1. Run OCR and preserve page geometry.
2. Normalize blocks into the schema above.
3. Chunk by block type, not arbitrary character count.
4. Attach page number, bbox, and confidence to every chunk.
5. Send low-confidence regions to human review.
6. Index approved chunks in search or vector storage.
7. Keep the original image for audit and citation checks.

## Prompt for downstream RAG

You are answering from extracted document blocks. Use only the provided sources.
Cite page number, block type, and bounding box when possible.
If confidence is low, say so instead of guessing.

## Practical threshold starter

- High confidence: 0.95 and above
- Medium confidence: 0.85 to 0.94
- Low confidence: below 0.85

## What not to do

- Do not flatten tables into plain paragraphs.
- Do not drop bounding boxes after extraction.
- Do not treat OCR output as final truth.
- Do not send low-confidence text straight into approval workflows.

這段我會直接留在 repo 裡。它給你 schema、review policy、retrieval prompt，沒有把 OCR 假裝成魔法。只要 OCR 4 真能像文章說的那樣吐結構化輸出，你就可以拿這份 downstream format 直接接上去。

來源與我自己的部分

原始素材來自 AI Daily Post 的這篇文章，我這篇是拿它當錨點，拆成台灣開發者比較能直接用的 ingestion 思路。上面的 schema、threshold、review flow 和模板是我自己的實作整理，不是原文照抄。