メインコンテンツへスキップ

概要

プロンプトベースの抽出では、自然言語による指示を使って、LLM を用いて文書から構造化データを抽出できます。従来の機械学習モデルを学習させる代わりに、抽出したいデータとその出力形式を記述すると、LLM がその指示に基づいて抽出を実行します。 データの取り扱いやコストを含む、Vantage における LLM の利用方法については、ABBYY Vantage での LLMを参照してください。 達成できること:
  • プロンプトベースの抽出アクティビティを作成する。
  • LLM 接続を設定する。
  • 効果的な抽出プロンプトを作成する。
  • 出力形式と構造を定義する。
  • 厳格度とバリデーションルールを適用する。
  • 抽出結果をテストして改善する。
所要時間: 20~30 分 ユースケース:
  • 請求書からのベンダー情報の抽出
  • ヘッダーレベルの文書データ抽出
  • 半構造化文書の処理
  • レイアウトが可変の文書

前提条件

始める前に、次の項目を確認してください。
  1. ABBYY Vantage Advanced Designer にアクセスできること
  2. LLM 接続が設定されていること。詳しくは LLM 接続の Configure を参照してください。
  3. サンプルドキュメントがロードされた Document Skill
  4. JSON 構造に関する基本的な理解
  5. 抽出したいデータのフィールド定義
このガイドでは、ヘッダーレベルの抽出に重点を置いています。テーブル抽出のサポート内容は異なる場合があります。

プロンプトベースの抽出について

プロンプトベースの抽出とは?

プロンプトベースの抽出では、LLM が自然言語の指示に基づいて文書を理解し、データを抽出します。設定する内容は次のとおりです。
  • Role: LLM にどのような役割を担わせるか (例: 「データ抽出モデル」) 。
  • Instructions: データをどのように抽出し、整形するか。
  • Output Structure: 結果の正確な JSON 形式。
  • Rules: あいまいなデータや欠落データの扱いに関するガイドライン。
プロンプトベースの抽出の長所と制約、および従来の抽出を優先すべき場面については、When to use LLMs を参照してください。

Step 1: プロンプトベースのアクティビティを追加する

Document Skill に新しいプロンプトベースの抽出アクティビティを追加します。
  1. ABBYY Vantage Advanced Designer で Document Skill を開きます。
  2. 左側のパネルで、EXTRACT FROM TEXT (NLP) を探します。
  3. Prompt-based を見つけてクリックします。
プロンプトベースのアクティビティを選択
  1. ワークフローキャンバスにアクティビティが表示されます。
  2. 入力アクティビティと出力アクティビティの間に接続します。
プロンプトベースのアクティビティは Activities パネルの「EXTRACT FROM TEXT (NLP)」にあり、固有表現 (NER) や Deep Learning など、ほかの抽出方法と並んでいます。

ステップ 2: LLM 接続を設定する

アクティビティで使用する LLM 接続を選択します。
  1. ワークフロー内でプロンプトベースのアクティビティを選択します。
  2. 右側の Activity Properties パネルで、LLM 接続 を探します。
  3. ドロップダウンメニューをクリックします。
LLM 接続の設定
  1. 一覧から設定済みの LLM 接続を選択します。
    • 例: Nick-ChatGPT, Microsoft Foundry, Production GPT-4
  2. 接続が選択されていることを確認します。
一覧に接続が表示されない場合は、まず Configuration → Connections から LLM 接続を設定する必要があります。
Skill を公開すると、ここで選択した接続が Vantage Web Portal でその Skill の デフォルト になります。Skill Catalog → [your skill] → Parameters では、その接続があらかじめ設定された状態で表示されます。テナント管理者は、Skill を再公開しなくても別の接続に切り替えられます (たとえば、環境ごとに本番用の Skill が別の LLM エンドポイントを参照するようにする場合) 。詳しくは、Document skill パラメーター を参照してください。

Step 3: Output field を定義する

プロンプトを記述する前に、抽出したいfieldを設定します。
  1. Activity Properties パネルで、Output セクションを探します。
  2. field グループとfieldの階層リストが表示されます。
  3. この例では、ベンダー情報を抽出します。
    • ベンダー
      • 名前
      • 住所
      • TaxID
      • アカウント番号
      • Sort Code
      • IBAN (国際銀行口座番号)
      • BIC_SWIFT
    • ビジネス ユニット
      • 名前
      • 住所
      • 請求日
      • 請求書番号
    • Totals
      • Net Amount
fieldの出力構造
  1. Activity Editor ボタンをクリックして、プロンプトの設定を開始します。
プロンプトを記述する前に、すべてのfieldを定義してください。field名はプロンプトの構造内で参照されます。

ステップ 4: ロール定義を記述する

ドキュメントの処理時に LLM がどのような役割を担うべきかを定義します。
  1. Activity Editor に Prompt Text インターフェイスが表示されます
  2. ROLE セクションから始めます:
プロンプト テキストエディター
役割を指定する際の重要なポイント:
  • 具体的にする: “data extraction model” とすることで、LLM にその目的を明確に伝えられます。
  • 範囲を定義する: “vendor-related fields” とすることで、何を抽出するかを限定できます。
  • 期待する動作を示す: “value text verbatim” とすることで、再整形を防げます。
  • データ欠落時の扱いを決める: “Omit any field that is not clearly present”。
ベストプラクティス:
  • 役割は明確かつ簡潔にします。
  • 命令形の文を使います (“Extract”、“Do not infer”) 。
  • してはいけないことも明示します。
  • 境界ケースの扱い方を定義します。

Step 5: 出力形式を定義する

抽出結果のJSON構造を厳密に指定します。
  1. ROLE セクションの下に、OUTPUT FORMAT 見出しを追加します。
  2. JSON構造を定義します。
JSON出力形式
構造コンポーネント:
  • FieldName: field 定義と完全に一致している必要があります (例: Vendor.Name) 。
  • Text: 文字列として抽出された値。
  • Line: ドキュメント内で値が現れる 0 ベースの行 index。
重要な注意事項:
  • Output の設定で使用している field 名を正確に指定してください。
  • 一部が空の場合でも、すべての field を含めてください。
  • 構造は有効な JSON である必要があります。
  • 行番号は Verification や Troubleshooting に役立ちます。

Step 6: field ごとの抽出ルールを追加する

各 field の抽出について、詳細な指示を記述します。 OUTPUT FORMAT の下に、各 field タイプに対する具体的なルールを追加します。
Extraction Rules
ルールの構成:
  • 認識パターン: 各fieldについて、代替ラベルを列挙します。
  • 形式仕様: 抽出対象の正確な形式を記述します。
  • 位置のヒント: データが通常どこに記載されているかを示します。
  • 除外: 抽出しないものを示します。
ベストプラクティス:
  • 分かりやすくするため、ルールには番号を付けます。
  • ラベルのバリエーションを複数記載します。
  • データの帰属先 (ベンダー側か顧客側か) を明記します。
  • 括弧内に形式の例を含めます。
  • 関連するfieldは明確に示します (例: “IBAN は無視する — 専用のfieldがあります”) 。

ステップ 7: 厳格度ルールを適用する

データ品質と一貫性を確保するため、バリデーションルールを追加します。 プロンプトの末尾に、STRICTNESS セクションを追加します:
厳格度ルール
追加の厳格度ルール (任意) :
厳格性が重要な理由:
  • ハルシネーションを防ぐ: LLMはもっともらしく見えても、誤ったデータを生成することがあります。
  • 一貫性を確保する: 明確なルールによって、実行ごとの差異を抑えられます。
  • 欠損データに対応する: fieldが見つからない場合の扱いを定義します。
  • データの整合性を保つ: 原文どおりに抽出することで、元の書式を維持できます。
厳格性の基本原則:
  • 文書内にないデータは決して生成しない。
  • 不確かな抽出結果は推測せず、省略する。
  • fieldが1つも見つからない場合は、空の構造を返す。
  • field名は完全一致させる。
  • 元のテキストの書式を保持する。

Step 8: 文書形式を選択

LLM に送信する文書表現を選択します。
  1. Activity Editor で、Prompt ドロップダウンを見つけます。
  2. 文書を LLM にどのような形式で渡すかのオプションが表示されます。
文書形式のオプション
利用可能な形式:
  • PDF: 元の PDF ファイル
    • 使用対象: レイアウトが重要な文書
    • 注意点: ファイルサイズが大きく、一部の LLM では PDF のサポートが限定的です
    非推奨: PDF 文書形式は非推奨であり、既存の OpenAI 接続でのみ利用できます。この形式は、どのプロバイダーの新規接続でもサポートされなくなりました。代わりに Annotated Text を使用してください。
  • Plain Text: 書式なしのテキスト抽出
    • 使用対象: シンプルなテキストのみの文書
    • 注意点: すべての書式設定とレイアウト情報が失われます
  • Annotated Text ⭐ (推奨)
    • 使用対象: ほとんどの文書タイプ
    • 注意点: テキストベースでありながら構造を保持します
    • 利点: 構造とパフォーマンスのバランスが最適です
  • Formatted Text: 基本的な書式を保持したテキスト
    • 使用対象: 一部の書式が重要な文書
    • 注意点: Plain Text と Annotated Text の中間に位置します
  1. 最良の結果を得るには Annotated Text を選択します
テストの結果、抽出タスクでは Annotated Text が最も一貫性が高く、信頼性の高い結果をもたらすことが確認されています。文書構造を保持しながら、LLM で効率的に処理できます。

ステップ 9: 抽出をテストする

結果を確認するには、サンプル文書に対してアクティビティを実行します。

アクティビティを実行する

  1. Activity Editorを閉じます。
  2. All Documents タブに移動します。
  3. テスト用のドキュメントを選択します。
  4. Test Activity または Run ボタンをクリックします。
アクティビティのテスト
  1. LLMによるドキュメントの処理が完了するまで待ちます
    • 処理時間: 通常、ドキュメントの複雑さに応じて5~30秒です。
    • APIレスポンスを待機している間、ロード インジケーターが表示されます。

結果を確認する

処理が完了したら:
  1. インターフェイスがPredictive viewに切り替わります。
  2. 抽出されたフィールドが表示されているOutputパネルを確認します。
  3. 各fieldをクリックして、次の内容を確認します。
    • 抽出された値
    • 確信度 (提供されている場合)
    • 文書画像上で強調表示された領域
結果の確認
確認するポイント:
  • ✅ 想定されるすべてのfieldに値が入っている
  • ✅ 値が文書と完全に一致している
  • ✅ 幻覚や推測によるデータが含まれていない
  • ✅ 複数行のfieldが適切に処理されている
  • ✅ 欠落しているfieldは省略されている (誤ったデータで埋められていない)

一般的な結果のパターン

抽出が成功した場合:
部分抽出 (一部のfieldが欠落している場合) :
field が見つかりません:

Step 10: プロンプトを改善する

テスト結果に基づいて、プロンプトを調整します。

よくある問題と解決策

問題: LLMが誤ったfieldを抽出する
  • 解決策: より具体的な位置のヒントを追加します。
  • : “ベンダー側のみ。顧客/購入者の住所は除外”
問題: 書式が変わってしまう
  • 解決策: 原文どおりに抽出するよう強調します。
  • : “印字された数値形式をそのまま正確に抽出すること (例: ‘12-34-56’) ”
問題: LLMがデータを捏造する
  • 解決策: 厳格度ルールを強化します。
  • : “値を生成したり推測したりしないこと。存在しない場合は省略すること。”
問題: 複数行のfieldが連結される
  • 解決策: エスケープシーケンスを指定します。
  • : “複数行の値では、改行に \n を使用する”
問題: 出力内のfield名が正しくない
  • 解決策: field名が完全に一致していることを確認します。
  • : AccountNumber ではなく Vendor.Account Number を使用

反復的な改善プロセス

  1. 複数の文書でテストする: 単一の例だけに最適化しないでください。
  2. 文書のパターンを記録する: どのルールが有効で、どれに改善が必要かを記録します。
  3. 具体例を追加する: 括弧内に書式の例を含めます。
  4. 厳格度を調整する: 過剰抽出または抽出不足のパターンに基づいて調整します。
  5. エッジケースをテストする: フィールドが不足している文書や、通常と異なるレイアウトの文書を試します。

改善例

変更前:
変更後:

抽出プロセスを理解する

プロンプトベースの抽出の仕組み

  1. ドキュメント変換: ドキュメントは、選択した形式に変換されます (推奨形式: Annotated Text) 。
  2. プロンプトの組み立て: ロール、出力形式、field ルール、厳格度ルールが組み合わされます。
  3. API 呼び出し: プロンプトとドキュメントが、接続を介して LLM に送信されます。
  4. LLM による処理: LLM がドキュメントを読み取り、指示に従ってデータを抽出します。
  5. JSON レスポンス: LLM は、指定された JSON 形式で構造化データを返します。
  6. フィールドマッピング: Vantage が JSON レスポンスを、定義した出力フィールドにマッピングします。
  7. 検証: 行番号と信頼度スコア (提供されている場合) は、精度の確認に役立ちます。

トークン使用量とコスト

コストに影響する要因:
  • 文書の長さ: 文書が長いほど、使用するトークン数も増えます。
  • プロンプトの複雑さ: プロンプトが詳細になるほど、トークン数が増えます。
  • 形式の選択: Annotated Text は通常、PDF より効率的です。
  • フィールド数: フィールドが多いほど、プロンプトも長くなります。
最適化のヒント:
  • プロンプトには、簡潔かつ明確な表現を使います。
  • 指示を重複させないでください。
  • 不要な例は削除してください。
  • 関連するデータは field グループ化を検討してください。

ベストプラクティス

プロンプトの書き方

推奨事項:
  • ✅ 明確な命令形 (「Extract」「Recognize」「Omit」) を使います。
  • ✅ 各fieldについて、複数のラベルのバリエーションを示します。
  • ✅ 括弧内に形式の例を含めます。
  • ✅ 抽出しないもの (除外対象) を明記します。
  • ✅ 参照しやすいようにルールに番号を付けます。
  • ✅ 全体を通して用語を統一します。
避けること:
  • ❌ 曖昧な指示 (「名前を取得する」など) は使わないでください。
  • ❌ LLMが業務領域固有の慣習を理解していると決めつけないでください。
  • ❌ 長すぎたり複雑すぎたりする文は書かないでください。
  • ❌ セクションごとに内容が矛盾しないようにしてください。
  • ❌ 厳格度ルールを省略しないでください。

field の定義

効果的な field の指示:
  • 認識パターン (代替ラベル) をまず指定します。
  • 保持すべき正確な形式を指定します。
  • 位置のヒント (一般的な配置場所) を示します。
  • データの帰属 (ベンダーか顧客か) を定義します。
  • 複数行の値の扱いを含めます。
  • 混同を避けるため、関連する fields を参照します。
例:

テスト戦略

  1. シンプルな文書から始める: まずは基本的な抽出をテストします。
  2. バリエーションを広げる: 異なるレイアウトや形式を試します。
  3. エッジケースをテストする: フィールドの欠落、通常と異なる位置、複数一致などを確認します。
  4. 失敗例を記録する: 抽出に失敗したケースの例を残します。
  5. 体系的に繰り返す: 一度に変更するのは1つだけにします。

パフォーマンスの最適化

速度を重視する場合:
  • プロンプトは簡潔にします。
  • Annotated Text形式を使用します。
  • アクティビティごとのフィールド数は最小限に抑えます。
  • 複雑な文書は分割することも検討します。
精度を重視する場合:
  • フィールドルールはできるだけ詳細に設定します。
  • 形式の例を含めます。
  • 明確な厳格度ルールを追加します。
  • 多様な文書サンプルでテストします。
コストを重視する場合:
  • プロンプトの長さを最適化します。
  • 効率的な文書形式を使用します。
  • 必要に応じて結果をキャッシュします。
  • LLM providerのダッシュボードでトークン使用量を監視します。

トラブルシューティング

抽出に関する問題

問題: データが存在するのに field が空です。 解決策:
  • field name のスペルが完全に一致しているか確認します。
  • データが選択した文書形式に含まれていることを確認します。
  • 認識パターンにラベルのバリエーションをさらに追加します。
  • 一時的に 厳格度 を下げて、LLM が見つけられるか確認します。
  • 文書品質が OCR/テキスト抽出に影響していないか確認します。
問題: LLM がベンダーのデータではなく顧客のデータを抽出します。 解決策:
  • ベンダー側の指定内容をより明確にします。
  • 顧客/購入者データに対する明示的な除外条件を追加します。
  • 位置のヒント (例: 「文書の上部」、「発行者欄」) を指定します。
  • 正しい抽出例と誤った抽出例の両方を含めます。
問題: 複数行の値が連結されたり、形式が崩れたりします。 解決策:
  • エスケープシーケンスの形式 (\n) を明示的に指定します。
  • 正しい複数行出力の例を示します。
  • 文書形式で改行が保持されることを確認します。
  • 「元の改行を \n を使って保持する」という指示を追加します。
問題: LLM がデータを再整形または正規化します。 解決策:
  • 「verbatim」と「印字どおり正確に」を強調します。
  • 厳格度 rule として「正規化や推測を行わない」を追加します。
  • 書式が保持されることを示す具体例を示します。
  • 否定例を含めます: 「‘12-34-56’ ではなく、‘12 34 56’ のままにする」。

パフォーマンスの問題

問題: 抽出速度が遅すぎます。 解決策:
  • PDF を使用している場合は、Annotated Text 形式に切り替えます。
  • 重要な指示を損なわない範囲で、プロンプトを簡潔にします。
  • 画像が非常に大きい場合は、ドキュメントの解像度を下げます。
  • LLMプロバイダーのステータスとレート制限を確認します。
  • 単純なドキュメントでは、より高速なモデルの使用を検討します。
問題: 実行するたびに結果が一致しません。 解決策:
  • 厳格度ルールを強化します。
  • 指示をより具体的で曖昧さのないものにします。
  • 書式の例をさらに追加します。
  • 解釈の余地を生む可能性があるプロンプトの複雑さを下げます。
  • より高い温度設定でテストします (接続で利用可能な場合) 。
問題: API コストが高すぎます。 解決策:
  • プロンプトの長さを最適化します。
  • PDF の代わりに Annotated Text を使用します。
  • オフピーク時にドキュメントをバッチ処理します。
  • 単純なドキュメントでは、より小規模で低コストのモデルの使用を検討します。
  • LLMプロバイダーのダッシュボードで予算アラートを設定し、監視します。

応用テクニック

条件付き抽出

条件が満たされた場合にのみ特定のfieldを抽出するよう、LLMに指示できます。

多言語対応

プロンプトベースの抽出は、多言語のドキュメントに対しても効果的です。

バリデーションルール

プロンプトにバリデーションロジックを追加します。

field間のリレーション

field同士のリレーションを指定します。

制限事項と留意点

現在の機能

サポート対象:
  • ✅ ヘッダーレベルのフィールド抽出
  • ✅ 単一行および複数行の値
  • ✅ 1つの文書内の複数のフィールド
  • ✅ 条件付きの抽出ロジック
  • ✅ 多言語の文書
  • ✅ さまざまな文書レイアウト
制限あり、または未対応:
  • ⚠️ テーブル抽出 (実装によって異なります)
  • ⚠️ 入れ子の複雑な構造
  • ⚠️ 非常に大きな文書 (トークン数の制限)
  • ⚠️ リアルタイム処理 (APIレイテンシ)
  • ⚠️ 結果の決定性保証

プロンプトベースの抽出を使用する場合

プロンプトベースの抽出が適しているケースと、従来の抽出を選ぶべきケースについては、LLM を使用する場合を参照してください。

Document Skills との連携

抽出されたデータの使用

抽出が完了すると、フィールドデータを Document Skill 全体で利用できます。
  1. Validation Activities: 抽出された値に業務ルールを適用します。
  2. Script Activities: 抽出されたデータを処理または変換します。
  3. Export Activities: データを外部システムに送信します。
  4. Review Interface: 抽出されたフィールドを手動で検証します。

他のアクティビティとの併用

プロンプトベースの抽出は、他のアクティビティと併用できます。

Field Mapping

抽出されたJSONのfieldは、自動的に定義したOutput fieldにマッピングされます。
  • "FieldName": "Vendor.Name" → Output field Vendor.Name にマッピングされます。
  • fieldの階層は出力構造内で保持されます。
  • 行番号は、Verificationやトラブルシューティングに役立ちます。

まとめ

以下の作業が完了しました。
  • ✅ プロンプトベースの抽出アクティビティを作成しました。
  • ✅ LLM 接続を設定しました。
  • ✅ 役割、形式、ルールを含む包括的な抽出プロンプトを作成しました。
  • ✅ 最適な文書形式 (Annotated Text) を選択しました。
  • ✅ データ品質を確保するために厳格度ルールを適用しました。
  • ✅ 抽出をテストし、結果を確認しました。
  • ✅ プロンプトエンジニアリングのベストプラクティスを学びました。
主なポイント:
  • プロンプトベースの抽出では、自然言語の指示を使用します。
  • Annotated Text 形式は最も良い結果をもたらします。
  • 明確で具体的なプロンプトほど、一貫した抽出結果が得られます。
  • 厳格度ルールはハルシネーションを防ぎ、データ品質を維持します。
  • 繰り返しテストと改善を行うことで精度が向上します。
これで、プロンプトベースの抽出アクティビティを文書処理に使用する準備が整いました。

次のステップ

  1. さまざまな文書でテストする: 異なるレイアウトやバリエーションで検証します。
  2. プロンプトを改善する: 結果に基づいて継続的に改善します。
  3. コストを監視する: LLM プロバイダーのダッシュボードでトークンの使用量を追跡します。
  4. パフォーマンスを最適化する: 速度と精度を高めるためにプロンプトを調整します。
  5. テーブル抽出を試す: 明細の抽出を試します (サポートされている場合) 。
  6. ワークフローと統合する: 他のアクティビティと組み合わせて処理全体を構成します。

追加リソース

  • ABBYY Vantage Advanced Designer ドキュメント: https://docs.abbyy.com
  • LLM 接続設定ガイド: LLM 接続をConfigureする.
  • プロンプトエンジニアリングのベストプラクティス: ご利用の LLM プロバイダーのドキュメントを参照してください。
  • サポート: 技術的なサポートが必要な場合は、ABBYY サポートにお問い合わせください。

よくある質問

Q: プロンプトベースの抽出と従来型の抽出の違いは何ですか? A: プロンプトベースでは、学習データを使わず、LLM に自然言語で指示を与えます。従来の方法では学習用のサンプルが必要ですが、大規模処理ではより高速でコスト効率に優れています。 Q: プロンプトベースの activities でテーブルを抽出できますか? A: ヘッダーレベルの抽出は十分にサポートされています。テーブル抽出の対応状況はケースによって異なり、特定のプロンプト構造が必要になる場合があります。 Q: PDF ではなく Annotated Text を使うのはなぜですか? A: Annotated Text は、構造保持と処理効率のバランスに最も優れています。テストでも、最も信頼性が高いことが確認されています。 Q: API コストを削減するにはどうすればよいですか? A: プロンプトの長さを最適化し、Annotated Text 形式を使用し、効率よく処理し、LLM provider のダッシュボードでトークン使用量を監視してください。 Q: LLM 接続が失敗した場合はどうすればよいですか? A: Configuration → Connections で接続のステータスを確認してください。接続を Test し、認証情報を確認し、API のクォータを超過していないことを確認してください。 Q: 1 つの Skill で複数の LLM 接続を使用できますか? A: はい。異なる activities で異なる接続を使用できます。これにより、抽出タスクごとに異なるモデルを使い分けられます。 Q: 複数の言語の文書はどのように扱えばよいですか? A: field ルールに多言語のラベルバリエーションを追加してください。LLM は一般に多言語コンテンツを適切に処理できます。 Q: 文書の最大サイズはどれくらいですか? A: これは LLM provider のトークン上限によって異なります。非常に長い文書は、分割するか、セクションごとに処理する必要がある場合があります。