Переполнение контекста (Context Stuffing)

Переполнение контекста — это антипаттерн, при котором промпт загружают большими объёмами информации — документами, историей разговора, результатами поиска, целыми файлами — исходя из предположения, что «больше контекста значит лучший результат», без продуманной стратегии того, что на самом деле релевантно, как это структурировать или помещается ли это осмысленно в эффективное внимание модели. Это распространённая ранняя ошибка в проектировании систем RAG (retrieval-augmented generation) и приложений с длинным контекстом: команды замечают, что модели поддерживают очень большие окна контекста (например, модели Claude поддерживают до 200 тыс.+ токенов) и делают вывод, что вываливание всего потенциально релевантного — безопасный, простой подход, но это часто даёт обратный эффект. Исследования поведения моделей с длинным контекстом (феномен «потерян в середине», lost in the middle) неоднократно показывали, что модели надёжнее обращают внимание на информацию у начала и конца длинного контекста, чем на информацию, зарытую в середине, а значит критический факт, засунутый в середину 50-страничного контекстного дампа, измеримо с большей вероятностью будет упущен или недооценён, чем тот же факт, размещённый заметно у начала или конца. Помимо снижения точности, переполнение контекста имеет прямые последствия для стоимости и задержки — каждый токен в окне контекста тарифицируется и добавляет время обработки при каждом вызове, поэтому неоправданно раздутый промпт одновременно медленнее и дороже без какой-либо выгоды для точности, а может быть и активно вредным, если нерелевантный контент отвлекает модель или размывает её фокус на действительно важном (в литературе по оценке агентов это иногда называют «отравлением контекста» или «отвлечением контекста»). Решение — не меньшее окно контекста, а стратегия извлечения и структурирования: извлекать только то, что действительно релевантно текущему запросу (правильный RAG с хорошим ретривером, а не «просто включи всю базу знаний»), резюмировать или сжимать контекст низкого приоритета, размещать самую критичную информацию заметно (в начале или конце промпта), использовать чёткие разделители для структурирования нескольких источников контекста, чтобы модель могла в них ориентироваться, и периодически подрезать историю разговора, а не пересылать при каждом ходе постоянно растущий, необрезанный журнал чата. Разобранный пример: ранняя версия ИИ-инструмента поддержки клиентов извлекает 20 самых семантически похожих статей справочного центра для каждого запроса и запихивает все 20 (часто 15 000+ токенов) в промпт «на всякий случай», что приводит к более медленным ответам, более высоким затратам на API и — как ни парадоксально — худшей точности, потому что единственная по-настоящему релевантная статья иногда оказывается зарыта на 14-м месте по релевантности посреди набитого контекста и недооценивается моделью. Команда исправляет это, сужая извлечение до 3 самых релевантных статей (с помощью лучшего ранжирования на основе эмбеддингов) и явно сортируя их по оценке релевантности в промпте, ближе к началу — точность ответов улучшается, стоимость падает примерно в 6 раз, а задержка значительно снижается, демонстрируя, что качественная курация контекста побеждает больший объём контекста.