見出し画像

Kaggleの生成AI集中コースより、古のNLPエンジニアが興味を持ったこと7選

べいえりあ

こんにちは、IVRyでPrincipal AI Engineerをやっているべいえりあです。今回はタイトルの通り、Kaggleの生成AI集中コースを見て目に留まったこと、そしてそれらについての個人的なコメントを書いていこうと思います。

本記事はIVRy Advent Calendar 2024の白組の初日の記事です。紅組はCEOの奥西が「SaaS+AIの未来予想」という記事を書いています。
2日目は特命係長のサトケンさんがこの一年の特命活動を振り返ります。

Kaggleの生成AI集中コースについて

こちらのコースです。

タイトルには生成AIとありますが、画像生成AIなどはほぼほぼ登場せず、基本的にはLLMをどう使うのかについての講義となっています。講義は

  • ホワイトペーパー

  • Code lab

  • 講義動画

の3つのパートから成っています。ホワイトペーパーで各トピックの技術的詳細を学び、Code labで実践し、それを元に講義動画で復習したり専門家たちのディスカッションを聞くという感じです。時間が無くてLLMについてある程度の知識のある方であれば、ホワイトペーパーは講義動画観てから気になるところを読む、くらいでも何とかなる印象はあります。

ホワイトペーパーは各トピックについてかなり詳しく書いてある印象で、例えばLLMのホワイトペーパーを読むとTransformerからLLMのアルゴリズムや歴史、軽量化の手法や応用まで、かなり詳しくなれるんじゃないかという気がしています。

Geminiって最近どうなん？

こちらはKaggle／Googleが作っている講義なので、LLMとしてはChatGPTやClaudeではなくGeminiが使用されています。

Geminiは初期はChatGPTにだいぶ遅れをとっていたの思うのですが、最近の自分の印象は、

  • いろんな意味でChatGPTに追いついている

  • Gemini 1.5 FlashはGPT-4o miniとほぼ同じノリで使える（何ならGPT-4o miniより速くて安い）し、Gemini 1.5 ProはGPT-4oとほぼ同じノリで使える

  • 推論ヘビーで高性能なo1、音声出力できるRealtime APIのようなものはまだ無いが、本番ユースケースでこれらのモデルはほぼ使わない気がする

という感じなので、現在であればLLMを学ぶ上でGeminiから始めてもまあいいんじゃないかという気はしています。

興味を持ったこと7選

というわけで、以下が自分が講義を見て興味を持ったこと7選です。「筆者コメント」の部分にそれぞれの項目について自分が思ったことや補足事項を記載しています。

（主に分類に使用する）列挙型モード

出典：Day 1 Prompting Code Labより

一般的にLLMの出力はフリーテキストになるが、Geminiでは以下リンクのようなコードを書くことで出力を指定した列挙型のいずれかに制限することができる。

＜筆者コメント＞
LLMはテキストを生成する応用が注目されがちですが、与えられた文書を理解する（Andrew NgのGenerative AI for Everyoneで言うところのReading）応用でも非常に有用です。そのような応用の中でも、テキスト分類（与えられたテキストの感情分析を行う、何かが言及されたか否かを分類する、トピックに分類する、etc.）は最もよく行われる応用の一つかと思います。このテキスト分類を行う際にこちらの列挙型スキーマは非常に有効だと思います。

一応、列挙型モードが無くてもある程度はpromptingを頑張ればほぼ列挙型のみを出力するようにはできるとは思うのですが、いらない説明をつけたり微妙に列挙型から外れた出力をしてしまう可能性をゼロにはできないわけで、出力の形式が保証されているというのは予期せぬエラーを避ける意味でも良いんじゃないかと思います。

ただし、以下の論文のように出力形式を制限すると精度が下がるみたいな話はあるので、使う場合はちゃんと精度検証をするのが無難かとは思います。

Promptingのベストプラクティス

出典：Day 1 "Prompt Engineering" Whitepaperより

以下のようなベストプラクティスがある。

  • 例を与えよ（Few-shot prompting）

  • プロンプトは簡潔かつ明快であるべし

  • 出力形式は細かく指定せよ

  • 制約よりも指示を心掛けよ（Don'tよりDoを使う）

  • 出力長をコントロールせよ

  • プロンプトを再利用できるよう変数を用いてテンプレート化せよ

  • （できれば複数人で）いろいろ実験せよ

  • 分類でfew-shot promptingを使う際、学習データをシャッフルせよ

  • モデルの更新に適応せよ

  • Promptingでいろいろ試行したことはドキュメントに落とせ

＜筆者コメント＞
Promptingのベストプラクティスは様々なところで語られていて、例えばOpenAIはこちらで、Anthropicはこちらでベストプラクティスを公開していたりします。

Few-shot examplesが強いとか、制約を与えるよりも指示しろなどは割とどこにでも書かれていると思うのですが、使うべきaction verbを列挙してくれてるところとか、これまでにやった試行錯誤をドキュメントに落とせという話はあまり見たことが無かったので、有用に感じました。

入力コンテクスト長の増加とRAGの関係

出典：Day 2 講義動画より

入力コンテクスト長が延びるとRAGがいらなくなる（検索対象の文書を全てコンテクストに入れてしまえば良い）のでは？という話はあるが、

  • 現状の100万トークン程度だと不十分な応用例はたくさんある

  • コンテクスト長が延びると計算量が大変なことになる（一方でベクトル検索は非常に効率的な実装がある）

  • 関係ないものをコンテクストに入れると精度が落ちる

などを考えると実際はそんなに簡単な話ではなく、結局はまずretrievalでコンテクストに入れる対象を絞りこんだ上で答えを生成するというRAGのアプローチが相変わらず有効であると思われる。

ただし入力コンテクスト長が延びたことでRAGにもご利益はある。これまでは入力コンテクスト長が短かったのでretrievalの部分でprecisionを重視せざるを得なかったが、コンテクスト長が延びたことによりprecisionがそこまで高くなくても良くなったのでrecall重視にできるようになり、retrievalの段階で情報が抜け漏れる可能性が減った。

＜筆者コメント＞
こちらはretrievalがrecall重視に寄せられるようになったというのは確かにそうだよなと思ったのと、上記のような構図は伝統的な情報検索でも一般的な気がしています。

情報検索ではよく

  1. 軽いモデルで関連文書を広くとってくる（この段階ではrecall重視）

  2. 重いが性能の良いモデル（巨大ニューラルモデルなど）で関連文書のrerankingを行い、検索の精度を上げる

というアプローチをとります。こちらでも計算量や関係無い文書を入れた時の精度劣化から、基本的にはrerankingのモデルに全てをやらせるのではなく、まずは軽いモデルで関連文書を選別するのが一般的です。RAGでの文脈でのLLMは情報検索におけるrerankingモデルのような立ち位置なんじゃないかと思っています。

NotebookLMについて

出典：Day 3 講義動画より

NotebookLMは2024年のTime誌のInvention of the Yearにも選ばれたLLMサービスで、端的に言うと物事を理解するためのツールである。

各種ドキュメントをアップロードしておくと、LLMがそのドキュメントの知識に基づいたやり取りをしてくれる。また、どのドキュメントのどの箇所を参照にしたかも提示してくれるので、ファクトチェックを行ったり、元のドキュメントをより深く読み込んで知識を深めることができる。

＜筆者コメント＞
全然技術的な話ではないのですが、個人的に面白かったのがNotebookLMを作ったSteven Johnson氏は自身がそのサービスの一ユーザーであるということです。自分が読んだり書いたりした大量の文書を全て知っていて、それらについて質問できるサービスを求めていたとのことで、やはり自分がペインを感じてるサービスを作るのが一番上手くいくんじゃないかと思いました。

モデルの進化とエージェントの進化の関係

出典：Day 3 講義動画より

エージェントの構成要素についてはLLMが出てきた当初からそんなに変わっていないが、モデルの進化に伴い各コンポーネントはより簡単になっている（ここあんまりよく分かっていないですが、多分planningとかtool useとかがモデルの進化によってpromptingや下記のchainingを頑張らなくても比較的簡単にできるようになったという話かなと思っています）

＜筆者コメント＞
一般論として、下記のポストでも言われているようにモデルが進化するに伴い必要な構造は減っていくものなので、いろんなものが簡単にできるようになっていくのは納得できる気がしました。いずれは、

  • 使えるツールがたくさんあって

  • 解こうとしてるタスクも多岐に渡りかつ複雑で

  • 使用できるデータも雑多に入っている

みたいなケースでも最低限のプロンプトで動く自律型エージェントが出てきたりするんでしょうか。

精度を上げる工夫：Chaining

出典：Day 5 "MLOps for Generative AI" Whitepaperより

難しい問題、特に段階的な推論が必要な問題などについては、一つのプロンプトでその問題を解ききるのは難しい。そのような場合、divide and conquerの要領で問題を複数のタスクに分解してそれぞれをLLMその他を用いて解くというアプローチが有効なことがある。このようなデザインパターンをchainingと呼ぶ。

＜筆者コメント＞
Chainingについては自分のXなどをフォローしていただいてる人にはお馴染みの話かと思っていて、compound AIとかflow engineeringと呼ばれているものと基本的には同じものだと思っています。

ホワイトペーパー読んでて目を引いたのが、このアプローチをdivide and conquerの一種としているところで、compound AIの話は自分がどんだけXで呟いても全然普及しないのですが、divide and conquerという古くから知られたアルゴリズムの一種と考えることで、皆さんにも腹落ちしやすくなるかもと思いました。

MLOpsとLLMOpsの違い

出典：Day 5 講義動画より

  • 多くのユーザーがモデルの学習を行わずにLLM APIをそのまま使うようになったので、（fine-tuningをしない限りは）学習に伴う面倒さが無くなった

  • プロンプトの管理などは増えたが、これらは比較的簡単である

  • Toxicityやタスク特有の評価指標などに集中できるようになった

  • 出力形式が制限されなくなったため、ガードレールなどを入れる必要が出てきた

  • 自分でモデルをホストする必要が無くなったので、オートスケーリングが不要になった

＜筆者コメント＞
個人的にはオートスケーリングというか、たくさんリクエストが来た時のわずらわしさが無くなったのがめちゃめちゃデカいと思っています。

LLM以前の機械学習だと基本的には自前でモデルをホストしていたため、特に大きなモデルを使う場合などにたくさんリクエストが来ると非常に困っていた（待ちが発生する／対応するためのオートスケールしようにも時間がかかる、etc.）と思います。今はLLM APIプロバイダーの方々がそのめんどくささを引き受けてくれるようになり、我々はrate limitとAPIが落ちた時の処理だけ見ておけば良くなったので、機械学習システムの運用が非常にやりやすくなったと思っています。

最後に

以上、自分がKaggleの生成AI集中コースを見て興味を持ったこと7選でした。これらはあくまで自分が興味を持ったことで、これら以外にも講義の中で大事な情報はたくさんあると思うので、LLMについて学びたい皆さんはこの記事を読んで満足せず、実際にコースを受講してみるのがいいんじゃないかと思います。

IVRyではAIエンジニアを絶賛募集中です。

今回はLLMの基礎知識について書いたわけですが、IVRyでは複数のLLMプロジェクトが走っており、LLMをいじり倒すという意味では最高な環境なんじゃないかと思っています。LLMを使ったサービスを極めたい方は是非応募してみてください！

いいなと思ったら応援しよう！