前言
在數位轉型（DX）加速的現代，文件處理自動化已成為許多企業面臨的重要課題。特別是，從請求書和合同等非結構化數據中提取資訊，是提高生產力的關鍵。
作為解決這一課題的有力方案之一，微軟提供的「Azure AI 文件智能」備受關注。為了驗證其高性能，我本人也進行了測試。
本文將詳細闡述在測試過程中發現的使用 Free 計畫時的重要限制事項，以及相應的解決方案。希望這對於考慮導入該服務的讀者能提供有益的資訊。
Azure AI 文件智能的概覽
根據微軟 Learn 的定義，本服務是「從文件中高精度提取文本、佈局、鍵和值對等訊息的 AI 服務」。它利用機器學習模型，能夠從掃描的文件或數位 PDF 中自動生成結構化數據，而無需人為介入。
具體的應用案例包括以下場景：
- 請求書處理自動化：自動提取支付方、請求金額、項目等信息，並與會計系統進行聯結
- 身份證件驗證：從身分證或護照中讀取個人資訊，加快身份確認流程
- 合同管理效率化：提取合同當事人、合同期間、重要條款等資料，並進行數據庫化
這些功能具有顯著減少人工數據輸入成本和人為錯誤的潛力。
測試過程①：使用 Free 計畫進行初步測試
為了評估服務的有效性，我首先利用提供的Free (F0) 計畫搭建了測試環境。從 Azure 入口網站創建資源的步驟極為簡單，只需在價格層級中選擇「Free F0」。
部署完成後，我利用無需編碼的解析功能「Document Intelligence Studio」進行了解析測試。測試用的文件是 IPA 公開的資料「SEC BOOKS：IT 專案的「可視化」總集篇」的 PDF，這份資料長達數十頁，適合測試多頁識別性能。
問題出現：多頁 PDF 的識別範圍受限現象
確認解析結果時，我面臨了意想不到的情況。上傳的「SEC BOOKS：IT 專案的「可視化」總集篇」的 PDF 檔案中，只有前兩頁的解析結果被輸出。
(第 1 頁)
(第 2 頁)
(第 3 頁)
起初，我懷疑是檔案本身的問題或服務的暫時故障，並重複進行多次測試。然而，無論如何嘗試，第 3 頁以後都無法被識別。此時無法對該服務進行正確的評估。
原因判定：Free 計畫的規範和限制事項
為了解決問題，我檢查了官方文檔，結果發現原因並非服務的故障，而是Free 計畫所設立的規範。
在進行服務的概念證明（PoC）時，這一限制是相當重要的資訊。
測試過程②：利用 Standard 計畫再次驗證及結果
經過問題確認後，我立即使用Standard (S0) 計畫創建新資源，再次用「SEC BOOKS：IT 專案的「可視化」總集篇」的 PDF 進行測試。
結果，這次所有頁面都能正常識別。這使得我能正確評估 Azure AI 文件智能的本來性能。
(第 3 頁)
結論與思考：選擇計畫的重要性與未來展望
此次測試中獲得的最重要的見解是，在評估服務功能時，必須事先確認使用計畫的限制事項。
特別是 Free 計畫，僅用於功能的基本動作確認和小規模測試，並不適用於多頁文件的正式測試或實際運用。即使在 PoC 階段，依據評估對象的需求選擇合適的計畫（在本例中為 Standard 計畫）是關鍵的要素。
Azure AI 文件智能若能正確理解和應用它的功能，將擁有顛覆文件處理業務的強大潛力。未來，我們計畫針對更接近實務的文件如請求書和合同進行更詳細的精度驗證，並進行實際運用的評估。
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式