• レポジトリ：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とする

• アーキテクチャ

• 前回の勉強会で紹介した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

• 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のようなシンプルなアプローチも考えられるなあと思った

• モデルの性能が上がり、事前学習の計算量もどんどん上がっている

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

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

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

• 事後学習: 人間による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)
• 解候補の枝刈りを高速化して推論速度向上

1) マクロレベルでエージェントアーキテクチャに差分はない

昨今のLLMを用いたエージェントは登場から2年近く経っていますが、2024年に何か新しいエージェントの基礎技術があったかといわれると言葉が詰まります。 エージェントの基礎は2023年の夏には出揃っていたと思います。 エージェントの基礎は、知覚、プロフィール、プランニング、リフレクション、ツール利用、メモリです。 各大学や企業が様々なエージェントアーキテクチャを提案したのも2024年の特徴ですが、どれも同じ基礎技術を使っています。 もう少し言うと、エージェントアーキテクチャもほぼ同じです。過去の経験をメモリから引き出して、計画して、行動して、振り返って、目標を達成したか確認するプロセスはどのエージェントも同じです。

（略） どちらもエージェントのアーキテクチャの根幹は同じです。図を見ると人間の役割をもとに業務プロセスを記述するか、エージェントのワークフローを記述するかの違いです。 ソフトウェアの操作だけでなく、RAGの拡張も、データ分析も文章作成系もマクロレベルでは同様なエージェントアーキテクチャになっていることがほとんどです。 なぜならそれが人間の基本的な思考と行動プロセスだからです。考えて、行動して、振り返って、また考えて、行動する。

もう一つ応用開拓の年と思えたのは、特定の業務に向けたエージェントを開発し評価した論文が多く発表されたからです。

1. 回答の根拠の引用
• SystemPromptに回答と共に参考にした文章の引用キー(例えば [PDFのID-チャンクのID] など) を付けるように指示

2. 該当箇所のハイライト
• Azure Document Intelligence layout model を使用し、OCR した文字情報と共に、位置情報（polygon）を取得
• RAGに利用するチャンクと位置情報を紐付けて利用することで、ハイライトするべき位置情報を算出

• 工夫点
• 単純な文字数によるChunking だと表が途中で切れてしまって意味のあるチャンクにならない
• そこで MultiVectorRetriever を採用し、表だけを１つのチャンクにすることで正しい結果が返せるようにしました
• また表の文字列は数字の羅列のためそのままベクトル化しても質問文にHitしないことが多いため、一度LLMに要約させた文章をEmbeddingにすることでより質問文にHitするように工夫しました（MultiModal RAG）