[2/2] Когда память одного аналитика пригодится всей команде (Рубрика #Agent)
Продолжая обсуждение MemCurrent от Databrics хочется рассмотреть вопрос применения памяти не только в разрезе пользователя, но и выше.
«Исключай фоновые запросы» - так в примере из статьи аналитик поправляет расчёт активных пользователей. В следующей сессии того же человека тест проверяет, учтёт ли агент этот фильтр в новом отчёте. Когда такой отчёт понадобится коллеге, откуда агент узнает, что фильтр нужен и ему? К ноябрю 2026 года у аналитических платформ уже есть несколько способов передать такое знание команде.
В Genie One сохранённые воспоминания личные. Общий контекст настраивают в Genie Agent. При подключении таблиц он ищет популярные запросы к ним среди тех, которые доступны редактору. Редактор может принять подходящий SQL как пример для будущих ответов. Так запрос, которым уже пользуется один аналитик, становится подсказкой для общего агента. Подробнее можно почитать в документации про память Genie One и настройку Genie Agent
У Snowflake видно, как этот цикл устроен вокруг семантического слоя. Cortex Analyst ищет в доступной истории SQL повторяющиеся фильтры, метрики и запросы. По статистике использования он также находит популярные вопросы, для которых ещё нет проверенного SQL. Предложения можно принять в общий semantic view. А в тестах есть хорошая деталь. Когда проверенный запрос выбирают как эталон для оценки (evals), Snowflake временно убирает его из подсказок, доступных агенту, и сравнивает результат сгенерированного SQL с эталонным.
Когда формула уже согласована, её можно закрепить в модели данных. В Databricks это, например, metric view в Unity Catalog. В Microsoft Fabric агент может обращаться к опубликованной семантической модели Power BI и строить DAX-запросы поверх её мер. Общий агент использует модель с правами того, кто задал вопрос. Конфигурацию самого агента, включая инструкции и выбор источников, можно версионировать в Git.
Для собственного агента у Databricks есть и общее хранилище agent memroy на базе Lakebase. Принадлежность памяти определяется через actor_id (это пользователь или другой агент - это личная память, или id группы, если память шаренная), также опционально можно добавить session_id - это даст понимание из какой сессии появилось это воспоминание. Память можно получать списком или искать по ней, а также писать в нее. Здесь приходится отдельно учитывать, кому можно показать саму заметку: в ней уже могут быть цифры из исходного запроса. Отдельно авторы отмечают, что все, кто имеют доступ к хранилищу памяти могут прочитать всю память, то есть actor_id не влияет на права доступа.
В исследовательском проекте MemAlign Databricks попробовала извлекать общее знание прямо из разговоров. Авторы взяли логи рабочего Genie Space, дали LLM-судье отобрать полезные и сохранили извлечённые знания. По их данным, после первых 62 записей результат на тесте превысил 50% при 33% у варианта с экспертными инструкциями. Это эксперимент в одном Genie Space.
Если возвращать к примеру из статьи, то у того же фильтра фоновых запросов есть область применения. В отчёте об активности он помогает посчитать людей, а при разборе нагрузки может скрыть то, за чем аналитик пришёл. Когда SQL из истории становится примером в Genie Agent или частью semantic view в Snowflake, у команды появляется конкретное место, где можно увидеть, к каким данным и вопросам относится правило.
#AI #Agents #Architecture #Data #Evals