Семантический кэш в диалогах: как измерить пользу и риск

Почему одной доли попаданий мало

Высокая доля попаданий хорошо выглядит в отчете, но для диалога этого мало. Один и тот же вопрос меняет смысл уже через пару реплик. Фраза "сделай короче" в начале сессии может относиться к письму, а через десять минут - к SQL-запросу, описанию тарифа или ответу клиенту.

Поэтому семантический кэш в диалогах нельзя оценивать по простому правилу: "нашли похожее - значит все хорошо". Похожий текст не всегда означает тот же смысл. Система может сэкономить токены, но при этом сломать ход беседы.

На длинных сессиях такая ошибка стоит дороже, чем кажется. Пользователь получает уверенный, но чужой по смыслу ответ. Потом тратит еще 2-3 реплики на исправление, модель получает лишний контекст, а команда теряет не только деньги, но и доверие к самой идее кэширования.

Это хорошо видно в поддержке или во внутреннем помощнике. Клиент сначала пишет: "покажи статус заявки", потом уточняет номер, а затем просит: "теперь коротко объясни причину". Если кэш возьмет старый похожий запрос и не учтет новое состояние диалога, ответ будет формально похожим, но по сути неверным.

Смотреть нужно сразу на несколько метрик: долю попаданий по всем запросам, долю ложных срабатываний, экономию токенов и денег, а также изменение задержки на длинной сессии. Эти цифры важны только вместе. Допустим, команда получила 42% попаданий и сэкономила 18% токенов. Звучит неплохо. Но если ложные срабатывания выросли до 6%, итог может оказаться плохим: операторы чаще перепроверяют ответы, а пользователи чаще переспрашивают.

Если трафик идет через единый OpenAI-совместимый шлюз вроде AI Router, сравнение обычно проще. В одном месте видны стоимость, задержка и цепочка реплик. Но сама логика шире любого инструмента. Доля попаданий показывает активность кэша, а не его пользу. Пользу видно только вместе с ошибками и ценой.

Что считать хорошим результатом

Хороший семантический кэш не обязан давать самый высокий процент попаданий. Намного важнее другое: он не должен подсовывать ответ, который похож по форме, но не подходит по смыслу. Один такой промах в длинном чате часто обходится дороже, чем десятки удачных попаданий.

Сначала задайте жесткий предел ложных срабатываний. Для чата с низким риском можно начать с уровня до 1%. Для банка, телекома, медицины или внутреннего помощника, который работает с персональными данными, планка обычно ниже. В таких сценариях лучше потерять часть попаданий, чем выдать неверный ответ в важный момент.

Потом выберите цель по экономии на одну сессию, а не на один запрос. В коротком диалоге на 2-3 реплики даже заметный hit rate может почти ничего не дать по деньгам. В длинной сессии на 20-30 ходов тот же кэш уже срезает тысячи токенов и убирает часть задержки.

Полезно смотреть не только на проценты, но и на деньги в расчете на 1000 сессий. Так проще сравнивать эффект между моделями и понимать, где кэш реально окупается, а где просто красиво выглядит в отчете.

Стартовые пороги

До эксперимента лучше зафиксировать простые ориентиры. Ложные срабатывания не должны выходить за порог, который подходит вашему сценарию. Экономия на длинной сессии должна быть заметной - хотя бы 8-12% по токенам или стоимости. Снижение задержки должно быть таким, чтобы пользователь его чувствовал без секундомера. И почти всегда нужны отдельные цели для коротких и длинных диалогов.

Короткие и длинные сессии ведут себя по-разному. В коротких чатах любой неверный ответ заметнее, потому что у системы почти нет шанса исправиться. В длинных сессиях цена ошибки тоже высока, но там чаще встречаются повторы, уточнения, сводки и запросы статуса, где кэш может приносить больше пользы.

Еще до запуска решите, что для продукта важнее: цена, скорость или точность. Для саппорта точность обычно важнее экономии. Для внутреннего рабочего чата на дорогой модели иногда можно принять небольшое падение качества ради ощутимого снижения расходов.

Нормальный результат выглядит так: ложных срабатываний мало, длинные сессии дешевеют, ответы приходят быстрее, а команда не получает поток жалоб на странные повторы. Если растет только доля попаданий, это еще не успех.

Как собрать честную выборку диалогов

Для замера берите не красивый набор тестовых промптов, а живые сессии за последние 2-4 недели. Только так видно, как люди пишут на самом деле: с повторами, обрывками фраз, сменой темы и длинными уточнениями. Тестовые чаты почти всегда завышают пользу кэша.

Сначала почистите сырой массив. Уберите пустые диалоги, спам, технические пинги, массовые дубликаты и сессии, где пользователь сразу ушел. Иначе попадания кэша будут выглядеть лучше, чем в реальном потоке.

После очистки не сводите каждый чат к одному тексту. Сохраните признаки, без которых вы не поймете, где кэш помогает, а где вредит: длину сессии в сообщениях, тему или тип задачи, модель, число входных и выходных токенов, время между сообщениями.

Это нужно не для красоты в таблице. Длинный диалог поддержки и короткий внутренний вопрос сотрудника дают разный шанс на повтор смысла. Если команда работает через единый шлюз, полезно фиксировать еще и модель или провайдера на каждом шаге. Один и тот же запрос может давать разную пользу кэша на разных моделях.

Дальше разделите выборку по сценариям. Обычно хватает четырех корзин: поддержка, продажи, поиск по базе знаний и внутренний рабочий чат. Не смешивайте их в одну среднюю цифру. Кэш может отлично работать в поддержке, где люди часто задают похожие вопросы, и почти не работать в исследовательских диалогах, где контекст быстро меняется.

Важно держать баланс по длине сессий. Если в наборе 80% коротких чатов на 2-3 сообщения, вы почти ничего не узнаете про длинные сессии, где экономия токенов обычно заметнее, а риск ложного попадания выше. Лучше заранее выделить короткие, средние и длинные цепочки и проверить, что каждая группа достаточно большая.

И еще одно правило: не тратьте весь массив на настройку. Отложите отдельный набор для финальной проверки и не трогайте его, пока не выберете пороги сходства и правила кэша. Иначе вы подгоните метрики под знакомые диалоги и получите слишком оптимистичный результат.

Как пометить удачные и плохие срабатывания

Оценка кэша ломается в тот момент, когда команда смотрит только на сам факт попадания. Одно и то же попадание может дать идеальный ответ, терпимый ответ или промах, который тихо портит диалог.

На каждом шаге сохраняйте две версии ответа: из кэша и без кэша, если бы запрос ушел в модель заново. Сравнивать нужно на одном и том же шаге, с той же историей, теми же параметрами и тем же ожидаемым форматом. Иначе вы измеряете не кэш, а шум.

Удобно использовать три метки:

• Точное попадание. Ответ из кэша совпадает по смыслу и по действию. Пользователь не заметит разницы.
• Полезное приближение. Формулировка отличается, но ответ все еще верный и помогает продолжить диалог без риска.
• Опасная ошибка. Кэш вернул ответ, который уже не подходит: пропустил новый факт, перепутал условие, дал старую сумму, старый статус или старую рекомендацию.

Самая частая проблема в длинных сессиях проста: в последних репликах появился новый факт, а кэш его не учел. Пользователь сначала спрашивает про доставку в Алматы, потом уточняет, что заказ срочный и нужен самовывоз сегодня. Если кэш достает старый ответ про обычную доставку, формально сходство высокое, но по делу это ошибка.

Поэтому при разметке отдельно проверяйте свежие детали из последних 1-3 реплик. Если ответ из кэша потерял хотя бы один факт, который меняет смысл или следующее действие, ставьте не "полезное приближение", а "опасную ошибку".

Спорные случаи лучше не отдавать одному человеку. Дайте их двум рецензентам с простым правилом: может ли пользователь безопасно опереться на этот ответ прямо сейчас. Если мнения разошлись, смотрите на реальный риск, а не на красоту формулировки.

Полезно записывать и причину промаха. Обычно вариантов немного: старый контекст, когда кэш взял ответ для ранней стадии диалога; неверное сходство, когда похожие фразы скрыли разный смысл; слишком низкий порог, когда система пустила в кэш слишком далекие запросы.

Такая разметка быстро показывает, где кэш действительно экономит токены, а где создает тихие ошибки. Если логи и метки лежат рядом, потом легко разбирать результат по моделям, сценариям и длине сессии.

Как посчитать деньги, токены и задержку

Смысл замера виден не по средней цифре за день, а по каждой реплике в длинной сессии. Один удачный hit в начале чата может сэкономить копейки, а такой же hit на 18-м сообщении часто убирает большой кусок контекста и дает заметную разницу по цене и времени ответа.

Для каждого ответа держите две цифры: сколько стоил бы обычный вызов модели и сколько реально стоил ответ через кэш. Во вторую сумму включайте не только почти бесплатную выдачу из кэша, но и цену поиска по эмбеддингам, запись новых элементов и хранение. Иначе семантический кэш в диалогах выглядит дешевле, чем есть на самом деле.

Удобно собирать одну карточку на каждый ход:

• цена без кэша: входные токены и выходные токены модели;
• цена с кэшем: поиск похожего запроса, эмбеддинг, чтение или запись в кэш;
• чистая экономия: цена без кэша минус цена с кэшем;
• задержка: время до первого токена и время до полного ответа.

Потом соберите эти карточки в цену одной длинной сессии. Например, в чате на 25 ходов кэш дал 9 срабатываний. На бумаге это выглядит хорошо, но деньги покажут более честную картину: 6 попаданий сэкономили много токенов на длинных запросах, 3 почти ничего не дали, а 1 ложное срабатывание добавило еще два уточняющих сообщения.

Ошибки считайте так же строго, как экономию. Если кэш вернул старый или неточный ответ, запишите цену повтора, цену дополнительных токенов на исправление, возможную эскалацию к оператору и риск потери пользователя. В поддержке банка или телеком-сервиса один плохой ответ может стоить больше, чем десятки удачных попаданий экономят за день.

С задержкой часто ошибаются из-за нечестного стенда. Сравнивайте кэш и обычный путь на одной и той же нагрузке, с одной и той же моделью, одинаковым размером контекста и похожей долей длинных сессий. Если трафик идет через AI Router или другой шлюз, зафиксируйте провайдера и маршрут, чтобы разница не смешалась с разницей между моделями.

Хорошая финальная метрика простая: сколько стоит одна длинная сессия без кэша, сколько с кэшем, сколько секунд ждет пользователь и сколько денег теряется на ложных срабатываниях. После этого уже видно, помогает кэш или просто красиво выглядит в отчете.

Как провести замер по шагам

Сначала зафиксируйте набор диалогов и не меняйте его до конца теста. Иначе вы будете сравнивать не настройки, а разные данные. Для первого прохода отключите семантический кэш полностью и снимите базовую линию: токены на каждом ходе, задержку ответа, длину истории, тип запроса и итоговую стоимость.

Не смотрите только на сессию целиком. Полезные различия обычно видны по каждому ходу. На 3-м сообщении кэш может почти не помогать, а на 18-м уже заметно снижать цену, потому что история длиннее и повторов больше.

Последовательность прогона

• Прогоните тот же набор сессий без кэша и сохраните логи по каждому ходу.
• Повторите прогон с несколькими порогами сходства, например 0.82, 0.86 и 0.90.
• Для каждого порога меняйте и окно истории: последние 4, 8 или 12 сообщений.
• На каждом ходе запишите hit или miss, score сходства, сэкономленные токены, задержку и метку качества ответа.
• После этого разложите результаты по длине сессии и типу запроса.

Сам по себе порог редко дает честную картину. Если окно истории слишком широкое, кэш начинает цеплять старые, уже неуместные ответы. Если окно слишком узкое, вы теряете повторы, которые часто встречаются в длинных сценариях поддержки и внутренних помощников.

Сессии полезно делить хотя бы на три группы: короткие, средние и длинные. Например, 1-5, 6-15 и 16+ ходов. Запросы тоже стоит разнести по типам: фактологический вопрос, уточнение по прошлому ответу, переписывание текста, действие по инструкции. Ошибки кэша почти никогда не растут равномерно. В простых ответах на частые вопросы он ведет себя спокойно, а в диалоге с меняющимся контекстом ломается быстрее.

Хорошая рабочая точка редко совпадает с максимальной экономией. Чаще выигрывает настройка, где ложные срабатывания растут медленно, а экономия уже заметна. Если при переходе с 0.86 на 0.82 вы экономите еще 6% токенов, но удваиваете число плохих ответов, такой выигрыш обычно не стоит риска.

Если вы тестируете через единый шлюз и снимаете метрики в одном формате для всех моделей, проще увидеть, где кэш помогает сам по себе, а где результат зависит уже от выбранной модели.

Пример длинной сессии клиента

Представьте диалог в чате продаж. Клиент сначала пишет: "Сколько стоит тариф для команды из 40 человек в Казахстане?" Модель дает нормальный ответ, и система кладет его в семантический кэш.

Через пару реплик клиент уточняет детали: часть сотрудников будет в другой стране, нужен другой лимит запросов, а оплату хотят в тенге по ежемесячному счету. По смыслу запрос похож на первый, поэтому кэш может решить, что ответ уже есть. На вид это удачное попадание: ответ приходит быстро, токены почти не тратятся.

Проблема всплывает позже. В раннем ответе не было новой страны, других лимитов и новых условий оплаты. Клиент замечает расхождение, задает еще два или три уточняющих вопроса, а иногда просто теряет доверие к чату. Формально система сэкономила на одном ходе, но по факту создала лишнюю работу.

На коротком отрезке такая ошибка может казаться мелкой. Если сессия длится 4-5 реплик, экономия от кэша и так скромная. Часто это сотни токенов и доли секунды, которые пользователь даже не заметит.

На длинной сессии картина меняется. Если разговор идет 20-30 реплик, темы начинают повторяться: тариф, лимиты, документы, регионы, условия доступа, правила хранения данных. В таких местах хороший кэш уже дает заметную выгоду. Он может снять часть повторных обращений и сберечь тысячи токенов за одну сессию.

Но один пропущенный факт легко съедает эту выгоду. Допустим, шесть корректных попаданий сэкономили 7000 токенов и несколько секунд суммарной задержки. Затем одно ложное попадание дало неверный ответ, клиент переспросил три раза, а модель заново пересобрала контекст из длинной истории. Экономия быстро тает, а иногда уходит в минус.

Именно поэтому такой сценарий полезен для замера. Он показывает не только долю попаданий, но и цену ошибки: сколько токенов, времени и доверия съедает ответ, который "почти подошел", но пропустил одно важное уточнение.

Где команды чаще ошибаются

Перекос обычно начинается не в формуле, а в выборке. Команда берет удобные диалоги, быстро считает попадания и получает красивую цифру. Через неделю кэш выходит в прод, а жалобы приходят уже на длинных сессиях, где смысл вопроса меняется от шага к шагу.

Самая частая ошибка простая: в тесте оставляют только первые реплики. В начале сессии запросы короче, общий контекст еще не накопился, и повторов больше. Поэтому кэш кажется точнее, чем он есть на 12-м или 20-м ходе, когда пользователь ссылается на прошлые ответы, меняет условия или просит уточнить факт.

Еще одна ловушка - одна таблица для всех моделей. Если часть трафика идет через более сильную модель, а часть через дешевую, сравнение ломается. Одинаковое попадание кэша может давать разный итог: одна модель хорошо переносит короткий ответ из кэша, другая в том же месте ошибается или звучит не в тон.

Часто команды слишком мягко оценивают качество. Ответ похож по смыслу - значит, его записывают в плюс. Но для живого диалога этого мало. Если пользователь спросил про лимит, дату, ставку, статус заказа или норму закона, даже близкий по форме ответ может быть неверным. В отчете это выглядит как удачный кэш-хит, а в продукте уже считается ошибкой.

Отдельно разделяйте безопасные подсказки и ответы с фактами. Если кэш вернул вежливое приветствие, шаблонную инструкцию или нейтральное пояснение, риск низкий. Если он вернул число, имя, срок, цену или отсылку к прошлому контексту, риск выше в разы. Складывать такие случаи в одну метрику нельзя. Иначе средняя точность скроет дорогие промахи.

На практике цифры чаще всего портят одни и те же перекосы: в выборке много первых ходов и почти нет длинных веток разговора; ответы разных моделей считают вместе, как будто они равны по качеству; смысловое сходство путают с правильностью ответа; безопасные шаблоны смешивают с фактами и персональными данными; один порог похожести ставят сразу на все сценарии.

Один порог почти всегда дает ложное чувство контроля. Для раздела с частыми вопросами, поддержки, продаж и внутренних помощников нужна разная строгость. Там, где ответ опирается на факты или историю клиента, порог лучше поднимать и чаще отправлять запрос в модель заново. Там, где ответ типовой, можно быть смелее.

Если после замера у вас получилась очень высокая доля попаданий и почти нет ошибок, причина часто не в хорошем кэше, а в слишком добром тесте.

Проверка перед запуском

Запуск без базовой линии почти всегда дает красивую, но пустую цифру. Если вы не знаете, сколько токенов, денег и секунд уходит без кэша, потом просто не с чем сравнивать. Для семантического кэша в диалогах это частая ошибка: команда видит 30% попаданий и радуется, хотя ответы стали хуже, а экономия оказалась скромной.

Перед первым замером проверьте пять вещей:

• Сначала прогоните ту же выборку без кэша и зафиксируйте токены, цену, задержку и качество ответа на каждом ходе.
• Оставьте ручную проверку спорных случаев. Автоматика хорошо считает попадания, но плохо ловит ответы, которые "почти подходят", а по смыслу уже уводят диалог не туда.
• Разведите метрики по длине сессии. Короткие чаты и разговоры на 20-30 ходов ведут себя по-разному.
• Считайте полную цену, а не только входные токены. В расход должны войти эмбеддинги, хранение, повторные обращения к модели при промахе и любая служебная обработка.
• Заранее договоритесь, когда кэш надо выключать: при смене темы, появлении новых фактов, низком запасе по score сходства, чувствительных сценариях и шагах, где ошибка дороже лишнего запроса к модели.

Ручная проверка особенно нужна на длинных сессиях. Представьте чат поддержки на 25 ходов: первые 10 вопросов похожи, и кэш работает хорошо. Потом клиент меняет условие, например указывает другую дату, тариф или страну. Если система все еще тянет старый ответ из кэша, вы вроде бы экономите токены, но теряете точность там, где она нужнее всего.

Если вы гоняете модели через единый шлюз, сам список не меняется. Маршрутизация моделей, rate limits и data residency решают другие задачи. Пользу кэша все равно нужно измерять отдельно, на живых диалогах и с ручной проверкой спорных ответов.

Что сделать после первого замера

Если после первого отчета хочется сразу включить кэш везде, лучше притормозить. Один удачный прогон еще не показывает, как семантический кэш в диалогах поведет себя в соседних сценариях, где цена ошибки выше.

Начните с одного потока запросов, где промах не ломает процесс целиком. Обычно это раздел с частыми вопросами, внутренний помощник для сотрудников или типовые ответы в поддержке. Не стоит сразу нести кэш в юридические ответы, медицину, скоринг и другие случаи, где даже редкое ложное срабатывание обходится дорого.

Сохраните данные, пока они свежие

После первого цикла команды часто помнят только долю попаданий и общую экономию. Этого мало. У каждого попадания должна остаться причина рядом с логом диалога: почему система решила, что ответ можно переиспользовать, какой был score сходства, какая модель дала исходный ответ, сколько токенов и миллисекунд удалось сэкономить.

Такая запись помогает быстро разбирать спорные случаи. Через неделю уже трудно восстановить, почему похожие реплики "перевыпустить счет" и "отправить копию счета" дали хороший результат, а фразы с новым контекстом внезапно получили старый ответ.

Если вы сравниваете несколько моделей, лучше не разводить трафик по разным интеграциям. Когда все идет через один API-шлюз, формат запросов, логи и метрики остаются одинаковыми. Для команд в Казахстане это удобно делать через AI Router и airouter.kz: один OpenAI-совместимый endpoint упрощает сравнение моделей на одном потоке запросов, а аудит-логи помогают разбирать спорные случаи без ручной склейки данных.

Подготовьте второй цикл

После первого замера обычно меняют не все сразу, а несколько вещей: поднимают или снижают порог похожести, добавляют правила отключения кэша после смены темы, запрещают кэш для сообщений с числами, датами, суммами и персональными данными, отделяют безопасные сценарии от тех, где нужен новый ответ модели.

Смотрите не только на среднюю экономию, но и на хвосты распределения. Иногда 80% пользы дают длинные сессии, а короткие почти ничего не выигрывают. Иногда наоборот: кэш хорошо работает на первом вопросе и начинает ошибаться после пятого, когда контекст уже изменился.

Хороший следующий шаг простой: возьмите обновленные пороги, прогоните тот же сценарий еще раз и отдельно посчитайте случаи, где кэш пришлось бы отключить вручную. Если таких случаев стало меньше, а экономия не просела слишком сильно, настройка движется в правильную сторону.