ML_Bear

中身まだみれてないんだけど、DeNAがセルフホストDify構築用のterraform公開してくれてるみたいだ。めちゃくちゃありがたいですね😇

https://github.com/DeNA/dify-google-cloud-terraform

OpenAIがAgent関連で色々発表しました！

個人的には、本で紹介したけど全然流行らなかったAssistantsAPIが「ResponsesAPI」として奇跡の復活を遂げたのが驚きでした😇

他にもLangSmith的な可視化ツールも搭載するAgents SDKの発表や、WEB検索のツールなど見どころも多かったです。

詳細をスレに↓ 

【Responses API】
・Chat Completion APIにツール機能や画像分析機能を付与した新しいAPI
・後述のWEB検索ツールなどを簡単に組み込める
・1回のAPI呼び出しで複数のツールと数回のモデル動作を使用して複雑なタスクを解決できるようになる (簡単なエージェントが動いているのとほぼ同義だと思う) 

・Chat Completions APIは今後も継続的にサポートされるのでツール不要の場合はこちらも使用可能
・ただし新しくプロジェクトを始める場合はResponses APIから始めることを勧めるとのこと。
・ResponsesAPIとの比較表は下図の通り。
・AssistantsAPIは2026年半ばに廃止予定（移行ガイド提供予定） 

【WEB検索ツール】
・gpt-4oとgpt-4o-miniで利用可能なWEB検索ツール
・最新の情報を明確な「引用付き」で取得可能
・ショッピングアシスタント、研究アシスタント、旅行予約など多様なユースケースを想定
・SimpleQAベンチマークで高い精度を記録
・費用: 1000検索あたり25-30ドル 

【ファイル検索ツール】
・企業や個人の文書データを効率的に検索するツール
・Assistants APIについていたものと似てると思う
・組み込みのクエリ最適化とリランキングがあり複雑な設定が不要
・さまざまなファイルタイプに対応 

【コンピュータ操作ツール】
・AIがマウス・キーボードを使ってPC操作を自動化
・Operatorと同じCUAモデルでブラウザやアプリを操作
・レガシーシステムもAPI不要で自動化可能に
・Tier3-5の開発者向けに研究プレビューとして提供開始
・費用 (1M token): 入力: $3, 出力$12 

【Agents SDK】
・実験的なSDK「Swarm」を大幅に改善したもの
・マルチエージェントワークフローの実装を簡素化
・LangSmith的な可視化ツールも使用可能
・Python対応済み、Node.js対応予定
・他社モデルとも互換性あり (Chat Completion APIが必要) 

Agent SDKの主な機能は以下の通り
・Agents：明確な指示と組み込みツールを持つLLM
・Handoffs：エージェント間の制御移行
・Guardrails：入出力検証のための安全チェック。Moderation API も使用可能。
・Tracing：LangSmith的な可視化・デバッグ機能 

【今後の展開】
・エージェントはすぐに労働力の不可欠な部分になる
・今回のリリースは最初の構成要素にすぎない
・今後、APIのより深い統合や、エージェントのデプロイ、評価、最適化のための新ツールを提供予定
・シームレスなプラットフォーム体験の提供を目指す

【参考資料】

New tools for building agents
https://openai.com/index/new-tools-for-building-agents/

Agents
https://platform.openai.com/docs/guides/agents

Agents SDK
https://platform.openai.com/docs/guides/agents-sdk

Responses vs. Chat Completions
https://platform.openai.com/docs/guides/responses-vs-chat-completions

公式Devアカウントのこのスレもわかりやすいと思います😇
https://x.com/OpenAIDevs/status/1899531225468969240

以前、OpenAIのReasoningモデルのベストプラクティスを紹介しましたが、Anthropicも同様のガイドを出していました。CoTは避けようといった大まかな内容には共通点も多く、面白かったです😇

以下 2つのトピックをスレで紹介します
・プロンプトエンジニアリングのコツ
・テクニカルな考慮点  

続く↓ 

【プロンプトエンジニアリングのコツ】
1. しっかり考えるよう指示しよう
2. few-shotは必要最低限に  
3. 思考過程の再入力は避ける
4. 長文出力性能を活かそう
5. 自分でチェックさせよう
6. 性能重視なら英語で指示
7. 大規模アウトプット時には構造化を
8. 小規模な思考は従来のCoTで十分

1. しっかり考えるよう指示しよう
・「手順を細かく列挙する」より「問題をしっかり考えて」というハイレベルな指示の方が創造性を活かせる
・何を望んでいるのかは明確かつ具体的に示そう
・精密な構造化が必要な場合は、シンプルな箇条書きを与えた後、出力された思考過程を確認して微調整しよう。

2. few-shotは必要最低限に  
・下図に示すようにClaudeでは <thinking> タグなどで推論例を提示することも可能
・だが、事前の例示が多すぎるとモデルの自由な思考を阻害することがあるので自由に考えさえることも検討しよう。

3. 思考過程の再入力は避ける
・Claude が生成したステップ思考（thinking）をそのままユーザープロンプトに流し込むと、モデルの混乱や性能劣化を招く場合がある
・デバッグ用途として参考に見るだけに留めるのがおすすめ

4. 長文出力性能を活かそう
・Extended thinkingモデルは長文テキストを出力することに優れる
・なるべく長い時間考えられるように工夫して指示してあげよう。図の例などを参考。

※ Extended thinking: AnthropicではOpenAIで言うところのReasoningモデルをこう呼ぶ

5.自分でチェックさせよう
・Claudeに自らアウトプットをチェックさせるのが有効
・例: タスク完了前に簡単なテストで作業を検証する、正しい結果かどうか分析を行う、テストコードを実行する

6. 性能重視なら英語で指示
・Extended thinkingの推論は英語が最も得意とされている
・出力は日本語にしても、推論時の混乱を減らすために主要な指示文は英語で書く、といった使い分けで性能向上が期待できる。

7. 大規模アウトプット時には構造化を
・20,000 語相当以上のテキストが必要な場合は「段階的なアウトライン」→「段落ごとの内容固め」など、構造化出力を指示する。
・学術的レポートや長大データ生成では「最初にインデックスと見出しを作る」→「内容を分割して展開」の手順が有効。

8. 小規模な思考は従来のCoTで十分
「途中経過は詳しく要らないけど多少のステップ思考はしてほしい」くらいなら、Extended thinkingモードではなく、標準モードでCoTのプロンプトを書くだけで十分な場合もよくある。

【テクニカルな考慮点】
1. 最低 1024 トークンが必要  
2. 長い思考を行う際はバッチ処理を検討
3. 大規模出力時もバッチ処理やストリーミングを
4. コストと時間に注意  
5. 前のターンの thinking は課金対象にならない  
6. 他機能との併用制限に注意

1. 最低 1024トークンが必要  
・Thinking には最低 1024 トークンが必要
・最初は小さめ（1024）から開始し、タスクの複雑さに応じて増やすのがおすすめ

2. 長い思考を行う際はバッチ処理を検討
・大量の思考トークンを要するタスク（目安として32,000 超）を一度に実行するとタイムアウトやネットワーク上限に達しがち。
・適切に分割してバッチ処理を行うのが良い。

3. 大規模出力時はバッチ処理やストリーミングを検討
・Claude 3.7は128,000トークン規模の出力も可能だが、回線切断リスクを減らすためにストリーミングやバッチ処理を推奨。
・単にトークン数を大きくするだけでなく、段階的に増やし最適バランスを探る。

4. コストと時間に注意  
・Thinking トークンも出力トークンとして課金対象
・思考用トークンが増えるほど、応答時間も長くなるため、必要性に応じてバランスを取ることが重要。

5. 前のターンの thinking は課金対象外
・過去の thinking ブロックはコンテキストウィンドウから自動的に除外される
・トークン管理上は何度も積み重ならない設計となっている

6. 他機能との併用制限
・thinking が ON のときは `temperature`, `top_p` などのパラメータ変更は非対応。
・ツール強制使用 (forced tool use) やレスポンスのプリフィル (pre-fill) も利用不可。

参考記事

Extended thinking tips
https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/extended-thinking-tips

Building with extended thinking
https://docs.anthropic.com/en/docs/build-with-claude/extended-thinking#how-extended-thinking-works

OpenAI版のベストプラクティスは↓で紹介しました
https://x.com/MLBear2/status/1890201467350577591

o3, o4-miniから導入されたFlex Processingが便利かもなのでメモ📝

【Flex processingとは？】
・o3, o4-miniからOpenAI APIに導入された新しいオプション
・多少の遅延やGPUリソースエラーの発生を許容するとAPIコストが半額に
・リクエストにパラメータを1個足すだけで利用可能

詳細はスレに↓ 

【安くなる理由 / 注意点】
・Flex Processingは「即座に処理しなくても良いリクエスト」を低優先キューへ回し、OpenAI側のGPUが低負荷の際に処理するための仕組み。
・混雑時は待たされレスポンスが遅延したり、最悪の場合はGPUリソースエラーで弾かれる。
・その代わり支払うAPIコストは半額で済む

【どうやって利用するの？】
・APIコールの際に"service_tier":"flex"を追加するだけ
 ・デフォルトのタイムアウトは10分。それ以上に遅延することもあるから注意
・実験を並列で回して1個1個の処理時間気にしない時とか良さそう？
・OpenAI SDKを利用しているとtimeoutの際は自動的に2回再実行される 

【失敗したAPIコールは課金されるの？】
・GPUリソース不足エラーや処理待ちのまま1トークンも生成されなかった場合は課金されない
・生成中にタイムアウトを迎えた場合、生成された分は従量課金される (なのでタイムアウト長めにするといい？)

【Batch APIとの違いは？】
・今までもBatch APIという仕組みがあり、処理の遅延を許容するとAPIコストが半額になった
・Batch APIは専用エンドポイントにJSONLを投げる必要があった
・他方、Flexは通常エンドポイントへのリクエストに1行足すだけで利用可能

・大量のバッチ処理はBatchを利用し、遅延を許容できる適時処理はFlexを利用するのが良さそう

まだ本格的に試したことないので429エラー多すぎて使えないかもですが笑、Batchみたいに特別なエンドポイントに投げなくてもいいのは楽ですね。

詳細は↓のDocをご覧ください😇

https://platform.openai.com/docs/guides/flex-processing