Hallucination

DeFi Agentシナリオでのハルシネーションの最も一般的な現れ方は何ですか？

DeFi Agentの実際の運用では、ハルシネーションには4つの最も一般的な現れ方があります：

感知欠如型ハルシネーション（最も一般的）：ツール呼び出しが失敗し（APIタイムアウト・接続切れ）、AgentがAPYデータを受け取れなかったのに、LLMのThoughtステップで訓練データの歴史的印象からのAPY数値を引用します。識別：Thoughtログにツール呼び出しログに存在しない数値が引用されている。

針穴の中の針型ハルシネーション：ContextWindowが長いとき、LLMはContextの中間部分への注意力が最も弱く、数ループ前の古い数字を使う可能性があります。識別：ツールが正しいデータを返したが、Thoughtが異なる数値を引用している。

解析混同型ハルシネーション：ツールが複数の資産を含む複雑なJSONを返し、LLMがETHのAPYをUSDCのAPYとして誤って引用します。識別：引用された数値は存在するが、誤った資産に帰属している。

Prompt Injection誘発型：攻撃者がツール返却データに偽の数値を埋め込み、LLMに特定プロトコルのAPYが実際より高いと信じさせます。識別：ツールの生のJSONに異常なフォーマットや無関係なテキストが含まれている。

設計レベルでAgentのハルシネーションを減らすにはどうすればいいですか？直接実装できる防御策はありますか？

ハルシネーション防御は複数のレベルで同時に設計する必要があります：

System Promptのグラウンディングルール（最高優先度）：System Promptに明示的に規定します：具体的な数値に関わるすべての推論はツール返却データを引用し、データソースを述べなければならない；必要なツール呼び出しが失敗した場合は、さらなる推論を禁止してThoughtステップで「Xデータが不足、今回の推論サイクルを中止」と宣言しなければならない。

バックエンドの数値整合性検証：各LLM出力後・ツール実行前に、ThoughtのN引用数値を解析してツールログの実際の返却と比較します。偏差が5%を超える場合はアラートを発してツール呼び出しの実行を拒否します。これは純粋なコードレベルの後処理でLLMの遵守に依存しません。

ツール返却値の合理性フィルタリング：ツール関数で返却値を合理的な範囲で検証します——ステーブルコインAPYが30%超・Gas費が1,000 Gwei超は異常とみなし、LLM Contextに入れず最後の有効なキャッシュ値を使用します。

重要データをContextの末尾に配置：「最も重要な現在のデータ」をContextの最後の数行に配置し（中間ではなく）、LLMのContextの末尾への注意力が強い特性を活用します。

複数ソースのクロス検証：リバランスをトリガーしようとするAPY数値については、少なくとも2つの独立したデータソースから取得し、中央値を取ります；いずれかのソースが中央値から15%以上乖離している場合はアラートを発し操作を停止します。

ハルシネーションとPrompt Injectionの違いは何ですか？ログからどちらの問題かをどのように判断しますか？

ハルシネーションとPrompt InjectionはどちらもAgentに不正確な動作をさせますが、メカニズムが異なりログでの現れ方も異なります：

ハルシネーション：LLMが不完全または欠如した情報に基づいて、もっともらしく聞こえる答えを「創造」します。根本原因はAgentシステム内部にあります。ログの特徴：Thoughtがツールログに存在しない数値を引用している（感知欠如型）、またはThoughtが引用する数値はツールログに存在するが異なる資産または時点のもの（解析混同型）。

Prompt Injection：外部攻撃者がAgentの入力（ツール返却データ・ユーザーの指示・またはスクレイピングされたウェブコンテンツ）を汚染して悪意ある命令を注入し、LLMに偽のタスク目標を信じさせます。ログの特徴：Thoughtに元のタスク目標と全く無関係の命令が含まれている、またはValidation Logに大量の「BLOCKED: address not in whitelist」がある。

判断方法：まずThoughtログを見ます——Thoughtの推論ロジックが元のタスクと一致していて誤った数値を引用しているだけなら、ハルシネーションに傾きます；Thoughtの推論目標が変わっているなら（「収益の最適化」から「戦略にない操作の実行」へ）、Prompt Injectionの可能性が高くなります。次にThoughtの数値とツールログを比較します——ツール返却に数値が存在しなければハルシネーション；数値は存在するがターゲットアドレスやプロトコルがホワイトリストにない場合はPrompt Injectionを示します。

小型LLM（Claude Haikuなど）は大型モデルよりもハルシネーション率が大幅に高いですか？モデル選択時にハルシネーションリスクをどのように考慮しますか？

オンチェーンAgentの実際のデプロイ経験から、異なるサイズのLLMにはハルシネーション率に顕著な違いがありますが、この違いは主に「グラウンディングハルシネーション」に現れます。

グラウンディングハルシネーションとは：Contextにすでに正しいツール返却データがあるのに、LLMがそれを無視して訓練記憶の古い数字を使うことです。これはDeFi Agentシナリオで最も危険なハルシネーションタイプです。実際のテスト結果から：Claude Opus 4は明確なツールデータがある場合のグラウンディングハルシネーション率が最も低い；Claude Sonnetは中程度の性能；Claude HaikuやGPT-4o miniなどの小型モデルのグラウンディングハルシネーション率は大型モデルより著しく高く、明確なツールデータがあっても訓練記憶の異なる数字を頻繁に引用します。

強力なグラウンディングルールとバックエンドの数値整合性検証を組み合わせれば、Claude SonnetでもDeFi Agentシナリオで十分に低いグラウンディングハルシネーション率を達成できます。小型モデルは読み取りやフォーマットなどの低複雑度のサブAgentタスクに適していますが、複数の数値の比較推論とオンチェーン操作のトリガーが必要なコアOrchestratorレイヤーには推奨しません。