ベスト プラクティス

このセクションでは、プロジェクト レベル (つまり、全体的な抽出レベル)、フィールド グループ レベル、および個々のフィールド レベルで適切なプロンプトの指示を記述する方法に関するベスト プラクティスについて説明します。

注:

これらのベスト プラクティスは外部 LLM 向けに設計されていますが、OCR の問題は引き続き発生する可能性があります。プロンプトが適切に作成されていても、すべてのガイドラインに従っているからといって、抽出のパフォーマンスが期待に応えられるとは限りません。

タクソノミーに関する一般的な推奨事項

• 明確かつシンプルにする - 明確・端的で、曖昧ではない言葉を使用します。指示を複雑にし過ぎないようにします。モデルが混乱する可能性があります。平易な言葉を使い、文章を簡潔に保ってください。
• 一貫性を保つ - 混乱を避けるため、フィールド、フィールド グループ、指示にわたって用語の一貫性を保ちます。
• コンテキストを提供する - 関連するコンテキストをモデルに提供し、タスクの全般的な範囲を理解できるようにします。モデルは処理するタスクを理解する必要があるため、業界に関する情報、ドキュメントの種類、全体的なデータ形式を含めることができます。プロンプト内で提供するコンテキストを増やすと、モデルがフィールドを一貫して正しく予測する確率が上がります。
• 反復する - プロンプトの改良は反復的なプロセスであるため、下書きとそれに対応する結果の記録を保持しておくと、今後の調整や改良のための貴重な洞察が得られます。プロンプトの記述、テスト、編集というプロセスを目的の抽出が得られるまで繰り返します。
• 否定的な指示を避ける - 「ドキュメントのどのセクションも省略しないでください」のような指示を入力しないでください。代わりに、「X、Y、Z など、ドキュメントの主要なセクションがすべて網羅されていることを確認してください」のような指示に置き換えます。
• 言葉を繰り返さないようにする - 言葉を繰り返すと、重複や混乱を招き、モデルにとって不明確な指示になる可能性があります。
• 矛盾する情報がないか注意する - プロジェクト レベル、フィールド グループ レベル、およびフィールド レベルの指示が、抽出する情報、抽出の形式、情報がある場所の点で互いに矛盾していないことを確認します。矛盾があると、モデルが混乱し、一貫性のない結果が生じます。
• 例を追加して強化する - 可能な限り、正しい回答の例を追加してプロンプトの指示を強化します。このような例により、期待される結果へモデルをガイドすることができます。

図 1. タクソノミーの例

プロジェクト (全体的な抽出) レベル

ベスト プラクティス	詳細	重要度	正しい例	誤った例
業界とドキュメントの種類を定義する	業界、および情報を抽出するドキュメントの種類について簡単に説明します。続いて、そのドキュメントの種類の主な特徴と予期される構造を指定し、抽出をガイドします。	これにより、データ抽出プロセスに重要なコンテキストが提供されます。	指示: 証券取引明細書から情報を抽出してください。証券取引明細書は金融サービス業界でよく見られます。証券取引明細書は通常、口座の概要、口座の要約、口座の保有資産、口座の取引活動という複数のセクションで構成されています。	指示: ドキュメントから以下のフィールドを抽出してください。 説明: このプロジェクトの指示の例は、モデルにとってメリットがありません。モデルをガイドする重要なコンテキストや主な特徴が提供されていません。
1 つのファイル内にドキュメントが複数回出現することが予想されるかどうかを指定する	ドキュメントに同一データの複数のインスタンスが含まれるかどうかを指定し、抽出インスタンスそれぞれに対してガイダンスを提供します。1 つのファイル内に複数のドキュメントが含まれる可能性があるユース ケースでは、一意の識別子を特定し、それを各フィールド グループにフィールドとして含めます。	これにより後処理が容易になり、より効率的な自動化が可能になります。	指示: 1 つのドキュメント ファイル内に複数の証券口座が存在する可能性があります。証券口座は、各フィールド グループに存在する一意の口座番号フィールドで識別できます。各口座について、口座情報、口座保有資産、および入出金のフィールド グループを抽出してください。	指示: 各口座ドキュメントからデータのすべてのインスタンスを抽出してください。 説明: この指示の例は、ファイル内にドキュメントの種類が複数回出現するかどうかを判断する方法を指定していないため、不十分です。

フィールド グループ レベル

ベスト プラクティス	詳細	重要度	正しい例	誤った例
一緒に抽出する類似のデータ ポイントをフィールド グループにグループ化する	関連するフィールドを論理的なグループに整理します。	これは、抽出の効率化とエラーの最小化に役立ちます。	口座所有者の名前、住所、婚姻状況はすべて、口座所有者情報フィールド グループの下にグループ化できます。	フィールド グループ: 口座情報 フィールド: 口座保有資産、取引日、口座所有者 説明: このグループ化は、ユーザーがこれら 3 つのフィールドのみを抽出したい場合には有効です。ただし、ティッカー シンボルや原価基準などの他のフィールドがある場合、このグループの設計や構造は最も効果的なものではなくなります。
フィールド グループのコンテキスト	各フィールド グループが文書の全体的な意味と目的にどのように寄与するかを説明します。	これにより、モデルは抽出のコンテキストを理解できます。	指示: このセクションには、株式名、購入日、購入数量、原価基準、支払総額など、証券取引明細書の主要な口座保有詳細情報の概要が記載されています。これらの詳細は、証券取引明細書内にある現在の保有資産を判断するのに役立ちます。	指示: ドキュメントから以下のフィールドを抽出してください。 説明: このプロンプトの指示には、コンテキストと、モデルに対する詳細な指示がありません。抽出が必要な情報の種類について説明されておらず、その重要性も強調されていません。
ドキュメント内の情報の場所と構造をフィールド グループのプロンプト内で活用する	各フィールドのデータがあると考えられる場所 (表、ヘッダー、本文など) を指定し、抽出をガイドします。 注: 情報が同じセクション内に出現するドキュメントで作業している場合は、そのセクションをプロンプトで指定します。	これにより、モデルは各フィールドに対して、ドキュメントの正確な部分に的を絞ることができます。	指示: このセクションのフィールドレベルのデータは、ほとんどの場合、最初のページのドキュメント タイトルの下にある、レポートのヘッダーで見つかります。	指示: ドキュメントの先頭から情報を抽出してください。 説明: このプロンプトは曖昧で、具体的にドキュメント内のどこを探すべきかについてモデルに十分な詳細を提供していません。
フィールド グループとフィールドを使用して表をモデル化する	フィールド グループを表とみなします。各列はそのグループ内の一意のフィールドとして機能します。このアプローチは効果的なデータ モデリングの鍵となります。これによって、明確に区別できるほか、データの重複が最小限に抑えられ、データの一貫性が向上するためです。	この方法を用いると、データを論理的に構造化して体系的に整理することができ、後でデータをクエリおよび分析する際の効率が向上します。	フィールド グループ: 顧客 フィールド: 名前、住所、電話番号	フィールド グループ: 顧客名、顧客住所、顧客電話番号 フィールド: 名前、住所、電話番号 説明: この例では、顧客の詳細情報それぞれを専用のフィールド グループに不必要に分けているため、データの管理が複雑化し、不整合が発生しやすくなります。
親フィールド グループと子フィールド グループを作成する	大なり記号 > で関係を指定します。1 つの親フィールド グループが複数の子フィールド グループを持つことができます。	フィールド グループを利用してドキュメント内のデータ間の関係を示すと、データの階層的な構成を効果的に維持できます。	フィールド グループ: 証券取引明細書 フィールド: 口座所有者、口座種別 フィールド グループ名: 証券取引明細書 > 資産配分 フィールド: 資産種別 (例: 株式、債券、現金、総資産に対する割合) フィールド グループ名: 証券取引明細書 > 投資 フィールド: 投資名、保有数量、一株あたりの発行価格、投資総額	フィールド グループ: 口座所有者 フィールド: 名前、投資名、口座種別、株、株式、および債券の数 フィールド グループ: 口座所有者 > 住所 フィールド: 番地、市区町村、都道府県、郵便番号 フィールド グループ: 口座所有者 > 連絡先情報 フィールド: 電話番号、メール アドレス 説明: この階層は適切に構造化されていません。関連しないフィールドが同じ親の下に結合されており、子フィールド グループ (住所と連絡先情報) がその親のフィールド (投資名、株、株式、および債券の数) と論理的に関連していないためです。これにより、ドキュメント内のデータの自然な構成が反映されないため、AI モデルが混乱する可能性があります。
複数のドキュメントを含むファイルに対して 1 つのキー フィールドを使用する	データを区別可能な、ドキュメント内の一意の識別子を選択します。このフィールドをすべてのフィールド グループに含めます。このフィールドに対する指示は、フィールド グループごとに変更する必要はありません。	このキー フィールドを含めることにより、ドキュメント内の情報を分離することができ、抽出データを処理する際の混乱が解消されます。	フィールド: 口座番号、社会保障番号、保険証券番号	フィールド: 日付、名前 説明: ここに挙げられているフィールド名は一意ではないため、適切なキー フィールドになりません。日付と名前はどちらも繰り返し出現する可能性があります。

フィールド レベル

ベスト プラクティス	詳細	重要度	正しい例	誤った例
フィールド名は慎重に選ぶ	フィールドには、ユーザーの期待に沿った明確でわかりやすい名前を選択します。ドキュメントのすべてのバリエーションで使用される共通の名前がある場合は、必ずその名前を含めてください。	正確なフィールド名を使用すると、正確な抽出が保証され、曖昧さが減ります。	フィールド: 事故発生日	フィールド: 日付 説明: 日付は一般的な用語であり、日付が何を指すかについてのコンテキストを提供しません。AI モデルはドキュメントに出現する任意の日付を取得する可能性があるため、データ抽出が不正確になる可能性があります。
指示は明確かつ詳細に記述する	モデルを開始するには、モデルで何を抽出するかを明確に記述します。抽出するデータの形式と構造を正確に指定します。	明確で詳細なプロンプトにより、必要な情報を期待する形式で正確に抽出するようモデルをガイドします。	指示: ドキュメントからすべてのアドバイザーのリストを抽出し、コンマ区切りリスト形式にしてアドバイザーをアルファベット順に並べてください。	指示: すべてのアドバイザーを取得してください。 説明: このプロンプトは曖昧で、目的の結果と必要な形式についての明確な指示をモデルに提供していません。そのため、抽出された情報に一貫性がなく、結果を処理しづらくなる可能性があります。
指示の中で例を提供する	入力の例と、対応する期待される出力を提供し、期待される結果を明確にします。	これによって、モデルはユーザーが何を探しているかを正確に理解できます。	指示: ドキュメントからトランザクションの日付を抽出します。日付は MM/DD/YYYY 形式である必要があります。たとえば、ドキュメントにトランザクションが 2021 年 1 月 1 日に完了したと記載されている場合、抽出日は 2021 年 1 月 1 日になります。取引日が MM/YYYY 形式で記載されている場合は、その月の 1 日として抽出します。たとえば、日付が 2021 年 5 月 5 日と表示される場合は、2021 年 5 月 1 日として抽出します。	指示: ドキュメントから取引日付を取得してください。 説明: 上記のプロンプトは、ドキュメント内で見つかるさまざまな日付形式を処理する方法についての明確な指示を提供していないため、あまり効果的ではありません。このように明確さが欠けていると、日付の抽出に一貫性がなくなり、データの解釈と分析の作業が複雑になる可能性があります。
フィールド指示ごとに 1 つの主要なアイデアに固執する	プロンプトに指示を詰め込みすぎないようにします。これは、連続する大量のデータを 1 つのフィールドで抽出して精度を向上させようとした場合に発生します。各フィールド レベルでは、1 つのデータの抽出に的を絞る必要があります。	これにより、後処理も容易になります。	フィールド 1: 口座番号を抽出する フィールド 2: 取引日付を抽出する フィールド 3: 口座残高を抽出する	指示: 口座番号、取引日付、口座残高を一緒に抽出してください。 説明: このプロンプトには複数の指示が詰め込まれていて、異なる種類のデータを同時に抽出するようモデルに指図しています。このアプローチでは、雑然とした抽出結果が生成され、後処理が困難になる可能性があります。

フィールドの種類レベル

ベスト プラクティス	詳細	重要度	正しい例	誤った例
目的を持ってデータ型を選択する	抽出したデータをどのような形式にするかを検討し、データを下流のユース ケースに合致させて、抽出データを自動化用に最適化します。  日付 - テキスト内の日付を表す場合に使用します。日付は YYYY-MM-DD HH:MM:SS 形式で UTC として正規化されます。  正確なテキスト - テキスト内に逐語的に表示されているテキストを表す場合に使用します。  推論されたテキスト - テキスト内に逐語的には表示されていない可能性があるものの、ドキュメント内に他の識別子があるテキストに使用します。  金額 - テキスト内の金額を表す場合に使用します。金額は、たとえば $00.00 や 00.00 USD の形式で正規化されます。 数値 - テキスト内の量や数を表す場合に使用します。数値はドキュメントから推論されます。ユーザーは値を入力したり、根拠となる箇所のアノテーションを任意で行ったりできます。値は 10 進値 (00.00) として書式設定されます。	適切なデータ型を選択すると、形式を正確に設定でき、下流での処理が容易になります。	フィールド名: 取引高 データ型: Number	フィールド名: 電話番号 データ型: Number 説明: 電話番号に Number データ型を使用しても有益ではありません。電話番号は数字で構成されていますが、数値ではありません。つまり、電話番号で計算を行うわけではないので、数字の文字列として記述した方が適切です。したがって、正確なテキストのデータ型を使用するのが適切な選択です。
フィールドの種類には、そのフィールドの種類専用の指示のみを含める	データ抽出の指示を入力する際は、常に指示を各フィールドの種類専用にすることが重要です。特定の種類のフィールドすべてに適用される全般的な指示がある場合、ユーザーはその指示をフィールドの種類レベルで入力して、繰り返しを避けることができます。たとえば、すべての金額フィールドを米ドルにする必要がある場合は、フィールドの種類レベルで指定します。  ただし、データセットによっては、既存のフィールドの種類 (日付、テキスト、金額など) でカバーされていない一意のフィールドが必要になる場合があります。このような場合は、カスタマイズされた新しいフィールドの種類を作成できます。これらの新しいフィールドに対する指示を記述するときは、データをどのような形式にする必要があるかを指定し、抽出データが意図した目的に合致するようにします。これらの手法により、抽出データの精度と一貫性が向上します。		フィールドの種類: 日付 指示: ドキュメントから取引に関連するすべての日付を抽出してください。日付は、YYYY-MM-DD 形式で正規化する必要があります。	フィールドの種類: 金額 指示: 請求書明細項目の表の価格列から項目の価格を抽出してください。 説明: この指示は、特定のフィールド ([価格] 列) から金額を抽出することに特に関連しており、他の金額ベースのフィールドには関連していません。

フィールドとフィールドの種類の例

署名

ドキュメントに署名が含まれる場合は、次のベスト プラクティスを適用してください。

• [署名者 X?] フィールド (つまり、この個人によって署名されていますか?) には Boolean データ型を使用し、個人の名前を表すテキスト フィールド (通常は出力されます) を使用します。

• 通常、署名がテーブルまたはテーブルのような形式で表示される場合は、[ テーブル モデルの 前処理] オプションを使用します。

• 失敗は、文書内の指名された個人とその証人の両方を含む複数の署名者がいる文書で最も一般的です。

• 次の点について明確かつ説明的に指定します。

  • 署名を構成するものは何ですか?
  • 署名を構成しないものは何ですか?
  • ドキュメントには誰が署名する必要がありますか?
  • ドキュメントに署名する必要がある人を検出するにはどうすればよいですか?

• 次の例で説明するように、ドキュメント内の潜在的な失敗ケースを考慮し、指示に含めます。

  [署名者] フィールドの指示例

  証人ではなく、署名者が文書に署名したかどうかを判断します。

  ドキュメントがこの署名者によって署名されている場合にのみ true を返します。署名されていない場合はfalseを返します。

  署名は印刷された名前のようには見えない場合があるため、特定の署名者の名前の近くの署名用のスペースで、ドキュメントへの署名または手書きの署名のような追加を探します。

  名前が手書きの追加で修正された場合、これは署名として扱われるべきではなく、明示的な署名としてのみ扱われるべきです。

  署名は通常、「署名者」という単語、または「証書として署名された」、「の面前で」などのバリエーションの周りに近くなります。

  点線は署名を構成しません。

  署名フィールドが一般的な署名フィールドグループで、署名者の名前または位置、あるいはその両方と組み合わされている場合は、指示を追加できます。 署名を正しい個人に帰属させていることを確認してください。

  より広範な [署名] フィールド グループに対する指示の例を次に示します。

  [署名] フィールド グループの指示例

  ドキュメントの署名者とステータスに関する情報。ドキュメントに複数の署名ブロックがあり、複数のユーザーが存在する場合は、すべての署名ブロックを抽出します。

  明示的な署名ブロックがない場合、契約書や手紙は送信者によって署名され、受け入れる人の署名ブロックがある可能性があります。この場合は、両方の署名のセットを抽出します。

  注:

  指示のチューニングを通じてパフォーマンスを改善するために粘り強い努力をした後でも、パフォーマンスが十分でない場合は、アカウントマネージャーに連絡してください。役立つプレビュー処理機能がリージョンで利用可能かどうかを確認できます。

地域差

金額とコンマ区切り文字

LLM の既定の動作を修正するよう求めるプロンプトが表示される地域差の例としては、ドイツやインドなどの特定の国での小数点の区切り文字としてのコンマの使用が挙げられます。

ドイツの領収書のユース ケースの次の例は、予期しない形式の値の存在を考慮する方法を示しています。

指示例

ドイツの領収書からデータを抽出している。金額はすべて€ですが、€記号が表示されない場合があります。"," はすべての数値を表す一般的な小数点区切り文字であり、'.' は大きな値の書式を設定するために使用されます。

この形式が使用されているかどうかを確認するには、値の最後の区切り文字としてコンマがあるかどうかを確認します。そうでない場合、数値は、書式設定に「,」を使用し、小数点以下の桁数に「.」を使用する別の形式で書式設定される可能性があります。

金額は通常、小数点以下が 2 桁です (例:8,58は8.58€、9.115,00は9115.00€)。食料品の領収書の単一品目は100ユーロ未満になると予想されます。

テストして反復する

1. 抽出するすべての情報に対してフィールドを作成します。ただし、指示は含めません。
2. 2 個から 3 個のドキュメントのサンプルを選択し、それぞれに対して予測を実行します。これらのドキュメントには、モデルを構築するドキュメントに存在するバリエーションが反映されている必要があります。
3. モデルの抽出データを期待した内容と比較します。パフォーマンスが十分でなかったフィールドについては、前述のベスト プラクティスを使用してプロンプトの下書きを作成します。これはベースライン プロンプトとして機能します。
4. 以前にテストしたものと同じ 2 個から 3 個のサンプル ドキュメントを使用して予測を再実行し、抽出のパフォーマンスが向上したかどうかを確認します。
5. 予測が不正確または不完全な場合は、プロンプトを調整して必要な詳細情報を追加し、モデルの抽出パフォーマンスを向上させます。予測が期待と一致する場合は、ドキュメントのサンプル サイズを拡大します。サンプルの数は徐々に増やしていくことが重要です。2 から 3、さらに 10 に増やし、その後 20、30 というように増やしていきます。モデルの予測が正しいと確信できるまで、この作業を続けます。
6. 指示を変更した場合は、以前に表示したドキュメントを再評価して、予測が依然として正確であることを確認します。
7. モデルのパフォーマンスに満足したら、最初のドキュメントに戻ってアノテーションを開始します。[評価] タブで少なくとも 10 個のドキュメントのアノテーションを行い、フィールドのパフォーマンスに関する貴重なメトリックを取得します。この機能により、抽出のパフォーマンスを全体的なプロジェクト レベルとフィールド レベルの両方で評価できます。
8. パフォーマンス メトリックを監視して、プロンプトの大規模な改良のための情報を提供します。プロンプトを反復するプロセスは、主にフィールド レベルで行う必要があります。こうすることで、パフォーマンスが良好でない特定のフィールドに調整の対象を絞って直接影響を及ぼすことができます。フィールド グループのスコアのパフォーマンスが良好でない場合は、プロジェクトとフィールド グループの指示を調整します。これらの指示は複数のフィールドに影響するため、影響が大きくなります。