Приветствуем всех! С вами снова ML-команда RnD для B2C SberAI. Этой осенью в рамках AI Journey Contest 2025 мы представили задачу GigaMemory: global memory for LLM. Её цель — создание автономного модуля долговременной памяти для языковых моделей, способного накапливать и использовать знания о конкретном пользователе, по сути наделяя ИИ способностью «помнить» своего собеседника.

Пришло время объявить результаты! Но для начала — кратко напомним детали соревнования.

О чём было соревнование

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

• Fact Equal Session — ответ можно найти в рамках одной конкретной сессии.

• Info Consolidation — ответ требует объединения информации из нескольких сессий.

• Info Updating — вопросы, в которых данные о пользователе со временем меняются.

• No Info — вопросы, на которые в диалоге нет ответа.

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

Для успешной отправки решения участнику нужно было предоставить код модуля памяти, который встраивался в общий пайплайн: для каждой пары сообщений каждого диалога последовательно вызывался метод  write_to_memory. Здесь должна была быть основная логика: реализация механизма памяти, преобразование контекста в долгосрочную память. Конечно, каждый раз записывать информацию в память было не нужно, иначе она дублировала бы содержание диалога и «раздувала» контекст. Поэтому метод должен был уметь анализировать входящий контекст и записывать в память только важные факты. Далее после записи в память к каждому диалогу применялся метод answer_to_question, в котором нужно было сгенерировать ответ на вопрос с помощью Gigachat Lite 20b, — ожидалось, что участники будут находить и подставлять в контекст релевантную память для правильного ответа.

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

Метрика. Качество решений оценивали по метрике Accuracy (доля верных ответов). Модель сопоставляли с эталоном с использованием подхода LLM as a judge: ответ засчитывался, если его смысл полностью отражал правильный.

Ограничения и ресурсы. Мы установили для участников ряд условий:

• Фиксированный Docker-образ с предустановленным набором библиотек, моделью GigaChat Lite и без доступа в сеть.

• Максимальный объём загружаемого решения — 5 Гб, при лимите дискового пространства в 10 Гб.

• Общее время работы решения не должно было превышать 8 часов (7 на генерацию ответов и 1 на их оценку).

• Техническая конфигурация: 243 Гб RAM, 16 CPU-ядер, 1 GPU Tesla A100 (80 Гб).

Решения нужно было загрузить на платформу DS Works до 30 октября 2025 года.

Победители

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

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

А теперь кратко разберём решения команд, занявших первые четыре места. Так как третье место заняла команда из Сбера, то призовыми оказались первое, второе и четвёртое место.

Выводы из победных решений

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

1 место: ammarali32&WalaaSO 

Система использует две модели — Qwen3-8B-AWQ и GigaChat-Light-20b — и строится вокруг классификации релевантности и финальной проверки ответа, делая ставку на чистую LLM-генерацию вместо классической RAG-памяти.

Как работает

1. В методе write_to_memory система просто сохраняет весь диалог в оперативную память.

2. При ответе на вопрос система фильтрует релевантные сообщения с помощью GigaChat: для каждой пары реплик user-assistant и вопроса модель выдаёт токен 0 или 1, а далее по logprobs определяется, насколько она релевантна (порог 0,5).

3. В контекст собираются только релевантные user-сообщения.
   Если релевантных нет, то подставляется фраза «нет информации».

4. Qwen (в режиме reasoning) формирует ответ.

5. Ответ отправляется в GigaChat вместе с вопросом и ходом рассуждений.
   GigaChat при необходимости исправляет ответ Qwen’а и возвращает финальный короткий ответ. 

Fallback-ветка

Если Qwen в основном режиме вернул «нет информации», то релевантность пересчитывается ансамблем Qwen+GigaChat (берётся та, у которой вердикт-вероятность выше). Затем выполняются те же шаги.

Модели работают через vLLM с низкой температурой и ограничениями по VRAM.

2 место: Denisiuskley

Инженерно сложный и интересный пайплайн: здесь реализован многоуровневый отбор релевантной информации и формирование конечного ответа по системе «агентов». По структуре решение ближе к мини-агентной системе, чем к обычному RAG.

Как работает

1. В методе write_to_memory выполняется организация памяти:

   - Все сообщения хранятся в словаре, для каждого считается вес через экспоненциальное затухание по времени (decay_factor = 0.95).

   - Сообщения группируются в блоки (без пересечения разных сессий). Блок содержит список сообщений, границы, идентификаторы сессий и поле для релевантности или краткого итога.

2. Быстрая фильтрация через Qwen-4B. Для каждого блока формируется промпт (кратко) : «оцени релевантность блока к вопросу, верни цифру 0—9». Модель генерирует 1 токен; по logprobs вычисляется средневзвешенная оценка релевантности. Выбираются блоки с наибольшими значениями (по top-k и порогу).

3. Выбранные блоки склеиваются в один текст с пометками сессий, индексами и релевантностью. Qwen (в режиме reasoning) генерирует итог размером до 5000 токенов. Промпт инструктирует модель восстановить хронологию, вычислить зависимости, определить актуальное состояние и сделать логический вывод, не формулируя финальный ответ.

4. Сводка подаётся в GigaChat Light. Промпт описывает систему правил (SmartResponseSystem): использует внутренние «агенты» ARCHITECT, BREVITY, CONTEXT, QUALITY, EXPERT, устанавливает контроль лаконичности и достоверности, запрет на галлюцинации. GigaChat выдаёт короткий финальный ответ (одно предложение), либо фразу «У меня нет такой информации».

Модели также работают через vLLM.

3 место: WealthLab

Классический RAG-подход: система использует энкодер bge-m3 для поиска релевантных фрагментов диалога и GigaChat Light для генерации финального ответа. В отличие от первых двух мест, здесь нет LLM-классификаторов или агентных схем — оно основано на векторном поиске.

Как работает

1. Вся история диалога хранится не как набор сообщений, а как один накопленный текст, собранный из всех user-сообщений. При построении RAG этот текст разбивается на два уровня «чанков»:

   - крупные (256 токенов, overlap 64) — для грубого отбора;

   - мелкие (32 токена, overlap 8) — для дополнительного покрытия текста.

   Оба типа чанков объединяются в общий пул. Для каждого чанка с помощью модели bge-m3 вычисляется эмбеддинг и векторы сохраняются в локальную матрицу.

2. Энкодер bge-m3 кодирует вопрос. Система считает косинусное сходство между вопросом и всеми сохранёнными векторами. Выбираются топ-45 релевантных чанков, которые объединяются в финальный контекст.

3. Если релевантных чанков нет или единственный найденный содержит фразу «нет информации», то система отвечает «нет информации».

4. Финальный промпт для GigaChat простой: ответить на вопрос, опираясь на предоставленный контекст.

4 место: OPIA

И снова RAG, на этот раз — с векторным поиском по эмбеддингам FRIDA, кросс-реранкером и многоступенчатой агрегацией ответов одной LLM с целью повышения точности.

Как работает

1. Для каждого диалога хранится список пользовательских сообщений. Перед записью сообщения фильтруются по роли (обычно берётся только user role), затем нарезаются на предложения (простая сегментация по знакам/правилам). Для каждого предложения энкодер Frida вычисляет эмбеддинги.

2. При поиске релевантности вопрос кодируется тем же энкодером; затем считается косинусное сходство между вопросом и памятью. Кандидаты проходят через кросс-реранкер bge-reranker-v2-m3, после чего отбираются топ-30 кандидатов.

Генерация ответа выполняется многошагово. На основе одного и того же вопроса, но пяти разных system-промптов (на точность, полноту, наличие информации, учёт временного порядка и консолидацию фактов) GigaChat формирует пять отдельных вариантов ответа. Затем специальный агрегирующий промпт получает все пять ответов сразу и формирует единый ответ; этот шаг выполняется дважды с разными sampling-параметрами, в итоге получается два варианта агрегированного ответа. На финальном восьмом вызове GigaChat эти два агрегированных ответа объединяются в один финальный.

P. S.

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

Отдельное спасибо оргкомитету AIJ Contest за плодотворное сотрудничество и оперативность работы. 

Для вас задачу и статью готовили:

• Марк Баушенко, telegram: @kaggle_fucker

• Андрей Пономарев

• Елизавета Шевцова, telegram: @privet_liz

• Инна Глебкина

• Ольга Борисова

• Таисия Метелкина

• Юлия Васильева

• Павел Гуляев, telegram: @ai_programulya, habr: @PaGul

• Александр Абрамов, telegram: @DealerAI, habr: @Andriljo

До встречи в следующих сезонах! Stay tuned! ?