Зменшіть витрати на LLM на 73% за допомогою семантичного кешування

1

Витрати на велику мовну модель (LLM) для багатьох компаній стрімко зростають. Одна компанія виявила, що її рахунок за API збільшувався на 30% щомісяця не через трафік, а через те, що користувачі ставили те саме запитання різними способами. рішення? Семантичне кешування — це техніка, яка значно зменшує надлишкові виклики LLM, розуміючи значення, а не просто зіставляючи слова.

Проблема з кешуванням точної відповідності

Традиційне кешування базується на точному збігу запитів. Це працює, якщо користувачі формулюють свої запитання однаково, але більшість цього не робить. Аналіз 100 000 запитів на виробництво показав:

– Лише 18% були точними дублікатами.
– 47% були семантично схожі (однакове значення, різні формулювання).
– 35% були абсолютно новими.

Ці 47% представляють величезну можливість заощадити. Кожен злегка перефразований запит ініціював повний виклик LLM, генеруючи майже ідентичну відповідь. Кешування точної відповідності просто втратило цю економію.

Як працює семантичне кешування

Замість хешування тіла запиту семантичне кешування використовує векторні представлення (вбудовування). Це числові представлення значення. Система знаходить кешовані запити в межах порогу подібності:

Основна ідея полягає в тому, щоб вбудовувати запити у векторний простір і знаходити близькі збіги замість того, щоб покладатися на точний текст.

Проблема порогу: точність проти запам’ятовування

Поріг схожості є критичним. Занадто високий, і ви пропустите дійсні звернення до кешу. Занадто низький, і ви повернете неправильні відповіді. Поріг 0,85 може здатися розумним, але тестування виявило проблеми:

Наприклад, запит на скасування підписки може помилково збігатися з кешованою відповіддю на скасування замовлення.

Оптимальний поріг залежить від типу запиту:

  • Питання у стилі поширених запитань (0,94): потрібна висока точність, щоб уникнути порушення довіри.
  • Пошук товарів (0,88): Більший допуск до близьких збігів.
  • Підтримка клієнтів (0,92): Баланс між покриттям і точністю.
  • Транзакційні запити (0,97): Надзвичайно низька толерантність до помилок.

Затримка: чи варто це того?

Семантичне кешування додає затримку (вбудовування + векторний пошук). Заміри показали:

  • Вбудований запит: 12 мс (стор. 50) / 28 мс (стор. 99)
  • Векторний пошук: 8 мс (p50) / 19 мс (p99)
  • Загальний пошук кешу: 20 мс (p50) / 47 мс (p99)

Затримка незначна порівняно із середнім часом виклику LLM у 850 мс. З 67% звернень до кешу чистим результатом є 65% покращення затримки разом із економією коштів.

Анулювання кешу: збереження актуальності відповідей

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

  • TTL на основі часу: термін дії вмісту закінчується залежно від мінливості вмісту (наприклад, ціна оновлюється кожні 4 години).
  • Анулювання на основі події: Анулювання, коли базові дані змінюються (наприклад, коли оновлюється політика).
  • Виявлення застарілості: періодично перевіряє, чи кешована відповідь є актуальною, повторно виконуючи запит і порівнюючи векторні представлення.

Операційні результати: реальний вплив

Через три місяці результати були значними:

  • Швидкість звернень до кешу: збільшено з 18% до 67%.
  • Витрати API LLM: Зменшено на 73% (з $47 000 на місяць до $12 700 на місяць).
  • Середня затримка: покращено на 65% ​​(з 850 мс до 300 мс).
  • Рівень помилкових позитивних результатів: залишається низьким на рівні 0,8%.

Ця оптимізація забезпечила найбільшу віддачу від інвестицій для виробництва систем LLM. Ретельне налаштування порогів має вирішальне значення для запобігання погіршенню якості.

Семантичне кешування — це не рішення «встановити й забути». Потрібні постійний моніторинг і коригування.

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