Кеш ответов ИИ-агента: когда похожий вопрос требует нового ответа

Сотрудник получает от ИИ-агента быстрый ответ, но в нём закрытые условия другого клиента и устаревшая цена. Разбираем, как устроен кеш ответов и какие проверки не дают ему раздавать неверные факты.

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

В условной компании «Северный мотив» менеджер по продажам в 11:40 спрашивает у внутреннего ИИ-ассистента: «Можно ли отгрузить партию со склада в Екатеринбурге на условиях прошлого месяца?» Ассистент за доли секунды отвечает: «Да, отгрузка возможна, скидка 7%, отсрочка 14 дней». Менеджер отправляет клиенту письмо. А в 12:10 выясняется, что скидку 7% отменили ещё в понедельник, склад в Екатеринбурге переведён на другой юридический адрес, а отсрочка 14 дней действовала только для контрагентов с подписанным допсоглашением. Ответ был технически быстрым и фактически устаревшим — потому что его взяли из кеша, а не собрали заново.

Кеш ответов ИИ-агента — это не то же самое, что кеширование префикса промпта или кеш HTTP-страниц. Здесь переиспользуется готовый текст ответа, собранный из источников, прав доступа и версии знаний на конкретный момент. И как только хотя бы одно из этих измерений меняется, «похожий» вопрос перестаёт быть тем же самым. Разберём, как устроен такой кеш, где он ломается и как проверить, что он не превращает ассистента в машину по раздаче устаревших фактов.

Ключ кеша — это не текст вопроса, а снимок условий

Первое, что обычно делают при слове «кеширование», — берут нормализованный текст вопроса и хешируют его. «Можно ли отгрузить со склада в Екатеринбурге?» и «Можно ли отгрузить со склада в Екатеринбурге» дадут одинаковый хеш, если убрать знаки препинания и регистр. Это удобно и почти всегда неправильно для агента, который отвечает по корпоративным данным.

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

Практичнее считать ключом не строку, а кортеж: нормализованный вопрос плюс идентификатор роли или набора прав, плюс версия источника знаний, плюс область данных (например, склад или регион), плюс временное окно действия ответа. Тогда «тот же вопрос» — это совпадение по всем измерениям, а не только по буквам. И это уже не «кеш ответов», а «кеш ответов при условиях», что гораздо ближе к тому, как реально работает бизнес.

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

Семантическая близость: где «похоже» превращается в «то же самое»

Когда ключ строится по смыслу, а не по точному тексту, появляется соблазн считать вопросы «Можно ли отгрузить со склада в Екатеринбурге?» и «Разрешена ли отгрузка из екатеринбургского склада?» одинаковыми. По смыслу они действительно близки. Но семантическая близость — это мера сходства векторов, а не гарантия, что ответ на один вопрос годится для другого. Два вопроса могут быть близки по формулировке и различаться по существу: «Можно ли отгрузить партию на условиях прошлого месяца?» и «Можно ли отгрузить партию на условиях позапрошлого месяца?» — векторы почти совпадут, а ответы разные.

Поэтому порог семантического совпадения — это не техническая настройка, а бизнес-решение. Чем ниже порог, тем больше попаданий в кеш и тем выше риск, что «похожий» вопрос получит ответ от «соседнего». Чем выше порог, тем чаще агент идёт собирать ответ заново и тем дороже каждый запрос. В документации Microsoft по политике семантического кеша для Azure API Management прямо описано, что поиск по кешу опирается на векторную близость запроса к сохранённым, и что порог задаётся конфигурацией — то есть ответственность за качество попаданий лежит на том, кто этот порог выставил, а не на модели. Это полезно держать в голове: механизм не «понимает», что вопрос другой, он измеряет расстояние.

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

Версия знания: ответ живёт ровно столько, сколько живёт факт

Самый частый источник ошибок — не права и не семантика, а время. Ответ «скидка 7%» был верным в прошлый вторник и перестал быть верным в понедельник. Если кеш не знает, к какой версии прайса или регламента привязан ответ, он будет раздавать его до истечения технического срока жизни, который к бизнес-факту отношения не имеет.

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

Полезно держать в голове простую аналогию с HTTP-кешем: там тоже есть заголовки свежести и валидации, и сервер может сказать «не изменилось» или «устарело». В документации MDN по HTTP-кешированию описано, как клиент и сервер договариваются о свежести через Cache-Control, ETag и Last-Modified. Идея валидации переносится и на кеш ответов агента: перед выдачей готового ответа можно проверить, не изменилась ли версия источника, и если изменилась — пересобрать. Это дешевле, чем всегда собирать заново, и надёжнее, чем слепо доверять сроку.

Права доступа: один вопрос, разные ответы

В условном сценарии в «Северном мотиве» два сотрудника задают один и тот же вопрос про условия отгрузки. Руководитель направления видит полную скидку и отсрочку. Стажёр, у которого нет доступа к коммерческим условиям, должен получить ответ «уточните у руководителя» или общую справку без цифр. Если кеш общий, стажёр получит ответ руководителя — и это уже не мелкая неточность, а утечка.

Проблема в том, что права — это не атрибут вопроса, а атрибут спрашивающего. Поэтому кеш ответов для агента почти всегда должен быть партиционирован по правам или, как минимум, проверять права при выдаче. В документации Microsoft по Azure AI Search описан подход, при котором приложение фильтрует результаты поиска по идентичности пользователя (security trimming) до того, как они попадут в ответ. Для кеша это означает: либо ключ включает набор прав, либо выдача из кеша проходит ту же проверку, что и первичная сборка. Второй вариант надёжнее, потому что права могут меняться, а ключ — нет.

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

Два эпизода: как кеш ломается на ровном месте

Первый эпизод — условный, про цены. Компания «Ладья» (название условное) обновляет прайс каждый вторник. В понедельник менеджер спрашивает агента: «Сколько стоит базовая лицензия на 50 пользователей?» Агент отвечает: 240 000 рублей. Ответ попадает в кеш с часовым сроком жизни. Во вторник в 09:15 прайс обновляется, цена становится 265 000. В 09:40 другой менеджер задаёт тот же вопрос — и получает из кеша 240 000, потому что час ещё не истёк, а связь с версией прайса не настроена. Менеджер отправляет клиенту коммерческое предложение со старой ценой. Ошибка обнаруживается через день, когда клиент присылает оплату по старой сумме.

Что здесь пошло не так: срок жизни был привязан к времени, а не к событию обновления прайса. Исправление — инвалидировать записи кеша по событию «опубликована новая версия прайса», а не по таймеру. И дополнительно — помечать ответы, содержащие цены, как «требующие проверки версии» перед выдачей.

Второй эпизод — условный, про права. В компании «Гранит» (название условное) есть агент, который отвечает на вопросы по договорам. Юрист с полным доступом спрашивает: «Какие штрафы предусмотрены по договору с контрагентом X?» Агент отвечает: «0,1% за день просрочки, максимум 10%». Ответ кешируется. Через час тот же вопрос задаёт менеджер, у которого доступ только к реквизитам договора, но не к тексту. Агент отдаёт ответ из кеша — с суммой штрафа, которую менеджер видеть не должен. Формально это не взлом, а просто отсутствие проверки прав при выдаче. Но последствия те же.

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

Запись кеша ответов: что именно хранит запись кеша

Если не описать запись кеша явно, её форма сложится сама — и обычно неудачно. Минимальный набор полей, который стоит зафиксировать до реализации, выглядит так: нормализованный вопрос, вектор вопроса (если используется семантика), набор прав или роль, область данных, идентификатор версии источника, тип факта (справка, цена, состояние, персональные условия), время создания, срок жизни или условие инвалидации, сам текст ответа и ссылки на источники, из которых он собран.

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

Отдельное поле — тип факта. Именно оно определяет, можно ли кешировать ответ вообще и на какой срок. Справочные ответы («как оформить заявку») живут долго. Цены и скидки — коротко и с привязкой к версии прайса. Состояния («заявка одобрена») — не кешируются. Персональные условия конкретного клиента — не кешируются или кешируются только в разрезе этого клиента и с проверкой прав.

Эта таблица — не истина в последней инстанции, а рабочий шаблон, который стоит адаптировать под свои источники. Главное — чтобы тип факта был явным полем, а не выводился из текста ответа на лету.

Запись кеша ответов: когда кеш лучше отключить

Есть случаи, где кеширование ответов приносит больше вреда, чем пользы, и честнее это признать заранее. Первый — вопросы о состоянии: «прошёл ли платёж», «подписан ли договор», «есть ли товар на складе». Здесь ответ меняется независимо от текста вопроса, и любой кеш рискует отдать вчерашнюю картину. Второй — вопросы с персональными данными: ответ, собранный для одного клиента, не должен всплывать в ответе для другого, даже если вопрос сформулирован одинаково. Третий — вопросы, где ответ зависит от времени суток или дня: «можно ли отгрузить сегодня» в пятницу вечером и в понедельник утром — разные вопросы.

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

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

Запись кеша ответов на экране сотрудника

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

Практичный вариант — небольшая метка рядом с ответом: «из кеша, версия прайса от 12.05» или «собрано заново, источники: регламент, прайс». Если сотрудник видит, что версия старая, он может запросить пересборку. Это дешевле, чем строить сложную систему автоматической инвалидации, и честнее, чем делать вид, что кеш всегда актуален.

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

Как проверить кеш перед запуском

Проверка кеша ответов — это не один тест, а набор сценариев, которые стоит прогнать до того, как агент начнёт отвечать сотрудникам. Первый сценарий — изменение источника: обновите прайс или регламент и проверьте, что ответы, собранные из него, перестали выдаваться из кеша. Второй — разные права: задайте один и тот же вопрос от имени сотрудника с полным доступом и сотрудника с ограниченным, убедитесь, что ответы различаются. Третий — семантическая близость: задайте вопрос, близкий по смыслу, но отличный по существу (например, про другой месяц или другой склад), и проверьте, что кеш не отдаёт ответ от «соседнего» вопроса. Четвёртый — состояние: задайте вопрос о статусе заявки, измените статус и проверьте, что агент не отдаёт старый ответ.

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

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

Практикум: проверка кеша на вопросе о сроках поставки

Возьмём другой пример, чтобы не повторять арифметику из начала статьи. Условная компания «Вектор» продаёт оборудование и держит агента, который отвечает на вопросы о сроках поставки. Вопрос звучит так: «За сколько дней поставите насос модели N-200 в Казань?» Агент отвечает: «14 рабочих дней при наличии на складе, 30 рабочих дней под заказ». Ответ попадает в кеш.

Через неделю склад в Казани опустел, и срок при наличии изменился на «под заказ, 30 дней». Менеджер задаёт тот же вопрос и получает из кеша старые 14 дней. Клиент рассчитывает на две недели, а по факту ждёт месяц. Чтобы этого не случилось, нужно:

1. Определить тип факта для этого вопроса — это состояние склада плюс срок поставки, то есть комбинация состояния и справочной информации.
2. Привязать запись кеша к версии данных о наличии на складе, а не только к тексту вопроса.
3. Задать короткий срок жизни для ответов, содержащих сроки поставки, и инвалидацию по событию «изменилось наличие».
4. Проверить сценарий: изменить наличие на складе и убедиться, что агент пересобирает ответ.
5. Добавить в интерфейс метку «данные о наличии от такого-то времени», чтобы менеджер видел, на чём основан ответ.

Этот практикум показывает главное: кеш ответов — это не про скорость, а про то, какие условия делают ответ верным. Если условие не описано, кеш будет раздавать ответы, которые когда-то были правильными.

Проверка на практике: запись кеша ответов

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

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

Смежный вопрос разобран отдельно: Кэширование промптов: когда длинный контекст дешевле.