Kei Moriyama keimoriyama

📄論文情報

• Bayesian Optimization from Human Feedback: Near-Optimal Regret Bounds
• ICML 2025

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

• ….?

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

• 一対比較によるフィードバックを用いたベイズ最適化のregret boundを解析した
• この解析結果を元に新しいベイズ最適化のアルゴリズムを提案した

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

• 既存の解析論文では、ある定数がついていたが、この論文でこの定数を減らしても良い事を示した
• 通常のベイズ最適化とは異なり、評価値が一対比較であるため、regret boundの解析が複雑である

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

• よく分からなかった
• 理論的な事を理解するための知識が足りなすぎ

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

• 何が分かれば分かるようになるのか分からない

❓疑問点は何か

📄論文情報

• Comparison-based Active Preference Learning for Multi-dimensional Personalization
• ACL 2025 main

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

• 様々な評価軸に重みを持たせることで、多様な価値観を考慮したLLMを作成することができる

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

• 人間の多様な好みに合わせてLLMを最適化すること
  • LLMは与えられたコンテキストに合わせた文章を生成する
  • 生成した文章に対してd次元の報酬が与えられる
  • この報酬に対する重みを個人に最適化し、LLMの生成文章の条件付ける

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

• 個人の価値観に合わせた文章を生成する技術が求められている
• 一方で、既存の学習手法は、一つの観点からの学習しかできずに、多様で複雑な人間の観点を反映することができない

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

• active learningベースの手法を提案した
• フィードバックの形式は、一対比較になっている
• クエリの選択方法としては、目的関数の期待値が最大になるものを用いている
  • この目的関数は、重みなどのパラメータを考慮した関数になっている
• 重みの更新はベイズ推論により推定される
  • 報酬の差が最大になるように学習されているっぽい

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

• 実験は人間の変わりにLLMを使用して評価している
• 報酬関数は、様々な観点からの評価を行う既存の報酬モデルを使用している
  • 人間のプロファイルとして、重みを事前に決めておき、この重みで条件付けしたLLMにより文章を生成している
• 最適化の効率が既存の手法よりも良い結果であった
  • win-rateも既存手法より良いので、改善方法として妥当であることが分かる

❓疑問点は何か

• 良さそう。
• 人間の報酬モデルは既知ではないから、実用性があまり無い気がする
• 獲得関数の設計は参考になる

📄論文情報

• From Outcomes to Processes: Guiding PRM Learning from ORM for Inference-Time Alignment
• ACL 2025 Long

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

• （1, 2文でまとめる）

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

• Reward Guided Searchは、LLMが生成した複数の文章から報酬モデルの値を用いて文章を選択する手法である
• この文章の選択に使用する報酬モデルの出力に一貫性を持たせることを目指す

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

• 報酬モデルは、文章の全体を評価するように学習される
• そのため、文章の一部を評価する時に報酬の一貫性が無くなる課題がある
  • 特に、冗長な文章を高く評価する傾向がある
• この報酬モデルを再学習するには計算コストが多くかかるため、既存のモデルを使用しつつ、報酬の計算を工夫することで、より良い文章の選択が可能になる

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

• スコアの計算時にscore consistencyの分析をしている
• Score Consistencyの定義
  • 文章AとBにおける報酬値r(A)とr(B)がある時、AとBの部分文字列aとbにおける報酬r(a)とr(b)は、以下の関係が成立する
    • r(A)>r(B) -> r(a) > r(b)
  • RGSでは、新しいトークンを選択する時に、これまで生成された文章と新しいトークンを繋げた文章の報酬が最大になるように選択するため、重要な性質になる
  • この時、部分文字列を評価することになるため、文章の部分文字列の評価の一貫性が必要
• 既存の報酬モデルは部分文字列の評価に一貫性が無いため、部分文字列を評価するためのデータセットを構築し、報酬モデルを学習した
• 学習には、報酬モデルの分布の差のエントロピーを重みとして使用している

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

• 文章全体を評価するように学習された報酬モデルは、Score Consistencyを満たさない

  • 報酬モデルの学習に使用するデータセットの部分文字列が、良いと評価された文章の方が高くなる割合で評価した

  • 5トークンで、57%くらいであり、50トークンまで増やすと60%まで上がる

  • 一方で、人間との評価の一致度は高い

  • 提案手法により学習した報酬モデルは、5トークンで55%、50トークンで65%まで改善した

• ベンチマークにおける評価は、報酬の平均値や文章の多様性などで評価

  • 様々なチャンクで文章を区切る方法に提案手法により学習した報酬モデルを使用したっぽい
  • 報酬の値などのスコアを見ると、既存の手法を改善できていると言える

❓疑問点は何か

• 着眼点が良いと思った
• 報酬モデルの学習が必要になっているのはネックになっていないのか気になった。

📄論文情報

• Meta-Tool: Unleash Open-World Function Calling Capabilities of General-Purpose Large Language Models
• ACL2025 main

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

• プロンプトにツール情報が含まれない時、LLMの仮説生成+埋め込み検索が効果的である

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

• LLMと外部ツールの連携をするためのフレームワークを提案する
• 外部ツールと連携する時にプロンプトに外部ツールの情報が与えられないケースを想定している

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

• プロンプトにユーザーの指示が含まれるということは、ユーザーが事前に使用できるツールを知っている必要がある
  • この状況は、LLMの性能が一定の範囲しか発揮されないため、に制限をかけていることになる
• そのため、ユーザーの指示に応じてツールを選択し、呼び出す必要がある
  • これを、オープンワールドファンクションコーリングと呼んでいる

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

• LLMの推論のためのフレームワークと、学習と評価のためのデータセットを構築した
• 推論のフレームワークには、hypothesize(仮説生成)-retrieve(検索)-invoke(呼び出し)フレームワークとしている
  • Hypothesize(仮説生成)
    • LLMがユーザーの指示から、必要なツールの要件や引数を推論する
  • Retrieve(検索)
    • テキスト埋め込みモデルを使用した検索システムを採用している
    • 推論したツール要件や引数を埋め込み表現に変換し、 類似度を計算している
  • Invoke(呼び出し)
    • ツールに対するクエリを生成する
• データセットには、既存のデータセットをオープンワールド形式に拡張するための方法を提案している
  • 拡張として、データセット内で呼び出されているツールをLLMで類似の形式に変換している
  • 変換後のツール呼び出しについて、推論プロセスを生成する
  • この生成した一連のデータをルールベースやLLMベースの方法により評価する

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

• simpleタスクとhardタスクがあり、それぞれについてLLMを評価した
  • hardは、拡張したツール呼び出しや、呼び出しの回数が多いデータが含まれる
• 評価の結果、学習したモデルがGPT-4oやオープンソースモデルよりも性能が良いことが分かった
• 検索システムは、キーワードベースの手法と比較していて、提案手法の方がhard設定で良い性能であった。
  • シンプルな設定では、ますおこまで差がでないように見える
  • 埋め込みベースの他のモデルと比較しなくて良いのだろうか？

❓疑問点は何か

• 仮説生成がどれだけ効くのか気になる
• 埋め込みベースの検索が効くのは分かるが、ベースラインが弱いのでは？
  • 他の良さそうな方法は思いつかないけど
  • ツール呼び出しならではの検索システムとか考えることができそう
  • 引数の型は大きな制約の一つになると思う

📄論文情報

• 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においても同様の傾向がある

❓疑問点は何か

📄論文情報

• 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と比較すると、少ないデータで同等の性能が得られた
  • 高品質なデータであると言えるのか？評価データによって結果が変わりそう

❓疑問点は何か

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

📄論文情報

• 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を実際にしているのか？
  • 下流タスクにおいて外部ツールを呼び出せるなら性能の向上は必然では？とも思う。
• このデータ拡張のやり方は面白いと思った。

📄論文情報

• Personalized Text Generation with Contrastive Activation Steering
• ACL2025 long

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

• LLMが生成する応答を人間が書いた応答を比較することで、LLMが生成する文章のスタイルを合わせることができる。

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

• LLMの内部表現に介入して、生成する文章を個人に最適化すること

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

• ユーザー毎に最適化されたテキストを生成する需要が高まっている
• 既存の手法はRAGやPEFTによる手法が注目されている
  • これらの手法は計算コストが高いことや、ユーザー特有の言い回しに影響されやすい

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

• LLMの隠れ層に介入することで、個人に最適化された文章を生成すること
• 前提として、あるユーザーのプロンプトとそれに対する応答がある
• 最初に、LLMはプロンプトに対する応答を生成する
• プロンプトと応答を繋げた文章の最終トークンに該当する特徴量を使って介入する方向の計算をする
  • ユーザーの応答を繋げた場合の特徴量をポジティブ、LLMの応答を繋げた場合の特徴量をネガティブとしている
    • こうすることで、今のLLMがその人に合わせるためにどれくらい介入すれば良いか計算できる
  • 方向の計算には、様々な方法を使用している
  • PCAとか、Mean Differenceなどなど
• ここで計算したベクトルを用いて介入する

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

• 個別最適化ベンチマークのLaMPで評価した
  • 短文を評価するものと長文を評価するものの二つがある
• 提案手法は、RAGやPEFTの手法よりも良い性能を示している
• 介入量により性能が大きく変わる
  • 提案手法により推定された介入ベクトルにおいて正の方向に介入するとユーザーのスタイルを反映しやすくなるが、負の方向にするとスタイルが関係無くなってしまう

❓疑問点は何か

• 実験のスタイルベクトルの計算には何を使用したのだろうか？
  • スタイルベクトルの計算方法によって性能が変わったりするのかな