LLMによるデータ抽出:雑然としたテキストを表に変える

多くの有用な情報は、どんな表計算ソフトも読めないテキストの中にあります。メール、請求書、履歴書、サポートチケット、契約書、メモです。それらすべてをきれいな行と列に流し込むのが夢であり、これは言語モデルが本当に成果を出すタスクの一つです。自由形式の生成とは違い、抽出には正解があります。値はテキストの中にあるか、ないかのどちらかです。それが、ほとんどのAIユースケースより有用かつ検証可能なものにします。これは、それをうまく行う方法と、どこで間違うかの概念的な解説です。

テキストではなく、スキーマから始める

最もよくある誤りは、モデルに「重要な情報を抜き出して」と頼むことです。その指示に正解はないので、文書ごとに形が変わる一貫性のないフィールドが得られ、決して表に読み込めません。代わりに、目標とするスキーマを正確に定義することから始めましょう。欲しい正確なフィールド、それぞれの型(テキスト、数値、日付、カテゴリ、ブール値)、そしてそれぞれが何を意味するかです。「請求書の合計を数値として、通貨を3文字のコードとして、支払期日をYYYY-MM-DDとして」は、モデルが一貫して当てられる目標です。「お金まわりのもの」はそうではありません。スキーマは仕様です。下流のすべては、まずそれを明示的にすることに依存しています。

「不在」を一級の値にする

現実の文書は不完全です。期待するフィールドはしばしば欠けており、これが扱うべき最も重要なことです。フィールドを埋めるよう圧力を受けたモデルは、空白にしておくより、もっともらしい値をでっち上げるからです。でっち上げられた請求書番号は本物とまったく同じに見え、空のセルよりはるかに危険です。何もそれを誤りと示さないからです。だから「存在しない」がどう見えるか、すなわちnull、空文字列、特定のマーカーを明示的に定義し、値が本当にテキストにないときは常にそれを使うようモデルに指示しましょう。「フィールドが存在しなければnullを返す。推測するな」は、どんな抽出プロンプトでも最も価値ある一文です。

構造化された出力を要求し、制約する

データを、後で解析しなければならない散文ではなく、構造化された形式、すなわちたいていはスキーマに合致するJSONで求めましょう。現在のほとんどのモデルとサービングツールは、あなたが提供するスキーマに従う制約付きまたは構造化された出力をサポートしており、その仕組みはHugging Faceのドキュメントのようなリソースによく文書化されています。フィールド名を欲しいとおりに正確に与え、それぞれの型と許される値を指定し、カテゴリ型のフィールドには選択肢の閉じたリストを与え、モデルがラベルを発明するのではなくあなたの分類体系から選ぶようにします。制約がきついほど出力は一貫し、一貫性こそが眼目です。整列しなければならない行を作っているのですから。

語るだけでなく、見せる

抽出の質は、指示に2、3の作り込んだ例、すなわち代表的な入力の断片と、それから欲しい正確な構造化出力を含めると跳ね上がります。例は、散文では伝えにくい際どいケースを伝えます。部分的な日付をどう整形するか、一つを期待するところで二つの値をどう扱うか、存在するが曖昧なフィールドをどうするか、です。きれいなケースだけでなく、厄介なケースを網羅する例を選びましょう。きれいなケースは最初から問題ではなかったのですから。よく選ばれたひと握りの例は、何段落ものルールより価値があることがしばしばで、追加するコストはほぼゼロです。

抽出後に全フィールドを検証する

抽出されたデータを信仰で信じてはいけません。返ってきた瞬間に、別のモデルではなく普通のコードで検証しましょう。型が合うかを確認します。日付フィールドが日付として解析できるか、数値フィールドが数値か、カテゴリが許された値の一つか。範囲と形式を確認します。数量が負でないか、メールに「@」が含まれるか、コードが期待されるパターンに合うか。できる場合は内部の整合性を相互チェックします。明細の合計が記載された合計になるか。検証は、モデルの誤りと本当に不正な入力の両方を捕まえる場所であり、静かな不良データを、目に見えて振り分け可能な例外に変えます。検証に失敗するものは、表に読み込むのではなく、人間のために印を付けるべきです。

失敗するもののための経路を計画する

強力なパイプラインでさえ、すべてを正しく抽出はしません。そうでないふりをすることが、不良データがデータベースを毒する仕方です。抽出や検証が失敗したときに何が起きるかを、あらかじめ決めましょう。低信頼または無効なレコードを、捨てたり盲目的に受け入れたりするのではなく、人間のレビューキューへ振り分けます。この人間を介在させるフォールバックこそが、信頼できるシステムと、時とともに静かにデータを破損させるシステムの差を生みます。それはまた、NIST AI Risk Management Frameworkのようなフレームワークが推奨する、まさに帰結を意識した制御です。誤りに下流のコストがあるとき、人がループに留まるのです。レビューキューは失敗の印ではありません。簡単な9割を自信を持って自動化させてくれる安全弁です。

ラベル付きサンプルに対して測る

パイプラインを大規模に信頼する前に、測りましょう。代表的な文書のサンプルに正しい抽出を手でラベル付けし、それからパイプラインを走らせてフィールドごとに比較します。フィールドごとの正確さが、どのフィールドが信頼でき、どれが手直しを要するかを教えてくれます。そしてその答えはほぼ常に不均一で、きれいなフィールドはほぼ完璧、雑然としたものは苦戦します。これにより、情報に基づく判断ができます。信頼できるフィールドを自動化し、信頼できないものをレビューへ振り分けるのです。スキーマ、プロンプト、例、モデルのいずれかを変えるたびに測定を再実行しましょう。そのどれもが、以前は機能していたフィールドを静かに劣化させうるからです。抽出は正解が具体的な数少ないAIタスクの一つなので、測らない言い訳はありません。

モデルを責める前に、入力に注意する

抽出の問題の驚くほどの割合は、モデルとは何の関係もなく、テキストがどう届いたかにすべて関係します。文書は、きれいなデジタルテキストとして、スキャン画像として、レイアウトを台無しにするエクスポートとして、あるいは視覚的な構造が、生のテキストが失う意味を担う形式として届きます。表が一続きの行に潰されたり、スキャンが文字誤りとともにテキストに変換されたりすると、モデルはゴミから抽出しており、スキーマがどれだけ良くてもゴミを生みます。プロンプトを調整する前に、モデルが実際に何を与えられているかを見ましょう。画面上であなたに見える入力ではなく、パイプラインに見える入力です。最もてこの効く修正は、しばしば上流にあります。より良い変換、保たれた構造、あるいは答えを保持していたまさにそのレイアウトを破壊するテキストチャネルに無理やり通すのではなく、画像を画像として扱うことです。

コストとスケールについても早めに考える価値があります。抽出はしばしば大量処理の仕事だからです。すべての文書を最も有能で最も高価なモデルに通すことはめったに必要ありません。多くのフィールドは簡単で、小さく安いモデルが確実に処理し、より難しいフィールドや文書だけがより強いものへ引き上げられます。できるものはバッチ化し、正確さを測るのと同じように文書あたりのコストを測りましょう。正確だが実際の量で採算が合わないパイプラインは、実は配備可能ではありません。そしてそれを発見すべき時は、百万件のレコードに向けた後ではなく、設計中なのです。

まとめ

雑然としたテキストを表に変えることは、言語モデルでできる最も信頼でき、検証でき、静かに価値ある仕事の一つです。魔法ではなくエンジニアリングとして扱うなら。まずスキーマを定義し、モデルが決して値を発明しないよう不在を明示的にし、制約付きの構造化出力を要求し、例で教え、全フィールドをコードで検証し、失敗を人間へ振り分け、ラベル付きデータに対して測りましょう。検証とレビューキューを飛ばせば、もっともらしく誤った行を生成する高速な機械が手に入ります。それらを組み込めば、どんな表計算ソフトも決して読めなかったテキストから、きれいなデータが手に入るのです。