Семантичний кеш LLM: як скоротити витрати та затримки повторюваних запитів

Компанія, яка обробляє 8 000 запитів на місяць до асистента AI, може платити 800-1 600 zł за токени, з яких 40-55% припадає на запитання, що повторюються в майже ідентичній формі. Семантичний кеш усуває цю категорію витрат без зміни якості відповідей, якщо впровадити його з правильним TTL та порогом подібності.

Процес виглядає так. Запит користувача потрапляє до шару кешу перед моделлю. Система генерує його ембедінг (наприклад, BGE-M3, text-embedding-3-small) і порівнює з ембедінгами раніше збережених запитів у векторній базі. Якщо косинусна подібність перевищує налаштований поріг, повертається збережена відповідь. Нижче порогу запит надходить до моделі, а нова пара (запит, відповідь) потрапляє до кешу з призначеним TTL.

Три параметри керують поведінкою всього механізму:

Поріг подібності (threshold): значення 0,92-0,96 підходять для більшості впроваджень обслуговування клієнтів. Нижчий поріг збільшує hit-rate, але зростає ризик, що семантично близька пара отримає відповідь з іншого контексту. Вищий поріг безпечніший, але пропускає більше запитів до моделі.

TTL (Time to Live): визначає, як довго відповідь залишається дійсною. Години роботи магазину можуть мати TTL 24 год, але ціна продукту або статус замовлення вимагають TTL у межах 5-15 хвилин або інвалідації за подією після кожного оновлення в базовій системі.

Ключ контексту: у багатокористувацьких системах (SaaS, обслуговування кількох компаній) ключ кешу повинен містити ідентифікатор тенанта. Без цього компанія A може отримати відповідь, підібрану під дані компанії B.

Фізична архітектура проста: векторна база даних (наприклад, Qdrant, Redis з векторним модулем) зберігає пари ембедінг-відповідь, а модель ембедінгів працює локально або через швидке API. Затримка влучення в кеш зазвичай становить 10-30 мс проти 300-1500 мс для повної інференції.

Не кожен тип запитів підходить для кешування. Найвищий hit-rate отримуєш там, де запитання повторювані, а відповідь змінюється нечасто.

Обслуговування клієнтів — класичний випадок: «коли ви працюєте?», «як довго триває доставка?», «чи можу я повернути товар після 30 днів?» — це запитання, які протягом тижня з’являться десятки разів. Корпус FAQ з 50-100 запитань і відповідей з TTL 24 год дає hit-rate 50-65% при стабільному асортименті.

Технічна документація та внутрішня база знань — другий сильний випадок. Запитання розробників про конфігурацію, параметри API чи кроки встановлення мають повторюваний характер, а відповіді змінюються рідко (при новій версії ПЗ достатньо масового скидання кешу за тегом версії).

Асистент онбордингу для нових працівників — третій сценарій: сотні людей проходять через той самий набір запитань про процедури, системи та права доступу.

Коли кеш не допомагає або шкодить: запити, що потребують свіжих даних (біржові ціни, статуси замовлень у реальному часі), персоналізовані запити зі специфічними даними користувача та довгі діалогові розмови, де контекст сесії змінює значення кожного наступного повідомлення.

Хибно-позитивні влучення — найсерйозніший операційний ризик. При порозі 0,90 запит «чи є продукт X у синьому кольорі?» може потрапити на раніше збережену відповідь для «чи є продукт Y у червоному кольорі?», якщо структури речень семантично близькі. Рішення: відстежуй рівень хибно-позитивних влучень (FPR) на тестовому наборі та підвищуй поріг, коли FPR перевищує 1-2%.

Прострочені відповіді підривають довіру клієнтів сильніше, ніж повільний асистент. Компанія, яка змінила політику повернень з 14 на 30 днів, але не скинула кеш, протягом кількох годин надсилає некоректну інформацію. Механізм інвалідації за подією (webhook з CMS або CRM → DELETE кешу за тегом) тут важливіший, ніж сам TTL.

Різні відповіді на ті самі запитання можуть з’являтися, коли модель оновлюється, а кеш зберігає відповіді старої версії. Додай до ключа кешу ідентифікатор версії моделі або очищуй кеш після кожного оновлення.

Зростання операційної складності: кеш — це додатковий компонент, який може вийти з ладу (векторна база недоступна), вимагає моніторингу та займає пам’ять. Перш ніж впроваджувати, оціни, чи виправдовує hit-rate у твоєму випадку додаткове обслуговування, скориставшись калькулятором ROI.

Корисні метрики для моніторингу: hit-rate (ціль: > 35% для FAQ), FPR на тестовому наборі (ціль: < 2%), середня затримка кешу vs. моделі, відсоток відповідей, скинутих до закінчення TTL. Більше про моніторинг системи AI читай у статті про моніторинг якості агента AI.

Сам TTL вирішує проблему прострочення лише частково. На практиці потрібні три механізми, що працюють паралельно.

Інвалідація за подією: webhook або доменна подія з базової системи (CMS, ERP, CRM) надходить до шару керування кешем і видаляє записи, пов’язані з певним тегом (наприклад, product:P-123, policy:returns). Це єдиний ефективний метод для даних, що змінюються нерегулярно.

Інвалідація на основі версії: кожне оновлення моделі LLM або корпусу бази знань очищує кеш повністю або за сегментами. Ключі кешу містять хеш версії документа, тому після оновлення документа старі записи автоматично стають недійсними (не збігається хеш).

TTL як захисна сітка: мінімальний TTL 1 год навіть для «рідко змінюваних» даних захищає від ситуації, коли подія інвалідації не спрацювала (збій webhook, баг деплойменту).

Детальні патерни керування знаннями в RAG, включаючи версіонування та інкрементальну реіндексацію, описані в статті про оновлення знань RAG.

Мінімальний стек для семантичного кешу в обслуговуванні клієнтів: модель ембедінгів (BGE-M3 локально або API), Qdrant як векторна база з фільтрацією за метаданими (tenant, tag, версія), Redis для TTL та можливого запису тегів інвалідації, а також легкий оркестратор (n8n або власний код), що зв’язує шари.

Впровадження у три етапи: спочатку запусти в режимі shadow (записуй влучення та промахи, але завжди відповідай моделлю), щоб виміряти реальний hit-rate перед продакшеном. Другий крок — калібрування порогу: тестуй значення 0,90, 0,92, 0,94, 0,96 на валідаційному наборі з вручну оціненими парами. Третій крок — поступове ввімкнення кешу для категорій з найвищим hit-rate та найнижчим ризиком прострочення.

Детальні патерни оптимізації витрат на токени, включаючи prompt caching на рівні API моделі (доповнює семантичний кеш), знайдеш у статті про оптимізацію витрат на токени LLM. Семантичний кеш та класифікація і маршрутизація звернень AI добре працюють як спільний шар перед роутером моделей, що також описано в аналізі витрат на утримання агента AI.

Почни з 0,94 і тестуй на наборі з 50-100 пар з вручну оціненою релевантністю. Якщо рівень хибно-позитивних влучень перевищує 2%, підвищ до 0,96. Якщо hit-rate нижче 20% і в даних мало шуму, спробуй 0,92. Універсального значення для всіх сценаріїв немає.

З обмеженнями. Кешування всього контексту розмови непрактичне (низький hit-rate, великі ключі). Ефективніший підхід — кешувати лише перше запитання в сесії або фактичні запитання (FAQ-like), що виникають у межах розмови та не залежать від попередніх ходів.

Веди два лічильники: загальна кількість запитів до системи та кількість запитів, пропущених до моделі. Hit-rate = (запити з кешу / всі запити). Витрати без кешу = всі запити × середня вартість токенів. Витрати з кешем = пропущені до моделі × вартість токенів + фіксовані витрати на інфраструктуру кешу (ембедінги + векторна база). Різниця — це реальна економія, зіставлена з витратами на утримання додаткового компонента.

Відповіді, що потрапляють до кешу, не повинні містити персональних даних (імена, номери замовлень, адреси конкретних користувачів). Кеш підходить для узагальнених відповідей (політики, процедури, FAQ). Персоналізовані запити з даними користувача мають оминати кеш або кешуватися з ключем per user-id та TTL, що відповідає політиці зберігання. Проведи DPIA для кожного сценарію, де відповідь може опосередковано містити конфіденційні дані.

Ні. RAG шукає фрагменти документів як контекст для відповіді моделі. Семантичний кеш зберігає готові відповіді та повертає їх без участі моделі при схожих запитаннях. Обидві технології можуть працювати разом: RAG надає знання для першої відповіді, а кеш зберігає цю відповідь для наступних ідентичних запитів. У статті про семантичний пошук та ембедінги описано векторний шар, спільний для обох підходів.