Kei Moriyama keimoriyama

• TorchHubなどにアップロードされているモデルカードから仮想APIの呼び出しコードを作成している
• このAPIについて指示をGPT-4を使用して生成している

• プロンプトに含まれているAPIのドキュメントが不正確である可能性がある
• 最初に、プロンプトに含まれているドキュメントが正確であるかを予測する
  • 学習データには、不正確なドキュメントを含めるように拡張している
• 正確ではない予測した場合、そのドキュンメントを使用して推論しないように学習を促す

• APIの引数には、必要ではないものが存在している
• そこで、構文木を作っておき、LLMの生成した呼び出しのコードが部分木であるかどうかを判定して評価している

• Few-shotに使用するRetrieverを変えても同様の結果になった

• LLMが与えられたドキュメントを判断した後に、プロンプトの文言を追加するという事なのか

• Llamaベースのモデルになると思うが、シンプルなSFTをした時との比較は無いのだろうか

• エンコーダの出力が、入力次元数よりも大きいAuto Encoderのこと

• 特徴量を見つけるために、F-Statisticを使用して次元削減をしているっぽい
• これ以外にも、学習した線形モデル（Probe）の次元削減をするための工夫がある

• ポジティブとネガティブに分類されたデータからSAEが抽出した特徴量に介入する
• この介入後の特徴量が、ポジティブなデータとネガティブなデータの特徴量のセントロイドに近くなるように学習する
• 加えて、言語モデル自体の損失関数や介入ベクトルに対するL1損失を制約として使用している

性能的には、既存の介入手法よりも良いスコアになっている

SAEにより抽出された特徴量が良くクラスを分類できる特徴量になっていることが分かった

• SAEによる特徴量の抽出を用いた介入の有効性を示している

Ablation Studyにより損失関数の必要性が示されている

• Probeの学習を行わないと、出力文章の整合性や論理性が無くなる

• 言語モデルの損失を無くすと、ベースになる言語モデルの応答を保持することが難しくなる

介入の方向については提案手法で良い方向を見つけることができたが、大きさについては未知である

• 生成された文章が対象の文章を適切に反映できているのかを評価させている

• Ablation Studyに一応あった

• 例えば、学習データ内で使用されているAPIが一部のカテゴリに偏っている場合、そのデータで学習されたLLMエージェントは他のAPIからのデータの取得ができなくなるという課題がある。

1. 既存のAPIを用いたQAペアをJSON形式に変する。
2. プロンプトはデータ生成の目的になるテンプレートを選択し、QAペアを生成させる
3. 生成されたペアをJSON形式に変換する

1. フォーマットの検証：生成されたJSONのフォーマットが正しいか、APIの呼び出し時に適切な引数を指定しているか検証する
2. 実行可能性の検証：データに含まれたAPIが実行可能であるか検証する、実行可能ではない場合、フィルターする
3. 文法の検証：複数のLLMを用いて、目的を達成するための関数を呼び出すことができるかなどを総合的に評価する

ToolBenchを基データとして生成を行った

• 基データとして活用するために、いくつかのフィルターを適用したの3500件を使用している

生成パイプラインを様々なLLMを用いて検証した所、小規模なモデルは無効なAPIを呼び出る例が多い

学習したモデルの評価はBerkley Function-Callingデータセットを使用している

FCのために学習されたLLMはGPT-4oなどよりも良い性能を示している

• 学習に使用しているLLMは1Bと7Bのモデルなので、より小規模なパラメータになっているかも？

各フィルタリングステップにおいて、フィルター後のデータを用いてモデルを学習し、評価した

• 上の説明において、フォーマットの検証のみを適用したデータ、1と2を適用したデータ、全てを適用したデータに分けている
• 評価結果としては、全てを適用したデータにより学習されたLLMの性能が最も良かった
• このことから、提案したフィルター方法の有効性が分かる

• プロンプトのテンプレやデータの持ってき方の工夫で十分なのかな