Сокращение затрат на LLM на 30% за счет многоуровневого кэширования с учетом проверки подлинности.
Делиться
Технология генерации с расширенными возможностями поиска (Retrieval-Augmented Generation, RAG) вышла из экспериментальной фазы и прочно вошла в корпоративную эксплуатацию. Мы больше не просто создаем чат-боты для тестирования возможностей LLM; мы строим сложные агентные системы, которые напрямую взаимодействуют с внутренними структурированными базами данных (SQL), неструктурированными озерами знаний (Vector DBs), а также сторонними API и инструментами MCP. Однако по мере масштабирования внедрения RAG в организации становится очевидной и дорогостоящей проблема — избыточность .
Во многих корпоративных системах RAG команды отмечают, что более 30% запросов пользователей являются повторяющимися или семантически схожими . Сотрудники разных отделов запрашивают одни и те же данные о продажах за 4 квартал, одни и те же процедуры адаптации и одни и те же сводки стандартных договоров с поставщиками. Внешние пользователи, спрашивающие о страховых взносах на медицинское страхование для своего возраста, часто получают идентичные ответы для пользователей со схожими профилями.
В простой архитектуре RAG каждый из этих повторяющихся вопросов запускает идентичную, дорогостоящую цепочку событий: генерацию эмбеддингов, выполнение поиска векторного сходства, сканирование таблиц SQL, извлечение огромных контекстных окон и принуждение большой языковой модели (LLM) к анализу тех же самых токенов для получения ответа, сгенерированного час назад.
Эта избыточность увеличивает затраты на облачную инфраструктуру и добавляет ненужные многосекундные задержки в ответах пользователей. Нам необходима интеллектуальная стратегия кэширования для контроля затрат и поддержания жизнеспособности RAG по мере роста числа пользователей и запросов.
Однако кэширование для Agentic RAG — это не простое хранилище типа «ключ:значение». Язык программирования многогранен, данные очень динамичны, и использование устаревшего или некорректного кэша представляет собой реальный риск. В этой статье я продемонстрирую архитектуру кэширования на реальных примерах, которая может принести ощутимые преимущества.
Схема подключения: двухканальная агентная система
Рассмотрим смоделированную корпоративную среду, используя набор данных отзывов о товарах Amazon (CC0).
Наша система Agentic RAG выступает в роли интеллектуального маршрутизатора, оснащенного доступом к двум хранилищам данных:
1. Структурированная база данных SQL (SQLite): содержит табличные данные отзывов (идентификатор, имя профиля, оценка, время, краткое описание, текст отзыва).
2. Неструктурированная векторная база данных (FAISS): содержит встроенный текстовый контент отзывов покупателей о товарах. Это имитирует внутренние базы знаний, вики-сайты и нормативные документы.
Двухуровневая архитектура кэша
Мы используем двухуровневую архитектуру кэширования, потому что пользователи редко задают один и тот же вопрос дословно, но часто задают вопросы с одинаковым смыслом , а следовательно, требующие одного и того же контекста.
Уровень 1: Семантический кэш (на уровне запроса)
Семантический кэш выступает в качестве первой линии защиты, перехватывая пользовательский запрос. В отличие от традиционного кэша, требующего идеального совпадения строки (например, кэширование `SELECT * FROM table`), семантический кэш использует эмбеддинги.
Когда пользователь задает вопрос, мы встраиваем запрос и сравниваем его с ранее кэшированными запросами, используя косинусное сходство. Если новый запрос семантически идентичен — например, показатель сходства > 95% — мы немедленно возвращаем ранее сгенерированный ответ LLM. Например:
Вопрос А: «Какова политика компании в отношении отпусков?»
Вопрос Б: «Не могли бы вы рассказать мне о правилах предоставления отгулов?»
Семантический кэш распознает эти намерения как идентичные. Он перехватывает запрос еще до вызова агента, в результате чего ответ доставляется за миллисекунды с нулевой стоимостью токенов LLM.
Уровень 2: Кэш извлечения данных (контекстный уровень)
Рассмотрим случай, когда пользователь задает вопрос следующим образом:
Запрос C: «Кратко изложите политику предоставления отпусков, специально разработанную для удаленных сотрудников».
Это не 95% совпадение, поэтому оно не проходит первый уровень. Однако документы, необходимые для ответа на запрос C, в точности совпадают с документами, полученными для запроса A. Именно здесь активируется второй уровень — кэш поиска.
Кэш поиска хранит необработанные блоки данных (строки SQL или фрагменты текста FAISS) с более широким порогом «соответствия теме» ( например, > 70% ). Если семантический кэш не справляется с задачей, агент проверяет второй уровень. Если он находит соответствующий предварительно загруженный контекст, он пропускает дорогостоящие запросы к базе данных и напрямую передает кэшированный контекст в LLM для генерации нового ответа. Он действует как высокоскоростной блокнот.
Интеллектуальный маршрутизатор: создание агентов и инструментарий.
Простого извлечения данных из кэша недостаточно. Нам необходимы механизмы для обнаружения устаревания сохраненного контента в кэше, чтобы предотвратить некорректные ответы пользователю. Для организации извлечения и проверки данных из двухуровневого кэша и бэкэндов с двумя источниками система использует агент LLM. Вместо агента RAG, который действует только как синтезатор ответов в зависимости от контекста, здесь агенту предоставляется строгий системный запрос и специальный набор инструментов, позволяющих ему выступать в качестве интеллектуального маршрутизатора запросов и валидатора данных.
Инструментарий агента включает в себя несколько настраиваемых функций, которые он может вызывать автономно в зависимости от намерений пользователя:
- search_vector_database: Выполняет запросы к базе данных Vector DB (FAISS) для поиска неструктурированного текста.
- query_sql_database : Выполняет динамические SQL-запросы к локальной базе данных SQLite для получения точных чисел или отфильтрованных данных.
- check_retrieval_cache : Извлекает предварительно загруженный контекст для более чем 70% похожих тем, чтобы пропустить поиск по Vector/SQL.
- check_source_last_updated : Быстро запрашивает у работающей базы данных SQL точное значение MAX(Time) по метке времени. Помогает определить, была ли обновлена исходная таблица 'reviews' для глобальных агрегационных запросов (например, какова средняя оценка по всем отзывам?).
- check_row_timestamp : Проверяет параметр даты и времени для конкретного идентификатора строки.
- check_data_fingerprint : Вычисляет хеш содержимого документа для обнаружения изменений. Полезен, когда отсутствует столбец «Дата-время» или в распределенной базе данных.
- check_predicate_staleness : Проверяет, изменился ли определенный «фрагмент» данных (например, определенный год).
Эта архитектура вызова инструментов преобразует LLM из пассивного генератора текста в активный, самокорректирующийся менеджер данных. В следующих сценариях будет показано, как эти инструменты используются для конкретных типов запросов с целью управления стоимостью и точностью ответов. На рисунке показан поток запросов во всех рассмотренных здесь сценариях.
Реальные сценарии
Сценарий 1: Попадание в семантический кэш (скорость и стоимость)
Это идеальный сценарий, когда вопрос одного пользователя практически идентично повторяется другим пользователем (>95% сходства). Например, пользователь спрашивает систему: «Каковы распространенные мнения о вкусе кофе?». Поскольку система впервые видит этот вопрос, это приводит к ошибке кэширования (MISS). Агент методично выполняет запрос к векторному поиску, извлекает три документа, и LLM тратит 36 секунд на анализ текста, чтобы сгенерировать исчерпывающее описание горького и восхитительного вкуса кофе.
Спустя мгновение второй пользователь задает тот же вопрос. Система генерирует векторное представление, обращается к семантическому кэшу и регистрирует совпадение. Точный ответ возвращается мгновенно.
В итоге время ответа сократилось с ~36,0 секунд до 0,02 секунд. Общая стоимость токенов для второго запроса: 0,00 долларов.
Вот последовательность выполнения запроса. ============================================================ ==== Сценарий 1: Попадание в семантический кэш (скорость и стоимость) ===== ============================================================== -> Запрос в ПЕРВЫЙ раз (ожидается промах кэша, медленный LLM + поиск в базе данных) [ПОЛЬЗОВАТЕЛЬ]: Каковы распространенные мнения о вкусе кофе? [СИСТЕМА]: Промах в семантическом кэше / ПРОПУЩЕНО. Перенаправление к агенту… [ИНСТРУМЕНТ: RetrievalCache]: Проверка кэша на наличие темы: 'общепринятые мнения о вкусе кофе' [ИНСТРУМЕНТ: RetrievalCache]: ПРОМАХ. Тема не найдена в кэше. [ИНСТРУМЕНТ: VectorSearch]: Поиск по запросу 'общепринятые мнения о вкусе кофе'… [ИНСТРУМЕНТ: VectorSearch]: Найдено 3 документа. Сохранение в кэш поиска. [АГЕНТ]: Судя по отзывам, общепринятые мнения о вкусе кофе различаются. Некоторые считают его горьким, другие описывают его как очень вкусный и восхитительный. Также встречаются мнения, что кофе может быть несвежим и безвкусным. Некоторые потребители также обеспокоены тем, как раскрыть весь вкусовой потенциал своего кофе. [ВРЕМЯ ЗАТРАЧЕНО]: 36,13 секунд -> Запрашивается ВТОРОЙ раз (ожидается попадание в семантический кэш, мгновенно) [ПОЛЬЗОВАТЕЛЬ]: Каковы общепринятые мнения о вкусе кофе? [СИСТЕМА]: Попадание в семантический кэш -> Судя по отзывам, мнения о вкусе кофе сильно разнятся. Некоторые считают его горьким, другие же описывают его как очень вкусный и приятный. Также встречаются мнения, что кофе может быть несвежим и безвкусным. Некоторые потребители также обеспокоены тем, насколько полно раскрывается вкус кофе. [ВРЕМЯ ВЫПОЛНЕНИЯ]: 0,02 секунды
Сценарий 2: Кэш извлечения данных (общий контекст)
Далее пользователь задает уточняющий вопрос: «Обобщите эти мнения в виде 3 пунктов».
Семантический кэш регистрирует ошибку MISS, поскольку намерение (формат суммирования) принципиально отличается. Однако семантическая тема очень похожа (>70%). Система обращается к кэшу поиска второго уровня , извлекает те же 3 документа, что и в сценарии 1, и передает их в LLM для форматирования в виде маркированных списков.
В итоге мы устраняем задержку и затраты, связанные с поиском ближайшего соседа в векторных базах данных, сохраняя процесс извлечения данных исключительно в оперативной памяти.
Вот последовательность выполнения запроса. ============================================================ ===== Сценарий 2: Попадание в кэш извлечения (общий контекст) ===== ============================================================== -> Проверка заполнения кэша извлечения (тихая проверка)… [ПОЛЬЗОВАТЕЛЬ]: Каковы общие мнения о вкусе кофе? [СИСТЕМА]: Попадание в семантический кэш -> Судя по отзывам, общие мнения о вкусе кофе различаются. Некоторые считают его горьким, в то время как другие описывают его как очень вкусный и восхитительный. Также существуют мнения, что кофе может быть несвежим и безвкусным. Некоторые потребители также обеспокоены тем, как раскрыть весь вкусовой потенциал своего кофе. -> Задается ДРУГОЙ вопрос на ТУ ЖЕ ТЕМУ. -> Семантический запрос немного отличается, поэтому происходит промах семантического кэша. -> Агент должен обратиться к кэшу извлечения, чтобы избежать поиска FAISS и ответить на него. [ПОЛЬЗОВАТЕЛЬ]: Обобщите эти мнения о вкусе кофе в виде маркированного списка. [СИСТЕМА]: Промах/обход семантического кэша. Переадресация агенту… [ИНСТРУМЕНТ: RetrievalCache]: Проверка кэша на тему: 'мнения о вкусе кофе' [ИНСТРУМЕНТ: RetrievalCache]: ПОПАДАНИЕ! Найден кэшированный контекст (ID документа: 481389 [АГЕНТ]: Вот краткое изложение отзывов о вкусе кофе: * Один пользователь отметил «странный привкус» и горький вкус кофе, выразив разочарование. * Другой пользователь оценил кофе, описав его как «очень вкусный» и «восхитительный» при приготовлении в капельной кофеварке, хотя он не был уверен, что полностью раскрыл его вкусовой потенциал из-за отсутствия инструкций по приготовлению. * Третий пользователь был сильно разочарован, посчитав кофе несвежим и безвкусным. [ВРЕМЯ ВЫПОЛНЕНИЯ]: 34,24 секунды
Сценарий 3: Обход кэша Agentic
Если запрос пользователя касается последних аналитических данных, таких как текущие тенденции или последние показатели продаж, целесообразно полностью обойти кэширование. В этом случае пользователь запрашивает: «Какие последние негативные отзывы?»
В этом случае маршрутизатор Agentic анализирует пользовательский запрос и понимает его временные намерения. На основе системного запроса он принимает решение полностью обойти кэш . Запрос направляется непосредственно в исходную базу данных SQL, чтобы обеспечить актуальный контекст для формирования ответа.
Вот последовательность выполнения запроса. ============================================================ ======= Сценарий 3: Обход семантического кэша для получения «последних» данных ======= ============================================================== -> Запрос «последних» данных. -> Логика запроса агента должна явно обходить кэш и обращаться к SQL. [ПОЛЬЗОВАТЕЛЬ]: Какие последние пятизвездочные отзывы? [СИСТЕМА]: Промах / Обход семантического кэша. Переадресация агенту… [АГЕНТ]: Вот последние 5-звездочные отзывы: * **Оценка:** 5, **Краткое описание:** Вкусно, **Текст:** Тонкие палочки в моей семье расходятся слишком быстро!.. продолжение
Сценарий 4: Обнаружение устаревших данных на уровне строк.
Данные не статичны. Поэтому перед использованием необходимо проверить содержимое кэша.
Допустим, пользователь спрашивает: «Каково краткое содержание отзыва с ID 120698?» Система кэширует ответ.
Впоследствии администратор обновляет базу данных, изменяя краткий текст для того же идентификатора. Когда пользователь задает тот же самый вопрос снова, семантический кэш определяет 100% совпадение. Однако он не выдает ответ вслепую.
Каждая запись в кэше хранится с тегом стратегии проверки . Перед возвратом результата система запускает инструмент проверки времени строки check_row_timestamp. Он быстро проверяет столбец Time на наличие ID 120698 в рабочей базе данных. Увидев, что метка времени в рабочей базе данных новее метки времени создания кэша, система запускает процесс аннулирования . Она удаляет устаревший кэш, принудительно выполняет запрос к базе данных и получает исправленную сводку.
Вот последовательность выполнения запроса. Я добавил дополнительную проверку, чтобы показать, что обновление несвязанной строки не приводит к аннулированию кэша. ============================================================ == Сценарий 4: Обнаружение устаревших данных (временная метка на уровне строки) === ============================================================== -> Шаг 1: Первоначальный запрос (ожидается промах, агент получает данные из SQL) [ПОЛЬЗОВАТЕЛЬ]: Предоставьте подробное описание проверки с ID 120698. [СИСТЕМА]: Промах / ОБХОД семантического кэша. Переадресация агенту… [TOOL: RetrievalCache]: Проверка кэша на наличие темы: 'review ID 120698' [TOOL: RetrievalCache]: ПРОМАХ. Тема не найдена в кэше. [AGENT]: Отзыв с ID 120698 имеет краткое описание «Мусор с привкусом гари»..продолжение. -> Шаг 2: Повторный запрос (ожидается совпадение — данные актуальны) [ПОЛЬЗОВАТЕЛЬ]: Предоставьте подробное описание отзыва с ID 120698. [СИСТЕМА]: Совпадение в семантическом кэше (метка времени актуальности строки) -> Отзыв с ID 120698 имеет краткое описание «Некачественный мусор»..продолжение.. -> Шаг 3: Имитация фонового обновления (не связанный ID 99999)… -> Тестирование извлечения ПОСЛЕ несвязанного изменения (ожидается совпадение — строка по-прежнему актуальна): [ПОЛЬЗОВАТЕЛЬ]: Предоставьте подробное описание отзыва с ID 120698. [СИСТЕМА]: Совпадение в семантическом кэше (метка времени актуальности строки) -> Отзыв с ID 120698 имеет краткое описание «Некачественный мусор»..продолжение.. -> Сейчас обновляется сам целевой отзыв (строка 120698)… [ОБНОВЛЕНИЕ В РЕАЛЬНОМ ВРЕМЕНИ]: Новый Временная метка в БД: 27-02-2026 03:53:00 -> Проверка извлечения данных из семантического кэша для строки 120698 ПОСЛЕ ее собственного обновления: -> ОЖИДАНИЕ: Обнаружен устаревший кэш (на уровне строки). Аннулирование. [ПОЛЬЗОВАТЕЛЬ]: Предоставьте подробное описание обзора с ID 120698. [СИСТЕМА]: Обнаружен устаревший кэш (строка 120698 обновлена 27-02-2026 03:53:00). Аннулирование. [СИСТЕМА]: Промах / ОБХОД семантического кэша. Переадресация агенту… [ИНСТРУМЕНТ: RetrievalCache]: Проверка кэша на наличие темы: 'обзор ID 120698' [ИНСТРУМЕНТ: RetrievalCache]: ПРОМАХ. Тема не найдена в кэше. [АГЕНТ]: ОБНОВЛЕННЫЙ отзыв по товару с ID 120698 кратко описывается как «Мусор с привкусом гари»…продолжение…
Сценарий 5: Устаревание данных на уровне таблиц (агрегации)
Проверка на уровне строк хорошо работает для отдельных запросов, но не для запросов, требующих агрегирования большого количества строк. Например;
Пользователь спрашивает: «Сколько всего отзывов в базе данных?» или «Какова средняя оценка всех отзывов?». И затем другой пользователь задает тот же вопрос снова. В этом случае проверка временной метки тысяч строк была бы крайне неэффективной. Вместо этого семантический кэш помечает агрегационные запросы стратегией проверки максимального времени в таблице. Когда тот же вопрос задается снова, агент использует инструмент check_source_last_updated для проверки запроса SELECT MAX(Time) FROM reviews. Если он обнаруживает новую временную метку в исходной таблице, он аннулирует кэш и точно пересчитывает общее количество.
Вот последовательность выполнения запроса. ============================================================ ====== Сценарий 5: Обнаружение устаревших данных (на уровне таблицы) ======= ============================================================= -> Шаг 1: Первоначальный запрос (ожидается MISS, агент выполняет глобальный подсчет) [ПОЛЬЗОВАТЕЛЬ]: Сколько всего отзывов в базе данных? [СИСТЕМА]: Промах/проход в семантическом кэше. Маршрутизация к агенту… [ИНСТРУМЕНТ: RetrievalCache]: Проверка кэша на наличие темы: 'общее количество отзывов' [ИНСТРУМЕНТ: RetrievalCache]: ПРОМАХ. Тема не найдена в кэше. [АГЕНТ]: В базе данных всего 205 отзывов. -> Шаг 2: Повторный запрос (ожидается попадание — таблица актуальна) [ПОЛЬЗОВАТЕЛЬ]: Сколько всего отзывов в базе данных? [СИСТЕМА]: Попадание в семантический кэш (актуальная метка времени источника) -> В базе данных всего 205 отзывов. -> Добавление новой записи об отзыве (id 11111) с актуальной меткой времени… -> Проверка извлечения из глобального кэша ПОСЛЕ изменения таблицы: -> ОЖИДАНИЕ: Обнаружен устаревший кэш (на уровне источника). Аннулирование. [ПОЛЬЗОВАТЕЛЬ]: Сколько всего отзывов в базе данных? [СИСТЕМА]: Обнаружен устаревший кэш (Источник 'reviews' обновлен 27.02.2026 08:03:26). Аннулирование. [СИСТЕМА]: Промах / Обход семантического кэша. Маршрутизация к агенту… [ИНСТРУМЕНТ: RetrievalCache]: Проверка кэша на наличие темы: 'общее количество отзывов' [ИНСТРУМЕНТ: RetrievalCache]: Промах. Тема не найдена в кэше. [АГЕНТ]: В базе данных всего 206 отзывов.
Сценарий 6: Выявление устаревших данных с помощью дактилоскопии.
Иногда в базах данных отсутствуют надежные метки времени updated_at, или мы имеем дело с неструктурированными текстовыми файлами или распределенными базами данных. В этом случае мы полагаемся на криптографию. Пользователь задает вопрос: «Что говорится в отзыве с ID 120698?» Система кэширует ответ вместе с хешем SHA-256 исходного текста.
Когда текст изменяется без обновления метки времени, семантический кэш обнаруживает совпадение. Используя инструмент check_data_fingerprint, он пытается выполнить проверку, сравнивая кэшированный хеш SHA-256 с новым хешем исходного текста. Несоответствие хешей вызывает срабатывание сигнализации, что безопасно аннулирует скрытое редактирование.
Вот последовательность выполнения запроса. =========================================================== == Сценарий 6: Обнаружение устаревших данных (снятие отпечатков данных) === ============================================================== -> Шаг 1: Первоначальный запрос (ожидается промах, агент получает текст) [ПОЛЬЗОВАТЕЛЬ]: Какой точный текст отзыва с ID 120698? [СИСТЕМА]: Промах / обход семантического кэша. Переадресация агенту… [АГЕНТ]: Точный текст отзыва с ID 120698: «Худший кофейный напиток, который я когда-либо пил… продолжение». -> Шаг 2: Повторный запрос (ожидается совпадение — хеш действителен) [ПОЛЬЗОВАТЕЛЬ]: Какой точный текст отзыва с ID 120698? [СИСТЕМА]: Совпадение в семантическом кэше (действительный хеш) -> Точный текст отзыва с ID 120698: «Худший кофейный напиток, который я когда-либо пил… продолжение». -> Изменение исходного текста без метки времени в базе данных SQL… -> Проверка извлечения из семантического кэша ПОСЛЕ изменения содержимого: -> ОЖИДАНИЕ: Обнаружен устаревший кэш (несоответствие хеша). Аннулирование. [ПОЛЬЗОВАТЕЛЬ]: Какой точный текст отзыва с ID 120698? [СИСТЕМА]: Обнаружен устаревший кэш (несоответствие хеша). Аннулирование кэша и повторный запуск. [СИСТЕМА]: Промах / ОБХОД семантического кэша. Маршрутизация к агенту… [АГЕНТ]: Точный текст отзыва с ID 120698: «Худший кофейный напиток, который я когда-либо пробовал…»
Сценарий 7: Резервный вариант кэширования при извлечении данных (достаточность контекста)
Хотя контекстный кэш второго уровня является мощным инструментом, иногда контекст может содержать лишь половину ответа на вопрос пользователя.
Например, пользователь спрашивает: «Каково мнение об упаковке кофе?» Система выполняет поиск, и база данных Vector возвращает документы, в которых говорится исключительно об упаковке кофе. Эта информация кэшируется.
Далее пользователь спрашивает: «Что люди думают об упаковке и вкусе кофе?»
Система обращается к кэшу поиска на основе сходства тем и передает документы в LLM. Но агенту дается указание оценить достаточность с помощью инструмента check_retrieval_cache. Агент анализирует кэшированный контекст и понимает, что контекст содержит информацию только об упаковке, но не о вкусе кофе.
Вместо того чтобы генерировать ответ о вкусе, агент запускает резервный контекст . Он отбрасывает кэш, генерирует новый запрос, специально нацеленный на «вкус кофе» и «упаковку кофе», обращается к работающей базе данных Vector DB и объединяет результаты, чтобы предоставить безупречный, основанный на фактах ответ.
Вот последовательность выполнения запроса. ============================================================ Сценарий 7: Резервный кэш извлечения (достаточность контекста) ============================================================= -> Шаг 1: Заполнение кэша извлечения узким контекстом (только упаковка) для широкой темы… -> Шаг 2: Задание широкого вопроса («упаковка» И «вкус»). -> Ожидание: [ПОЛЬЗОВАТЕЛЬ]: Что люди думают об упаковке и реальном вкусе кофе? [СИСТЕМА]: Промах / ОБХОД семантического кэша. Маршрутизация к агенту… [ИНСТРУМЕНТ: RetrievalCache]: Проверка кэша на наличие темы: 'упаковка и вкус кофе' [ИНСТРУМЕНТ: RetrievalCache]: ПОПАДАНИЕ! Найден кэшированный контекст (Отзыв 1: Коробка пришла слегка помятой, но внутренняя упаковка была надежной. [ИНСТРУМЕНТ: VectorSearch]: Поиск по запросу «упаковка кофе»… [ИНСТРУМЕНТ: VectorSearch]: Найдено 3 документа. Сохранение в кэш поиска. [ИНСТРУМЕНТ: VectorSearch]: Поиск по запросу «вкус кофе»… [ИНСТРУМЕНТ: VectorSearch]: Найдено 3 документа. Сохранение в кэш поиска. [АГЕНТ]: Мнения людей об упаковке и вкусе кофе разделились. Что касается **упаковки**: * Некоторые покупатели получили товары с поврежденной упаковкой, например, «помятая коробка» и «кофейная пыль по всей упаковке капсул». * Другие отметили проблемы с четкостью информации на упаковке. Что касается **фактического вкуса кофе**: * В нескольких отзывах вкус описывается негативно, например, «очень горький». * Один рецензент просто заявил, что он «на вкус как растворимый кофе». [ВРЕМЯ, ЗАТРАЧЕННОЕ НА ЗАТРАТЫ]: 7,34 секунды
Сценарий 8: Кэширование предикатов (проверка с ограничением по времени)
Наконец, мы можем применить усовершенствованную логику аннулирования устаревших данных для оптимизации извлечения данных из кэша. Вот пример.
Пользователь спрашивает: «Сколько отзывов было написано в 2011 году?»
Поскольку это глобальный запрос, затрагивающий большое количество строк, применяется проверка на устаревание на уровне таблицы (сценарий 5). Однако, если кто-то добавит обзор за 2026 год, значение MAX(Time) для всей таблицы изменится, и кэш за 2011 год будет аннулирован и очищен. Это неэффективно.
Вместо этого мы используем кэширование предикатов . Запись в кэше фиксирует конкретное ограничение предложения WHERE в SQL (например, Time BETWEEN start_of_2011 AND end_of_2011).
При добавлении нового обзора 2026 года с помощью инструмента check_predicate_staleness система проверяет MAX(Time) только в пределах среза 2011 года. Поскольку срез 2011 года остается неизменным, система безопасно возвращает Cache HIT. Только при добавлении обзора, датированного конкретно 2011 годом, проверка предиката помечает его как устаревший, обеспечивая высокоэффективную и целенаправленную аннулирование.
Вот последовательность выполнения запроса. ============================================================ = Сценарий 8: Кэширование предикатов (проверка с ограничением по времени) == ============================================================== -> Шаг 1: Первоначальный запрос (ожидается промах, агент выполняет отфильтрованный SQL) [ПОЛЬЗОВАТЕЛЬ]: Сколько отзывов было написано в 2011 году? [СИСТЕМА]: Промах/проход в семантическом кэше. Переадресация агенту… [АГЕНТ]: В 2011 году было написано 59 отзывов. -> Шаг 2: Повторный запрос (ожидается совпадение — фрагмент предиката свежий) [ПОЛЬЗОВАТЕЛЬ]: Сколько отзывов было написано в 2011 году? [СИСТЕМА]: Совпадение в семантическом кэше (маркер свежего предиката) -> В 2011 году было написано 59 отзывов. -> Шаг 3: Добавление НОВОГО отзыва за ДРУГОЙ год (2026)… -> Проверка семантического кэша за 2011 год ПОСЛЕ несвязанного обновления 2026 года: -> ОЖИДАНИЕ: Совпадение в семантическом кэше (фрагмент 2011 года не изменился!) [ПОЛЬЗОВАТЕЛЬ]: Сколько отзывов было написано в 2011 году? [СИСТЕМА]: Срабатывание семантического кэша (новый маркер предиката) -> В 2011 году было написано 59 отзывов. -> Шаг 4: Добавление НОВОГО отзыва В 2011 году… -> Проверка семантического кэша за 2011 год ПОСЛЕ соответствующего обновления 2011 года: -> ОЖИДАНИЕ: Обнаружен устаревший кэш (изменен маркер предиката). Аннулирование. [ПОЛЬЗОВАТЕЛЬ]: Сколько отзывов было написано в 2011 году? [СИСТЕМА]: Обнаружен устаревший кэш (изменен маркер предиката 'Время >= 1293840000 И Время <= 1325375999'). Аннулирование. [СИСТЕМА]: Промах / обход семантического кэша. Переадресация агенту... [АГЕНТ]: В 2011 году было написано 60 отзывов.
Заключение
В этой статье мы продемонстрировали, как избыточность незаметно увеличивает задержку и расход токенов в производственных системах RAG. Мы рассмотрели настройку агентской системы с двумя источниками данных, сочетающую структурированные данные SQL и неструктурированный векторный поиск, и показали, как повторяющиеся запросы излишне запускают идентичные конвейеры извлечения и генерации данных.
Для решения этой проблемы мы внедрили двухуровневую архитектуру кэширования, учитывающую валидацию:
- Первый уровень (семантический кэш) исключает повторные рассуждения в рамках LLM, мгновенно предоставляя семантически идентичные ответы.
- Второй уровень (кэш получения данных) позволяет избежать избыточных поисков в базе данных и векторных поисков за счет повторного использования ранее полученного контекста.
- Многоуровневая проверка данных с помощью агентов — обход временных ограничений, проверки на уровне строк и таблиц, криптографическое хеширование, аннулирование с учетом предикатов и оценка достаточности контекста — гарантирует, что эффективность не достигается за счет корректности.
В результате получилась система, которая не только быстрее и дешевле, но и умнее и безопаснее.
По мере масштабирования системы RAG на предприятиях разница между прототипом и производственной системой будет заключаться не в размере модели, а в архитектурной дисциплине и эффективности. Интеллектуальное кэширование превращает Agentic RAG из реактивного конвейера в самооптимизирующийся механизм обработки знаний.
Свяжитесь со мной и поделитесь своими комментариями на сайте www.linkedin.com/in/partha-sarkar-lets-talk-AI
Ссылка
Набор данных «Отзывы о товарах Amazon» от Архама Руми (владелец) (CC0: общественное достояние)
Изображения, использованные в этой статье, сгенерированы с помощью Google Gemini. Рисунки и соответствующий код созданы мной.
Источник: towardsdatascience.com
