Приборкання затримки ШІ за допомогою SSE
Я розробив функцію автодоповнення на базі ШІ. Користувачам вона не сподобалася.
Кожне натискання клавіші ініціювало запит до ШІ. Користувачі чекали від 2 до 3 секунд на повну JSON-відповідь. Інтерфейс здавався зламаним. Я пробував дебаунсинг та кешування. Нічого не допомагало. Основна проблема залишалася незмінною: користувачі нічого не бачили, поки не приходила вся відповідь повністю.
Я вирішив це за допомогою Server-Sent Events (SSE), щоб передавати відповіді потоком (streaming) частинами.
Старий процес виглядав так:
- Користувач друкує
- 300 мс дебаунсинг
- HTTP POST-запит
- ШІ обробляє (1-2 секунди)
- Сервер повертає повну відповідь
- Клієнт рендерить
Користувачі бачили порожній екран протягом кількох секунд. Навіть із індикатором завантаження це здавалося повільним.
Я розглядав опитування (polling) або WebSockets. Опитування створює занадто велике навантаження. WebSockets занадто важкі для одностороннього потоку.
Я обрав SSE, тому що:
- Він працює в один бік: від сервера до клієнта
- Він використовує прості текстові та JSON-фрагменти
- Він автоматично перепідключається, якщо з'єднання розривається
- Він не потребує додаткових бібліотек на вашому сервері
Результати змінили все:
- Час до першої візуальної відповіді: з 2,1 с до 0,3 с
- Залученість користувачів: зросла на 40%
- Скарги користувачів: нуль
Стрімінг — це про сприйняття. Прогресивний інтерфейс здається швидшим за статичний. Користувачі воліють бачити, як слова з'являються одне за одним, замість того, щоб чекати на цілий блок тексту.
Якщо ваші відповіді ШІ дуже короткі, використовуйте стандартні запити. Якщо вам потрібен двосторонній зв'язок, використовуйте WebSockets. Але для більшості завдань стрімінгу ШІ найкращим вибором є SSE.
Як ви боретеся із затримкою ШІ у своїх застосунках? Ви використовуєте стрімінг чи чекаєте на повні відповіді?