Модель, которой отдали договор на сорок страниц целиком, уверенно ответит про предмет и реквизиты и промолчит про штраф на двадцатой странице — а платить по нему будете вы. Это не поломка и не признак слабой модели, а следствие того, как устроено контекстное окно: объём, который модель держит перед глазами за один раз, и внимание к нему распределяются неравномерно. Ниже — механика без формул, где это стоит денег и как построить процесс, чтобы важный пункт не выпадал.
Контекстное окно — рабочий стол, а не память
Контекстное окно — это максимальный объём текста, который языковая модель обрабатывает за один запрос. Сюда входит всё сразу: ваша инструкция, приложенный документ, история переписки и ответ, который модель сейчас пишет. Измеряется окно в токенах — кусочках слов. Для русского текста грубый ориентир — полтора-два токена на слово, но точное число зависит от модели, и его проще посчитать встроенным счётчиком, чем угадывать.
Руководителю проще всего представить окно как рабочий стол. На стол помещается ограниченное число бумаг, и всё, что на нём лежит, делит одно место: чем больше разложено документов, тем меньше места, чтобы писать. Модель ничего не «помнит» между запросами — всё, что должно участвовать в ответе, должно лежать на столе прямо сейчас.
Первое следствие, которое обычно упускают: окно расходуется совместно. Если приложен большой документ и диалог длится давно, места на ответ остаётся меньше — и ответы становятся короче и беднее без видимой причины. Люди в этот момент думают, что модель «устала», а она просто упёрлась в край стола.
Середина проседает: что об этом известно
Модель обрабатывает текст не одинаково внимательно. Начало и конец получают больше внимания — так работает механизм, который решает, на какие части опираться при ответе. Середина длинного текста оказывается в зоне наименьшего внимания, и информация оттуда используется хуже, даже если формально поместилась. Эффект описан в исследовании «Lost in the Middle» (Нельсон Лю и соавторы, Стэнфорд, 2023): точность ответа заметно падала, когда нужный факт стоял в середине длинного контекста, а не в его начале или конце.
Новые модели с тех пор стали держать длинный текст лучше, и спорить о том, насколько, можно долго. Для бизнеса важен другой вывод, и он пока не устарел: факт, попавший в контекст, не равен факту, который будет использован. «Мы всё загрузили» не означает «модель всё учла». Проверять это нужно на своих документах, а не по таблице из пресс-релиза.
Где потеря середины стоит денег
Длинные договоры. Модель отвечает про предмет договора и реквизиты, но пропускает пункт об ответственности или об автопролонгации, стоящий в середине. Цена ошибки — не неточный пересказ, а неучтённая неустойка или пропущенный срок расторжения.
Долгие диалоги с ассистентом. На тридцатом сообщении модель «забывает» условие, названное на пятом: «цены без НДС», «клиент из другого региона». Формально оно ещё в окне, фактически — в зоне низкого внимания, и расчёт в конце переписки получается неверным.
Пакетная обработка. Когда в один запрос кладут двадцать обращений клиентов сразу, первые и последние разобраны заметно подробнее, чем те, что в середине пачки. Жалоба, оказавшаяся десятой, может так и не попасть в отчёт.
Всё по клиенту в одном запросе. Звонки, переписка и карточка из CRM складываются вместе в надежде на «полную картину». Картина получается, но собранная из того, что лежало с краю.
Сколько на самом деле помещается в окно
Считать в страницах удобнее, чем в токенах, поэтому вот грубые ориентиры для русского текста — порядок величины, а не норматив. Страница договора формата А4 — примерно 500–700 токенов. Часовой телефонный разговор в расшифровке — от 6 до 9 тысяч. Переписка в мессенджере за месяц по одному клиенту — обычно в пределах 3 тысяч.
Отсюда условный расчёт: если у модели окно в 32 тысячи токенов, туда войдёт договор на сорок страниц (20–28 тысяч) или три часовых разговора (18–27 тысяч) — но не то и другое сразу, и без запаса на инструкцию с ответом. Именно здесь ломаются наивные схемы вида «сложим в один запрос всё, что есть по клиенту».
Отдельная тонкость: русский текст у многих моделей расходует токены быстрее английского при том же смысле. Оценки объёма из англоязычных руководств поэтому к нашим задачам напрямую не переносятся — пересчитайте на своём документе.
Четыре приёма, с которых я бы начинал
1. Не грузить всё, а искать нужное. Вместо того чтобы класть в запрос весь документ, сначала находят относящиеся к вопросу фрагменты и передают модели только их. Как это устроено, мы разбирали в статье про то, как AI находит ответ в документах. Побочный эффект приятный: запрос становится в разы дешевле, потому что вы не платите за нерелевантные страницы.
2. Ставить важное в начало и в конец. Инструкция — в начале, ключевое требование — повторить в конце. Выглядит как костыль, но работает стабильно и ничего не стоит.
3. Резать на части с перекрытием. Длинный документ обрабатывается кусками, каждый со своим запросом, с небольшим нахлёстом между кусками, чтобы не потерять смысл на стыке. Результаты сводятся отдельным шагом.
4. Проверять пропуски целенаправленно. Если задача критична, задайте контрольный вопрос по факту из середины документа. Отвечает верно — схеме можно доверять; нет — резать на части.
Порядок не случайный. Первый приём решает больше всего, но требует настройки поиска. Второй и четвёртый можно применить сегодня в обычном чате, без разработки.
Проверочный факт в середине документа
Ответ модели звучит одинаково уверенно и когда она нашла нужное место, и когда достроила его из общих соображений. Отличить одно от другого можно приёмом, который стоит минуты.
Спрячьте в середину документа проверочный факт — нетипичную формулировку или число, которого не может быть в других документах. Затем спросите о нём. Если модель отвечает верно, середина действительно попадает в обработку; если отвечает общими словами или ошибается, вы нашли границу, за которой ответам верить нельзя.
Второй, более практичный вариант — требовать цитату. Запрос «приведи точную цитату, на которой основан ответ, и укажи раздел» переводит проверку в разряд механических: цитата либо есть в документе, либо нет, и это ищется поиском по тексту за секунду. Почему без такой опоры модель уверенно достраивает недостающее, разобрано в статье о том, почему нейросеть выдумывает.
Почему тот же вопрос завтра даёт другой ответ
Сильнее всего доверие подрывает ситуация, когда тот же вопрос по тому же документу даёт разные ответы в разные дни. Причин обычно две, и обе устранимы.
Первая — ответ модели не строго детерминирован, и на длинном документе разброс заметнее: чем больше материала, тем больше вариантов, какие фрагменты счесть важными. Вторая, более частая: изменился не вопрос, а контекст вокруг него — в диалоге накопилась история, и она вытеснила часть документа из зоны внимания.
Лечится это тем же, чем и потеря середины. Задавайте вопрос в чистом диалоге, а не в конце длинной переписки. Передавайте только относящийся к делу фрагмент. И просите цитату — она дисциплинирует ответ сильнее любых настроек.
Резать по пунктам, а не по символам
Механическое деление на куски равного размера — самый быстрый способ получить систему, которая уверенно отвечает не на тот пункт. Разрыв посередине предложения или между условием и исключением из него делает фрагмент бессмысленным или, хуже, переворачивает смысл.
Резать нужно по структуре документа: по пунктам, разделам, статьям. Заголовок раздела при этом остаётся с каждым фрагментом, иначе фраза «в этом случае применяется повышенный тариф» ничего не значит в отрыве от того, о каком случае речь.
Проверить разбивку просто: прочитайте пять случайных фрагментов и спросите себя, понятно ли из каждого, о чём он. Если непонятно вам, модели тоже.
Таблицы и допсоглашения выпадают первыми
При переводе таблицы в плоский текст структура рассыпается: столбцы склеиваются, заголовки отрываются от данных, а сноска под таблицей перестаёт относиться к своей строке. Первое, что помогает, — не отдавать таблицу картинкой и не превращать её в сплошной текст: разметка, где явно видны строки и столбцы, обрабатывается заметно лучше. Второе — дублировать заголовки столбцов в каждой строке, если таблица длинная.
Приложения и дополнительные соглашения — вторая частая потеря. Формально это отдельные документы, по смыслу они меняют основной, и ответ по одному основному тексту оказывается неверным. Правило простое: если документ менялся дополнениями, в обработку идёт весь комплект, а не последняя редакция основного файла.
Большое окно покупает объём, а не внимание
Модели с огромным окном создают ощущение, что проблема решена: влезает всё, значит, можно не думать. Два ограничения остаются. Внимание по-прежнему распределяется неравномерно, а стоимость запроса растёт вместе с объёмом — вы платите за каждый токен, включая девяносто страниц, которые к вопросу отношения не имели.
Моя позиция здесь простая: в рабочих системах почти всегда выгоднее аккуратный отбор фрагментов, чем «загрузим всё и понадеемся». Это не экономия ради экономии — короткий точный контекст даёт и более точные ответы, и ответ, который можно проверить по цитате.
Когда отбор фрагментов городить не нужно
Честно о границах. Если документ короткий — договор на пять страниц, одна переписка, один звонок, — он целиком лежит в зоне уверенного внимания, и никакой поиск фрагментов не нужен: достаточно хорошей инструкции и просьбы о цитате. Не окупится настройка и там, где ошибка ничего не стоит: черновик письма, пересказ статьи для себя, мозговой штурм.
И наоборот: если на ответе модели принимается решение с деньгами — подписать договор, выставить претензию, отказать клиенту, — ни большое окно, ни поиск не отменяют человека, который сверяет цитату с оригиналом. В проектах 404ai мы с этого и начинаем разговор: какое решение будет приниматься по ответу и сколько стоит ошибка в нём. От этого зависит, нужна ли сложная обработка документов или хватит проверочного вопроса.
Что проверить на своём документе, прежде чем доверять ответам
Главное, что меняет знание о контекстном окне, — вопрос к любому инструменту для работы с документами звучит не «сколько страниц он принимает», а «откуда в ответе этот факт». Возьмите один свой длинный документ, в котором вы точно знаете содержание, задайте три вопроса по середине и потребуйте цитаты. Если хотя бы один ответ ушёл в общие слова, процесс нужно строить через отбор фрагментов и проверку, а не через «загрузить целиком». Если все три точные — для этого типа документов можно двигаться дальше, повторяя проверку при смене модели.
