みんな知っているよ｡
つい先日のことのように思えるが､ 私たちは今､ 4週目に入り､
急速に中間地点に近づいている｡
さて､ 今回は何が待ち受けているのだろうか？
ええと､ 今週は核となる知識を構築するのに不可欠な時期に入る｡
今回は､ 私たちすべてに襲いかかるこの非常に挑戦的な問題､ つまり､ 私たちは選択の余地を奪われているということについて話すつもりだ｡
世の中にはたくさんのLLMがある｡
クローズドソースかオープンソースか､ 決断しなければならないことはたくさんある｡
そして､ それぞれのカテゴリーで､ 非常に多くの選手がいる｡
目の前の問題に適したLLMを選ぶにはどうすればいいのか｡
それが今週のメインテーマだ｡
さらに､ 私たちはオープンソースの土地で私たちのためにコードを書いてくれるllmsを構築するコードを生成することになるだろう｡
それは楽しみだね｡
ええと､ 今日私たちがやろうとしているのは､ タスクに適したモデルを選ぶにはどうすればいいかというテーマについて､
さっそく考えてみることだ｡
オープンソースのモデルを比較するのに役立つ､ Hugging
Faceの素晴らしいリソースであるOpenml leaderboardというものを使うつもりだ｡
その前に､ もちろん､ 8週間を振り返ってみよう｡
左からやり直した｡
私たちは右で終えるつもりだ｡
週目だ｡
私たちはフロンティア・モデルについて語り､ 6つのフロンティアLMSを比較しました｡
第2週はGradioのエージェント化でUIを紹介し､ 第3週はもちろんマルチモダリティで遊んだ｡
先週､ 私たちはオープンソースにどっぷりはまった｡
私たちはハブを調べ､ ハイレベルAPIとパイプラインを調べ､ そしてトークナイザーとモデルを調べました｡
そして､ これらのチャット・インターフェースがどのように機能するのか､
そしてこれらの辞書のリストがどのようにトークンになるのかを理解するという点で､ 多くのことがまとまったと思います｡
第4週は､ LMSの選択と､ 非常に興味深いコード生成の問題についてだ｡
第5週がラグであることを願う｡
第6週は微調整｡
トレーニングを始めるときだ｡
フロンティアでのトレーニング､ そしてオープンソースでのトレーニング､ そしてそのすべてを統合する｡
これが8週間のプランだ｡
それで今日は､ モデルの比較､ LMSの比較についてお話しします｡
そして､ このセッションから1つ収穫があるとすれば､ 最も重要なポイントは､ このLLMが他のLLMより優れているというような単純な答えがあるわけではないということだ｡
ベストからワーストへというランキングではない｡
何を達成しようとしているのかがすべてだ｡
そして､ 目の前の課題に適したLLMを選ぶことだ｡
ですから､ さまざまなLMSを比較検討し､
要件と比較することが重要です｡
その第一は､ モデルに関する基本的な事実だけを見ることだ｡
ええと､ モデルの値段のような明らかなものです｡
そうすれば､ 決断の幅が狭まり､ 選択肢が少なくなる｡
そして､ 基本的な属性や異なるモデルの基本的な側面を調査したら､
次に詳細な結果を調べ始める｡
そのためには､ ベンチマーク､ リーダーボード､ アリーナといったものを見る必要がある｡
そして､ これらすべてを踏まえて､ 最終的にあなたのタスクに最適なLLMを選択するためのプロトタイピングに使用する候補のLLMを手に入れる必要があります｡
それで､ 基本的なことを少し話そう｡
だから､ 基本的なことを比較すると言ったのは､ 異なるモデルについて評価しなければならない最も明白なことを意味しているんだ｡
そして､ オープンソースモデルかクローズドソースモデルかを理解することから始める｡
そしてもちろん､ 長所と短所があり､ 他の基本的な属性の多くに影響する｡
そこで､ 候補リストを作成する際､ 最初にメモしておくべきことは､ オープンソースかクローズドソースかということだ｡
発売はいつですか？
発売日はいつですか？
しかし､ 注意すべき重要な点は､ 知識のカットオフとは何かということだ｡
日付は？
学習データの最終更新日｡ それ以降は通常､ 現在の出来事に関する知識を持たない｡
そして､ あなたのユースケースによって､ それはあなたにとって重要かもしれないし､ そうでないかもしれない｡
次にパラメータの数｡
これでモデルの強さがわかる｡
また､ かかるコストの強さもわかるだろうし､ どれだけのトレーニングデータが必要かもわかるだろう｡
そのモデルを微調整したいのであれば､ それについても少しお話ししましょう｡
パラメーターの数､ モデルのサイズも基本的な事実のひとつで､ トレーニング中に使用されたトークンの数をメモしておく｡
トレーニングデータセットのサイズは重要なポイントで､ モデルのパワー､ そのレベル､
専門知識の深さ､ そしてもちろんコンテキストの長さ､ コンテクストウィンドウの大きさを改めて感じさせてくれる｡
過去に何度も話したことだ｡
次のトークンを予測する間､ 効率的にメモリに保持できるトークンの総量は､ オリジナルのシステム､
プロンプト入力プロンプトを含む必要がある｡
また､ チャットのユースケースで指示する場合､ ユーザーとアシスタントのやりとりはすべて､
コンテキストの長さに収まる必要がある｡
マルチショット・プロンプティングを扱う場合､ 推論時に複数の例を提供してモデルに学習させるのであれば､
それらの例をすべて取り込むのに十分なコンテキストの長さを確保する必要がある｡
今日の文脈の長さが最も長いモデルを覚えていますか？
ええと､ ジェミニ1号｡ 5フラッシュに100万サイズのコンタクトウインドウがある｡
これが基本中の基本だ｡
もっと基本的なことに目を向けてみよう｡
だから､ 気をつけなければならないコストがたくさんある｡
推論コスト､ トレーニングコスト､ ビルドコストに分けてみた｡
つまり､ 推論コストとは､ 入力が与えられたときに出力を生成するために､ 本番でこのモデルを実行するたびにどれだけのコストがかかるかということである｡
簡単に言えば､ 推論とはそういうことだ｡
オープンソースかクローズドソースか､ あるいはどのようなやり取りをするかによって､ さまざまな種類のコストが発生する可能性がある｡
もちろん､ フロンティアモデルでは､ APIコストについて考えていることは知っている｡
Proのユーザーインターフェイス､ チャットUIを使うということであれば､ サブスクリプション､ つまり月額のサブスクリプション費用を考えていることでしょう｡
また､ オープンソースのモデルを自分で実行するのであれば､ 実行時の計算コストがかかるでしょう｡
これは､ 共同研究コストのようなものかもしれませんし､ このコースの最終週には､ 本番環境へのデプロイ方法についてお話しすることになるでしょう｡
モーダルのようなプラットフォームを考えてみると､
GPUボックス上でモデルを本番稼動させることができる｡
オープンソースのランタイム・コンピュートもその要因のひとつだ｡
通常､ 自分でトレーニングしたオープンソースのモデルを使用している場合､
推論コストは低くなる｡
毎回API使用料を支払う必要はない｡
でも､ 明確な計算はできない｡
ユースケースによる｡
モデルの選択､ パラメーターの数などによる｡
そしてトレーニング費用｡
だから､ 箱から出してフロンティア・モデルを使うのであれば､ トレーニング・コストはかからない｡
さらに微調整をするのでなければ､ 第7週にすることになる｡
しかし､ もしオープンソース・モデルを構築し､ それを自分の専門分野に特化させ､ トレーニング費用やトレーニング付きで提供するのであれば､
それにはコストがかかる｡
それを方程式に組み入れる必要がある｡
建設費｡
では､ この解決策を作るのにどれだけの労力がかかるのか｡
そして､ それは次の「市場投入までの時間」に大きく関係している｡
フロンティア・モデルを使うことのセールスポイントのひとつだ｡
それが市場投入のタイミングなのか？
また､ 建設コストも非常に低く抑えることができる｡
フロンティア・モデルを使った強力なソリューションの立ち上げには､ ほとんど時間がかからない｡
通常､ 独自のオープンソースモデルを微調整しようとすれば､ より時間がかかり､
より難しくなる｡
つまり､ フロンティア・モデルを使ったレート制限を検討する上で､ 電話できる頻度の制限にぶつかる可能性があるということだ｡
これは通常､ サブスクリプション・プランの場合である｡
それと､ もしかしたら､ 料金制限もあるかもしれない｡
私は､ APIを通じてフロンティア・モデルを使用する際にも信頼性を指摘している｡
GPT4とクロード3の両方で経験したことがある｡
5ソネットのAPIは､
その時間帯は生産が忙しすぎるため､ 負荷がかかりすぎているというエラーで応答する｡
これはレート制限に関連するものだが､ ある種の安定ポイントであり､ スループットの一種であるスピード､ つまり､ どれくらいの速さでレスポンス全体を生成できるか､
どれくらいの速さで新しいトークンを生成できるかということだ｡
そしてとてもよく似ている｡
スピードとレイテンシー（リクエストの応答時間）には微妙な違いがある｡
と尋ねると､ トークンごとにどれくらいのスピードで返答が始まるのですか？
私たちが航空会社のためにAIアシスタントを開発したときのことを覚えていらっしゃるかもしれない｡
そこではレイテンシーが少し問題になった｡
その時は言わなかったと思うけど､ テキストがある時はもちろん､ それがモデルに送られるから､
気まずい間があったんだ｡
フロンティアモデルに呼びかけ､ オーディオを生成し､ 戻って来てオーディオを再生する｡
そして､ 画像を生成しているときはさらに衝撃的で､ 画像が戻ってくるまでに時間がかかり､
私たちはそこに座って画像を待っていた｡
もちろん､ 私たちのプロトタイプでやったよりももっと潔くそれを処理する方法はある｡
もしあなたが独自のオープンソースモデルを扱っているのであれば､ それはあなたがよりコントロールしやすいものであることを覚えておいてほしい｡
そして､ 基本中の基本だが､ 間違いなく重要なのがライセンスだ｡
オープンソースであろうとクローズドソースであろうと｡
使用できる場所､ 使用できない場所など､ ライセンスの制限を十分に認識しておく必要がある｡
ええと､ オープンソースのモデルの多くは､ 非常にオープンなライセンスを持っています｡
うーん､ 中には細かい字が書いてあるものもある｡
安定した拡散というのは､ ある程度までは商業的に使うことが許されている｡
収益があるレベルを超えると､ その時点で何らかの､ 安定した普及のためのビジネスアレンジメントが必要になる｡
そして､ 私たちは､ ラマ3との利用規約にサインした｡ メタで1｡
でも､ ライセンスの一部であることは認識しておく必要がある｡
基本的なことは以上だ｡
これらはすべて､ 目の前のタスクに対するモデルのパフォーマンスや精度をより詳細に分析する前にメモしておくべきことだ｡
そして､ 次のセッションに続く｡