ストリーミング応答：なぜ、どのようにUXを改善するのか

チャット形式のAIツールを使う人を眺めていると、まるでモデルがタイプしているかのように、テキストが一語ずつ現れることに気づくでしょう。それがストリーミングであり、あらゆるLLM製品において最も影響の大きいUXの判断の一つです。注目すべきは、ストリーミングがモデルを少しも速くしないという点です——完全な答えを生成するのにかかる総時間は変わりません。変わるのは待ち時間がどう感じられるかであり、インタラクティブなソフトウェアでは、その知覚が生の数字以上に重要なことがしばしばあります。本稿では、ストリーミングがなぜ役立つのか、どのように動くのか、そして構築の本当のコストを取り上げます。

ストリーミングが解決する問題

言語モデルはテキストを一度に1トークンずつ、順番に生成します。長い答えは生成に実際に時間がかかり、それを回避する方法はありません——各トークンはその前のトークンに依存するからです。これは答えが長くなった瞬間にUXの問題を生みます。

ストリーミングがない場合、ユーザーはリクエストを送信し、答え全体が用意できるまで空白やスピナーを見つめ、それから一気に表示されます。長い応答では、何かが起きている気配のないまま、居心地の悪いほど長い沈黙になり得ます。答えが長いほど待ち時間は悪化し、アプリケーションがフリーズしたように感じられます。ストリーミングはまさにここを突きます。答えが完成するまで出し惜しみする代わりに、モデルが生成した各断片をその都度届けるのです。

なぜ体感速度が実際の速度に勝るのか

総生成時間は、ストリーミングしてもしなくても同一です。ストリーミングが変えるのは最初のトークンまでの時間——ユーザーが何かが起きるのを目にするまでの時間——であり、この一つの指標が体感の大部分を左右します。

これはインターフェース設計においてよく理解された原則です。人は進捗が進んでいるというフィードバックがあるとき、待つことにずっと耐えられます。ほぼ即座に現れ始め、数秒かけてスクロールしていく応答は、たとえ非ストリーミング版と同じ瞬間に完了するとしても、応答性が高く生き生きとして感じられます。同じ内容が同じ総時間の後に一つの沈黙した塊として届けられると、遅く不確かに感じられます。ストリーミングは本質的に、長く不透明な待ち時間を、短い待ち時間とそれに続く目に見える進捗へと変換する手段であり、インタラクティブな製品においてその変換には大きな価値があります。

ストリーミングの仕組み、概念的に

通常、モデルへのリクエストは生成が完了したときに一つの完全な応答を返します。一方ストリーミングリクエストは、接続を開いたままにし、生成されるにつれて一連の増分更新——答えの断片——を送り続け、最後に応答が完了したことを示すシグナルが届きます。

モデルプロバイダーはこれをAPIのストリーミングモードとして公開しており、OpenAIやAnthropicといったプロバイダーのドキュメントが、正確な仕組みと断片の形を説明しています。あなたの側では、アプリケーションが届く断片を読み取り、ユーザーに見えているものへ一つずつ追記していき、おなじみのタイプライター効果を生み出します。メンタルモデルは単純です。「尋ねて、待って、すべてを受け取る」のではなく、「尋ねて、それから断片のストリームを受け取り、届くにつれて表示する」になります。ストリーミングについての難しさはすべて、その一つの変化から流れ出ます——あなたは今や、一度にではなく時間をかけて到着する応答を扱っているのです。非ストリーミングの呼び出しは、手にしているかいないかのどちらかである単一の不可分なイベントです。ストリーミングの呼び出しは、最初から最後まで管理しなければならない、進行中の小さなプロセスです。イベントからプロセスへのその転換は、紙の上では微妙でも、実践では重大です。なぜなら、それはあなたのクライアント、サーバー、そしてその間のあらゆる層に触れるからです。

ストリーミングの構築コスト

ストリーミングはタダではなく、そうであるふりをすると中途半端な実装に行き着きます。それはスタック全体に複雑さを押し込みます。

• エンドツーエンドの配管。 ストリームはあらゆるホップを生き延びなければなりません。クライアントとモデルの間にサーバーがあるなら、応答全体をバッファリングして目的を台無しにするのではなく、届いた断片をその都度転送しなければなりません。すべての層がストリームを意識する必要があります。
• より難しいエラー処理。 ストリームの途中での失敗は、応答が始まる前の失敗よりも厄介です。何かが壊れたとき、ユーザーはすでに答えの半分を見てしまっているかもしれず、部分的な結果をどう優雅に扱うかを決めなければなりません。
• 部分的な出力のパース。 構造化された出力が必要なら、それは断片で届きます。十分に届くまで構造をパースできないため、ストリーミング中の応答に対して動作するあらゆるロジックが複雑になります。
• クライアント側での蓄積。 インターフェースは届く断片を滑らかに追記し、スクロールを管理し、ユーザーが途中で離脱したりキャンセルしたりする場合にも対応しなければなりません。

これらはどれも法外なものではありませんが、本物の作業であり、ストリーミングがすべてのエンドポイントのデフォルトではなく、意図的な選択である理由です。

ストリーミングが価値あるとき、そうでないとき

ストリーミングは、インタラクティブで人間に向き合う文脈でその複雑さに見合います。人が出力が現れるのを見ているなら、とくに長めの答えにおいては、体感速度の恩恵は大きく、たいてい決定的です。チャットインターフェース、ライティングアシスタント、そしてあらゆる会話的な接面が自然な適合先です。

いくつかのよくある状況では、これは間違った選択です。出力を消費するのが人間ではなく機械の場合——バックエンドのジョブ、データパイプライン、別のサービス——トークンが現れるのを見ている者は誰もいないため、ストリーミングは何の恩恵もなく複雑さを加えるだけです。その消費者はいずれにせよ完全な結果を欲しがります。行動を起こす前に構造化された応答全体が必要な場合、いずれにせよ最後まで待たねばならないため、ストリーミングは何ももたらしません。そして応答がほぼ瞬時に届くほど短い場合、待ち時間は感じるに値しないほど短く、ストリーミングは無用な仕掛けです。正直な原則はこうです。人間が些末でない答えの到着を見ているときはストリーミングし、それ以外ではやめておく。恩恵は、答えがどれだけ長いか、そして人がどれだけ直接それを待っているかに比例します——だからインタラクティブで冗長なユースケースほど、ストリーミングを採る根拠は強くなります。

ストリーミングとシステムの他の部分

ストリーミングは、LLMアプリケーションの他の部分と、あらかじめ見越しておくべき形で相互作用します。可観測性はそれを織り込まなければなりません。最初のトークンまでの時間は、総完了時間とは別個の、それ自体が一つの指標になります。なぜなら、それこそユーザーが実際に感じるものだからです。キャッシュはストリーミングとぎこちなく組み合わさります——キャッシュされた答えはすでに完成しているため、ストリームを再シミュレートするのではなく即座に返すことを選ぶかもしれず、これは意図的なUXの判断です。そして完全な応答を後処理あるいは検証するものは、その仕事をする前にストリームの完了を待たねばならず、つまり一部のロジックは「ストリーミングしながら」走らせることが端的にできません。こうした相互作用をあらかじめ知っておくことが、ストリーミングが周囲の機能を静かに壊すのを防ぎます。

まとめ

ストリーミングはモデルを速くするのではありません。長い沈黙を即座の目に見える進捗へと変えることで、待ち時間を短く感じさせます。そのトレードオフ——総時間は変わらず、体感応答性は劇的に改善する——は、人間が些末でない答えの到着を見るインタラクティブな製品では決定的であり、機械が出力を消費する場合や応答が極小の場合は無意味です。コストは本物の複雑さで、ストリームを意識したサーバーから、より難しいエラー処理、部分的なパースまで、スタック全体に織り込まれます。誰かが言葉の到着を見ているときにはストリーミングへ手を伸ばし、どの層もストリームをバッファで握りつぶさないようエンドツーエンドで構築し、それ以外の場所では気持ちよく省きましょう。