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

​
概要

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

​
前提条件

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

​
プロンプトベース抽出を理解する

​
プロンプトベース抽出とは？

プロンプトベース抽出は、LLM を使用して、自然言語による指示に基づきドキュメントからデータを理解・抽出する手法です。次の内容を定義します：
  • 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. ドロップダウンメニューをクリックします。
Configuring LLM Connection
  1. 一覧から設定済みの LLM 接続を選択します。
    • 例: Nick-ChatGPT, Microsoft Foundry, Production GPT-4
  2. 選択された接続が正しいことを確認します。
注: 接続が何も表示されない場合は、先に Configuration → Connections から LLM 接続を構成しておく必要があります。

​
Step 3: 出力fieldを定義する

プロンプトを作成する前に、抽出したいfieldを設定します。
  1. Activity Properties パネルで Output セクションを探します。
  2. fieldグループとfieldの階層リストが表示されます。
  3. この例では、ベンダー情報を抽出します:
    • ベンダー
      • Name
      • Address
      • TaxID
      • アカウント番号
      • Sort Code
      • IBAN（国際銀行口座番号）
      • BIC_SWIFT
    • Business Unit
      • Name
      • Address
      • 請求日
      • 請求書番号
    • 合計
      • Net Amount（正味合計金額）
field出力構造
  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」で抽出対象を限定する。
  • 期待を明示する: 「value text verbatim」と指定して再フォーマットを防ぐ。
  • 欠損データへの対応を指示する: 「明確に存在しない 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 出力形式 構造コンポーネント:
  • 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.
Extraction Rules ルールの構成:
  • 認識パターン: 各 field の代替ラベルを列挙する
  • フォーマット仕様: 抽出すべき正確な形式を記述する
  • 位置のヒント: データが通常どこにあるかを示す
  • 除外条件: 抽出してはいけないものを示す
ベストプラクティス:
  • 分かりやすくするためにルールに番号を付ける
  • 複数のラベルバリエーションを用意する
  • データがどちら側のものか（ベンダー側か顧客側か）を明示する
  • 括弧内にフォーマット例を含める
  • 関連する 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": []
  }
Strictness Rules 追加の厳格性ルール（オプション）: 
GENERAL RULES
- Extract exactly one value per field.
- Skip any field that cannot be confidently located — omit it from the output.
- "FieldName" must match the names above exactly.
- "Text" must be copied verbatim from the document — no normalization or inference.
- For multiline values (e.g., addresses), represent each new line using the escape sequence "\n" (a backslash followed by the letter n).
- Do not insert HTML tags such as <br> in the output text.
- "Line" is the 0-based index of the first line containing the extracted value; include it only if verifiable.
厳格さが重要な理由:
  • ハルシネーションを防ぐ: LLM はもっともらしく見えても誤ったデータを生成する可能性がある。
  • 一貫性を確保する: 明確なルールにより、実行ごとのばらつきを減らす。
  • 欠損データを処理する: field が見つからない場合にどうするかを定義する。
  • データの完全性を維持する: 原文どおりに抽出して元の書式を保持する。
厳格さに関する主な原則:
  • ドキュメントに存在しないデータを決して生成しない。
  • 推測するのではなく、不確実な抽出結果は省略する。
  • field が見つからない場合は空の構造体を返す。
  • field 名は完全一致させる。
  • 元のテキストの書式を保持する。

​
ステップ 8: 文書形式を選択する

LLM に送信する文書の表現形式を選択します。
  1. Activity Editor で Prompt ドロップダウンを見つけます
  2. 文書を LLM にどのような形式で渡すかのオプションが表示されます
文書形式オプション 利用可能な形式:
  • 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 が入力されていること
  • ✅ 値がドキュメントと完全に一致していること
  • ✅ ハルシネーション（AI による虚偽生成）や推測されたデータがないこと
  • ✅ 複数行の 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 }
  ]
}
部分的な抽出（いくつかの field が欠落している）: 
{
  "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. 複数のドキュメントでテストする: 単一の例だけに最適化しないようにする。
  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 をまとめてグループ化することを検討する。

​
ベストプラクティス

​
プロンプト記述

やるべきこと:
  • ✅ 明確な命令形の文を使う（“Extract”、“Recognize”、“Omit” など）。
  • ✅ 各 field に対して複数のラベル候補を用意する。
  • ✅ かっこ内にフォーマット例を含める。
  • ✅ 抽出してはいけないもの（除外項目）を明示する。
  • ✅ 参照しやすいようにルールに番号を振る。
  • ✅ 全体を通して用語を統一する。
やってはいけないこと:
  • ❌ あいまいな指示を使う（“get the name” など）。
  • ❌ LLM がドメイン固有の慣習を知っていると仮定する。
  • ❌ むやみに長く複雑な文を書く。
  • ❌ セクション間で内容が矛盾するように書く。
  • ❌ 厳格さに関するルールを省略する。

​
Field 定義

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

​
テスト戦略

  1. シンプルなドキュメントから始める: まずは基本的な抽出をテストする。
  2. バリエーションに広げる: 異なるレイアウトや形式を試す。
  3. エッジケースをテストする: field が欠落している場合、通常と異なる位置、複数の一致がある場合など。
  4. 失敗事例を記録する: 抽出が失敗した例を残しておく。
  5. 体系的に反復する: 1 回に 1 つずつ変更する。

​
パフォーマンス最適化

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

​
トラブルシューティング

​
抽出に関する問題

問題: データが存在するにもかかわらず、field が空になる。 解決策:
  • field 名のスペルが完全に一致しているか確認する。
  • データが選択したドキュメント形式内にあることを確認する。
  • 認識パターンにラベル表記のバリエーションを追加する。
  • 一時的に厳格さを下げて、LLM が見つけられるか確認する。
  • ドキュメント品質が OCR/テキスト抽出に影響していないか確認する。
問題: LLM がベンダーのデータではなく顧客データを抽出してしまう。 解決策:
  • ベンダー側の指定をより詳細にする。
  • 顧客/購入者データを明示的に除外する。
  • 位置に関するヒントを提供する（例: “ドキュメント上部”, “発行者セクション”）。
  • 正しい抽出と誤った抽出の例を含める。
問題: 複数行の値が連結されたり、不正な形式になる。 解決策:
  • エスケープシーケンスの形式（\n）を明示的に指定する。
  • 正しい複数行出力の例を提供する。
  • ドキュメント形式が改行を保持しているか確認する。
  • 次の指示を追加する: “元の改行を \n を使って保持すること”。
問題: LLM がデータを再フォーマットしたり正規化してしまう。 解決策:
  • “verbatim” および “印字されているとおり正確に” を強調する。
  • 厳格さのルールを追加する: “正規化や推論は行わないこと”。
  • 書式を保持する具体例を提供する。
  • 次のようなネガティブ例を含める: “「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 間の関係

fields が互いにどのように関連しているかを指定します。 
口座番号 vs IBAN
- 口座番号: 通常は短く、数字のみ、国内形式。
- IBAN: 英数字、国コードで始まる（例: "GB29 NWBK..."）。
- 両方が存在する場合は、両方を別々のフィールドに抽出します。
- 一方のみが存在する場合は、適切なフィールドに抽出します。
- 両方のフィールドに同じ値を重複させないでください。

​
制限事項と留意事項

​
現在の機能

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

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

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

​
Document Skill との統合

​
抽出データの使用

抽出が完了すると、field のデータは Document Skill 全体のあらゆる箇所で利用できるようになります。
  1. Validation Activities: 抽出された値にビジネスルールを適用します。
  2. Script Activities: 抽出されたデータを処理または変換します。
  3. Export Activities: データを外部システムに送信します。
  4. Review Interface: 抽出されたフィールドを手動で確認します。

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

プロンプトベース抽出は、他のアクティビティと組み合わせて利用できます。 
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 フィールドは、定義した出力 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 プロバイダーのトークン上限によって異なります。非常に長いドキュメントは、分割するか、セクションごとに処理する必要が生じる場合があります。