Все числа на месте, а смысл изменился: как проверять правки ИИ

Анна получила 30 000 рублей. Борис получил 50 000 рублей.

После редактуры:

Анна получила 50 000 рублей. Борис получил 30 000 рублей.

Оба имени на месте. Обе суммы тоже. Только деньги достались не тем людям.

Это нарочно грубый пример: ошибку ^[1] видно сразу. Но если проверять текст по списку сохранившихся имён и чисел, придраться не к чему. Именно поэтому ответ «факты сохранены» требует уточнения: что проверка считает фактом?

Я развиваю humanizer-ru ^[2], набор инструкций и утилит для работы с текстом. Одна из утилит сравнивает две версии: ищет потерянные и добавленные числа, отрицания и другие извлекаемые элементы. В примере с Анной и Борисом версия 3.36.4 не обнаружила различий среди извлекаемых элементов.

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

Один абзац, одно потерянное условие

Исходник:

Экспорт доступен на тарифе Pro при включённой двухфакторной аутентификации. Ссылка на архив действует 30 дней. Сервис не сохраняет исходный текст.

Допустим, в ответ на просьбу сократить текст получился такой вариант:

Экспорт доступен на тарифе Pro. Ссылка на архив действует 30 дней. Сервис не сохраняет исходный текст.

Читается гладко. Условие о тарифе осталось, срок не изменился, обещание не хранить исходный текст тоже на месте. Исчезло условие о двухфакторной аутентификации. Пользователь купит Pro, откроет экспорт и обнаружит требование, о котором инструкция промолчала.

Проверку можно начать с четырёх утверждений исходника:

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

В примере с выплатами список был бы совсем коротким: «Анна получила 30 000» и «Борис получил 50 000». Он сразу показывает ошибку, которую перечень имён и сумм пропускает.

Что сказала программа

Для повторения ^[3] сохраните исходный абзац в before.txt, а сокращённый вариант — в after.txt. Оба файла должны быть в UTF-8.

python -m pip install humanizer-ru==3.36.4
humanizer-facts diff before.txt after.txt --no-additions --json

В отчёте вернулись нули в lost, added и changed, а поле identical получило значение true:

{
  "counts": {
    "lost": 0,
    "added": 0,
    "changed": 0
  },
  "identical": true
}

counts содержит количество найденных расхождений среди извлекаемых элементов, а identical показывает, обнаружены ли такие расхождения. Сами файлы при этом различаются. Условие доступа такая проверка не поймала.

Для двух более простых искажений результат другой:

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

Есть и менее очевидная деталь вывода: для замены 30 на 90 поле changed равно нулю. Различие лежит в lost и added. Если смотреть только на changed, можно пропустить обнаруженное программой расхождение. С флагом --no-additions любое добавление извлечённого элемента даёт код возврата 1, даже если потерь нет.

Как поймать известное условие

Вернёмся к экспорту. Если важная фраза известна заранее, её можно защитить явно. В protected.txt запишем:

при включённой двухфакторной аутентификации

Добавим файл к сравнению:

humanizer-facts diff before.txt after.txt --protect protected.txt --no-additions --json

Теперь проверка возвращает код 1. В списке lost появляется запись категории protected со значением «при включённой двухфакторной аутентификации».

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

Для экспорта нужны тариф Pro и включённая двухфакторная аутентификация. Ссылка на архив действует 30 дней. Сервис не сохраняет исходный текст.

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

Поэтому protected стоит читать как «проверь это место». Если условие исчезло — возвращаем текст на правку. Если сохранилось в другой формулировке — принимаем после сравнения. Иначе вместо редактора получится охранник запятых.

Самое полезное происходит до запроса к модели

Вот задание для нашего абзаца:

Сделай текст проще. Сохрани четыре утверждения:
1. Экспорт требует тарифа Pro.
2. Для экспорта должна быть включена двухфакторная аутентификация.
3. Ссылка на архив действует 30 дней.
4. Сервис не сохраняет исходный текст.
Не добавляй новых возможностей или обещаний.

Список здесь выполняет две работы: ставит задачу редактору и остаётся у нас для приёмки результата. Он полезен и при правке человеком.

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

Что проверять перед публикацией

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

Для короткого текста это несколько строк рядом с черновиком, для длинного — список, к которому возвращаются после правок. Если источник сам противоречив, сравнение версий этого не исправит: оно отвечает только на вопрос, что изменилось.

Если у вас есть короткая пара, где после редактуры исчезло условие или сумма оказалась у другого человека, приведите её в комментариях без личных данных.

А из нашего абзаца можно забрать простое правило: если условие мешает сократить предложение, пусть предложение останется длиннее.