なぜ小規模なローカルモデルはJSON出力時により多くの幻覚を起こすのか？

小型のローカルモデルは、JSONを出力する際に、厳格なスキーマと有効な構文を維持しながらタスクも解決しなければならないため、ハルシネーションが起こりやすくなります。

ホームAIワークフローでは、コンパクトなモデルにファイル名、日付、タグ、デバイスの状態、オートメーションの引数などを抽出させ、機械可読なJSONとして返させることがあります。モデルが行う仕事は1つではありません。正しい事実を特定し、意図されたフィールドに割り当て、指定された型や列挙値を守り、句読点や入れ子構造を維持し、コメントを追加せずに終了する必要があります。モデルの処理能力が限られている場合、これらの制約が、値を根拠に基づいたものに保つために必要な推論能力と競合します。

JSONによって正確性は二層の問題になる

回答は、意味的に正確であると同時に、構造的にも有効でなければなりません。自由形式の回答なら、不確実性を表現したり、値が不足している理由を説明したりできます。一方、JSONの契約では、証拠が弱い場合でもモデルにフィールド値の選択を求めることがよくあります。

有効性と正確性のトレードオフに関する研究が示すように、これらの指標は分けて扱う必要があります。出力制約を強化するとスキーマの有効性は向上しますが、選択された値の正確性が低下する場合があります。

小型のローカルモデルでは、指示の追跡、情報抽出、シリアライズに割ける余力が少ないため、この負荷がより明確に現れます。大規模モデルでもフィールドを創作することはありますが、コンパクトなモデルでは、形式の遵守が回答品質を圧迫する段階に早く到達します。

有効なオブジェクトでも、回答がハルシネーションである可能性はある

制約付きデコーディングは、不正な中括弧、未知のキー、無効な列挙値が出力されるのを防げます。しかし、選択された顧客ID、日付、パス、ステータスが情報源に存在することまでは証明できません。

vLLMは、JSONスキーマ制約を、生成される出力の形式を制限する方法として説明しています。デコーダーは次に選べるトークンを絞り込みますが、それらの合法的なトークンが持つ意味は、依然としてモデルが提供します。

これはオートメーションにとって危険な失敗パターンを生みます。オブジェクトは正常に解析できるため後続のコードは信頼しますが、1つのフィールドが捏造されている可能性があります。解析に成功したことを事実の正確性とみなすのではなく、スキーマ検証後にビジネスルールと情報源の証拠を検証してください。

ネストされたスキーマは分岐と状態追跡を増やす

必須プロパティ、任意の分岐、ネストされた配列、null許容フィールド、列挙値が増えるたびに、モデルが生成中に追跡しなければならない状態も増えます。似たキー名や繰り返されるオブジェクト構造があると、正しい値を誤った場所に配置しやすくなります。

llama.cppの文法制約付きJSONのガイドでは、許可される出力文法と、フィールドの意味を説明するプロンプトを区別しています。文法によって構造は強制できますが、スキーマには明確な意味上の指示も必要です。

同時に行う判断の数を減らしましょう。深くネストされたオブジェクトを平坦化し、使用していない任意フィールドを削除し、区別しやすいキー名を使い、ローカルモデルが関係のないフィールドを繰り返し入れ替えたり埋めたりする場合は、大規模な抽出を小さなオブジェクトに分割してください。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

JSONのみを求めるプロンプトは、有用な推論を抑制する可能性がある

「JSONのみを返す」という厳格な指示は、モデルにすぐ回答をまとめるよう促します。難しい抽出では、競合する箇所を比較したり、曖昧な日付を解決したりする前に、フィールド値を早々に選択してしまう可能性があります。

Hugging Faceの評価では、プロンプト形式への感度が示されています。期待される構造や推論に使える余地を変えるだけで、同じ質問でもタスクの性能が変化する可能性があります。

プライベートな思考の連鎖を公開する必要はありませんが、内部でのタスク解決と最終的なシリアライズは分けてください。ワークフローではまず、簡潔な証拠レコードを抽出するか、決定的な検索を実行し、その後、検証済みのフィールドだけをモデルに出力させます。

プロンプトによるJSONと制約付きデコーディングは異なる形で失敗する

プロンプトだけでJSONを求めると、コードフェンス、コメント、重複キー、末尾のカンマ、未完了のオブジェクトが追加されることがあります。制約付きデコーディングは多くの構文エラーを排除しますが、「不明」が許可されていない場合、モデルに有効な値の中から選択させてしまう可能性があります。

Fireworksは、スキーマで制限されたトークンの選択肢によって生成を出力契約の範囲内に保ちながら、意図されたデータを正確に説明するプロンプトも必要になることを解説しています。

両方の失敗群を追跡してください。プロンプトだけの出力では解析失敗を測定し、制約付きデコーディングを有効にした後は、誤っているものの有効なフィールド、望ましくないデフォルト値、根拠のない確信を測定します。

サンプリングと切り詰めは小さな誤りを増幅する

温度を高くするとキーの選択やフィールド値が変化しやすくなり、トークン予算が不足すると配列や閉じ中括弧が途中で切れる可能性があります。温度を低くすれば変動は抑えられますが、根拠のない値が真実になるわけではありません。

ローカル構造化出力パイプラインの実践的なレビューでは、検証と制約付き生成が、単一のプロンプト技法ではなく別々のコンポーネントである理由が示されています。

最大サイズの有効なオブジェクトを出力できるだけのトークンを確保し、配列の長さに上限を設け、失敗した部分だけを再試行してください。オブジェクト全体を再生成すると、すでに正しかったフィールドが新たなハルシネーションで置き換えられる可能性があります。

二段階のローカルJSONパイプラインを使う

まず、タスクを最小限の型付きレコードに変換します。そこには、正確な情報源の範囲、正規化された日付、選択された識別子、信頼度の状態、明示的に不足している値を含めます。この段階では、必須データが不足している場合に創作するのではなく、リクエストを拒否できるようにします。

次に、そのレコードをスキーマ制約付きデコーダーで出力し、解析したうえで、ファイルの存在、日付範囲、列挙値との互換性、フィールド間の整合性などを意味的に検証します。バリデーターは、修正すべきフィールドを特定する、対象を絞ったエラーを返すべきです。

ZimaSpaceによる小型モデルのほうが信頼性を高められる理由の解説は、その境界を示しています。コンパクトなモデルは、タスク、コンテキスト、ツール群、出力契約を検証できるほど限定した場合に最も効果を発揮します。

よくある質問

有効なJSONなら、モデルはハルシネーションを起こしていないということですか？

いいえ。有効なJSONであることは、オブジェクトが構文またはスキーマの規則に従っていることを示すだけです。フィールド値が情報源から取得されたものか、実際のシステム状態と一致するかまでは証明しません。

温度を0に設定すればJSONのハルシネーションは解決しますか？

いいえ。出力をより再現しやすくすることはできますが、根拠のない値が一貫して選択されるなら、それもハルシネーションです。

オートメーションには制約付きデコーディングだけで十分ですか？

いいえ。情報源に基づく抽出、スキーマ解析、意味的検証、不足または曖昧なデータを安全に拒否する経路と組み合わせて使用してください。