Соответствие вопросов и ответов: алгоритмы ИИ-сжатия

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

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

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

QA-подход: не «угадай слово», а «докажи ответ источником»

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

Логика довольно человеческая. Допустим, исходная новость сообщает: компания рассматривает запуск сервиса в нескольких регионах во втором полугодии. Суммаризатор пишет: компания запустит сервис по всей стране в сентябре.

Тематически фразы рядом: компания, сервис, запуск, сроки. Но если задать точные вопросы, картинка распадается:

• Что именно сделает компания: рассматривает запуск или уже запускает?
• Где это произойдёт: в нескольких регионах или по всей стране?
• Когда: во втором полугодии или именно в сентябре?
• Есть ли в источнике подтверждение, что решение уже принято?

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

Исследовательская метрика QAGS, опубликованная в 2020 году, построена именно на этой идее. Она генерирует вопросы по итоговому резюме и проверяет, даст ли исходный документ сходные ответы. Если в дайджесте сказано, что «министр назвал сумму», а в оригинале этой суммы нет или её назвал другой человек, расхождение должно проявиться в вопросно-ответной паре.

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

Хорошее резюме не просто похоже на источник. Оно выдерживает неудобные вопросы к каждому своему факту.

Как выглядит выделение пар «вопрос—ответ» нейросетью

Упрощённо алгоритм поиска ответов в тексте проходит четыре шага.

1. Выделяет проверяемые утверждения.

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

2. Превращает утверждение в вопрос.

Из фразы «регулятор продлил срок подачи заявок до 15 мая» получаются вопросы: «Кто продлил срок?», «Что именно продлили?», «До какой даты?». Это и есть автоматическое выделение пар вопрос—ответ, только не в виде таблицы для урока, а как проверочная сетка для фактов.

3. Ищет ответ в исходнике.

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

4. Сопоставляет ответы.

На последнем шаге система решает, согласуются ли «15 мая» и «до середины мая», «регулятор» и «профильное ведомство», «временно приостановили» и «отменили». Именно здесь начинается работа со смыслом, а не с буквами.

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

Почему ROUGE и BERTScore не закрывают вопрос

Долгое время автоматическую оценку суммаризации часто связывали с ROUGE. Эта метрика появилась ещё в 2004 году и сравнивает пересечения между автоматическим и эталонным текстами: слова, n-граммы, общие фрагменты.

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

BERTScore идёт дальше: он сопоставляет не точные совпадения слов, а контекстные представления токенов. Это лучше работает с перефразировками. Например, «сократила штат» и «уволила часть сотрудников» семантически ближе, чем кажется при механическом сравнении слов.

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

В работе QuestEval, опубликованной в 2021 году, как раз предложили оценивать резюме через вопросы и ответы без обязательной привязки к одному «идеальному» эталонному пересказу, написанному человеком. Это важный поворот: для новости часто существует не один правильный краткий вариант, а несколько. Один редактор вынесет в лид цифру, другой — решение суда, третий — реакцию рынка. И все трое могут быть точны.

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

QAGS, QuestEval и FactCC: три разных способа поймать искажение

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

QAGS: спрашивает резюме и сверяется с первоисточником

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

Представим заметку: «Совет директоров рекомендовал акционерам одобрить сделку». Из неё система может вытащить:

• Кто рекомендовал одобрение?
• Кому адресована рекомендация?
• Что именно предлагается одобрить?
• Это решение уже принято или пока только рекомендация?

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

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

QuestEval: проверяет покрытие с обеих сторон

QuestEval работает шире. Он задаёт вопросы так, чтобы оценить не только то, подтверждается ли содержание резюме источником, но и не потеряло ли резюме существенные факты из оригинала.

Это два разных риска, которые часто смешивают:

• Лишнее утверждение: в дайджест добавили факт, которого нет в источнике.
• Пропущенный факт: дайджест ничего не выдумал, но выкинул главное — например, условие сделки, исключение из правила или причину решения.

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

QA-подход хорош именно тем, что умеет работать с вопросами вида «что сказано в резюме?» и «что значимое осталось в источнике?». На пальцах: он проверяет и то, не принёс ли курьер чужой пакет, и то, не забыл ли ваш.

FactCC: разбирает резюме по предложениям

FactCC, представленная в 2020 году, формулирует задачу иначе. Она оценивает, согласовано ли конкретное предложение резюме с источником, и пытается выделить фрагмент источника, который это решение подтверждает. Если предложение не согласовано, система также ищет конфликтующий кусок внутри самого резюме.

Это близко к редакторской привычке проверять текст построчно. Не «дайджест в целом выглядит разумно», а: вот предложение про сумму — где подтверждение? Вот фраза про срок — она следует из документа или автор чуть-чуть разогнался?

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

Чем короче дайджест, тем дороже каждое слово, которое он добавил от себя.

FRANK: ошибка — это не всегда просто «да» или «нет»

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

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

FRANK использует шкалу фактичности от 0 до 1 наряду с бинарными метками. Но я бы не превращала такой балл в единственный пропускной пункт. Универсального отраслевого стандарта с обязательной QA-метрикой и единым проходным порогом для новостных дайджестов нет. Особенно нельзя механически переносить результаты англоязычных исследований на русскоязычный новостной поток: язык, стиль источников, морфология, имена и редакционные форматы здесь заметно меняют картину.

Логическое следование важнее одинаковых слов

Самое коварное место в сопоставлении вопросов и ответов ИИ — случаи, когда ответы похожи на поверхности, но не совместимы логически.

Возьмём три фразы:

1. «Переговоры могут возобновиться в июне».

2. «Переговоры возобновятся в июне».

3. «Переговоры не возобновятся в июне».

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

Для этого используют подходы, связанные с NLI — natural language inference, или логическим выводом. Система оценивает, следует ли одно утверждение из другого, противоречит ему или не получает достаточной опоры.

В исследовании Q², посвящённом проверке фактичности диалогов, ответы сопоставляли именно через NLI, а не простое совпадение токенов. Для суммаризации принцип тот же: важны не только слова «сделка», «компания» и «апрель», но и отношения между ними.

Что NLI особенно помогает не пропустить

• Отрицания. «Не подтвердил» и «подтвердил» отличаются четырьмя буквами, а для новости — всем.
• Модальность. «Планирует», «готова», «обязана», «может», «рассматривает» нельзя безнаказанно склеивать в одно «сделает».
• Роли участников. Инвестор предложил, совет рекомендовал, акционеры должны утвердить — участники близки по сюжету, но функции разные.
• Причины и следствия. Падение спроса могло совпасть со снижением выручки, но не обязательно стало его причиной.
• Числовые ограничения. «До 10%», «на 10%», «не менее 10%» и «около 10%» — не взаимозаменяемые фразы, как бы ни хотелось уместить их в один короткий лид.

QAFactEval, работа 2022 года, аккуратно раскладывает поле на два основных направления: методы на основе логического следования, то есть entailment/NLI, и методы на основе вопросов и ответов. На практике это не конкуренты в духе «выберите одного». Скорее два фонарика, которые светят под разными углами.

QA спрашивает: «Какой ответ даёт источник на этот вопрос?»

NLI уточняет: «Подтверждает ли источник именно это утверждение или оно ему противоречит?»

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

Где автоматическая проверка всё ещё спотыкается

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

Не получится. ИИ-проверка помогает быстро отсеивать очевидно слабые или подозрительные фрагменты, но не отменяет ручной контроль.

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

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

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

Наконец, автоматический балл нельзя читать как оценку «правдивости вообще». Высокий результат QA-проверки говорит, что модель хорошо прошла конкретную процедуру сопоставления вопросов и ответов. Это полезный сигнал, но не сертификат безошибочности. ROUGE, BERTScore, QAGS, QuestEval, NLI-модель — каждый инструмент измеряет свой кусок реальности.

Как я бы выстроила проверку дайджеста на практике

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

1. Сначала отделить факты от интерпретаций.

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

2. Сгенерировать вопросы к каждому плотному утверждению.

Особенно к датам, суммам, именам, географии, статусам решений и словам-маркерам неопределённости.

3. Найти доказательные фрагменты в источнике.

Не просто похожий абзац, а участок, который действительно отвечает на вопрос. Если такого участка нет, утверждение получает красный флажок.

4. Проверить смысловую совместимость.

Здесь нужны NLI-проверка или аналогичная логическая оценка: не потерялось ли отрицание, не сменился ли субъект, не превратилась ли гипотеза в факт.

5. Отправить человеку только рискованные места.

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

6. Собирать собственный набор ошибок.

Не абстрактный «качество 87%», а живую коллекцию: путает должности, сглаживает модальность, объединяет разные периоды, неверно сокращает проценты. Через несколько недель станет видно, где именно ваш суммаризатор наступает на одни и те же грабли.

Не ищите одну идеальную метрику

Вопросно-ответная проверка — один из самых разумных способов держать ИИ-сжатие в рамках источника. Она заставляет резюме отвечать за собственные утверждения: не прятаться за гладкостью языка, не прикрываться похожими словами, не выдавать догадку за новость.

Но я бы не доверяла ни одной цифре в одиночку. ROUGE показывает текстовое сходство, BERTScore ловит перефразирование, QA-метрики проверяют ответы на вопросы, NLI смотрит на логическую совместимость, а человек замечает то, что пока не уложилось в модель: контекст, интонацию источника, скрытое условие и ту самую разницу между «обсуждают» и «решили».

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