カスタム生成モデルV2.0の作成(新規)
OCI Document Serviceは、LMM(Large Multimodal Models)を活用したKey-Value Extractionを備えており、従来のモデル駆動方式よりも高い精度と適応性を実現しています。
情報
OCI Document Serviceのキーバリュー抽出では、マルチモーダル推論を使用してテキスト・コンテンツとビジュアル・レイアウトの両方を分析し、さまざまな形式、テンプレート、構造を持つドキュメントの処理に非常に効果的です。抽出に必要なキー(フィールド)の概要を示すスキーマを提供して、モデルを再トレーニングすることなく、様々なドキュメント・タイプにまたがってサービスを適応させることができます。
この大規模なマルチモーダル・モデル(LMM)を利用したアプローチは、レイアウトの不整合、不規則なラベル付け、またはトレーニング・データの不足などの状況で、従来のテンプレートやモデルベースのソリューションで継続的な更新や維持が必要になることがよくあります。
使用可能なリージョン
次のOCIリージョンで、Generative Large Multimodal Model (LMM)ベースのKey-Value抽出用のカスタム・モデルを作成できます:
| 地域名 | 場所 | リージョン識別子 | リージョン・キー |
|---|---|---|---|
| ブラジル東部(サンパウロ) | サンパウロ |
sa-saopaulo-1
|
GRU
|
| 日本中央部(大阪) | 大阪 |
ap-osaka-1
|
KIX
|
| 英国南部(ロンドン) | ロンドン |
uk-london-1
|
LHR
|
| 米国中西部(シカゴ) | シカゴ |
us-chicago-1
|
ORD
|
リージョンおよび可用性ドメインについてについて学習します。
権限の追加
IAMポリシーを使用して権限を追加します:
キーおよび値用のJSONファイルの作成
生成抽出では、スキーマを定義して抽出する情報を指定します。スキーマは、対象のキー(フィールド)とその予想される値を説明する一連の命令として機能します。モデルは、これらの指示に基づいて、ドキュメント全体の値を詳細とともに識別および抽出します。
キー値抽出用のJSONファイルの例を次に示します:
[
{
"key": "InvoiceId",
"dataType": "String",
"description": "A unique alphanumeric identifier assigned to the invoice. Usually labelled Invoice No., Inv #,
Bill Number and appears near the top of the invoice, often right after the text label."
},
{
"key": "InvoiceDate",
"description": "Date the invoice was issued. Common formats include DD-MM-YYYY or MM/DD/YYYY."
},
{
"key": "DueDate",
"description": ""
},
{
"key": "PurchaseOrder",
"description": ""
},
{
"key": "InvoiceTotal",
"description": "Total amount due. Exclude subtotals, taxes, and discounts.
Look for labels such as Grand Total, Amount Payable, or Balance Due near the bottom of the document."
},
{
"key": "TotalTax",
"description": ""
},
{
"key": "SubTotal",
"description": ""
},
{
"key": "AmountDue",
"description": ""
},
{
"key": "PreviousUnpaidBalance",
"description": ""
}
]システム・キーとカスタム・キーの使用
ドキュメント理解には、事前定義されたシステム キーのセットが用意されています。これらのキーは、様々なドキュメント・タイプおよびレイアウトで機能するようにチューニングされています。これらのキーはそのまま再利用することも、その説明を変更することもできます。
システム提供のキーで開始
まず、事前定義済のシステム キー定義を使用して、記入票の代表的なサンプルでパフォーマンスを評価します。システム提供のキーのリストは、キーと値の抽出を参照してください。
- 結果が要件を満たしている場合は、システム提供のキーを再利用します。
- これらのキーの説明を追加する必要はありません。
必要に応じてキーの説明をカスタマイズします。
システム提供のキーが要件に適合しない場合は、ドキュメントに基づいてカスタムの説明を定義します。
-
ドキュメント固有の用語、レイアウトおよび書式設定パターンに合せて説明を調整します。
-
説明については、Best Practices for Custom Descriptionsに従ってください。
カスタム説明のベスト・プラクティス
主要な説明を記述する例を示すいくつかのベスト・プラクティスを次に示します。
明確かつ明確であること
異なる数値識別子など、類似しているように見える可能性のあるフィールドを明確に区別します。
例
"key": "Invoice number"
"description": "A unique alphanumeric identifier assigned to the invoice.
Usually labeled Invoice No., Inv #, Bill Number and appears near the top of the invoice,
often right after the text label." コンテキストおよびラベルのバリエーションの説明
生成モデルは、周囲のテキストとラベルに大きく依存します。一般的なラベル・バリアントを含めます。
例
"key": "Company GST Number" "description": "Company GST number,
often labeled as GSTIN, GST No., or Tax ID. Usually appears
in the header with other business identifiers."期待値書式の指定
フィールドが既知の形式に従っている場合は、明示的に指定します。
例
"key": "Invoice Date" "description": "Date the invoice was issued.
Common formats include DD-MM-YYYY or MM/DD/YYYY."除外する対象を明確化
抽出したくない類似フィールドを明示的に識別します。
例
"key": "Total Amount" "description": "Total amount due.
Exclude subtotals, taxes, and discounts.
Look for labels such as Grand Total, Amount Payable, or Balance Due near the bottom of the document."シノニムとラベルのバリエーションを含める
異なるラベルを指定して、ドキュメント・バリアント間の堅牢性を向上させます。
例
"key": "Customer Phone Number" "description": "Customer phone number.
A 10-digit numeric value labeled as Phone, Tel, Contact, or Mobile, typically adjacent to the
customer name or address."参照ロケーション・ヒントの追加
文書が一貫したレイアウトに従っている場合は、相対的な位置合図を含めます。
例
"key": "Supplier Address" "description": "Supplier address
located under the business name in the top-left area of the first page." 役立つ例を含む
具体的な例は抽出精度を向上させます。
例
"key": "Invoice Date" "description": "Invoice date,
for example 24-12-2025 or Dec 24, 2025.
Usually follows labels such as Date or Invoice Date."簡潔で正確であること
重要な制約または例を補足する明確な記述文を1つ優先します。
フォールバック動作の定義
該当する場合は、プライマリ・ラベルがない場合に値を推測する方法を指定します。
例:
請求書合計が欠落している場合は、かわりに未払額合計を使用します。
セクション認識を明示的にエンコードする
複数セクション・ドキュメント(フォームなど)の場合は、セクション・コンテキストとフィールド順序を指定します。
例
"key": "First Name" "description": "Person’s given name.
Appears under the Personal Information or Applicant Details section header.
Usually the first field in the section and appears before Last Name.
Might contain multiple words (for example, MaryAnn)."複数語および複数行の値の処理
該当する場合は、マルチトークンまたはマルチライン抽出を明示的に許可します。
例
"key": "Address" "description": "Full residential address.
May span multiple consecutive lines within the same section.
Extract all adjacent address lines as a single value."ネガティブ・ガイダンスを使用した誤検出の回避
値を抽出しない明示的な状態。
例
"key": "Applicant Name" "description": "Applicant name.
Do not extract names appearing in signature blocks, declaration sections,
or references to officials or witnesses."明示的なラベルがないフィールドの処理
暗黙フィールドの場合は、セマンティック・ロールおよびレイアウト・キューに依存します。
-
セクション・ヘッダーに対する相対位置
-
近くのフィールド間の順序付け
-
関連ラベルへの近接性
フレーズの例
- 次の直後に表示されます...
- 隣…
- セクションヘッダーに従います...
カスタム生成モデルの作成
生成AIを使用してキー値抽出用のカスタム・モデルを作成するには、次のステップに従います。
データの選択
Document Understandingを使用してキー値(KV)カスタム生成モデルを作成します。
モデルのトレーニング
レビュー
- 前のステップで指定した情報を確認します。「前へ」または「編集」を選択して、変更を加えることができます。
- 選択内容に問題がない場合は、「作成およびトレーニング」を選択します。
モデルのテスト
- カスタム・モデルが作成されたら、モデル詳細ページで「分析」セクションにナビゲートします。
- ローカル・ファイルまたはオブジェクト・ストレージからドキュメントをアップロードして、カスタム・モデルをテストします。
- 「分析」を選択します。
- キーとその抽出値をレビューします。
- たとえば、キーの追加や説明の更新など、結果に満足できない場合は、JSONファイルを更新し、前のステップを繰り返します。