利益:
- ストリーミングとは何か、イベントの種類、ストリーミングが必要な理由を説明できる。
- max_tokensはタイムアウトと128Kロング出力の関係を把握
- ワークロードに応じてストリーミングリクエストと非ストリーミングリクエストを適切に選択できる
チャット インターフェイスでは、応答が単語ごとに「入力」されることに気づいたかもしれません。これは視覚的な華やかさではありません。これはストリーミングと呼ばれる技術の結果であり、実稼働品質の LLM 統合には多くの場合必須です。この単元では、フローとは何か、フローがどのようなイベントで構成されているか、長い出力やタイムアウトとの関係、フローをいつ使用するか、いつ使用しないかを学習します。ライブアシスタント、長いレポートの生成、バッチ処理など、プロフェッショナルの実際のタスクを通じてこのトピックを取り上げます。
フローとは何ですか?
非ストリーミング (同期) リクエストの場合は、モデルが応答全体を生成するまで待機します。答えが完成すると、それはまとめて届きます。ストリーミング リクエストでは、サーバーはモデルが生成されるにつれて応答を少しずつ送信します。技術的には、これはサーバー送信イベント (SSE — Server-Sent Events、サーバーが開いた接続を介して小さなイベントを連続して送信する方法) を使用して行われます。
違いはユーザー エクスペリエンスで明らかです。8 秒かかる応答では、非ストリーム ユーザーは 8 秒間空白の画面を見つめます。ストリーミング ユーザーは約 0.5 秒以内に最初の単語を目にし、テキストが流れ始めます。体感的な待ち時間 (ユーザーが感じる待ち時間) は大幅に短縮されますが、合計時間は変わりません。
フローのイベントタイプ
フローとは一連の出来事です。概念的に、典型的なフローは次のようになります。
事件
意味
メッセージ開始
反応が始まりました。モデルやIDなどのヘッダー情報が到着しました。
content_block_start
コンテンツのブロック (テキストなど) が開始されました
content_block_delta
小さなテキスト (デルタ) が到着しました。あなたはこれらを集めています
content_block_stop
ブロック完了
メッセージデルタ
stop_reason や使用法などの終了情報を更新
メッセージ_ストップ
返信終了
コードは、content_block_delta イベント内のテキストの部分を順番に結合します。最終的には、非ストリーミング応答とまったく同じテキストが得られます。通常、使用量 (トークン番号) はフローの最後に明確になります。フローが終了するとコストを追跡できます。
ヒント: ほとんどの公式 SDK (ソフトウェア開発キット - プロバイダーの既成ライブラリ) は、ストリームを収集するヘルパー (stream.get_final_message() など) を提供します。すべてのトラックを手動で管理する必要はありません。フルテキストが必要な場合、個々のイベントを処理するが、ライブ印刷の場合は、このヘルパーを使用します。
長い応答、max_tokens、およびタイムアウト
ストリーミングの 2 番目の、より技術的な原因はタイムアウトです。 HTTP リクエストが一定時間内に完了しない場合、クライアントは接続を切断します。モデルから大量の出力 (例: 40,000 トークンのレポート) をリクエストすると、非フロー呼び出しがこの制限を超えてタイムアウトになる可能性があります。リクエストは失敗し、生成されたトークンの料金を支払う必要があります。
最新のモデルでは、1 回のリクエストで最大 128,000 個のトークンを出力できます。ただし、経験則は明らかです。「max_tokens」の値が高い場合 (約 16,000 を超える場合)、ストリームを使用します。ストリーミングにより接続が維持され、タイムアウトが防止されます。進捗状況もすぐに確認できます。
- `max_tokens`: モデルが生成できる最大出力トークン。硬い天井。割り込みが発生した場合は、stop_reason max_tokens が返されます。
- コンテキスト ウィンドウ: 入力と出力の合計が収まる必要があるウィンドウ。 max_tokens は出力の上限です。この 2 つを混同しないでください。
注意: max_tokens が大きい非フロー リクエストをスローすることは、運用環境における典型的な間違いです。応答がなければ接続は切断され、ユーザーにはエラーが表示され、トークンのコストが無駄になります。長い出力 = ストリーム。
いつ流れるのか、いつそうでないのか?
ステータス
好み
なぜ
ライブチャット/アシスタント
流れ
レイテンシの低下が認識され、ユーザーは進捗状況を確認できる
長文レポート・資料作成
流れ
タイムアウトを防ぎ、大出力を安全に伝送します
短い分類 (例: 単一の単語タグ)
流れがない
出力はすでに小さいです。追加の複雑さは不要
バッチ処理
フローレス/バッチ
結果はすぐには表示されません。ユニット 7 を参照
自動化ステップ (バックグラウンド)
通常は流れがない
結果を次のステップに渡します。ライブ表示はありません。
コピー可能なプロンプト/テンプレート
ストリーム自体はプロンプトではありませんが、プロンプトはストリームによって生成される出力を管理するために重要です。長くて流れるような制作では、構造を正面から印象付けることで、品質とトレーサビリティの両方が向上します。
# 長いレポートをセクションに分割します (進行状況がフローで表示されるように) 次の見出しを付けて、この順序どおりにレポートを作成します。各見出しは「## 」で始めます:## 概要## 調査結果## 推奨事項## 次のステップ
# 長いプロダクションでの切り捨てを避けるために、ターゲットの長さを指定します。合計テキストは約 800 ワードになります。分量のバランスを保ってください。最後に文を半分残さないでください。
# ストリーミング アシスタントに最初の文をすぐに伝えます。最初に一文で直接答えてから、詳細を説明します。したがって、ユーザーは待っている間、すぐに結果が表示されます。
# 長い出力を構造化しておきます (後で解析できるようにします)。これらのセクションに出力を出力し、各セクションに個別の '### ' ヘッダーを付けて、プログラムで解析できるようにします。 ### 概要 ### 本文 ### ソース
弱いプロンプト / 強いプロンプト (長時間生産)
# WEAKこのトピックについて長く詳細なレポートを作成します。
# STRONGこのトピックに関して約 900 語のレポートを作成します。見出し: ## 概要、## 分析、## リスク、## 推奨事項。各見出しは最大 3 段落にする必要があります。最後に文を半分残さないでください。
強力なバージョン。長さ、構造、仕上がりの品質を事前に決定します。フローにセクションが入ると、ユーザーは進捗状況を明確に確認し、モデルが中断されるリスクに備えて長さを自分で管理します。
ミニケース3個
ケース 1 — 空白の画面に関する苦情。コンサルティング チームのクライアント アシスタントは流れのない対応をしていました。平均応答時間は 7 秒、ユーザーは「フリーズしませんか?」と尋ねます。彼は不平を言った。一旦流れに乗ると、最初の単語は約 0.6 秒で出てきました。合計時間は変わりませんでしたが、「遅い」という不満はほとんどなくなりました。
ケース 2 — 古いレポート。財務チームは 30 ページの四半期報告書を作成していました。 max_tokens: 30000 の場合、フローなしリクエストは 60 秒のクライアント タイムアウトでスタックし、リクエストは失敗し、生成されたトークンが請求書に書き込まれます。彼らは流れに身を任せた。接続は維持され、レポートは完全に配信され、無駄なコストが排除されました。
ケース 3 — 不必要なフロー。運用チームは受信メールに「緊急/定期」というラベルを付けていました。アウトプットは一言でしたが、彼らはフローを愛用していました。このフローでは 1 単語の応答では何のメリットも得られず、コードが不必要に複雑になってしまいました。フローレスに切り替えたところ、コードは簡素化されましたが、動作は変わりませんでした。教訓: ストリーミングは、どこでもではなく、長時間/ライブの出力で価値があります。
よくある間違い
- 長い出力でストリームを使用しない: タイムアウトと無駄なトークン コスト。
- 短い出力でのストリーミングの使用: 不必要に複雑になり、メリットはゼロです。
- ストリームの最後にある `stop_reason` をチェックしない: max_tokens で切り詰められた応答は完了したとみなされます。
- デルタの不適切なマージ: SDK ヘルパーを使用して手動で合計すると、順序/欠落部分エラーが発生します。
- ストリームの途中で「使用法」を読み取ろうとする: トークン番号は通常、最後に明らかになります。最後にコストを追跡します。
- ストリーミングをコスト削減と誤解する: ストリーミングはエクスペリエンスと耐久性を向上させます。トークンの価格は変わりません。
さらに深く: 流れの中断と回復力
ストリーミングはライブ接続です。これは、その強さでもあり、脆弱さでもあります。接続が途中で切れた場合（ネットワークの変動、クライアントのタイムアウト）、それまでに蓄積したテキストは保持されますが、応答は不完全になります。運用品質のストリーミング クライアントは、これに備える必要があります。部分テキストを「完了した応答」として扱ってはならず、message_stop イベントが表示されるまで応答が終了したと見なすべきではありません。
2 番目の微妙な点は、フローによってコストが変わらないことです。ストリーミングを使用して応答を受信したかどうかは、トークンの価格に影響しません。フローは経験と持久力を向上させるだけです。それで、「ストリーミングにしたら安くなるでしょうか？」質問の答えはノーです。コストについては、5 番目と 6 番目のユニット (モデルの選択、キャッシュ) を見てください。
3 番目のポイントは、実際的なバランスを取ることです。ライブ アシスタントでは、最初の単語の迅速な到着 (知覚される遅延) が高く評価されます。したがって、モデルに答えを直接入力し、最初に (4 番目の単元のシステム プロンプトを介して) 短い結果を与えるように依頼すると、フローの利点が倍増します。最初の 1 秒で何か意味のあるものを見た場合、ユーザーはその後に続く詳細を辛抱強く待ちます。一方、フローはバックグラウンドで実行されるジョブには影響せず、その出力は次の自動化ステップに送られます。唯一の基準は、ジョブが正しく完全に完了することです。
要約すると
ストリーミングは応答を部分的に取得するため、知覚される遅延が軽減され、大規模なスループットでのタイムアウトが防止されます。ライブアシスタントや長いドキュメントの制作にはほぼ必須です。短時間/バックグラウンド作業の場合は不要です。長い作品では、プロンプトを使用して正面から構造と長さを強調すると、品質とトレーサビリティの両方が向上します。フローが終了すると、stop_reason と使用法が必ずチェックされます。
アプリケーションタスク
2 つのシナリオを選択します: 1 つはライブ/長期 (例: 顧客へのレポート)、もう 1 つは短期/バックグラウンド (例: タグ付け)。 (1) それぞれにフローを使用するかどうかを決定し、正当化します。 (2) 長いスクリプトの構造 (見出し + ターゲットの長さ) を強制するプロンプトを作成します。 (3) max_tokens の値を決定します。 (4) stop_reason で実行するチェックとフローの最後での使用法をリストします。
チェックリスト
- [ ] ストリーミングとは何か、そしてストリーミングによって知覚される遅延がどのように軽減されるかを説明できます。
- [ ] ストリーム結合とデルタ結合の基本的なイベント タイプを理解しました。
- [ ] 大きな max_tokens でストリーミングする必要性とタイムアウトの関係については理解しています。
- [ ] どのワークロードでストリーミングを使用し、どのワークロードで使用しないかを決定できます。
- [ ] ストリームの最後で stop_reason と使用状況を確認できます。