よくできた文書AIが2年で止まった——だからDEEP Opsをリリースしました

ひと目で把握

「それ、一昨年に自動化したのではなかったですか？」文書AIを導入した担当者なら、一度は耳にしたことのある言葉でしょう。うまく回っていたシステムが、ある日たった一つの項目の前で止まり、見積書がまた届き、会議でこの質問が飛び出します。

인식 넘어 이해하는 AI 뜬다…한국딥러닝, 문서 운영 ‘딥 옵스’ 출시

전 세계 지능형 문서처리(IDP) 시장이 올해 39억 달러에서 2033년 297억 달러로 커질 전망이다. 한국딥러닝은 추출 항목 수정과 성능 검증을 고객이 직접 할 수 있는 문서 AI 운영 플랫폼 ‘딥 옵스’를 출시했다.

https://www.donga.com/news/It/article/all/20260902/134590873/2

KDLは、去る9月2日にDEEP Opsをリリースしました。

文書AIには、なぜ別途の運用プラットフォームが必要なのでしょうか。この記事では、うまく回っていた文書AIが、時間とともになぜ止まるのか、運用の過程で実際に何を管理すべきか、そしてDEEP Opsがこの問題をどう解決するのかを、順を追って説明していきます。

問題は精度ではなく、変更でした

私たちが実際によく受けるお問い合わせの一つが、こうしたケースです。他社の文書AIを構築して2年近くうまく使ってきたのに、ある日、業務基準が変わったことで問題が生じます。

「告示が改正されて、支援対象の基準日という項目が追加されたのに、既存のシステムではこの項目が読めないのです。」

最初に構築したときは、問題ありませんでした。当時決められた文書と項目は、きちんと処理できていたからです。しかし新しい項目が追加されると、既存のシステムだけでは対応が難しくなります。システムが止まる理由は、精度ではありません。その項目を読むように学んだことがない、ということなのです。こうしたことは、思いのほか頻繁に起こります。

• 法令や告示が改正されるとき

• 商品や審査基準が変わるとき

• 取引先が新しい書式で書類を送ってくるとき

• 抽出結果の変更根拠と適用時点を記録に残さなければならないとき

結局、文書AIを長く運用するほど重要になるのは、最初に構築したときの精度だけではありません。業務が変わったとき、どれだけ速く基準を修正し、検証し、再び運用に反映できるかが、あわせて重要になってきます。

項目一つに、なぜ数週間もかかるのでしょうか

従来のOCR方式で抽出項目を一つ追加すると、次のような手順を踏みます。

短くて数週間、長ければ2か月かかります。

このとき、KDLが着目したのは期間ではなく、構造でした。導入の成果は一度出れば終わりなのに、変更のコストは業務が変わるたびに繰り返し発生します。時間が経つほど、文書AIは成果の項目ではなく、コストの項目として見え始めます。

これは、担当者がベンダーを選び間違えた結果ではありません。その時点のOCRが、変更というものを前提とせずに設計されていたからです。導入の段階で何を見るべきかは、OCR APIをつなげば自動化になるのか？『AI社員』を作る5つの導入基準に整理してありますが、この記事はその次の段階の話です。

最初はKDLも、再学習で解決していました

正直に言うと、KDLも当初は同じやり方でした。変更の依頼が来ると、データを受け取って再び学習させ、また再デプロイしていました。

ところが、顧客企業のプロジェクトで適用範囲が広がると、問題の性質が変わってきました。部署ごとに必要な抽出項目が違い、品質基準が違い、使うプロンプトも違いました。一つを変えると、他のところにどんな影響が及ぶのかを、ずっと見続けなければなりませんでした。

そのとき、気づいたことがあります。私たちが管理すべきなのは、モデルではありませんでした。

MLOpsが管理するのはモデル、文書AIで変わるのは業務基準

ソフトウェア業界はこの種の問題を何度も経験し、そのたびに運用体系を一つずつ作ってきました。

上から下へ読むと、管理対象が移っていくのが見えます。コードからモデルへ、モデルからプロンプトへ、と。

文書AIで実際に変わるのは、モデルではありません。法令が変わり、審査基準が変わり、抽出すべき項目が変わります。変わるのは、業務基準なのです。

だからMLOpsだけでは解決しません。MLOpsは優れた体系ですが、管理対象はモデルのパラメータです。業務基準が変わったときにMLOpsが出す答えは、結局のところ再学習です。ところが現場が求めているのは、「この項目もあわせて抽出してください」という一文なのです。

VLM Ops、文書AIのための運用体系

この空白を埋めるためにKDLが定義したのが、VLM Opsです。視覚言語モデルを実際の企業業務にデプロイし、調整し、品質を管理する運用体系です。VLMそのものについては、以下で扱いました。

문서를 '이해'하는 AI OCR, VLM OCR의 시대가 열렸다

VLM OCR의 개념과 기존 OCR과의 차이, 템플릿 없이 비정형 문서까지 읽는 원리, 그리고 2026년 글로벌 1위로 검증된 성능까지 정리했습니다. | ABOUT AI

https://koreadeep.com/blog/vlm-ocr

VLM Opsが資産として管理するのは4つで、それぞれにバージョンが付きます。

• モデル——どのVLMを使うか

• プロンプト——何をどう読むよう指示したか

• 抽出スキーマ——どの項目をどの形式で抽出するか

• 品質基準——どこまでを合格とみなすか

核心は、再利用です。

ある業務で検証を終えた組み合わせを保存しておき、別の部署、別の業務に持っていって使います。現場から出てきた評価結果や検収のフィードバックは、再び品質改善に反映されます。

全社的なAIプラットフォームの観点で見ると、これがなぜ必要なのかがはっきりします。企業がAIプラットフォームを作るとき、モデルのサービングやデータパイプラインまでは設計するのに、文書の層は空いている場合が多いのです。文書は部署ごとに書式が異なり、規定に応じて随時変わるため、中央で一度作れば終わり、という資産ではないからです。

この流れは、私たちだけが見ているわけではありません。

• 世界の知能型文書処理(IDP)市場:今年39億ドル → 2033年には297億ドルと予測

• 韓国の公共文書、hwpからhwpxという開放型フォーマットへの移行政策が始動

• 韓国・科学技術情報通信部のAI特化行政サービス事業が今年着手

文書を、AIが使える形として継続的に管理しなければならない時代が来たのです。とはいえ、体系さえあれば担当者が使えるでしょうか。いいえ。だからこそ、製品にしました。

DEEP Ops、その体系を製品に

DEEP Opsは、VLM Opsを実際に使えるようにした文書AIの運用プラットフォームです。文書AIを導入した後に変わる業務基準に合わせて、顧客が自らシステムを修正し、性能まで検証できるプラットフォームです。行うことは3つです。

すでにKDLの製品をお使いの方は、DEEP Agentと何が違うのか気になるかと思います。

DEEP Agent：文書を読んで業務を処理するAI社員DEEP Ops：そのAI社員の働き方、検証、管理

動作はシンプルです。担当者が自然言語で抽出基準を変えると新しいバージョンとして保存され、既存のバージョンと同じ文書で結果を比較したうえで、承認を経てデプロイされます。ステップごとの画面の流れはリリース案内の記事に整理してあるので、ここではその背後にある原則をお話しします。

自然言語で変えても、承認なしには反映されません

自然言語で変えられるからといって、誰もが運用中のシステムを好き勝手に変えられるようにすること、それがこの製品の目的ではありません。役割が分かれています。

この構造で最も大きく変わるのは、変更の主体です。ベンダーやAI開発者が行っていたことを、顧客の現場担当者が自ら行います。必要なものも、新規の学習データではなく、実際の文書と抽出基準があれば十分で、データが外に出ることもありません。

だからこそ、こう言えるようになりました。変更の回数に、もはやコストが付かなくなります。

• 事前に登録した書式でなくても読み取ります

• 抽出基準は、必要なだけ再定義します

• 業務フローは、必要なだけ構成します

私たちは、この方式が従来の新規構築の方式に比べて、少なくとも50パーセント以上コストを削減できると見込んでいます。

運用性能は、無介入率で測ります

ここが最も実務的な部分です。構築時の精度は契約書に書かれます。ところが、運用中の性能はたいていの組織が測っていません。何を測るべきか、決めたことがないからです。

4つのうち、導入効果を最も正直に示してくれるのが、無介入率です。

なぜでしょうか。フィールド精度95パーセントのシステムがあるとします。文書1件にフィールドが20個あれば、1件あたり平均1個が間違います。すると担当者は結局、すべての文書を開いて見なければなりません。精度は95パーセントなのに、無介入率はほぼ0という状況が、実際に起こります。

すでに文書AIをお使いなら、最初の問いはこれです。私たちは無介入率を測っているだろうか。

今お使いの文書AI、無介入率が何パーセントかご存じですか？ 実際の文書サンプルをもとに、現在の無介入率を測定します。

DEEP Opsが必要な理由

数字だけでは、DEEP Opsがどこで必要なのか、なかなか実感しにくいかもしれません。ここからは、製造品質の業務を例に、順を追ってお見せします。

製造現場でよく扱う文書の一つが、素材の入荷時にあわせて届く試験成績書(CoA)と検査証明書です。協力会社ごとに書式が異なり、引張強度・降伏強度・伸び率・硬度といった実測値に、印鑑、手書きメモ、QRなどがあわせて入ります。

今はこうです

確認が滞ると、入荷が滞ります。しかもこの時間の大部分は、判断ではなく、読んで照らし合わせる時間なのです。

文書AIを導入すると、こうなります

成績書をアップロードすると、必要な項目を文書AIが抽出します。

鋼管の検査証明書1枚をもとにテストしたときは、証明書番号、発行日、規格、寸法、等級、熱処理、引張強度、降伏強度、伸び率、硬度など、29個のフィールドが自動で捉えられました。

担当者は、必要なフィールドと抽出基準を決めればよいだけです。

QA確認をなくすことが目的ではありません。すべての成績書を人が最初から最後まで見る代わりに、基準値に近い、単位が異なる、値が欠落している、といった文書だけを確認する構造へと変えることが核心です。

DEEP Opsで運用すると、ここからさらにもう一段変わります

規格が改正され、新しい協力会社が別の書式の成績書を送ってきて、顧客の要望に応じて確認すべき項目も追加されます。従来の方式では、こうした変化が生じるたびに、開発と検証が再び必要でした。

DEEP Opsでは、業務基準そのものを、運用しながら変えます。

1. 自然言語で基準を変えます。「引張強度の実測値が規格最小値415MPa以上なら合格、未満なら不合格と表記」のように、新しい判定基準を追加します。

2. 変更内容をバージョンとして残します。規格改正の反映といったメモとともに新しいバージョンが作られ、以前のバージョンもそのまま保管されます。

3. 同じ文書で、変更の前後を比較します。既存のバージョンと新しいバージョンを同じ成績書に適用し、新しい項目がきちんと抽出されるか、既存の項目に影響がないかを確認します。

4. 承認したバージョンだけを運用に反映します。検証を終えたバージョンだけがデプロイされ、いつ、誰が、何を変えたかも記録として残ります。

たとえば新しいバージョンでは、引張強度の実測値471MPaが基準の415MPaと比較され、「合格」と判定されるかどうかを、すぐに確認できます。核心は、新しい機能を一つ追加することにあるのではありません。

規格や書式が変わるたびに開発し直す代わりに、担当者が基準を修正し、検証して、運用を続けていけるということです。製造記録書(BPR)、検査成績書、設備点検表のように、基準値と実測値を比較する文書であれば、同じ方式で適用できます。

金融の審査基準が変わったり、公共の行政基準が変わったりするときも、構造は同じです。

判定基準を必要なだけ変え、比較し、検証すること。それが、DEEP Opsの仕事です。

ほかの事例もあります

顧客企業のセキュリティ方針に従い、社名は伏せ、測定条件とあわせて整理しました。広域自治体の事例は、人の確認を減らす業務とは、少し性格が異なります。行政文書を、生成AIが活用できる構造データへと変換した事例で、構造要素302個をすべて検出し、テキスト類似度は98.8%、表の構造類似度は79.18%でした。

文書ごとに目標とする指標は異なりますが、共通点は一つです。文書を一度うまく読んで終わりではなく、実際の業務に合わせて継続的に運用できなければならない、ということ。

ベンチマークで確認されたこと

運用体系を語る前に、その上で動くモデルがどこまで検証されているのかも、押さえておきます。

OCRBench v2は、文書の認識と抽出だけでなく、構造パーシング、計算、理解、推論まで、7つの項目をあわせて見るベンチマークです。私たちのモデルは、特にパーシングと計算と理解の項目で差を広げました。文字を読む能力よりも、文書構造を理解し判断する能力で先んじた結果です。

ParseBenchで最も大きく先んじた項目は、視覚的な位置の根拠です。抽出した値が原文のどこにあるのかを、どれだけ正確に指し示せるかを見る項目で、金融や公共でAIの結果を受け入れるとき、真っ先に確認するのがまさにこれです。結果だけを渡すのではなく、根拠もあわせて示せるか、ということです。

自分の組織はどうか、8つの問いで確かめてみてください

すでに文書AIを運用しているなら、答えてみてください。

1. 抽出項目を一つ追加するのに、何日かかりますか

2. その変更を実行するのは、現場ですか、開発会社ですか

3. 変更前後の性能を、同じ文書で比較したことはありますか

4. 過去1年間で抽出基準を何回変え、それぞれいくらかかりましたか

5. 無介入率を測っていますか

6. 変更履歴は、社内監査の要求に耐えられますか

7. 問題が起きたとき、以前のバージョンに戻せますか

8. ほかの部署が同じ文書AIを使うには、一から構築し直しますか

答えにくいものが3つ以上あるなら、いま必要なのは、より正確なモデルではなく、運用体系です。

3つ以上あてはまったなら この8つの項目をそのままお持ちいただき、御社の基準に沿って一緒に点検します。

よくある質問

すでにMLOpsを運用していますが、別途必要ですか？ 管理対象が異なります。MLOpsはモデルと学習データを、文書AIの運用は抽出スキーマと業務基準を管理します。法令や書式が変わったとき、MLOpsの答えは再学習ですが、現場で必要なのは抽出基準の一行の変更である場合がほとんどです。置き換えの関係ではなく、層が異なる関係です。

既存のMLOpsパイプラインと併用できますか？ はい。DEEP Opsが管理するのはスキーマとプロンプトと品質基準で、モデルの学習とサービングは既存のパイプラインが担います。扱う資産が重ならないため、併用は自然です。

無介入率はどのように算定しますか？ 全体の処理件数を分母に、人の確認なしに完了した件数を分子に置きます。重要なのは、何を「確認」とみなすかを先に決めることです。信頼度が低く自動で例外に分類された件、文書間の照合で不一致が出た件、担当者がただ開いてみた件を、それぞれどう数えるか。基準なしに出した無介入率は、比較になりません。

ほかの部署へ拡張するとき、一からやり直す必要がありますか？ ある業務で検証を終えたモデル、プロンプト、抽出スキーマ、品質基準を資産として保存しておき、ほかの部署で再利用するのが、VLM Opsの目的です。文書の種類がまったく異なる場合は新しいスキーマの定義が必要ですが、最初に構築するときよりは少なくて済みます。

変更履歴は、社内監査の基準を満たしますか？ スキーマの内容が実際に変わったときだけ新しいバージョンが作られ、以前のバージョンは上書きされずに残ります。何を、いつ、なぜ変えたかがバージョンごとに残ります。組織によって監査項目は異なるため、必要なログ項目と保存期間は、構築時にあわせて確認するのがよいでしょう。

公共機関のhwp文書にも対応できますか？はい。hwpとhwpxの行政文書の構造化は、京畿道庁や広域自治体の生成AIプラットフォーム構築で検証しました。法令や告示の改正に合わせて抽出基準を変える運用方式は、公共で特によく必要とされる機能です。

読むAIから働くAIへ、そして働き続けるAIへ

文書AIは、文字を読む段階を過ぎて、業務を行う段階へと来ました。分類し、抽出し、照合し、システムへ引き渡す仕事を、AI社員が行います。

ところが、社員は採用して終わりではありません。規定が変われば知らせる必要があり、業務が増えれば説明する必要があります。AI社員も同じです。仕事を始めさせるのが導入で、基準が変わった後も正しく働き続けさせるのが、運用です。

自社の文書AI、まずは無介入率から確認してみてください実際の文書サンプルで現在の無介入率を測定し、変更への対応範囲を表に整理してお渡しします。

参考資料

• 東亜日報「認識を超えて理解するAIが台頭…韓国ディープラーニング、文書運用『ディープ・オプス』をリリース」

• ベンチャースクエア「ジェミニ・GPTを超えた…韓国ディープラーニング、グローバルOCRベンチマークで1位」

• ベンチャースクエア「文書を読むAI、いまやビッグテックも超えた…韓国ディープラーニング、グローバル文書パーシング評価で1位」