Все уроки · 44
Как ломается контекст: когда больше — значит хуже
Потеря в середине, отравление контекста, «гниение» контекста и противоречивые инструкции — как ломается контекст, как это обнаружить и как предотвратить.
Контекст ещё и портится
В предыдущих уроках окно контекста было бюджетом, который нужно заполнить. Но полное окно может работать хуже небольшого: всё, что видит модель, влияет на её ответ, и мусор тоже.
Сбои из-за испорченного контекста опасны тем, что переживают тестирование. Ваш промпт в демо работает, прогон на тестовом стенде выглядит отлично, а потом реальный пользователь с более длинной историей и более путаным вопросом получает уверенный, но неверный ответ. Ничего не падает, в логах нет ни одной ошибки. Вот четыре вида сбоев, с которыми вы встретитесь в реальной эксплуатации, — и что делать с каждым.
Пара слов о галлюцинации, раз она встретится ниже: так называют ситуацию, когда модель утверждает нечто правдоподобное, но ложное. Модель при этом не лжёт и не говорит наугад: обычно контекст сам делает неверный ответ самым вероятным следующим предложением.
Контринтуитивная часть: больше контекста может снизить точность
Инстинкт подсказывает считать контекст топливом: чем его больше, тем дальше сможет уехать модель. Но контекст скорее похож на письменный стол: каждый лишний лист — это ещё одна вещь, которая борется за внимание. Три разных механизма превращают добавление контекста в плохой ход:
- Отвлечение. Нерелевантный материал модель не игнорирует, а использует. Фрагмент, у которого лишь совпадают с вопросом ключевые слова, конкурирует с правильным, и модель вплетает оба в один гладкий ответ. Если перейти от 5 надёжных фрагментов к 25 «авось подойдёт», ответы станут хуже.
- Позиция. Внимание сильнее всего в начале и в конце окна и слабее всего в середине. Поэтому новый контекст добавляет шум и заодно сдвигает уже имеющиеся факты в мёртвую зону. Факт, хорошо заметный в коротком промпте, может пропасть из виду, когда вокруг него появляется лишний текст.
- Противоречие. Каждый добавленный блок — ещё один шанс внести второе, конфликтующее правило. Тогда модель молча выбирает одно сегодня и другое завтра.
Для тех, кто потратил недели на повышение полноты поиска (recall), вывод такой: точность (precision) обычно побеждает полноту. Десять фрагментов, которым вы доверяете, лучше пятидесяти, в которых вы надеетесь найти ответ. Когда качество падает, убирать контекст почти всегда быстрее, чем добавлять новый.
Отравление: один лишний фрагмент сбивает всё с пути
Самый частый сбой. Ваш поиск срабатывает по ключевым словам, подтягивает документ, который выглядит связанным, хотя к вопросу не относится, — и модель вплетает его в ответ. Пройдитесь по этому разговору со службой поддержки и посмотрите, как это происходит:
Цена всё это время была в контексте. Но фрагменты два и три, которые нашлись потому, что совпало слово «холст», загрязнили окно, и модель любезно пересказала это загрязнение в ответе. С арифметикой модели и её данными о ценах всё было в порядке — грязным оказалось окно.
Посмотрите на последние два сообщения: та же модель, тот же вопрос, один фильтр, добавленный выше по цепочке. Исправление почти всегда лежит в поиске, а не в промптах: более точные фильтры, меньше фрагментов, но более релевантных, и инструкции вроде «для вопросов о ценах используй только фрагмент с ценами».
Потерянное в середине: мёртвая зона
Внимание модели распределено по окну неравномерно. Факты в начале и в конце она замечает, а факты, зарытые в середине длинного контекста, стабильно используются не в полную силу — так же, как читатель пролистывает средние главы длинного отчёта. Это классический эффект «потерянного в середине»: поместите главное ограничение в середину 60K токенов — и модель может выполнить все инструкции, кроме этой.
Вот как это происходит — на брифе из сорока инструкций:
Ограничение в 150 слов было инструкцией 20 из 40 — ровно в центре стопки. Модель безупречно выполнила инструкции 1, 2 и 40. Той, что в середине, для неё не существовало.
Против этого помогает порядок: самое важное (системный промпт, ключевые факты, жёсткие ограничения) ставьте первым, а самое свежее сообщение пользователя — последним. Если вам всё же нужно обработать огромный массив текста, разбейте работу на несколько вызовов и объедините результаты — иначе остаётся только надеяться, что середину прочитают.
Гниение: медленный распад в длинных сессиях
Гниение контекста (context rot) — это постепенное снижение качества в длинных сессиях. Сороковая реплика разговора тащит с собой отброшенный подход из двенадцатой, три устаревших допущения и сообщение об ошибке, которое никто не убрал. Каждый из этих элементов по отдельности выглядит безобидно; вместе они размывают у модели картину задачи. Симптомы: модель заново отвечает на уже решённые вопросы, путает старые и новые требования, становится медленнее и расплывчатее. Помогает то же, что и в предыдущем уроке: сжатие и новый старт, когда сессия становится длинной.
Противоречивые инструкции: тихая ничья
Старые инструкции остаются в контексте и голосуют наравне с новыми. Если системный промпт говорит «всегда отвечай в JSON», а двадцатая реплика истории — «вообще-то, с этого момента можно простым текстом», модель держит в голове оба правила и гадает, какое сегодня победит. Формат вывода плавает от запроса к запросу, и ничего не падает — всё просто тихо становится ненадёжным.
Предотвращайте это, обращаясь со старыми инструкциями как с кодом: никогда не добавляйте в историю «забудь всё, что я говорил раньше». Либо отредактируйте постоянную инструкцию (системный промпт, память), либо начните новую сессию с уже вшитым новым правилом.
Как обнаружить и предотвратить
- Читайте сам контекст. Логируйте весь запрос, отправленный модели, и разбирайте его, когда ответы идут не так: большинство сбоев видны с первого прочтения.
- Отслеживайте поиск. Для каждого ответа RAG записывайте, какие фрагменты были использованы. Нерелевантные фрагменты в логе обычно объясняют галлюцинацию.
- Оценивайте качество контекста быстро и дёшево: возьмите выборку реальных сессий и задайте три вопроса — всё ли в окне релевантно? лежит ли главный факт у краёв окна? нет ли двух конфликтующих инструкций? Если нужна автоматизация, пусть модель оценивает каждый контекст на релевантность и противоречия до отправки.
- Предпочитайте вычитание. Когда качество падает, убрать контекст почти всегда помогает быстрее, чем добавить ещё.
Ритуал отладки
Получили неверный ответ? Прежде чем переписывать промпт, достаньте точный контекст, который был отправлен, прочитайте его сверху вниз и спросите себя: что здесь ввело бы в заблуждение уставшего человека? Виновника вы найдёте за несколько минут.
Ваш RAG-бот работает плохо, и вы увеличиваете число найденных фрагментов с 5 до 25. Что обычно происходит?
Бот поддержки то и дело добавляет в правильные ответы лишние факты. Где, скорее всего, ошибка?
У вас три жёстких ограничения и бриф на 60 страниц. Куда поместить ограничения?
Формат вывода плавает от запроса к запросу, и ничего не падает. Наиболее вероятная причина:
Итог
Теперь у вас есть полный набор для работы с контекстом: вы знаете, что попадает в окно, как его хорошо заполнять и как оно ломается. Именно эти навыки нужны агентам: AI-агент — это модель плюс контекст, который она сама переписывает шаг за шагом.
Есть вопросы?
Присоединяйтесь к Telegram-каналу — с радостью обсудим проектирование контекста и поделимся примерами.