非構造化ドキュメントや複雑なドキュメント ユーザー ガイド
このセクションでは、プロジェクト レベル (つまり、全体的な抽出レベル)、フィールド グループ レベル、および個々のフィールド レベルで適切なプロンプトの指示を記述する方法に関するベスト プラクティスについて説明します。
- 明確かつシンプルにする - 明確・端的で、曖昧ではない言葉を使用します。指示を複雑にし過ぎないようにします。モデルが混乱する可能性があります。平易な言葉を使い、文章を簡潔に保ってください。
- 一貫性を保つ - 混乱を避けるため、フィールド、フィールド グループ、指示にわたって用語の一貫性を保ちます。
- コンテキストを提供する - 関連するコンテキストをモデルに提供し、タスクの全般的な範囲を理解できるようにします。モデルは処理するタスクを理解する必要があるため、業界に関する情報、ドキュメントの種類、全体的なデータ形式を含めることができます。プロンプト内で提供するコンテキストを増やすと、モデルがフィールドを一貫して正しく予測する確率が上がります。
- 反復する - プロンプトの改良は反復的なプロセスであるため、下書きとそれに対応する結果の記録を保持しておくと、今後の調整や改良のための貴重な洞察が得られます。プロンプトの記述、テスト、編集というプロセスを目的の抽出が得られるまで繰り返します。
- 否定的な指示を避ける - 「ドキュメントのどのセクションも省略しないでください」のような指示を入力しないでください。代わりに、「X、Y、Z など、ドキュメントの主要なセクションがすべて網羅されていることを確認してください」のような指示に置き換えます。
- 言葉を繰り返さないようにする - 言葉を繰り返すと、重複や混乱を招き、モデルにとって不明確な指示になる可能性があります。
- 矛盾する情報がないか注意する - プロジェクト レベル、フィールド グループ レベル、およびフィールド レベルの指示が、抽出する情報、抽出の形式、情報がある場所の点で互いに矛盾していないことを確認します。矛盾があると、モデルが混乱し、一貫性のない結果が生じます。
- 例を追加して強化する - 可能な限り、正しい回答の例を追加してプロンプトの指示を強化します。このような例により、期待される結果へモデルをガイドすることができます。
| ベスト プラクティス | 詳細 | 重要度 | 正しい例 | 誤った例 |
|---|---|---|---|---|
| 業界とドキュメントの種類を定義する | 業界、および情報を抽出するドキュメントの種類について簡単に説明します。続いて、そのドキュメントの種類の主な特徴と予期される構造を指定し、抽出をガイドします。 | これにより、データ抽出プロセスに重要なコンテキストが提供されます。 | 指示: 金融サービス業界で一般的に見られる証券会社の明細書から情報を抽出します。証券取引明細書は通常、口座の概要、口座の概要、口座保有、口座取引活動のいくつかのセクションで構成されています。
|
指示: ドキュメントから以下のフィールドを抽出します。 説明: このプロジェクトの指示の例は、モデルにとって有益ではありません。モデルの指針となる重要なコンテキストや重要な特性は提供されません。 |
| 1 つのファイル内にドキュメントが複数回出現することが予想されるかどうかを指定する | ドキュメントに同一データの複数のインスタンスが含まれるかどうかを指定し、抽出インスタンスそれぞれに対してガイダンスを提供します。1 つのファイル内に複数のドキュメントが含まれる可能性があるユース ケースでは、一意の識別子を特定し、それを各フィールド グループにフィールドとして含めます。 | これにより後処理が容易になり、より効率的な自動化が可能になります。 | 指示: 1 つのドキュメント ファイル内に複数の証券会社の口座が存在する可能性があります。証券口座は、各フィールドグループに存在する一意の口座番号フィールドを介して識別できます。各取引先企業の取引先企業情報、保有口座、および取引先活動フィールド グループを抽出します。
|
指示: 各アカウント ドキュメントからデータのすべてのインスタンスを抽出します。
説明: この説明の例は、ファイル内にドキュメントの種類が複数回出現しているかどうかを判断する方法を指定していないため、不十分です。 |
| ベスト プラクティス | 詳細 | 重要度 | 正しい例 | 誤った例 |
|---|---|---|---|---|
| 一緒に抽出する類似のデータ ポイントをフィールド グループにグループ化する | 関連するフィールドを論理的なグループに整理します。 | これは、抽出の効率化とエラーの最小化に役立ちます。 | 口座所有者の名前、住所、婚姻状況はすべて、口座所有者情報フィールド グループの下にグループ化できます。 |
フィールド グループ: アカウント情報
フィールド: Account Holdings (口座保有)、Transaction Date (取引日)、Account Owner (口座所有者)
説明: このグループ化は、ユーザーがこれら 3 つのフィールドのみを抽出したい場合に機能します。ただし、保有ティッカーシンボルやコストベースなどの他のフィールドがある場合、このグループのデザインや構造は最も効果的ではありません。 |
| フィールド グループのコンテキスト | 各フィールド グループが文書の全体的な意味と目的にどのように寄与するかを説明します。 | これにより、モデルは抽出のコンテキストを理解できます。 | 指示:このセクションでは、株式名、購入日、購入数量、コストベース、支払総額など、主要な証券取引明細書の口座保有の詳細について説明します。これらの詳細は、証券取引明細書の現在の保有額を判断するのに役立ちます。 |
指示: ドキュメントから以下のフィールドを抽出します。
説明: プロンプトの指示には、モデルに対するコンテキストと詳細な指示が欠けています。抽出が必要な情報の種類についても説明されておらず、その重要性を強調しているわけでもありません。
|
| ドキュメント内の情報の場所と構造をフィールド グループのプロンプト内で活用する | 各フィールドのデータがあると考えられる場所 (表、ヘッダー、本文など) を指定し、抽出をガイドします。
注: 情報が同じセクション内に出現するドキュメントで作業している場合は、そのセクションをプロンプトで指定します。
| これにより、モデルは各フィールドに対して、ドキュメントの正確な部分に的を絞ることができます。 | 指示: このセクションのフィールド レベルのデータは、ほとんどの場合、レポートのヘッダーの最初のページのドキュメント タイトルの下にあります。 |
指示: ドキュメントの先頭から情報を抽出します。
説明: プロンプトが曖昧で、ドキュメント内の具体的にどこを確認すべきかについて十分な詳細をモデルに提供していません。 |
| フィールド グループとフィールドを使用して表をモデル化する | フィールド グループを表とみなします。各列はそのグループ内の一意のフィールドとして機能します。このアプローチは効果的なデータ モデリングの鍵となります。これによって、明確に区別できるほか、データの重複が最小限に抑えられ、データの一貫性が向上するためです。 | この方法を用いると、データを論理的に構造化して体系的に整理することができ、後でデータをクエリおよび分析する際の効率が向上します。 |
フィールド グループ: 顧客 フィールド: 名前、住所、電話番号 |
フィールド グループ: Customer Name (顧客名)、Customer Address (顧客の住所)、Customer Phone Number (顧客の電話番号) フィールド: 名前、住所、電話番号 説明: この例では、各顧客の詳細を不必要に独自のフィールド グループに分離しているため、データ管理が複雑になり、不整合が発生しやすくなります。 |
| 親フィールド グループと子フィールド グループを作成する | 大なり記号 > で関係を指定します。1 つの親フィールド グループが複数の子フィールド グループを持つことができます。
| フィールド グループを利用してドキュメント内のデータ間の関係を示すと、データの階層的な構成を効果的に維持できます。 |
項目グループ: 仲介方針 項目: Account Owner (取引先所有者)、Account Type (取引先種別) フィールドグループ名: Brokerage Statement > Asset Allocation (証券取引明細書資産配分) フィールド: アセットの種類 (例: 株式、債券、現金、総資産に対する割合) フィールドグループ名: Brokerage Statement > Investments フィールド: 投資名、所有数量、一株当たり価格、投資総額 |
フィールド グループ: アカウント所有者 項目: Name (名前)、Investment Name (投資名)、Type of Account (口座の種類)、Number of Share (株式数)、Stocks (株式)、Bonds (債券) フィールド グループ: アカウント所有者 > アドレス フィールド: 番地、市区町村、都道府県、郵便番号 フィールド グループ: アカウント所有者>連絡先情報 フィールド: Phone Number (電話番号)、Email (メール アドレス)
説明: この階層は、同じ親の下にある無関係なフィールドを結合しており、子フィールド グループ ([住所] と [連絡先情報]) が親のフィールド ([投資名]、[株式数]、[株式]、[債券]) と論理的に関連していないため、階層の構造が不十分です。これにより、ドキュメント内のデータの自然な構成が反映されないため、AI モデルが混乱する可能性があります。 |
| 複数のドキュメントを含むファイルに対して 1 つのキー フィールドを使用する | データを区別可能な、ドキュメント内の一意の識別子を選択します。このフィールドをすべてのフィールド グループに含めます。このフィールドに対する指示は、フィールド グループごとに変更する必要はありません。 | このキー フィールドを含めることにより、ドキュメント内の情報を分離することができ、抽出データを処理する際の混乱が解消されます。 | フィールド: 口座番号、社会保障番号、保険証券番号 |
フィールド: Date、Name 説明: リストされているフィールド名は一意ではないため、適切なキーフィールドにはなりません。日付と名前の両方を繰り返すことができます。 |
| ベスト プラクティス | 詳細 | 重要度 | 正しい例 | 誤った例 |
|---|---|---|---|---|
| フィールド名は慎重に選ぶ | フィールドには、ユーザーの期待に沿った明確でわかりやすい名前を選択します。ドキュメントのすべてのバリエーションで使用される共通の名前がある場合は、必ずその名前を含めてください。 | 正確なフィールド名を使用すると、正確な抽出が保証され、曖昧さが減ります。 | フィールド: Date of Accident |
フィールド: 日付
説明: 日付は一般的な用語であり、日付が何を指すかについてのコンテキストを提供しません。このため、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: アカウント残高を抽出します。 |
指示: 勘定科目番号、取引日付、勘定科目残高を一緒に抽出します。 説明: このプロンプトは、異なる種類のデータを同時に抽出するようモデルに指示する複数の命令で過負荷になっています。この方法では、抽出結果が煩雑になり、後処理が困難になる可能性があります。 |
| ベスト プラクティス | 詳細 | 重要度 | 正しい例 | 誤った例 |
|---|---|---|---|---|
| 目的を持ってデータ型を選択する | 抽出したデータをどのような形式にするかを検討し、データを下流のユース ケースに合致させて、抽出データを自動化用に最適化します。
| 適切なデータ型を選択すると、形式を正確に設定でき、下流での処理が容易になります。 |
フィールド名: Transaction Volume データ型: 数値 |
フィールド名: 電話番号 データ型: 数値 説明: 電話番号に Number データ型を使用しても有益ではありません。電話番号は数字で構成されていますが、数値ではないため、計算は行いません。数字の文字列として説明した方が適切です。したがって、Exact Text データ型を使用するのが適切な選択です。 |
| フィールドの種類には、そのフィールドの種類専用の指示のみを含める |
データ抽出の指示を入力する際は、常に指示を各フィールドの種類専用にすることが重要です。特定の種類のフィールドすべてに適用される全般的な指示がある場合、ユーザーはその指示をフィールドの種類レベルで入力して、繰り返しを避けることができます。たとえば、すべての金額フィールドを米ドルにする必要がある場合は、フィールドの種類レベルで指定します。
ただし、データセットによっては、既存のフィールドの種類 (日付、テキスト、金額など) でカバーされていない一意のフィールドが必要になる場合があります。このような場合は、カスタマイズされた新しいフィールドの種類を作成できます。これらの新しいフィールドに対する指示を記述するときは、データをどのような形式にする必要があるかを指定し、抽出データが意図した目的に合致するようにします。これらの手法により、抽出データの精度と一貫性が向上します。 |
フィールドの種類: 日付 指示: ドキュメントから取引に関連するすべての日付を抽出してください。日付は、
YYYY-MM-DD 形式で正規化する必要があります。 |
フィールドの種類: 金額 指示: 請求書明細項目の表の価格列から項目の価格を抽出してください。 説明: この指示は、特定のフィールド ([価格] 列) から金額を抽出することに特に関連しており、他の金額ベースのフィールドには関連していません。 |
- 抽出するすべての情報に対してフィールドを作成します。ただし、指示は含めません。
- 2 個から 3 個のドキュメントのサンプルを選択し、それぞれに対して予測を実行します。これらのドキュメントには、モデルを構築するドキュメントに存在するバリエーションが反映されている必要があります。
- モデルの抽出データを期待した内容と比較します。パフォーマンスが十分でなかったフィールドについては、前述のベスト プラクティスを使用してプロンプトの下書きを作成します。これはベースライン プロンプトとして機能します。
- 以前にテストしたものと同じ 2 個から 3 個のサンプル ドキュメントを使用して予測を再実行し、抽出のパフォーマンスが向上したかどうかを確認します。
- 予測が不正確または不完全な場合は、プロンプトを調整して必要な詳細情報を追加し、モデルの抽出パフォーマンスを向上させます。予測が期待と一致する場合は、ドキュメントのサンプル サイズを拡大します。サンプルの数は徐々に増やしていくことが重要です。2 から 3、さらに 10 に増やし、その後 20、30 というように増やしていきます。モデルの予測が正しいと確信できるまで、この作業を続けます。
- 指示を変更した場合は、以前に表示したドキュメントを再評価して、予測が依然として正確であることを確認します。
- モデルのパフォーマンスに満足したら、最初のドキュメントに戻ってアノテーションを開始します。[評価] タブで少なくとも 10 個のドキュメントのアノテーションを行い、フィールドのパフォーマンスに関する貴重なメトリックを取得します。この機能により、抽出のパフォーマンスを全体的なプロジェクト レベルとフィールド レベルの両方で評価できます。
- パフォーマンス メトリックを監視して、プロンプトの大規模な改良のための情報を提供します。プロンプトを反復するプロセスは、主にフィールド レベルで行う必要があります。こうすることで、パフォーマンスが良好でない特定のフィールドに調整の対象を絞って直接影響を及ぼすことができます。フィールド グループのスコアのパフォーマンスが良好でない場合は、プロジェクトとフィールド グループの指示を調整します。これらの指示は複数のフィールドに影響するため、影響が大きくなります。
