見出し画像

【自動論文?】SakanaAIのAI Scientistのpromptの工夫についてまとめてみた




はじめに


sakana.aiのAI Scientistが一部話題になっていますが、
オープンソースで、公開されているので

本記事では

基本的な概要を説明するのではなくて

どのようなpromptの工夫がなされているのか

ということを主眼に、チャットUIでの活用もできるように
解説していきます。

基本的な解説はサイトやgithubのレポジトリごとLLMに投げて解説でもしてもらったりほかの人の記事などをみたほうがよいと思いますのでここではしません。

基本的な構成図は以下のとおりです。
あまり一般向けでなくわかりにくいかもですね。

SakanaAI 自動論文構成

まぁソースコードにあるプログラムの工程を詳細に並べるとこうなると思いますが、ちょっと詳細度をさげて、シンプルさにフォーカスすると

アイデアだし→
アイデアをもとに繰り返し実験→
実験の趣旨、方法、結果などをまとめて論文のフォーマットに落とし込む

ベースのフローはこれです。

詳細なプログラムの部分は、
基本的には、LLM自らが評価して、
それをもとに主には再帰的に論文のクオリティーをあげるということを行っています。

一発だといい結果にならないというのは普段から
生成AIとわちゃわちゃしてる人ならもちろんわかると思います。

なのでそういった部分を限界はありますが、
プログラム的に工夫しています。

アイデアだしの部分のprompt解説


肝心のどうやって論文のアイデアを生成するのかという部分ですが、

普通にやるとアイデアが容易に重複したりするので、
重複せずに新しいアイデアを出すという部分に主軸を置いています。

では、どのようにして重複しないようにしているかというと

すでにあるアイデアはこのようなものですとpromptに含めてしまって、生成させるときにある程度重複しないように仕向ける方法を用いています。

その後出てきたアイデアたちも、
ある検索ワード(query)を使って、
apiから取得した既存の論文のリスト(knowledge store)と照らし合わせて、

新規性(novelity)があるのかどうか再度判断させます

まだ決断できない場合は繰り返し上限まで
論文を検索するワード自体を考えさせ、
再度論文と照らし合わせるという作業を繰り返す

自信をもって、決定を下せる場合は繰り返し回数に関係なく、その場で決定をくだし、それ以上は繰り返し判断させない。

このpromptのみそは、LLM自体にここで決断するかしないかの判断を委ねているというところにあります。

判断材料をもとに新規性があるかどうかの理由を明確に考えられるなら、
繰り返さないという具合にです。

LLMには上限まで、

・yes
・no
・skip(判断しがたいので判断材料を変える)

の3種類選択肢が生まれるので、単純に1回でyes/noを決めさせるよりも判断の精度を高めることができます。

これは、この箇所に限らず、
なにかLLMに判断させたい場合
ほかのタスクでも、応用できます。

現実世界でも判断がむずかしい場合は、
う~んよくわからないから、
もう1ラウンド戦ってください、
延長線ですとかってなりますよね
まぁそれと同じです。

また、アイデアを考えさせるときには、あらかじめ参考にアイデアを与えることもできます。(参考prompt)

出力結果をある程度誘導したい場合には、
例を与える手法をよく使うと思いますが、その機能もあります。

ある程度は個体のドメイン知識等によって
このような論文の方向性という直感があると思うので、
そういった場合は誘導の上でアイデア出しをさせることができます。

実験部分のプロンプトの解説

ここでいうexperimentとは、実際に実行可能なPythonコードのことです。
このような手法を用いれば、仮説どおりの結果になることを検証できるということを想定したコードです。

ということでこのレポジトリは、
コード上で仮説検証ができるものしか取り扱うことができません
そういう意味では計算方法の工夫に関するものなどに限られてはいます

そして、この部分では、アイデア生成の部分で考えた仮説を下に、
実際に実行可能なPythonファイルを生成して、実行した結果(plot.py)を出力可能にすることをゴールにしています。

実際の論文では、このような手法を用いたら、
結果はこうなりました

という記述やグラフが必要ですよね
なので、その部分の生成です。

それで、次の段階で、
この実行結果をもとに論文の部分を生成させるわけです。

肝心の実験用コードを生成するための工夫ですが、
以下のようなものがあります

・python experiment.py というコードで、実行する予定なので、
追加のパラメーターをつけたりしないでください
大文字のみを使ってpromptを書くことで、強調する手法も使っている
→たぶん、これを先回りして仕込まないといろいろと丁寧に冗長なコマンドをつけてしまうからこうしている。(先回りprompt)

・まずは、アイデアに基づいて、実験計画のリストを作ってください。
(タスク分割prompt)

・たとえば、実験の実行ループの中で、
変更したいハイパラメータの計画をしてください
(参考prompt)
→このような参考promptをいれることで、適切にパラメータを変更しつつ意味のある実験結果を出力させるように誘導しています。

こうしないと、検証するパラメータの組み合わせが無駄に多くなってしまって非効率なため、事前に防止しています。
全通り検証するわけにもいかずある程度角度よくバッチを回すためです。

論文執筆部分のプロンプトの解説


基本出力想定

この論文生成の部分では

  • Introduction(序論)

  • Background(背景)

  • Method(方法)

  • Experimental Setup(実験設定)

  • Results(結果)

  • Conclusion(結論)

というフォーマットで文章を生成させることを主軸としています

per_section_tipsという箇所をみると、
各章ではこのようにしてくださいという指示promptが書いてありますので、確認してみてください

気になった部分について言及すると、

  • Introduction(序論)

この部分ははじめにつくらせた要約(Abstract)のロングバージョンをつくってくださいというpromptで作成されます

  • Results(結果)

存在しない結果をハルシネーションしないでください
→ 最近はアップルのハルシネーション防止promptが話題になりましたが、
ハルシネーションに直接言及する形でハルシネーション対策を行っています
ほかにも、結果が存在していたらという風に何度も言及しているので、普通に出力すると結果はLLMによって適当にでっちあげられやすいということを示唆しています。

自動修正用のprompt

自動修正用のpromptもリスト化(error_list)されていて、生成した論文の項目に対して、このリスト項目に引っかかる場合は自動的に修正されるような仕組みになっています。
おそらく、まだこのOSSは生まれたてなので、ユーザーイノベーション型で
これからさらに充実するのでわ?という予想です。

自動修正用のpromptとは、たとえば、

Numerical results that do not come from explicit experiments and logs
実験やログに基づかない数値結果の使用を避ける

ここでも再度、ハルシネーション対策が行われています。

他は主には、LaTeXの記述方法に関してのもので、たとえば

Incorrect closing of environments
環境の不適切な閉じ方
(HTMLタグ風の閉じ方ではなく、LaTeXの正しい閉じ方を使用)

このような微妙に生成ミスしがちなものに関してです。

基本的にLLMはHTMLの学習ソースのほうが多いはずなので、そのように出力してしまうというのは至極当然という気がします。

論文の引用の自動化

各章に対して、
一番はじめのアイデア生成で使用していた方法同様に、
内容に紐づいた論文の検索語を生成させて

その検索でhitしたものを引用として用いるという手法をとっています

レビュー部分のprompt解説

最終パートは、生成された論文のレビューです。

レビューの生成は、複数レビュワーの評価をまとめるという方式で、

以下の項目を埋めさせます

  • "Summary": 論文の内容と貢献の要約

  • "Strengths": 論文の強み(リスト形式)

  • "Weaknesses": 論文の弱点(リスト形式)

  • "Originality", オリジナリティ 1-4

  • "Quality": クオリティ 1-4

  • "Clarity": 明確さ 1-4

  • "Signification": 重要度 1-4

  • "Questions": 著者に対しての論文内容の明確化のための質問群

  • "Limitations": 研究の限界と潜在的な社会的影響

  • "Ethical Concerns": 倫理的懸念の有無(bool値)

  • "Soundness", 健全性 1-4

  • "Presentation": 表現と構成 1-4

  • "Contribution": 貢献度 1-4

  • "Overall": 総合評価 1-10

  • "Confidence": 自信度 1-5

  • "Decision": 最終的にこの論文を"Accept"(採択) するか "Reject"(却下)するかの2択 

流れとしては、まず各種レビュワーに評価させて、
そのあとにメタレビューと題して、
総合的に評価して同じフォーマットで再度出力するというやり方です。
一人だけも指定できて、その場合はメタレビューはないです

出力結果はすべて、いままでのやりとりも含めて、任意の回数
reflection(内省)させて、精度をあげます。

チャットUIでもなじみがあると思いますが、
本当にそれでいい?こういう内容をちゃんと加味できてる?
もっとよくできるよ?50点だね
と何度も詰めて出力をよくするという手法です。

強くなるとパワハラpromptなんて言い方もされていますが、
ここではreflection(内省)と題してレビューの質を底上げするために
同様の手法を実行しています。

手法まとめ

参考prompt(few shot)

だいたいこんな感じだよと例や参考を教えることで、
出力結果をコントロールする手法

先回りprompt

特定のミスなどが起こる場合に先回りして宣言することで、
望まない出力を避ける方法

LLMの種類に依存したりはしますが、出力の経験値が蓄積される場所
だいたいプロント構築に対しての人間の価値はここにあったりします。

判断材料スワップ

N択の場合、1回で判定をさせるのではなくて、
判断材料自体を変更するという第三の選択肢を与えることで、N択の精度を向上させる手法。

判断材料自体や判断の精度にばらつきがあって、
N択させたい場面は多々あるので、
その場合は、使えます。

チャットUI的には1,2,3かこの情報では判断できないで答えてくださいのような具合。

LLMにも逃げ道もつくっておかないとよくわからないけど、
無理やりこっちですと言わざるを得ないですから

フォーマット先行指定

ほとんどのpromptでそうですが、あらかじめ出力フォーマットを指定してからそのあとに、そのフォーマットへ記述する内容の指定をします。

まずは箱を用意してあげて、それを埋めさせるイメージです。

このようにすることで、
フォーマット通りに出力する可能性をあげています。
筆者の経験的にも、prompt内でフォーマット指定する場合は、
先に内容を指定すると内容に引っ張られてしまうので、
フォーマット指定のapiが別途用意されていないときはこうしたほうがよいと思います。

それか普通に実装する場合はフォーマット出力ライブラリもあったりするので、それらを利用するのも手です

zodを用いた固定フォーマットの手法なども近年人気の手法ではあります。

自然言語的終了フラグ


例えば、終わったことを確認するのに、i'm doneと出力してくださいなど、終了判定に自然言語を用いるという手法です。

引用に関しても、引用がない場合はNo more citations neededと出力してくださいと指定して、それが含まれていたら○○という条件をつかったりしています。

シンプルで使いやすいフラグの立て方ですが、意図していない出力に
指定していた言葉が含まれていた場合は、誤判定の恐れがあるので、自然には出力しえない言葉を指定する必要があります。

タスク分割プロンプト

言わずと知れたほうほうで、タスクの処理の能力を上げるために、まず分割させる方法です。

大文字強調

何度か使用されていますが、特に守ってほしいことを強調するのに、英語の大文字だけ(upper case)の宣言というのを用いています。

アンサンブル

複数の得意分野の違うLLMや役割付きのLLMに意見をださせて、それらをまとめることで、意見の健全性や中立性、網羅性などを向上させるやりかた。 
円卓方式やマギシステムとして広く愛されている方法です。

リフレクション

出力結果に対して何度も、質の改善を促して、
最終出力結果の質を上げさせる手法

人間も一回は出力してから、自分で後から見直すと間違えに気づいて直すということができますが、LLMにもそれができるわけです。

パワハラpromptも広義の意味では同様の類ですね


↑手法についてわかりやすくキャッチーにネーミング
しているつもりですが、
いろいろな呼ばれ方があると思います

これからの発展の余地や予知

まえおき

まず1から70まで作るのはとても大変かつ偉大なことで、70→100に関しての言及をこれからしますが、それは1-70の土台のうえにあることなので、敬意をもって行います。 そして大抵reflectionと同じで、すでにあるものに対しての言及は比較的簡単なものです。

・すでにPull Requestが来ていたりしますが、今は使用想定のLLMが決め打ちされているので、いろいろなLLMに柔軟に対応できるようになる

・Docker環境の構築
わたしはDocker至上主義ではないですが、このようなレポジトリとはとても相性はよいと感じます

・GUIでの実行環境
簡易的でもよいので、GUIから入力生成までできると
ぐっと使用率が高まりそう

・あるフォーマットに落とし込む関数などは汎用化できる説

・reflectionのprompt部分は倫理的な問題はあれど、もっとパワハラ気味になってもよいかもしれない


The Last


今回はpromptの工夫という観点から少し書いてみました
あなたのお役に立てたら幸いです

それではよいライフを。







この記事が気に入ったらサポートをしてみませんか?