День сурка: секрет работы с LLM

Вы когда-нибудь отправляли в ИИ длинный запрос, а в ответе получали логичный и уверенный текст - но без ключевых деталей, ради которых вы это писали. Это не ваша ошибка. У любой LLM есть ограниченный зрительный угол: она не видит весь диалог целиком, она видит только то, что помещается в контекстное окно прямо сейчас.

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

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

Контекстное окно - это максимальный объем текста (в токенах), который модель может учитывать одновременно, когда формирует ответ. Туда попадает все, что модель видит в момент ответа:

• системные инструкции и правила поведения
• инструкции разработчика
• часть истории диалога
• текущее сообщение пользователя

Токены - это не слова. Это фрагменты текста: иногда слово целиком, иногда часть слова, иногда несколько символов. Поэтому два текста одинаковой длины в символах могут занимать разный объем в токенах.

Главная мысль тут простая: вы управляете ответом не количеством текста, а тем, какие именно фрагменты попадают в окно и насколько они плотные по смыслу.

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

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

Отсюда важное следствие: прошлое в диалоге не гарантировано. Поэтому опорные условия лучше держать в настоящем, в явном виде.

Когда текста больше, чем помещается, система обычно удерживает то, что сильнее всего влияет на правильность ответа.

Логика похожа на пирамиду важности:

• в первую очередь сохраняются системные инструкции и текущий запрос, то есть правила ответа и то, что нужно сделать прямо сейчас
• затем сохраняются явные требования и ключевые данные: критерии, запреты, числа, даты, параметры, списки условий
• далее идет контекст, который помогает, но не является критичным: примеры, пояснения, часть истории обсуждения
• в последнюю очередь остаются повторы и фрагменты, которые не влияют на результат

Внутри этого выбора обычно работают простые принципы:

• более свежие уточнения важнее старых, потому что цель могла измениться
• фрагменты, напрямую связанные с текущей задачей, важнее общего фона
• короткие списки требований часто важнее длинных описаний, потому что они точнее управляют ответом
• цифры, даты и конкретные условия важнее того, что можно восстановить логически
• если есть противоречия, приоритет обычно у более позднего уточнения или у явно обозначенного финального требования

Если одно сообщение само по себе превышает лимит, лишняя часть может быть обрезана еще до того, как модель начнет формировать ответ. Что именно будет обрезано - начало или конец - зависит от платформы.

Смысл простой: монолитные большие сообщения ненадежны. Если важное оказалось в обрезанной части, модель даже теоретически не может это учесть.