システムプロンプトとモデルパラメータ

利益:

システムプロンプトが会話全体を通じてモデルをどのようにガイドするかを設計できる
適応的思考と努力パラメータの役割とコストへの影響を理解する
max_tokens、停止シーケンス、構造化出力などの出力制御を実装します。

同じモデルの 2 つの異なる製品は、まったく異なる動作をする可能性があります。違いはモデル自体にあるのではなく、システムプロンプトとそれに与えられるパラメーターにあります。システムプロンプトはモデルの「作業契約」であり、パラメータは「作業設定」です。この単元では、強力なシステムプロンプトを設計する方法、最新のモデルの思考と労力の設定が何を行うか、出力の形式や長さを制御する方法を学びます。これらの設定を正しく設定することで、品質とコストの両方を同時に管理できます。

システムプロンプト: モデルの永続的なディレクティブ

システムプロンプトは、会話全体に適用される高レベルの指示です。これらのルールは、ユーザーが何を入力しても有効です。適切なシステムプロンプトには、次のコンポーネントが含まれています。

役割/アイデンティティ: モデルは誰ですか? (「あなたは企業のサポートアシスタントです。」)
範囲と境界: 何が行われ、何が行われないのか? (「提供されたポリシー文書のみに基づく。」)
フォーマット規則: 出力はどのようになるべきか? (「最大 3 つの記事、公用語」)
不確実性の中での行動: 不確実性があるとき、人は何をしますか? （「情報がない場合は作成し、関係部門に指示してください。」）
セキュリティ/プライバシー: 何が望ましくないのか、何が望ましくないのか? (「個人データの要求」)

ヒント: システムプロンプトは固定しておいてください。リクエストごとに変更される情報 (現在の日付、ユーザー名、セッション ID) を埋め込まないでください。これにより、一貫性が失われ、ユニット 6 のプロンプトキャッシュが無効になります。変数情報をユーザーメッセージに含めます。

強引すぎる指導の罠

最新のモデルは指示に非常に厳密に従っています。古いモデルでは機能していた「必ず」、「常に」、「必ずこれを行う」などの攻撃的なフレーズは、現在ではオーバートリガーにつながります。モデルは、必要のないときにエージェントを呼び出したり、不必要に長時間実行したりします。ルールを緩和します。「必ず検索ツールを使用しなければなりません」ではなく、「会話の中に答えが見つからない場合は、検索ツールを使用してください」の方が正確です。

モデルパラメータ: 思考と努力

従来の LLM には温度パラメータがありました。値が低いほど、より具体的で一貫した出力が生成され、値が高いほど、より多様で創造的な出力が生成されます。最新世代のモデル (Opus 4.8、Sonnet 5 など) では、このアプローチが 2 つのより強力なメカニズムに置き換えられ、温度などのサンプリングパラメーターは受け入れられなくなりました。

適応的思考: モデルは応答する前に「頭」の中で段階的に推論します。モデルは、タスクの難易度に基づいて、どれだけ考えるかを決定します。複雑な複数ステップの問題の精度が大幅に向上します。彼は、単純な質問について不必要な遅れを避けるためにあまり考えません。
Effort: モデルがタスクにどれだけ深く取り組むか、および合計でどれだけのトークンを費やすかを調整する高レベルのノブ。一般的なレベル: 低、中、高、およびそれ以上。多大な労力を費やすと品質が向上する可能性がありますが、遅延とコストも増加します。少ない労力でスピードと節約がもたらされます。

設定

どういうことですか

いつ

考え事をしない/努力が少ない

速い、安い、表面的

シンプルな分類、短い応答、遅延に敏感なタスク

適応的思考 + 中程度の努力

バランスの取れた品質/コスト

ほとんどの汎用タスク

適応的思考 + 多大な努力

最高の精度

複雑な推論、コーディング、長距離エージェントの作業

注意: 「何が何でも最大限の努力をする」という反射神経がコストを膨らませます。タスクに合わせて労力を調整します。単純なタスクでは、多くの場合、少ない労力で、はるかに安価な価格で同じ正確な結果が得られます。クリティカルな精度が必要な場合は高いレベルに設定してください。

出力制御: フォーマット、長さ、構造

パラメーターに加えて、出力自体も制御します。

max_tokens: 出力のハードシーリング (1 番目と 3 番目のユニット)。
シーケンスの停止: 特定の文字列が見つかったときにモデルを停止します。構造化されたプロダクションでブレークポイントを設定するのに役立ちます。
構造化された出力: モデルの応答を指定した JSON スキーマに強制的に準拠させます。これにより、出力がプログラムで解析可能で有効であることが保証されます。プロンプトで「JSON を返すだけ」と言うよりも信頼性が高くなります。

{ "output_config": { "format": { "type": "json_schema", "schema": { "type": "object", "AdditionalProperties": false, "properties": { "category": { "type": "string", "enum": ["invoice", "technical", "return", "other"] }, "urgency": { "type": "string", "列挙型": ["低"、"中"、"高"] } }、"必須": ["カテゴリ"、"緊急度"] } } }}

コピー可能なシステムプロンプトテンプレート

# 企業サポートアシスタントあなたは企業サポートアシスタントです。- 提供されるポリシー文書のみに依存してください。文書にない場合は、「この情報はありません」と言ってください。 - 形式的かつ明確な回答を最大 3 文で入力してください。 - 個人データ (TC ID 番号、カード番号) を尋ねますが、回答の中でそれを繰り返さないでください。 - よくわからない場合は、推測しないでください。

# 構造化出力強制分類子あなたは要求分類子です。入力は顧客メッセージです。要求されたフィールドのみを返し、コメントは書かないでください。よくわからない場合は「その他」を使用してください。

# 不確実性の中に立つという明確な行動を持つアナリストあなたはデータアナリストです。提供された表から検証可能な推論のみを導き出します。データに存在しない結論を決してでっち上げないでください。推論が不明瞭な場合は「データ不足」と記入してください。

# トーンと長さを制御できるコンテンツライターあなたはコンテンツライターです。温かくプロフェッショナルな口調を使用します。各テキストは 120 ワード以下に制限してください。ありきたりなマーケティング言語は避けてください。

弱いプロンプト / 強いプロンプト

# WEAKB 役に立ち、良い回答をしてください。頑張ってください。

# STRONGRole: テクニカルサポートスペシャリスト。範囲: 製品ガイドのみ提供。形式: ステップバイステップ、番号付きリスト、最大 5 ステップ。制限: ガイドに記載されていないソリューションを推奨。「説明書を見ても見つからなかった」と言いましょう。プライバシー: 応答でユーザーが共有したシリアル番号を繰り返さないでください。

強力なバージョン。役割、範囲、形式、境界、機密性を個別に決定します。出力の一貫性は、この明瞭さから直接生まれます。

ミニケース3個

ケース 1 — 工数調整によるコスト削減。あるチームは、すべてのコールを高い労力と思考力で実行していました。単純な電子メールダイジェストであっても、作成にはコストがかかり、時間がかかりました。彼らは、要約などの単純なタスクを低労力に割り当て、契約分析を高労力に割り当てました。精度は維持され、平均レイテンシは半分になり、月々のコストは 3 分の 1 に削減されました。

ケース 2 — JSON 保証。運用チームは、「JSON を指定してください」というプロンプトとともに分類出力を要求しましたが、モデルは時折「結果は次のとおりです」と書き込み、パーサーがクラッシュしていました。構成された出力スキーマを接続すると、出力は毎回有効な JSON を返しました。解析エラーはリセットされました。

ケース 3 — 積極的な即時反動。アシスタントのプロンプトには、「すべての質問を検索する必要があります」と表示されました。このモデルは、すでに答えがわかっている単純な質問であっても不必要な検索を行うため、速度が低下し、コストが増加しました。彼らは「答えが文脈にない場合は検索する」というルールを緩和しました。不要な電話が70％減り、対応が早くなりました。

よくある間違い

システムプロンプトに変数データを埋め込むと、一貫性が失われ、キャッシュが無効になります。
過度に積極的な指示: 最新のモデルでは過剰なトリガーと不必要なコストが発生します。
すべてのタスクに多大な労力を費やす: 単純なタスクでは無駄が発生します。タスクに合わせて労力を調整します。
プロンプト経由のみで JSON をリクエストする: 時々壊れます。重要な場合は、構造化された出力を使用します。
境界/曖昧な動作を定義していない: モデルは捏造 (幻覚) でギャップを埋めます。
古い「温度」の習慣: 最新のモデルはこれを受け入れません。迅速かつ努力をもって行動を導きます。

より深く: 契約のようにプロンプトを作成する

経験豊富なチームは、システムプロンプトを、明確な条項、測定可能なルール、明確な境界など、文学的なテキストではなく契約書のように扱います。このアプローチには 3 つの具体的な利点があります。 1 つ目は一貫性です。同じ入力から、異なる時点で同様の出力が得られます。 2 番目はテスト容易性です。サンプルを使用して各項目を個別にテストできます。 3 番目はメンテナンスの容易さです。動作が間違っている場合、どのアイテムを交換すればよいかがわかります。

良い例は、前向きな例で先導することです。最新のモデルでは、「これを実行してはいけない」というリストを提供するよりも、「これがまさに望ましい出力がどのようなものであるか」という例を提供する方がはるかに効果的です。たとえば、分類子では、予想される JSON の 1 つまたは 2 つのサンプルをプロンプトに追加すると、書式設定エラーが大幅に減少します。

もう 1 つの強力なテクニックは、不確実性の動作を明示的に記述することです。「確信がない場合は、推測しないでください。『データが不十分です』と言ってください」などの条項は、モデルが捏造 (幻覚) で空白を埋める傾向を抑制します。この 1 つの文により、検証層の負荷が軽減されます。これについては単元 11 で説明します。モデルにすでに不確実性のフラグが立てられると、人間による検証が容易になります。

最後に、努力とプロンプトを一緒に考えてみましょう。労力がかかると、モデルはより多くの探索を行い、場合によっては望ましくない「余分な作業」(不必要な説明、追加の提案) を実行します。プロンプトで「必要な出力のみを提供し、コメントを追加しないでください」と指定すると、多大な労力によるこの副作用が相殺されます。

要約すれば

システムプロンプトはモデルの永続的なディレクティブであり、役割、範囲、形式、隠蔽動作、および機密性を定義します。最新のモデルでは、行動は温度ではなく適応的思考と努力パラメータによって駆動されます。作業をタスクに合わせることで、品質とコストを同時に管理できます。 max_tokens、stop 配列、および構造化出力を使用して出力を保護します。

アプリケーションタスク

タスクを選択します。 (1) 5 つのコンポーネント (役割、範囲、形式、曖昧さ、機密性) を含むシステムプロンプトを作成します。 (2) このタスクにどのレベルの労力を選択するか、およびその理由を述べます。 (3) 出力を構造化する必要がある場合は、小さな JSON スキーマをスケッチします。 (4) プロンプトに過度に攻撃的なパターンがないか確認し、それを和らげます。

チェックリスト

[ ] 優れたシステムプロンプトの構成要素を 5 つ挙げることができます。
[ ] 適応的思考と努力パラメータが何をするのか説明できます。
[ ] タスクに応じて労力を調整することで、品質とコストのバランスを保つことができます。
[ ] プロンプト経由で JSON をリクエストするよりも構造化された出力の方が安全である理由はわかりました。
[ ] 最近のモデルでは、過度に攻撃的な命令のリスクがあることがわかります。

システム プロンプト: モデルの永続的なディレクティブ