Kei Moriyama keimoriyama

📄論文情報

• ToolACE: Winning the Points of LLM Function Calling
• ICLR 2025

🔑この論文のキーメッセージ

• 人工APIをLLMが生成することで、LLMのツール呼び出しの性能を向上させることができる。

🎓どういう問題に取り組んだのか

• ツール呼び出しタスクの学習に使用するためのデータを生成するパイプラインを作成する
• マルチターンなどの複雑なタスクが必要な状況を想定している

🧑‍🎓その問題に取り組むことがなぜ重要なのか

• 現実世界におけるツール呼び出しは複雑である
  • ユーザーの指示の多様さや曖昧さ、zero-shot推論だけではなく、複数のツールの組み合わせが必要なケースがある

💡問題解決に向けたキーアイデアは何か

• データ生成パイプラインとして以下の3ステップを提案した

  1. ツール生成

     • Tool Self-Evolution Synthesisという方法を提案した
     • 最初に、事前学習用のデータからAPIの情報を抽出する
       • 人工APIの分類を指しているのかも？
     • 作成したノードを基に、APIが対応している範囲を調査する
       • フィードバックをしていると考えて良さそう
     • フィードバックを基に、APIの仕様を改善する

  2. 対話生成

     • user、assistant、toolのそれぞれのroleをLLMが生成する
     • 対話の複雑さを評価するために、コンテキストから次のステップのトークンが生成される確率の平均値を使用している

  3. 検証

     • ルールベースの評価とLLMによる評価によるデータセットの評価が適用される

     • LLMの評価は、ハルシネーションの確認、レスポンスの一貫性、ツール呼び出しの適切さで評価される

👀新たに分かったことは何か

• 8Bモデルを学習し、BFCLとAPI-Bankで評価した
• BFCLの評価では、オープンソースのモデルよりも良い性能であった
  • xLAMよりも性能が良く、GPT-4oの一部のモデルよりも良い
  • 特に、Non-liveが強くなっている
• API-Bankにおいても同様の傾向がある

❓疑問点は何か

ファラオの密室を読んだ。 ある事件で死んだセティと呼ばれる神官が訳あって復活し、自分の死に関する謎を解くミステリー。 本の中には、大きく3つの謎がある。 一つ目は、神官セティはなぜ復活したのか？という謎である。 二つ目は、先王のミイラは何故棺の中に無かったのか？ 三つ目は、ピラミッドの建築のための資材の移動が遅いのは何故か？というものであった。 二つ目の謎については、プロローグで事件が起きる。 そして、神官セティが冥界で目を覚まして小説が始まる。

ミステリーとしても面白かったし、エジプト社会の描写も楽しめた。 それぞれの謎のトリックについて、そうかという納得感があった。 背景にも、エジプト社会固有の事情が背景になっていて、エジプトという世界が活かされていた。 オシリスやアヌビスなどの多神教の教えを、アテンという唯一神に先王は変えようとした。 この宗教対立という実際にあった出来事を事件の背景に上手く導入されていたと思う。 宗教観の理解については、エジプト人ではない奴隷に質問させることで噛み砕かれて、うまかった。

エピローグでは、セティ本人の真実が明かされる。。。! これは、おまけと言って良いのか分かんないけど、小説の締めとして終わった感じがした。

📄論文情報

• API-Bank: A Comprehensive Benchmark for Tool-Augmented LLMs
• EMNLP 2023 main

🔑この論文のキーメッセージ

• Tool Callingタスクのデータの構築において、多様なドメインを含めることが重要である。

🎓どういう問題に取り組んだのか

• LLMが外部ツールを使用する能力を評価するためのベンチマークを構築した

🧑‍🎓その問題に取り組むことがなぜ重要なのか

• LLMの性能は学習データに依存するため、最新の情報を応答に反映することができない
• 外部ツールを使用することで、最新の情報に対応することができるが、LLMの外部ツールの性能評価はされていない

💡問題解決に向けたキーアイデアは何か

• LLMのAPI呼び出し性能を評価するためのベンチマークデータセットと学習データを構築した
• ベンチマークデータセットの構築
  • LLMの能力を評価する上で、APIの呼び出し回数と呼び出すことのできるAPIの数を基準にタスクを構築
  • タスクの分類は以下の三種類
    • Call : 一回以上のAPI呼び出しで、APIの数が少ない
    • Retrieve+Call : 一回のAPI呼び出しで、APIの数が多い。LLMには使用できるAPIが与えられない。
    • Plan+Retrieve+Call : 複数回の呼び出しで、APIの数が多い。LLMには使用できるAPIが与えられない
  • ベンチマークに使用されるAPIは、実際に実装している(おそらく架空のAPI)
  • アノテーションは人手で行うようにしている
  • 評価指標は、LLMが作成したクエリの正解率とAPIの応答を基に生成した文章のROUGE-Lスコアを使用している
• 学習データセットの構築
  • データセットはLLMを用いて作成された合成データセットを用いる
  • 生成は五つのLLMが独立してデータを生成する
    1. ヘルスケアなどのデータのドメインを指定する
    2. ドメインを基にAPIを合成する、合成時には実データを例として与えている
    3. 合成されたAPIをランダムサンプリングし、クエリを作成する
    4. APIのレスポンスを生成する
    5. データセットに沿う内容になっているか、評価し、フィルターする

👀新たに分かったことは何か

• Lynxというモデルを提案手法により作成されたデータセットを用いて評価した
• 学習することで、LLMの性能が向上することが分かった
  • 同じようなデータになっているなら、当然な気がする
  • エラーの傾向として、学習前はAPIの呼び出しが無いケースが多いが、学習後はAPIの関数名の間違えているケースに変化した
• ベンチマークについては、GPTなどのモデルと比較すると、Callが一番簡単で、Plan+Retrieve+Callが難しい傾向がある
• ToolAlpacaと比較すると、少ないデータで同等の性能が得られた
  • 高品質なデータであると言えるのか？評価データによって結果が変わりそう

❓疑問点は何か

• ベンチマークと学習データを同じような方針で作成したら、評価結果が良くなるのは当たり前ではと思った
• 手法自体は参考になりそう

中山七里の「有罪、とAIは告げた」を読んだ。 東京地裁を舞台に、人間の裁判官と同じ判決を出力できるAI裁判官「法神」の判決を巡るミステリー。 最初は、AI裁判官の導入や性能評価の話をしている。 この「法神」が、ある殺人事件において死刑を宣告する所から物語が大きく動き出す。

上手く言語化できないけど、すごくもやもやした。 AIに流される人やAIの営業をする人の行動や言動にムカついただけな気がしてきた。 AIは中国との技術交流の名目で持ち込まれていて、「法神」にはある秘密がある。 この秘密については現実味がある程度あると思うのだけど、露悪的過ぎのようにも感じた。

AI時代において、人間の仕事は責任を取ることであるということがメッセージの中核にあると思う。 これ、柞刈湯葉の「未来職安」の話と同じだ。 場所が裁判所か、架空の職業かという違いくらいしか無いんじゃないか？

文化系のための野球入門を読んだ。 日本に野球が持ち込まれてから、現代までどのような変遷を辿ってきたのかを解説しつつ、批評している本だった。

野球という一つの題材を、ジェンダーや歴史、社会など色々な側面から論じていて、面白かった。 野球が元々サブカル的なものであったことや、甲子園が成立に至るまでの経緯など、知らなかったことが多かった。 甲子園は、明るいニュースを生み出す必要があって企画された側面があったことや、球場のスタンド？に入ることができる女子が1人までという規定があるというのは知らなかった。 この規定については、甲子園の伝統とやらを守るという本音が隠れているという指摘など、ジェンダー論などにも踏み込んでいて、そこまで分析できるんだという視点が新しく得られた。

野球だけではなく、体育や他のスポーツについて論じている点も学びになった。 他のスポーツを同じように分析してみると、どのような結論が出てくるのか興味がある。 野球と比較されがちなサッカーについてはどうなんだろうか。

📄論文情報

• AgentTuning: Enabling Generalized Agent Abilities for LLMs
• ACL 2024 findings

🔑この論文のキーメッセージ

• NLPとエージェントタスクの損失関数の重み付き和を使うことで、NLPタスクの性能を維持しつつ、エージェントタスクの性能が向上する。

🎓どういう問題に取り組んだのか

• LLMのエージェント性能を向上させるためのデータセット構築、学習パイプラインを提案した

🧑‍🎓その問題に取り組むことがなぜ重要なのか

• 既存のエージェントタスクの手法はプロンプトや特定のエージェントタスク偏っている
• NLPにおけるタスクの能力を維持しつつ、エージェントタスクの能力を向上する必要がある

💡問題解決に向けたキーアイデアは何か

• データセットの構築には、self-instrcutを使用している
  • 既存のデータセットにあるユーザーとエージェントのインタラクションの続きを、GPT-4により生成する
  • 最終的なエージェントの行動の結果は報酬として評価される
    • この報酬は、タスク毎に設計されていて、報酬の値を基にフィルタリングをしている
• 学習に使用するデータセットは、上記の方法で構築されたデータセットと指示学習用のものの二つを用いる
  • 損失関数には、それぞれのデータセットに対するクロスエントロピーの重み付け和を使用している

👀新たに分かったことは何か

• held-in、heol-outなタスクにおいてGPT-4や3.5と同等の性能を示した
  • これが公平な比較になっているかは分からない
• 公開されているLlamaよりも基本的なエラーが減少している
• 学習には、エージェントタスクだけではなく、指示学習用のデータも混ぜた方が汎化性能が向上する
  • 出力を見た感じでは、想定しているエージェントタスクと違うのかも？

❓疑問点は何か

• 損失関数を混ぜることと、継続学習でどちらが有効なのか気になった

📄論文情報

• Lemur: Harmonizing Natural Language and Code for Language Agents
• ICLR Spotlight

🔑この論文のキーメッセージ

• 事前学習にコーディングタスクを混ぜることで、実用的なLLMを学習することができる。

🎓どういう問題に取り組んだのか

• 一つのLLMで、言語とプログラミングの能力をバランス良く学習すること

🧑‍🎓その問題に取り組むことがなぜ重要なのか

• LLMの実環境用のインタラクションにおいて、APIを活用する必要がある
  • チャット機能や推論だけではなく、プログラムを適切に構築する能力も必要になっている
• ChatGPTなどのClosedなLLMでは、チャット機能とプログラムの両方を実現できている
• 一方で、Llamaなどのモデルは、それぞれのタスク専用のLLMを公開するに留まっている

💡問題解決に向けたキーアイデアは何か

• 事前学習とインストラクションチューニングに分けて学習する。
  • 事前学習では、コーディングタスクとテキストの割合を10:1にして学習している
    • 学習に使用したプログラムはThe Stackデータセットを活用している
  • インストラクションチューニングは既存の複数のデータセットを混ぜて使用している
    • ここのデータはテキストのみ
    • そこまで工夫している点ではないのかも？

👀新たに分かったことは何か

• 事前学習にコーディングタスクを混ぜて学習し、インストラクションチューニングを適用することで、自然言語を対象とした推論能力を維持しつつ、コーディングタスクにおける性能が向上している
  • プログラミングだけではなく、APIを使用した推論についても性能が向上している。
  • 事前学習が有効であると言えるのかもしれない。

❓疑問点は何か

• 査読でも指摘されていたけど、事前学習のタスクの割合がどれくらい有効なのか分からない
  • 著者らは継続学習して、調べているらしい
  • この辺のバランスを良い感じに調整できたら熱い気がする

📄論文情報

• Toolformer: Language Models Can Teach Themselves to Use Tools
• NeurIPS 2023

🔑この論文のキーメッセージ

• データ拡張にAPIを用いることで、下流タスクにおける性能が向上する。

🎓どういう問題に取り組んだのか

• 自己教師有り学習により、外部ツールをLLMが使用する方法を学習する
  • 評価と違う点があるから、読み違えているかも
• テキストデータから、Tool Callingデータセットを作成する

🧑‍🎓その問題に取り組むことがなぜ重要なのか

• 既存の手法は、大規模な人手アノテーションが必要であることや、特定のタスクのみを対象としている
• そのため、学習したLLMの応用先が限られるという課題がある

💡問題解決に向けたキーアイデアは何か

• データ拡張にはテキストデータを用いる
  • 疑似APIをLLMを用いて生成する
    • 疑似APIの形式は QA(c)-> r のような感じ
    • 使用するタスクとしては、QAや計算問題を用いている
  • 生成された疑似APIを実行する
    • 実行は、LLMやPythonなどの環境ですることを想定している
  • フィルタリングには、重み付きクロスエントロピーを基準として用いている
    • 生成されたトークンの損失と、何も生成されなかった時の損失の差が閾値よりも大きい時、データセットに含むようにしている
• 推論時には、 -> トークンが生成されるまでデコーディングを行う
  • ここでAPIの呼び出しが入るため、APIの結果を挿入して、デコーディングを再開する

👀新たに分かったことは何か

• QAや数学タスクにおける性能が向上した
  • 下流タスクにおける性能が向上している
• Tool Callの評価が無いのが気になる
  • 目的がTool Callingの性能向上ではなく、Tool Callingを通した性能向上になるのかも

❓疑問点は何か

• 評価のやり方が適切であるかどうか分からない
  • API callを実際にしているのか？
  • 下流タスクにおいて外部ツールを呼び出せるなら性能の向上は必然では？とも思う。
• このデータ拡張のやり方は面白いと思った。

都市伝説解体センターをクリアした。 主人公は、不思議な力を持つピュアな大学生。 この主人公が、都市伝説解体センターという機関で様々な事件や謎を解決していくノベルゲームだ。

序盤は退屈な感じがしていたけど、後半の展開は見事だった。 SNSと通した調査があるの何？って思いながら進めていたのだが、これにも意味があるので、心を折らずに最後までやって欲しい。 普通の事件を都市伝説と関連付けながら解決していくだけのゲームだと思っていたら、最後に怒涛の伏線回収があり、とても良かった。 全ての謎に理由があるというのがすっきりした。 全部で6章あり、最後の事件は全ての謎が繋り、事件の謎や能力の理由が明かされた。 最後の展開は完全に予想外だった。

ストーリーも良かったけど、ピクセルをベースにしたデザインが気に入った。 あざみやジャスミンの表情や動いている様子が刺さった。 個人的にピクセルアートが好きなのだが、それを上手くアニメーションに落とし込めているように見えた。

後で、全部見返すと、気付いていない伏線がたくさんありそうなとても良いゲームだった。 疑問としては、センター長の電話がどうなっているのか分からなかった。 ノベライズして欲しいなあ。

伊坂幸太郎のマイクロスパイ・アンサンブルを読んだ。 猪苗代湖で行なわれているロックフェスにおいて、毎年配布される冊子で連載されているものを文庫化したらしい。 これにちなんで、小説の舞台は猪苗代湖が中心になっている

話の内容としては、ある機関のスパイと社会人の物語。 二人が住んでいる世界は別物のように書かれているが、実は繋っている。 どちらかが取った行動が、どちらかの世界に影響している様子が面白かった。 社会人の世界において、社会人の友達が猪苗代湖で無くしたものが、スパイの世界では宝物として引き上げられて、最終的に見つかる所や、社会人の世界で地面に置いたコップがスパイの命を助けたりしている。 この奇妙な偶然の一致が話を進めていく様子は、何か暖かい気持ちになった。