シミュレーションエンジン

タスクから、追跡可能なエージェントの実行過程へ#

エージェントがつまずく原因が、プロダクトの選択、操作の呼び出し、返されたデータの利用のどこにあるのかを切り分けます。エンジンが各段階の動作を記録するため、どの説明やインターフェースを直すべきかを具体的に検討できます。

Floviaのシミュレーションエンジンは、評価計画を個別に識別できる実行単位へ展開します。各実行には、タスク、モデル、候補の提示条件、実行経路、反復、入力のバージョンが結び付きます。段階別評価ではPromptCaseを使います。これは、許可する操作、引数の期待値、結果に必要なフィールド、完了基準まで含むタスク定義です。

エンジンは、判断と検証を分けることで、エージェントの実行過程を観測できるようにします。モデル呼び出しからは候補の選択、ツール呼び出し、回答が得られます。決定的なチェックでは、ツールの識別、引数、結果の構造を検証します。別途設定するモデル補助のJudgeが、タスクの評価基準に照らして最終回答を判定します。

モデル呼び出しの流れ#

モデルの判断を段階ごとに確認し、次へ進む条件を満たしているかを検証します。条件を満たさない場合はそこで実行を止め、失敗した箇所とその根拠を記録します。

モデル呼び出しとツール実行は別の経路#

PromptCaseのLive LLM / Mock Tool経路では、指定したモデルのエンドポイントを実際に呼び出し、対象ツールの実行には、fixtureと呼ぶバージョン管理された準備済み応答を使います。応答環境を一定に保つことで、エージェントの判断、呼び出し、返されたデータに基づく回答がどう変化するかに焦点を当てられます。

operation bindingは、選択したツールと引数をリクエスト仕様に対応付けます。fixture adapterはリクエストの表現をローカルで組み立て、ツールと引数の条件に合う応答を返します。そのリクエストを対象プロバイダーへ送信することはありません。この仕組みにより、安定したツール環境で、呼び出しの誤りや結果に基づかない回答を調べられます。

入力のバージョン管理による再現性#

PromptCase、ツールカタログ、operation binding、fixture、採点プロンプトは、バージョンまたはハッシュで管理します。実行前にはそれぞれの整合性を検証します。期待するツールがカタログに存在するか、引数の意味的な期待値を解決できるか、必要な結果の事実に検証仕様があるかを確認します。

各実行には識別情報、段階別の記録、エラー、採点の来歴を保持します。並列数の制限、チェックポイント、再開機能により、個々の観測を保持しながら、定義した実行集合を処理します。ここでいう再現性は、条件を追跡でき、同じ手順を繰り返せることです。後日同じモデルのエンドポイントを呼び出しても、回答が異なる可能性はあります。

評価範囲と比較条件を設計する#

Floviaは、利用目的、ペルソナ、モデル、候補の提示条件を実験要因として扱います。調べたい動作に合わせて評価ケースを構成し、比較する条件と固定する条件を明確にします。

• シナリオ行列：目的とペルソナを組み合わせて診断し、モデル別・目的別の結果を比較します。どの条件で選択されにくくなるかを調べ、次に検証する説明や使用例を選びます。
• 候補位置の均衡化：対応する比較実験では、循環ラテン方格で候補の順序を入れ替えます。各候補が各位置に現れるようにし、同じ順序の中で変更前後を比較します。
• ツール応答の固定：バージョン管理したfixtureを使い、同じタスクに対して返すデータを揃えます。応答データの変動を抑え、説明文やツール情報の変更が判断・呼び出し・回答にどう影響するかを調べます。