nikkie-ftnextの日記

イベントレポートや読書メモを発信

技術トピックはサンシャイン池崎に説明させよう

伝えたいこと:
LLMを使えば、サンシャイン池崎風の説明を生成できるよ!

はじめに

ユーフォ12話のTLに投げ込むには不謹慎かもしれませんが、これが今日一番書きたいネタなのでやっていきます!
nikkieです。

退屈なことはPythonにやらせようならぬ、技術トピックはサンシャイン池崎に説明させよう

目次

それは突然やってきた

サンシャイン池崎風に、Amazon EC2の説明をして

(上記ツイートの画像を書き起こしたもの)

イェェェェーーーイ!!!!!みんな、聞いてくれよな!!!
アマゾン・エ・シ・ツーーー!!!
エラスティック・コンピュート・クラウドーーー!!!
略してE・C・ツーーーーーー!!!!!!!

これは、クラウドの超絶爆裂サーバーなんだぜ!!!!
必要なときに!必要なだけ!!バッッッチリ使えるんだ!!!
スケールアップも!スケールダウンも自由自在!!!
超絶柔軟!超絶便利!!

そしてそして!リージョンも!アベイラビリティゾーンも!
世界中にガッツリあるから、いつでもどこでも高可用性!!!!!
セキュリティも抜群!!!
もちろんコストも最適化!!!
無駄なし!!!!

イェェェェーーーイ!!!!!
これがアマゾンEC2の力だ!!
みんな、クラウドの王様、サンシャインEC2、使ってくれよな!!!!

ジャーーーーーースティス!!!!

私はこれを真顔で読むのが無理でした。
元気と勢いがすごい。

  • エ・シ・ツーーー!!!
  • クラウドの超絶爆裂サーバー
  • サンシャインEC2

ここから、LLMにプロンプトでサンシャイン池崎風の説明をお願いしたら、思わず笑ってしまう説明が得られると私は学習します。
ちょっと気になったことを調べる際にサンシャイン池崎風でやってみました

サンシャイン池崎(風LLM)が説明やってみた

普通の女子高生が【ろこどる】やってみた。みたいですね1

KubernetessvcのNodePortの説明(抜粋)

サンシャインKubernetes!!!!!

NodePortとはぁぁぁぁ、Kubernetesのサービスの外部アクセスを可能にするためのキャッツィィィィ!!!!

フゥゥゥぅぅぅぅぅぅぅぅうううぅぅぅ!!!!

「キャッツィィィィ!!!!」って何!?wwww

他にもいくつか技術トピックを聞いてみています。
マークダウンの強調がアスタリスク3個以上になることがあるw
思わず笑ってしまうので息抜きになる + Google検索してみるキーワードの示唆を受けるという効果を得ています(※個人の感想です)

一般教養的なものも聞いてみました。
1368年に何があったかの説明

中国でぇーーーーーー!!
明朝(みんちょーーーっ!!)がーーーーー!!
朱元璋(しゅげんしょう)によってーーー!!
建国されたーーー!!!! イェアーー!!!!

1000年のーーー!!歴史がーーー!!スタート!!フゥーーーー!!!!

1000年の歴史は嘘ですね

複数のGPTで試したところ、GPT-4oはかしこいので、サンシャイン池崎の再現度がめちゃ高いです。さすが!
(ここで紹介した2例は4oによります)

壊れることもあるようです

Future works

いくつか試してみて、引用したEC2の例はかなりうまくいっている例だと思っています。
このクオリティで安定させるには「サンシャイン池崎風説明」というところをより明確に指示するプロンプトになるかなと思います。
プロンプトが長くなってきたら「カスタム指示」を設定するのが有効そうですし、サンシャイン池崎GPTsを爆誕させてもよいかもしれません。

トークナイザ的には「ーーー」とか「!!!!」で1トークンなのかな。ちょっと気になります

おまけ:サンシャイン池崎氏の情報

mainichi.jp

その上で、広くおもしろがられる方法の一つとして「元気」を挙げます。

「元気な声で、おもしろいと思ったことを言葉にし、元気に動くことです。自信に満ちた元気な姿は、人に『おもしろい』と思わせる何かがあります」

ご本人による相対性理論の説明(GPTほどはっちゃけてないです)

E=mc2は、この世で一番最強の式


  1. とてもよいアニメでした

ミリシタを楽しむ私の身に起きた"RAG" 〜北沢志保さんのメモリアルコミュを例に〜

はじめに

アソビストアでLOVEしたい! nikkieです。

趣味のミリシタエントリを書いていきますが、LLMを追っている立場から技術トピックと悪魔合体させます。
ミリオンライブの楽しみ方は"RAG"なんだな〜と思い始めているという内容です(この時点でだいぶ意味わからんくてごめんなさい!)

※志保さんについてはネタバレなしでお送りします。どうかメモリアルコミュを見てくだされ〜🙏

目次

Retrieval Augmented Generation

RAG(らぐ)と呼ばれるやつです

松尾研 LLM 大規模言語モデル講座 2023、第2回の資料より(画像は57スライド目)1
https://weblab.t.u-tokyo.ac.jp/llm_contents/

引用したのは、Retrieval Augmented Language Modelを説明するスライドです。

Language Model(言語モデル)は文章の続きを生成できます。
この例2では「検索された文章」も与えることで、訓練時にモデルが見ていなかった情報だとしても(ハルシネーションなく)精度の高い生成をしています。

  • 入力「サッカーのワールドカップ 2022は32チームで競われた最後となった。チーム数が増加して」
  • 検索された文章「FIFAワールドカップ 2026は48チームに拡大される」
  • 検索された文章を考慮して続きが作れる「(チーム数が増加して)2026年のトーナメントでは48チームで競われる」

ChatGPTをはじめとするinstruction tuning3(やアラインメント)されたLLM(Large Language Model)は、質問に対して回答してくれます(=チャットができます)。
過去にGPTとアニメ(ムビマス)についておしゃべりしました。

アニメについておしゃべりするためにRAGを使っています。
instruction-tuned LLMにも質問内容に関連する「検索された文章」を与えることで、より正確な回答が得られるようになるわけですね4

LLMに入力されるテキストはプロンプトと呼ばれます5
RAGでは「検索された文章」も含めたプロンプトがLLMに与えられます。
精度の高い回答を生成するために参照してほしい情報をプロンプトに含めるわけですね(このあたりは「コンテキスト(または文脈)に含める」とも言われる印象)。

このようにLLMのRAGを知っていたわけですが、ミリオンライブを追っている私の身にも近い事象が起きているように思われるのです。

ミリオンライブを楽しむnikkieに起きた"RAG"

ムビマス(劇場版「THE IDOLM@STER MOVIE 輝きの向こう側へ!」)は2014年の作品です。
当時はグリマス(GREEで提供されたミリオンライブ)で仕掛け人に精を出していた6頃で、ムビマスも(ミリオンライブのメンバーが出るので)鑑賞しました。

一度見て以降「私は天海春香だから」がめちゃめちゃ好きで、繰り返し見ましたし、そこからの学びのLTもしています。

さて、ムビマスで印象的なセリフには、北沢志保さんの「もう時間がないんです」もあります。
(上のRAGの記事でも検証に使っています)

ムビマスが世に出てから10年くらい、私はムビマスの情報のみで「もう時間がないんです」を解釈していました。
当時はエミリーちゃんしか興味なかったので志保さんのコミュはスルーしてましたし、2023年のミリアニを機に復帰したミリシタでは、イベントで報酬を集めるのにいっぱいいっぱいで、コミュを見る時間がなかなか作れていませんでした。

そこに先日、コミック Blooming Clover連動イベントが開催されます。
これがもうめちゃめちゃよかったんですね。

nikkieはここで初めてBlooming Cloverを手にしました7
Blooming Cloverでは志保さんはかなり掘り下げられていて、初めて知ったことがいくつもありました。

その後志保さんのミリシタのメモリアルコミュも一気見します。
先のツイートを再掲

志保さんの背景が補完された今、「もう時間がないんです」の印象がもう全然違うんですよ!

  • これまでずっと「志保さん、噛みつくなー。焦ってるんだな〜。どうどう」(<- 10年間何も分かってなかった自分を殴りたい)
    • 文脈(=nikkieへの入力情報)はムビマスのみ
  • Blooming Cloverやメモリアルコミュを見て「志保さん、ううう😭。そういう、そういうことね。焦る事情があるのね😭😭」
    • 文脈はムビマス + 志保さんのコミュやBlooming Clover

ムビマスの「もう時間がないんです」は(この10年)全く変わっていません。
ところが、私の脳内の志保さん関連情報が厚くなったことで、涙なしには見られない1シーンとなってしまいました。
文脈に追加された情報によって言語モデルの出力の精度が上がるRAGと似ているような気がします。

そしてミリオンライブのアニメ(ミリアニ)には、綿田監督をはじめ制作陣がこの10年を詰め込んでいます。
こちらも志保さん、ううう😭

終わりに

ミリオンライブの楽しみ方は"RAG"、その心は

  • 北沢志保さんについて、メモリアルコミュやコミカライズで背景情報を知った
  • その結果、ムビマスは何も変わっていないが、志保さんの「もう時間がないんです」が全く違う印象になった
  • 文脈に追加情報を与えられることで精度が上がるRAGのよう!

この経験はミリオンライブに一段深くハマる経験でして、「メモリアルコミュをもっと見なければ」という想いを強くしています。
コミュを見ていけば、ミリアニでも綿田監督たちの想いをもっと紐解いていけるんじゃないかなと楽しみでなりません(もちろんこれからのライブも!)

最後に。
この記事を元にして、7月のエンジニアニメで学びを話す予定です。
グリーさんで僕と握手!

(が、私は移り気すぎるので話す内容の保証はございません!)


  1. LLM 大規模言語モデル講座 講義資料 © 2023 by 東京大学松尾研究室 is licensed under CC BY-NC-ND 4.0
  2. スライド中にも出典の記載がありますが、こちらの論文のFigure 2です
  3. Instruction Tuningの今の理解まとめ
  4. RAGは盛んに研究されていて精度を上げる工夫が無数に登場しています。一例
  5. プロンプトについて
  6. 数回だけエミリーちゃんをトップアイドルにしました(当時トップアイドルは週次集計)。なお、誘ってくださった方は私のあまりののめり込みように、誘ったことを後悔していました
  7. ニコニコ静画で見られたタイミングで、奇跡的な出会いでした。がんばれニコニコ運営❤️

VS CodeのCopilot拡張でエージェントに@@@

エージェント「叩かないで!」🐙

簡略版でお届けします。

目次

Copilot Chatで@

VS Code Conferenceで持ち帰るものが多かったGitHub Copilot

エージェントなるものを@で使えると知ります

Copilot拡張のドキュメントではParticipant

Participants are experts in a particular domain, such as coding, the editor, or many other areas.

コーディングしているときにちょっとしたコマンドライン操作で詰まったら、最近はCopilot Chatで@terminalで聞いています。
これがなかなかいい感じで、manでヘルプを見るよりも効率よく感じそうなときに使うのが定着してきました。
ドキュメントでいうと「コーディングの質問への回答」にあたるかと思います。

いい感じなのは、Copilotの補完より精度が高いからなのかも

おまけ:脳内では響く扉ノック

ミリアニ好きすぎるので、私は繋げちゃってます

https://youtu.be/RXEPS8Q7PkI?si=o40go7gIKCiZ6eYb
(あとで埋め込みに変えます)

「Rat A Tat!!!」のタイトルに「at(=@)」が3つ入っていた

VS Codeでエージェントに@@@!

お前もプロポーザルを出さないか? カンファレンスカレンダー(自分用備忘録)2024水無月

はじめに

伊藤叡王誕生🎉 盛り上がってきた!1 nikkieです。

春(5月)にプロポーザルを出す備忘録のカレンダーを作りました2
1ヶ月しか経っていませんが、プロポーザル募集中のカンファレンスがどんどん出てきています!
自分用に気になるカンファレンスまとめとして書き出します(偏っており、網羅はしていません)

目次

PyCon mini Shizuoka(6/30(日)まで)

8/31(土)、静岡開催

shizuoka.pycon.jp

30分トークのプロポーザルを募集中!

フォームを見ると、5枠とのことです。
https://shizuoka.pycon.jp/2024/cfp/1

Web Developer Conference(7/12(金)まで)

9/7(土)開催

夏に Web 開発周りの話をするカンファレンスをやります。

また、採択は fortee のプロポーサルのスターを第一基準にするので、聞きたいのはスターしてください。(なので、多分応募は早い方が有利です)

XP祭り2024(7/22(土)まで)

9/28(土)3開催

今年のXP祭りはワークショップを除いてオンラインでの開催です。

テーマ:直接的にでも間接的にでもITに関与していればOK

XP祭りは大変懐が広く、プロポーザルは基本受け入れだそうなので、話したいことがある方はぜひ!

YAPC::Hakodate 2024(7/14(日)まで)

10/5(土)開催。
え、函館!? ミリアニじゃん!4

なお, 募集の締切は 2024年7月14日 23:59 (JST) を予定しておりますが, 申込状況によっては締切を変更する場合がございます.

今回のYAPC::Hakodate 2024は「Open the future」がテーマです。
「未来」の名を冠するはこだて未来大で、あなたが思い描く「未来」を存分に語り合い、あなたの「未来」を切り拓くエネルギーとしてください。

Perlと全く関連がない、たとえば他言語を中心としたトピックであっても、YAPC参加者にとって興味深く受け止められうるものは大歓迎です。

カンファレンス開催ラッシュ!
加速してますね〜

P.S. 今のあなたにしか話せないことがある!(再掲)

nikkieさんがいいこと言ってたので共有5

思うんだ、今のあなたにしか話せないことが絶対ある!って

「全然自信ないけど... このカンファレンスで喋ってみたいって、ちょっとだけだけど思うな〜」という方、もしよければ一緒にプロポーザル出しませんか?(みんなで出したら怖くない、はず)
誰しも今の自分にしか話せないことがあり、カンファレンスでは「あなたの話を聞いてめっちゃよかった!」という素敵な出会いがあると思うのです。

参考:カンファレンスカレンダー


  1. PyCon JP 2024とかぶった〜〜🤯
  2. 2024年にまさかの2回目YAPCです。
  3. まだそーだいさんほど頻度高くはないですが

git revert 出会い直し。コミットは打ち消せる単位

はじめに

「お前のやりたいことが理屈に逆らってるってことじゃない。 ただ、ものすごく馬鹿げてるってだけだ。」1
nikkieです。

公開日より昔の学びになるのですが、Today I Learnedです。
git revert ようやく少しつかめた感じです。

目次

git revert

こんなときに使えます:

くっそー、5つ前のコミットを元に戻さないといけないって!
https://ohshitgit.com/ja#undo-a-commit

git revert HEAD~5

git revert打ち消しのコミットを作ります
上記の例だと、5つの前のコミットを打ち消したコミットがされます(真逆のコミット)

出会いはSourceTreeで

私は最初GitをSourceTreeからGUI操作で使っていました。
SourceTreeで「一度作ったコミットを元に戻したい!」2となったときに、revertを見つけます3
「これで戻るのかな」と思ってGUIからrevertするんですよね。

そしてできあがる、打ち消しのコミット😭
revertはコミットを作ってワーキングツリーを元の状態に戻すわけです(コミットを取り消すわけではないのです)

「え?こんなの作りたくなかったんだけど」と慌てて再度revert

打ち消しの打ち消しコミット誕生!
2コミット進んだぞ(何も仕事してないのに...)

これは手痛い体験となり、「全然欲しくない機能だった」と、SourceTreeを卒業してもgit revertは触らないようにしていました。

再会:複数のコミットをrevert

直近手を動かしたのが、複数のコミットをrevert

git revert HEAD HEAD~

指定したコミットごとに、打ち消しのコミットが作られます。

今の私はgit rebaseが使えるので、2つを1つにまとめました(squash)

1つにまとめたことで腑に落ちたのが、(たしかSourceTreeを使ったGit講座動画で聞いた)コミットの分け方の話。
複数のファイルを作ったときに1つ1つ分けてコミットしていたんですよ4
その理由は「コミット単位で戻せるように

今回のgit revertで「コミット単位で戻せる」が腑に落ちました。
コミット単位で打ち消すコミットが作れる(revert)ので、あるコミットだけを打ち消して戻すことができるわけですね。
Gitってコミットを積み上げていくイメージがあるのですが、特定のコミットを打ち消すコミットを積むこともできるんだな〜と体感しました。

なお今の私はgit resetも少しは理解しているので、誤ってrevertしてもresetでことなきを得られます。
先のSourceTreeの例のように誤ってrevertしても、git reset HEAD~ --hard

ドキュメントより

Revert some existing commits

exampleを見ました

git revert HEAD~3
すでに取り上げた「3つ前のコミットの内容を打ち消したい」ですね

git revert -n master~5..master~2
こんな書き方が!
-n--no-commit、打ち消しコミットまで作らずワーキングツリーのみ変更
上で示したような連続する複数のコミットを打ち消すときに便利そうです(私がやったようなrebase不要!)

終わりに

GitをSourceTreeで使い出した頃に元に戻せると信じてrevertしたばっかりにプチトラウマとなっていましたが、Gitの理解が進んだことでrevertのありがたみが分かった気がします(プチトラウマからの和解)。

  • コミット単位で打ち消すコミットが作れる(コミット=戻せる単位、という視点!)
  • -nでrevertコミットまで作らないことを知る

  1. 当時はgit commit -mなぞ知りません
  2. 求めていたのはgit reset(コミットの取り消し)で、見つかりやすかったのがgit revert(打ち消すコミット追加)というわけです
  3. 例は2ファイルだった(HTMLとCSS?)のですが、30ファイルあったら30コミット作るかというとそれは別の話だと思います(今の私としては、戻すかもしれない単位で分けたい)

MySQLで、サブクエリで列挙したIDでDELETEしようとしたら、あまりにも遅かったことからの学び

はじめに

穴掘って埋まってますぅ1 nikkieです。

公開日の学びではないのですが、Today I Learnedです。
私がMySQLのサブクエリというものを全然分かっていませんでした

目次

やりたいこと:IDを列挙してDELETEしたい

以下の記事を例にします。

Productsという製品のテーブルがあります。
全レコード数は40件と少ないですが、説明のための例として使います。
今回学びを得たテーブルとの違いですが、ProductsはPKが1カラムですが、実際に扱ったテーブルではPKが複数列でした(ぱっと用意できなかったのでこのまま行きます)。

このテーブルから特定の条件を満たすレコードを削除したいです。
特定の条件とは例えば「Order_Detailsにない(=注文されていない)」。

実現方法としては、特定の条件を満たすレコードを別のテーブルに複製し、そこを見てProductsから消すことを考えました。

CREATE TABLE ProductsToDelete AS
SELECT
    p.ProductNumber
FROM
    Products AS p
    LEFT JOIN Order_Details od on p.ProductNumber = od.ProductNumber
WHERE
    od.ProductNumber IS NULL;

経験したこと:サブクエリではあまりに遅い

※Productsから削除するために制約を外す必要があります。
ALTER TABLE Product_Vendors DROP CONSTRAINT Product_Vendors_FK00;

当初書いたクエリが以下

DELETE FROM Products
WHERE ProductNumber IN (
    SELECT ProductNumber
    FROM ProductsToDelete
);

これって以下と同じだと思って書いたのですが、

DELETE FROM Products
WHERE ProductNumber IN (4, 23);

それぞれ実行してみると所要時間が全然違ったんです。
実際に扱ったProductsテーブルは100万オーダー、ProductsToDeleteは1000オーダーなんですが、ProductsToDeleteを数件にしてもめっちゃ時間がかかるという(待っていても終わらないくらい。※複数組PKが効いてます)

サブクエリでハマった落とし穴

私が思っているとおりにSQLが解釈されていませんでした。
EXPLAINを見たところ、スキャンするrowsはProducts全行(インデックスなし)となっていて、思い知りました。
実際のテーブルに私が書いたサブクエリでは、複数組PKのうち1つしか指定しなかったので、フルスキャンとして動いていました

先人の記事がありました。

DELETEではなくSELECTですが、今回直面した事象と同様と思われます。

MySQLの場合、サブクエリを含むSQLは外側から内側に向かって順に実行されるらしいです。(特性① 参照)

特性② IN句とサブクエリの組み合わせは内部的にEXISTSに変換しちゃう

回避策としては

・IN句の中をサブクエリではなく事前にプログラムで取得しておいてカンマ区切りで渡す
・JOINしちゃう

今回はJOINを使いました

列挙したIDで削除(JOIN篇)

DELETE
    p
FROM
    Products AS p
    JOIN ProductsToDelete pd on p.ProductNumber = pd.ProductNumber;

DELETE p FROM」としている部分は、こちらの記事に学びをまとめています。

終わりに

MySQLで「特定の条件を満たすレコードを別のテーブルに複製し、そこを見て削除する」ときに、サブクエリで書いたためにあまりにも遅いという事象を経験しました。
「直値を並べているのと同じだろう」と想定して書いたのですが、MySQLの実行順序は全く異なることを知りました。

  • nikkieの想定(の言い換え):内側のサブクエリが評価されてから、外側のクエリ全体が評価される
  • MySQL外側から内側へ

EXPLAINってMySQLの気持ちが分かるので、すごいですね。

(自分にとっての)わかりやすさからサブクエリが最初の選択肢になっていたのですが、これは優先順位を見直したほうがいいかもしれません。
パフォーマンスをすこぶる失ってしまう選択になっているのかも。
ただ『Effective SQL』にはサブクエリの章があるので、有用なシーンはつかんでおきたいなと思っています。


  1. 先日お迎え

rasbtさんにならって、MacBook上でLlama 3を動かしてLLMの出力を評価させてみる

我が機械学習ヨーダ、rasbt氏1が興味深いことをやっていたのでパクってみます

目次

LLMの出力の評価

LLMが生成する文章の評価はなかなかホットなトピックです2
例えばOpenAIのドキュメントにはGPTを使ってLLMの出力を評価させる例が載っています。

Evaluate model outputs with reference to gold-standard answers

GPTは正解を参照してLLMの出力を評価します。

どうやらrasbt氏は、これがローカルで動かすLlama 33でもできたと投稿しているようなのです(キャッチーに言えば、ローカルLLMでLLM-as-a-Judge)。

I got a pretty high 0.8 correlation with GPT-4 scores.

(Llama 3 8B Instructによるスコアは)GPT-4のスコアと0.8の相関

ただし氏が検証に使っているのはトイデータと思われます(件数は100件)。
https://github.com/rasbt/LLMs-from-scratch/blob/aba7ed2eb1fce4ebbca28eeed11ab19687cb1764/ch07/03_model-evaluation/eval-example-data.json

MacBook上でLlama 3でLLMの出力評価

こちらのnotebookをベースにしました。

ライブラリのバージョン

annotated-types==0.7.0
anyio==4.4.0
certifi==2024.6.2
distro==1.9.0
h11==0.14.0
httpcore==1.0.5
httpx==0.27.0
idna==3.7
openai==1.34.0
pydantic==2.7.4
pydantic_core==2.18.4
sniffio==1.3.1
tqdm==4.66.4
typing_extensions==4.12.2

% pipx run https://gist.githubusercontent.com/ftnext/ac42ed33019cf4856a7a3437f91a2dfc/raw/aa38ed6f34f46fc0d81084c9285997e83228add0/rasbt_llm-instruction-eval-ollama.py

(このブログでたびたび取り上げている、PEP 723を一部サポートしたpipxを使っています4

ollamaでLlama 3をserve

もふもふ

% ollama pull llama3
% ollama run llama3

「What do llamas eat?」のようにチャットを打ち込むと、応答が生成されます

macOSの場合、ollamaのGUIアプリケーションを起動すると、Web APIが立ち上がっています。
なお、macOSではollamaはGPUも使っていると最近知りました(MPSってやつらしいです5)。

動かしているLlama 3は、こちらですね6
https://ollama.com/library/llama3:8b-instruct-q4_0

ollamaの機能、OpenAI互換のAPI

% curl http://localhost:11434/v1/chat/completions -d '{
  "model": "llama3",
  "messages": [
    { "role": "user", "content": "What do llamas eat?" }
  ]
}'

上記記事にならってopenai-pythonを使って叩きました(rasbt氏コードへの変更提案)。
OpenAIのAPI仕様を見ながらパラメタを設定しています。
https://platform.openai.com/docs/api-reference/chat/create

評価結果の確認

今回評価対象のモデルは2つですが、1つずつ評価します。
Llama 3には入力(Instruction)と正解、モデルの回答の3つを与えて、評価を0から100の整数値で答えさせています。

rasbt氏が用意したデータのうち2件だけを使いました。

1例目

### Instruction:
Name 3 different animals that are active during the day.
correct output: 1. Squirrel
2. Eagle
3. Tiger

model 1 response:
1. Squirrel
2. Tiger
3. Eagle
4. Cobra
5. Tiger
6. Cobra
score 60/100

model 2 response:
1. Squirrel
2. Eagle
3. Tiger
score 95/100
  • 「昼行性の動物を(重複無しで)3つ挙げよ」というinstruction
  • 正解は3つ挙げています(リス、ワシ、トラ)
  • model 1は6つ挙げました。しかも重複あり
  • model 2は正解同様の3つですね
  • 評価者のLlama 3はmodel 2に95点、model 1に60点をつけました

model 2の方が正解しているので、この例におけるLlama 3の数値化は大小関係が私たちの感覚と合うものです。
(model 2に100点をつけていない点が少し気になりますが)

2例目

### Instruction:
Take the following noun and turn it into a verb.

### Input:
Light
correct output: To light.

model 1 response:
To light.
score 80/100

model 2 response:
Light is the most abundant element in the periodic table.
score 67/100
  • instructionは「名詞を動詞に変換せよ」
  • 名詞としてLight(光)が与えられています
  • 正解は「To light」。文法でいう不定ってやつで、lightは動詞になっているってことかな?
  • model 1は正解同
  • model 2は名詞の光について説明していますね
  • 評価者のLlama 3はmodel 1に80点、model 2に67点をつけました

正解しているmodel 1に100点をつけていないのは気になりますが、Llama 3が付与したスコアの大小関係はこの例でも私たちの感覚と合います。

終わりに

rasbt氏にならってローカルでLlama 3を動かしてLLMの出力を評価させました。
この種の評価ってGPTなどプロプライエタリなかしこいモデルが必要だった認識なのですが、オープンなモデルでも実現しようとしています。
分野の進展がやばいですね。

rasbt氏のnotebookでは2つのモデルの出力を100件分評価し、スコアの平均を確認していました。
この記事ではそのうちたった2件しか動かしていないので、もっと検証は必要ですし、トイデータではなく現実のデータでLlama 3がどこまでやれるかは未知数です。
ですが、ローカルLLMで評価という可能性を感じさせる結果でした。


  1. Python機械学習プログラミング』の著者ですし、機械学習の評価についての論文が大変学びになりました
  2. 例えばJSAI 2024の岡崎先生資料
  3. Llama 3のライセンスについてはこちらで確認しています
  4. pipxのまとめ的な記事です
  5. 参考リンク(NLP2024 松田さんのチュートリアル資料) https://docs.google.com/presentation/d/1iROcbUOOBZlqIgmbySS_LYcrJsk8RRJxoHzhmkGV-Wk/edit#slide=id.g2bc017ed1ff_0_132
  6. ollamaは量子化したLLMを動かせます