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

概要

プロンプトベースの抽出では、自然言語の指示を使い、LLM によってドキュメントから構造化データを抽出できます。従来の機械学習モデルをトレーニングする代わりに、抽出したいデータとその書式を自然言語で指定すると、LLM がその指示に基づいて抽出を行います。 このセクションで行うこと:
  • プロンプトベース抽出アクティビティを作成する
  • LLM 接続を構成する
  • 効果的な抽出プロンプトを作成する
  • 出力形式と構造を定義する
  • 厳格さとバリデーションルールを適用する
  • 抽出結果をテストし、改善する
所要時間: 20~30 分 ユースケース:
  • 請求書のベンダー情報の抽出
  • ヘッダーレベルのドキュメントデータの取得
  • 半構造化ドキュメントの処理
  • レイアウトが可変なドキュメントの処理

前提条件

開始する前に、以下が用意されていることを確認してください。
  1. ABBYY Vantage Advanced Designer へのアクセス権
  2. 構成済みの LLM 接続LLM 接続の構成方法 を参照)
  3. サンプルドキュメントが読み込まれている Document Skill
  4. JSON 構造に関する 基本的な理解
  5. 抽出したいデータの field の定義
注記: このガイドではヘッダーレベルの抽出に焦点を当てています。テーブル抽出機能は異なる場合があります。

プロンプトベースの抽出について理解する

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

プロンプトベース抽出は、自然言語による指示に基づいて LLM を使用し、Document からデータを理解して抽出する手法です。ここでは次の内容を定義します:
  • Role: LLM にどのような役割を担わせるか(例: 「data extraction model」)
  • Instructions: データをどのように抽出し、どのような形式に整形するか
  • Output Structure: 結果の厳密な JSON フォーマット
  • Rules: あいまいなデータや欠損データをどのように扱うかについてのガイドライン

メリット

  • 学習データ不要: プロンプトエンジニアリングだけで利用可能
  • 柔軟: field の追加や変更が容易
  • バリエーションに対応: LLM はさまざまな文書形式を理解できる
  • セットアップが速い: 従来型の機械学習モデルの学習よりも短時間でセットアップ可能
  • 自然言語: 平易な英語で指示を書ける

制限事項

  • コスト: 各抽出処理で LLM API 呼び出しが発生します
  • 速度: 単純な文書に対する従来の抽出よりも遅くなります
  • 一貫性: 実行のたびに結果がわずかに異なる場合があります
  • コンテキスト制限: 非常に長い文書では特別な対応が必要になる場合があります

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

Document Skill に新しいプロンプトベース抽出アクティビティを作成します。
  1. ABBYY Vantage Advanced Designer で対象の Document Skill を開きます
  2. 左側のパネルで EXTRACT FROM TEXT (NLP) を見つけます
  3. Prompt-based をクリックします
Selecting Prompt-Based Activity
  1. ワークフローキャンバス上にアクティビティが表示されます
  2. 入力アクティビティと出力アクティビティの間に接続します
注: プロンプトベースのアクティビティは、Activities パネル内の「EXTRACT FROM TEXT (NLP)」配下にあり、Named Entities (NER) や Deep Learning などの他の抽出方法と並んで表示されます。

ステップ 2: LLM 接続を構成する

アクティビティで使用する LLM 接続を選択します。
  1. ワークフロー内のプロンプトベースのアクティビティを選択します
  2. 右側にある Activity Properties パネルで LLM Connection を探します
  3. ドロップダウンメニューをクリックします
LLM 接続の構成
  1. リストから構成済みの LLM 接続を選択します
    • 例: Nick-ChatGPT, Microsoft Foundry, Production GPT-4
  2. 接続が選択されていることを確認します
注記: 接続が一つも表示されない場合は、先に Configuration → Connections から LLM 接続を構成する必要があります。

ステップ 3: 出力fieldを定義する

プロンプトを作成する前に、抽出したいfieldをあらかじめ設定します。
  1. Activity Properties パネルで、Output セクションを見つけます
  2. fieldグループとfieldの階層リストが表示されます
  3. この例では、ベンダー情報を抽出します:
    • ベンダー
      • Name
      • Address
      • TaxID
      • アカウント番号
      • Sort Code
      • IBAN(国際銀行口座番号)
      • BIC_SWIFT
    • Business Unit
      • Name
      • Address
      • 請求日
      • 請求書番号
    • Totals
      • Net Amount
Field Output Structure
  1. Activity Editor ボタンをクリックして、プロンプトの設定を開始します
Note: プロンプトを作成する前に、すべてのfieldを定義してください。field名はプロンプト構造内で参照されます。

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

ドキュメントを処理する際に LLM が果たすべき役割を定義します。
  1. Activity Editor で Prompt Text インターフェースが表示されます
  2. ROLE セクションから開始します。
役割

あなたはデータ抽出モデルです。ドキュメントから指定されたベンダー関連の
フィールドのみを抽出してください。ラベルではなく、値のテキストをそのまま抽出してください。
データを推測したり再フォーマットしたりしないでください。明確に存在しないフィールドは省略してください。
Prompt Text Editor 主要なロール指示:
  • 具体的に記載する: 「data extraction model」で LLM に役割(目的)を伝える
  • スコープを定義する: 「vendor-related fields」で抽出対象をベンダー関連の field に限定する
  • 期待値を設定する: 「value text verbatim」でテキストを原文どおりに出力させ、書式変更を防ぐ
  • 欠損データへの対応を指示する: 「Omit any field that is not clearly present」で明確に存在しない field は出力しないようにする
ベストプラクティス:
  • ロールを明確かつ簡潔に保つ
  • 命令形の文(「Extract」「Do not infer」)を使う
  • 実行してはならないことを明示する
  • 例外的なケースの扱い方を定義する

ステップ 5: 出力形式を定義する

抽出結果のための正確な JSON 構造を指定します。
  1. ROLE セクションの下に OUTPUT FORMAT という見出しを追加します
  2. JSON 構造を定義します:
OUTPUT FORMAT

Return one valid JSON object using this exact structure:

{
  "Fields": [
    { "FieldName": Vendor.Name, "Text": "...", "Line": <FirstLineIndex> },
    { "FieldName": Vendor.Address, "Text": "...", "Line": <FirstLineIndex> },
    { "FieldName": Vendor.TaxID, "Text": "...", "Line": <FirstLineIndex> },
    { "FieldName": Vendor.Account Number, "Text": "...", "Line": <FirstLineIndex> },
    { "FieldName": Vendor.Sort Code, "Text": "...", "Line": <FirstLineIndex> },
    { "FieldName": Vendor.IBAN, "Text": "...", "Line": <FirstLineIndex> },
    { "FieldName": Vendor.BIC_SWIFT, "Text": "...", "Line": <FirstLineIndex> }
  ]
}
JSON Output Format 構造要素:
  • FieldName: field 定義と完全に一致している必要があります(例: Vendor.Name
  • Text: 抽出された値(string)
  • Line: 値が文書内のどの位置に現れるかを示す、0 ベースの行インデックス
重要な注意事項:
  • Output の設定で定義した正確な field 名を使用する
  • 一部が空になる可能性があっても、すべての field を含める
  • 構造は有効な JSON 形式でなければならない
  • 行番号は検証やトラブルシューティングに役立つ

ステップ 6: Field ごとの抽出ルールを追加する

各 field の抽出方法について、詳細な手順を記述します。 OUTPUT FORMAT の下に、各 field の種類ごとの具体的なルールを追加します。
VENDOR NAME
1) Recognize names like "ABC Corporation", "XYZ Ltd", "Acme Inc.".
2) Extract the complete company name including legal suffixes (Ltd, Inc, GmbH, etc.).
3) Vendor name typically appears near the top of the document.

VENDOR ADDRESS
1) Extract the complete address including street, city, postal code.
2) For multiline addresses, represent each new line using "\n".
3) Vendor-side only; exclude customer/buyer addresses.

ACCOUNT NUMBER
1) Recognize "Account Number", "Account No", "Acct #".
2) Extract the numeric format exactly as printed (e.g., "12-34-56" or "500 105 17").
3) Vendor-owned accounts only (e.g., "Beneficiary" or "Vendor Payment" sections).
4) Ignore IBAN — it has its own field.

SORT CODE
1) Recognize "Sort Code", "Sort No.", "BLZ", "Bankleitzahl".
2) Extract the numeric format exactly as printed (e.g., "12-34-56" or "500 105 17").
3) Vendor-side data only; ignore payer/buyer codes.

IBAN
1) Recognize "IBAN", "International Bank Account Number".
2) Extract the full IBAN exactly as printed (include spaces).
3) Vendor-side only, typically under "Bankverbindung", "Coordonnées bancaires", "Payment Details", or "Beneficiary Bank".

BIC_SWIFT
1) Recognize "BIC", "SWIFT", or "BIC/SWIFT".
2) Extract the complete identifier (usually 8 or 11 uppercase letters/numbers).
3) Vendor-side only, near the IBAN or bank name.
4) Exclude customer/payer data.
抽出ルール ルールの構成:
  • 認識パターン: 各fieldの代替ラベルを列挙する
  • 書式仕様: 抽出対象データの正確な形式を記述する
  • 位置のヒント: データを通常どこで見つけられるかを示す
  • 除外項目: 抽出してはいけないものを指定する
ベストプラクティス:
  • 分かりやすいようにルールに番号を振る
  • 複数のラベル候補を用意する
  • データの所有主体を明示する(ベンダー側 vs. 顧客側)
  • 括弧内に書式の例を含める
  • 関連するfieldについて明確にする(例: “IBANは無視 — IBANには専用のfieldがある”)

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

データの品質と一貫性を確保するためにバリデーションルールを追加します。 プロンプトの最後に STRICTNESS セクションを追加します。
STRICTNESS
- Never generate or infer values.
- Omit ambiguous or missing fields.
- If none of the vendor fields are found, return:
  {
    "Fields": []
  }
厳格ルール 追加の厳格ルール(オプション):
一般ルール
- 各fieldから正確に1つの値を抽出します。
- 確実に特定できないfieldはスキップし、出力から除外します。
- "FieldName"は上記の名前と完全に一致させる必要があります。
- "Text"はドキュメントから一字一句そのままコピーします。正規化や推測は行いません。
- 複数行の値(例:住所)の場合、各改行をエスケープシーケンス"\n"(バックスラッシュに続けて文字n)で表現します。
- 出力テキストに<br>などのHTMLタグを挿入しないでください。
- "Line"は抽出された値を含む最初の行の0ベースのインデックスです。検証可能な場合のみ含めます。
厳密性が重要な理由:
  • ハルシネーションを防ぐ: LLM はもっともらしいが誤ったデータを生成することがある
  • 一貫性を確保する: 明確なルールによって実行ごとのばらつきを減らす
  • 欠損データに対応する: field が見つからない場合の扱いを定義する
  • データ完全性を維持する: 原文どおりの抽出で元の書式を保持する
厳密性に関する主な原則:
  • 文書内に存在しないデータは決して生成しない
  • 推測するのではなく、確信が持てない抽出結果は省略する
  • field が見つからない場合は空の構造を返す
  • field 名を厳密に一致させる
  • 元のテキストの書式を保持する

Step 8: ドキュメント形式を選択する

LLM に送信するドキュメントの形式を選択します。
  1. Activity Editor で Prompt ドロップダウンを見つけます
  2. ドキュメントを LLM にどの形式で渡すかを選択できます
Document Format Options 利用可能な形式:
  • PDF: 元の PDF ファイル
    • 推奨用途: レイアウトが重要なドキュメント
    • 考慮事項: ファイルサイズが大きくなり、一部の LLM は PDF への対応が限定的です
  • 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. 抽出された field が表示される Output パネルを確認します
  3. 各 field をクリックして次を確認します:
    • 抽出された値
    • 信頼度(提供されている場合)
    • ドキュメント画像上でハイライトされている領域
Reviewing Results 確認すべき点:
  • ✅ 期待されるすべての field が入力されている
  • ✅ 値がドキュメントと完全に一致している
  • ✅ ハルシネーション(誤生成)や推測によるデータがない
  • ✅ 複数行の field が正しく処理されている
  • ✅ 欠落している field が誤ったデータで埋められず、省略されている

共通の結果パターン

抽出が正常に行われた場合:
{
  "Fields": [
    { "FieldName": "Vendor.Name", "Text": "ABC Corporation Ltd", "Line": 3 },
    { "FieldName": "Vendor.Address", "Text": "123 Business Street\nLondon SW1A 1AA", "Line": 5 },
    { "FieldName": "Vendor.IBAN", "Text": "GB29 NWBK 6016 1331 9268 19", "Line": 15 }
  ]
}
部分的な抽出(いくつかの fields が欠落している):
{
  "Fields": [
    { "FieldName": "Vendor.Name", "Text": "ABC Corporation Ltd", "Line": 3 }
  ]
}
Field が見つかりません:
{
  "Fields": []
}

ステップ 10: プロンプトを改善する

テスト結果に基づいて、プロンプトを繰り返し見直して改善します。

よくある問題とその解決策

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

反復的な改善プロセス

  1. 複数のドキュメントでテストする: 1つの例に合わせて最適化しない
  2. パターンを記録する: どのルールが有効で、どれにさらなる調整が必要かを記録する
  3. 具体的な例を追加する: 括弧内に書式例を含める
  4. 厳しさを調整する: 過剰抽出/不足抽出のパターンに基づいて調整する
  5. エッジケースをテストする: field が欠落しているドキュメントやレイアウトが特殊なドキュメントでテストする

改善例

修正前:
VENDOR NAME
1) Extract the vendor name from the document.
処理後:
ベンダー名
1) 「ABC Corporation」、「XYZ Ltd」、「Acme Inc.」のような名称を認識します。
2) 法的接尾辞(Ltd、Inc、GmbH等)を含む完全な会社名を抽出します。
3) ベンダー名は通常、文書の上部付近に表示されます。
4) 顧客/購入者名は除外し、請求書を発行する事業体に焦点を当てます。

抽出プロセスを理解する

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

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

トークン使用量とコスト

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

ベストプラクティス

プロンプト作成

推奨事項(Do):
  • ✅ 明確な命令形の文を使う(“Extract”、“Recognize”、“Omit”)
  • ✅ 各fieldに対して複数のラベル表現を用意する
  • ✅ 括弧内に書式の例を含める
  • ✅ 抽出してはいけないもの(除外項目)を明示する
  • ✅ 参照しやすいようにルールに番号を振る
  • ✅ 全体を通して用語を一貫して使用する
非推奨事項(Don’t):
  • ❌ あいまいな指示を使う(“get the name” など)
  • ❌ LLMがドメイン固有の慣例を知っていると想定する
  • ❌ 不必要に長く複雑な文章を書く
  • ❌ セクションごとに内容が矛盾するように書く
  • ❌ 厳密さに関するルールを省略する

Field の定義

効果的な Field 指示のポイント:
  • 認識パターン(代替ラベル)から記述する
  • 保持したい正確なフォーマットを指定する
  • 典型的な配置など、位置の目安を示す
  • データの所有者(ベンダーか顧客か)を定義する
  • 複数行の値の扱い方法を明記する
  • 混同を防ぐために、関連する field を参照する
例:
IBAN(国際銀行口座番号)
1) 「IBAN」、「International Bank Account Number」を認識する。
2) 印刷されているとおりにIBAN全体を抽出する(スペースを含む)。
3) ベンダー側のみ、通常は「Bankverbindung」、「Payment Details」配下に記載。
4) アカウント番号と混同しないこと — IBANはより長く、英数字形式である。

テスト戦略

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

パフォーマンス最適化

速度向上のため:
  • プロンプトを簡潔に保つ
  • Annotated Text 形式を使用する
  • アクティビティごとの field 数を最小限にする
  • 複雑なドキュメントは分割を検討する
精度向上のため:
  • 網羅的な field ルールを設定する
  • 形式(フォーマット)の例を含める
  • 厳格なルールを追加する
  • 多様なドキュメントサンプルでテストする
コスト削減のため:
  • プロンプトの長さを最適化する
  • 効率的なドキュメント形式を使用する
  • 適切な場合は結果をキャッシュする
  • LLM プロバイダのダッシュボードでトークン使用量を監視する

トラブルシューティング

抽出に関する問題

問題: データが存在するにもかかわらず field が空のままになる 解決方法:
  • field 名の綴りが完全に一致しているか確認する
  • データが選択したドキュメント形式で利用可能か検証する
  • 認識パターンにラベルのバリエーションを追加する
  • 一時的に制約の厳しさを下げて、LLM が見つけられるか確認する
  • ドキュメントの品質が OCR/Text 抽出に影響していないか確認する
問題: LLM がベンダーのデータではなく顧客データを抽出してしまう 解決方法:
  • ベンダー側の指定/要件を強化する
  • 顧客/購入者データを明示的に除外する
  • 位置に関するヒントを与える(例: 「ドキュメント上部」「発行者セクション」)
  • 正しい抽出と誤った抽出の例を含める
問題: 複数行の値が連結されたり、不正な形式になる 解決方法:
  • エスケープシーケンス形式(\n)を明示的に指定する
  • 正しい複数行出力の例を提示する
  • ドキュメント形式が改行を保持することを確認する
  • 次の指示を追加する: 「元の改行を \n で保持すること」
問題: LLM がデータを再フォーマットまたは正規化してしまう 解決方法:
  • 「verbatim」および「exactly as printed」を強調する
  • 厳格なルールを追加する: 「正規化や推論は行わないこと」
  • 書式を保持する具体的な例を提示する
  • 否定例を含める: 「12-34-56」ではなく「12 34 56」のままにする

パフォーマンスの問題

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

高度なテクニック

条件付き抽出

条件が満たされている場合にのみ特定の field を抽出するよう、LLM に指示できます。
ACCOUNT NUMBER (CONDITIONAL)
1) Only extract if the document contains bank payment details.
2) If "Payment Method: Check" or similar appears, omit this field.
3) Recognize "Account Number", "Account No", "Acct #".

多言語サポート

プロンプトベースの抽出は、多言語ドキュメントに対しても効果的に機能します。
VENDOR NAME (MULTI-LANGUAGE)
1) Recognize in English: "Vendor Name", "Supplier", "Seller"
2) Recognize in German: "Verkäufer", "Lieferant", "Anbieter"
3) Recognize in French: "Fournisseur", "Vendeur"
4) Extract the complete company name regardless of language.

バリデーションルール

プロンプトにバリデーションロジックを追加します:
IBAN (WITH VALIDATION)
1) Extract the full IBAN exactly as printed.
2) Verify it starts with a 2-letter country code.
3) If format doesn't match IBAN pattern, omit the field.
4) Do not invent check digits or country codes.

Field 間の関係

Field 同士がどのような関係にあるかを指定します:
ACCOUNT NUMBER vs IBAN
- Account Number: Usually shorter, numeric, domestic format
- IBAN: Alphanumeric, starts with country code (e.g., "GB29 NWBK...")
- If both are present, extract both to separate fields
- If only one is present, extract to the appropriate field
- Do not duplicate the same value in both fields

制限事項と考慮事項

現在の対応状況

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

プロンプトベース抽出を使用するタイミング

最適なケース:
  • レイアウトが可変なドキュメント
  • 半構造化されたドキュメント
  • 迅速なプロトタイピングとテスト
  • 少〜中程度のドキュメント量
  • 学習データが利用できない場合
  • 複数言語のドキュメント処理
代替手段を検討すべきケース:
  • 大量処理が必要な本番環境(従来型の機械学習の方が高速な場合があります)
  • 高度に構造化された帳票(テンプレートベースの抽出)
  • コストに敏感なアプリケーション(従来手法の方が安価な場合があります)
  • レイテンシ要件の厳しいアプリケーション(LLM API にはネットワーク遅延があります)
  • オフライン処理が必要な場合(従来手法ではインターネット接続が不要です)

Document Skill との連携

抽出データの使用

抽出が完了すると、field データは Document Skill 内のあらゆる箇所で利用できるようになります。
  1. 検証アクティビティ: 抽出された値にビジネスルールを適用します
  2. スクリプトアクティビティ: 抽出されたデータを処理または変換します
  3. エクスポートアクティビティ: データを外部システムへ送信します
  4. レビューインターフェース: 抽出された field を手動で検証します

他のアクティビティとの組み合わせ

プロンプトベースの抽出は、他のアクティビティと組み合わせて使用できます。
Workflow Example:
1. Classification (identify document type)
2. OCR (extract text)
3. Prompt-based extraction (extract structured data)
4. Validation rules (verify data quality)
5. Script (format for export)
6. Output (deliver results)

Field マッピング

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

まとめ

ここまでで、次のことを行いました:
  • ✅ プロンプトベースの抽出アクティビティを作成しました
  • ✅ LLM 接続を構成しました
  • ✅ 役割・形式・ルールを含む包括的な抽出プロンプトを作成しました
  • ✅ 最適なドキュメント形式(Annotated Text)を選択しました
  • ✅ データ品質のための厳格性ルールを適用しました
  • ✅ 抽出をテストし、結果を確認しました
  • ✅ プロンプトエンジニアリングのベストプラクティスを学びました
重要なポイント:
  • プロンプトベースの抽出は自然言語による指示を使用します
  • Annotated Text 形式が最良の結果をもたらします
  • 明確で具体的なプロンプトは、一貫した抽出結果につながります
  • 厳格性ルールによりハルシネーションが防止され、データ品質が維持されます
  • テストと改善を繰り返すことで精度が向上します
これで、プロンプトベースの抽出アクティビティはドキュメント処理に利用できる状態になりました!

次のステップ

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

参考リソース

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

よくある質問

Q: プロンプトベース抽出と従来型抽出の違いは何ですか? A: プロンプトベース抽出は、学習用データなしで LLM への自然言語による指示を利用します。従来の手法では学習用サンプルが必要ですが、大規模運用時の処理速度とコスト効率に優れています。 Q: プロンプトベースのアクティビティでテーブルを抽出できますか? A: ヘッダー単位での抽出は十分にサポートされています。テーブル抽出機能はケースによって異なり、特定のプロンプト構造が必要になる場合があります。 Q: なぜ PDF ではなく Annotated Text を使うのですか? A: Annotated Text は、構造の保持と処理効率の最適なバランスを提供します。テストの結果、最も信頼性が高いことが確認されています。 Q: API コストを削減するにはどうすればよいですか? A: プロンプトの長さを最適化し、Annotated Text 形式を使用し、処理を効率化するとともに、LLM プロバイダーのダッシュボードでトークン使用量を監視してください。 Q: LLM 接続が失敗した場合はどうすればよいですか? A: Configuration → Connections で接続ステータスを確認してください。接続テストを実行し、認証情報を確認し、API クォータを超過していないことを確認します。 Q: 1 つの Skill 内で複数の LLM 接続を使用できますか? A: はい、アクティビティごとに異なる接続を使用できます。これにより、抽出タスクごとに異なるモデルを使い分けることができます。 Q: 複数言語のドキュメントにはどのように対応すればよいですか? A: field ルールに多言語のラベルバリエーションを追加します。LLM は一般的に多言語コンテンツを良好に処理できます。 Q: ドキュメントの最大サイズはどのくらいですか? A: 使用する LLM プロバイダーのトークン上限に依存します。非常に長いドキュメントは分割するか、セクションごとに処理する必要があります。