Настройка параметров суммаризации: 5 главных правил для длинных текстов

«Почему ИИ сделал аккуратную выжимку на полстраницы, но пропустил единственный пункт, ради которого я вообще загружала этот отчёт?» — вот вопрос, с которого обычно начинается настройка параметров суммаризации для длинных документов.

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

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

1. Управляйте длиной ответа, а не надейтесь на слово «кратко»

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

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

В системах на базе Transformers за верхнюю границу нового текста отвечает max_new_tokens. Этот параметр ограничивает именно количество токенов, которые модель создаст в ответе, не смешивая их с объёмом исходного запроса. Для дайджеста это обычно понятнее и предсказуемее, чем max_length, который относится к полной длине последовательности и во многом сохранён ради совместимости со старыми сценариями.

Нижнюю границу можно обозначить через min_new_tokens. Так модель не отделается двумя дежурными фразами, если документ действительно требует развёрнутой выжимки. Если одновременно выставлены min_length и min_new_tokens, приоритет получает именно второй параметр.

На пальцах разница выглядит так:

Но один лимит не заменяет задачу. Если вы просто скажете модели «до 500 токенов», она выберет то, что сама сочтёт главным. А это иногда заголовок и первая мысль автора — то есть ровно то, что вы и так уже видели.

Я бы формулировала запрос в два слоя:

1. Ограничение формы: сколько нужно пунктов, какой максимальный объём, нужен ли связный текст или маркированный список.

2. Приоритет содержания: какие сущности нельзя потерять — решения, суммы, сроки, противоречия, риски, цитаты, изменения по сравнению с прошлым периодом.

Например, вместо «Суммируй документ кратко» лучше попросить: «Сделай 8–10 тезисов. Сначала решения и обязательства, затем цифры и сроки, отдельно — риски и нерешённые вопросы. Не добавляй интерпретаций, которых нет в источнике».

Это не бюрократия. Это как заказать кофе: «что-нибудь вкусное» и «капучино на овсяном, без сиропа» — формально оба запроса понятны, но шанс получить именно свой напиток очень разный.

Краткость — не свойство модели и не комплимент промпту. Это заранее заданная рамка, внутри которой вы ещё объяснили, что нельзя выбрасывать.

Почему не существует универсальной «правильной» длины

Вопрос «какой объём выставить?» звучит разумно, но готового числа для всех случаев нет. Оно зависит от жанра исходника, языка, длины контекста конкретной модели и, главное, от назначения результата.

Новость о сделке можно сжать до нескольких строк. Протокол совещания требует сохранить, кто что обещал и к какому сроку. Научная статья без метода, ограничений и выводов часто становится опасно убедительной рекламной листовкой. А настройка суммаризации PDF-документов добавляет ещё один слой неприятностей: в файле могут быть колонтитулы, сноски, таблицы, сканы и плохо распознанный текст.

Поэтому не гонитесь за одним «идеальным» лимитом. Возьмите несколько типичных документов из своего потока, прогоните их в двух-трёх форматах и посмотрите, где ответ перестаёт быть полезным. Не по красоте фраз — по тому, сохранились ли ваши рабочие опорные точки.

2. Большое контекстное окно не спасает середину документа

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

Исследования длинного контекста показывают заметную уязвимость: модели лучше используют релевантные сведения, стоящие в начале или в конце входа, и хуже извлекают информацию из середины. Этот эффект получил говорящее название Lost in the Middle — «потеряно в середине».

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

Вот почему «модель всё прочитала» не равно «модель всё учла».

Как поймать потерянный факт до публикации

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

• Разметьте исходник по смысловым блокам. Не просто по страницам и не после каждого случайного количества символов. В отчёте это могут быть финансовые результаты, риски, прогноз, приложение; в расшифровке — темы встречи и принятые решения.
• Выберите 2–3 факта из центральной части. Цифра, условие сделки, исключение из правила, дата, формулировка возражения — то, что нельзя потерять без искажения смысла.
• Проверьте, появились ли они в итоговой выжимке. Если нет, не обязательно раздувать ответ. Иногда достаточно изменить инструкцию: «Удели отдельное внимание разделам 3–5» или «Не пропусти изменения в методологии и допущения».
• Повторите проверку на нескольких документах. Один удачный ответ не доказывает, что ваш пайплайн надёжен. Он доказывает лишь, что сегодня звёзды сошлись.

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

3. Делите длинный текст по смыслу, а не рубите его кухонным ножом

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

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

Подводные камни начинаются на границах.

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

Рабочая схема для длинных материалов

Для очень длинных текстов часто применяют иерархическую сборку:

1. Делят исходник на смысловые части.

2. Делают выжимку каждой части по одинаковому шаблону.

3. Собирают промежуточные выжимки.

4. Создают финальный дайджест из этой сборки.

5. Сверяют финал с критичными местами оригинала.

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

То есть «сделать summary из summary» — не преступление. Просто не надо делать это вслепую.

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

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

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

Что делать с таблицами, сносками и сканами в PDF

PDF — это не всегда текст. Иногда это красиво нарисованная коробка, внутри которой данные живут отдельной жизнью. При извлечении могут съехать колонки, исчезнуть примечания, перемешаться заголовки и значения. А сканированный документ сначала проходит распознавание — и уже там может превратить «0,1» в «01» или потерять знак процента.

Перед запуском суммаризации я бы быстро проверила:

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

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

4. Не лечите точность температурой

Настройка температуры модели для сжатия текста обросла примерно тем же количеством мифов, что и совет «положите телефон в рис». Температура действительно влияет на генерацию, но она не делает модель автоматически фактчекинговой и не управляет объёмом ответа.

Она меняет распределение вероятностей следующего токена. Если значение не задано в конфигурации конкретной модели, в документации Transformers используется значение по умолчанию 1.0. Рядом живут top_p, top_k, min_p и другие параметры отбора токенов. Они влияют на вариативность продолжения, а не знают, где в вашем отчёте правда, а где автор красиво сформулировал предположение.

Для суммаризации, где нужен воспроизводимый и аккуратный результат, обычно разумнее стремиться к более стабильной генерации, а не к творческому полёту. Но не стоит превращать это в догму «ставим минимальное значение — и всё идеально». Настройки зависят от модели, языка, промпта и типа исходников; универсальной нормы для новостных дайджестов или длинных статей никто честно не установил.

Полезнее разделить задачи параметров:

Промпт должен быть редакторским заданием, а не заклинанием

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

Я обычно добавляю четыре вещи:

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

Особенно полезна формулировка: «Для каждого ключевого тезиса укажи, к какому разделу документа он относится». Это не заменяет ссылку на первоисточник в опубликованном материале, но внутри рабочего процесса помогает быстро найти, откуда взялся вывод.

5. Не путайте похожесть на эталон с достоверностью

На этом месте хочется сказать неприятное: высокий ROUGE не доказывает, что выжимка правдива.

ROUGE сравнивает совпадения с эталонным текстом и может быть полезен для технического сравнения вариантов. Но фактическую согласованность с источником он не измеряет. Исследования длинных документов показывают, что оптимизация под более высокую релевантность по таким метрикам не обязательно делает summary более точным.

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

Для материалов, где цена ошибки высока, я бы проверяла не весь текст одним вопросом «ну, похоже?», а отдельные утверждения.

Как проверять выжимку без бесконечной ручной вычитки

Подход на уровне клауз — маленьких смысловых утверждений — даёт более устойчивую оценку фактической верности, чем оценка текста целиком. В исследовании LongEval такой переход заметно сократил разброс человеческих оценок: стандартное отклонение снизилось с 18,5 до 6,8.

В рабочем режиме это можно упростить до пяти вопросов к каждому важному тезису:

1. Есть ли утверждение в источнике буквально или по смыслу?

2. Не изменился ли субъект? Компания, ведомство, исследователь, участник встречи — это не взаимозаменяемые люди в очереди за кофе.

3. Сохранились ли числа, даты, единицы и сравнения?

4. Не исчезли ли ограничения? «Предварительно», «в отдельных регионах», «при выполнении условий», «по оценке компании».

5. Не склеила ли модель два соседних факта в новый, более удобный, но несуществующий вывод?

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

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

Настройка — это не один параметр, а привычка не доверять гладкому тексту

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

Дальше логика довольно земная:

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

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