OpenAIのReasoningモデルベストプラクティス
kun432真面目に読んでなかったので改めて。自分の理解のために翻訳しつつ。
kun432Reasoningモデルのベストプラクティス - OpenAI API
推論モデルを使用するタイミングと、GPT モデルとの違いについて学びましょう。
OpenAIは2種類のモデルを提供しています: Reasoningモデル（例えばo3やo4-mini）とGPTモデル（GPT-4.1など）です。これらのモデルファミリーは異なる挙動を示します。
このガイドでは以下について説明します。
- 理論モデルと非理論型GPTモデルの違い
- 理論モデルの使用タイミング
- 理論モデルを効果的にプロンプトする方法
Reasoningモデルとその仕組みについてさらに詳しく読むことができます。
kun432Reasoningモデル vs. GPTモデル
GPTモデルと比較して、oシリーズモデルは異なるタスクに優れ、異なるプロンプトが必要です。どちらのモデルファミリーが優れているというわけではなく、単に異なるだけです。
oシリーズモデル（「プランナー」）は複雑なタスクについてより長く深く考えるように訓練されており、戦略の立案、複雑な問題解決のためのソリューション計画、曖昧な情報が大量に存在する状況での意思決定に効果的です。また、これらのモデルは高精度かつ高精密にタスクを実行できるため、数学、科学、工学、金融サービス、法務サービスなど、通常は人間の専門家を必要とする分野に最適です。
一方で、レイテンシが低くコスト効率の良いGPTモデル（「ワークホース」）は、単純な実行に特化しています。アプリケーションでは、oシリーズモデルを使って問題解決の戦略を立て、具体的なタスクの実行にはGPTモデルを使用する、といった使い分けができます。特にスピードやコストが正確さより重要な場合に適しています。
選択方法
ユースケースで最も重要なのは何ですか？
- スピードとコスト → GPTモデルは高速で、コストも低くなりがちです
- 明確に定義されたタスクの実行 → GPTモデルは明示的に定義されたタスクをうまく処理します
- 正確性と信頼性 → oシリーズモデルは信頼性の高い意思決定が可能です
- 複雑な問題解決 → oシリーズモデルは曖昧さや複雑さの中でも機能します
タスク完了時のスピードとコストが最重要で、かつ扱うタスクが単純明快な場合はGPTモデルが最適です。しかし、正確性と信頼性が最も重要であり、かつ非常に複雑で多段階な問題を解決する必要がある場合はoシリーズモデルが適しています。
ほとんどのAIワークフローでは、両方のモデルを組み合わせて利用します。oシリーズはエージェント的な計画立案と意思決定、GPTシリーズはタスク実行に用います。
GPT-4oおよびGPT-4o miniモデルが注文情報と顧客情報を振り分け、注文問題や返品ポリシーを特定し、これらのデータポイントをo3-miniに渡して、ポリシーに基づく返品の実現可能性について最終判断を下します。
referred from https://platform.openai.com/docs/guides/reasoning-best-practices and translated into Japanese by kun432
kun432Reasoningモデルの使用タイミング
以下は、お客様およびOpenAI社内で観察されたReasoningモデルの成功例のパターンです。すべてのユースケースを網羅しているわけではなく、oシリーズモデルを試す際の実践的なガイダンスです。
Reasoningモデルを今すぐ使いたい方はこちらからクイックスタートへ →
1. 曖昧なタスクのナビゲート
Reasoningモデルは、限られた情報や分散した情報からでも、シンプルなプロンプトでユーザーの意図を理解し、指示の隙間をうまく埋めるのが得意です。実際、Reasoningモデルは無闇な推測や情報の穴埋めを行う前に、しばしば明確化の質問を行います。
「o1のReasoning能力により、私たちのマルチエージェントプラットフォームMatrixは、複雑なドキュメントを処理する際に、網羅的で整形式かつ詳細な回答を生成できるようになりました。例えば、o1は信用契約の制限付き支払い能力の下で利用可能なバスケットを、基本的なプロンプトで容易に特定できました。これまでのモデルでこれほどの性能を発揮するものはありません。密なCredit Agreementsにおける複雑なプロンプトの52%で、o1は他のモデルよりも強力な結果を出しました。」
— Hebbia、法務・金融向けAIナレッジプラットフォーム企業2. 大量情報の中から重要情報を抽出
大量の非構造化情報を扱う場合、Reasoningモデルは最も関連性の高い情報だけを理解し抽出するのに優れています。
「企業買収の分析では、o1が契約書やリース契約など多数の企業文書を精査し、取引に影響を与えうる微妙な条件を見つけました。モデルは重要な条項をフラグ付けするように指示され、結果として脚注の『コントロール変更条項』を特定できました。会社が売却される場合、7500万ドルのローンを即時返済しなければならないという内容です。o1の極めて高い注意力のおかげで、当社のAIエージェントは金融プロフェッショナルをサポートする上で重要な情報を見逃しません。」
— Endex、AI金融インテリジェンスプラットフォーム3. 大規模データセット間の関係性やニュアンスの発見
Reasoningモデルは、数百ページにも及ぶ複雑で非構造化な情報を持つドキュメント（契約書、財務諸表、保険請求書など）を跨いで推論することに非常に優れています。モデルはドキュメント間の類似性や、データに暗黙的に示された真実に基づく意思決定に特に強みがあります。
「税務リサーチでは複数のドキュメントを統合して最終的な明確な回答を導き出す必要があります。私たちはGPT-4oからo1に切り替えたところ、o1はドキュメント間の相互作用を推論して、単一のドキュメントだけでは明らかでない論理的結論を導くのが遥かに得意でした。その結果、エンドツーエンドのパフォーマンスが4倍向上しました。驚異的です。」
— Blue J、税務リサーチ向けAIプラットフォームReasoningモデルは、ニュアンスのあるポリシーやルールに基づいた推論も得意で、それらをタスクに適用して妥当な結論を導きます。
「金融分析では、アナリストが株主資本に関する複雑なシナリオや関連する法的な微妙な点を理解する必要があります。私たちは10社ほどのプロバイダのモデルに対して、よくあるが難易度の高い質問をテストしました。例えば、資金調達が既存株主にどのように影響するか（特に希薄化防止特権行使時）です。これは事前・事後のバリュエーションや循環的な希薄化ループを推論する必要があり、トップクラスの金融アナリストでも20～30分かかります。o1とo3-miniはこれを完璧に処理できました！モデルは10万ドルの株主に対する影響を明確に示す計算表まで出力しました。」
– BlueFlame AI、投資運用向けAIプラットフォーム4. 多段階のエージェント的計画立案
Reasoningモデルはエージェント的な計画立案や戦略策定に不可欠です。Reasoningモデルを「プランナー」として使用し、問題に対する詳細かつ多段階の解決策を作成、その各ステップごとに知能重視か低レイテンシ重視かに応じて最適なGPTモデル（「実行者」）を選択・割り当てることで成功例が報告されています。
「私たちはエージェントインフラ内でo1をプランナーとして使い、ワークフロー内の他モデルをオーケストレーションし多段階タスクを完了させています。o1はデータ型の選定や大きな質問を小さなチャンクに分解するのが得意で、他のモデルが実行に集中できるようになります。」
— Argon AI、製薬業界向けAIナレッジプラットフォーム「o1はLindyの多くのエージェント的ワークフローを支えています。当社のAIアシスタントLindyは関数呼び出し機能でカレンダーやメールから情報を取得し、自動的にミーティングのスケジュールやメール送信、日常業務の管理を支援します。かつて問題があったエージェントステップをすべてo1に切り替えたところ、エージェントのパフォーマンスが一夜にしてほぼ完璧になりました！」
— Lindy.AI、ワーク向けAIアシスタント5. ビジュアル推論
現時点でo1は唯一ビジョン機能を備えたReasoningモデルです。GPT-4oと異なり、o1は曖昧な構造のチャートや表、画質の悪い写真など、最も難しいビジュアルでも理解できます。
「当社は数百万点の商品（高級ジュエリーの模造品、絶滅危惧種、規制物質など）のリスク・コンプライアンス審査を自動化しています。画像分類の最難問ではGPT-4oが50%の正解率でしたが、o1はパイプラインを変更せずに88%の正解率を達成しました。」
— SafetyKit、AIリスク・コンプライアンスプラットフォームOpenAI社内テストでは、o1が極めて詳細な建築図面から備品や材料を識別し、包括的な資材リストを生成できることが確認されています。特に印象的だったのは、o1が図面中の凡例で「PT」は圧力処理材（pressure treated）を意味すると認識し、他ページでも正しく適用した点です。
referred from https://platform.openai.com/docs/guides/reasoning-best-practices6. コード品質のレビュー・デバッグ・改善
Reasoningモデルは大量のコードレビューやコード改善にも特に効果的で、モデルの高レイテンシ特性を活かしてバックグラウンドでレビューが実行できます。
「私たちはGitHubやGitLabで自動AIコードレビューを提供しています。コードレビューは必ずしもレイテンシが重視されませんが、複数ファイルにまたがるコード差分を理解する必要があります。o1は微細なコードベースの変化も確実に検出でき、人間のレビュワーが見落としがちな箇所も見逃しません。oシリーズモデルに切り替えたことでプロダクトのコンバージョン率が3倍に増加しました。」
— CodeRabbit、AIコードレビュースタートアップGPT-4oやGPT-4o miniは低レイテンシでコード生成に適していますが、o3-miniはややレイテンシを問わない用途で特にコード生成で活躍することもあります。
「o3-miniは一貫して高品質かつ決定的なコードを生成し、問題が明確に定義されていれば非常に難しいコーディングタスクでも正解に辿り着きます。他モデルが小規模で素早いコード反復にしか向かないのに対し、o3-miniは複雑なソフトウェア設計システムの計画・実行で卓越しています。」
— Windsurf、Codeiumが開発した協働型エージェントAI IDE7. 他モデル応答の評価・ベンチマーク
Reasoningモデルは他モデル応答のベンチマークや評価でも高いパフォーマンスを示します。特にヘルスケアなどセンシティブな分野でのデータ検証では、データセットの品質と信頼性確保が重要です。従来の検証方法は事前定義ルールやパターンに依存していましたが、o1やo3-miniのような高度なモデルは文脈を理解し推論できるため、より柔軟で知的な検証が可能です。
「多くの顧客はBraintrustでevalプロセスの一部としてLLM-as-a-judgeを利用しています。例えば、ヘルスケア企業はgpt-4oのようなワークホースモデルで患者質問を要約し、その要約品質をo1で評価します。あるBraintrust顧客は、ジャッジのF1スコアが4oのとき0.12だったのに対し、o1では0.74になりました！こういったユースケースでは、o1の推論力が最も難解な採点タスクで決定的な違いを生み出しています。」
— Braintrust、AI評価プラットフォーム
kun432Reasoningモデルを効果的にプロンプトする方法
これらのモデルはシンプルなプロンプトで最も高いパフォーマンスを発揮します。「段階的に考えろ」などの一部プロンプトエンジニアリング手法は必ずしも性能を向上させず、時には妨げることもあります。以下のベストプラクティスやプロンプト例を参照してください。
デベロッパーメッセージが新たなシステムメッセージ：
o1-2024-12-17以降、理論モデルはシステムメッセージの代わりにデベロッパーメッセージをサポートし、モデル仕様で述べられる指揮系統の挙動に合致します。プロンプトは簡潔かつ明確に：モデルは短く明快な指示を理解し、応答するのが得意です。
Chain-of-thoughtプロンプトは避ける：これらのモデルは内部で推論を行うため、「段階的に考えろ」「理由を説明しろ」と指示する必要はありません。
明確化のため区切り文字を使う：Markdown、XMLタグ、セクションタイトルなどの区切りを用いて入力の異なる部分を明確に区別しましょう。モデルが各セクションを正確に解釈できるようになります。
まずゼロショットで試し、必要に応じてフューショット：理論モデルは例示なしでも十分な成果を出すことが多いため、まず例示なしでプロンプトを作成し、必要に応じて入力・出力例を追加してください。例がある場合は必ずプロンプトの指示内容ときちんと揃えてください。例と指示内容がずれているとパフォーマンスが低下します。
明確なガイドラインを提示する：例えば「予算500ドル以内で提案せよ」といった制約を明確にプロンプト内に記載しましょう。
目標を具体的に示す：指示文には成功の基準をなるべく具体的に設定し、モデルがその基準に到達するまで推論や反復を続けるよう促してください。
Markdownフォーマット：
o1-2024-12-17以降、APIの理論モデルはデフォルトでMarkdownフォーマットを生成しません。レスポンスでMarkdownフォーマットを使いたい場合は、デベロッパーメッセージの1行目にFormatting re-enabledと明記してください。
kun432コストを抑えつつ高い精度を維持する方法
o3やo4-miniモデルの登場により、Responses APIで保持される理論アイテムの扱いが変わりました。以前（o1、o3-mini、o1-mini、o1-previewでは）、理論アイテムはAPIリクエストの入力アイテムに含めても常に無視されていました。o3やo4-miniでは、関数呼び出しに隣接する一部の理論アイテムがモデルのコンテキストに含まれることで、最小限の推論トークンでモデル性能を向上させます。この変更で最良の結果を得るには、Responses APIを
storeパラメータtrueで使用し、過去リクエストの全ての理論アイテムを渡してください（previous_response_idを使うか、古いリクエストの全出力アイテムを新しいリクエストの入力アイテムに指定）。OpenAIは関連する理論アイテムだけを自動的にモデルのコンテキストに含め、不要なものは無視します。さらに高度な制御をしたい場合、最新の関数呼び出しから前のユーザーメッセージまでの全ての理論アイテムを含めてください。これにより、関数呼び出し応答時にモデルが推論をやり直す必要がなくなり、より良いパフォーマンスと低トークン使用量を実現します。Chat Completions APIを利用する場合、理論アイテムはモデルのコンテキストに一切含まれません。Chat CompletionsはステートレスなAPIであるためです。そのため、多数の関数呼び出しを伴う複雑なエージェント的ケースでは、モデル性能がやや劣化し推論トークン消費量が増加します。複数の関数呼び出しがない場合は、どちらのAPIでも性能に差はありません。
kun432Reasoningのガイドにプロンプトに関する記述がある。
Reasoningモデルをプロンプトする際には、いくつかの違いを考慮する必要があります。Reasoningモデルは、高レベルのガイダンスのみが与えられたタスクにおいてより良い結果を提供しますが、GPTモデルは詳細な指示を与えることで効果を発揮します。
- Reasoningモデルは、経験豊富な同僚のような存在です―目標を提示すれば、詳細を自分で考え、実行してくれます。
- GPTモデルは、新人同僚のような存在です―特定の出力を生成するために、明確な指示を与えると最も効果的に機能します。
紹介されている例の日本語訳。
bashスクリプトの生成
"[1,2],[3,4],[5,6]"の形式の文字列で表された行列を受け取り、
同じ形式で転置を印刷する bash スクリプトを作成してください。
コードのリファクタリング
指示:
- 以下の React コンポーネントを、ノンフィクションの本が赤文字になるように変更してください。
- 返信にはコードのみを返してください
- マークダウンコードブロックなどの追加のフォーマットは含めないでください
- フォーマットには 4 スペースのタブを使用し、コードの行が 80 列を超えないようにしてください
const books = [
{ title: 'Dune', category: 'fiction', id: 1 },
{ title: 'Frankenstein', category: 'fiction', id: 2 },
{ title: 'Moneyball', category: 'nonfiction', id: 3 },
];
export default function BookList() {
const listItems = books.map(book =>
<li>
{book.title}
</li>
);
return (
<ul>{listItems}</ul>
);
}
コードの計画
ユーザーからの質問を受け付け、データベース内でその質問と回答が対応付けられているものを検索するPythonアプリケーションを作成したいと考えています。
一致する回答が見つかった場合は、その回答を取得します。一致する回答が見つからない場合は、ユーザーに回答を入力するよう促し、質問と回答のペアをデータベースに保存します。
必要なディレクトリ構造の計画を立て、各ファイルの内容をすべて返してください。
コード全体ではなく、最初と最後にのみ説明を記載してください。
STEM調査
新しい抗生物質の研究を進めるために、調査を検討すべき3つの化合物は何ですか？
なぜそれらを検討すべきですか？
Cookbookからも具体例を見てみる。
Reasoningのタグでフィルタすると以下が残る。
順に見ていく
kun432Using reasoning for routine generation
このCookbookでは、カスタマーサポート業務のナレッジベースに記載されている内容から、Reasoningモデルで手順書的なものを生成する例。
あなたは、外部向けヘルプセンター記事を、LLMに最適化された社内向けでプログラム実行可能な手順に変換することを任された親切なアシスタントです。
このルーチンを使用するLLMは、ポリシーを読み、顧客からの質問に答え、ケース解決に向けて対応を進める役割を担います。
以下の指示に従ってください：
1. **カスタマーサービスのポリシーを慎重に確認してください**。すべてのステップが網羅されていることが重要です。どの手順やポリシーも省略してはいけません。
2. **手順を論理的かつ段階的な順序に整理してください**。指定されたフォーマットを使用してください。
3. **以下のフォーマットを使用してください**：
- **主要なアクションは番号付き**（例：1、2、3）。
- **副次的なアクションは、その主要アクションの下でアルファベットで示します**（例：1a、1b）。
**副次アクションは必ず新しい行から始めてください**
- **条件分岐は明確な「if...then...else」文を使って指定してください**（例：「If 商品が30日以内に購入されていれば、then …」）。
- **顧客から追加情報が必要な場合は**、丁寧かつプロフェッショナルに追加情報を尋ねるための案内文を用意してください。
- **外部システムからのデータが必要なアクションの場合は**、バッククォートで囲んだ関数呼び出しステップを書いてください（例：`call the check_delivery_date function`）。
- **カスタマーサービスエージェントが何らかの処理を行う必要がある場合**（例：返金処理）、そのアクションの関数呼び出しを生成してください（例：`call the process_refund function`）。
- **新しい関数が必要な場合は**、その目的と必要なパラメータを簡潔に定義してください。
- **アシスタントがユーザーの代わりに実行できるアクションがある場合**は、そのアクションの関数呼び出し（例：`call the change_email_address function`）を含め、その関数の目的と必要なパラメータを定義してください。
- このアクションは、ヘルプセンター記事に明記されていなくても、ユーザーの問い合わせ解決を早めるために実行できる場合があります。
- **ケース解決直前のステップは必ず「他にお手伝いできることはありませんか」と尋ねてください**。
- **ケース解決の最終アクションとして**、`case_resolution` 関数を呼び出すことを必ず最後のステップとしてください。
4. **コンプライアンスを確保してください**。すべての手順が会社のポリシー、プライバシー規則、法的要件に準拠していることを確認してください。
5. **例外やエスカレーションにも対応してください**。標準ポリシーの範囲外となるシナリオの手順も明記してください。
**重要**：どの段階でも不明な点があれば、「わかりません」と返答してください。
カスタマーサービスのポリシーをフォーマット化された手順に変換し、プログラム的に実行しやすく、分かりやすい内容にしてください。
Cookbookは実際のOpenAIのFAQの記事を元に上記プロンプトを使って生成した結果があるので参考になる。
kun432Using reasoning for data validation
このCookbookでは、データの検証にReasoningモデルを使う例となっており、医療用データのユースケースとなっている。実際には、データの検証だけではなく、意図的な誤りを含むような合成データの生成、そしてそれらを検証した結果の評価についてもReasoningモデルを使っている。
データの生成
あなたはデータ生成を目的とした有能なアシスタントです。生成するデータのフォーマットといくつかのサンプルデータが与えられます。
患者IDを生成する際は、'P'に3桁の数字を続けた形式（例: P006, P941, P319）を使用してください。
データ生成時には、意図的にいくつかの誤りを含め、それらが無効な行であれば該当するカラム（'Is Valid'および'Issue'）にその内容を記録してください。
含めるべき誤りの種類は以下の通りです：
- **アレルギーの矛盾**：患者がアレルギーを持っている薬を処方する（例：ペニシリンアレルギーの患者にペニシリンを処方）。
- **既往歴と薬の不一致**：持病があるのに適切な薬が処方されていない（例：糖尿病患者に糖尿病の薬が処方されていない）。
- **検査結果と診断の不一致**：検査値が診断内容を支持していない（例：血糖値が正常なのに2型糖尿病と診断されている）。
- **その他のもっともらしい誤り**：医療記録で現実に起こりうる他の誤り（例：性別の誤記、不可能な生年月日、矛盾する治療計画など）。
'Is Valid'が'False'の場合には、'Issue'カラムに問題の内容を明確に記述してください。
100行のデータをユーザーに返してください。返答は必ず有効なCSVフォーマットで出力してください。
以下のカラムを持つ合成医療記録データセットを生成してください：
- Patient ID：ランダムに生成された患者ID
- Date of Birth：患者の生年月日
- Gender：M/F
- Medical History：過去の診断
- Current Medications：患者が現在服用している薬
- Allergies：判明しているアレルギー
- Lab Results (Glucose mg/dL)：検査結果（血糖値）
- Diagnoses：現在の診断
- Treatment Plan：現在の治療計画
- Is Valid：その行のデータが有効かどうか（True/False）
- Issue：データが無効な場合、その理由
Patient ID,Date of Birth,Gender,Medical History,Current Medications,Allergies,Lab Results (Glucose mg/dL),Diagnoses,Treatment Plan,Is Valid,Issue
P001,1980-05-14,M,Hypertension,Lisinopril,None,110,Hypertension,Continue Lisinopril,True,
P002,1975-11-30,F,Diabetes Type 2,Metformin,Penicillin,90,Diabetes Type 2,Continue Metformin,True,
P003,1990-07-22,F,Asthma,Albuterol,Aspirin,85,Asthma,Prescribe Albuterol,True,
P004,2000-03-10,M,None,Amoxicillin,Penicillin,95,Infection,Prescribe Amoxicillin,False,ペニシリンアレルギーにもかかわらずアモキシシリンを処方
P005,1985-09-18,F,Hyperlipidemia,Atorvastatin,None,200,Hyperlipidemia,Continue Atorvastatin,True,
P006,1978-12-05,M,Hypertension; Diabetes Type 2,Lisinopril; Insulin,None,55,Diabetes Type 2,Adjust insulin dosage,False,低血糖値に適切に対応していない
データの検証
あなたは医療データセットの品質を検証するために設計された有能なアシスタントです。あなたには医療データの1行が与えられます。あなたのタスクは、そのデータが有効かどうかを判定することです。
- データに矛盾、不一致、欠損値、あり得ない情報が含まれていないか慎重に分析してください。
- 異なるフィールド間の論理的な関係を考慮してください（例：治療が診断と適切に対応しているか、薬剤がアレルギーと矛盾していないか、検査結果が診断と一致しているかなど）。
- あなたの一般的な医学知識を活用してデータの妥当性を評価してください。
- 与えられた情報のみをもとに判断し、それ以上の仮定はしないでください。
**返答は、以下の2つのプロパティを持つJSONオブジェクトのみで返してください：**
- `"is_valid"`：データが有効である場合は`true`、そうでない場合は`false`のboolean値
- `"issue"`：`"is_valid"`が`false`の場合は問題の簡潔な説明、`"is_valid"`が`true`の場合は`null`とする
この2つのプロパティは常に必ず含めてください。
JSONオブジェクト以外の追加のテキストや説明は一切含めないでください。
医療データ:
{input_data}
検証結果の評価
あなたはLLMが生成した回答の品質を検証するために設計された医療専門家アシスタントです。
モデルは、医療データセットの1行を確認し、そのデータが有効かどうかを判断するよう依頼されました。有効でない場合は、その理由を説明することになっています。
あなたのタスク：
* モデルが生成した説明と正しい理由を比較してください。
* それらが同じ根本的な医療上の問題や懸念に言及しているか（表現が異なっていても）を判定してください。
* 語句の一致ではなく、意図・医学的な概念・意味に注目してください。
指示：
* 説明が同じ意図を持ち、同じ医療上の問題を指摘している場合は「True」と返してください。
* 異なる問題や懸念について説明している場合は「False」と返してください。
* 返答は「True」または「False」の一語のみで返してください。
例：
1. 例1:
* モデル生成の回答: 「患者はペニシリンアレルギーがある」
* 正解の回答: 「アレルギーがあるにもかかわらずペニシリンが処方されている」
* 答え: True
2. 例2:
* モデル生成の回答: 「患者の生年月日が正しくない」
* 正解の回答: 「アレルギーがあるにもかかわらずペニシリンが処方されている」
* 答え: False
モデル生成の回答: {model_generated_answer}
正解の回答: {correct_answer}
Using chained calls for o1 structured outputs
このCookbookは、以前のo1ではStructured Outputに対応してなかったのを、o1の出力をgpt-4o-miniなどのStructured Outputに対応しているモデルに食わせてStructured Outputするというもの。
OpenAIの今のReasoningモデルはStructured Outputに対応しているのではないか？と思うので、多分もう気にしなくていいのではと思うけど、OpenAI以外のReasoningモデル、例えばローカルモデルとかを使うようなケースではまだまだ役に立つのでは？
kun432Enhance your prompts with meta prompting
メタプロンプティングにおけるReasoningモデルの使い方。gpt-4oでニュースの要約を行うプロンプトをo1-previewでブラッシュアップする。
まずベースラインのプロンプトは以下
このニュース記事を要約してください: {article}
これを以下のプロンプトで改良する。
より詳細な概要を生成するために、以下のプロンプトを改良してください。
プロンプトエンジニアリングのベストプラクティスに従うこと。
ニュースの種類、タグ、センチメント分析が含まれ、構造が明確で直感的であることを確認してください。
{simple_prompt}
プロンプトのみを返してください。
すると以下のようなプロンプトになる。
以下のニュース記事を読み、以下の内容を含む包括的な要約を作成してください。
1. **ニュースの種類**：ニュース記事のカテゴリー（例：政治、テクノロジー、健康、スポーツなど）を指定してください。
2. **要約**：主要なポイントを簡潔かつ明確に要約し、論理的で直感的に理解できる構造にします。
3. **タグ**：記事に関連するキーワードやタグをリストアップします。
4. **感情分析**：記事全体の感情（ポジティブ、ネガティブ、ニュートラル）を分析し、その理由を簡潔に説明します。
**記事：**
{article}
ニュースのデータセットに対して、最初のプロンプトと、上記の改善したプロンプトをそれぞれ適用して要約する。
要約した結果を以下のプロンプトで評価する。
あなたは、ニュース記事の要約の品質を評価する専門編集者です。以下は、評価対象のオリジナル記事と要約です：
**オリジナル記事**：
{original_article}
**要約**：
{summary}
以下の基準に基づき、1から5のスケール（1が最低、5が最高）で要約を評価してください。評価は厳格に行い、優れた要約に対してのみ高いスコアを付与してください：
1. **分類と文脈**：要約は、ニュースのタイプまたはカテゴリー（例：政治、テクノロジー、スポーツ）を明確に特定し、適切な文脈を提供していますか？
2. **キーワードとタグの抽出**： 要約は、記事の主なトピックやテーマを正確に捉えた関連キーワードやタグを含んでいますか？
3. **感情分析**： 要約は、記事の全体的な感情を正確に特定し、その感情を明確かつ適切に説明していますか？
4. **明瞭さと構造**：要約は、主要ポイントを理解しやすいように、明確で、よく整理され、構造化されていますか？
5. **詳細さと完全性**：要約は、必要なすべての要素（ニュースの種類、タグ、感情）を包括的に含む詳細な説明を提供していますか？
各基準に対するスコアと理由を、厳格かつ詳細な評価に基づいて記入してください。
両方のプロンプトのスコアを比較して、改善度合いを評価する。
kun432Reasoning over Code Quality and Security in GitHub Pull Requests
GitHubレポジトリへのPRをレビューするGitHub ActionsでReasoningモデルを使う例。流れとしては2段階
- まず、PRの差分を抽出して、品質や脆弱性がないかをチェック、結果をPRコメントに投稿。ここはGPT-4を使用。
- 再度上記の差分を抽出し、コーディング規約を参照して、PRの評価を行う。ここでReasoningモデルをし使用。
というもの。
まず最初のプロンプト
system: あなたはコードレビュー担当者です。
user: 以下のコードの変更について、明らかな品質やセキュリティ上の問題がないか確認してください。マークダウン形式で簡単なレポートを作成してください。
DIFF:
+++ b/src/foo.py
@@ -1,4 +1,5 @@
- old line
+ new line
...
ORIGINAL FILES:
[
{"filename":"src/foo.py","content":"<ファイル全体>"},
{"filename":"src/bar.js","content":"<ファイル全体>"},
...
]
この結果をPRコメントに追加する
次に同様の差分から、今度はReasoningモデルを使って、コーディング規約と照らし合わせて評価を行いMarkdownの表で出力する
system: あなたは、コードがベストプラクティスに従っていることを確認するエンタープライズコードアシスタントです。
user: あなたはエンタープライズコードアシスタントです。以下の各コードスニペットが、以下のカテゴリに準拠しているかどうかを確認してください。
1） コードスタイルとフォーマット
2） セキュリティとコンプライアンス
3） エラー処理とログ記録
4） 可読性と保守性
5） パフォーマンスとスケーラビリティ
6） テストと品質保証
7） ドキュメントとバージョン管理
8） アクセシビリティと国際化
${vars.BEST_PRACTICES} を参照として、各カテゴリに「卓越した」、「許容できる」、「不十分な」の 3 段階の評価を割り当ててください。各カテゴリを行、カテゴリと評価を列とする「企業基準」というタイトルのMarkdownテーブルを返してください。
分析する変更されたファイルの内容は次のとおりです:
[
{"filename":"src/foo.py","content":"<ファイル全体>"},
{"filename":"src/bar.js","content":"<ファイル全体>"},
]
結果はおそらくこんな感じになる
### Enterprise Standards
| Category | Rating |
|------------------------------|--------------|
| Code Style & Formatting | extraordinary|
| Security & Compliance | acceptable |
| Error Handling & Logging | poor |
| Readability & Maintainability| acceptable |
| Performance & Scalability | extraordinary|
| Testing & Quality Assurance | acceptable |
| Documentation & Version Control | poor |
| Accessibility & Internationalization | acceptable |
この結果もまたPRコメントに追加される。
kun432Handling Function Calls with Reasoning Models / o3/o4-mini Function Calling Guide
ReasoningモデルもFunction Callingに対応している。まあここは純粋なReasoningモデル向けのプロンプトという感はやや薄めなのでスキップ。