Я проверил свой "очеловечиватель" текста - и отозвал лучшую метрику
Представьте: вы подготовили с помощью ИИ описание продукта, скопировали его в редактор и обнаружили служебный мусор. Исправить его нужно. Но от удаления лишних символов абзац не станет точнее, а мысль - интереснее.
С чего началась проверка
Я развиваю humanizer-ru, открытый проект для работы с текстом из ИИ-чатов. В августе у меня появился результат, который очень хотелось поставить на первый экран: после обработки тексты получали заметно более низкую оценку "машинности".
Контрольная проверка показала, что с выводом я поторопился. Расскажу, где ошибся и что теперь проверяю, прежде чем считать изменение полезным.
Что на самом деле измеряла метрика
25 августа 2026 года на 12 парах текстов средняя оценка языковых моделей-судей снизилась с 0,846 до 0,438. Это баллы конкретной оценочной процедуры, а не вероятность авторства. По ним я судил о качестве переписывания.
В сравнении была ловушка. Между исходным текстом и финальной версией стояли две операции: сначала уборка оформления, потом переписывание. Я разделил их и посмотрел, какой вклад дает каждая. В разборе с тремя семействами моделей убедительный эффект остался у оформления. Отдельного подтверждения пользы переписывания сверх этой очистки не получилось.
1 сентября я отозвал интерпретацию результата. Исходные данные сохранил. Число само по себе не стало ошибочным: ошибочным был мой вывод о том, что оно показывает. Разбор и команды перепроверки: https://github.com/Vladimir-Human/humanizer-ru/blob/main/research/AXIS-RUBRIC-RETRACTION-2026-09-01.md
Для меня здесь главный урок про оценку ИИ-продуктов: повторяемый результат еще не означает, что измеряется нужное свойство. Несколько моделей могут согласованно реагировать на оформление, пока разработчик думает, что проверяет качество мысли.
Очистка и редактура решают разные задачи
Поэтому в проекте я разделяю механическую очистку и редакторскую работу. Первая ищет известные следы вставки и снимает поддерживаемые артефакты. Вторая требует смотреть на содержание: что автор хотел сказать, где повторяется, какое утверждение надо уточнить. Убирать слова ради меньшего количества флагов - плохая редактура.
На 4 сентября 2026 года в проверке легкого домена из 12 314 текстов, не отобранных как носители артефактов, строгие маркеры класса A дали 0 ложных срабатываний. Контекстные индикаторы класса B дали 8. Эти группы нельзя складывать в общий вердикт "написано ИИ".
Результат ограничен этим корпусом. Он не доказывает точность на юридических документах, другом языке или любом будущем ответе модели. Методика, состав корпуса и интервалы оценки опубликованы здесь: https://github.com/Vladimir-Human/humanizer-ru/blob/main/research/FP-CORPUS-2026.md
Что делать с оценками детекторов
Снижение оценки детектора можно исследовать. Но сначала стоит разобраться, что именно изменилось в тексте. Если вместе с формулировками пропали оговорки, даты или ссылки, низкий балл не исправляет потери.
В работе MASH, опубликованной в Findings of ACL 2026, авторы исследуют обход детекторов через перенос стиля. Для humanizer-ru это возможное направление экспериментов, а не уже полученная возможность. Результаты той работы я не выдаю за результаты своего проекта. Статья: https://aclanthology.org/2026.findings-acl.1487/
В таком эксперименте я бы отдельно оценивал реакцию детектора, сохранение фактов и качество чтения. И обязательно сравнивал бы переписанный текст с версией, в которой изменено только оформление. Именно этого контроля не хватало моей первой интерпретации.
Как сравнивать инструменты
Для совместного теста я предложил общий корпус и одинаковые условия. До запуска фиксируем данные и критерии. После запуска показываем результаты целиком, в том числе ошибки. Обсуждение открыто: https://github.com/Vladimir-Human/humanizer-ru/issues/220
Пока совместного результата нет, таблица "кто лучше" была бы преждевременной. В собственных проверках мне важнее видеть конкретный провал: изменилось число, пропала ссылка, поврежден пример кода. Такой результат подсказывает, что исправлять.
Что можно попробовать
В браузерном демо можно вставить текст, увидеть найденные следы и сравнить версии до и после очистки. Применение отдельной кнопкой, отмена и копирование результата уже доступны. Обработка выполняется в браузере. Перед публикацией все равно стоит прочитать получившийся текст.
Демо без установки: https://vladimir-human.github.io/humanizer-ru/
Для работы с файлами есть Python-пакет и команды проверки, очистки и сравнения фактов. Для ИИ-ассистентов - MCP-сервер. Установка, исходный код и ограничения: https://github.com/Vladimir-Human/humanizer-ru
Сверка фактов тоже не всезнающая. Совпадение чисел и имен не доказывает сохранение связей между ними: можно оставить две суммы, но поменять их получателей местами. Такую ошибку нельзя объявить исправленной только потому, что проверка прошла.
Как проверить похожую функцию у себя
Возьмите исходный текст, версию после одной лишь очистки оформления и версию после полной редактуры. Сравните их по отдельности. Проверьте числа, условия, отрицания, ссылки и код. Затем дайте читателю варианты без подсказки, какой считается улучшенным. Заранее решите, какой результат заставит вас отказаться от красивого вывода.
Мне сейчас полезны реальные примеры того, что ломается при переносе текста из чата в документ: таблицы, ссылки, отступы, фрагменты кода. Их можно прислать через Issues в репозитории. Достаточно короткого примера до и после; личные данные замените вымышленными.
А вам приходилось отказываться от хорошей метрики, когда выяснялось, что она измеряет не то? Интересно, какой контроль помог это заметить.
Автор: Vladimir-Human, проект humanizer-ru (https://github.com/Vladimir-Human/humanizer-ru).