Большое контекстное окно помогает ИИ держать в голове текущий диалог, но плохо подходит для «рабочей памяти» на месяцы. В Битрикс24 рассказали, как слой Радиант собирает данные из портала, хранит их локально и подмешивает в запросы только то, что нужно задаче.
Когда ИИ‑агента просят «вспомнить, что мы обсуждали весной» или «достань контекст по проекту за последний квартал», упираться только в большое окно контекста оказывается неудобно. Даже если модель умеет работать с сотнями тысяч или миллионом токенов, это не превращает её в систему, которая стабильно помнит историю работы команды. Внутри Bitrix24 для такого сценария тестируют отдельный слой долговременной памяти — его называют Радиант.
Почему «миллион токенов» не решает задачу памяти
Контекстное окно хорошо подходит для текущей беседы: оно удерживает последние сообщения, куски кода, требования, уточнения. Но у корпоративной рутины другой масштаб: переписки в чатах, задачи, изменения в CRM, заметки по встречам, статьи базы знаний. Если пытаться держать всё это «внутри одного запроса», возникают проблемы:
- Цена и скорость. Чем больше контекст, тем дороже запрос и тем сложнее прогнозировать время ответа.
- Шум. В большом объёме текста легко утонуть: нужные детали конкурируют с неважными.
- Нестабильность повторного использования. Одна и та же «история» в разных формулировках запроса может подтягиваться по-разному, а значит и ответы будут гулять.
Поэтому подход «просто увеличим контекст» в продуктовых сценариях часто дополняют отдельной памятью, которая заранее хранит рабочие факты и по запросу выдаёт только релевантные фрагменты.
Что такое Радиант и как он встроен в агента
В материале Bitrix24 описывают Радиант как слой долговременной памяти, который работает рядом с ИИ‑агентом. Он получает доступные пользователю данные из разных частей портала и складывает их в локальное хранилище на компьютере. В качестве источников упоминаются, в частности:
- переписка и чаты;
- задачи и проекты;
- статьи базы знаний;
- информация о людях, событиях и рабочих контекстах.
Дальше логика похожа на «умный поиск»: когда пользователь формулирует задачу, память не вываливает всю историю целиком, а пытается найти подходящие записи и подмешать их в запрос к модели как справку. В результате агент отвечает не «по общим знаниям», а опираясь на рабочие факты конкретной компании.
Чем это полезно в реальной работе
Главная ценность подхода — в предсказуемости и в том, что агент становится ближе к роли «коллеги», а не чат‑бота. Слой памяти позволяет собирать контекст из нескольких системных мест и возвращать его пользователю в нужный момент.
Несколько типичных сценариев, где долгосрочная память особенно заметна:
- Возврат к старым договорённостям. Например, агенту можно задать вопрос по проекту, который уже не обсуждали неделями, и получить ответ с опорой на прошлые задачи/обсуждения.
- Подготовка перед встречей. Быстро собрать «что мы обещали клиенту», «какие риски фиксировали», «какие дедлайны горят» — без ручного пролистывания разделов.
- Снижение нагрузки на пользователей. Люди меньше копируют фрагменты переписок и меньше пересказывают предысторию, а значит меньше ошибок «из уст в уста».
Практический нюанс: память должна быть управляемой
Долговременная память в корпоративных инструментах — это не только про удобство, но и про дисциплину. Если агент «помнит» всё подряд, качество может просесть из‑за устаревших или противоречивых данных. Поэтому важны правила: что считать источником правды, как обновлять сведения, как не подтягивать лишнее и как объяснять пользователю, откуда взялся контекст (хотя бы на уровне «какие записи использовались»).
Идея Радианта как отдельного слоя как раз помогает двигаться в сторону управляемости: вместо бесконечного контекста появляется система, которая сначала отбирает, а потом даёт модели ровно тот минимум, который нужен для задачи.
Источник: Хабр
