Память на миллион токенов, а толку ноль: как ИИ-агента спасали от «тупости»
Бот для компании Айтон помогает внутренним консультантам и клиентам работать с 1С:Управление нашей фирмой: принимает текстовые вопросы и скриншоты, ищет инструкции в базе знаний и при необходимости вызывает отдельного эксперта для поиска свежей информации. В стеке используются Python, FastAPI, LangChain, Qdrant, Langfuse, OpenRouter, Gemini 3.1 Pro для основного агента и Gemini 3 Flash для лёгких задач вроде пересказа.
Главная проблема оказалась не в самой переписке, а в инструментальных вызовах. На каждый клиентский вопрос агент делает 2–4 тяжёлых запроса в базу знаний, один такой результат занимает около тысячи токенов, а в среднем 93% одного цикла приходится на результаты поиска. К 15-му шагу диалога 83% контекста занимают устаревшие поисковые выгрузки, а самые тяжёлые сессии без оптимизации доходят до 200 тысяч токенов уже на 19-м шаге.
Авторы сравнили четыре режима на сценарии из 40 реальных вопросов: baseline, только очистка результатов поиска, trimming + clearing и summary + clearing. Обрезка сократила контекст до 15.1K токенов, но подняла стоимость сессии до $1.33 из-за поломки префиксного кэша; суммаризация с очисткой дала 12.9K токенов и снизила стоимость до $0.87. Поэтому для коротких внутренних диалогов оставили обрезку, для длинных клиентских — суммаризацию, очистку поисковых результатов включили всегда, а свежую проверку фактов вынесли в изолированного субагента без общей истории.
Коротко
- В кейсе разобрали более 300 реальных сессий ИИ-консультанта по 1С:УНФ и структуру токенов в каждом цикле вопрос-ответ.
- В среднем один цикл занимает около 2000 токенов, при этом 93% приходится на результаты поиска, а не на диалог пользователя с ботом.
- К 15-му шагу диалога 83% контекста уже занимают устаревшие поисковые выгрузки, которые мешают текущему ответу.
- На тесте из 40 вопросов summary + clearing снизил итоговую стоимость до $0.87, а trimming + clearing поднял её до $1.33.
- Изолированный эксперт-субагент получает только конкретный вопрос, ищет свежие факты и не тащит мусор в память основного агента.
FAQ
Зачем чистить контекст ИИ-агента, если у современных моделей уже есть окна на миллион токенов и больше?
Большое окно не означает, что модель одинаково хорошо работает со всем объёмом текста. В кейсе старые результаты поиска создавали шум, ухудшали фокус агента и делали качество зависимым от конкретной модели.
Почему обрезка истории может увеличить стоимость сессии, хотя она сокращает количество токенов в запросе?
Обрезка меняет начало переписки и ломает префиксный кэш провайдера. Из-за этого меньше токенов может считаться по более дорогому тарифу, а итоговая стоимость растёт.
Как в кейсе распределили разные способы управления памятью между внутренними консультантами и клиентами?
Для коротких вопросов сотрудников оставили обрезку истории, потому что контекст не успевает разрастись. Для длинных клиентских диалогов включили суммаризацию, а очистку результатов поиска держат постоянно.
Читайте также
Конец бесплатного кремния: как Google AI Studio превратилась из рая для инженеров в симулятор смены аккаунтов- От RAG-прототипа к агенту в продакшн: путь по метрикам, а не по моде
- Тестируем MVP в 4 раза быстрее: как нейросети изменили жизнь предпринимателей
- Как использовать Qwen3.7-Max и Grok Build 0.1 для ИИ-агентов в России
- Как я пытался сжимать смыслы вместо байтов
- Большое контекстное окно не заменяет управление памятью агента: Даже модели с контекстом на миллион токенов могут резко терять качество на длинных диалогах, если в окно попадает много старых и нерелевантных данных. Для продуктовых AI-агентов нужно проектировать отдельный слой управления контекстом, а не рассчитывать, что модель сама разберётся с большой историей.
[AI-агенты и контекст-инжиниринг]
Зарегистрированные пользователи видят только два тезиса.
Зарегистрироваться
Кейс LLMStart.ru про корпоративного ИИ-консультанта по 1С:УНФ показывает, что миллионное контекстное окно не спасает агента, если память забита старыми результатами поиска. Главный вывод: качество и стоимость зависят не от размера окна, а от управления контекстом.