В одном из тестов моего humanizer-ru оценка “машинности” ответа упала с 0,95 до 0,10. Сам ответ при этом не изменился ни на букву: “Столица Австралии - Канберра”. Из файла убрали строки вокруг него, включая название чат-бота.
В другой паре тексты отличались лишь переводом строки в конце файла. Оценки всё равно разошлись: 0,9 и 0,3.
Эти пары лежат в открытых данных проекта. По общей таблице я раньше делал вывод о качестве редактирования, но теперь эта интерпретация отозвана. Чтобы объяснить почему, сначала покажу, что именно я пытался проверить.
Что делает humanizer-ru
Я развиваю Vladimir-Human/humanizer-ru. Это открытый проект для работы с русским текстом после чат-бота. В нём соседствуют две задачи, которые легко перепутать.
Первая - обычная редактура. Допустим, в черновике написано: “В рамках проекта было осуществлено внедрение системы мониторинга”. Это можно сократить до “В проекте внедрили систему мониторинга”. Такой пример иллюстрирует правку канцелярита; это не результат теста и не доказательство нейросетевого авторства исходной фразы.
Для этой задачи в проекте есть скилл: набор текстовых инструкций и примеров для ИИ-ассистента. Модель читает их вместе с вашим текстом и по просьбе предлагает редактуру. Отдельную нейросеть humanizer-ru не обучает. Результат зависит от модели и от задания; полезную правку всё равно нужно отличать от пересказа, который потерял важную оговорку.
Вторая задача гораздо конкретнее: убрать технический мусор, попавший в документ при копировании из чата. Например, вместо нормальной сноски в тексте может остаться :contentReference[oaicite:3]{index=3}. Для такой уборки у меня есть Python-утилиты: они ищут известные последовательности символов и снимают поддерживаемые артефакты по правилам. Языковая модель для этого не нужна.
На вход утилите даёте текстовый файл, на выходе получаете список находок, очищенный текст или разницу между версиями. Канцелярское предложение она за вас не перепишет. А скилл для модели, наоборот, занимается редактурой и не превращается от этого в надёжного эксперта по авторству.
Проблема началась, когда я попробовал оценить обе задачи одним числом.
Как получился хороший результат
В замере от 25 августа 2026 года были 12 сохранённых ответов Алисы, GigaChat и Le Chat. Именно сохранённых: вместе с ответами в файлы попали вопросы и подписи. Это не были двенадцать одинаково подготовленных статей.
Модель DeepSeek переписывала их по инструкциям humanizer-ru версии 3.15.0. Задание требовало убрать следы машинной генерации, сохранить все факты и вернуть только итоговый текст. Другого шага обработки в описании прогона нет: отдельной подготовительной очистки для этих двенадцати пар не записано.
Судьёй выступала другая модель, GLM-5.3: она оценивала исходный и обработанный варианты.
Опубликованная инструкция судье задавала шкалу от 0 до 1, где 0 означает “выглядит как человеческий текст”, а 1 означает “как нейросетевой”. Здесь и дальше это условная оценка модели. Число 0,95 нельзя читать как установленную вероятность “95%, что автор - ИИ”: калибровки, которая позволяла бы так говорить, этот замер не предъявлял.
Средняя оценка исходников составила 0,846, после обработки 0,438. Ниже оценка оказалась в 11 парах из 12, а разница средних дала минус 0,408. В одной паре из двенадцати оценка, наоборот, немного выросла.
Арифметика сходится: эти числа можно заново получить из сохранённых оценок, не обращаясь к моделям. Но я использовал падение оценки как свидетельство того, что редактура сделала тексты лучше. Вот этого счёт не доказывал.
Канберра, которую не пришлось переписывать
Вот полный исходник одной пары из того замера, ai-09:
Режим: Fast (Vibe)
Вопрос: Какая столица у Австралии?
Дата: 2026-07-14
Клиент: chat.mistral.ai
Ответ Le Chat (Mistral, fast mode):
Столица Австралии — Канберра.
После обработки в файле осталось:
Столица Австралии — Канберра.
У первого варианта сохранена оценка 0,95, у второго - 0,10. Последнее предложение совпадает дословно. В начале исходного файла также была невидимая метка кодировки BOM; в обработанном её нет.
Да, в исходнике буквально написано, кто ответил. До обработки судье показывали ответ с подписью “Le Chat”, после - короткую фразу без подписи. Убрать эти строки полезно, если нужен чистый ответ. Но более точного или содержательного ответа в этой паре не появилось. А падение оценки я засчитал именно как улучшение.
Это не специально придуманный для статьи пример. Оба файла пары, eval/runs/2026-08-25-axis-12/source/ai-09.txt и eval/runs/2026-08-25-axis-12/with/ai-09.txt, лежат в общем снимке данных вместе с остальными парами; ссылка на снимок - в приложении.
Здесь не убрали ничего, а оценка всё равно упала
Другой ответ на тот же вопрос, пара ai-03, сохранился в таком виде:
Вопрос: Какая столица у Австралии?
Ответ Алисы (YandexGPT, 2026-07-14):
Столица Австралии — Канберра.
Источники
В обработанном файле ровно те же строки. Исчез только завершающий перевод строки. Подпись Алисы осталась на месте, а оценка упала с 0,9 до 0,3.
Эта пара ломает удобное объяснение “всё дело в удалённых подписях”. Почему разошлись оценки, по сохранённым файлам установить нельзя: модель могла ответить по-разному на два одинаковых запроса. Зато видно, чем это точно не было: читателю предложили ровно те же слова.
Обе пары входят в те самые двенадцать, а не в отдельный эксперимент. Всю среднюю разницу они не объясняют. Они объясняют, почему её нельзя предъявлять как доказательство хорошей редактуры.
Что я отозвал и что осталось
В журнале исправлений от 1 сентября 2026 года я отозвал интерпретацию минус 0,408 как показателя качества текста. Исходные файлы и оценки остались в репозитории. Пересчёт по-прежнему даёт прежнее число. Изменилось то, какой вывод из него допустим.
Это не доказательство бесполезности редактирования. В длинном ответе можно убрать повтор или, наоборот, потерять условие, от которого зависит весь смысл. Каждую такую правку нужно рассматривать отдельно, и оценка модели, разошедшаяся даже на паре без единой правки, для этого не годится.
А вот у очистки критерий проще. Известный служебный маркер снимается и проверяется повторным сканом. Команду внутри блока кода трогать нельзя: читатель скопирует испорченную строку. А спорный невидимый символ не удаляют скопом, потому что часть таких символов держит составные эмодзи и разметку абзацев.
И пустой отчёт сканера означает только, что он не нашёл поддерживаемых маркеров. Из этого не следует, что текст написал человек. Полезность уборки можно проверить отдельно от любых предположений об авторстве.
Что можно попробовать сейчас
Вот маленький учебный пример для Python-утилиты. Это вымышленная строка для демонстрации команды, не данные эксперимента с двенадцатью ответами.
Сохраните в UTF-8 файл example.txt:
Согласно отчёту, число заявок выросло. :contentReference[oaicite:3]{index=3}
Установите утилиты моего проекта. На PyPI имя humanizer-ru занято им, у соседнего проекта пакет называется иначе. Номер 3.36.4 относится к текущему выпуску утилит; 3.15.0 из рассказа выше было версией текстовых инструкций на момент того замера.
python -m pip install humanizer-ru==3.36.4
humanizer-markers --scan example.txt
humanizer-clean --diff example.txt
Первая команда найдёт contentReference. Её код возврата 1 означает находку, а не поломку программы. Вторая покажет предполагаемое изменение и не перезапишет файл.
Чтобы получить очищенный текст в терминале:
humanizer-clean example.txt
Результат:
Согласно отчёту, число заявок выросло.
Маркер исчез. Подтверждение роста заявок из этого не появилось: ссылку на настоящий отчёт всё ещё должен проверить редактор. Утилита не восстанавливает утраченный источник и не проверяет правдивость утверждения.
Для сравнения исходника с уже отредактированным текстом есть отдельная команда humanizer-facts diff before.txt after.txt. Она помогает заметить потерянные числа, даты и другие извлекаемые элементы. Это дополнительная проверка: совпадение таких элементов не гарантирует сохранения всего смысла.
Зачем здесь второй humanizer-ru
На GitHub есть одноимённый проект Ильи Утова. По его текущей документации, это тоже инструкции для ИИ-редактора вместе со сканером. Пользователь передаёт русский текст и просит убрать канцелярит или штампы; агент правит конкретные места и сверяет утверждения с исходником. Сканер отдельно подсвечивает обороты и считает балл по своим правилам, с поправкой на жанр текста.
То есть сравнение “у него только промпт, а у меня программа” было бы неверным. У обоих проектов есть и инструкции для моделей, и программные проверки. У моего сейчас основной упор на очистке следов вставки и проверяемых ограничениях этой очистки. У проекта Ильи в описании на первом плане локальная стилистическая редактура. Это описание подходов, а не результат соревнования.
7 сентября Илья предложил: “публичный тест, публичные данные. Сделать бенч для хуманайзеров”. Я согласился и открыл отдельное обсуждение. Формат общего теста ещё предстоит согласовать; результатов совместного сравнения в этой статье нет.
В таком тесте я предлагаю отдельно проверять ложные срабатывания, удаление технических артефактов и потери фактов. Если позже мы возьмёмся именно за качество редактуры, понадобится сравнить несколько вариантов одного текста:
-
исходник без изменений;
-
тот же текст после одной лишь технической уборки;
-
текст после редактирования моделью с одинаково подготовленным входом.
Тогда будет видно, что дала сама редактура сверх уборки. До основного прогона нужно проверить и способ оценки: замечает ли он намеренно испорченное утверждение, не награждает ли один и тот же текст за разное оформление. Иначе можно снова получить красивую таблицу про что-то другое.
Старое число я оставил в данных вместе с отозванной интерпретацией: удалять неудобный результат - худший способ с ним разобраться. Но выбирать по нему инструмент больше нельзя, и это, пожалуй, единственный вывод, который я готов защищать. Проверка, которая измеряет не то, что вы думаете, выглядит точно так же, как удачная. Те же графики, те же проценты. Отличить их можно, только попробовав её сломать.
Приложение: как проверить приведённые числа
Снимок исходных данных, на который ссылается статья, закреплён коммитом 75c7711. Установленный выше пакет нужен для очистки файлов; для проверки исторического замера нужен репозиторий:
git clone https://github.com/Vladimir-Human/humanizer-ru.git
cd humanizer-ru
git checkout 75c7711f174133139e3ff8e22c67bdc11231baee
python eval/reproduce.py
Скрипт пересчитывает статистику по сохранённым результатам. Он не опрашивает нейросети заново и не доказывает, что новый вызов даст те же оценки. В выводе: среднее до 0.8458, после 0.4375, разница -0.4083; выше эти числа округлены.
Файлы, на которые опирается статья, лежат в одном снимке. В каталоге прогона есть пары source и with; там же manifest.json с описанием задания редактору. Сводная таблица оценок - в eval/detect-results/2026-08-25-detect-axis-12-glm53.json.
В журнале исправлений описаны и дополнительные контрольные прогоны, исходные данные которых опубликованы не полностью. Их численные результаты здесь не использованы: примеры и пересчёт выше опираются на открытый архив.
Автор: Vladimir-Human
