00:05
こんにちは、セヤさん、よろしくお願いします。
よろしくお願いします。
今回、この回を収録日時点で3日後、4日後に、私がLTしてくるんですけど、
せっかくなので、それを題材に話そうかなと思っています。
テーマとしては、タイトルまだ全然悩んでいるというか、決めかねているんですけど、
プロンプトの自動化、自動チューニングみたいなところとかをテーマにしようかなと思っています。
いきなり話を振っちゃいますけど、セヤさん、このプロンプトの自動プロンプティングとか、
自動でプロンプト生成するとか、JITSMでも普段、何かChatGPで使うときとか、何でもいいんですけど、
やったりとかされてますか?
いや、やってないですね。
プロンプトチューニングは、タイトルを台無しにするようなあれかもしれないんですけど、
プロンプトチューニング自体に困ることがそんなにないというか、
割と評価のデータセットをしっかり作っていたら、それにめがけてゴニゴニをすればいいだけなんで、
そんなにそこでめっちゃ困るというイメージがないという感じですかね。
そうですね。その辺とかは結局どれだけの頻度で変えようとしてるんだっけってところにも依存をするとは思うので、
そんなでも正直、1日何回も変えるとかはやってないですよね。複数人でとか多分。
それはないですね。
ことしては、プロダクションにとかプロダクターに何か使うようなプロンプトとかをガンガン自動生成してますっていうのは僕も正直なくて、
どっちかっていうと、大体このLTで話そうとしてることは結局この一言で終わるんですけど、
評価基準とかどこを目指してどの基準で行こうだよねっていうのが定まってたら、
あとはそこに向かって少しずつ頑張るだけと言えば頑張るだけ。
自動化できるよねっていうのは全然そうだろうなと思いますし、
逆に構成的には評価とかその辺考える方が圧倒的に辛いだろうなとは思いますし、
プロンプト自体もそんな品高く改善するようなプロダクトとか、
それで価値が出るような構造になってる環境もまだ希少かなと思うので、
そもそもそんなに今現時点だとめちゃくちゃこの自動化すること自体にすごいニーズがあるっていうような感覚はないんじゃないですね。
03:04
自動化って呼んでるものの中に一つ、
今言ってるのは最終的にシップするものに向けて良くするっていうのは他に、
最近オープンAIのプレイグラウンドでプロンプトジェネレーターとか、
あとVertexでもプロンプトファインダーみたいなものが入ってたりするんですけど、
そっちはティンガンブソートとかそういうのに乗っ取って現状のプロンプト改善してくれるみたいなものとかがあったりするので、
そういう方面を指すみたいな、そっちの方面があるかもって感じですね。
オープンAIとか、それでいうとクロードも出てますけど、
プロンプトジェネレーターとか、メタプロンプトみたいなやつとかを最初結局プロンプトを書くときに使うとかは全然やるので、
自動化と呼んでも結構幅はありはありますね。
どこまで自動化するんだっけみたいなところとかは。
その辺とかは多分他の中でのレベルなのかカテゴリーなのか分類なのかみたいなところだったりとか、
どこを結局どこまで自動化するんだっけっていうのはあるので、
整理自体はないと話が逸れる、話が認識がずれるっていうのはありそうだなって感じはしますね。
そんな感じで一応プロンプティング。
ざっくり最初の時点とかではそんなにどのレベルの自動化みたいなのとかは定義せずに、
もともとLT考えてたんですけど、
プロンプティング自体最近ちょっと前のリサーチだと思うんですけど、
マイクロソフトがBuilding Your Own Product Copilotっていうリサーチ出してて、
要するにそのコーパイロットみたいな機能を開発してるソフトウェアエンジニアに、
どういう開発タイクルだったりとか、
普段のソフトウェア開発の違いをヒアリングしてリサーチして、
サブンとかまとめましたよみたいなリサーチだったんですけど、
そこでプロンプティングエンジニアリングどうやってるかみたいな話とかもちょろっと書かれていて、
初期フェーズ特に初期フェーズは、
プレイグラウンドみたいなところでアドホックで環境で実験して、
何かしらの評価基準みたいな何かしらの基準があって、
そこをもとに試行錯誤を繰り返して、
一番良さげなパラメータ組み合わせみたいな特定してっていうような、
そういうようなみんな踏んでプロンプティングエンジニアリングやってますみたいな話をしてましたと。
アンソロピックもプロンプティングエンジニアリングライフサイクルだったかな、
みたいなやつとかで似たようなことを書いていて、
06:00
結局プロンプトで何したらいいんだっけってところから、
何したら成功、プロンプトは良いと判断できるんだっけっていうのがまず決めて、
そこに向かって評価と改善、リファインメント繰り返して、
こうやってたらいいよねっていうやるっていうのがざっくり、
プロンプティングのサイクルみたいなのがあるとしたら、
基本的には抽象化するとこういうフローなのかなと思ってますと。
オートメイテッドプロンプティングとかの特に一番コアの発想とかは、
基本的には何らかの評価が可能で必要基準があるんだったら、
その基準で優れた出力になり得られる組み合わせの探索の自動化自体はできるよねっていうのが基本的なアイディアかなと思っていて、
なので結局評価とかそういう基準を作るとか、
その辺は結局変わらないなって感じですね。
これもセヤさん何かの記事で触れた気がするんですが、
これ結構前ですよね、オートメイテッドプロンプティングエンジニア、
2022、3年ぐらいとかに改訂というか修正みたいなのされてたんですけど、
最初2022年とかなので。
これもいわゆる入力と出力のペアがあって、
そこに一番近いプロンプと自動生成するみたいな形。
ここで入力と出力っていうのが評価じゃないですけど、
基準、ここにこれを出したいっていうようなところで、
ここは基本的には当たり前ですけど、
我々が整備したきゃいけないところなので、
ここまでできたらアウトプットやすいプロンプと得られるっていうのは、
自動化したよねっていうのは前からの通り、
買おうとした自然だなって感じですね。
オートメイテッドプロンプエンジニアに関してだけ言うと、
確かこれ評価はスコアはつけていくけど、
評価基準の言語化とかはたぶんそんなしない感じですよね、確か。
確かですね。
インプットとアウトプットは定義していたセットとして渡します。
それにプロンプトが何個かというかバーッと生成されて、
それにスコアがついているんですけど、
そのスコアは普通にオートメイテッドエンジニア側、
プロンプトエンジニア側が出してくれてて、
たぶんスコアがついているんですけど、
そのスコアは普通にオートメイテッドエンジニア側、
プロンプトエンジニア側が出してくれてて、
たぶんちょっと詳細分かってないですけど、
インプット一番アウトプットを出しやすいプロプトっていうのを
なんとなくスコアつけて、
それで判断できるようになっているが、
それ以上はないって感じだと思いますね、確か。
そうですね。
これメリットとデメリットというか、
評価基準を言語化するテーマとかはやってるんですけど、
説明可能性みたいなものがちょっとなくなっているっていう、
09:06
いいところと悪いところがあるなっていう印象ですね。
そうですね。
僕もちょっと読んでくらいなのであれですけど、
こんな感じのやつとかが、
論文とかも結構いろんなのがありましたけど、
普通にツールみたいな感じとかで動かせるやつとかも
最近ちょこちょこ出てて、
たぶん全部収集しきれてないんですけど、
僕が触ったことあるやつだと、
マイクロソフトがこれも半年くらい前なのかな、
サモっていうライブラリー出してて、
これエンジニアリングオプテマイズライブラリー
みたいなこととか確か書いてたんですけど、
シンプルにそのLLMの並列実行とかを簡単に
プログラミングっぽくより書けますっていうような、
そういう仕組みもあるんですけど、
さっきのAutomated Prompt Engineerみたいに、
これも確かインプットとアウトプットを出したら
プロンプト生成してくれるみたいな、
そういうプロンプトの最適化機能とかもあったりとか、
Auto Promptも僕一時期手元でちょっと動かして
自動生成したノテーションできて、
それを元にまた最適化してみたいなやつですね。
発想としては似てる、ちょっと差分はありますけど、
大体やろうとしてることの大枠は一緒なものとかは、
数としてはいっぱい出ている。
その辺とかのアウトプットとか、
オープンAIのプロンプトジェネレーターとか、
そっちを使ってると思うので、
他にプロンプティング自動化しますみたいな、
普通にPythonで動くみたいなライブラリとかって、
ご存知だったりするものって他にあったりします?
他にプロンプティング自動化しますみたいな、
春先ぐらいに記事にまとめたやつで、
多分私の知識は止まってるんですけど、
このサモンも知らなかったんで、
他に何かあったっけなぁ。
なんかね、ちょこちょこあったというか、
見たことあるような気はするんですけど、
ちょっと出てこなくて。
なんかね、
多分ね、発想としては、
自然とは自然だから結構あるんだとは思うし、
プロンプトライブラリの中の機能として
そういう機能が載ってますぐらいだったら、
多分結構あるんだと思いますけど、
それでいうと、最近、
Pythonのプロンプトライブラリの中の機能として、
そういう機能が載ってますぐらいだったら、
多分結構あるんだと思いますけど、
それでいうと、最近、この辺とかは全然僕、
12:01
まだ概要見たぐらいしか見れてないですけど、
なんかラグのチャンクサイズのパラメーターとかを
チューニングしますとか、
ちょっとプロンプティングから外れますけど、
エージェントがエージェントを生成しますみたいなやつとか、
結構リサーチとか、
リファレンス実装レベルとかが出てきていて、
それも発想としては似てはいますよね。
ラグとかも確かテストのデータセットがあって、
そっからテンプレート元にテストデータセットとか、
強化のメトリクスとか選べなくて、
ラガスとかだけになっちゃった気がするけど、
いろんなラグのチャンクサイズとかプロンプトとか、
自動チューニングしますっていうところも、
プロンプティングの拡張版みたいなのが出てきてるので。
強化期限と移動強化みたいなものをしっかり作って、
大地化みたいなのは、
プロンプトだけじゃなくて、
こういう今おっしゃってきたような、
ラグのパイプラインとか、
チャンクサイズもそうですし、
ラグって結構いろいろ、
クエリをどう作るかとか、
因数がいろいろあるんで、
コアが高くなるものに最適化してくれるみたいな、
そっちの方、
プロンプト最適化も嬉しいは嬉しいんですけど、
そういう変数がいろいろ組み合わさったシステムの最適化とかも、
応用していきたいなっていう感覚はありますよね。
そうですね。
僕も最近ラグみたいなこととか作ってて、
当たり前ですけど、プロンプトよりは取り得る、
探索範囲が広いというか、
さっきのチャンクサイズみたいな話とか、
プロンプトだけじゃなくて、
クエリ拡張みたいなアプローチを入れるんだっけとか、
そういうとこまで含めるとたくさんあるので、
どこまで自動化できるかは、
とにかくラグとかの設定とかをチューニングしてくれるの方が、
結構頑張って、頑張ってというか、
実運を乗せるために頑張ってみるかっていうモチベーションにはなる。
プロンプティングぐらいだったら正直、
評価基準とか作れたタイミングで、
あとは時間があったらやるぜ、
みたいな感じにもしかしたら、
なっちゃうかもしれない状況によっては。
この辺とかはディスパイ、ディスパイって読むのかなこれ、
ディスパイって読む?
これ多分なんだけど、
後ろがPythonのPyらしいですよ。
PyTorchとかと同じようなノリか。
DSPyとかも多分、
僕もちょっと変わったぐらいの記憶が止まってるんで、
もうだいぶ曖昧なんですけど、
パイプラインっぽいの作ってとか、
DSPy側とかで最適化したいなと思うので、
ディスパイって読むのかなこれ、
ディスパイって読むのかなこれ、
ディスパイって読むのかなこれ、
15:00
DSPy側とかで最適化する、
オプテパイザーみたいなコンポーネント、
モジュールがあったりとかするので、
そういうのとかが、
使っていく方向には向かうんだろうなと思いつつ、
プロンプティング自動化は結局評価とか、
その辺とかあったらできますよねって話ですね。
そうですね。
1個DSPyの重箱の隅に落ち着く話をすると、
DSPyの改善の仕方って、
評価データセットの中からうまいことスコアが上がる、
フューショッツの組み合わせを見つける、
みたいな感じだったと思うんですけど、
ちょっと私が昔調べた時点から変わってなければ、
それが評価データセットと同じように、
プロンプトに使っちゃってるので、
いわゆる学習用のデータとテストデータを分けていない、
みたいな感じには、
もしかしたらなっちゃってるかもしれないので、
他のメソッドはいろいろあるんですけど、
そういうフューショッツを使う方式は、
ちゃんと成果出ると思うんで、
だからすごい悪いと主張するわけではないんですけど、
細かい内容とか見ていくと楽しいかなっていう、
そんな感じです。
そうですね。
細かく見ていくと結構アプローチが違ったりとかするので、
サモンを覗いたときどうだったかな、
ちょっとサモンを全然覚えてないな。
よくよく見ていくと微妙に違ったりとかはするし、
シンプルにライブラリが登場するタイミングが、
なんだかんだ1年ぐらい前に出たやつとかも全然あるので、
タイミングとかで、
今見ると結構ナイブな実装になってるみたいなのとかはある気がしますね。
それとDSPyとかもどこまで使われてるのかって言われると、
僕はあんまり使ってる例自体知らないっちゃ知らないんで。
そうですね。
使われてるかどうか自体があんまりよくわからないっていう。
そうですね。
使ってみた感はあるんですけど、
DSPyに限って言うと、
フロント実行の部分までDSPyがコードを持っちゃってたんですよね、確か。
なので、
ラングチェーン、あれどうだったっけな。
ラングチェーンでLLM叩いてる既存のコードがあるときに、
それを乗り換えるのがちょっとめんどくさいなと。
そうっすよね。
そこまで。
DSPy側でチェーンオブソートとかをモジュール化して持ってて、
ここでこれコッド使えますみたいなのを、
18:02
パイプラインみたいなのを設計できる、
ワークフローみたいなのを設計できる、
みたいな思想だったと思うので、
プロダクション、プロダクトで使われるっていうか、
今だとラングチェーンとかに完全に負けてるような気は正直しなくはない。
そうですね。
あんま効かないなっていうのはそうですね。
僕も試してみて、使うとこまで行ってないっていうのもありますけど。
なので、結局あれなんですよね。
もともとダウンロードしてたんですけど、
LTE自体が確か今注目してる技術みたいな話とかだったので、
僕の直近の一番インプットしたいこととして、
オートメートプロッティングみたいなところとかを選定したんですけど、
結局評価大事だなみたいな話とかが終わっちゃって、
そんなにDSPyとかちゃんと深掘れてないから、
そういう話になったんですけど、
これも最近パーセルが出してた、
Eval Driven Developmentみたいな記事出してて、
要するにAIプロダクトみたいな開発、
筆記決定論的な性質があるので、
今まででいうE2Eテストとかに近いような扱いとして、
Eval大事だよねっていう話。
その評価の仕方自体も、
例えば正規表現とかこのキーワード含まれてたらみたいなので、
選べるとか、それで評価できるものももちろんあるので、
コードベースみたいなのでやるやつと、
人間が見るってやつと、
あとLM使った、LM as a judgeみたいな、
この評価3つぐらいはあるよねって話と、
今までで言うE2Eテストとかに近いような扱いとして、
Evalドリブンで評価して、
その評価とかを元にモデルの性能を向上させるためのデータを
さらに収集して、プロダクト作って、
ユーザーからのフィードバックを元にまたモデル改善して、
評価もアップデートしてみたいなサイクルを回すっていうのを
AIネイティブフライウィールみたいな、
そういうのを主張してる方とか、
似たようなこととかはいろいろあると思うんですけど、
そういうようなのもバーセル自体も結構主張しようと、
主張というかテックブログを書いてたりしていて、
結局この流れとかそういうフライウィールみたいなのを
自体が構築できてたら、
そのうちプロンプティングをある程度探索自動化します
みたいなものだったりとか、
っていうのはめちゃくちゃハードに
フィードバックループが回る仕組みを作る方が
圧倒的に先ですし、
そこがないと自動化しても判断、
よしよしの判断ができなかったりとか、
結局人間の評価がボトルネックになるから、
そこだけちょっと自動化しても、
めちゃくちゃ全体で見たときにリリースされるかもしれないので、
そこがないと自動化しても判断ができなかったりとか、
21:01
人間の評価がボトルネックになるから、
そういうのをめちゃくちゃ全体で見たときに
リードタイムとか上がらないと思うので、
っていうのにまた戻ってきたんで、
結局プロンプティングの話はあんまりしてないですけど、
このLTの中で。
そうっすね。
私も感覚すごい分かるというか、
最初プロンプトの自動化に夢を見て、
いろいろ調べたんですけど、
結局どの手法も評価を、
自動評価でうまいことスコア出すみたいなものが必要になってきていて、
でなると、そこがどう…
そもそも今そんなうまくできていないっていう、
私の会社での課題が目の前にあって、
じゃあ先にそれ解かないと自動化にも何もできないから、
そこの歯を調べても仕方ないなみたいな気持ちになったというか、
まずそっちだなみたいな。
僕もそんな、別に面白いんで、
調べること自体を否定するものではないんですけど、
優先の理由と評価とかの方が先だなっていうのはそう。
だから改めて今回調べてみて、
何かしらの合否というか、
よしあしを判定するために何かが結局必要。
なのでそれを何かが必要っていうのは変わらないので、
そこの基準とかの与え方とかがちょっと異なってたりとかはしますけど、
大体やっぱ何かが必要っていうのは変わらないので、
それをどこから作りますかって言われると、
多分我々が作るプロダクトとかドメインに特化した評価データセット、
インアウトみたいなところを流用して与えるっていうことにしかならないので、
そこが整備されてきてから、
ようやくちゃんとプロンプティングの自動最適化を一番ちゃんと楽しめそうだなって感覚はあるんで、
もうちょっと将来に行きたいって感じですね。将来の自分に行きたいっていう感じもある。
結論としては。
なのでバーセルがイーバールドリブンみたいな話とかしましたけど、
本当は昔のソフトウェア開発という自動テストって、
品質というよりかは高速に回線し続けるためにも必要だよねみたいな話であると思うんですけど、
それがまさしくLMプロダクトにおける評価みたいな、
結局そういう結論で終わりましたね。
このプロダクションAIエンジニアリングスタートミスイーバルじゃないですけど、
結局こっちの話をして終わりました。
どう考えても、だいたいLMプロダクト改善の話、評価に落ち着くというイメージがあるので、
24:08
そうだよねっていう感じですね。
そうなんですよね。
結局テーマとテーマに沿った話になったかどうか、
謎のLTが結局仕上がって、厳密にはまだ仕上がってないから明日もやるんですけど。
流れとしてはすごい自然だと思いますけどね。
いろいろ手法があるけど、
どれを選ぶことになっても評価基準の策定とかいるよね。
だから結局これだよねみたいな。
そうですね。
まさしく前段の一応プロンプティングってなんだっけとか、
何が結局難しいんだっけとかっていうのを話の流れとして入れようってなって、
それ入れていくと結局評価の話になって終わる。
ざっくりそんな感じでLTとかをまた回収してくるんですけど、
最後ちょっと感想的なとことかで言うと、
最近っていわゆるエージェンテックワークフローとかフルエンジニアリングとか言われるような、
そういうのとか組まれてるプロダクトの裏側で、
ディパイとかでも何個かいろいろ連ねて何か作るとかやってる方とかいらっしゃると思うので、
個人的にはそういうフローエンジニアリング的なところまで自動生成とかチューニングとかやってほしいというか、
フローエンジニアリング的なところに自然とある程度なる中で、
特定のプロンプトだけ自動でチューニングするっていうのも大事は大事。
結局それを全部集めたら全体のフローになるので大事なんですけど、
結局その辺一気通貫でやらなきゃいけないって話になりそうな気がするので、
プロンプティングの自動最適化のライブラリは面白い面白いと思いつつ、
あれを使って全体のフローを見た上でそれを最適化するっていう、
また何か別なライブラリが登場するか、そういうのを我々は組むっていうのをやらないと、
現実そんなに開発スピードめっちゃ上がるっていうこととかにもならないんだったら、
そこまでやらないとインパクト薄いだろうなと思うので、
その辺とかそういうライブラリが出てきたりとか、
自作したいなっていうのはめっちゃ今改めて思ってます。
分かるんですね。
私たちももともとエージェンティックワークフローで3段ぐらいのプロンプトで作ってたものが、
ちょっとルースケースが変わったときに、
むしろ1プロンプトで済ませたほうが性能高いみたいな評価した結果ですね。
27:02
みたいなことがあったんですけど、
そういう今おっしゃっていただいたのって、
我々常に自分たちで定義してたエージェンティックワークフローがあったんですけど、
それすらもいい分割の仕方とかを勝手に探索してくれて、
見つけてくれるみたいなものだと思うんですけど、
人間がいろいろ考えるのも楽しいんですけど、
自動で探索してくれるのがすごい、
そっちのほうが最適化されやすいと思うので、
そこまでできるとすごいかっこいいなって感じですね。
かっこいい。そうなんですよね。
こういうの探索とかチューニングすること自体も、
試行錯誤するのも楽しいというか、嫌いじゃないんで、
全然自動化しなくても俺にやらせてくれよって気持ちは正直あるなと思うんですけど、
これフローエンジニアリング的なとこまで自動生成チューニングしたいですよねみたいな話。
やっぱりドメインの、それこそエキスパートとか現場の人とかにヒアリングしていくと、
めっちゃすごい細かい知識、
例えばこの実務ってこのウェブページとかを原点に回ってるから、
ここだけ見とけばこの領域のラグは別にこれで大丈夫みたいな、
適切にできればとか思ってて、
そういうのとかが結構細かく見ていくと、
この法律の場合はここでいいとか、
この法律の場合はここでよくて、
だいたいこの辺のQAが来るからこれ答えられたらここはOKみたいなやつとか、
そういうのやっぱりヒアリングしていくと結構そういうのはあるなって思っていて、
その時に僕がいちいちプロンプト書いてとか、
このフローエンジニアリングみたいなフローを作っていくと、
効率化したい業務の数からするとめちゃくちゃ単純に人手が足りないみたいな状態なので、
どっちかっていうと僕がそういうのを自動生成するみたいなところの仕組み作り頑張って、
もうちょっとメイン知識持ってる人とかがガンガン自動生成して、
チューニングとかは難しいと思うのである程度、
消化データセットとか作るところとかはちょっと手伝ってもらって、
それもとにある程度いい感じにチューニングするみたいなものとかを7割とか8割とかやってくれたら、
多分いろんな業務とかワークフローで効率化するみたいなのをスケールさせられるんだろうなっていうのを思う機会がありまして、
そういうのとかやろうとすると、
全然違うエンジニアリング貢献ができる領域があるので、
個人的には次半年はこの辺とか探索したいなっていう感想ですね。
30:01
これは強いんですかね。
やっていきたいですね。
今回はちょっとそんな感じですけど、
一応最後まとめていくと、
ウメティテプロンプティングとかは、
先ほど聞いたラーマンさんで充実できるようになったらいいなっていう感じがするので、
一応最後まとめておくと 埋めていったプロンプティング とかは結局評価基準とか何かしらの出力基準みたいなものっていうのは
当然求められるので そこの仕組みだったりとか そこの評価データセットみたいなのを アップデートしていく仕組みっていうのを作るっていうのが
多分プロンプトの自動化みたいな意味でも 基本的には寛容だなっていうところ
当然普通にプロンプトジェネレーターとか パッと使うとかも圧倒的に便利なので
このプロダクトにガンガン自動化頑張るみたいなのとか抜きにして 色的なプロンプトは別にジェネレーター使えますとか
そういうところから始めつつ 最終的にはラグのチューニングとか フローエンジニアリングの自動性質チューニングみたいなところとかに
業界としては多分進んでいくんだろうなと思うので 多分僕も瀬谷さんもやっていきっていうようなまとめかなと思います
ちょっと勝手にまとめちゃいましたけど まだ話し足りないこととかこのネタであったりしますか
やっていきでしかないですね
そうですね やっていきということで 今回の回はこれで終わりにしようと思います
もし面白いと思ってくださったら フォローをしていただけるととても嬉しいです
では 本日はそんな感じで 瀬谷さん ありがとうございました
ありがとうございました
