2025-01-09 機械学習勉強会
今週のTOPIC[paper] DeepSeek-V3 Technical Report[論文] SWE-Bench+: Enhanced Coding Benchmark for LLMs[blog] 🚀 Cache-Augmented Generation (CAG): A Rising Competitor to RAG?[slide] 新しいスケーリング則と学習理論[blog] Weekly AI Agent News!から見えたAIエージェントの現在地 - 襖からキリン[blog] LLM を用いた PDF を元にした回答と、該当箇所のハイライトメインTOPICToolformer: Language Models Can Teach Themselves to Use Toolsサマリー1. Introduction2. Approach1. Sampling API Calls2. Executing API Calls3. Filtering API Calls4. Model Fine-Tuning5. Inference3. Tools4. Experiments4.1. LAMA4.2.Math Datasets4.3. Question Answering4.4 Multilingual Question Answering4.5 .Temporal Datasets4.6. Language Modeling4.6. Scaling Law4. Limitaion5. 感想
今週のTOPIC
※ [論文] [blog] など何に関するTOPICなのかパッと見で分かるようにしましょう。
出典を埋め込みURLにしましょう。
@Naoto Shimakoshi
[paper] DeepSeek-V3 Technical Report
- レポジトリ:https://github.com/deepseek-ai/DeepSeek-V3
- MITライセンスではあるが、モデルの重みを使う場合はこちらのライセンスが適用される模様。とはいえ、出力に対して責任を負う旨などが明記されているだけで、商用利用や公開義務については書いてない模様。
- とはいえ、数百GB規模のファイルをホスティングする必要があるので、localで動かすのは容易ではなさそう。
- 元のテクニカルレポートはちゃんと読めてないが、かいつまんだ紹介
- 概要
- DeepSeek-V3は671Bのパラメータを持つMixture-of-Experts(MoE)アーキテクチャに基づく大規模言語モデル
- 実際には37Bのパラメータのみがアクティブ。効率的な推論とコスト効率の良いトレーニングを目指し、Multi-head Latent Attention(MLA)とDeepSeekMoEを採用。
- オープンなモデルの中で最も強力で、GPT-4oやClaude 3.5 sonnetにも精度が匹敵。
- めちゃくちゃ安い。GPT-4oの50分の1とか
- (中国文化が出力に表れていて面白いらしい)
- 特徴
- FP8 Mixed Precision Training
- 学習効率化のためにNVLinkの通信カーネルなども開発
- Auxiliary-loss-free strategy
- 一部のExpertに偏りすぎないようにRootingにbias項を追加
- Multi-Token-Prediction
- 複数ステップのトークンを一気に予測する手法
- Multi-Head Latent Attention
- Latent Vectorを挟むことによって低ランク圧縮を行う
- キャッシュするのはLatent Vectorだけにすることで、KVキャッシュを小さくすることでメモリ効率化
- DeepSeekMoE
- 普通より細かいExpertを作成し、いくつかのExpertを共有Expertとする
- アーキテクチ

@Tomoaki Kitaoka
[論文] SWE-Bench+: Enhanced Coding Benchmark for LLMs
- 前回の勉強会で紹介したSWE-Benchの続編的なやつ
- SWE-Bench の課題
- 解答のリーク(Solution Leakage)
- 課題文やコメントに修正コードがそのまま含まれるケースが 30% 超存在し、モデルが「ただコピペしている」可能性がある。
- 不十分なテスト (Weak Tests)
- 修正内容が誤っていてもテストを通過できてしまう事例が 30% 前後発生し、実際には問題を解決していないにもかかわらず「成功」と判定される。
- SWE-Agent+GPT-4の例
- SWE-Bench Full/Lite/Verified を用いて GPT-4 ベースのエージェント (SWE-Agent+GPT-4) をテストしたところ、これらのデータセットでも同様に解答例のリークやテスト不十分による「怪しい成功」が含まれていることがわかり、問題点を除去すると、モデルの実際の成功率は大幅に低下した (例: SWE-Bench Full で約 12.47% → 3.97%)。
- SWE-Bench+ の提案
- モデルの学習データ切り取り時点以降に作成された GitHub 課題を選び、かつ課題やコメントに解答例が含まれないようにフィルタリングを徹底し、従来よりもデータ漏れや解答例のコピペのリスクを大幅に低減。
- [tomo] 結局時間が経てばまたリークするだろうけど、これまでのモデルを再評価するには良さそう。あと、継続的にベンチーマークをfreshなものにする仕組みが作れると良さそう。
- 評価
モデル | SWE-Bench Full(リーダーボード等) | SWE-Bench+(本研究) | 差分(SWE-Bench+ − Full) |
SWE-RAG + GPT-4 | 1.31% | 0.73% | −0.58 |
SWE-RAG + GPT-3.5 | 0.17% | 0.55% | +0.38 |
SWE-Agent + GPT-4 | 3.97% | 0.55% | −11.92 |
AutoCodeRover + GPT-4o | 18.83% | 3.83% | −15.00 |
@Yuta Kamikawa
[blog] 🚀 Cache-Augmented Generation (CAG): A Rising Competitor to RAG?
- RAGのように文書を検索せずとも、LLMのコンテキスト長も大きくなってきてるし、関連しそうな文書をあらかじめ全部読み込んでしまっていいのでは?というCache-Augmented Generation (CAG)という方法の紹介
- 従来手法(Retrieve + Generate: RAG)
- RAGは、LLMの知識を補うために、必要な文書を検索エンジン等からその都度取得する仕組み
- 「文書Aを見つけて→LLMに読み込ませ→回答を生成」という流れが基本
- 高い汎用性がある一方、検索レイテンシや文書選択ミスなどのリスク
- Cache-Augmented Generation(CAG)
- 一方、CAGでは、最初にすべての必要文書をLLM読み込んでおき(実装見た感じプロンプトに入れてる)、リアルタイム文書検索をしないというシンプルなアプローチ
- LLMの長大なコンテキストを活かして、関連文書をまとめて読み込んで、推論時にユーザ質問を加えるだけ
- 検索がない分、処理がシンプルで高速、かつ間違った文書を拾う心配もほぼない

- 実験
- QA用の2つのデータセットで評価(Docs, Tokens少なめ)
- Claude-3.5 Sonnetのコンテキスト長が200k
- CAG が多くの設定で BERT Score が最も高く、Sparse RAG / Dense RAG より良い結果を示した
- 「リアルタイム検索時のミス」が起こらない
- LLMが文書全体を最初から包括的に処理している
- 処理速度においては、検索部分がないので、最大40倍高速



- 「更新頻度が低い」「文書量が限られている」環境では、CAGが非常に有力な選択肢になり得る
- 医療情報のQA, 財務データ分析, 企業のFAQやナレッジベース
- CAGの弱点
- 文書が膨大すぎると、事前読み込みがそもそも難しい
- 頻繁に更新がある
- 感想
- AIエージェントだと自律的に文書検索とかweb検索とかAPI連携とかでよしなに情報を取得してタスクをこなしたりするが、情報を全てLLMに持たせることができる条件下であれば、CAGのようなシンプルなアプローチも考えられるなあと思った
@Shun Ito
[slide] 新しいスケーリング則と学習理論
- モデルの性能が上がり、事前学習の計算量もどんどん上がっている

- 事前学習のスケーリング則をそのまま突き進まず他のところにも目を向ける必要がある
- “訓練データはインターネット上のほぼ全てのデータを使い切っており”

- 事後学習・テスト時推論にも目を向ける

- 質の高いデータをいかに用意できるかが重要

- 事後学習: 人間によるfeedback (RLHF) ではなく、別のLLMによるfeedback (RLAIF) を使う
- 評価用LLMが自身より”優れている”必要はなく、AI自身の生成データで自己改善できる可能性がある

- テスト時の推論でもスケーリングの余地が多く残されている
- Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters (Snell, et al. 2024)
- 解候補の枝刈りを高速化して推論速度向上

@qluto (Ryosuke Fukazawa)
[blog] Weekly AI Agent News!から見えたAIエージェントの現在地 - 襖からキリン
AI Agentについてずっと動向を追いかけている方が、最近の状況を俯瞰的に考察したブログ
1) マクロレベルでエージェントアーキテクチャに差分はない昨今のLLMを用いたエージェントは登場から2年近く経っていますが、2024年に何か新しいエージェントの基礎技術があったかといわれると言葉が詰まります。 エージェントの基礎は2023年の夏には出揃っていたと思います。 エージェントの基礎は、知覚、プロフィール、プランニング、リフレクション、ツール利用、メモリです。 各大学や企業が様々なエージェントアーキテクチャを提案したのも2024年の特徴ですが、どれも同じ基礎技術を使っています。 もう少し言うと、エージェントアーキテクチャもほぼ同じです。過去の経験をメモリから引き出して、計画して、行動して、振り返って、目標を達成したか確認するプロセスはどのエージェントも同じです。(略) どちらもエージェントのアーキテクチャの根幹は同じです。図を見ると人間の役割をもとに業務プロセスを記述するか、エージェントのワークフローを記述するかの違いです。 ソフトウェアの操作だけでなく、RAGの拡張も、データ分析も文章作成系もマクロレベルでは同様なエージェントアーキテクチャになっていることがほとんどです。 なぜならそれが人間の基本的な思考と行動プロセスだからです。考えて、行動して、振り返って、また考えて、行動する。
感想:確かにエージェントの話は LangChain が出た当初から機能として組み込まれていましたし、研究もずっと前から継続的にされている印象。それでも去年1年をまとめて振り返ってこういう印象なのだとしたら、このアーキテクチャが肝だというのは芯を食った話。
もう一つ応用開拓の年と思えたのは、特定の業務に向けたエージェントを開発し評価した論文が多く発表されたからです。
感想:基本的なエージェント問題に限らず、特定の業務に向けたベンチマークやエージェントの開発が増えてきたというのは確かに感じているところ。その分精度評価自体が難しくはなるのですが。
@Yosuke Yoshida
[blog] LLM を用いた PDF を元にした回答と、該当箇所のハイライト
- 回答の根拠の引用
- SystemPromptに回答と共に参考にした文章の引用キー(例えば [PDFのID-チャンクのID] など) を付けるように指示
- 該当箇所のハイライト
- Azure Document Intelligence layout model を使用し、OCR した文字情報と共に、位置情報(polygon)を取得
- RAGに利用するチャンクと位置情報を紐付けて利用することで、ハイライトするべき位置情報を算出
- 工夫点
- 単純な文字数によるChunking だと表が途中で切れてしまって意味のあるチャンクにならない
- そこで MultiVectorRetriever を採用し、表だけを1つのチャンクにすることで正しい結果が返せるようにしました
- また表の文字列は数字の羅列のためそのままベクトル化しても質問文にHitしないことが多いため、一度LLMに要約させた文章をEmbeddingにすることでより質問文にHitするように工夫しました(MultiModal RAG)
メインTOPIC
Toolformer: Language Models Can Teach Themselves to Use Tools
Timo Schick, Jane Dwivedi-Yu, Roberto Dessì, Roberta Raileanu, Maria Lomeli, Luke Zettlemoyer, Nicola Cancedda, Thomas Scialom
- 2023年2月にarXivに投稿されたMicrosoft Researchによる論文
- ‣
- 2025を象徴するというAIエージェントについてサーベイする中で、うまく外部のツール(API)を呼び出して適切な知識を得たり処理を行うことが重要だなぁと再認識し、キャッチアップのために少々古い論文ですが読んでみました。
- 自社のプロダクト内で自由に機能するAIエージェントを開発するにあたっては、自社固有のツールの使い方をLLMに教えることは重要であり、そのヒントになるなと感じています。
サマリー
- LLMがさまざまな外部APIをうまく呼び出してタスクをこなせるようにファインチューニングした Toolformer を提案した論文
- 今更でもあるが単純なLLMは最新の情報にアクセスしたり、単純な算術演算などが苦手であったりという弱点が存在する。
- 人間のアノテーションを必要とせず、機械的にでデータセットを作成した上で自己教師あり学習を行い、電卓やQA、検索エンジンなどの外部APIを適切なタイミングで適切な形で呼び出す方法を学習する。
- ゼロショットで(当時)既存のより大きいモデルの性能を超えた。
1. Introduction
- LLMsはゼロショットやFew-Shotタスクで高い性能を発揮する一方、以下のような課題を有する。
- 学習データに含まれない最新情報へのアクセスが困難
- hallucinationリスク
- 計算能力の不足
- 時間的な文脈(temporal awareness)の欠如
- e.g. 「前の月曜日は何日?」のような、質問タイミングで回答が変わるものに答えられない。
- Low-resource言語の理解が不十分
- これらに対処する一つの方法は、外部ツール(検索エンジン、計算機、カレンダーなど)を利用可能にすること。
- 一方で、既存のツール利用手法には以下のような課題
- 大量の人手でのアノテーションが必要
- ツール利用が特定タスクに限定されており、汎用性が低い
- そこで以下を満たすToolformer手法を提案
- 人間による大量のアノテーションなしに自己教師あり学習で学習
- 特定のタスクにしばられることなく、モデル自身がどのツールを、いつ、どのように利用すべきかを決定できる
- 人間が記述した最低限のAPI利用方法の文章のみを与え、LLM自身にAPI利用方法を学習するためのデータセットを作成させ、それを用いて自己教師あり学習を行う。
- データセットの種類はなんでもいいので、事前学習に利用したデータセットを拡張させることも可能。
- GPT-J(6.7B)をベースとしてToolformerが、GPT-3をゼロショットで上回ることを実験で確認
2. Approach
- やりたいことのイメージは以下のよう。
- 色付き部分が外部APIツールの呼び出しと結果取得部分
- 外部API呼び出し部分(`[QA(”Who is the pubkisher of …?”)]`)をLLMが自分で生成し、それに従って外部APIが実行されて結果(`”Massachusetts Medecal Soceiety”`)を取得して文章に埋め込み、それをもとに以降の生成を行う。
- このようなデータセットを自動で作れるという部分が本研究のミソ。

- データセット作成の全体像は以下。それぞれ説明する。

1. Sampling API Calls
- データセット内のサンプルごとに、どこでどのようにAPIをcallすべきかを判定する。
- 以下のようなプロンプトを与えて、LLM自身にAPI call 位置を生成させ、予測確率が閾値以上かつtop k の位置をAPI call の位置として採用
- x はサンプル文章中の位置。API call の位置を文章の先頭からずらしてすべてのパターン試していく。

- k パターンの位置において、実際にAPIをcallする方法(入力)を m 個ずつ生成させる

2. Executing API Calls
- k * m パターンで実際にAPIを実行して結果を得る。
3. Filtering API Calls
- API実行結果をもとに学習に利用するサンプルをフィルタリングする。
- API call 位置から後続の単語の予測確率の重み付きクロスエントロピーロスを計算
- 重みはAPI call 位置から遠いほど小さく、5つ先で 0

- API call なし or API を呼んだが結果が返ってこなかった場合と比べて、API call およびその結果を文章に埋め込んで出力した場合のほうがlosszが十分に小さくなれば採用


- 以下は例。誤ったAPI call(位置や入力)をしている場合は loss が小さくならず、データセットからフィルタリングされる。

4. Model Fine-Tuning
- フィルタリング後のデータセット C∗ を作成しLLMをfinetuning
- データセットには、API call をいつ(位置)どのように(入力)呼び出すべきかの情報が含まれており、それらの学習を狙う。
5. Inference
- 通常の推論(デコーディング)行い、APIコールが必要と判断された箇所(特殊トークン「→」が生成された箇所)でデコーディングを一時中断
- 実際にAPI call を行い、その結果を埋め込んで </API> を挿入して後続の推論(デコーディング)を行う。
- つまりゼロショットでAPIの選択および実行が行えている。
3. Tools
以下の外部APIを採用
- Question Answering
- Wikipedia Search
- Calculator
- Calendar
- Machine Translation

- 選定基準
- 入出力がテキスト形式
- 意図した使用方法をLLMに示しやすい
4. Experiments
- データセット
- CCNet(Webクロールデータセット)
- 今回作成するデータセットは、ツールの種類ごとに有益そうなサンプルにさらに絞って作成(コスト削減)
- 電卓の場合、少なくとも3つの数字を含むなど

- モデル
- GPT-J: 通常のGPT-J
- GPT-J + C : 今回利用するデータセットでfinetuning した GPT-J
- Toolformer: API call 用に拡張したデータセットでfintuningした GPT-J
- Toolformer(disabled): API call のでコードを無効にした Toolformer
4.1. LAMA
- 欠落している日付や場所を埋めるタスク

4.2.Math Datasets

4.3. Question Answering

4.4 Multilingual Question Answering

4.5 .Temporal Datasets
- 時間変化により答えが変わるタスク
- 「30日前の日付は?」

4.6. Language Modeling

4.6. Scaling Law
- より大きなモデル(GPT-2)でも検証
- 大きいモデルほど高い性能が出ている。
- GPT-3をこえるタスクも見られた。

4. Limitaion
- 連鎖的なAPI call(あるAPIの結果を利用して次のAPIを呼び出す)はできない。
- インタラクティブにAPIを利用できない
- 検索結果を人間が見て対話的に
- API call のコストはほとんど気にしていない
5. 感想
- データセットの作成方法、聞いてしまえばアレだが賢いなと感じた。
- API call がひとつのパターンにしか対応していないとのことだが、工夫すれば(お金も無限にあれば)なんとかできるんじゃないかなと感じた。
- 今回のToolは汎用的なものが多かったが、独自ドメインの文書とToolでAgentを実現するためには重要な切り口になるのではと感じた。