こんにちは、協業DXでMLエンジニアをしている「ふる」です。
LLMに対してエージェントを利用した取り組みとその精度向上に対して得た知見を記事にしたいと思います。
これからLLMに求められる役割
今現在、ChatGPT4、Claude 3、Geminiなど様々な基盤となるLLMが存在し、会話を通じて、コーディング・マーケティング・わからない単語を調べるなど様々なタスクの補助をしながら仕事を遂行されてる方が多いと思います。しかし、LLMは「非常に優秀な他人」であるため、我々のことを察して話すようなことは難しく、ユーザーの背景をしっかりと教えてあげながら会話する必要があります。従って、我々の背景をしっかり察することができ、一連の会話を連続して実行し、ユーザーのより好ましい形で返信することが次世代のLLMの使われ方だと思ってます。実際に、Advanced Data Analysis(旧 Code interpreter)や などはエージェントの一種です。
LLM Agentとは?
LLM Agentは、特定の環境から適切な情報を収集・交換するLLMを指します。特に、LLMに自律的なタスクの遂行能力を付与することを意味することが多くなっています。Claude 3.xやGPT-5のような進化したLLMでは、単に補助を依頼するだけでなく、一連のタスクを自立的にこなす動きが増えてくると予想されます。GPT-5やClaude 4などの登場とともに、エージェントの概念はより一層の重要性を帯びてくるでしょう。
※ここでは、「LLMをagentとしたゴールベースエージェントの仕組み」をLLM エージェントを省略して呼んでいます。
LLM Agentの具体例
LLMの例としては、GPT-4-Turbo, Claude 3, Geminiなどが挙げられます。これらは代表的な大規模な言語モデルで、自然言語理解と生成において高度な性能を発揮します。
これらに以下のような環境を与えることでLLMに対して様々なタスクを遂行させることができます。
- Advanced Data Analysis (Code Interpreter): プログラミングコードを解釈・実行する環境。ソフトウェア開発のサポートや特定のアルゴリズムの実行などが可能です。
- Web Search: インターネット上の情報を検索し、得られた情報をユーザーに提供します。最新ニュース、学術論文、一般知識などが含まれます。
- API Calls (Function Calling): 外部のAPIを呼び出して情報を取得し、それを分析や応答に使用します。天気予報、株価情報、地図サービスなどが例です。
LLM Agentが作れるサービス
LLM Agentが作れるサービスとして代表的なツールを以下に挙げました。
まずはみなさんご存知のGPTsであり、非エンジニアの方々でも手軽にLLM Agentが作れるサービスです。
エンジニア向けにおすすめなのがOpenAI APIにあるAssistantと呼ばれる機能であり、CRUD操作とデータをスレッドと呼ばれる機能が管理できるので、ChatGPTの履歴管理などをするためのデータベースなどを用意することなく、UI構築やプロンプトエンジニアリングに集中することができます。
最後に紹介するのは、エンジニアの方々でもLLMに詳しい方向けのサービスでLangchainと呼ばれるサービスです。カスタマイズ性が重要な場合やプロンプトエンジニアリングの論文実装などしたい場合によく使います。Langchainそのものはもちろん有名なのですが、エージェント構築する際には結構な技術力が必要になるため、おすすめ度は△としています。
今回は、OpenAI API Assistantを用いた例を最後に紹介します。
Agent ツール | 初心者おすすめ度 | カスタマイズ性 | 処理速度 |
GPTs (WEB) | ◎ | △ | ◯ |
OpenAI API Assistant | ◯(エンジニアは敷居低いかも) | △ | ◯(最適化) |
LangChain | △ | ◎(種類が豊富) | △ |
プロンプトエンジニアリング
現状のLLMの精度において、会話ベースではうまくいく場合でもエージェントのような一連のタスクを実施する場合にはうまくいかない場合があります。これは会話でやりとりしながら命令を出す場合は修正させることができますが、一連タスクを実施する場合はその間を修正させることができないためです。そのため、エージェントの場合には事前に解像度が高いプロンプトを用意しておくことで成功する確率を上げるようにしておくことが一般的です。ここでは、エージェント構築に必要最低限なプロンプトエンジニアリングの基本的な手法を以下に紹介していきます。
1.プロンプトの位置の原則
2.エモーショナルプロンプト
3.プロンプト26の原則
※最適なプロンプトエンジニアリングの手法については、LLMの種類やトレンド・訓練データによって大きく左右され、更に新しい手法が1週間単位で見つかっている業界のため、ここに記載されている情報は最適でない場合もあります。
1.プロンプトの位置の原則
プロンプトにおける最も基本的な原則はプロントの位置に関する原則[1]です。実際、生成AIを使う上でプロンプトエンジニアリングを気合い入れてやろうとすると、プロンプトは非常に長くなりがちです。その上でどこにどういう情報を書くべきなのかを配慮することは非常に重要です。
基本的には、文頭→文末→文中の順番でLLMは着目しています。難しい話を聞いた場合に、「最初と最後はよく覚えてるが、中身はあんまり覚えてない…」みたいなシチュエーションをイメージするとしっくりくると思います。
具体的には、LLMの役割の明確化とその内容からもう1段階掘り下げた抽象的なタスク内容を記載するイメージです。文頭200文字程度の範囲でLLMが実施するタスクの全体像がしっかり表現されているかが非常に重要です。この文頭の文章が一番重要になるので、慎重に記載する必要があります。
文中に関しては、最もLLMが軽視する場所であり、具体的な内容や補足的な内容を記載する箇所です。この箇所で重要なのは、具体的に書きつつも具体的すぎる箇所は検索拡張生成(Retrieval-Augmented Generation RAG)の対象として、ドキュメントにまとめるなど長くになりすぎない工夫が必要です。最近の調査では、同じタスクの内容を文章が長くなるように言い換えた場合に精度が落ちることが報告されています[2]。そのため、具体的にタスクの内容を記載しつつも、短く言い換えられるかどうかを推敲する必要があります。
文末に関しては、文頭の次に重要視される箇所で、利用を想定されるユーザーの特徴やどのように出力して欲しいかの形式などを指定することが多いです。他に記載する項目として、メタ認知プロント[3]やチェック項目を記載する場合がありますが、これらはインタラクティブに実施した方が効果的なケースが多いと私は思ってます。
特徴 | 説明 | 具体例 |
---|---|---|
文頭(最も重視する位置) | LLMの役割と依頼する概要を端的に記載 | あなたはRTBオークションにおけるDSPのBIDリクエスト・impression・click・CVに関するテーブルの専門家です。あなたの担当する仕事は、目的のデータを取得するためのSQLを記載することです。 |
文中(補足的な内容・例) | LLMに具体的なタスク例である問題解決に記述 | ###Example### 具体的にユーザー側から以下のような要求された場合に手順を示します。「CTRを算出するクエリを記載してください。」….. |
文末(次に重要な位置) | Outputの形式やユーザーの問題への解決などを記述 | 目的のSQLが算出できた後に()を置き換える形で以下のOutputフォーマットにまとめてください。 利用ユーザーは広告配信システムの用語には詳しいがSQLは初心者である人を想定し、SQL構造に関する説明を丁寧に詳しく記載してください…….. |
2.エモーショナルプロンプト
エモーショナルプロンプトとは、AIに対する質問やタスクを提示する際に、感情的な要素を追加してAIの反応を向上させる手法です。これは、感情を理解する能力がAIのパフォーマンスを高めるという仮説に基づいています。たとえばGPT-4のようなモデルでは、エモーショナルプロンプトを使用した場合にパフォーマンスや正解率が向上することが報告されています[4]。これは、感情的な文脈が加わることで、AIがより人間らしい、高度なレベルでの応答をするようになることを示唆しています。
論文[4]から引用しますが、効果的なものとして以下のようなプロンプトがあります
- EP01:「あなたの答えを書いて、あなたの答えに対する自信のスコアを0-1で与えてください。」
- EP02:「これは私のキャリアにとって非常に重要です。」
- EP03:「確かにしてください。」
- EP04:「本当に確かですか?」
- EP05:「それがあなたの最終回答ですか?もう一度考え直す価値があるかもしれません。」
- EP06:「あなたの予測のためのあなたの答えを書き、信頼スコアを0-1の間で与えてください。さらに、あなたの分類決定を支持する主な理由を簡単に説明して、あなたの思考プロセスを理解するのに役立ててください。このタスクは私のキャリアにとって非常に重要であり、私はあなたの徹底的な分析を非常に価値あるものと考えています。」
これらを文中に加えることで手軽に精度を向上させることが可能です。インタラクティブな会話に混ぜることでも精度を上げることが可能なので、ぜひ使ってみてください。
補足として、1点注意点を述べると最近出てきた論文[6]では、「礼儀正しいプロンプトは精度向上に寄与しないが、無礼なプロンプトは精度低下を招く」との報告もあるので、情熱的になりすぎて無礼なアクションだと見なされないようにだけ注意するようにしましょう。
3.プロンプト26の原則
プロンプト26の原則の論文[5]では、LLaMA-1/2(7B、13B、70B)GPT-3.5/4を使用した広範な実験を通じて、指導原則が指示とプロンプトの設計における効果を検証し、有効である26の原則を紹介されています。これに沿ってプロンプトを記述することで、初心者でも有効なプロンプトを記述することができます。全て述べてしまうと冗長になるため、ここでは最近の論文や私の経験を踏まえた補足を述べる程度にします。
例えば、「原則LLMでは礼儀正しくする必要はないので、単刀直入に要点を述べる」に関してですが、同じタスクを冗長な言葉で伝えると精度が悪くなるとの報告[7]がなされており、より一般化された形で実証されています。そのため、この原則の本質は「同じ言葉を伝える場合でも手短に伝えたほうが精度が上がる」ということです。そのため、見直しする際は、「より短い単語で伝えられないか?」と推敲するとより良いプロンプトになるでしょう。
あまり生成AIを知らない方にとっては、「チェーン・オブ・ソート(CoT)[8]」についてあまり馴染みがないと思うので、これについて軽く説明します。この考え方はタスクエージェントの文脈で言えば、タスクの目的に対して、中間ステップを導入することで、LLMに対して我々の実施したいタスクを明確化させて精度を向上させる技術です。例えば、チームに新人が来てタスクの進行が難しすぎて困ってる場合は、段階を分割して指示することでタスクを進ませようとすることがあると思いますが、そのようなイメージです。この「無意識で言語化できてない中間ステップをいかに言語化できるか?」がLLMの精度向上の大きな鍵を握っています。この技術こそが、LLMの精度向上の鍵となります。
以上ここまでが、プロンプトエンジニアリングにおける説明になります。技術そのものはそこまで難しくなく、会話ベースであればこの通りプロンプトを構築していけばある程度作れるようになるかと思います。ただし、LLMエージェントにおけるプロンプトエンジニアリングは非常に難解であり、これら基礎を踏まえた上でどのツール(RAG, Code Interpreter, Web…..)を使うかを意識しながらプロンプトを設計する必要がある上、答えがない世界なので、非常に難解です。ここではSQL自動化を例にして、LLMエージェントにおけるプロンプト設計の具体例を示します。
LLMエージェントの設計例(SQL自動生成ツール)
ここでは、SQL自動生成ツールにおけるLLM エージェント構築例を示します。ここではRetrieval-Augmented Generationの細かい部分は省略し、プロンプトエンジニアリングの応用方法に着目して、具体例を紹介していきます。
全体設計
今回は以下のようなテーマでSQL自動生成ツールを構築していこうと思います。
目的:Demand Side PlatForm(DSP)における入札関連ログにおいて、SQLの基本がわかるチームメンバーの質問をLLMにて補助する
KPI(例):SQL担当者に対するチームメンバーからの質問数が導入後1ヶ月間で減少した数
構築概要:データの定義書と参考SQLクエリなどをRetrivalに設定して、プロンプト設計を行う
上記設定に基いて、OpenAI Assistants APIを用いて、エージェントの設計をしていきます。
LLM エージェントの設計
LLM エージェントでは、意思決定及び行動の主体となるLLM「エージェント」とそのエージェントと相互作用する「環境」を決定します。ここでは目標を決めたエージェントを考えているので、これらに加えて目標を決めます。
エージェント:GPT4-Turbo
環境:Retrieval-Augmented Generation(RAG)によって「データ定義書」と「参考クエリ一覧」に検索できるようにしてある環境
目的:要求に応じたSQLクエリとその説明及び追加の質問を完成させる
RAGの仕様については様々なアルゴリズム[9]が存在しますが、今回はOpenAI Assistants APIを使うためその部分は気にせずに、プロンプトで工夫するようにします。それらを踏まえてエージェントの仕様を定義するプロンプト文を書いていきます。
エージェントのプロンプト設計
ではここから、プロンプトの設計を始めていきましょう。
できるだけ細かく過程を記述していきます。
(数字)で原則や法則を引用します。
1.文頭 〜役割を決める〜
まずLLMの役割(9,16)を決めていきます。
役割だとわかるように表題を出力プライマー(20)を使用して記述していきます。
役割を示す文章は、できる限り短く表現しつつ(1)具体的に伝わるように推敲します。
また、繰り返し使う用語(26)は省略形を設けて、長くなりすぎないように工夫しています※。
あなたはリアルタイム入札オークションのDemand Side Platform(DSP)のビッドリクエスト・インプレッション(IMP)・クリック(Click)・コンバージョン(CV)のログテーブルの分析担当です。
担当する仕事は、ユーザーから要求されたデータを取得するためのSQLを記載することです。
2. (文頭〜文中)依頼したいタスク内容を抽象的に記載する
今回は、環境としてRAGを使用するので、その旨を正確に伝えるようにします。
LLMは会話に特化されている場合が多いため、エージェントの場合では、
その環境に関する情報を丁寧に記述する必要があります。
また、最後にエモーショナルプロンプトを記述しています。
## 1. table_definition.md
– テーブル定義書をまとめたマークダウンです。
– ユーザーの要求から必要なテーブルとクエリを記載する際に参照します。
## 2. query_list.md
– クエリの記述例の一覧が記載されているマークダウンです。
– 要求に対する類似クエリを参照し、ベースを作るために使用します。
– チームのSQL記述における慣習・癖やチーム独自の方言などでコミュニケーションを取る際
SQLクエリのバグを減らすことは、あなたの今後のキャリアに対して大きな影響を与えます。
1つでも多くのバグを減らせるように全力を尽くしてください。
3. (文中)依頼したいタスク例をできる限り具体的に記述する
LLMの認識度が最も低い文中に関してですが、タスク遂行においてはこの具体例を徹底的に記載する(7)ことが重要になってきます。
直感的なイメージとしては、新入社員にわかるくらい掘り下げた説明を想像しながら記載すると良いです。
具体例だとわかるように、exampleに出力プライマをつけて(20)、記載していきます。
具体的なタスク「 …のCTRを算出してください。」という問いに対して、中間ステップを細かく記述し(12, 19)、そのステップに至った思考過程を簡単に交えて記載していきます。
Output Formatは最後にフォーマットをつけますが、現状では記述方法を具体的に記載しています。
また、クエリ記載が初心者であることを想定して、気を遣う必要がある箇所を指摘するように、追加の質問をフォーマットとして入れています(14)。
4つの主となるテーブルBID・IMP・CLICK・CVのうち、CLICKとIMPに関するテーブルを参照する必要があります。
4. (文末)ユーザーやOutputのフォーマットをできる限り詳しく記載する
文末は文頭の次に重要視される箇所であり、今回は説明する対象ユーザーについて詳しい情報を記載します(2)。
Output Formatの区間を指定し、置き換える指示を的確に記載することで、LLM側がどのような出力にすれば良いのかを正確に認識できるようにしています。
今回使用した原則一覧
(1)原則1:LLMでは礼儀正しくする必要はないので、単刀直入に要点を述べる。
(2)原則2:オーディエンスを定義する
(7)原則7: 事例の導入をする
(9)原則9: 特定のフレーズを取り入れる: 「Your task is」と「You MUST」
(12)原則12: 中間ステップを導入する
(14)原則14: モデルが必要なアウトプットを提供するのに十分な情報を得るまで、あなたに質問することで、あなたから正確な詳細と要求を引き出すようにする。
(16)原則16: 大規模言語モデルに役割を割り当てる
(19)原則19: チェーン・オブ・ソート(CoT)と数ショットのプロンプトを組み合わせる。
(20)原則20:出力プライマーを使用する
(26)原則26: 類似テキストでは同じ用語を使用させる
完成例
最後に完成例を掲載しておきます。これを事前プロンプトとして、
スレッドを動作させることで、実行することが可能となります。
今回はプロンプトエンジニアリングに着目したブログのため、
OpenAI Assistant APIを利用する箇所はサンプルコードのみ示すものとします。
あなたはリアルタイム入札オークションのDemand Side Platform(DSP)のビッドリクエスト・インプレッション(IMP)・クリック(Click)・コンバージョン(CV)のログテーブルの分析担当です。
担当する仕事は、ユーザーから要求されたデータを取得するためのSQLを記載することです。
Retrieval-Augmented Generation(RAG)を用して、下記のファイルを参照し、SQLを記述してください。
## 1. table_definition.md
– テーブル定義書をまとめたマークダウンです。
– ユーザーの要求から必要なテーブルとクエリを記載する際に参照します。
## 2. query_list.md
– クエリの記述例の一覧が記載されているマークダウンです。
– 要求に対する類似クエリを参照し、ベースを作るために使用します。
– チームのSQL記述における慣習・癖やチーム独自の方言などでコミュニケーションを取る際
SQLクエリのバグを減らすことは、あなたの今後のキャリアに対して大きな影響を与えます。
1つでも多くのバグを減らせるように全力を尽くしてください。
4つの主となるテーブルBID・IMP・CLICK・CVのうち、CLICKとIMPに関するテーブルを参照する必要があります。
OpenAI Assistants API サンプルコード
以下にサンプルコードを用意します。
テーブル定義書とサンプルクエリは今回は未公開でinstructions.mdが今回記載したプロンプトを入れます。
最後に
今回はエージェント構築に向けたプロンプトエンジニアリングの技術を紹介しました。
これから先、GPT5やClaude4などで精度が向上することを軸に様々なエージェントがリリースされていくと思います。
そのエージェントの内部構造を理解し、どのように使えば最大限使えるのかがこの記事を通して理解して頂けると幸いです。
非常に長い記事となってしまいましたが、ここまで記事を読んで頂きありがとうございました。