RUMBA: русскоязычный бенчмарк для оценки долгосрочной памяти

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

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

Из-за этого качество памяти становится не столько вопросом того, насколько хороша модель, сколько вопросом всей архитектуры: как система извлекает факты, что именно сохраняет, как разрешает противоречия, удаляет ли данные по запросу пользователя и как использует временной контекст.

Для русского языка до сих пор не хватало бенчмарка, который проверяет именно такие аспекты долгосрочной памяти в многосессионных диалогах. Поэтому мы сделали RUMBA — Russian User Memory Benchmark: русскоязычный бенчмарк для анализа способности диалоговых систем работать с долгосрочной памятью пользователя в реалистичных разговорных сценариях.

Что проверяет RUMBA

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

В датасете выделено три крупные группы задач — «супергруппы»:

• Information Extraction объединяет вопросы, где система должна найти в прошлых сессиях нужную информацию и корректно перенести её в ответ. Это могут быть факты о пользователе, его планах, привычках, предпочтениях, работе, близких, событиях из жизни или рекомендации, которые раньше давал ассистент. В таких задачах важно не только найти совпадающий фрагмент, но и понять его статус: является ли факт актуальным, был ли он позже изменён, дополнен или удалён по просьбе пользователя. В части вопросов дополнительно важно время: система должна связать факт с датой, периодом, конкретной сессией или моментом, к которому он относится.

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

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

Что внутри датасета

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

Русская версия является основной. Английскую версию получили с помощью автоматического перевода через LLM и вручную выровняли с русской. Она нужна для кросс-лингвального сравнения: можно запускать одни и те же задачи на русском и английском языках и смотреть, как меняется поведение моделей и систем памяти.

Диалоги создавали с нуля. Пользовательские реплики писали люди, а ответы ассистента генерировали с помощью GigaChat Max. Вопросы и эталонные ответы к диалогам создавали и проверяли вручную. Метаданные — включая категории вопросов, временные метки и другие служебные поля — размечали частично вручную, частично автоматически. В сборе датасета участвовали 26 контрибьюторов, весь процесс занял 20 рабочих дней.

Многослойная таксономия

Во многих англоязычных бенчмарках (LoCoMo, LongMemEval, Mem-Gallery) для оценки памяти вопрос получает один «плоский» тип: например, temporal, multi-hop или update. Для многогранной оценки механизма памяти этого недостаточно. Один вопрос может одновременно проверять обновление факта, требовать собрать информацию из нескольких сессий общения, зависеть от даты и включать рассуждение – и мы хотим знать, как та или иная реализация памяти справляется на всех подобных «срезах».

В RUMBA каждый вопрос описан композиционно: у него есть базовая тройка тегов: semantic type × session scope × temporality. То есть мы отдельно фиксируем:

• что именно проверяет вопрос по смыслу;

• содержится ли ответ в одной сессии или распределён по нескольким;

• нужен ли для ответа временной каркас диалога.

Для темпоральных вопросов добавляем ещё один тег — temporal expression. Он показывает, как именно время выражено в репликах пользователя внутри сессий, необходимых для ответа (мы называем их «evidence-сессиями»): явно, неявно или не выражено напрямую.

Внутри семантического типа есть более детальная иерархия подтипов, а сами типы объединяются в более крупные семантические «супергруппы».

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

Примеры семантических типов вопросов

Extraction

Самый простой случай — StaticUser — устойчивый факт.

user: Нашу собаку зовут Лосяш.

Вопрос: Как зовут мою собаку?

Ответ: Лосяш.

Но Extraction не ограничивается простым поиском. Внутри есть разные подтипы.

UpdatingInfo — проверяет актуальность факта:

user: Я люблю розы.

…

user: Теперь мне больше нравятся кактусы.

…

user: Кактусы надоели, теперь мои любимые цветы — лилии.

Вопрос: Какие цветы я люблю?

Ответ: Лилии.

DeleteInfo проверяет забывание:

user: Я хочу стать актрисой.

…

user: Удали информацию о том, кем я хочу стать.

Вопрос: Кем я хочу стать?

Ответ: Нет такой информации.

AsstQuery нужен для случаев, когда важная информация была не в реплике пользователя, а в ответе ассистента:

user: Кого из писателей XX века мне почитать?

assistant: Можно начать с Булгакова, Пастернака, Довлатова, Оруэлла и Джойса.

Вопрос: Каких русских писателей XX века ты мне рекомендовал?

Ответ: Булгакова, Пастернака и Довлатова.

Reasoning

В Reasoning-вопросах ответ нельзя просто скопировать из текста.

SocialRelationship раскрывает характер связи между людьми, при этом в диалоге нет прямого называния социальной роли, она должна выясниться при помощи рассуждения:

user: У моей мамы есть только одна сестра, Лера.

Вопрос: Кем мне приходится Лера?

Ответ: Тётей.

Ordering предполагает, что сущности имеют какой-то общий атрибут, нужно расположить их в определённом порядке по заданному параметру.

user: Моих сестер зовут Ира, Василиса, Алиса

Вопрос: Назови моих сестер в алфавитном порядке

Ответ: Алиса, Василиса, Ира.

Comparison требует качественного или количественного сравнения и отражает понимание компаративных, суперлативных и тождественных отношений:

user: У нас две кошки: Мусе 5 лет, а Кусе 5 месяцев.

Вопрос: Кто из питомцев старше?

Ответ: Муся.

MultiStep требует нескольких шагов рассуждения:

user: Я купила четыре фиалки.

…

user: Одна фиалка погибла, Лена отдала мне фикус, а бабушка подарила два алоэ.

…

Вопрос: Сколько у меня теперь растений?

Ответ: Шесть.

Abstention

Abstention-вопросы проверяют, умеет ли система не отвечать, когда данных нет.

user: Мне 17, у меня есть парень.

Вопрос: Сколько лет моему парню?

Ответ: Нет такой информации.

Одна сессия и несколько

Отдельная ось разметки в RUMBA — количество сессий, нужных для ответа. На односессионные (single-session) вопросы можно ответить по одной сессии общения. Многосессионные (multi session) вопросы требуют собрать факты из разных частей истории. Нужные сведения могут появляться частями: в разных эпизодах общения пользователь сообщает отдельные детали, ограничения, уточнения или связанные факты, а ответ строится через интеграцию этих частей.

При этом многосессионность не стоит путать с распространённым типом вопросов multi-hop — многошаговыми вопросами. Multi-hop означает, что для ответа нужно пройти несколько смысловых или логических шагов. Многосессионность же описывает не сложность рассуждения, а распределение нужной информации по истории общения.

В RUMBA эти измерения разведены. Вопрос может быть многосессионным, но не требовать сложного рассуждения; а может, наоборот, требовать рассуждения даже внутри одной сессии. Благодаря этому можно отдельно оценивать, где именно возникает ошибка: в поиске нужных сессий, в объединении фактов или в самом рассуждении.

Темпоральная разметка

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

В RUMBA временная разметка устроена в несколько уровней.

Сначала вопрос получает общий тег: temporal или atemporal. В первом случае дополнительно фиксируется, как именно время выражено в evidence-сессии(-ях): явно, неявно или только через временную метку сессии.

Например, время может быть задано:

• явной датой: «14 марта», «в 2025 году»;

• относительным выражением: «вчера», «позавчера», «через три дня», «на прошлой неделе»;

• порядком событий: одно событие произошло до или после другого;

• длительностью или частотой: «две недели», «каждую пятницу», «три раза за месяц»;

• только временной меткой сессии, когда в самой реплике дата напрямую не названа.

Помимо способа выражения времени, в RUMBA размечаются подтипы temporal reasoning. Они показывают, какая именно временная операция требуется для ответа: извлечь дату, преобразовать относительное выражение в абсолютную дату, восстановить порядок событий, определить длительность, частоту или связь между несколькими событиями.

Внутри темпоральной разметки выделяется несколько важных случаев:

Пример CalendarUnderstanding, Implicit Temporal Expression:

[28.10.2025]

user: Я вчера возила Мурку к ветеринару, а сегодня забрала результаты анализов.

[02.11.2025]

Вопрос: Когда я возила Мурку к ветеринару?

Ответ: 27 октября 2025 года.

Здесь системе недостаточно просто найти событие про ветеринара. Ей нужно преобразовать «вчера» в абсолютную дату с учётом временной метки сессии, в которой была произнесена эта реплика.

Пример DateExtraction, No Temporal Expression:

[14.03.2025]

user: Я наконец-то подписала договор на новую квартиру.

[20.04.2025]

Вопрос: Когда я подписала договор на новую квартиру?

Ответ: 14 марта 2025 года.

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

Пример ComplexRelations, EventEventTimeUnderstanding:

[15.11.2025]

user: Вася и Петя приходили в гости.

[17.11.2025]

user: Мой день рождения был позавчера.

[30.11.2025]

Вопрос: Кто приходил ко мне на день рождения?

Ответ: Вася и Петя.

Здесь ответ строится не на одной реплике. Система должна понять, что «позавчера» относительно 17 ноября — это 15 ноября, а затем связать это с другим событием из той же даты: приходом Васи и Пети.

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

Как устроена оценка

Конвейер оценки RUMBA поддерживает два режима запуска, которые проверяют разные способы работы с историей общения.

Full-context. В этом режиме модель получает весь диалог целиком и отвечает на вопрос за один проход. Это не отдельная система памяти, а контрольный режим для современных LLM с большим контекстным окном: он показывает, насколько хорошо модель сама ориентируется в длинной и шумной истории общения с пользователем, находит нужные фрагменты, отделяет важные факты от фонового диалога, учитывает временные метки сессий и не путает старую информацию с актуальной. Для этого режима мы взяли несколько относительно свежих моделей, у которых весь диалог помещается в контекст.

Агент, RAG-память. Второй режим проверяет уже полноценную систему памяти вокруг LLM: RAG с долговременным хранилищем, агентную архитектуру с вызовом инструментов или их комбинацию. Такая система последовательно получает пары сообщений user-assistant, решает, какие факты стоит сохранить, записывает их в память, обновляет или удаляет при необходимости, а на этапе вопроса достаёт нужные воспоминания и передаёт их отвечающей модели. Для этого режима мы взяли несколько популярных проектов для организации памяти в LLM-системах.

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

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

RAG-системы:

Полный контекст:

Как добавить свой результат на RUMBA?

Для публичного сравнения моделей и систем памяти мы сделали таблицу лидеров RUMBA на Hugging Face.

Если вкратце:

1. Запустите свою модель или систему памяти на RUMBA. Механизм описан в README репозитория.

2. Получите файл с результатами в нужном формате и отправьте результат по правилам таблицы лидеров.

3. Дождитесь проверки администраторами.

Подробные инструкции по формату, правилам отправки и процедуре проверки можно найти в карточке таблицы лидеров.

В заключение

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

Другое важное направление — уйти от чисто Q&A-формата. Сейчас качество памяти проверяется через финальный ответ модели на вопрос, но в будущем мы хотим оценивать и само внутреннее состояние памяти: какие факты хранятся в системе, каков их набор в разные моменты диалога и как он меняется по ходу общения. Такая постановка тоже имеет свои ограничения, но при грамотной реализации позволит уйти от косвенной проверки через итоговый ответ и оценивать непосредственно промежуточные и конечные состояния памяти.

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

Ссылки

• Датасет RUMBA

• Таблица лидеров RUMBA

• Кодовая база

• Статья

Над проектом работали: Елизавета Шевцова (@spreadingmind), Инна Глебкина (@inna_glebkina), Марк Баушенко (@e0xextazy), Павел Гуляев (@PaGul), Алёна Феногенова (@alenusch).

Благодарим тех, кто внёс свой неоценимый вклад в создание данных для RUMBA.

Писали, правили, проверяли диалоги: Ирина Шамова, Ксения Кулешова, Ольга Бородина, Мария Авилова, Ангелина Прядко, Елена Дорофеева, Татьяна Чабанюк, Анна Плотникова, Маргарита Хуррамова, Максим Аношин, Павел Просяник, Ксения Кондракова, Юлия Пилигузова, Екатерина Курячая, Аллам Атабаев, Инесса Куревлева, Захар Чайченко, Виктория Николаева, Ольга Борисова, Всеволод Алипов, Данил Вязовов, Евгения Ефремова, Тимур Шентюрк, Константин Гридин.

Финально валидировали данные: Ольга Борисова, Таисия Метелкина, Мария Сабурбаева, Юлия Пилигузова, Екатерина Курячая, Аллам Атабаев. Валидация была бы невозможна без Артемия Станкевича.

Работали над английской версией: Екатерина Курячая, Аллам Атабаев, Наталья Чукичева, Ксения Кулешова, Дмитрий Косоуров, Элеонора Петрикова, Алена Губарь, Мария Петрова, Лада Ковальчук, Дарья Панайотти.

Менеджеры команд: Эльвира Будаева, Павел Ковалёв, Анна Костикова, Дмитрий Бочаров. Менеджер всего проекта: Юлия Васильева.

Мы активно развиваем проект, формируем бэклог, открыты для сотрудничества и будем рады видеть ваши сабмиты в таблице лидеров RUMBA!