AI面接問題二：大規模言語モデル(LLM)がツールを確実に呼び出す方法

大規模言語モデル（LLM）がツール呼び出し時に確実かつ制御可能に動作するようにするには、単にプロンプトでモデルを「説得」するだけでは不十分です。システム的に多層的な制約フレームワークを提供する必要があります。

例えば天気を問い合わせる例で、モデルがツール呼び出しでよく見られる3つの「でっち上げ」動作：
1. ツールを呼び出さず、直接架空の答えを生成する。
2. ツール呼び出し時に形式が間違ったパラメータを渡す（例：ツールが「明後日」をサポートしていないのに、date="明後日"と渡す）。
3. 勝手にパラメータ形式を変換する（例：勝手に「明後日」を具体的な日付に変換する）、ツールがその要求をしていない場合でも。

問題の根源は、モデルの出力が本質的に確率的であり、プロンプトは確率分布に「ソフトな制約」を課すだけで、モデルが厳密に従うことを保証する強制メカニズムではないことです。複雑なシナリオでは、この「ソフトな制約」は簡単に機能しなくなります。

この問題を解決するには、多層的な工学的解決策が必要です：

1. 第一層：プロンプトの最適化（ソフトな制約）

   • 位置づけは制約体系の出発点ですが、決して終点ではありません。
   • プロンプトを「操作契約」と見なし、ツールの用途、各パラメータの型、境界を明確に説明し、不正な値の例を列挙します。
   • Few-shot例を追加し、「正しい入力→正しい呼び出し」の例を示すことで、文脈学習を利用してモデルの行動パターンを固定します。

2. 第二層：JSON Schemaの導入（ハードな制約）

   • これは「理屈を言う」から「柵を設ける」への重要なステップです。
   • 自然言語によるパラメータ記述を、機械可読で検証可能な構造化定義（JSON Schema）に置き換えます。フィールドの型、必須かどうか、列挙値の範囲を厳密に定義でき、additionalProperties: falseを設定することでモデルが未定義のフィールドを出力するのを禁止できます。
   • 主要なAPIプラットフォームは、モデルのデコード段階でこのような構造化出力制約をサポートしており、生成の根源から形式違反を防ぎます。

3. 第三層：検証・修正・再試行のループ（実行のセーフティネット）

   • Schemaがあっても、モデルの出力を受け取った後に構文とSchemaの検証を行う必要があります。
   • 検証に失敗した場合、自動クリーニングと再試行メカニズム（上限あり）を設計し、エラー情報をモデルにフィードバックして出力を修正させます。再試行回数を超えた場合は、フォールバックまたは手動処理の計画が必要です。

4. アーキテクチャレベル：責務の分離

   • 決定と実行を分離し、3層アーキテクチャを形成します：
     • モデル層：決定のみを担当（どのツールを呼び出すか、どのパラメータを生成するかを判断）。
     • フレームワーク層：実行フレームワークを担当。Schema検証、ツール呼び出し、再試行処理、結果の統合を含む。これにより、モデルのエラーがツールの安全性に直接影響せず、ツールの変更に伴うプロンプトの頻繁な調整も不要になります。
     • ツール層：具体的なビジネス機能の実装。
   • LangChain、LlamaIndexなどのフレームワークはまさにこのような作業を行っています。

現在の解決策の限界：パラメータ形式の問題はうまく処理できますが、パラメータの意味（例：「上海」と「沪」の等価性）の検証カバレッジはまだ不十分です。これは将来直面する工学的課題です。

核心的な結論：LLMにツールを確実に呼び出させることは、本質的にソフトウェア工学の問題であり、ソフトな制約、ハードな制約、実行のセーフティネット、アーキテクチャ設計に至る体系的な工学的解決策を構築する必要があり、単にプロンプトの最適化に依存するだけでは不十分です。