На связи Сергей Смирнов, AI-инженер и основатель LLMStart.ru. Мы делаем AI-системы для бизнеса, и эта статья — про то, как мы управляем памятью в нашем ИИ-консультанте по 1С:УНФ для компании Айтон. О том, как этот бот прошёл путь от кривого прототипа до реального продукта, я рассказывал в первой статье серии. А здесь мы поговорим про одну конкретную боль — контекст (он же память нейросети).

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

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

Поехали…

Знакомьтесь, пациент: корпоративный ИИ-консультант по 1С

Наш «пациент» — это корпоративный бот, который помогает людям работать в программе «1С:Управление нашей фирмой». Пользователь может написать ему текстовый вопрос или просто скинуть скриншот из 1С — бот всё поймёт. Под капотом это классический агент, который умеет пользоваться разными инструментами (например, поиском по базе знаний).

У агента две группы пользователей:

1. Внутренние консультанты. Для них бот работает как быстрый справочник. Вопросы чёткие, диалоги короткие.

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

Чтобы просто ответить на один вопрос пользователя, боту приходится попотеть. Сначала он расшифровывает вопрос (термины в 1С хитрые: слово «счёт» может означать и счет на оплату, и банковский счет). Затем он лезет в базу знаний искать нужные инструкции. Если сомневается, зовет на помощь субагента, который пойдет гуглить свежую инфу в интернете. И только потом собирает итоговый ответ.

Из-за этого на каждый вопрос клиента бот делает по 2–4 тяжелых поисковых запроса в базу. Запомните этот факт — именно он станет главной проблемой дальше.

Стек коротко:

• Python, FastAPI на бэкенде

• LangChain для управления агентом

• Qdrant как векторная база данных (там лежат инструкции)

• Langfuse для аналитики и метрик

• OpenRouter как провайдер нейросетей. Основной мозг — Gemini 3.1 Pro, для лёгких задач (например, сделать краткий пересказ) — дешёвая Gemini 3 Flash.

На этом про архитектуру всё. Дальше мы будем говорить только про память.

Проблема 1M токенов: как нейросети забывают всё на ходу

С пациентом разобрались. Теперь давайте посмотрим на нейросети, которые работают у него под капотом, и обсудим ту самую страшную цифру — миллион токенов.

У всех современных топовых моделей заявлено гигантское окно памяти (от миллиона токенов и больше). Звучит круто: закинул туда всё что было под рукой и пошел пить кофе. Но возникает вопрос — а что модель реально сделает с этой горой текста? Сможет ли она найти нужную информацию или забудет половину, перепутает ссылки и потеряет суть разговора?

Парадокс в том, что миллион токенов в окне не означает, что модель реально способна работать с этим миллионом. У разных нейросетей память «протухает» по-разному.

Чтобы измерить это, придумали специальный тест — MRCR (что-то вроде продвинутой версии «найди иголку в стоге сена»). В огромный бессмысленный текст прячут 8 важных фактов («иголок»), а потом просят нейросеть найти их все и не перепутать. Именно на этом тесте становится видно, как сильно тупеют модели от переизбытка текста.

Посмотрим на сводные результаты этого теста для окна в 1 миллион токенов (данные из обзора yage.ai, март 2026):

Если взять актуальные модели, разрыв просто гигантский — трёхкратный! Claude Opus 4.6 находит 76% спрятанных фактов, а наша Gemini 3.1 Pro — только 24.5%. А если посмотреть на чуть более старые модели, то там вообще слёзы (16-18%). И заметьте, задача одна и та же, длина текста одна и та же, и у всех заявлено окно в миллион токенов! Создатели моделей из Anthropic честно называют это явление context rot («гниение контекста»).

Даже если взять текст поменьше (256 тысяч токенов), проблема никуда не исчезает, разрыв между умной и тупой моделью остается двукратным.

Что это значит для нас с вами — людей, которые создают реальных ботов?

Если вы выбираете стратегию «запихать весь мусор в окно и пусть нейросеть сама разбирается», вы становитесь заложником одной конкретной модели (у которой с памятью получше). Но если завтра вы захотите поменять провайдера, ваш бот моментально отупеет.

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

Вскрытие показало: 93% памяти забито мусором

Это были синтетические бенчмарки. А теперь посмотрим на реальные данные нашего агента. Спойлер: интуиция нас обманывает. Кажется, что память (контекст) забивается историей диалога — вопросами пользователя и ответами бота. На практике это не так: к 15-му циклу диалога 83% контекста занимают устаревшие результаты поиска.

Чтобы понять, как так выходит, мы разобрали более 300 реальных сессий. Мы посмотрели, из чего состоит каждый цикл «вопрос-ответ» (один шаг диалога основного агента). Для объективности взяли среднее значение (avg), медиану (p50) и 95-й перцентиль (p95 — это показатель для самых тяжелых и длинных сценариев).

Вот из чего складывается стоимость (в токенах) одного шага:

Если посмотреть на цифры, системный промпт — это константа. Вопросы пользователя и ответы агента весят сущие крохи. А вот результаты работы инструментов (поиска) перевешивают всё остальное на порядок. Один поход в базу стоит около тысячи токенов, а за один шаг агент делает их два-три.

В среднем один цикл забирает около 2000 токенов, и 93% из них — это результаты вызова поиска, а не переписка. Даже в самых длинных диалогах картина та же: выгрузки из базы — это главный потребитель памяти. Это первый неочевидный поворот: на архитектурных схемах блоки «чат» и «инструменты» выглядят равноправными, но в реальности инструменты тяжелее в десятки раз.

Дальше срабатывает эффект снежного кома. Агент помнит всю историю сессии. С каждым новым вопросом модель тащит за собой не только предыдущие реплики, но и все те огромные куски текстов, которые она искала раньше. Доля «мусора» — старых результатов поиска, уже не нужных для текущего ответа — растет стремительно:

К пятнадцатому шагу диалога больше 80% информации, которую мы отправляем в модель, — это старые результаты поиска. Скорее всего, пользователь на 15-м шаге обсуждает уже совсем не ту тему, что на первом, но агент продолжает упорно тащить за собой старые данные.

Объем контекста раздувается моментально. Даже с заявленным окном в 1 миллион токенов это становится проблемой. Без оптимизации самые тяжелые сессии упираются в 200 тысяч токенов уже на 19-м шаге. Формально место в окне ещё есть, но из-за гигантского объема “шума” контекст начинает разваливаться. Практика смыкается с выводами бенчмарков: большое окно не спасет, если бездумно заливать в него всё подряд.

Три способа не сойти с ума: как мы чистим память

Итак, мы поняли, что за несколько шагов диалога контекст забивается мусором. Что с этим делать? У нас в проекте работает три разных механизма. Они решают одну проблему, но делают это совершенно по-разному.

Главное отличие — что именно они удаляют. Первые два (обрезка и суммаризация) работают со всей историей переписки. Третий (очистка) работает только с гигантскими выгрузками из базы знаний.

Обрезка и суммаризация — это два способа укоротить начало переписки, поэтому они взаимоисключают друг друга (выбираем что-то одно). А вот очистка результатов поиска работает точечно: она не трогает историю чата, а вырезает только тяжелые тексты. Поэтому она работает всегда, независимо от того, что мы выбрали в первом случае.

Вот как они устроены:

Обрезка истории (Trimming) — самый простой и грубый метод. Мы просто отбрасываем старые сообщения, оставляя только свежие.

Очистка результатов поиска (Clearing) — работает умнее. Она находит в истории огромные куски текстов, которые бот вытаскивал из базы, и заменяет их на короткую заглушку [cleared]. Модель видит: «тут я что-то искала в базе», но сам текст в память уже не грузится.

Суммаризация (Summary) — срабатывает, когда история становится слишком длинной. Старые сообщения отправляются в отдельную, дешевую нейросеть (Gemini 3 Flash), которая делает из них короткий пересказ. Этот пересказ и подставляется вместо простыни сообщений. Минус очевиден — мы платим за дополнительный вызов нейросети.

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

Парадокс кэша: почему удалять сообщения оказалось дороже

Как эти механизмы работают на практике? Чтобы это проверить, мы прогнали бота по тестовому сценарию из 40 реальных вопросов по 1С.

Мы сделали 4 прогона с разными настройками:

1. baseline (без оптимизаций вообще)

2. clearing (только очистка результатов поиска)

3. trimming + clearing (обрезка сообщений + очистка)

4. summary + clearing (суммаризация + очистка)

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

Вот что получилось на сороковом вопросе:

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

Почему так вышло? Причина в одной хитрости провайдеров, которая называется кэш префикса.

У нейросетей есть скидка на одинаковое начало разговора. Если вы отправляете боту длинную переписку, и её начало полностью совпадает с прошлым вашим запросом, провайдер делает огромную скидку (в 10 раз дешевле!). Это и есть кэш.

И вот что происходит с нашими механизмами:

• Когда мы ничего не делаем (baseline) — начало переписки всегда одинаковое. Провайдер радостно дает нам огромную скидку. 72% наших текстов идут по дешевке из кэша.

• Когда мы делаем Обрезку (trimming) — мы постоянно отрубаем старые сообщения. Начало переписки всё время меняется! Провайдер видит «новый» текст и считает его по полному тарифу. Из-за этого кэш падает до 8.6%, и мы платим кучу денег.

• Когда мы делаем Суммаризацию (summary) — мы заменяем кучу сообщений на один текст-пересказ. Этот пересказ долгое время не меняется. Нейросеть видит одинаковое начало переписки и снова дает нам скидку.

А что если просто чистить результаты поиска (clearing) и ничего больше не делать? Казалось бы, идеальный вариант. Но таблица показывает, что это делает только хуже: контекст уменьшился, а стоимость выросла. Почему? Потому что модель перестает видеть старые выгрузки из базы. И если ей снова нужна та же информация, она просто идет искать её заново, делая лишнюю работу. Очистка полезна только в паре с обрезкой или суммаризацией.

Итог эксперимента: Мы решили использовать разные настройки для разных пользователей. Для наших сотрудников (которые задают короткие вопросы) мы оставили Обрезку — там память просто не успевает забиться. А для клиентов (где диалоги длинные) мы включили Суммаризацию — она экономит и память, и деньги. Очистка текстов из базы включена всегда в качестве дополнения.

Четвёртый путь: ничего не помнить, чтобы работать лучше

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

Иногда боту нужно проверить свежую информацию в интернете (например, появилась ли новая кнопка в 1С). Для этой задачи мы сделали отдельного «агента-эксперта» (субагента). Основной бот вызывает этого эксперта, когда сомневается. И вот главная фишка: эксперт вообще не видит историю диалога. Ему дают только один конкретный вопрос, он идет в интернет, ищет ответ и возвращает сухие факты.

У такого подхода (когда субагент изолирован от общего разговора) есть четыре плюса:

1. Это дешевле: эксперт использует дешевую нейросеть. Так как он не тащит с собой длинную историю переписки, запрос к нему весит копейки.

2. Это точнее: эксперт отвечает ровно на тот вопрос, который ему задали. На него не давит контекст всей предыдущей беседы, и он не пытается «удовлетворить ожидания» пользователя.

3. Это объективнее: эксперт дает только факты и ссылки. Он не делает выводов за пользователя (существует кнопка или нет) — он просто приносит данные. А выводы делает уже основной агент.

4. Это спасает от галлюцинаций (феномен [ClashEval](https://arxiv.org/abs/2404. 10198)): нейросети очень любят верить своей встроенной памяти больше, чем реальным фактам из свежего поиска. Если в длинном разговоре пользователь уже пять раз уверенно сказал, что «в 1С есть кнопка Х», то нейросеть может поверить ему, даже если свежий поиск говорит, что такой кнопки нет. Изолированный эксперт с пустой памятью этому давлению не подвержен — он просто верит фактам из интернета.

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

Вместо выводов: почему размер (окна) не имеет значения

Завтра окно в миллион токенов превратится в десять миллионов. Но это ничего не меняет.

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

Когда на 15-м шаге диалога мы отправляем нейросети 34 тысячи токенов, из которых 28 тысяч — это старый мусор из поиска, она начинает работать хуже. Шум сбивает её с толку, и ей сложнее сосредоточиться на текущем вопросе. Большое окно не спасет от каши в голове.

В нашем боте мы собрали такой коктейль:

• Обрезка сообщений — для коротких диалогов (сотрудники).

• Суммаризация — для длинных диалогов (клиенты).

• Очистка результатов поиска — включена всегда фоном.

• Эксперт-субагент — решает отдельные задачи вообще без общей памяти.

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

Если вы просто бросаете всё в окно, вы ставите качество своего продукта в зависимость от конкретной модели. А мы уже видели на бенчмарках, что разные модели по-разному справляются с длинными текстами: смена провайдера может уронить вам качество в 3-4 раза.

За рамками статьи остались две большие темы. Во-первых, мы не замеряли, как именно обрезка или суммаризация влияют на качество самих ответов (вдруг пересказ теряет важные факты?). Этому я посвящу следующую статью. Во-вторых, мы не разобрали, как боту помнить вас между разными сессиями (когда вы возвращаетесь к нему через неделю). Там свои хитрости, и к ним мы тоже вернёмся.

А ваш бот работает на длинных диалогах? Как вы чистите ему память — обрезаете, суммаризируете или как-то иначе? Поделитесь в комментариях, соберу самые интересные подходы в отдельный пост.

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

В LLMStart.ru мы помогаем бизнесу решать такие задачи и получать реальный эффект от ИИ — от прототипа до промышленной эксплуатации. Если вы упёрлись в раздутый контекст и не уверены, что выбрать, обращайтесь, будем рады помочь консультацией или разработкой под ключ.

Если хотите перенять опыт и научиться делать подобные системы самостоятельно, у нас есть онлайн-курсы, а ближайший живой поток курса Deep Agents, где контекст-инжиниринг — один из четырёх ключевых блоков, стартует уже в четверг, 28 мая.

По любым вопросам пишите мне в личку: Telegram или ВК. Приглашаем также в наши соцсети про ИИ-кодинг ИИ-агентов: в ТГ-канал и ВК-сообщество