Как добавить ИИ-агенту память, RAG и семантический кеш с Serverless YDB

Память и умный поиск — ключевые компоненты ИИ‑агентов: они помогают сохранять контекст и давать более точные ответы. В статье разберём, как расширить возможности агентов с помощью внешних хранилищ и семантического поиска в Serverless YDB.

Вы узнаете, зачем агенту внешнее хранилище, в чём разница между долговременной памятью и RAG, как организовать семантический поиск и сократить обращения к языковой модели с помощью кеша. Также сравним MCP‑сервер памяти с YDB MCP и обсудим нюансы перехода от прототипа к рабочему приложению.

Почему ИИ-агенту нужна база данных

Большая языковая модель, или LLM, сама по себе не хранит состояние между вызовами. Каждый запрос она обрабатывает заново и видит только тот контекст, который приложение передало ей в текущем обращении.

Поэтому агент без внешнего хранилища:

• не помнит сведения о пользователе после завершения сессии;
• не знает содержания внутренних документов;
• повторно обращается к модели при похожих запросах;
• не может передать накопленный контекст другому агенту.

Чтобы сохранить состояние, приложение должно записать нужные данные, найти среди них релевантную информацию и добавить её в следующий запрос к модели.

В демонстрационном проекте на вебинаре мы использовали для этого Yandex Managed Service for YDB в режиме Serverless (далее — Serverless YDB). В таком режиме вам не нужно настраивать и администрировать вычислительные ресурсы базы: оплата зависит от выполненных запросов и фактического объёма хранимых данных.

Как устроен демонстрационный ИИ-агент

Проект объединяет несколько компонентов:

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

• memories;
• rag_documents;
• semantic_cache.

Исходный код, сценарий демонстрации и тестовые документы доступны в репозитории вебинара. В нём отдельно вынесены модули памяти, RAG, семантического кеша, работы с YDB и обращения к языковой модели.

Архитектуру можно развивать постепенно: начать с простого агента без состояния, затем добавить память, поиск по документам, кеш и подключение через MCP.

Как подготовить инфраструктуру

Для демонстрации в Yandex Cloud создаётся база YDB в режиме Serverless и два сервисных аккаунта:

• сервисный аккаунт облачной функции получает доступ к YDB и языковой модели;
• сервисный аккаунт пользовательского интерфейса получает право вызывать функцию.

После этого в Yandex Cloud Functions разворачивается функция на Python^®. В первой версии она выполняет минимальный сценарий:

1. Получает сообщение и идентификатор пользователя.
2. Формирует системный промпт.
3. Передаёт запрос языковой модели.
4. Возвращает ответ.

Пока внешнее хранилище не подключено, каждый новый диалог начинается для агента с чистого листа.

Шаг 1. Добавляем долговременную память

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

• поиск релевантных фактов;
• извлечение и сохранение новых фактов.

Как обрабатывается запрос:

1. Вы отправляете сообщение.
2. Для запроса рассчитывается эмбеддинг.
3. Агент ищет в таблице memories семантически близкие факты.
4. Поиск ограничивается идентификатором текущего пользователя.
5. Найденные сведения добавляются в системный промпт.
6. Языковая модель формирует ответ с учётом памяти.
7. Из нового сообщения извлекаются потенциально полезные факты.
8. Факты сохраняются в YDB.

Для интеграции LangChain с YDB используется библиотека langchain-ydb, а за извлечение, дедупликацию и обновление фактов отвечает Mem0. Память строится поверх этих двух компонентов, а эмбеддинги и метаданные сохраняются в Serverless YDB.

Как работает разделение пользователей

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

Агент нашёл факты в памяти и подготовил ответ с учётом предпочтений команды.

После добавления нового сотрудника-вегетарианца агент сохранил ещё один факт и использовал его в следующих диалогах.

Когда идентификатор пользователя сменили, память оказалась пустой. Факты первого пользователя не попали в контекст второго, поскольку поиск выполнялся с фильтрацией по user_id.

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

Шаг 2. Подключаем RAG и поиск по документам

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

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

Чем RAG отличается от памяти

Механика при этом похожа: текст преобразуется в эмбеддинги, сохраняется в YDB и участвует в семантическом поиске.

Как обрабатывается документ:

1. Вы загружаете текстовый файл.
2. Приложение разбивает его на фрагменты.
3. Для каждого фрагмента рассчитывает эмбеддинг.
4. Текст, эмбеддинг и метаданные сохраняются в rag_documents.
5. При новом вопросе агент ищет семантически близкие фрагменты.
6. Найденный текст добавляется в промпт вместе с фактами из памяти.

Как агент объединяет память и документ

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

После загрузки меню у агента спросили:

• что заказать на весь отдел в рамках бюджета;
• какие блюда подойдут сотрудникам с разными предпочтениями;
• когда выгоднее делать заказ;
• какие скидки и комбо-наборы доступны.

При формировании ответа агент объединил два источника контекста:

• факты о сотрудниках из memories;
• позиции и условия заказа из rag_documents.

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

Шаг 3. Добавляем семантический кеш

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

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

Как работает семантический кеш:

1. Новый запрос преобразуется в эмбеддинг.
2. Агент ищет похожие запросы в таблице semantic_cache.
3. Для найденных вариантов рассчитывается степень семантической близости.
4. Если результат превышает заданный порог, возвращается сохранённый ответ.
5. Если совпадение недостаточно точное, запрос отправляется языковой модели.
6. Новый запрос, его эмбеддинг и ответ можно сохранить в кеше.

Эмбеддинг строится для исходного пользовательского запроса. Ответ модели хранится в текстовом виде.

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

Какие ответы не стоит кешировать автоматически

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

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

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

Шаг 4. Подключаем готовых агентов через MCP

Model Context Protocol позволяет ИИ-агентам обращаться к внешним данным и инструментам через стандартизированный интерфейс.

На вебинаре мы показывали два разных MCP-сценария. Их важно не смешивать: они решают разные задачи.

MCP Memory: интерфейс долговременной памяти

MCP-сервер памяти предоставляет агенту специализированные инструменты:

• memory_save — извлечь из текста факты, устранить дубли и сохранить результат;
• memory_search — найти релевантные факты по смыслу.

Универсальные SQL-инструменты в этом сервере отключены. Агент работает с памятью через ограниченный набор операций и не должен самостоятельно разбираться в структуре таблиц.

В демонстрации Claude Code через MCP Memory сохранил факт о том, что цены в меню намеренно указаны в токенах. В другой сессии агент нашёл этот факт и не стал воспринимать необычную валюту как ошибку.

YDB MCP: универсальный интерфейс к базе

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

Через такой сервер агент может:

• посмотреть список объектов базы;
• изучить структуру таблиц;
• получить примеры строк;
• выполнить запрос;
• проанализировать накопленные данные.

В финале вебинара агент через YDB MCP изучил содержимое базы и подготовил обзор сохранённой информации.

Какие данные хранятся в Serverless YDB

В демонстрационном проекте данные распределены между тремя таблицами.

Это обычные таблицы YDB, а не закрытый внутренний формат агентского фреймворка. Их содержимое можно изучать и изменять через интерфейс базы, программный код, запросы или MCP. Структура и последовательность обработки запроса опубликованы в репозитории проекта.

Как YDB взаимодействует с языковой моделью

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

Сохранённые в YDB данные не используются для обучения языковых моделей. Вызов модели происходит отдельно — в коде агента и с явно сформированным контекстом.

Таким образом, в этой архитектуре разделены две функции:

• Serverless YDB хранит данные и выполняет поиск;
• приложение управляет обращениями к модели и передаваемым ей контекстом.

Что добавить при переходе к рабочему приложению

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

Определить правила памяти

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

Необходимо определить:

• какие категории фактов нужны агенту;
• какие сведения нельзя сохранять;
• как долго факты остаются актуальными;
• какие изменения должны заменять предыдущие значения.

Предусмотреть обновление и удаление

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

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

Не считать логическое разделение защитой

В вебинаре память разделялась по user_id, а в MCP Memory могут использоваться пространства имён. Но пространство имён работает как фильтр запросов, а не как самостоятельный механизм аутентификации или построчной защиты данных.

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

Продумать инвалидацию кеша

Даже семантически похожие вопросы не всегда должны получать один ответ. Результат может зависеть от даты, пользователя, обновлённого документа или текущего состояния системы.

Поэтому политика кеширования должна определять:

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

Как проходит запрос после подключения всех компонентов

Итоговый маршрут выглядит так:

1. Агент ищет похожий вопрос в semantic_cache.
2. Если подходящего ответа нет, получает факты пользователя из memories.
3. С учётом запроса и памяти ищет фрагменты в rag_documents.
4. Добавляет найденный контекст в промпт.
5. Передаёт запрос языковой модели.
6. Возвращает вам ответ.
7. Сохраняет новые факты в память.
8. При выполнении правил кеширования записывает ответ в semantic_cache.

Такую последовательность реализовали в демонстрационном проекте: сначала проверяется кеш, затем подключаются память и RAG, после чего вызывается языковая модель.

Что в итоге

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

В показанной архитектуре эти механизмы работают в одной Serverless YDB:

• память возвращает факты о пользователе;
• RAG добавляет информацию из документов;
• кеш переиспользует ранее сгенерированные ответы;
• MCP подключает к данным готовых ИИ-агентов.

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

Вопросы и ответы