Эксперименты с Радиантом: память агента против окна в миллион токенов

Привет! Меня зовут Глеб Смольяков, я инженер-программист в DevRel-отделе Битрикс24.

Если агент должен помнить работу за месяцы и годы, одного большого контекстного окна недостаточно. Нужен отдельный слой памяти, который хранит рабочую историю снаружи и перед запросом, если он касается работы, достаёт из неё подходящие записи. В агенте Битрикс24 Коворк/Код такой слой называется Радиант, его я и проверял.

Содержание

• Эксперимент 1: проблема контекстного окна в один миллион токенов

• Как устроена память Коворк/Код

• Эксперимент 2: как далеко Радиант может заглянуть в рабочую историю

• Эксперимент 3: два подхода на одинаковых вопросах

• Эксперимент 4: сколько контекста Радиант реально передаёт модели

• Где память всё ещё не справляется

• Что показывают другие исследования длинного контекста

• Заключение: а что у других агентов?

Эксперимент 1: проблема контекстного окна в один миллион токенов

Контекстное окно модели работает внутри одного сеанса: в нём лежит текущая переписка и то, что агент подгрузил для ответа. Можно загружать туда всю историю каждый раз, но она не влезет даже в окно на миллион токенов. У меня память Радианта весит 6,8 млн токенов, в ней переписка, карточки людей, чатов, событий и статей, задачи. Это в 6,5 раза больше такого окна, а из самой переписки оно вмещает только последние четыре месяца.

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

Ниже в таблице — данные о поиске факта внутри длинного контекста. Проверял я это на синтетическом журнале команды: вымышленные имена, задачи и технические данные, нужный факт примерно в середине. Модель bitrixgpt-5.6-agent через AI Router  (OpenAI-совместимый API Битрикс24 для доступа к языковым моделям), каждый объём по 3–5 прогонов. Ещё я двигал факт по контексту. Факт в начале контекста модель находила стабильно, хуже всего — в конце.

После 400 тысяч точность быстро снижается. Например, в журнале было указано, что стенд QA-17 работает на порту 8443. Рядом находились похожие записи о других стендах и портах. На контексте в 700 тысяч токенов модель уверенно отвечала 8539 — значением из соседней записи. 

В журнале: «Стенд QA-17 поднят на порту 8443, доступ выдаёт дежурный по релизу.» Рядом разбросаны строки той же формы про другие стенды и порты.

Вопрос: «На каком порту поднят стенд QA-17? Ответь только числом.»

Ответ на 700 тысячах: «8539». Модель уверенно называет порт соседнего стенда, ответа «не знаю» не было ни разу. Для сравнения тот же тест провели на bitrixgpt-5.5, и на 200 тысячах она так же ответила «8138».

Как устроена память Коворк/Код

За долговременную память Коворка отвечает слой Радиант. Он собирает доступные пользователю данные Битрикс24 из разных источников (переписку, задачи, статьи базы знаний, информацию о людях, чатах и событиях) и сохраняет их в локальном хранилище на компьютере.

В нашем эксперименте память Радианта распределилась так:

После обновления Радиант смог догрузить старую историю: журнал переписки вырос с 2432 до 17 085 сообщений.

Данные лежат в Markdown и JSON. Поиск простой, по словам запроса и без векторного индекса, выше в выдаче те записи, где совпало больше слов. Источники обновляются отдельно, а полный пересчёт памяти идёт ночью.

Глубина такой памяти зависит от тарифа: можно хранить данные за 30, 90 или 180 дней либо без ограничения. На ограниченных тарифах старые записи удаляются, а без ограничения Радиант хранит всю накопленную историю. У меня включён безлимит, поэтому старые записи не удалялись. А после обновления Радиант загрузил с портала старую переписку, так в памяти оказались сообщения пятилетней давности.

Эксперимент 2: как далеко Радиант может заглянуть в рабочую историю

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

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

Поиск работает в два этапа:

1. Сначала Радиант находит все записи, где есть хотя бы одно слово из запроса, в этом эксперименте первый поиск находил в медиане 3 294 записи. Модели уходит не больше 100 верхних, где совпало больше всего слов. 

2. Если нужного сообщения среди них нет, агент меняет запрос и ищет снова, и каждый такой поиск — это ещё один шаг модели. Время уходит на эти шаги, а сам вызов поиска занимает около секунды, в сумме от одной до девяти секунд на ответ. Верный ответ приходил в медиане через 101 секунду.

Эксперимент 3: два подхода на одинаковых вопросах

Я задал 12 одинаковых вопросов в двух вариантах. В первом Коворк работал с Радиантом. Во втором выгрузку памяти Радианта, до 380 тысяч токенов, получала bitrixgpt-5.6-agent через AI Router. Эта же модель была выбрана в интерфейсе Коворка, но какой моделью приложение отвечало на самом деле, в августовских записях не сохранилось. В выгрузку поместились переписка, чаты, события, задачи и 107 карточек сотрудников из 230. База знаний не влезла совсем.

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

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

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

Этот замер я делал в августе. Тогда память Радианта покрывала 28 дней, и вся переписка ещё помещалась в окно. Сейчас память выросла до 6,8 млн токенов.

Эксперимент 4: сколько контекста Радиант передаёт модели

Дальше я разобрал журнал приложения за 24–25 сентября, 22 хода агентной модели. Я хотел понять, сколько данных Радиант передаёт модели за ход и нужно ли для этого окно в миллион.

Все засчитанные верные ответы в этой выборке получены на bitrixgpt-5.5-agent с окном 262 тысячи токенов. За ход модель получала в медиане 89 тысяч, примерно 1,3% всей памяти Радианта. На таком объёме окно ещё не ошибается, я проверил это отдельно: прогнал 5.5-agent на синтетическом журнале с 90 и 155 тысячами токенов, и факт нашёлся 6 раз из 6. Получается так, что окно в миллион для этих ответов не пригодилось совсем.

Где память всё ещё не справляется

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

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

С конкретными фактами результат стабильный: один и тот же вопрос в трёх отдельных сеансах дал три одинаковых ответа за 25–28 секунд. На вопросах с обобщением разброс выше: в четырёх случаях из пяти агент называл одну и ту же главную тему, но детали и числа внутри ответов различались, а время колебалось от 27 до 189 секунд.

Отдельно я проверил саму модель, без Радианта: может ли она связать факты, разбросанные по контексту. Тест шёл через AI Router на синтетическом журнале. В нём было указано, что задачу T-482 ведёт Ирина Ковалёва, с 12 по 26 мая она в отпуске, а на время отпуска её задачи переходят Олегу Дёмину. На вопрос «Кто отвечает за задачу T-482 пятнадцатого мая?» модели выбирали первый подходящий факт и отвечали «Ирина Ковалёва». Без подсказки правильного ответа не было ни в одном из 107 запусков, даже на 10 тысячах токенов.

Ограничения Радианта на сегодня в одной таблице

Что показывают другие исследования длинного контекста

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

Есть и работы в пользу большого контекста. В отчёте Google о Gemini 1.5 простой поиск одного факта держал точность больше 99% до 10 млн токенов. А Li и др. (EMNLP 2024) показали, что длинный контекст в среднем отвечает точнее поиска, пока все нужные данные помещаются в окно.

Заключение: а что у других агентов?

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

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