LLMニュースの新しいエピソードへようこそ。ここでは、AIと大規模言語モデルの世界に関する最も興味深くエキサイティングな発展をお伝えします。始める前に、まだの方はチャンネルにいいねと登録をお願いします。それによってチャンネルの運営に役立ち、皆様のためにこれらの動画を続けることができます。
まず最初は、AnthropicからのClaudeのプロンプトキャッシングに関する重要な発表です。Geminiでもキャッシングのサポートがあることは以前の動画でお伝えしましたが、AnthropicもAPIコールでこの機能を有効にし、Anthropic APIですぐに利用可能になりました。これにより、長いプロンプトの場合、コストを最大90%、レイテンシーを最大85%削減できます。プロンプトキャッシングは、Claude 3.5 SonnetとClaude 3 Haikuのパブリックベータ版で今日から利用可能です。
プロンプトキャッシングの使用方法はいくつかありますが、将来的にAnthropicのこの特定のプロンプトキャッシング機能の使い方について、より長い動画を作成する予定です。別のチュートリアルを用意しますので、お楽しみに。
ここで推奨されているプロンプトキャッシングの使用例は、会話エージェントです。これらのエージェントは潜在的に高いレイテンシーを持つ可能性があり、レイテンシーの問題からプロンプトキャッシングは会話エージェントに非常に適しています。コーディングアシスタンス、大規模文書処理、詳細な指示セット、エージェンティックな検索、ツールの使用などもあります。エージェントを構築する際、ツール使用メカニズムがあり、関数やツールの定義などを含める必要があります。これを非常に繰り返し行うため、それをキャッシュして再利用するのは良いでしょう。ただし、時間制限があるので、それに対応する必要があります。
本、論文、ドキュメント、ポッドキャストとの対話も可能です。これは恐らく今日のプロンプトキャッシングの最も一般的な使用法でしょう。理由は、単に文書をアップロードしてプロンプトを与えることができるからです。プロンプトキャッシングの考え方は、その文書、本、論文などをキャッシュし、それに対してクエリを行うことです。キャッシングに対して1回だけ課金され、その後はユーザー入力に含まれる内容に対してのみ2回目の請求が発生します。
価格設定はこちらに記載されています。異なるモデルに対して非常に明確です。例えば、100万トークンあたり3ドルが課金され、プロンプトキャッシングの場合は100万トークンあたり3.75ドルが課金されます。これがキャッシュへの書き込みで、1回だけ行います。その後の呼び出しでは、100万トークンのキャッシュ読み取りに対して30セントが課金されます。つまり、かなり安くなります。3ドルを再度支払う必要がないのです。
キャッシュへの書き込みは基本入力よりも25%高くなりますが、キャッシュされたコンテンツの使用は基本入力トークン価格のわずか10%のコストで、はるかに安くなります。その後の利点が得られ、キャッシュに書き込む必要があるため、最初のリクエストは少し遅くなる可能性がありますが、その後のリクエストははるかに高速になります。
ここに多くの例を含む優れたドキュメントがあります。このプロンプトキャッシング機能の使用方法についての独自の例を紹介するチュートリアルを行う予定ですので、お楽しみに。
次に、XからのGrok-2のリリースに関する発表があります。これはGrokの次のイテレーションです。詳細はこちらで確認できます。Grok-2とGrok-2 miniをリリースしており、これらはすでにXプラットフォーム上のGrokユーザーが利用可能です。実際に先週これを試してみて、コード推論や指示遵守能力などさまざまなテストケースでモデルをテストする動画を作成しました。非常に優れたモデルで、LLMリーダーボードでもかなり良いランクを獲得しています。テストしてみると、非常に優れたモデルだと感じました。彼らが言うには、さまざまなタスクでClaude 3.5 SonnetやGPT-4 Turboを上回る性能を発揮できるとのことです。
LLM6リーダーボードには多くの更新がありました。これは現在、最も能力の高いモデルまたは最も能力の高いLLMをモニタリングするためのコミュニティリーダーボードの1つです。特にChat Arenaについて話をしますが、この特定のSalsカラムRがGrok-2の早期バージョンで、まだ公開されていないことがわかります。12,000のコミュニティ投票を獲得し、GPT-4と同じく3位にランクインしています。これは5月のチェックポイントで、Gemini 1.5 Pro実験版という別の素晴らしいモデルと、先週の最新のチェックポイントであるCH GPT-4 latestのすぐ下にランクされています。これがChat Arenaの結果と更新です。
次に、Genieモデルについてです。これはソフトウェアエンジニアリングAIシステムで、非常に難しいベンチマークであるS-SWBenchで最先端の結果を達成しました。30.8%を達成し、2番目に優れたモデルと比較して57%の改善を示しています。ここでさまざまなモデルを見ることができますが、どのようにしてこれを達成したのかと疑問に思うかもしれません。本質的に、彼らは推論データセットに多くの焦点を当てています。ブログでより詳細に読むことができますが、要するに推論データセットに多くの努力を注いでおり、それは理にかなっていると思います。過去の研究やプロジェクトで見てきたように、推論データセットはこれらのモデルを強化します。
さらに、彼らは検索、計画、書き込み、実行のネイティブ機能を持つエージェンティックシステムも可能にしています。彼らのモデルはこれらすべてを行うことができ、また自己改善を含めて、発生したミスを修正し続けるモデルを改善しています。このレシピが、これらの最新のエージェンティックシステムが特定のタスクに本当に優れているために支持しているものであるように見えます。この分野をフォローしている場合、これらの取り組みのいくつかを見てみるのが良いでしょう。特に研究側での新しいアイデア、最近のデータセットについての人々の考え方、自己改善がどのように進歩しているかなどです。
これは、Andre Karpathyが以前に書いた特定の投稿を思い出させました。彼は、LLMの理想的なトレーニングデータは、あなたが書いたものではなく、あなたの内部の考えの完全な配列と、あなたが書いている間のすべての個々の編集であると述べています。しかし、あるものでやっていくしかありません。次のステップは、データセットをより深く掘り下げ、それらのプロセスがどのように見えるかをより良く表現するデータセットを可能にし、言語モデルがダウンストリームタスクに役立つパターンを学習できるかどうかを確認することです。
次に、Paulのこのブログ投稿があります。この特定のブログ投稿が気に入った理由は、実践的であり、非常に有用な洞察を提供していると思うからです。ご存知のように、構造化された出力とJSONタイプの出力を使用するアイデアについての動画を作成しました。彼らが主張しているのは、彼らの実験に基づいて、LLMがJSONでコードを返すのが本当に苦手だということです。彼らが言っているのは、すべての形式やすべてのタイプのコンテンツがJSON出力に適しているわけではないということで、コードはその1つのようです。彼らはいくつかの詳細とその理由について言及しています。
分析の結果、LLMは多くの構文エラーを引き起こすことがわかりました。ブログ投稿をチェックできますが、実際にMarkdownを使用することが、少なくともコードに関しては自由形式のテキストの方が良いようです。これは実験する必要があるものです。つまり、利用可能な機能だからといって、構造化された出力を単に使用するだけではなく、実際にパフォーマンスを損なう可能性があり、エラーにつながる可能性があります。この場合、JSONでコードを使用した際に構文エラーやインデントエラーが発生しました。そのため、非常に注意深く扱う必要があり、そのためにこの投稿を強調したかったのです。
次に、Saken AIと他のいくつかの研究者によって発表されたこの論文があります。この論文は本当に気に入りました。先週の私のお気に入りの論文の1つで、実際に論文を読んで要約もYouTubeチャンネルで行いました。これらの論文の説明も行っています。これが本当に私の注目を集めた理由は、彼らがこれらのエージェントワークフローを使用して、科学的発見のプロセスを基本的に自動化しようとしているからです。少なくともそれがAIサイエンティストの目標です。彼らは最先端のLLMを使用しており、LLMを一から構築しているわけではありませんが、この種のエージェントを構築するために必要なコンポーネントを把握しようとしています。これにより、自動的な科学的発見が可能になります。
ここで彼らが行ったことは非常に興味深く、実際に注目に値します。なぜなら、論文の作成と執筆のプロセスを自動化したからです。研究者であれば、そのプロセスがどれほど面倒で難しく、時間がかかるかご存じでしょう。彼らは15ドル以下でこれを行うことができると主張しています。つまり、その価格で完全な会議レベルの科学論文を作成できるのです。
この論文で本当に気に入った部分の1つは、生成された論文を自動的に評価する自動レビューアのアイデアでした。彼らは論文スコアの評価において、人間に近いパフォーマンスを達成したと主張しています。人間と比較して、これらの論文をどのように評価し、基準などを評価しているかを比較できます。
少し見過ごされた発表の1つはAgent Qでした。これも同じ線上にあり、自己改善できるエージェントを構築するというものです。Genieで見たような自己改善コンポーネントは、これらのエージェントを構築する上で本当に重要な部分になってきています。自己改善する能力ですが、そのためには実際に良いデータが必要です。彼らがここで提案しているのは、さまざまなタスクを達成できるエージェントです。
彼らがそれを達成する方法は3つのコンポーネントを使用することです。ここにそのコンポーネントが表示されています。彼らはモンテカルロ木探索を使用しており、これは基本的に異なるアクションとウェブページを探索することでデータを自動的に生成するためのものです。本質的に、高いサンプリング温度と多様なプロービングを使用してMCTSによってアクション空間を拡張しています。これらは小さな詳細ですが、この問題に適したよりエージェンティックなタイプのデータセットを持つための探索が本当に重要なコンポーネントであることがわかります。私たちが取り上げた他のエージェントでも、その特定のコンポーネントがありました。
もう1つの重要な要素として浮上しているのは、システムが自己批評や自己判断を行う能力です。つまり、出力に対して何らかのフィードバックやフィードバックループを提供し、エージェントの意思決定プロセスを洗練させることです。現実世界ではタスクを完了するのに多くのステップがかかる可能性があり、実際に長い時間がかかる可能性があることを私たちは知っています。実際には、多くの異なるタスクを完了する必要があるかもしれません。そのため、彼らはここで、このステップレベルのフィードバックが長期的なタスクにとって重要であると述べています。スパースな信号が学習の困難さにつながることがよくあるからです。これは、多くの努力と異なる部分を必要とするタスクにとって非常に重要なコンポーネントです。
これは驚くべきことではありませんが、直接的な選好最適化を使用して、探索中に探索された最適でないブランチを含む集約データセットから効果的に学習し、複雑な環境での成功率を向上させています。これは重要です。なぜなら、最良の種類の出力と最も好ましい種類の出力を見つけ出すモデルを本当に作りたいからです。そのためにこのプロセスは非常に重要です。
彼らはALPaCA-7Bモデルで結果を検証し報告しています。これが実際に機能することを示すためです。彼らは18.6%の成功率から81.7%へと、わずか1日の自律的なデータ収集後に340%のジャンプを達成しました。さらにオンライン検索を拡張することで95.4%まで向上しました。これは信じられないと思います。
次に、1週間前に紹介したこの非常に興味深い論文があります。この論文は基本的にRAGシステムの効率を改善することを目的としています。この論文で提案されているアイデアが本当に気に入った理由は、全体的なRAGシステムの効率を向上させるモデルを調整しようとしているからです。RAGシステムでは多くのAPIコールを行う必要があり、通常これらの大規模言語モデルで行います。これらの複数のLLMコールをどのように最小化し、回避できるでしょうか。
これが彼らが提案しているフレームワークです。基本的なアイデアは、チャンクのラベル付けとタグ付けを行うためにツーエンコーダー言語モデルをトレーニングすることです。ここで質問が入力され、次にリトリーバーがあり、その後に小さなチャンクがあります。基本的にチャンクを「終了」または「継続」として分類します。「継続」の場合、次のステップであるフィルターモデルに送られます。このモデルは、元の質問と以前のアノテーションに基づいて次のホップクエリを作成するようにトレーニングされています。このプロセス全体が繰り返し行われます。目標は、最初の質問に答えるのに十分な情報を集めることです。最後のジェネレーターが最終的な回答を生成し、そのようにシステムが構築されています。
本質的に、2つのコンポーネントが反復的で効率的なシステムを構成し、RAGを使用して正確で複雑なマルチホップ質問応答を実行します。これは効率的です。なぜなら、以前に述べたように、マルチホップQARAGでのクエリ生成に典型的な複数のLLMコールを回避するからです。
とにかく、論文をチェックしてみてください。RAGの効率を向上させるこれらのアイデアはすべて興味深いと思います。誰もがRAGシステムを使用したいと考えていますが、使用しているさまざまなコンポーネント、行っているすべてのAPIコストなど、それらはすべて多くのリソースを消費し、おそらく非常にコストがかかるでしょう。したがって、フィルターモデルやチャンクのラベル付けとタグ付けに使用されたオートエンコーダーのような専用コンポーネントを持つこのような代替案を検討することは、本当に興味深いと思います。これらのRAGシステムのコストと効率を最小限に抑えるために提案されるこれらのアイデアがますます増えていくでしょう。
次に、この別の論文があります。rStarを提案しており、これは自己対戦型相互推論アプローチで、ファインチューニングや優れたモデルを必要とせずに、小規模言語モデルの推論能力を大幅に向上させると主張しています。彼らは優れたモデルの必要性を排除し、ファインチューニングの必要性を排除し、小規模言語モデルに焦点を当てて、推論能力を向上させ、本当に強力な問題解決者にできるかどうかを見ています。
彼らは自己対戦型相互推論を使用しており、これは生成-判別プロセスです。ここでの最初の部分は、小規模言語モデルであるターゲットSLMです。これは自己生成器であり、ここでの説明を見ることができます。自己生成器は、候補の推論軌跡を生成するためにターゲットSLMを拡張します。彼らは再びモンテカルロ木探索を使用しています。これらの軌跡を探索するためのモンテカルロ木探索を見てきました。Agent Qで始まり、それは重要なコンポーネントの1つでした。合成データを生成するためのウェブエージェントを生成する際の重要なコンポーネントでした。ここでも同じケースです。
判別器は、これとは別の小規模言語モデルで、部分的なヒントに基づいて各軌跡に対する教師なしフィードバックを提供します。これを別のフィードバックループと考えることができます。Agent Qで見たように、これは別の重要な部分でした。これらのコンポーネントがすべて、これらのエージェントにとって非常に重要なものとして浮上しているのが分かります。これが現在のエージェント研究で本当に興味深い点です。この自己改善コンポーネント、探索と活用のバランスを取るためのMCTSが見られます。
最後に、彼らがここで行っているのは、ターゲットSLMを使用することです。このLM2によって生成されたそれらのフィードバックに基づいて、ターゲットSLMが解決策として最終的な推論軌跡を決定します。これは非常にシンプルなフレームワークですが、拡張し続ける多くの機会があると信じています。小規模言語モデルの使用は私にとって非常に興味深いです。小規模言語モデルは、ご存じのように大規模なものほど能力がありませんが、これらの小規模モデルを良好に蒸留したり、大規模なものと同じくらい能力のある小さなバージョンに剪定する方法があるため、このような方法には大きな可能性があると思います。これは明らかに、この分野が向かっている方向と非常に一致しています。
最後の発表は、その同じアイデア、つまり大規模モデルをより能力の高い小規模バージョンに調整し蒸留することに関するものです。NVIDIAがここで行ったのは、過去に取り上げたように非常に能力の高いモデルであるLLaMA 3.8Bを、大規模なものと同じくらい能力のあるNVIDIA LLaMA 3.1 Mini 4Bモデルに蒸留したことです。これらの小規模言語モデルの重要性を考えると、これは興味深い開発だと思います。
詳細には立ち入りませんが、結果に直接飛びます。このブログ投稿が気に入った理由は、実際に剪定と蒸留の説明に焦点を当てているからです。これはこの動画の範囲を少し超えていますが、興味がある場合はコメントで教えてください。剪定と蒸留のこのアイデアについてより詳細な動画を作成できるかもしれません。これらの非常に大規模な言語モデルを開発し続け、その能力を活用したいが、より効率的な方法で行いたい場合、おそらく大規模モデルと同じ能力を持つ小規模モデルに蒸留したいと考えるため、ますます重要なアプローチになると思います。すべてのユースケースで大規模なモデル、つまり汎用の大規模システムが必要というわけではありません。
ここに結果が示されています。これが元のLLaMA 3.8Bモデルで、これらが彼らが提案しているものです。これは深さ方向の剪定で、これは幅方向の剪定です。隠れ層のサイズを減らすようなものです。こちらは層を減らすことについてです。ここで元の8Bモデルとの比較結果が見られます。実際に元のモデルにかなり近いです。これはさらに改善できるはずです。拡張実験を通じてこれを改善する方法はたくさんありますが、結果のギャップが縮小しているのを見るのは実際に非常に有望です。これは潜在的に、より大規模なモデルにも適用できる可能性があることを意味します。70Bや45BのLLaMAモデルにも適用できると想像できます。
これらは小規模モデルに関する予備的な結果です。リソースがどれだけかかるかという理由だけですが、実際に剪定と蒸留を行うと、一から言語モデルを訓練したり、大規模なデータセットで言語モデルをファインチューニングしたりするのと比べてコストが低くなります。このため、剪定と蒜の考え方が本当に気に入りました。前進するにつれてより顕著になると思います。
これらは、サイズが比較可能なモデルであるGemma 2やByte 2などの他のモデルとの比較です。ここでも、非常に印象的な結果が得られています。FP8やFP6などの異なる精度でのパフォーマンスベンチマークも示されています。どの精度が最良の結果をもたらすかについて多くの議論がありますが、それもテストされました。
一般的に、深さ方向や幅方向の剪定を使用しているかどうかに関わらず、MeninaTron 4Bモデルは標準的なLLaMA 3.8Bモデルと比較して比較的よく機能していると言えるでしょう。
これでLLMニュースのこのエピソードは終わりです。皆さんにとって何か有用で興味深いものがあれば幸いです。コメントで何か興味深いものを見つけたか、質問があればお知らせください。ご視聴ありがとうございました。まだの方はチャンネルにいいねと登録をお願いします。次回またお会いしましょう。
コメント