そこで､ 前日に構築したソリューションをもう一度見直して､ 測定基準について話をしよう｡
今申し上げたように､ 私たちは非常にシンプルなビジネス中心の指標で業績を測定し､ 業績を評価しています｡
単純にコードのパフォーマンスだ｡
コードはどれだけ速くなったか？
そして明らかにクロード3だ｡ 5ソネットはそれを打ち砕き､ トップランナーとして､
GPTフォーゼロがミッションに失敗することもあったが､ 成功することもあった｡
そして残念なことに､ コード・クワンは､ 私が言うように､ まともな努力をしたが､ システム・プロンプトを通して強制的に結果を出そうと何度か試みたものの､
正しい結果を得ることはできなかった｡
わずかなズルも十分ではなかった｡
クインには70億のパラメータがあり､ クローズドソースでは1兆をはるかに超えるパラメータがライバルになる｡
だから､ それができたという事実そのものが､ 信じられないほど印象的なんだ｡
それとは別に､ 運営費､ つまり0ドルであることを忘れないでほしい｡ 80､ 私は推論エンドポイントとして稼働するために1時間を支払っていた｡
それはさておき､ 無料である｡
オープンソースだ｡
だから､ APIのコストは払っていない｡
特にGPUを持っている場合は､ GPUを動かすための電気代以外にコストはかからない｡
とても印象的なモデルだよ｡
たった70億のパラメーターを持つオープンソースのモデルが､ 円周率を計算するためにそのコードを変換するようなことができるのは､
率直に言って異常なことだ｡
そこで､ この時点で皆さんに課題を紹介したい｡
そして今週､ 私はそのいくつかを手に入れた｡ それはとてもハードなものだが､
とても充実し､ 満足のいくものだ｡
時間があることを願うよ｡
この数日間のレクチャーは､ 時間を空けるために比較的簡潔なものにした｡
これで､ これまで学んできたことの多くがより確かなものになるだろう｡
微調整すべき点がいくつかある｡
解決策はすでにある｡
クローズドソースのモデルにジェミニを追加することで､ ジェミニはクロードとジェミニのGPTとなり､ さらにオープンソースのモデルを追加することもできる｡
私が提案したように､ コード・ラマとスターコーダーを加えれば､ コード・ジェンマを強制的に働かせることができるかどうかがわかるだろう｡
乱数ジェネレーターを書き換えないように､ 積極的なプロンプトを出すことで､ そうならないように説得できるかもしれない｡
ええと､ 僕より運があるかどうか見てみて｡
もしそうなら､ どうかコードをプッシュしてほしい｡
見せてくれ｡
他の人たちにも教えてあげよう｡
そうすれば､ 私たち全員がその恩恵を受けることができる｡
そしてそれは
そうだね｡
本当に素晴らしい｡
ぜひ試して､ 結果をシェアしてほしい｡
でも､ それなら
しかし､ そんなあなたには､ コードを生成する能力を必要とする3つの難題がある｡
それは次のレベルに進むことになる｡
そこで､ 本当に素晴らしいアイデアをいくつか紹介しよう｡
そのひとつは､ コードにコメントやdocstringを自動的に追加できるコーディング・ツールを書くことだ｡
すでにそれを実現する製品がいくつかあることは知っているが､ 自分でやってみて､ それが機能しているのを確認し､
自分のためにこれを実行するのに十分なコードかどうかを確認するのは素晴らしいことだ｡
もうひとつは､ ユニットテストを書けるツールだね｡
ユニットテストは､ 私たちの人生の悩みの種だ｡
ああ､ とても過酷なものだよ｡
また､ ユニットテストが単に関数の入出力を複製するだけで､ 何か賢明なことをするわけではない場合､
ユニットテストは非常に稚拙に書かれることがある｡
そこで､ 特定のPythonモジュールのユニットテストケースを生成するために､ フロンティアモデルや､ もしかしたらオープンソースモデルを使うことができるかどうかを見てみましょう｡
そして最後に､ これは本当に楽しいものだ｡
そして､ 私はこれをやった｡
だから､ 私自身はエンターテインメントとしての価値だけでこれを持っている｡
そして素晴らしい｡
素晴らしいよ｡
そして､ シミュレートされた環境で株式の売買を決定するコードを書くコード・ジェネレーターを書くことを試すべきだ｡
もっと大きなプロジェクトなんだ｡
でも､ コードを生成させるだけで､ 少しずつステップを踏んでいくことができる｡
必ずしもシミュレートされた環境が必要なわけではない｡
APIを提供するわけだ｡
株価を調べるために利用できる一般的なAPIを探すこともできる｡
あるいは､ APIを考案し､ それをプロンプトで提供するだけで､ モデルが特定の日付のティッカーの価格を取得するためにどのメソッドを呼び出すことができるかを知り､
売買の決定を行う関数を生成できるようにすることもできる｡
そうそう､ これはすごく楽しかった｡
フロンティア・モデルとオープンソース・モデルの両方を使って､ たくさんの異なる売買シグナルを構築することができた｡
ひとつ言っておきたいのは､ 何をするにしても､ もしこれをやったとしても､ 実際に売買の意思決定に使わないでほしいということだ｡
私は､ この種のモデルを使って取引を決定しないことを強く勧める｡
実際､ フロンティアモデルにこのような手法を生成するように頼もうとすれば､ そうしてくれるだろうが､
どんなことがあっても実際の取引判断に使うべきではないと警告されるだろう｡
だから､ これは厳重注意だ｡
クローズドソースであろうとオープンソースであろうと､ LMの気まぐれで名声と富を実際に危険にさらすためではなく､
純粋に自分自身の楽しみのため､ そして関係する能力を確認するために使ってください｡
しかし､ これは素晴らしいプロジェクトだ｡
きっと楽しめると思うよ｡
もし誰もやらなかったら､ 僕のコードを共有するかもしれない｡ でも､ まず第一に､ 僕は君に挑戦状を出したんだ｡
もしあなたが売買シグナルを出したのなら､ 私はあなたに挑戦する｡
もちろん､ シミュレートされた環境においてのみですが､ 私たちが生成したさまざまな取引機能のうち､
どちらが偽の市場でより多くのお金を稼ぐことができるのか､ あなたと対決してみます｡
そうだ｡
それはあなたにとって本当に楽しいプロジェクトになるはずだし､ みんながどんなものを考え出すのか見るのが待ちきれないよ｡
それで､ あなたはそれを信じるだろうか？
信じられるか？
私たちは､ 熟練したLMエンジニアになるための旅の50％地点に到達したところです｡
もう半分まで来ている｡
少なくとも､ いくつかの宿題をこなし､ いくつかのプロジェクトを作り上げた後では､ その道半ばだ｡
というのも､ 私が言うように､ 学ぶための最善の方法は実践することだからだ｡
それができたら､ 自分を褒めて､ 50％は達成できたと言える｡
そして次回は､ ラグ・スーパーホットトピックについて､ そしてラグの背後にある大きなアイデアについてお話しする予定です｡
そして､ Ragのおもちゃバージョン､ つまりRagの背後にある大きな考え方であるベクトル・データベースと呼ばれるものを導入しないシンプルなバージョンを実装します｡
だから､ そのすべてにたどり着くのが待ちきれない｡
来週は本当に､ 本当にエキサイティングになりそうだ｡
そしてもう一度､ LLMSマスターへの道のりの半ばにいることを心から祝福したい｡