検証ルール - Entity Enricher ドキュメント

検証ルール

8 つの検証ルールが schema の品質を保証します。AI による schema 生成中にいずれかのルールが失敗すると、エラーが AI に返送され、自動的に自己修正されます。

自己修正の仕組み

AIがスキーマを生成すると、8つの検証ルールすべてを通過します。いずれかのルールが失敗すると、具体的なエラーメッセージがまとめられ、フィードバックとしてAIに送り返されます。次にAIは修正されたスキーマを生成し、再び検証されます。このループは合計最大6回(初回1回+リトライ5回)まで続きます。

修正フロー

AIが生成しますプロパティ、型、専門知識、説明を含むスキーマ
バリデーターチェック8つのルールを順次適用し、すべてのエラーを収集します
エラーが発生した場合送り返されるエラーメッセージ:「これらの問題を修正してください: [revenue: 型の不一致...]」
AIが修正報告されたエラーに対応した更新済みschemaを生成します
繰り返しすべてのルールが合格するか、最大試行回数に達するまで

実際には、ほとんどのスキーマは最初の試行で通過します。自己修正ループは、AIがタイプエラーを起こしたりフィールドを忘れたりするエッジケースを処理するセーフティネットです。

生成と編集のルール

すべてのルールがschema生成とAI編集の両方に適用されるわけではありません。入力データと比較するルールは、意図的にフィールドを追加・削除する場合があるため、編集時にはスキップされます:

スコープ適用されたルール理由
生成8つのルールすべて比較用の入力データが利用可能です
AI編集ルール2・3・4・5のみ入力データがありません。ユーザーが意図的に構造を変更する可能性があります

8つのルール

ルール 1

専門知識ドメインの数

スコープ: 生成のみ

専門ドメインの数は、プロパティ数に基づいて計算された最大値を超えることはできません。これにより、小さなスキーマに対して AI が細かすぎるドメインを作りすぎることを防ぎます。

エラーの例: Too many expertise domains: 6 defined, maximum is 3

最大値は floor(property_count / 6) で計算され、最小値は 1 です。12 個のプロパティを持つスキーマでは最大 2 つのドメインが許可されます。

ルール 2

少なくとも1つのプロパティ

スコープ: 両方

すべてのスキーマは、少なくとも1つのプロパティを定義する必要があります。空のスキーマはエンリッチメントに使用できません。

エラーの例: Schema must have at least one property

これにより、AIが有効なJSON構造を生成したものの、実際のフィールドを一切含め忘れるケースを検出します。

ルール 3

有効なJSON Schemaタイプ

スコープ: 両方

すべてのプロパティタイプは、標準のJSONスキーマタイプ(string、number、integer、boolean、array、object、null)のいずれかである必要があります。

エラーの例: revenue: invalid type 'float'

AIは「float」「decimal」「date」などの型を勝手に作り出すことがあります。このルールはそれらを検出し、有効な型への修正を求めます。

ルール 4

$ref ターゲットの存在

スコープ: 両方

すべての$ref参照は、スキーマの$defsセクションで定義されたエンティティを指す必要があります。参照が解決できないと、エンリッチメントパイプラインが壊れます。

エラーの例: manufacturer: $ref '#/$defs/Company' references undefined definition

AI が #/$defs/Company のような参照を作成した場合、$defs ブロック内に対応する Company の定義が存在する必要があります。

ルール 5

専門知識キーが存在します

スコープ: 両方

すべてのプロパティのexpertise値は、定義された専門領域のいずれかと一致する必要があります。これにより、タイプミスや不整合を防ぎます。

エラーの例: revenue: expertise 'finance' not in defined domains: ['financial_analyst']

AIは、定義された「financial_analyst」キーの代わりに「finance」を使用する場合があります。このルールはその不一致を検出し、AIが修正できるようにします。

ルール 6

専門知識が必要です

スコープ: 生成のみ

オブジェクトでもなく保持もされないプロパティには、expertise domainの割り当てが必要です。これにより、enrichment可能なすべてのフィールドが専門のドメインで処理されることが保証されます。

エラーの例: revenue: expertise is required for non-object types

オブジェクト型は、その子プロパティが独自のexpertise domainを持つため除外されます。保持されるフィールドは変更されずに通過するため除外されます。

ルール 7

型が入力データと一致

スコープ: 生成のみ

各プロパティの schema 型は、入力データ内の対応する値の実際の Python 型と一致している必要があります。

エラーの例: revenue: type mismatch - input is number but schema says 'string'

入力に "revenue": 42.5 が含まれる場合、スキーマは "string" ではなく "number" または "integer" タイプを使用する必要があります。バリデーターは柔軟で、整数に対して "number" を受け入れ、その逆も同様です。

ルール 8

すべての入力プロパティが存在

スコープ: 生成のみ

入力データのすべてのキーは、生成されるスキーマ内のプロパティとして表示される必要があります。これにより、AIがフィールドを無言で削除することを防ぎます。

エラーの例: Missing property from input: 'headquarters'

入力JSONに "headquarters" キーが含まれる場合、生成されるスキーマにはそれを含める必要があります。これにより、データの完全な網羅が保証されます。

型推論

ルール7(型マッチング)は、自動型推論を使用して入力値をスキーマで宣言された型と比較します。誤検知を避けるため、推論は柔軟に行われます:

入力値推定された型その他に受け付ける値
true / falseboolean(ブール値のみ)
42integernumber
3.14numberinteger
"hello"string(文字列のみ)
[1, 2, 3]array(配列のみ)
{"key": "val"}object(オブジェクトのみ)

注意:一部の言語ではブール値が整数のサブタイプであるため、ブール値は整数よりも先にチェックされます。この順序により、trueが整数として推論されるのを防ぎます。

次のステップ