プロンプトエンジニアリングの導入
データアナリストのりょっちです。 データサイエンティストのたっちゃんです。
LLM プロンプトエンジニアリングの本を読んできた。話題のやつね。
話題のやつですね。オライリーから出てるやつ。
そう、これはこのタイミングでちゃんと読むのがいいよって、なんかいろんな人がSNSで言ってたから、
読んでみるかと思って、読み始めた感じだね。
いっぱいいろんな人が感想を書いてるけど、
書いてるんだ。
結構見たよ、いろいろ。でも総括すると、一旦なんか実感しながら読んどいた方が良さそうだなっていうのがあったから、
読むかって提案して、2人でとりあえず読んできたみたいな感じだね。
そうですね。でもこのタイミングで読んでよかったなと思いましたね。
そうだよね。
LLMを使っている中で、あまり気にせずプロンプト書いてたけど、
こうやってプロンプト書くとちゃんとAIというかLLMが理解してくれるんだとか、
こういう仕組みに裏側なってるんだっていうのがわかったんで、学びは多かったですね。
赤ずきんの原則とマークダウン
それこそこの間、3月に出したChatGPTのAPI本の時に、
それこそプロンプトエンジニアリングのコツ何線みたいな章とかを俺が担当してたんだけど、
ちょっとやっぱ浅かったかなって思ったね。
でもオープンAIも一般ユーザーに向けてこれぐらいの内容は押さえておいた方がいいよみたいな、
なんかフューショットだったり、
あとはなんか禁止とかそういうのじゃなくて、ちゃんとルールを定めてあげる方がいいよみたいな話だったりとか、
なんかそこら辺を書いてはいたんだけど、今回の本の中とかそれこそフューショット意外と罠あるよみたいな話とか、
そうだね。
あとはなんかコンテキストをめちゃめちゃ与えればいいわけではないみたいな、
なんかそんな話とか書いてあったから、もうちょっとちゃんとやっとかないとまずいなみたいな。
どこまで書くかによりますよね。
本当に全部書こうと思ったらこの一冊できちゃうくらいの話なわけだから。
確かに。
とは言っても、こうやったらうまくいくみたいな攻略法みたいなものを提示してるわけではなかったじゃないですか、今回の本も。
あくまでこういう仕組みでできてるって言って、
それを理解した上でいろいろ試してみて、うまくいく方法を見つけるのがいいんじゃないかみたいな提案だったんで、
理解はしつつも触ってみるがいいのかなっていうところは思いましたけどね。
確かに。
これちゃんと読んだ後、確かに渡すプロンプトのなんか考え方変わるなっていうのがあったね。
まあ、どっから触れていくかというとなんか、ほら、一部、二部、三部みたいな分かり方してたじゃん。
一部はなんだろう、なんか、割と知ってる内容と基礎と歴史みたいな感じだったから、
ちょっと退屈、読んでて退屈になるかもとは思ったかな。
でもどうだろうな、その中でも、なんかこういろんな法則というか、赤ずきんの原則みたいなやつとか、
あとなんだっけ、チェイホフ、チェイホフの銃みたいなあったで、
なんかそのあたりは、なんかそんな、そんな名前でちゃんと知らなかったから、
なんかそんなんがあんだみたいな。
赤ずきんの原則って、赤ずきんの原則はモデルのトレーニングされたときのシチュエーションというか、
そのモデルの知ってる範囲をちゃんと認識して、
モデル、LLM自体が扱いやすいファイルの形で与えられた道を歩くようにしましょうみたいな。
そうだね、学習のデータに寄せた文章の書き方でLLMと会話するとうまくいくよみたいな話だよね。
そもそもマークダウンがいいみたいな、あるじゃん、通説というか、一般論として。
なんかこれもマークダウンの形でデータを引っ張ってきて学習してるっていうのが、
学習のこの過程の中でのマジョリティだからマークダウンっていう感じらしいね。
そうそう、世の中にある文章がマークダウンの形で書かれてるものが多いってことなんですかね、つまり。
Pythonのノートブック以外でちゃんとマークダウン意識したことなかったけど、でもマークダウンってHTMLだよね。
そうだね、構成はそうですよね。
そう、なんか俺ウェブのメディアの編集の仕事とかやってた時に基本HTMLファイルで編集の作業とかしてたから文字のメディアをね。
って時にわーって覚えたコマンドとかがノートブックのマークダウンとかでそのまま使えるから。
あーなるほど。
単純にシャープとかで第一見出し第二見出しみたいなのつけれるとか、
過剰書きのポイント出すとかもそうだし、括弧でBRで打ったら開業されるとか、
そういうのが普通になんかHTMLの書式だと思って入ったから、なんかマークダウンとHTMLあんまり区別して考えたことがそんなになかった。
最近のLLMの流れまで。だからマークダウンなんじゃないの?
そうな気がするね、確かに言われてみると。
ウェブページをバーっと持ってきてバーっと読ませるから、その形がいいよみたいな。
そっか、あとはWikipediaとかも確かマークダウンみたいな形式だった気がするんだよな。
あ、そうなんだ。あんまりそこの差わかってないんだよな。書き方一緒だから一緒なもんだろうって思ってたけど。
わざわざ言われて、改めて本で言われて、マークダウンがいいっていうのはトレーニングデータで頻繁に見られるからみたいな。
あ、そっちなんだみたいな。気づきだね。ここは気づきって感じだった。
プロンプトの活用と理解
あとこれを赤ずきんの原則って言うんだっていうのも初めて知った。
結構ピンとこなかったけどな。なんで赤ずきんなんだろうみたいな。
確かにね。赤ずきんちゃんが道を外れないようにって言われたのに外れちゃって大変なことになるっていう例なわけでしょ。
赤ずきんちゃんのお話から来てるのか。なるほどね。そうだよ。え?なんだと思ったの?
そうやって言うんだーくらいにしか思ってなかったけど。書いて書いてはあるか。道を外れないようにってことだよね。
なんか狼に出くわし、血なまぐさい展開になるみたいな。赤ずきんちゃんをそんな表現したことないけどなって。
赤ずきんちゃんそんな血なまぐさい?血なまぐさいか。おばあちゃん食われてるんだもんね。
まあそうね。日本だとデフォルメされてる可能性はあるよねちょっとね。
あ、なるほどね。クリム島は。
原作はもうちょっとグロテスクな可能性はあるのかなと思って。
なるほど。俺らが血なまぐさい赤ずきんちゃんを知らないだけ?可能性はある。
でもなんか改めてこの本当に基礎のところ、第一章の基礎のところを読んで、
LLMの仕組みっていうところを結構丁寧に書いていたじゃないですか。
そのトランスフォーマーベースでモデルができてますよとか。
つまりまあLLMのそのなんかコアの本質って何なんだっけっていうのが、
次の言葉を予測する、保管するっていう言葉で定義されてましたけど、
っていうことを繰り返して文章ができていくみたいなところを丁寧に説明していたのは、
なんかここはちゃんと理解しておくべきところなんだなっていうのは改めて思いましたけどね。
確かに。
知ってる人はもちろん知ってはいるものの、
それって結構一部の人だろうなと思っていて、
ほとんどの人はそこを知らずになんかLLM、ChatGPTとか使ってると思うから、
そこを何でもできる存在みたいなね。
すべて万物を作り上げられるみたいな。
だからどんどんこう次の言葉を予測して予測して保管して保管してで、
いう形を取ってるからこそどんどんおかしな方向に話が進んでいくっていうのは、
まあありえるよねっていうのがこう理論的に理解できるみたいな。
はいはいはい。
だからこう少しLLMの気持ちに寄り添えるというか、
人間側がこれを理解することで。
そうね。
とは思いましたし、そんなにみんな寄り添ってないのかな。
人のプロンプト見るときあんまないじゃん。
確かにね。
だからちょっとなんか画面共有とかでプロンプト売ってるとこ見せるのちょっと恥ずかしいとこがあるもんね。
すごいなんだろう。
丁寧に言う人もいれば、もうほんとにタメ口でこう雑に話してる人もいるわけでしょ。
それはそうだよね。
なんか意外と偉そうにするタイプなんだみたいな。
それを見せるのは少し恥ずかしいかもしれないね。
そうなんだよ。対AIのそのやっぱ感じはね。
今ってさ、ジェミニーとかめっちゃリアルタイムでの対話できるじゃん。
言葉だけで。
あれ使ってる?
たまーにですけど、遊びぐらいで使ってます。
なんかさ、仕事めっちゃバタバタしながら犬の散歩行かなきゃいけないみたいなときとかに、犬の散歩しながらジェミニーと喋るのよ。
で、普通に仕事中で気になってた内容とかワードとか背景とかをその場で聞いて、イヤホンつけながら、
これって何?って聞いて、バーって答えさせて、気になるところをさらに深掘りさせるのも返事してみたいな。
っていうしながら犬の散歩するときたまにあるんだけど。
電話しながら歩いてる人とかもさ、最近イヤホンつけてやってる人多いからさ、昔ほど気にならなくなってきたじゃん。
そうだね、確かに。
けど、AIと喋ってるときのスタンダードな喋り方がまだ染み付いてないというか。
え?どういう指示を出しちゃうの?
これってこうだよね、だからこうして、みたいな文章で書くときとかのってあんま口語的に言わないじゃん、そういうのって。
まあそうだね。
そう、っていうのを情報もらったときに、うんうんうん、みたいな言いながら、
それってこういうことだよね、だからこういうことなのかな、みたいなのを、っていう聞き方をしちゃうのよ。
はいはいはい。
喋ってる内容は一応プロンプトだから気にしなきゃいけないから、日本語をなるべく丁寧にしなきゃいけないから、口語よりはちょっと書いてるような感じで喋んなきゃいけない。
けど、そうやって喋る癖がないから、みたいなのを考えた結果、すごい気持ち悪いプロンプトみたいなのを口で言っているだけみたいな状態で歩いたりしちゃうのね。
だから多分電話じゃないのはバレるのよ。
確かにね。語尾が変なんだよね。
そうそうそうそう。
あーでも分からなくはないけど、結構自分はもう書いてるときもチャットしてるときも、全部語尾は敬語で統一されちゃってますね。
これってこういうことですかとか、これについて教えてくださいとか。
はいはいはい。
癖なのか分かんないけど、これについて教えてって止めたりとかはあんまりしないから、もしかしたら気にならないかもしれない。今のケースだとしたら。
最近、割と止めちゃうんだよな。
あとなんかほら、昔さ、番組の中でさ、ありがとう言ってないと後でAIの反逆を食らったときにみたいな話したらさ、オープンAIのサムアルトマンがお礼とか打たないでくれみたいな。
お礼打つとその分のトークンが消費されて、みんなのお礼のせいで永遠に電力がかかってるみたいなさ、そういうのがあるから最近はお礼を言うのを控えてるし。
でもあれ最終的には必要な経費なんじゃないかみたいな話でもありましたけどね。
あ、そうなの?え、じゃあ俺今あるじゃん、AI反逆リストちょっと駆け上ってるじゃん。
あ、俺言ってないんだ最近。
だからプロンプトのその意識の仕方みたいなのは、これこの本をちゃんと読んでからまだ音声入力で喋ってないから、これがインプットされた状態で喋ったらもうちょっと変わるかもしれない。
確かにね、音声の時にもLLMに寄り添った形式でちゃんと指示を出した方がいいっていうのがわかったから、
そうそう、リッチな文章で質問していかないといい答えはもらえないんじゃないですかね。
可能性はあるね。
どうなんだろうな。
なんかその、リッチにしすぎると、ほら、無関心の谷ってやつか。
はいはい。
っていうのがあるみたいなのは。
そうでしたね。
これ結構俺的には、なんかあんまちゃんと意識できてなかったなっていう感じはあって。
まあ確かにこれは知らなかったかもしれない自分も。
プロンプトの中間に埋め込まれてる情報が、そのプロンプトの冒頭とか後半の情報より活用されにくいみたいな。
ね。
本当に?本当にそうなる?みたいな。
でも書いてますよね。
今まではプロンプトって書いた順番とかあんま意識しなくていいのかなとか、どこに何書こうと全部こうフラットに見てくれるんだろうなと思ってたんですけど、
まさかこう場所によって忘れされる場所があるっていうのは意外。
そうなんだよね。
だから、いやなんかこれさ、今仕事でAIエージェントとかのルールファイルとかをいろいろ整備したりするわけよ。
うんうん。
カーソルだったりパイロットだったり、それこそ最近のGemini CLIとかクラウドコードとか、
あいつらって参照する用のファイルを明示的にセッティングのファイルの中に書いておいて、
その中身を例えばSQLのクエリがバーって書いてあったりとかするみたいなようなものを読み込ますんだけど、
プロンプトの設計と情報伝達
それも実はめっちゃ小分けの方がいいのかなみたいな。
あーなるほど。忘れされる可能性があるからっていうことを一定長い文章で置いておくと。
そう。いくら見出しをつけたとはいえ変わんのかなみたいな。
ここがそうなんだって思いながら、じゃあやれって言われてもどうすんだろうみたいな。
確かにね。
なるべく情報を与えたいし、例えばAIにSQL書かせるとかそういうのを考えたときに、
SQLのクエリの事例ってそんな、例えば100行のやつを10個20個とかだけじゃちょっと心もとないというかにもあるし、
あと縦にめっちゃ長いテーブルとかのテーブル定義書とかブワーって作って渡しても真ん中の方無視されちゃうのかなとかっていう、
そういうのがあんのかとは思いつつ、現実の問題に落とし込むのムズくねみたいな。
この本でも完璧な解決策ありませんって書かれていたから、
ここは仕方ないというか一定それは許容した上で使っていかなきゃいけないのかなと思いますけどね。
できるだけその分プロンプトを簡潔に保つとかっていうところで影響を軽減するっていうくらいしかないですよっていう話でしたよね。
赤ずきんの原則の応用
そうなんだよ、そこがムズい。
しかもエージェントとかの動きとかを制御しようとするとさ、
最近だとそのルーティングをそもそもやらせるエージェントとかに任せるからそんなにいらないんだけど、
ワークフローとかすげえ細かく組んでる人とかだと条件とかバーって書くだろうなみたいな。
そうだよね。
そうなったら冒頭と最後の方のパスばっかり通されちゃう。
バイアスのかかったワークフローとかになるのかなみたいな。
プロンプトを1回投げて帰ってくるこの一定の1回の会話のキャッチボールの中で起きる話なんじゃないですかね。
一発で500行みたいなのを渡した時の真ん中の方の行みたいな話?
そうそうそう。1回で500行渡した時はその中盤が忘れられやすいよっていう話。
だからそこを忘れないようにするためにはその500あるものを分割していくみたいなことで影響を軽減するっていう方法が現状だとベターというか。
マークダウンで見出しとかでめっちゃ明示的につけとくとかそういう話。
そうだね。話の中で出てたサンドイッチ手法っていうやつで一番伝えたいことを冒頭と最後にも必ず書くっていうのは、
やった上で1つのプロンプトを作るみたいな。これを細かく作っていくしかないんじゃないですかね。
これってプロンプトの話っていうよりさっきの赤ずきんの原則なんじゃないのともちょっと思うんだよね。
良質な文章をめちゃめちゃ読んだ時って最初にサマリーみたいなのがあって文章の書き方的に、
俺ら研究室とかで日本語の作文技術とか理科系の作文技術とかっていう本をよく読まされたりしてたし、
ベーシックなところで考えろってなって、英語の書き方って主流のところをバーって書いて、
そこから主流のところに話題が転換されていくみたいなさ、とかってなった時に何かの主張の文章がある時とかって、
その主流から入るし、結論を最初に書いた上で最後もう1回結論回ってくるし、
っていうトレーニングにそのまま引っ張られてるから無関心の谷ができるのかな。
あー、まあでもそうか。
別物じゃない気もする。今なんかいろいろ喋ってみると。
確かにね。別物ではなさそうだな。
トレーニングに引っ張られて無関心の谷ができちゃったみたいな。
できやすいっていうこと。
あともう1個言えるのは、そのLLMが1回のそのプロンプトを理解できる範囲がトークン数というのが決まってるので、
そこの中で、っていう前提の下での会話かなと思ってて、
コンテキストウィンドウが決まってるよみたいな話で、
そこの入れられる文章の中で1つのプロンプトを作ってねっていうことが前提だから、
それ以上の文章をまず上げてしまうと少なからず真ん中の情報で抜けるのはまずあるのかなと。
あー、なるほど。
さらにその中で正しい文章量でLLMに渡した時に暴動と最後の部分は重みがちゃんとついてLLMは理解できる。
相対的に真ん中の重みっていうのは薄くなりやすいっていうのはあるのかなと思うんですけど、
その話もさっきの和木の原則にもつながってると思ってて、
良質な文章って確かにそういう風にできてるよねと。
主張がちゃんと前半後半にあるのは間違いないから、そこに合わせてLLMがちゃんと理解するよりもできてるっていう、
いろいろとつながってるなと思いますね。
データ構造とLLMの相性
個別の話ではないみたいな。
そうですね。
勉強になるな。
これ本読んだ後に喋るのいいな。
だから少なからずLLMが受け付けられるトークン以上の文章を上げてもどうしようもないっていうのは理解しておくべきところではありますよね。
確かに。
おそらくChatGPTとかGeminiとかって今って相当なトークン数受け付けられると思うんですけど、
それを超えた時にこれこんなにこの量の文章は受けられませんみたいな、
LLMって出ないんじゃないかな。
出るのかな。
いやそう思った。
だからこれ読んで思ったのが多分LLM出なくて。
出ないですよね。
そう。だからこの間の俺書籍作りの時に本のPDF丸々ぶち込んでるって言ったけど、
あれちゃんと小分けにしないとダメなんじゃないかなとかちょっと思い始めて。
そうかもしれないね。
なんだっけなディバイかな。
なんかのインプットのPDFのサイズがめっちゃ小分けにしないと入らないやつがあった気がするんだよな。
ありそうそれは。アップロード条件数みたいなのもファイルだったらあるはずだから。
そうそうそう。あったけどなんだっけな。初期の頃のノートブックLLMかな。
でもなんかあれなんだよね。これ確か超デカいPDFとか渡しても内部の処理的にはPDFを上限ギリギリの確かページ数とかで分割して読み込ませるみたいなのを確かやってんだよね。
そうすると何か意図しないところで切られた時に無関心の谷が訳わかんないところで出る可能性もなくはない。
そうだよね。そこだよね。意図しないと省を立てて切ってくれるわけじゃないからおそらくエッジの情報って薄まるだろうし。
そうなんだよね。ノートブックLLMとかの場合はそこから検索かけるで理解するみたいな感じだからプロンプトとはまた別か。
大きく括ったら含まれるかもしれないけど。
ラグみたいな使い方をするっていう意図だとあまりトークン数って意識しなくてもいいのかもしれないけど難しいですね。
でもラグみたいな使い方をするとしても裏側でラグの情報からLLMにインプットする時のトークン数みたいなのは決まってるわけだから
人間は意識せずともちゃんとそこって情報の上限みたいなところは決まってるはずで。
だからこそラグに与える情報もちゃんと正しいテキストで準備しておく必要があるとか
データを揃える重要性ってすごく大事みたいなところにつながってくるのかなと思いますね。
確かにね。
汚い長な文章を置いておくとどうしてもLLMがそこを理解しにくかったり検索しにくいはあるだろうなと。
確かに確かに。
そういうのを防ぐ、ラグのデータの渡し方も文章で渡してベクトル化というかの指定でエンベディングしてみたいな。
そういう処理のパターンとグラフ構造でラグをラグ化するみたいな。
グラフラグとかっていうのもあるじゃん。
で何かそう思ってくるとグラフ構造だと情報のたどり方が違うからまた何か無関心の谷の出来方も変わるのかな。
この本ではあれでしたよね。
前者のベクトル表現して情報を持ってそこに対して検索させにいくみたいなことが書かれていてグラフについての言及はなかったけど
確かにグラフの方が実はLLMとの相性いいんじゃないかって話ありますもんね。
まあこの本自体がいつだっけ。
去年か。
24年とかだよね。
まあだからそういうのも多分その後いろいろ検討されてるって話だよなきっと。
すごいな。一部だけでこんなに喋れるもんか。永遠にいけんだろうな。
いやつか今回のはさ、オライリーの本をさPDFで変えるっていうところが結構デカかったんだよねこのボリューム。
となりのデータ分析屋さん今回も面白いと思ったらフォローレビューよろしくお願いします。
番組の感想や質問はハッシュタグとなりの分析屋。
となりのがひらがなで分析屋は漢字でお願いします。
また概要欄に貼ってあるお手紙フォームからコメントを寄せてください。
ではまた。バイバイ。
