Що ламається без кешування LLM-відповідей при зростанні навантаження
Поки навантаження невелике, повтори непомітні: ніхто не рахує, скільки звернень двічі йде в модель. На реальному трафіку частка повторюваних запитів сягає половини — привітання, типові формулювання, те саме питання про статус заявки різними словами.
Кожен такий запит заново проходить весь шлях: складання промпта, звернення до моделі, генерацію. Найбільш ресурсомістка частина конвеєра витрачається на відповідь, яку вже було отримано хвилину тому і яка лежить без діла.
Далі зростає час відповіді моделі, і причина не в самій моделі, а в черзі. Одночасних звернень більше, ніж доступних слотів обробки, тому запити чекають, а не обробляються. Хвіст затримок подовжується в усіх — включно з тими, хто прийшов з унікальним питанням.
На піках вмикається другий ефект — перевантаження під піками. Черга зростає швидше за пропускну здатність, і на верхній межі з'являються таймаути при піковому навантаженні.
Користувач бачить помилку й надсилає запит повторно, додаючи сервісу роботи: відмова починає підсилювати сама себе.
Кешування LLM-відповідей знімає саме цю механіку: повторюваний запит отримує готову відповідь, не доходячи до моделі. Нижче розбираємо, як це закривається — від точного збігу до семантичного.
Що дає кешування LLM: швидкість відповіді та навантаження на модель
Кеш працює на двох рівнях: точний збіг нормалізованого запиту та семантична близькість векторів. Перший рівень ловить дослівні повтори — типові питання в підтримці, шаблонні запити до документації, повторні виклики з одного сценарію.
Другий порівнює ембеддинги й віддає відповідь при близькості вище заданого порогу, тому перефразування («як оформити повернення» та «повернення товару — як зробити») потрапляють в один запис.
Частка влучань у корпоративних асистентах зазвичай тримається в діапазоні 30–60% і залежить від різноманіття формулювань і довжини системного промпта.
Саме ця частка визначає скорочення часу відповіді: влучання віддається зі сховища за десятки мілісекунд, тоді як генерація займає секунди. Користувач бачить різницю не в середньому часі, а в хвості — важкі запити перестають бути нормою.
Кількість звернень до моделі падає пропорційно до частки влучань.
Вивільнена потужність стає резервом потужності: асистент витримує зростання кількості користувачів без розширення контуру, а піки — ранковий наплив, масову розсилку, старт кампанії — проходить без відмов за лімітом запитів. Цей клас відмов зникає повністю, а не маскується повторами на клієнті.
Поріг близькості підбирається замірами, а не на око: занадто низький дає хибні влучання та відповіді не на питання, занадто високий обнуляє виграш.
Галузеві заміри, зокрема Anthropic щодо повторного використання промптів, показують кратне скорочення затримки на повторних зверненнях — за умови, що частка влучань і точність відповідей вимірюються постійно, а не один раз на запуску.
Два режими зіставлення запитів: точний і за змістом
Перш ніж вмикати кеш, потрібно вирішити, за якою ознакою два запити вважаються однаковими. Точний збіг порівнює нормалізовані рядки, пошук за змістом — близькість векторних представлень.
Від цього вибору залежить і частка влучань, і ризик віддати користувачеві відповідь на чуже питання.
Нормалізація запиту — спільний шар для обох режимів: регістр, зайві пробіли, службові поля, порядок параметрів. Без неї точний збіг втрачає влучання на порожньому місці: «Скільки коштує доставка?» і «скільки коштує доставка» йдуть у модель двічі.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Точний збіг | Шаблонні повтори: форми, автодоповнення, повторний виклик із тими самими параметрами | Не ловить перефразування й друкарські помилки, потребує нормалізації |
| Пошук за змістом | Вільні питання, де важлива суть, а не формулювання | Поріг близькості: занижений дає хибні влучання |
| Гібрид за рівнями | Різнорідний трафік: спочатку точний рівень, потім смисловий | Складніше налагодження та вибіркове скидання кешу при зміні моделі |
На практиці частіше працює гібридна схема зіставлення за рівнями: перший рівень точний — швидкий і безпомилковий, другий смисловий — ловить перефразування.
Поріг близькості підбирають на розміченій вибірці реальних діалогів: завищений знижує частку влучань, занижений збільшує клас хибних спрацьовувань.
Окреме обмеження смислового рівня — скидання: при оновленні моделі старі вектори перестають відповідати відповідям, записи інвалідують вибірково, а не повністю.
Порядок впровадження: від профілю запитів до передачі в підтримку
Порядок робіт фіксований: спочатку вимірюємо, що реально йде в модель, і лише потім вмикаємо кеш. Якщо почати з налаштування, ключ запиту збирається за здогадками — з'являються хибні влучання, і користувач отримує відповідь на чуже питання. Тому етапи йдуть послідовно, з точкою неповернення після перевірки на тіньовому трафіку.
- Аудит потоку запитів. Знімаємо вивантаження звернень за 2-4 тижні: частка повторів, розкид формулювань одного й того самого питання, довжина контексту, набір параметрів генерації, частка запитів з персональними даними. На виході — карта сценаріїв із потенціалом кешування.
- Схема ключів запиту. Визначаємо, що входить у ключ точного збігу (нормалізований текст, системна інструкція, параметри генерації, ідентифікатор версії моделі) і що вважаємо близькістю для семантичного шару. Окремо позначаємо сценарії, які не кешуються взагалі.
- Політики зберігання. Задаємо термін життя записів за типами сценаріїв, правила інвалідації при зміні промпта або моделі, обсяг індексу та ліміти на зберігання.
- Налаштування шару кешу. Ставимо його перед моделлю, піднімаємо індекс близькості, налаштовуємо прогрів на історичних запитах і логування влучань.
- Перевірка на тіньовому трафіку. Бойовий потік іде як зазвичай, а рішення кешу рахуються паралельно, без впливу на відповідь. Дивимося частку влучань, розбіжності відповідей і поведінку на рідкісних формулюваннях.
- Заміри після вмикання. Порівнюємо з базовою лінією: частка запитів, що дійшли до моделі, час відповіді, навантаження на генерацію, частка відповідей з ознаками деградації якості.
- Передача в підтримку. Регламент інвалідації, дашборд з метриками, пороги оповіщень і порядок швидкого вимкнення шару — щоб експлуатація не залежала від авторів рішення.
Артефакти впровадження: конфігурації, схеми, політики, регламенти
Впровадження закінчується не фактом увімкнення кешу, а передачею пакета артефактів, за яким служба експлуатації може вести рішення без автора. Нижче — склад цього пакета; кожен пункт закриває конкретний клас відмов, а не «для галочки».
- Конфігурації сервісу — робочі файли з порогом семантичного збігу, терміном життя запису за класами запитів, лімітами розміру сховища та правилами розділення просторів ключів. Кожне значення має коментар: діапазон, у якому його можна змінювати, і що деградує при виході за межі.
- Схема потоку запиту — від нормалізації вхідного тексту через пошук точного збігу та векторний пошук до звернення до моделі й запису відповіді. На схемі позначено точки логування та місце, де відповідь позначається як отримана з кешу.
- Політики винятків і приватності — перелік запитів, які не кешуються взагалі: з персональними даними, з контекстом поточної сесії, з обліковими даними клієнта. Плюс правила ізоляції ключів за орендарем, щоб відповідь одного користувача не спливла в іншого.
- Правила інвалідації — автоматичне скидання при зміні версії моделі або системного запиту, ручне очищення за тегом і за простором ключів, аварійне вимкнення кешу одним перемикачем. Описано, що відбувається з уже відданими відповідями.
- Панель метрик — частка влучань, частка хибних семантичних збігів, час відповіді, кількість звернень до моделі. За цими показниками видно, де поріг підібрано занадто м'яко.
- Документація для чергової зміни — покрокові інструкції на типові ситуації: зростання хибних збігів, переповнення сховища, недоступність векторного індексу. Для кожної — ознака, дія, порядок відкату до режиму без кешу.
- Регламент перевірки — набір регресійних запитів з еталонними відповідями та порядок прогону перед зміною конфігурації, а також доступи й ролі для команди замовника.
Пакет передаємо з розбором на дзвінку та короткою сесією для чергової зміни — щоб через місяць рішення можна було змінювати без нас.
Кейс: як за місяць знизили затримку та навантаження на модель
До: потік запитів без кешу
У замовника — діалоговий помічник першої лінії підтримки. Звернення масово повторюються, але кожен запит усе одно йшов у модель: середній час відповіді тримався близько 3,4 с, на піках сягав 9 с.
У години навантаження частина звернень обривалася через ліміт у постачальника моделі, і користувачі йшли у форму тікета замість відповіді в діалозі.
Після: два рівні кешу
Поставили два рівні. Точний порівнює нормалізований запит разом із версією промпта та параметрами генерації — збіг віддається відразу, сховище на Redis з обмеженим терміном життя запису, тому воно не зростає безконтрольно.
Семантичний шукає близькі за змістом формулювання у векторному індексі й відповідає лише вище порогу збігу, усе інше йде в модель.
На зіставному профілі частка влучань вийшла 41%, з них 27% — семантичні. Середній час відповіді впав з 3,4 до 0,6 с, верхній перцентиль — з 9 до 1,4 с, кількість звернень до моделі скоротилася на 43%.
Клас відмов «ліміт у постачальника на піку» зник: навантаження на модель більше не зростає від повторів.
Заміри знімали на одному й тому самому наборі запитів — два тижні до впровадження і два тижні після, з розбивкою за категоріями звернень і окремо за прогрівом у перші хвилини після перезапуску. Інвалідація за версією промпта не дала роз'їхатися відповідям після правок інструкції.
Повний розбір замірів — нижче: профіль запитів, частка влучань і розподіл затримок за кожною категорією.
Що робити при хибних влучаннях у вже працюючій системі
Хибне влучання майже ніколи не означає, що зіставлення налаштовано неправильно. У працюючій системі це зазвичай означає, що поріг близькості задано один на всі типи запитів, а рішення ніде не записуються: збій видно, причина — ні.
Перший крок — не крутити поріг, а логувати кожне влучання: вихідний запит, знайденого «сусіда», значення близькості та ознаку, чи прийняли відповідь.
Поріг близькості майже завжди потрібно розводити за групами. Короткі та загальні питання дають високу близькість із чим завгодно, тому для них поріг піднімають, а для довгих запитів з конкретикою залишають нижчим. Єдина цифра на всю систему — компроміс, який одночасно і пропускає сміття, і ріже корисні збіги.
Далі — розбір спірних пар: відбираємо ті, де близькість потрапила в пограничну зону, і дивимося їх вручну.
Кілька десятків переглянутих пар зазвичай показують, що частина влучань викликана не порогом, а службовим шумом у векторі — привітанням, підписом, технічним хвостом листування, який і тягне запит до чужої теми.
Точкові винятки працюють точніше, ніж підняття порогу для всіх підряд. У список винятків ідуть запити з числами, датами, назвами та запереченнями: там близькість обманює найчастіше, а підстановка чужої відповіді коштує дорожче, ніж зайвий виклик моделі.
Контроль якості відповідей замикає контур. Потрібен набір еталонних пар, який запускається при кожній правці порогу або правил, і метрика частки нерелевантних влучань у живому потоці. Якщо після зміни метрика не покращилася — зміну відкочують.
Часті технічні питання: інвалідація, приватність, заміри
Кеш відповідей ламається не на записі, а на супроводі: записи переживають зміну моделі, ключі клієнтів перетинаються, а ефект міряють за середнім часом відповіді.
Який термін життя ставити запису?
Задаємо двома шарами: закінчення за часом і поріг за кількістю звернень. Довідкові відповіді живуть довше, фактичні — коротше, тому термін прив'язаний до типу запиту, а не заданий одним числом для всього кешу.
Як розділяються дані різних клієнтів і орендарів?
Ключ будується як «орендар → клієнт → версія моделі → запит»: однакові питання різних клієнтів дають різні записи, перетин виключено. Сховище (наприклад, Redis) тримаємо роздільними наборами з окремими політиками витіснення.
Що відбувається при зміні версії моделі?
Версія моделі входить у ключ: нова версія не читає старий кеш, а пише свій, попередні записи доживають термін паралельно і не заважають. Відкат на попередню версію повертає її кеш повністю.
Як чесно заміряти ефект?
Рахуємо частку звернень, закритих з кешу, і час до першого токена за промахами. Замір іде на живому трафіку з тіньовою гілкою: частина запитів завжди йде в модель напряму, і різниця між гілками показує реальний виграш.
Обговоримо задачу: звіримо вимоги та повернемося з планом
Щоб оцінка кешування спиралася на ваші дані, а не на середні числа, до обговорення достатньо додати кілька вступних. Вони не потребують підготовки окремого документа — вистачить вивантаження метрик, схеми потоків і опису того, де зараз вузьке місце. Розберемо, як це влаштовано у вас, і повернемося з планом робіт.
- Вихідні дані щодо навантаження: скільки звернень на добу, як виглядає піковий профіль, яка частка формулювань повторюється дослівно, а яка — перефразовується.
- Де саме втрачається час і вартість: затримка відповіді, частка запитів до моделі, обсяг переплат за повторні генерації.
- Вимоги до свіжості: через скільки після оновлення джерела відповідь зобов'язана перестати віддаватися з кешу, чи є запити, які кешувати не можна в принципі.
- Інфраструктура та обмеження: де живуть сервіси, які вимоги до ізоляції даних, чи є правила зберігання персональних даних і аудиту доступу.
- Пріоритети за термінами: що має запрацювати першим, що можна відкласти на другий етап, до якої дати потрібен результат.
- Хто з боку замовника ухвалює рішення щодо спірних місць — наприклад, щодо порогу семантичної схожості та правил інвалідації.
На виході ви отримуєте формат пропозиції, за яким можна порівнювати підрядників: схему кешу з розбивкою на точний і семантичний рівні, етапи робіт з оцінкою витрат праці, набір метрик для приймання (частка влучань, затримка відповіді, частка коректних віддач після інвалідації) та перелік ризиків із планом відкату. Опишіть задачу в зручному вигляді — повернемося з оцінкою та планом робіт протягом робочого дня.
