Meta、コーディング向け大規模言語モデル「Code Llama」を公開
(ai.meta.com)- Metaは、Llama 2ベースのコード特化モデルであるCode Llamaを公開し、研究・商用利用向けに無料で提供し、同じコミュニティライセンスを適用
- Code Llamaはコードと自然言語プロンプトの両方を受け取り、コード生成・補完・デバッグを支援し、Python・C++・Java・PHP・TypeScript・C#・Bashなどに対応
- モデルサイズは7B、13B、34B、70Bに分かれ、小さいモデルは低レイテンシに有利で、34B・70Bはより優れたコーディング支援を目指す
- 基本モデル、Python特化モデル、自然言語の指示理解に合わせたInstructバリアントが提供され、実際のコード生成にはInstructの利用が推奨される
- Code Llama 34Bは自社評価でHumanEval 53.7%、**MBPP 56.2%**を記録し、公開コード特化モデルを通じてコミュニティによる評価と脆弱性改善を促すアプローチ
公開方式と70Bアップデート
- Metaは、テキストプロンプトからコードを生成できる大規模言語モデルCode Llamaを公開
- Code Llamaは、公開利用可能なコード向けLLMにおける最先端の性能を目指し、開発者ワークフローをより速く効率的にし、コーディング学習者の参入障壁を下げることに焦点を当てている
- 研究および商用利用向けに無料で提供され、Llama 2と同じコミュニティライセンスで配布される
- 2024年1月29日のアップデートで、Code Llamaファミリーで最大かつ最高性能のCode Llama 70Bが追加された
- CodeLlama - 70B: 基本コードモデル
- CodeLlama - 70B - Python: Python特化70Bモデル
- Code Llama - 70B - Instruct: 自然言語の指示理解に合わせてファインチューニングされた70Bモデル
Llama 2をコード作業向けに調整したモデル
- Code Llamaは、Llama 2をコード特化データセットで追加学習したコード特化版
- コードと自然言語プロンプトの両方を入力として受け取り、複数のコーディング作業に活用できる
- コード生成
- コードに関する自然言語生成
- コード補完
- デバッグ
- プロンプト例は「フィボナッチ数列を出力する関数を書いて」のような自然言語のリクエスト
- 対応言語にはPython、C++、Java、PHP、TypeScript(JavaScript)、C#、Bashが含まれる
モデルサイズ、学習データ、レイテンシの選択
- Code Llamaは7B、13B、34B、70Bパラメータサイズで提供される
- 70Bを除くモデルはコードおよびコード関連データ500Bトークンで学習され、70Bは1Tトークンで学習された
- 7Bと13Bの基本モデルおよびInstructモデルは、**fill-in-the-middle(FIM)**機能で学習されており、既存コードの途中に新しいコードを挿入できる
- 即時コード補完のような作業を支援する
- モデルサイズごとにサービングコストとレイテンシ特性が異なる
- 7Bモデルは単一GPUでサービング可能
- 34Bと70Bは最良の結果とより優れたコーディング支援を提供する
- 7Bと13Bはより高速なため、リアルタイムのコード補完のように低レイテンシが必要な作業により適している
- Code Llamaモデルは最大100,000トークンのコンテキストで安定した生成を提供する
- すべてのモデルは16,000トークンのシーケンスで学習されている
- 最大100,000トークンの入力で改善を示す
- 長い入力シーケンスは長いプログラムの生成だけでなく、コードベースのより多くの文脈をモデルに伝え、生成結果の関連性を高めるのに役立つ
- 大規模コードベースのデバッグでは、特定の問題に関連するコードをすべて把握するのが難しい場合があるため、開発者は大きなコードの塊全体をモデルに渡せる
基本・Python・Instructの3つのバリアント
- Code Llamaファミリーには、基本モデルに加えてPython特化モデルとInstructバリアントが含まれる
- Code Llama - Pythonは、Pythonコード100Bトークンで追加ファインチューニングされた言語特化モデル
- Pythonはコード生成で最も多くベンチマークされる言語
- PythonとPyTorchはAIコミュニティで重要な役割を担っている
- Code Llama - Instructは、指示ファインチューニングとアラインメントを経たバリアント
- 自然言語の指示入力と期待される出力を使って学習を継続する
- 人がプロンプトで期待する結果をよりよく理解するよう設計されている
- 実際のコード生成にはCode Llama - Instructの利用が推奨される
- 自然言語で有用かつ安全な回答を生成するようファインチューニングされているため
- Code LlamaとCode Llama - Pythonは一般的な自然言語タスクには推奨されない
- 両モデルは自然言語の指示に従うようには設計されていない
- Code Llamaはコード特化タスク向けであり、他のタスクの基盤モデルとしては適していない
- 利用者はライセンスと許容利用ポリシーに従う必要がある
ベンチマークと安全性評価
- MetaはCode Llamaの性能を評価するためにHumanEvalとMBPPベンチマークを使用
- 自社ベンチマークで、Code Llamaはオープンソースのコード特化LLMやLlama 2より優れた性能を示した
- Code Llama 34BはHumanEval 53.7%、**MBPP 56.2%**を記録
- 他の最先端の公開ソリューションと比べて最高スコアだった
- ChatGPTと同等レベルと評価された
- 公開前に複数の安全対策が適用され、レッドチームの過程で悪性コード生成リスクを定量評価した
- 明確な意図を持って悪性コードを求めるプロンプトを作成
- Code Llamaの応答をChatGPT(GPT3.5 Turbo)の応答と比較して採点
- 結果としてCode Llamaはより安全な応答を提供した
- 責任あるAI、攻撃的セキュリティエンジニアリング、マルウェア開発、ソフトウェアエンジニアリング分野の専門家によるレッドチームの詳細は、研究論文で確認できる
公開資料と責任ある利用
- 開発者はすでに、新しいソフトウェアの作成から既存コードのデバッグまで、さまざまな作業にLLMを使用している
- Code Llamaは、反復作業よりも人間中心の業務に集中できるよう、開発者ワークフローをより効率化することを目指す
- Metaは、コーディング向けLLMがイノベーションと安全性の面でオープンなアプローチの恩恵を大きく受けられると見ている
- 公開コード特化モデルは、コミュニティがモデルの能力を評価し、問題を見つけ、脆弱性を修正できるようにする
- Code Llamaの学習レシピはGitHubリポジトリで公開されている
- モデル重みはLlamaページで提供されている
- 研究論文には、開発の詳細、ベンチマークテストの方法、限界、既知の課題、緩和策、今後の調査課題が含まれる
- Responsible Use Guideも更新され、ダウンストリームモデルを責任を持って開発するための指針を提供している
- コンテンツポリシーと緩和策の定義
- データ準備
- モデルのファインチューニング
- 性能評価と改善
- 入力および出力レベルのリスク対応
- ユーザーとのやり取りにおける透明性と報告メカニズムの構築
- 開発者はコード特化評価ベンチマークでモデルを評価し、マルウェア・コンピュータウイルス・悪意あるコード生成のようなユースケースに対する安全性研究を行う必要がある
- 自動評価および人手評価のための安全データセット活用と、敵対的プロンプトに基づくレッドチームも推奨される
次のステップと参考資料
- Code Llamaは、研究、産業、オープンソースプロジェクト、NGO、企業など複数の部門のソフトウェアエンジニアを支援するよう設計されている
- 基本モデルとInstructモデルが提供できるもの以上に、さらに多くのユースケースが残されている
- Metaは、Code Llamaが他の人々にとってLlama 2を活用し、研究や商用製品向けの新しいツールを作るきっかけになることを期待している
- 関連資料
1件のコメント
Hacker News のコメント
llama.cpp でほぼすぐに動作するので、ローカルで簡単に試せる: https://github.com/ggerganov/llama.cpp/issues/2766
CodeLlama-7b-Python を q4_0 量子化で動かしてみたところ、「最初の10個の素数を出力せよ」という Python プロンプトに対して、
print_primes、is_prime、mainまで含むそれらしいコードを生成したより大きなモデルが、特にコミュニティによるチューニングや、より良いコンテキスト／プロンプトを経たあとでどうなるのか興味深い
primes_upto(limit: int)でブール配列を使って合成数をマークし、itertools.isliceで最初の10個だけ出力すれば2 3 5 7 11 13 17 19 23 29になるprint("1, 2, 3, 5, 7, 11... and so on!Llama2 も1か月以上前に出たが、何週間もアクセス待ちの状態で、このモデルも同じフォームを通るのであまり期待できない
別の方法で受け取ったのか気になる
もちろんほとんど定義の問題で、1を素数とみなすコミュニティや分野があるかもしれないが、言語モデルを使うとこうした微妙さが表に出る
¹) https://www.google.com/search?q=is+1+a+prime+number
個人的に重要なのは、最大100,000トークンのコンテキストで安定した生成を提供するという部分
すべてのモデルは16,000トークンのシーケンスで学習され、最大100,000トークンの入力でも改善が見られるという
ただ論文を読んでみると、重要情報の検索精度は16kトークン以降で大きく悪化しており、100kコンテキストが実際にどれほど有用かはまだ見極める必要がある
論文には Unnatural Code Llama が出てくるが、MBPP pass@100 で Code Llama Python にわずかに負け、HumanEval pass@1 で GPT-4 にわずかに負ける場合を除けば、すべてのベンチマークで他のモデル／微調整を圧倒している
Meta は後でこのモデルを公開しないとだけ述べ、説明はしていないので、それほどすごそうなモデルをなぜ出さないのか気になる
幅100kの Transformer 層をそのまま使うのはコスト的に不可能なはずだが、どんなトリックを使ったのだろう
Code Llama の 7Bモデルでさえ、Copilot の背後にあるモデルである Codex と競争力がありそうに見える
https://ai.meta.com/blog/code-llama-large-language-model-cod...
GitHub も「Copilot X」とともに GPT-4 側へ移行すると何度も述べてきた[1][2]
[0] https://github.blog/2023-07-28-smarter-more-efficient-coding...
[1] https://github.com/features/preview/copilot-x
[2] https://github.blog/2023-07-20-github-copilot-chat-beta-now-...
コーディング中に「こういうランダムなことはどうすればいい？」といった質問用に 7B をターミナルのタブで常に立ち上げているが、個人的にはほぼ Google/Stack Overflow の代わりになっている
Code Llama Python は Python 向けに特別にチューニングされていて非常に興味深い
Rust 全般に強いモデル、Linux 全般に強いモデル、ゲノミクス全般に強いモデル、物理モデリング全般に強いモデルのように、特定分野の LLM を作り、互いに対話させて協力して問題を解かせることはできるのだろうか
機械を本当に働かせる、かなりぶっ飛んだ未来になりそうだ
ただし小さなモデルを多数使うというより、大きなモデルをいくつか使う方式である可能性が高い
数か月前に Godot スクリプト向けに似た試みがあり、かなり良いとされている: https://github.com/minosvasilias/godot-dodo
これまで試みが多くなかったのは、ベースの Llama が他の強みに比べてコーディングがそれほど得意ではなく、Starcoder のようなものが相対的に埋もれていたからだと思う
まだ知らないなら Society of Mind を検索してみるといい
C は十分に低レベルでありながら、まれな瞬間には今でも読める
最高のモデルである Unnatural Code Llama は公開されていない
おそらく GPT-4 ベースのデータで学習されており、OpenAI の利用規約に違反する可能性があるためだろう
“Unnatural” 論文[1]によると、“unnatural” データは何らかの LLM の助けを借りて生成されるもので、できれば最も優れた LLM を使いたいはずだから
[1] https://arxiv.org/pdf/2212.09689.pdf
TheBloke は冗談ではない[1]
今日中に量子化版が出てきそうだし、3090 にぴったり収まりそうな 34B Python 4ビット量子化モデルを試せるのがとても楽しみ
[1] https://huggingface.co/TheBloke/CodeLlama-13B-Python-fp16
ollama run codellama:7b-instructhttps://ollama.ai/blog/run-code-llama-locally
さらに多くのモデルが今も追加されている: https://ollama.ai/library/codellama
Code Llama をローカルで動かすには、7B パラメータの量子化版をオープンソースツール Ollama でダウンロードして実行できる: https://github.com/jmorganca/ollama
ollama run codellama "write a python function to add two numbers"補完用モデル、Python モデル、さらに多様なパラメータ数のモデルもまもなく追加予定
100,000 トークンのコンテキストウィンドウは悪くないが、100K トークンを超えるコードベースを扱うとき、組み込み型のコードモデルがどのコンテキストを選ぶのか気になる
こうしたツールが広く使われ、依存度が高まることを前提にコーディングするなら、新たに考慮すべき点が出てくるのかも気になる
コメントをもっと多く、あるいは少なく書くべきなのか、トークン消費を抑えるために、より短くて読みづらいコードを書くべきなのか、ファイル構造や命名規則を変えるべきなのか、結局こうしたツールを最大限活用するには、私たちはどう適応すべきなのかが気になる
コードをコンテキスト非依存にしてトークン消費を抑えるよう縮めることはできるかもしれないが、そうすると人間にとっても言語モデルにとっても、より混乱しやすくなる
極端に言えば、
i、j、kのような1文字の関数名や変数名だけを使うと、モデルは何も推論できず、適当なでたらめを作ることになる解決策は、すでに複雑性を管理するときにやっているように、大きな作業を小さな ブラックボックスモジュール と API に分解し、トークンを大量に使う実装を隠して利用側には関係なくすること
関数シグネチャ、良い説明、いくつかの使用例を LLM に渡せば、実装を知らなくてもその関数を使える
簡潔さは LLM のコード処理能力を下げるだけで、コンテキスト長の問題は解決できず、最善の場合でもスケールしない
100k トークンは十分に多いので、そんなことをする必要はない
この情報は LLM に見せやすいよう圧縮できる
例えば C++ クラス内のメソッド実装を生成するには、そのクラスをコンパイルするときにコンパイラが見るヘッダーファイルの圧縮版を LLM に渡せる
空白とコメントを削除し、マクロを減らせば、かなりトークンを節約できる
標準ライブラリのヘッダーは微調整の過程で LLM がよく知っている可能性が高いので、省けるかもしれない
一般的な前処理済み C++ ファイルは、ある程度最適化しても 100K の上限に達することがあるため、LLM に渡す前に追加の精製を行う ミドルウェア が必須になる
モデルはより良い推論と提案を行う
データでも同様に、適切にタグ付けされたデータと説明的なフィールド名が、LLM の回答をはるかに役立つものにする
こうしたツールの普及が、同僚の開発者たちにようやくコードへコメントを書かせ、3文字の変数名をやめさせるきっかけになればと、ひそかに願っている
GPT-4 にどのファイルを渡すかを選ぶ方式は埋め込みベースだった
各ファイルの埋め込みと、指示文から作った埋め込みに簡単な処理を加えて、関連性が高そうなファイルを選んだ
完璧ではないが、中規模のコードベースではほとんどの場合十分で、非常に大きなコードベースには向いていなかった
この実装のせいで、ファイルをより短くし、内容を別のファイルへ移し始めた
1,000 行を超えるファイルはコンテキストウィンドウを使い切ってしまうので負担が大きく、100k のコンテキストウィンドウならそれほどではないだろうが、ファイルはもともと短く保つのが良いと思う
ファイル全体ではなく個別の関数やクラスを埋め込んで渡すような、もっと賢い方法もあるので、近いうちに誰かがより良いものを作るはず
AI を活用するためにコーディングパターンを変える必要は、ほとんどない可能性が高い
分割されたコードを1つの大きなファイルにまとめ、コメントを減らし、空白を削除する作業は、LLM 用のプリプロセッサができる
Copilotはこれまでうまく動いてきたが、インターフェースに限界がある
次のテキスト片を予測することしか知らないように見える
「この行は繰り返しなので関数に切り出したほうがいい」「この構造はこう変えると使いやすい」といったリファクタリングを提案するコードAIを誰が作っているのか気になる
Cody.devではリポジトリ全体に対する埋め込みを作れるので、コードベースと解決しようとしている問題について、はるかに大きなコンテキストを持てる
ちなみに数週間前にSourcegraphに加わった
まだ堅牢なものはないと思う
コードをハイライトして依頼すればよく、Code Llamaの使用にも対応している: https://continue.dev/docs/walkthroughs/codellama
IntelliJ IDEAはすでにローカルでどちらも進んで提案してくれる
大きな重複コードの塊を見つけて自動的に関数へリファクタリングできるし、コードをより明確にするリファクタリングを提案するインスペクションも多い
最後に聞いた時点ではベータ版で、うまく動いていなかった
例のページでも「add types」ブラシは
aとbをnullチェック対象にしていて厳しすぎるし、「fix simple bug」はほとんど単なるタイプミス修正だこういうモデルを自分で動かしたことがない完全な初心者としては、どんなハードウェアが必要なのか気になる
READMEではうまく見つけられなかった
ソースコードを大手テック企業にアップロードせずにこうしたモデルを使えるという考え方は本当に気に入っている
アプリをインストールしてシェルコマンドをいくつか実行するだけでいい
おそらくこのモデルも近いうちに提供されるだろうし、そうなればContinueのVS Code拡張と一緒に使えそうだ
やや遅いものの、必要な大容量RAMがなくてもスワップが十分な代替手段になっているようだ
Ollamaは13Bモデルの実行には32GBが必要だとしているが、16GBのMBPで
llama2:13bモデルを動かしている7Bはスマートトースターでも動かせるくらいだ
そうでなければ、llama.cppのCPU推論はたいていのマシンで動くはずだ