Утилита humanizer-facts версии 3.36.4 сравнила две версии текста и вернула нули в полях lost, added и changed, а также identical: true. Файлы при этом различались. В исходнике было «Анна получила 30 000 рублей. Борис получил 50 000 рублей», после редактуры — «Анна получила 50 000 рублей. Борис получил 30 000 рублей». Оба имени на месте, обе суммы тоже, но деньги достались не тем людям. Проверка по списку сохранившихся имён и чисел придраться не к чему.
Это нарочно грубый пример: ошибку видно сразу. Но тот же механизм работает и на менее очевидных правках. Автор проекта humanizer-ru разбирает условный абзац документации: «Экспорт доступен на тарифе Pro при включённой двухфакторной аутентификации. Ссылка на архив действует 30 дней. Сервис не сохраняет исходный текст». После сокращения осталось «Экспорт доступен на тарифе Pro. Ссылка на архив действует 30 дней. Сервис не сохраняет исходный текст». Читается гладко, условие о тарифе осталось, срок не изменился, обещание не хранить исходный текст тоже на месте. Исчезло условие о двухфакторной аутентификации. Пользователь купит Pro, откроет экспорт и обнаружит требование, о котором инструкция промолчала.
| Было | Стало | Что обнаружила версия 3.36.4 |
|---|---|---|
| Резервная копия хранится 30 дней. | Резервная копия хранится 90 дней. | Потерю 30 и добавление 90 |
| Сервис не сохраняет исходный текст. | Сервис сохраняет исходный текст. | Потерю отрицания и его инверсию |
Список утверждений лучше составлять по исходнику, пока новая версия ещё не начала казаться привычной. В нём нужны утверждения целиком: «для экспорта нужно включить двухфакторную аутентификацию», а не отдельные слова «экспорт» и «аутентификация». В примере с выплатами список был бы совсем коротким: «Анна получила 30 000» и «Борис получил 50 000». Он сразу показывает ошибку, которую перечень имён и сумм пропускает.
Для повторения сохраните исходный абзац в 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 содержит количество найденных расхождений среди извлекаемых элементов, а identical показывает, обнаружены ли такие расхождения. Сами файлы при этом различаются. Условие доступа такая проверка не поймала.
Для двух более простых искажений результат другой. Замена «Резервная копия хранится 30 дней» на «Резервная копия хранится 90 дней» даёт потерю 30 и добавление 90. Замена «Сервис не сохраняет исходный текст» на «Сервис сохраняет исходный текст» даёт потерю отрицания и его инверсию. Это полезные сигналы: в длинной инструкции трудно выловить каждую изменённую цифру. Но сигнал относится к конкретной проверке. Нулевой код возврата не делает весь новый текст правильным.
Есть и менее очевидная деталь вывода: для замены 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. Сервис не сохраняет исходный текст». Чем точнее список утверждений на входе, тем меньше правок придётся откатывать на выходе. Автор подчёркивает: все примеры составлены вручную и проверены на опубликованном пакете. Это демонстрация метода, а не статистика ошибок какой-либо нейросети.
