На связи Сергей Смирнов, AI-инженер и основатель LLMStart.ru. Мы делаем AI-системы для бизнеса, и эта статья — про то, как мы управляем памятью в нашем ИИ-консультанте по 1С:УНФ для компании Айтон. О том, как этот бот прошёл путь от кривого прототипа до реального продукта, я рассказывал в первой статье серии. А здесь мы поговорим про одну конкретную боль — контекст (он же память нейросети).
Контекстные окна моделей доехали до миллиона токенов. На бумаге это звучит как магия: кажется, что в один запрос можно положить всю годовую историю переписки с пользователем, добавить сверху все инструкции компании — и ещё останется место. На практике так не работает. Большое окно — не значит «работающее» окно. Качество и стоимость ответов зависят не от размера окна, а от того, какой мусор мы туда кидаем и как вовремя мы его оттуда вычищаем.
Прежде чем лезть в цифры и инженерию, давайте коротко познакомимся с пациентом — что это за бот и как он работает. Без этого вся дальнейшая магия будет непонятна.
Поехали…
Знакомьтесь, пациент: корпоративный ИИ-консультант по 1С
Наш «пациент» — это корпоративный бот, который помогает людям работать в программе «1С:Управление нашей фирмой». Пользователь может написать ему текстовый вопрос или просто скинуть скриншот из 1С — бот всё поймёт. Под капотом это классический агент, который умеет пользоваться разными инструментами (например, поиском по базе знаний).
У агента две группы пользователей:
Внутренние консультанты. Для них бот работает как быстрый справочник. Вопросы чёткие, диалоги короткие.
Реальные клиенты (бухгалтеры, владельцы бизнеса). Они общаются с ботом в групповых чатах. Диалоги у них длинные, запутанные, они часто прыгают с темы на тему и возвращаются к старым вопросам.
Чтобы просто ответить на один вопрос пользователя, боту приходится попотеть. Сначала он расшифровывает вопрос (термины в 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 — это показатель для самых тяжелых и длинных сценариев).
Вот из чего складывается стоимость (в токенах) одного шага:
Элемент | avg | p50 | p95 |
|---|---|---|---|
Системный промпт | 1 513 | 1 513 | 1 513 |
Вопрос пользователя | 45 | 48 | 70 |
Ответ агента | 109 | 33 | 446 |
Результат поиска по базе | 950 | 1 051 | 1 447 |
Результат вызова эксперта | 622 | 688 | 1 115 |
Вызовы инструментов на цикл | 2 | 2 | 5 |
Если посмотреть на цифры, системный промпт — это константа. Вопросы пользователя и ответы агента весят сущие крохи. А вот результаты работы инструментов (поиска) перевешивают всё остальное на порядок. Один поход в базу стоит около тысячи токенов, а за один шаг агент делает их два-три.
В среднем один цикл забирает около 2000 токенов, и 93% из них — это результаты вызова поиска, а не переписка. Даже в самых длинных диалогах картина та же: выгрузки из базы — это главный потребитель памяти. Это первый неочевидный поворот: на архитектурных схемах блоки «чат» и «инструменты» выглядят равноправными, но в реальности инструменты тяжелее в десятки раз.
Дальше срабатывает эффект снежного кома. Агент помнит всю историю сессии. С каждым новым вопросом модель тащит за собой не только предыдущие реплики, но и все те огромные куски текстов, которые она искала раньше. Доля «мусора» — старых результатов поиска, уже не нужных для текущего ответа — растет стремительно:
Циклов диалога (в среднем) | Доля устаревших результатов поиска |
|---|---|
5 | 65% |
15 | 83% |
30 | 88% |
50 | 90% |
К пятнадцатому шагу диалога больше 80% информации, которую мы отправляем в модель, — это старые результаты поиска. Скорее всего, пользователь на 15-м шаге обсуждает уже совсем не ту тему, что на первом, но агент продолжает упорно тащить за собой старые данные.
Объем контекста раздувается моментально. Даже с заявленным окном в 1 миллион токенов это становится проблемой. Без оптимизации самые тяжелые сессии упираются в 200 тысяч токенов уже на 19-м шаге. Формально место в окне ещё есть, но из-за гигантского объема “шума” контекст начинает разваливаться. Практика смыкается с выводами бенчмарков: большое окно не спасет, если бездумно заливать в него всё подряд.
Три способа не сойти с ума: как мы чистим память
Итак, мы поняли, что за несколько шагов диалога контекст забивается мусором. Что с этим делать? У нас в проекте работает три разных механизма. Они решают одну проблему, но делают это совершенно по-разному.
Главное отличие — что именно они удаляют. Первые два (обрезка и суммаризация) работают со всей историей переписки. Третий (очистка) работает только с гигантскими выгрузками из базы знаний.
Обрезка и суммаризация — это два способа укоротить начало переписки, поэтому они взаимоисключают друг друга (выбираем что-то одно). А вот очистка результатов поиска работает точечно: она не трогает историю чата, а вырезает только тяжелые тексты. Поэтому она работает всегда, независимо от того, что мы выбрали в первом случае.
Вот как они устроены:
Механизм | Что делает | В чём минус |
|---|---|---|
Обрезка истории | Просто отрубает старые сообщения | Теряем историю переписки, ломаем кэш (об этом ниже) |
Суммаризация | Делает краткий пересказ старых сообщений | Платим за дополнительный вызов дешевой нейросети ради пересказа |
Очистка результатов поиска | Меняет старые тексты из базы на заглушку | Если боту снова понадобится эта информация, он пойдет искать её заново |
Обрезка истории (Trimming) — самый простой и грубый метод. Мы просто отбрасываем старые сообщения, оставляя только свежие.
Очистка результатов поиска (Clearing) — работает умнее. Она находит в истории огромные куски текстов, которые бот вытаскивал из базы, и заменяет их на короткую заглушку [cleared]. Модель видит: «тут я что-то искала в базе», но сам текст в память уже не грузится.
Суммаризация (Summary) — срабатывает, когда история становится слишком длинной. Старые сообщения отправляются в отдельную, дешевую нейросеть (Gemini 3 Flash), которая делает из них короткий пересказ. Этот пересказ и подставляется вместо простыни сообщений. Минус очевиден — мы платим за дополнительный вызов нейросети.
В настройках проекта мы переключаемся между обрезкой и суммаризацией в зависимости от задачи: для коротких диалогов — обрезка, для длинных — суммаризация. Очистка результатов поиска при этом включена всегда.
Парадокс кэша: почему удалять сообщения оказалось дороже
Как эти механизмы работают на практике? Чтобы это проверить, мы прогнали бота по тестовому сценарию из 40 реальных вопросов по 1С.
Мы сделали 4 прогона с разными настройками:
baseline (без оптимизаций вообще)
clearing (только очистка результатов поиска)
trimming + clearing (обрезка сообщений + очистка)
summary + clearing (суммаризация + очистка)
И вот тут логика сломалась. Кажется очевидным: чем меньше токенов мы отправляем в модель, тем меньше мы платим провайдеру. На реальных замерах всё оказалось иначе.
Вот что получилось на сороковом вопросе:
Стратегия | Потрачено памяти (токенов) | Итоговая стоимость сессии |
|---|---|---|
baseline (ничего не делаем) | 31.7K | $1.06 |
clearing (только очистка) | 23.7K (−25%) | $1.13 (+7%) |
trimming + clearing (обрезка) | 15.1K (−52%) | $1.33 (+26%) |
summary + clearing (суммаризация) | 12.9K (−59%) | $0.87 (−17%) |
Заметили парадокс? Обрезка сжала контекст в два раза, но оказалась самой дорогой! А суммаризация, ради которой мы делаем платные вызовы дополнительной нейросети, оказалась дешевле всех.
Почему так вышло? Причина в одной хитрости провайдеров, которая называется кэш префикса.
У нейросетей есть скидка на одинаковое начало разговора. Если вы отправляете боту длинную переписку, и её начало полностью совпадает с прошлым вашим запросом, провайдер делает огромную скидку (в 10 раз дешевле!). Это и есть кэш.
И вот что происходит с нашими механизмами:
Когда мы ничего не делаем (baseline) — начало переписки всегда одинаковое. Провайдер радостно дает нам огромную скидку. 72% наших текстов идут по дешевке из кэша.
Когда мы делаем Обрезку (trimming) — мы постоянно отрубаем старые сообщения. Начало переписки всё время меняется! Провайдер видит «новый» текст и считает его по полному тарифу. Из-за этого кэш падает до 8.6%, и мы платим кучу денег.
Когда мы делаем Суммаризацию (summary) — мы заменяем кучу сообщений на один текст-пересказ. Этот пересказ долгое время не меняется. Нейросеть видит одинаковое начало переписки и снова дает нам скидку.
А что если просто чистить результаты поиска (clearing) и ничего больше не делать? Казалось бы, идеальный вариант. Но таблица показывает, что это делает только хуже: контекст уменьшился, а стоимость выросла. Почему? Потому что модель перестает видеть старые выгрузки из базы. И если ей снова нужна та же информация, она просто идет искать её заново, делая лишнюю работу. Очистка полезна только в паре с обрезкой или суммаризацией.
Итог эксперимента: Мы решили использовать разные настройки для разных пользователей. Для наших сотрудников (которые задают короткие вопросы) мы оставили Обрезку — там память просто не успевает забиться. А для клиентов (где диалоги длинные) мы включили Суммаризацию — она экономит и память, и деньги. Очистка текстов из базы включена всегда в качестве дополнения.
Четвёртый путь: ничего не помнить, чтобы работать лучше
До сих пор мы говорили о том, как убирать мусор из памяти основного бота-консультанта. Но есть и четвёртый, радикальный метод: вообще не класть в память то, что туда класть не нужно.
Иногда боту нужно проверить свежую информацию в интернете (например, появилась ли новая кнопка в 1С). Для этой задачи мы сделали отдельного «агента-эксперта» (субагента). Основной бот вызывает этого эксперта, когда сомневается. И вот главная фишка: эксперт вообще не видит историю диалога. Ему дают только один конкретный вопрос, он идет в интернет, ищет ответ и возвращает сухие факты.
У такого подхода (когда субагент изолирован от общего разговора) есть четыре плюса:
Это дешевле: эксперт использует дешевую нейросеть. Так как он не тащит с собой длинную историю переписки, запрос к нему весит копейки.
Это точнее: эксперт отвечает ровно на тот вопрос, который ему задали. На него не давит контекст всей предыдущей беседы, и он не пытается «удовлетворить ожидания» пользователя.
Это объективнее: эксперт дает только факты и ссылки. Он не делает выводов за пользователя (существует кнопка или нет) — он просто приносит данные. А выводы делает уже основной агент.
Это спасает от галлюцинаций (феномен [ClashEval](https://arxiv.org/abs/2404. 10198)): нейросети очень любят верить своей встроенной памяти больше, чем реальным фактам из свежего поиска. Если в длинном разговоре пользователь уже пять раз уверенно сказал, что «в 1С есть кнопка Х», то нейросеть может поверить ему, даже если свежий поиск говорит, что такой кнопки нет. Изолированный эксперт с пустой памятью этому давлению не подвержен — он просто верит фактам из интернета.
В итоге, эксперт-субагент работает как независимый аудитор. Ему дают конкретную задачу, он решает её с чистой головой, отдает сухие факты и уходит. Никакого мусора в общую память он не приносит.
Вместо выводов: почему размер (окна) не имеет значения
Завтра окно в миллион токенов превратится в десять миллионов. Но это ничего не меняет.
Обычно очистку контекста обсуждают как способ сэкономить деньги: провайдеры берут плату за каждый отправленный токен, поэтому выгодно отправлять меньше. Но наши данные показывают другое: главная проблема засорённой памяти — это не счёт от провайдера, а тупость бота.
Когда на 15-м шаге диалога мы отправляем нейросети 34 тысячи токенов, из которых 28 тысяч — это старый мусор из поиска, она начинает работать хуже. Шум сбивает её с толку, и ей сложнее сосредоточиться на текущем вопросе. Большое окно не спасет от каши в голове.
В нашем боте мы собрали такой коктейль:
Обрезка сообщений — для коротких диалогов (сотрудники).
Суммаризация — для длинных диалогов (клиенты).
Очистка результатов поиска — включена всегда фоном.
Эксперт-субагент — решает отдельные задачи вообще без общей памяти.
Даже если в будущем в окно памяти поместится вся годовая переписка с клиентом и все инструкции компании разом, просто заливать всё это в модель — плохая идея. Качество работы вашего бота зависит не от того, насколько огромное окно сделал провайдер, а от того, как вы управляете памятью.
Если вы просто бросаете всё в окно, вы ставите качество своего продукта в зависимость от конкретной модели. А мы уже видели на бенчмарках, что разные модели по-разному справляются с длинными текстами: смена провайдера может уронить вам качество в 3-4 раза.
За рамками статьи остались две большие темы. Во-первых, мы не замеряли, как именно обрезка или суммаризация влияют на качество самих ответов (вдруг пересказ теряет важные факты?). Этому я посвящу следующую статью. Во-вторых, мы не разобрали, как боту помнить вас между разными сессиями (когда вы возвращаетесь к нему через неделю). Там свои хитрости, и к ним мы тоже вернёмся.
А ваш бот работает на длинных диалогах? Как вы чистите ему память — обрезаете, суммаризируете или как-то иначе? Поделитесь в комментариях, соберу самые интересные подходы в отдельный пост.
Мы разобрали реальный пример того, как управление контекстом спасает агента от «тупости» и перерасхода бюджета. Качество бота держится не на размере окна, а на том, как грамотно вы чистите его память.
В LLMStart.ru мы помогаем бизнесу решать такие задачи и получать реальный эффект от ИИ — от прототипа до промышленной эксплуатации. Если вы упёрлись в раздутый контекст и не уверены, что выбрать, обращайтесь, будем рады помочь консультацией или разработкой под ключ.
Если хотите перенять опыт и научиться делать подобные системы самостоятельно, у нас есть онлайн-курсы, а ближайший живой поток курса Deep Agents, где контекст-инжиниринг — один из четырёх ключевых блоков, стартует уже в четверг, 28 мая.
По любым вопросам пишите мне в личку: Telegram или ВК. Приглашаем также в наши соцсети про ИИ-кодинг ИИ-агентов: в ТГ-канал и ВК-сообщество