Почему модель тупеет на больших документах

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

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

Как выглядит проблема

Четыре симптома, по которым её узнают.

Ответ становится общим. Вместо «в пункте 7.3 указано 10 рабочих дней» — «сроки указаны в разделе об ответственности».

Детали из середины пропадают. Факт, который точно есть в документе, в ответе не появляется. На прямой вопрос «есть ли там про X» модель отвечает, что не нашла.

Начало и конец пересказываются уверенно. Первые страницы и последние модель воспроизводит подробно, будто документ состоял только из них.

Противоречия не называются. Если в документе два несовместимых утверждения, в ответе окажется одно, третье или усреднённое — но не сообщение о расхождении.

Внимание распределяется неравномерно

Это основной эффект, и он наблюдается устойчиво у разных семейств моделей и разных поколений.

Модель не читает документ последовательно. Она получает его целиком и распределяет внимание по всему объёму сразу. Распределение это не равномерное: края ввода обрабатываются надёжнее середины, и чем длиннее ввод, тем заметнее провал посередине.

Практическое следствие, которое ломает интуицию: факт, формально переданный модели, может не участвовать в ответе. Он есть в запросе, он оплачен, он не участвует.

Отсюда простое правило размещения. Если в длинном вводе есть то, что важнее всего — инструкция, определение, ключевой пункт, — место для него в начале или в конце, а не в середине. Это не исправляет эффект, а обходит его.

Лишний контекст разбавляет сигнал

Второй эффект, и он не про место, а про пропорцию.

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

Из этого следует то, что противоречит привычке «дам побольше, разберётся сама»: лишний контекст не нейтрален. Он не лежит «на всякий случай» — он ухудшает ответ, причём заметно раньше, чем упирается в лимит окна. Состав запроса и то, что в него попадает помимо вашего вопроса, разобраны в статье что такое контекстное окно.

Противоречия внутри длинного текста модель сглаживает

Отдельный эффект, который дороже остальных, потому что на выходе выглядит как уверенный корректный ответ.

Длинный документ часто внутренне несогласован: старая редакция рядом с новой, приложение противоречит основному тексту, в протоколе сказано одно, а в договоре другое. Человек в такой ситуации останавливается и спрашивает. Модель по умолчанию формулирует одну связную версию.

Причина прозаичная: её попросили ответить на вопрос, а не проверить согласованность источника. Связность ответа — это то, к чему её приводили при обучении.

Чинится постановкой задачи. Вопрос «какой срок указан» даёт одну цифру. Вопрос «перечисли все места, где указан срок, с цитатами и номерами пунктов, и отметь расхождения» даёт список, по которому видно, что источник противоречив. Это же основной способ ловить галлюцинации нейросети на длинных материалах.

Почему это не лечится сменой модели

Переход на модель дороже или с большим окном сдвигает порог, на котором проблема становится заметной. Он её не убирает.

Заявленный размер окна говорит ровно одно: при каком объёме запрос будет отклонён. Про качество по дороге к пределу он не обещает ничего. Разбор ориентиров по типам задач — в статье сколько контекста нужно на деле.

Отсюда практический вывод: прежде чем платить за старшую позицию, стоит проверить, не решается ли задача сужением входа на текущей. Сравнивать модели имеет смысл на своём замере, а не по чужим таблицам — методика в материале как сравнивать модели.

Что делать: сузить вход до относящегося к делу

Самый результативный приём из всех, и почти всегда самый дешёвый.

Если вопрос про раздел 7, не отправляйте все сто страниц. Отправьте раздел 7. Качество растёт, счёт падает, эффект середины не наступает, потому что середины нет.

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

Что делать: спрашивать по частям и сводить

Когда сузить вход нельзя — например, нужен обзор всего документа, — задача разворачивается в два этапа.

Сначала одинаковый вопрос задаётся к каждой части по очереди: «что в этом фрагменте относится к срокам поставки, цитатой». Затем собранные ответы подаются отдельным запросом на сведение: «вот двенадцать выписок, собери сводную картину и отметь расхождения».

Так каждый проход работает на коротком вводе, где эффект середины не проявляется. Платите вы за это числом запросов, а не качеством.

Что делать: требовать цитату под каждым утверждением

Дисциплинирующий приём, который заодно превращает проблему в видимую.

Формулировка в промпте: «под каждым утверждением приведи дословную цитату из документа и номер раздела; если подтверждения в тексте нет — напиши "не найдено"».

Что это даёт: утверждение без цитаты сразу видно. Модель, которой нечего процитировать, либо честно отвечает «не найдено», либо приводит цитату, которой в документе нет, — и это обнаруживается поиском по файлу за секунду. Без такого требования обе ситуации выглядят одинаково уверенно.

Как проверить это на своих данных

Замер на вечер, без библиотек и без стенда. Идея одна: подложить факт с заранее известным ответом и посмотреть, найдётся ли он.

1. Возьмите свой реальный документ — тот, на котором проблема и проявляется.
2. Придумайте контрольный факт, которого в тексте нет и который ни с чем не спутать. Например: «Ответственный за приёмку — Кузнецов И. П., внутренний номер 4417».
3. Сделайте три копии файла: с этим фактом в начале, в середине и в конце.
4. Задайте по каждой копии один и тот же вопрос: «кто ответственный за приёмку и какой у него внутренний номер».
5. Повторите каждый прогон трижды. Ответы модели не детерминированы, разовый результат ничего не значит — про это есть отдельный разбор: почему модель отвечает по-разному.
6. Повторите весь цикл на укороченном документе — например, вчетверо короче. Так вы увидите не только разницу по позициям, но и порог, с которого она появляется.

Что смотреть в результатах:

Этот замер стоит копейки и делается на любой текстовой позиции. В KeyDealer один ключ открывает весь каталог — 57 позиций в живой выдаче, 44 доступны, — поэтому прогнать один и тот же список вопросов на дешёвой модели за 1 ₽ за миллион токенов и на старшей за 30 ₽ можно без второй интеграции и без второго договора. Пять текстовых позиций с нулевой ставкой открываются после первого платного пополнения и дальше не тарифицируются — черновые прогоны удобно гонять на них.

Частые ошибки, которые усиливают эффект

Складывать в запрос всё, что есть по теме. Привычка «пусть лучше будет» работает против вас: посторонние разделы конкурируют с нужным за внимание.

Прятать инструкцию в середину. Системный промпт и требования к формату должны стоять с краю. Инструкция, зажатая между двумя документами, выполняется хуже.

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

Делать вывод по одному прогону. Ответы не детерминированы: один удачный результат не доказывает, что проблемы нет, а один неудачный — что она есть.

Считать, что раз влезло, значит работает. Отсутствие ошибки о превышении длины ничего не говорит о качестве ответа.

Чего мы не утверждаем

Мы не называем процентов и не ссылаемся на исследования. Всё описанное — воспроизводимое наблюдение, которое вы можете подтвердить или опровергнуть на своих данных описанным выше способом. Если ваш замер покажет иное — верьте своему замеру.

Порог деградации мы не знаем заранее. Он зависит от модели, языка, типа текста и формулировки вопроса. Общей цифры «после стольких-то токенов становится плохо» не существует.

Приёмы выше не гарантируют точности. Они уменьшают вероятность потери факта и делают потерю заметной. Проверка ответственных выводов человеком остаётся обязательной.

Что нужно, чтобы попробовать

Ключ заводится за минуту на keydealer.ru/login — почта и пароль, без документов и без зарубежной карты. Оплата российской картой в рублях, один ключ на весь каталог.

Ставки и статусы видны в GET /v1/models без ключа и без регистрации. Замер из раздела выше — это восемнадцать запросов: три позиции факта, три повтора, две длины документа. На дешёвой позиции это несколько рублей и один вечер.

Что держать в голове

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

Противоречия в длинном документе модель по умолчанию сглаживает, а не называет. Если вам нужны расхождения, их надо запросить прямо и с цитатами.

Про свои данные знает только ваш замер. Контрольный факт в середине документа, три повтора и два размера файла дают больше, чем любая внешняя таблица сравнений.

Как мы проверяем факты и что храним из запросов — на странице о проекте и в llms.txt. Собрать свой замер: keydealer.ru/login.