AI / LLM
Streaming: повторение на припоминание
Припоминание сильнее перечитывания. Для каждого промпта проговори или запиши полный ответ по памяти, прежде чем открыть модельный, — именно усилие припоминания закрепляет ментальную модель streaming.
Восстанови основные механизмы юнита — модель латентности TTFT, жизненный цикл SSE, накопление delta, контракт частичного JSON для tool, стратегию reconnect и отказ из-за буферизации — не заглядывая обратно в урок.
- 01Почему streaming улучшает UX, не сокращая общее время генерации? Назови две метрики латентности, на которых он играет.
- 02Пройди жизненный цикл событий SSE для одного streamed-сообщения и скажи, что делаешь на каждом этапе.
- 03Почему аргументы tool-вызова нужно накапливать до парсинга и какой прод-баг возникает, когда промежуточный слой портит эти delta?
- 04Stream рвётся на 200-м токене из 400. Сравни полный resume через Last-Event-ID и прагматичный дефолт и скажи, что бы ты выкатил.
- 05Опиши прод-отказ №1 для streaming, его сигнатуру и конкретные фиксы.
- 06Почему reasoning-модель с chain-of-thought может заставить streaming-UI выглядеть зависшим и как это обработать?
Если ты смог восстановить каждый ответ по памяти, ты держишь хребет юнита: streaming меняет общее время на TTFT и читается по TPOT; SSE доставляет типизированный жизненный цикл, который ты накапливаешь в снапшот; text-delta рендерятся сразу, а фрагменты input_json_delta для tool парсятся только на content_block_stop, и пустые аргументы означают, что delta съел промежуточный слой; оборванные stream по умолчанию — повторяемые retry всего хода; TTFT reasoning-модели нужен UX-прогресс, а не фикс транспорта; а прод-убийца №1 — буферизующий прокси, превращающий TTFT обратно в общее время, чинится в конфиге пути, а не в приложении.