Оценка: 74/100 — КРЕПКИЙ СЕРЕДНЯК
TL;DR
Исследователи прогнали 12 языковых моделей через документы ООН длиной от 8 до 128 тысяч токенов на шести языках и проверили: как меняется точность модели, если задача становится крупнее — от поиска одного слова до пересказа целого документа. Оказалось, что модель, которая почти без ошибок находит конкретную цифру или дату в тексте, начинает "плыть", когда нужно понять роль целого предложения или абзаца в общей логике текста.
Главная боль: когда соседние предложения похожи по теме (одни и те же имена, даты, страны), модель цепляется за поверхностные сигналы — слова-связки типа "однако" или "поэтому", повторяющиеся названия — вместо того чтобы понять, какую функцию несёт предложение: это фон, объяснение или вывод. Вторая находка — тексты, которые модель генерирует (пересказ, заполнение пропуска), звучат гладко и убедительно, но реальные факты в них часто "уплывают" от исходника. Плюс — если дать модели список вариантов ответа, она чаще выбирает варианты, стоящие раньше в списке, независимо от содержания.
Метод, который тестировали в исследовании — не техника промптинга, а диагностический бенчмарк. Но из экспериментов вытекают конкретные приёмы работы с длинным контекстом: где физически размещать вопрос относительно нужного фрагмента текста, как не попасться на порядок вариантов ответа, и почему при пересказе документа нужно отдельно просить модель проверять факты.
Схема находок
НАХОДКА 1: Точность падает по мере роста задачи
слово → предложение → абзац → документ (точность снижается на каждом уровне)
НАХОДКА 2: Поверхностные сигналы обманывают модель
похожие соседние предложения → модель хватается за связки и повторы имён,
а не за реальную роль предложения (фон/вывод/объяснение)
НАХОДКА 3: Гладкость ≠ точность
пересказ/заполнение пропуска → текст читается хорошо → но факты не совпадают с источником
НАХОДКА 4: Расстояние между инструкцией и нужным местом в тексте влияет на точность
инструкция ближе к искомому фрагменту → точность выше
НАХОДКА 5: Порядок вариантов в multiple-choice создаёт смещение
вариант стоит раньше в списке → модель выбирает его чаще, вне зависимости от содержания
Пример применения
Задача: Юрист разбирает договор аренды коммерческого помещения на 40 страниц через Claude — нужно найти условие про штраф за досрочный расторг, которое спрятано где-то в середине документа, среди похожих пунктов про другие штрафы.
Промпт:
Вот договор аренды: {текст договора}
Раздел 7 "Штрафные санкции" (стр. 12-15) — найди в нём пункт
именно про досрочное расторжение договора арендатором.
Прежде чем дать ответ:
1. Процитируй сам пункт целиком
2. Объясни, почему именно этот пункт, а не соседние
(в разделе несколько похожих пунктов про другие виды нарушений)
3. Проверь цитату дословно против текста договора
Результат: Модель сначала процитирует найденный пункт, затем объяснит, чем он отличается от соседних похожих формулировок (не просто "нашла слово штраф", а разобрала функцию пункта). Явная просьба проверить цитату снижает риск, что модель "красиво перефразирует" вместо точной цитаты.
Почему это работает
Модель обучена предсказывать следующее слово, а не удерживать в голове "роль" каждого предложения в общей структуре текста. Поэтому ей проще опереться на лексическое сходство — те же слова, те же связки — чем держать в фокусе, зачем это предложение здесь стоит.
Сильная сторона модели — точный поиск конкретных фактов близко к тому месту, где стоит сам вопрос. Внимание модели устроено так, что информация рядом с инструкцией и в начале/конце текста обрабатывается лучше, чем информация в середине большого массива.
Метод использует это через позиционирование: если вопрос физически или логически приближен к нужному фрагменту (через явное указание "ищи в разделе X"), модель тратит меньше "внимания" на поиск и больше — на анализ. А явная просьба процитировать и сверить факт заставляет модель переключиться из режима "красиво написать" в режим "точно скопировать".
Рычаги управления: - Указание конкретного раздела/диапазона вместо "найди в тексте" → выше точность - Просьба процитировать перед ответом → меньше "уплывания" фактов - Перемешивание порядка вариантов в multiple-choice или просьба аргументировать перед выбором буквы → снижает order bias - Разбивка задачи на этапы (сначала найти факты, потом обобщить) → компенсирует слабость на уровне абзаца/документа
Шаблон промпта
Вот документ: {текст}
Мне нужно: {что найти или пересказать}
Если задача — найти конкретную информацию:
— Укажи, в каком разделе/части текста искать (не заставляй модель искать по всему документу)
— Попроси процитировать найденный фрагмент дословно перед ответом
Если задача — пересказ, заполнение пропуска или перевод:
— Добавь: "Проверь каждое утверждение против исходного текста.
Не добавляй факты, которых там нет"
Если задача — выбор из вариантов (A, B, C):
— Попроси сначала объяснить рассуждение по каждому варианту,
а потом назвать финальный ответ
— Или перемешай порядок вариантов перед отправкой
🚀 Быстрый старт — вставь в чат:
Я работаю с длинным документом: {опиши задачу}.
Помоги составить промпт, который учитывает три вещи:
1. Указание точного места в тексте, где искать нужную информацию
2. Требование проверять факты против источника при пересказе
3. Защиту от того, что ты выберешь вариант ответа просто потому что он первый в списке
Задавай вопросы, чтобы уточнить детали моей задачи.
Модель спросит, какой тип задачи (поиск / пересказ / выбор варианта) и насколько длинный документ — это нужно, чтобы понять, какие из трёх защитных приёмов применимы.
Ограничения
⚠️ Домен исследования специфичен: документы ООН — формальные, хорошо структурированные, с пронумерованными абзацами. На художественном тексте, переписке или неструктурированной странице сайта эффект инструкции-рядом-с-фрагментом может быть слабее.
⚠️ Часть находок не новые: recency bias (внимание к недавнему контексту) и order bias (предпочтение первых вариантов) — уже известные паттерны из прошлых исследований, MGAL их подтверждает, а не открывает.
⚠️ Языковой разрыв касается редких языков: разница между закрытыми и открытыми моделями заметна на языках с меньшим объёмом обучающих данных — для русского и английского пользователя это не так критично.
Как исследовали
Команда взяла пул из 70 000 отчётов ООН, отобрала около 4000 подходящих по структуре, и нарезала документы длиной от 8 до 128 тысяч токенов на шести официальных языках ООН — арабском, китайском, английском, французском, русском, испанском. Задачи размечали в четыре уровня: слово (найти ответ в тексте), предложение (восстановить пропущенное предложение из вариантов), абзац (сгенерировать пропущенный абзац) и документ (пересказать или перевести весь текст).
Черновики вопросов и ответов генерировал GPT-4, а затем два независимых человека-аннотатора вручную проверяли каждую пару вопрос-ответ — в бенчмарк попадало только то, что одобрили оба. Протестировали 12 моделей, включая GPT-5, Claude Sonnet 4, Gemini 2.5-Flash, Grok 4 и несколько открытых моделей.
Любопытная деталь: чтобы понять, почему на sentence-cloze задаче точность парадоксально выше для середины текста (а не только для начала/конца, как обычно бывает при recency bias), исследователи провели ручной анализ и обнаружили — это не признак хорошего понимания середины, а следствие того, что предложения в середине текста чаще содержат конкретные факты и повторяющиеся сущности, за которые легко "зацепиться" поверхностно.