Разработчик утилиты humanizer-ru, предназначенной для работы с текстом, опубликовал разбор метода проверки правок, вносимых искусственным интеллектом. На примере условного абзаца документации он показал, что стандартный подход, основанный на сравнении извлекаемых элементов вроде чисел и отрицаний, может не заметить исчезновение критически важного условия. В версии 3.36.4 программы diff, сравнивающей две версии текста, в приведённом примере не было обнаружено различий, хотя смысл изменился. Это демонстрирует ограниченность чисто формальной проверки и поднимает вопрос о том, что именно считать фактом при автоматизированном контроле качества.

В качестве наглядного примера автор приводит пару предложений: «Анна получила 30 000 рублей. Борис получил 50 000 рублей». После редактуры они превращаются в «Анна получила 50 000 рублей. Борис получил 30 000 рублей». Оба имени и обе суммы сохранены, но деньги достались не тем людям. Если проверять текст только по списку сохранившихся имён и чисел, ошибка останется незамеченной. Именно поэтому ответ «факты сохранены» требует уточнения: что проверка считает фактом. В примере с Анной и Борисом утилита humanizer-facts diff не обнаружила различий среди извлекаемых элементов, вернув нули в полях lost, added и changed, а также identical: true. Это показывает, что даже при полном совпадении формальных элементов смысл может быть искажён.

Более тонкий случай — потеря условия. В исходном абзаце документации сказано: «Экспорт доступен на тарифе Pro при включённой двухфакторной аутентификации. Ссылка на архив действует 30 дней. Сервис не сохраняет исходный текст». После сокращения остаётся: «Экспорт доступен на тарифе Pro. Ссылка на архив действует 30 дней. Сервис не сохраняет исходный текст». Читается гладко, условие о тарифе, срок и обещание не хранить текст на месте, но исчезло требование двухфакторной аутентификации. Пользователь купит Pro, откроет экспорт и обнаружит неожиданное требование, о котором инструкция умолчала. Программа diff в этом случае также не находит расхождений, если не использовать специальные флаги. Для обнаружения потери условия предлагается вручную выписать утверждения из исходника, например: «Для экспорта нужно включить двухфакторную аутентификацию», и затем защитить их явно. Если важная фраза известна заранее, её можно поместить в файл protected.txt и добавить к сравнению с флагом --protect. Тогда проверка вернёт код 1 и укажет на исчезновение защищённой формулировки. Однако автор предупреждает: если требовать буквального присутствия, можно отклонить и корректную перефразировку, где все утверждения сохранены, но выражены иначе. Поэтому protected следует читать как «проверь это место», а не как автоматический запрет на изменения.

Контекст разработки humanizer-ru связан с растущим использованием больших языковых моделей для редактирования и рерайтинга текстов. Многие организации внедряют ИИ для сокращения, упрощения или перевода документации, но при этом сталкиваются с риском потери смысла. Существующие инструменты проверки часто ограничиваются поиском чисел, дат, имён собственных или отрицаний. Однако, как показывает пример с Анной и Борисом, даже сохранение всех чисел не гарантирует правильности. Более сложные случаи, такие как изменение условия доступа или логических связей, требуют семантического анализа, который пока не автоматизирован в полной мере. Автор подчёркивает, что его статья — демонстрация метода, а не статистика ошибок какой-либо нейросети. Это означает, что проблема носит общий характер и касается любого автоматизированного редактирования, будь то с помощью ИИ или человека.

Для российского рынка эта тема особенно актуальна, поскольку многие компании активно внедряют ИИ-ассистентов для работы с внутренней документацией, клиентскими договорами и техническими регламентами. Ошибка в условии доступа или сумме платежа может привести к юридическим и финансовым последствиям. Реакция отрасли на подобные предупреждения пока неоднозначна: одни разработчики считают, что достаточно расширить списки проверяемых сущностей, другие настаивают на необходимости человеческого контроля на финальном этапе. Автор humanizer-ru предлагает компромиссный подход: автоматическая проверка чисел и части элементов, а утверждения, от которых зависит действие читателя, должны быть прочитаны целиком. Это перекликается с практиками тестирования программного обеспечения, где автоматические тесты дополняются ручным исследовательским тестированием.

Сравнение с альтернативами показывает, что многие коммерческие сервисы проверки текста, такие как Grammarly или LanguageTool, ориентированы на грамматику и стилистику, а не на сохранение смысловых утверждений. Специализированные решения для фактчекинга, например, от Google или Microsoft, также не решают задачу полностью, поскольку требуют предварительной разметки фактов. humanizer-ru предлагает более гибкий подход с возможностью защищать конкретные фразы, но и он не является панацеей. Автор честно признаёт, что в статье не измерялось, насколько запрос с перечислением утверждений снижает частоту ошибок модели. Проверено другое: на готовой паре видно, какое утверждение потерялось и как настроить проверку, чтобы она подала сигнал. Это оставляет открытым вопрос о количественной эффективности метода.

В перспективе развитие подобных инструментов может пойти по пути интеграции с системами управления версиями и CI/CD, чтобы автоматически блокировать публикацию документации при потере критических условий. Однако для этого потребуется более совершенные методы извлечения смысла, возможно, на основе больших языковых моделей, но с осторожностью, чтобы не создать иллюзию полного контроля. Автор призывает читателей присылать примеры, где после редактуры исчезло условие или сумма оказалась у другого человека, чтобы накопить эмпирические данные. Пока же рекомендуется сохранять исходник, выписывать условия, сроки, отрицания и связи, а после редактуры сопоставлять каждый пункт. Для короткого текста это несколько строк рядом с черновиком, для длинного — список, к которому возвращаются после правок. Если источник сам противоречив, сравнение версий этого не исправит: оно отвечает только на вопрос, что изменилось. Таким образом, проверка правок ИИ остаётся комбинированной задачей, где автоматика помогает, но не заменяет внимательного чтения.