← Все статьи

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

На 500 страницах документации полный контекст дал около 34% точности. Маленькая модель отбирает факты до дорогой.

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

Коротко

Андрей Бирюков на «Хабре» показывает, почему длинный контекст не отменяет подготовку текста. На 500 страницах сетевой документации модель, которой отдали всё сразу, ответила верно примерно в трети случаев и ещё собрала несуществующие маршруты из адресов по краям документа. Его приём — дешёвая модель сначала вытаскивает факты, а дорогая видит короткое резюме в начале и самый важный кусок в конце.

Что произошло

Повод знакомый: когда объявили контекст на миллионы токенов, многим показалось, что поиск по кускам можно выбросить и скормить модели весь архив. На практике внимание держит начало и конец сильнее середины. Бирюков сравнивает это со студентом перед экзаменом: первые и последние страницы выучены, середина размыта. Контекст огромный, а вопрос по документу на сто страниц модель отвечает хуже, чем меньшая модель с коротким окном. Он называет это свойством архитектуры внимания, а не случайной ошибкой.

Проверка устроена так. Пятьсот страниц документации по сетевому оборудованию — журналы, адреса, версии прошивок — разрезаны на пять частей по сто страниц. Десять вопросов, ответы на которые лежат только в средней части. Полный контекст GPT-4o: точность около 34%, первый токен примерно через 14 секунд, плюс выдуманные маршруты из адресов крайних частей. Наивный поиск пяти ближайших кусков поднял точность примерно до 42% и ответил за чуть больше секунды — быстро и всё ещё часто мимо, потому что связь между кусками пропала. Укрупнение кусков до десяти тысяч токенов, пишет он, только переносит ту же «забытую середину» внутрь куска.

«Семантический привратник» устроен как младший помощник при дорогом специалисте. Роль помощника — Mistral-7B-Instruct в 4-битной квантизации, вывод через vLLM. Сначала грубый векторный поиск берёт не пять, а пятьдесят кусков. Каждый кусок модель оценивает от нуля до единицы, вытаскивает три факта и отвечает JSON, без связного пересказа. Всё, что ниже 0,6, отбрасывают, из остатка берут десять лучших и кладут их по убыванию важности, а не в порядке документа. В начало запроса — сжатые конспекты этих десяти кусков, около двух тысяч токенов. В конец — самый релевантный кусок целиком, без сжатия. Важные факты оказываются в обеих зонах, где внимание сильнее.

В его сводной таблице на тысячу запросов картина такая. Полный контекст: около 180 тысяч токенов, 34,2% точности, 14,5 секунды, 180 долларов. Наивный поиск: около 8 тысяч токенов, 41,1%, 1,4 секунды, 15 долларов. RAPTOR: около 12 тысяч токенов, 49,7%, 5,2 секунды, 40 долларов. Привратник: около 9 тысяч токенов, 68,4%, 3,8 секунды, 22 доллара. Прогон через Mistral-7B занял 2,4 секунды, зато запрос к GPT-4 стал примерно в двадцать раз короче и сэкономил около десяти секунд. 22 доллара против 180 — это и есть экономия примерно в восемь раз на его тарифах.

Почему это важно

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

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

На практике

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

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

  1. Не скармливайте весь архив только потому, что окно это позволяет: проверьте вопросы к середине документа.
  2. Отделяйте извлечение фактов от ответа: дешёвая модель пусть возвращает оценку и факты в JSON, без пересказа.
  3. Берите с запасом на грубом поиске, затем отсекайте слабые куски и сортируйте остаток по важности, а не по порядку страниц.
  4. Кладите сжатое резюме в начало запроса и самый важный исходный кусок — в конец.
  5. Считайте не только точность, но и токены, время до первого ответа и деньги на тысячу запросов, как в его таблице.

Итог

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

Комментарии

Загрузка комментариев…