Связывание вопросов и ответов при автоматической суммаризации

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

Установить соответствие между вопросами и ответами — значит заставить машину доказывать, что она ничего не присочинила и ничего не забыла.

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

Почему ROUGE уже не справляется с проверкой фактов

Старые добрые метрики вроде ROUGE-1, ROUGE-2 и ROUGE-L смотрят только на совпадение слов и коротких словосочетаний между оригиналом и пересказом. Нейросеть переставила местами полпредложения, заменила «выручка упала» на «доходы снизились», поменяла падежи — ROUGE поставит низкий балл и закричит «плохо», хотя смысл передан верно. Или обратный случай: модель аккуратно скопировала красивые обороты, но тихо убрала ключевую оговорку — фраза про падение выручки с оговоркой про пересмотр прогноза вверх превратилась в короткое «выручка упала», и ROUGE опять ничего не заметит, потому что формально тексты похожи по большей части слов.

Вот и получается, что для абстрактивной суммаризации, где модель переписывает текст своими словами и собирает его заново, такие метрики слепы на оба глаза. Им подавай дословные совпадения, а понимания смысла у них нет в принципе. Поэтому инженеры давно искали способ заставить алгоритм не просто считать буквы, а отвечать на вопросы по тексту — и сверять эти ответы между версиями. Так выделение QA-пар из текста постепенно стало самостоятельным подходом к оценке качества.

Механика QAGS: проверяем смысл через вопросы

В 2020 году на конференции ACL появилась метрика QAGS, и она сразу показала, куда двигаться всей индустрии. Идея элегантная до неприличия: берём готовое саммари, по нему автоматически генерируем несколько вопросов — обычно про ключевые сущности, цифры, имена и даты. Затем ищем ответы на эти вопросы дважды: один раз в самом саммари, второй — в исходном документе. Если ответы совпали — отлично, фактологическая согласованность на месте. Если разошлись — где-то закралась фальшь, и QA-алгоритм это поймал без труда.

QAGS превращает саммари в экзамен: модель должна ответить на те же вопросы, что и оригинал, иначе доверия нет.

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

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

Оценка полноты через ответы «да», «нет» и «не знаю»

Одной фактологической точности мало, и это понимает любой, кто хоть раз получал «честный» пересказ с выкинутыми подробностями. Можно ведь пересказать текст абсолютно корректно, но убрать половину важного — и формально не соврать ни в чём. Поэтому QA-подход умеет проверять ещё и полноту покрытия.

Здесь логика зеркальная: вопросы генерируются не по саммари, а по исходному документу. Считается, что оригинал — это надмножество всего важного, что вообще есть в материале. Дальше QA-модуль отвечает на эти вопросы дважды: по исходнику и по сжатой версии. И вот тут начинается самое интересное — три варианта ответа, у каждого свой диагноз:

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

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

От QuestEval к QUALS: как ускорить проверку в 55 раз

У QAGS нашлось слабое место — скорость. Прогонять по каждому саммари тяжёлую QA-модель, да ещё и вопрос-генератор в придачу, на больших корпусах текстов выходит дорого и медленно. Особенно когда речь идёт о потоке новостей или ежедневной обработке тысяч документов в корпоративном дайджесте. Поэтому в 2021 году подоспели два ответвления идеи, каждое со своим акцентом.

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

QUALS от команды исследователей Amazon пошёл другим путём — ускорил сам механизм. По открытым данным, им удалось выполнить QA-процедуру примерно в 55 раз быстрее по сравнению с базовым алгоритмом QAGS. Для тех, кто гоняет суммаризаторы на потоке из тысяч документов в день, это не приятный бонус, а насущная необходимость. Никакой красивый отчёт о качестве не спасёт, если проверка одного саммари занимает пять минут.

Если вы собираете свой пайплайн оценки — выбирайте метрику под задачу. Для исследовательских экспериментов и редких отчётов QAGS ещё вполне годится. Для новостной ленты в реальном времени — смотрите на QuestEval или QUALS. Для смешанных сценариев — комбинируйте: грубую фильтрацию ROUGE, глубокую проверку QA-модулем на финальном этапе.

QA-Align и объединение данных в многодокументных сводках

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

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

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

Что всё это значит для нас с вами

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

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

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