DEEP Opsとは何か：文書AIの変更・検証・運用を管理するプラットフォームの完全ガイド

DEEP Opsとは、業務の変化に合わせて文書AIの抽出基準を変更し、変更前後の性能を検証して、バージョンと運用の履歴を管理できるように設計された、Korea Deep Learningの文書AI運用プラットフォームです。

文書AIは、構築よりも運用の段階で難しくなる

文書の自動化は、最初に構築したときに最もよく機能します。

それは、当時使われていた文書の書式、抽出項目、業務の基準に合わせてシステムを作ったからです。しかし、実際の業務環境はそのまま維持されるわけではありません。

保険の審査基準が変わり、既存の診断書から新しい項目を確認しなければならなくなることがあります。金融機関の申込書の書式が改定されたり、公共機関の法令や告示が変更されたりすれば、抽出の基準も変わることがあります。

従来の方式では、こうした小さな変更であっても、開発会社に修正を依頼し、必要なデータを準備し、モデルやシステムを修正してから、もう一度検証して配備する、という過程が繰り返されることがあります。変更そのものよりも、変更を適用する過程のほうが長くなってしまうのです。

DEEP Opsは、文書AIを一度構築して終わりとするのではなく、実際の業務の変化に合わせて継続的に管理できる運用の対象として扱うことに焦点を当てています。

DEEP Opsの正確な定義：何を運用するのか

文書AIの変更基準と検証の過程を管理します

DEEP Opsの中核は、単にAIモデルを配備することにあるわけではありません。

実際の文書業務では、どの項目を抽出するか、どの条件を適用するか、変更した基準が以前より良い結果を出すか、運用に反映した変更を元に戻せるかが重要です。

DEEP Opsでは、文書から新たに抽出する項目や条件を自然言語で定義し、変更された結果を実際の文書で確認できます。

現在運用中の基準と新しく作った基準を同じ文書に適用して、結果を比較することもできます。項目ごとの抽出結果や精度、処理の遅延などをあわせて確認し、変更が実際の改善につながったかどうかを判断する方式です。

変更内容はバージョン単位で管理されます。何がいつ変わったかを記録し、以前のバージョンとの違いを確認でき、必要であれば既存のバージョンに戻すこともできるようにします。

つまりDEEP Opsは、文書AIの変更、評価、承認、運用、履歴の管理を、1つの運用の流れとして扱うプラットフォームといえます。

DEEP Opsを構成する4つの機能

第一に、自然言語による抽出基準の変更

業務の担当者は、文書の中で新たに確認すべき項目や条件を、自然言語で定義することができます。

たとえば、これまで請求金額と契約番号だけを抽出していた業務で、新しい業務の基準により特定の日付や審査項目も確認する必要が生じた場合、新しい抽出基準を定義して結果を確認できます。

すべての変更にモデルの再学習が必要なわけではありません。モデルのパラメータを変えるのではなく、抽出基準とスキーマを調整することで対応できる領域では、別途の学習プロジェクトを行うことなく変更を適用できます。

第二に、同じ文書による性能の比較

変更したからといって、すぐに運用に反映するのは危険です。

DEEP Opsでは、既存のバージョンと新しいバージョンを同じ評価文書に適用し、結果を比較できるようにしています。

全体の結果だけを見るのではなく、文書ごと、項目ごとの抽出結果を確認でき、精度、処理の結果、遅延時間などの差を比較することで、新しい基準が実際に良くなったかどうかを判断できます。

これにより、変更の前後の効果を、人の感覚ではなく、同じ条件の評価結果によって確認できます。

第三に、バージョンと変更履歴の管理

文書AIの運用では、現在何が適用されているかを知ることと同じくらい、過去に何が変わったかを知ることが重要です。

DEEP Opsは、抽出項目や条件が変更されると、それをバージョン単位で記録します。

新しいバージョンが既存のバージョンと何が違うのかを比較でき、運用後に問題が確認されれば、以前の状態に戻すことができます。

業務の担当者が替わっても、どの基準がいつ、どのような理由で変更されたかが残せる点も、運用の面で重要です。

第四に、文書業務のワークフローの構成

文書業務は、情報を抽出したら終わりというわけではありません。

文書を受け付けて種類を分類し、必要な情報を抽出し、異なる値を照合したり計算したりして、条件に応じて次の業務を異なる方法で処理しなければならない場合があります。

DEEP Opsでは、文書の受け付けとOCRから、文書の分類、情報の抽出、値の照合と計算、条件別の処理の分岐、結果の判断と生成に至るまでの必要な過程を連携させ、業務ごとの流れを構成できます。

そのため、個々のモデルを管理するだけでなく、文書AIが実際の業務の中でどのように動くかも合わせて管理する方向に広がっています。

DEEP Opsの実際の適用方法

業務の基準が変わったら、まず抽出基準を変更します

これまで文書からA、B、Cの3つの項目を確認していたところ、新しい規定によってD項目を追加しなければならなくなったと仮定してみましょう。

まず、新しい抽出項目と条件を定義します。

この際、どのフィールドをどの基準で抽出するかを明確に記録しておく必要があります。単に項目名を追加するだけにとどまらず、値の形式や例外の条件まで一緒に管理しておくと、後から変更の履歴を理解しやすくなります。

既存のバージョンと同じ文書で比較します

変更した基準は、既存のバージョンと同じ評価文書で比較します。

新しい項目が正しく抽出されるか、以前からよく抽出できていた項目の性能が落ちていないかを確認します。

変更した1つの項目だけが良くなり、他の項目で誤りが増えているのであれば、運用に直ちに反映するのは困難です。

同じ条件で以前のバージョンと新しいバージョンを比較してこそ、変更の効果を正確に判断できます。

検証されたバージョンだけを運用に反映します

評価結果が基準を満たしたら、新しいバージョンを運用に反映します。

金融や公共のように、変更に対する内部統制が重要な環境では、検討する担当者と承認する担当者を分け、どのバージョンがいつ運用に適用されたかを記録する方式で管理できます。

問題が発生した場合には、以前のバージョンに戻せるようにしておく必要があります。

このようにすることで、文書AIの変更が一度限りの修正ではなく、管理可能な運用の過程になります。

業務の流れも合わせて管理します

文書から値をうまく抽出するだけでは、業務の自動化は完結しません。

たとえば申込書を処理する場合、文書の種類を確認し、必要な項目を抽出した後、他の文書と値を比較したり、条件に応じて承認や検収の段階へ回したりする必要があるかもしれません。

DEEP Opsでは、こうした後続の過程を業務の流れとして構成し、文書AIの結果が実際の業務の処理まで確実につながるように管理できます。

DEEP OpsとMLOps

MLOpsは、機械学習モデル全般の学習、配備、バージョン管理、性能の監視を体系化する方法論です。

管理の対象の中心には、学習データ、モデル、実験の結果、モデルのバージョンなどがあります。

DEEP Opsは、文書AIの実際の運用の過程により具体的に焦点を当てています。

文書業務では、モデルの重みだけでなく、抽出項目、スキーマ、自然言語による指示、評価文書、業務の基準、ワークフローが運用の結果に直接影響します。

したがって、DEEP Opsは一般的なMLOpsを置き換えるというよりも、文書AIが実際の業務の変化に対応するために必要な運用の領域を扱うプラットフォームに近いものです。

DEEP OpsとVLMOps

VLMOpsは、視覚言語モデルを実際の業務環境で継続的に運用するための概念と運用の体系を指します。

抽出基準、スキーマ、評価基準、バージョンと変更履歴などを管理し、文書AIが変化する業務に合わせて継続的に機能するようにすることが中核です。

DEEP Opsは、こうした文書AI運用の概念を実際の業務で遂行できるように実装した、Korea Deep Learningの運用プラットフォームです。

簡単に区別すると、VLMOpsは運用の方式と体系を説明する概念であり、DEEP Opsはその運用を実際に遂行するための製品だといえます。

DEEP AgentとDEEP Ops

DEEP AgentとDEEP Opsは、役割が異なります。

DEEP Agentは、実際の文書を読み、分類し、必要な情報を抽出・検証して、業務を処理する役割に焦点を当てています。

DEEP Opsは、構築された文書AIを業務の変化に合わせて変更し、新しい基準の性能を検証し、バージョンと変更履歴を管理する運用の領域を担当します。

DEEP Agentが文書業務を遂行するAI Workerだとすれば、DEEP Opsは、そのWorkerが変化する業務の中でも引き続き適切に働けるように管理する運用の環境として理解できます。

国内の金融・公共環境におけるDEEP Ops

金融と公共の分野では、文書の書式や業務の基準が固定されているわけではありません。

法令や告示が改正されたり、社内の審査基準が変わったり、新しい申込書や証明書が追加されたりすることがあります。

業務の変更は予定された時点で発生することもあれば、実際の運用中に予想していなかった文書が入ってくることで生じることもあります。

そのとき、すべての変更を改めて開発プロジェクトとして処理すると、業務が変わる速度とAIシステムが対応する速度との間に差が生じかねません。

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