私は最近OpenAIのパートナーコースを修了し、Technical Practitionerの証明書を取得しました。カリキュラムの多くは、システムレベルのトピックや市場へのアクセストピック、すなわちRAGワークフロー、APIプラットフォーム、モデル差、フィンタニング、カスタムGPT、ガードレイル、ビジネス価値フレームワークに焦点を当てています。 これらすべての事柄。 しかし、この投稿では、毎日ユーザーに適用される私の「aha」の瞬間や洞察をいくつかシェアしたいです。彼らは、初心者レベルの勧告を超えて、システムが実際にどのように機能するかを理解し、その理解を使用して、日常の思考と仕事でより一貫した結果を得るために。 次に、GPTを失望的なギャンブルから信頼できるツールに変える蒸留されたチェックリストです。 1. GPTが“gets dumber”: コンテキストウィンドウは本物のボトルネック 各モデルには、コンテキストウィンドウ(測定する)があります。 フリーレイヤーの場合、そのウィンドウはおよそ数千語に翻訳されます。 tokens ウィンドウには、あなたの指示、アップロードしたファイル、モデルの以前の回答、会話履歴が含まれています。 トレードが長くなり、またはあなたのタスクが複雑になるにつれて、モデルは詳細を落とし始めます. It may ignore previous constraints, forget definitions, or contradict things you established. トレードは、以前の制約を無視し、定義を忘れ、またはあなたが確立したものを矛盾させることがあります。 What to do instead: 大規模なタスクを段階に分割する(バッチで情報提供) 定期的に「働く仮定」をまとめ、GPTにそれを使用していることを確認するように依頼します。 長いプロジェクトでは、チャットから構造化されたワークフローに移行します(セクション 7 でその詳細を参照)。 モデルは優しく年をとらない システムはそうする コースからの重要なアイデア: . models are products, not living systems 一度リリースすると、モデルのトレーニングデータはほとんど凍結されます。時間の経過とともに、知識は自然に枯渇する - モデルが悪いからではなく、世界が動き続けるからです。 継続的に改善しているのは、モデルを取り巻くシステムです。 異なる強みを持つ新しいモデル より良いルーティングとオーケストラ ランタイムで新鮮な情報を注入する検索のようなツール だから選ぶのは より深いモデルは、より良い理屈を示す傾向がありますが、遅くなる可能性があります。タイムプレッシャー下でスピードとイテレーションを最適化すると、より速いモデル(例えばGPT‐4o)に切り替えます。 どのモデルを使うかは、 それはダウングレードではなく、制約意識の選択です。 シンプルなハイライト: If latency matters more than brilliance, switch models. If correctness matters more than speed, slow down. Prompt engineering is not a hack - it's just good product requirements. プロンプトエンジニアリングはハックではありません。 早速エンジニアリングはファンタジーのように聞こえますが、それは基本的に: あなたの入力構造は、モデルの思考構造になります。 Sample prompt construction to include, feel free to mix and match where applicable. サンプルプロンプト構造を含む、適用可能な場合に混合し、適合してください: 役割:モデルは誰のふりをするべきか? 目標:どんな結果が欲しいですか? 制限:何が真実でなければならないのか?何を避けるべきなのか? 背景:どのような背景が必要ですか? 品質バー:成功をどのように判断しますか? 出力形式:ヘッダー、弾丸、テーブル、コードなど あなたがすでに「良い」の見た目を知っているなら、小さなサンプルを追加すると、品質を劇的にジャンプすることができます。 ほとんどの現実の問題においては、論理は答えよりも重要である。 職場の多くの質問には、正しい答えが1つしかありません。 あなたが結論を求めるだけで、あなたは自信のある結論を得る - 時には揺るぎない論理の下にある。 その代わりに、フレームワークを求める: なぜこのアプローチを選んだのかを説明してください」または、使用する方法、フレームワーク、思考の学校を教えることもできます。 これにより、GPT はファンシーな autocomplete ツールから a : thinking amplifier 仮定があなたの世界に合っているかどうかを迅速に評価できます。 盲点を発見できる you can iterate on the reasoning - not only the output. あなたは論理に反復することができます - not only the output 精度:GPTは非常に間違って、非常にスムーズに GenAIは流暢な出力で素晴らしいです. それがどれほど自信を持つべきかをあなたに伝えるのは素晴らしいことではありません。 だからあなたは時々、きれいな、権威的な、そして完全に作り出されたように聞こえる答えを得るでしょう。 また、あなたのスピードがこれに影響します。 Vague prompt → より多くの創造性 → 幻覚のリスク Precise prompt → narrower search space → リスクの低下 正確さが重要であれば、私は文字通りカリブレーションを求めます: 「高信頼性の主張だけをあげる」 「自信がなければ、明確にラベルアップしてください」 「それぞれの主張(ソース、チェック、または実験)を確認する方法を教えてください。 その一つ一つの変化は、「自信のないばかげ」の問題を大幅に減らす。 6.検索エンジン vs. GPT: 彼らは異なる問題を解決する 高いレベルでは、検索エンジンとGPTは異なるものに最適化します。 検索エンジン Do GPT 依存 (しばしばベクトル検索として記述される) あなたが提供する文脈を加えて、最も信頼できる継続を生成します。 keyword matching + ranking semantic similarity Use a traditional search engine when you need: 特定のページまたはドキュメント 既存の紙 引用による事実主張 Use GPT when you need: 概要または合成 比較とトレードオフ分析 再編又は再編 シナリオ、概要、または意思決定支援 はい、GPT もしあなたが少しでも環境意識を持っているなら、それはキャンプ火災を開始するために森を切り落とすようなものです:より多くのコンピューティング、より多くのエネルギー、そして いつもより良い結果。 CAN not 新しい機能は「エキストラ」ではなく、あなたが働く方法を変えます。 チャットは迅速なQ&Aのための素晴らしいですが、実際の仕事は反復的なものです。 Canvas: edit mode instead of chat mode (チャットモードではなく編集モード) Canvas は長い形式の書き込みまたはコードで、繰り返し修正したい場合です。あなたは「質問をする」のではありません - あなたは共同編集しています。 プロジェクト:同じ背景を再説明するのをやめる プロジェクト スペースでは、ファイル、文脈、および会話が一緒に保存されますので、同じセットアップを貼り付け続けることはありません。 MCP:GPTはアプリプラットフォームのように動き始める モデルコンテキスト・プロトコル(MCP)は、GPTをアプリのエコシステムに近いものに変えています - ツールが接続でき、ワークフローが自動化され、 old SEO-driven discovery model gets disrupted. Rethink about marketing channels & budgets. Tool Use & Function Calling: From Answers to Actions (ツールの使用と機能の呼び出し:回答から行動へ) 現代のGPTはテキストを生成するだけでなく、ツールを呼び出し、コードを実行し、クエリシステムを発信し、構造化された出力を発信することができます。 これが「考えるのを助けて」と「実行するのを助けて」の違いです。正しいインターフェイスを設計すると、モデルは単なるブレインストーミングパートナーではなく、実際のワークフローの一部になります。 メモリ&インストラクション: 繰り返しが少ない、継続性が増える 持続的な指示と軽量なメモリは、モデルが時間の経過とともに好み、トーン、および作業仮定を保持することができることを意味します。 うまく使用すると、設定コストを削減します。悪く使用すると、悪い仮定にも閉じ込められますので、意図的にレビューしてリセットする必要があります。 (製品で作業する場合、このセクション全体は機能についてではなく、ソフトウェアがどのように設計されるかについての変化についてです。 最も過小評価されたスキル:モデルを「カリブレート」することを学ぶ 最高の結果を得る人々は、GPTを販売機のように扱うのではなく、調節が必要なシステムのように扱います。 実践的なループ: 品質バーを設定する(「良い」という意味は何ですか?) 論理を求める(表面仮定) ストレステスト(反論、エッジケース、何が答えを変える?) Verify(ソース、データ、迅速な実験) Iterate (tighten constraints and format) それは、GPTが一貫して役に立つとき - あなたがプロセスをコントロールしているため、単一のプロンプトで賭けるのではありません。 モードについて考える簡単な方法: チャット → thinking out loud (exploration, framing, ideation) Canvas → shaping the work (editing, refining, iterating) Codex → 作業の実行(適切なコードタスク、繰り返しのアクション) これはCodexのようなツールが輝く場所でもあります:タスクが明確に定義され、インターフェイスが実行(特にコードのための)に設計されると、モデルはチャットアシスタントとして機能しなくなり、信頼できるプログラマのカップルのように振る舞い始めます。 結論として より良い回答を求めるのをやめ、より良い相互作用を設計し始めましょう. これらのすべては、アプリを作成したり、APIを呼び出す必要はありません - それはあなたがすでに使用しているシステムのように少し考えることを学ぶことです。 他のヒント、ワークフロー、またはGPTの実際の仕事における有用性を顕著に向上させる小さなハックを見つけた場合 - 賢いヒントだけでなく - 私はそれらを聞くのが好きです。