Я делаю open-source хуманизатор для русского AI-текста. 27 апреля Хабр забанил мою же статью про этот хуманизатор как AI-генерацию.
Хронология. Я отправил материал про русские AI-паттерны на Хабр. Перед отправкой прогнал черновик через собственный скилл-хуманизатор, нашёл у себя слово «являются» в разделе про слово «являются», переписал, упомянул это в постскриптуме. Через несколько дней пришёл ответ от автомодератора:
К сожалению, данная публикация не сможет пройти модерацию, поскольку большая часть текста с высокой вероятностью создана с помощью генеративной модели ИИ.
Перечитал три раза. Статья про маркеры AI заблокирована как AI. Хуманизатор, через который я её только что прогнал, не сработал. Это не баг. Это его слепое пятно, о котором я узнал только в момент бана.
Возникает разумный вопрос, что вообще делает мой скилл, если не вытягивает текст, который сам про чистку от AI-маркеров. Полез разбираться. Из этого вылезло несколько вещей, которые до бана были мне самому непонятны, и я думаю, что они могут быть полезны любому, кто работает с русским контентом и думает про автоматическую детекцию.
Что такое humanizer-ru
Open-source скилл для Claude Code и OpenCode. Читает русский LLM-текст и возвращает в него живого автора. Ловит канцелярит, цепочки родительного, «является» как костыль, штампы вроде «в современном мире», ложные кальки с английского.
Я начал с того, что взял англоязычный blader/humanizer и попробовал применить к русскому. Из 29 правил оригинала рабочими оказались 8-10. Остальные либо неактуальны (Title Case в русском не существует), либо требуют другой логики. По итогам, 70% правил пришлось писать заново под русскую морфологию.
Чем русские AI-маркеры отличаются от английских
Пять основных классов, которые англоязычные хуманизаторы не покрывают.
Канцелярит и номинализация
Главный маркер. Стабильный. AI на русском превращает глаголы в существительные. «Осуществить проверку» вместо «проверить», «принятие решения» вместо «решили», «обеспечение возможности доступа» вместо «позволяет получить доступ». В английском такого нет в той же мере, потому что английская стилистика наоборот тяготеет к глаголам.
Простой эвристический тест. Если в абзаце больше существительных с суффиксом «-ание/-ение», чем глаголов, почти гарантированно LLM.
Цепочки родительного падежа
Три и более существительных подряд в родительном. «Улучшение качества обслуживания клиентов компании», пять подряд. Прочитайте вслух, попробуйте удержать в голове предмет высказывания. Не выйдет.
Живой автор скажет «клиенты стали довольнее». LLM так не делает. В английском этой проблемы нет вообще, английский язык не позволяет так наслаивать genitive case.
«Является» как костыль
LLM на русском использует связку «является» в 2-3 раза чаще, чем живые авторы. «Этот подход является эффективным», «продукт является решением». Русский в настоящем времени связку «быть» опускает, английский нет. AI копирует английскую логику и вставляет «является» туда, где её не должно быть.
Ещё один простой тест на любом подозрительном тексте. Поищите «является». Найдёте. Скорее всего, можно убрать или заменить на тире.
Канцелярские местоимения
«Данный», «указанный», «вышеупомянутый». Эти три слова из юридических текстов LLM расставляет по всему документу, как будто это что-то официальное. «В рамках данного проекта», «указанные выше пункты», «вышеупомянутая задача». В живом тексте так пишут только в договорах. В английском соответствующие конструкции (the aforementioned, the said) тоже звучат бюрократически, но в современном английском почти исчезли. В русском LLM их сохраняет.
Ложные кальки с английского
Когда AI на русском переводит английские штампы буквально. «В конце дня» (at the end of the day), «давайте нырнём» (let's dive in), «это меняет игру» (game-changer), «думать за пределами коробки» (outside the box), «в сердце системы» (at the heart of). Русский читатель морщится, опытный редактор хватается за голову.
В каталоге скилла четыре класса калек, типизированных по контексту. Маркетинговый перевод, академический английский, корпоративный язык, метафорические кальки. Полный список в репозитории, файл dictionaries/calques.md.
Что показал анализ моей же баненой статьи
Когда хуманизатор не помог пройти модерацию, я взял пять метрик, которые любой автоматический классификатор может посчитать по тексту, и прогнал ими свою статью. Получилось показательно. По всем пяти метрикам она была явным AI-документом, и каждая отдельная цифра помогает понять, на что именно реагирует автомодерация.
Параллельных секций уровня ## оказалось 19. Десять подряд имели одинаковую структуру. Тезис, таблица, объяснение, иногда мини-вывод. Это низкая burstiness структуры. Любой детектор, который смотрит на разнородность текста, такую регулярность видит сразу.
Плотность тире вышла в 5.88 на 1000 знаков. В среднем тире каждые 170 символов. Это уже не акцент, это пунктуационный фон. Я ставил их вместо запятых и точек, потому что так привычно. Детекторы считают частоту тире как один из ключевых статистических маркеров.
AI-цитаты в теле занимали 27.9% объёма. В каждой таблице «AI-русский / по-человечески» левая колонка, это специально сгенерированные шаблонные фразы для иллюстрации. Я давал их в кавычках и в таблицах, чтобы показать паттерн. Классификатору всё равно, в каких кавычках они стоят. Он считает суммарно. Треть моего текста по форме была AI-генерацией.
Абзацев в статье было 92, в основном 3-5 предложений. Длина почти не варьировалась. У человека текст рваный. Один абзац в одно предложение, потом длинный, потом средний, отступление в скобках. У AI-генерации почти всегда ровный ритм. У моей статьи ритм после прогона через скилл всё ещё был ровным. Скилл правит фразы, а не структуру.
Сумма факторов выглядела ровно как «средний AI-документ для тестового корпуса». Поэтому НЛО (что бы там ни было внутри) и среагировал.
Слепое пятно. Фразы против документа
Это важнее, чем сама история с баном.
Хуманизатор-скилл (любой, не только мой) работает на уровне фразы. Видит «осуществление проверки», заменяет на «проверим». Видит «является эффективным», превращает в «эффективен». Локальные правки. Точечные.
Автоматический классификатор смотрит на уровень документа. Распределение длин, плотность маркеров, разнородность структуры, ритм информационной плотности. Локальные правки фраз на это влияют слабо.
Можно прочистить каждое предложение и всё равно не пройти, если форма документа осталась шаблонной. Заголовок плюс одинаковые секции плюс таблицы плюс выводы по каждому пункту. Скилл лечит фразы. Форму документа он не видит.
Тут есть и более тонкий вывод. Текст-каталог про AI-паттерны технически невозможно сделать совсем «незаметным» для детекторов. Сам жанр требует приводить примеры AI-стиля. Чем больше примеров, тем больше детектор видит того, что должен видеть. Это компромисс жанра, не недоработка скилла.
Архитектура v0.2
После бана я переписал скилл. Из плоского каталога 38 правил он превратился в трёхслойный инструмент.
Слой 1, фразовый. Те же 38 правил из v0.1 плюс 13 новых. Девять тематических групп, включая отдельный раздел про русскую морфологию (падежные несогласования, деепричастия не к тому подлежащему, виды глагола, pro-drop) и расширенную идиоматику с типизацией калек.
Слой 2, документный. Audit-режим с 7 структурными метриками. Listicle-сигнатура, плотность тире, доля AI-цитат, burstiness предложений и абзацев, точка с запятой, одиночные двоеточия. Скилл не правит документ-уровневые маркеры (это требует переписывания целыми кусками с пониманием контекста), но сообщает автору, что нужно поменять руками. Чек-лист в виде отчёта.
Слой 3, голосовой паспорт. Сохраняемый артефакт .humanizer/voice.json с предпочтениями автора. Обращение, формальность, тип тире, кавычки, ритм предложений, идиолект, стоп-слова. Эволюционирует между сессиями через три механизма. Добавление новых образцов, inline feedback во время прогона, post-hoc reflection (сравнение с финальной опубликованной версией).
Voice passport как переиспользуемый артефакт это main feature, которой нет ни у англоязычных хуманизаторов, ни у других русских аналогов. Идея простая. Скилл не должен переписывать всё в один правильный «человеческий» стиль, потому что такого стиля не существует, а каждый живой автор пишет по-своему, и хороший редактор работает с этим конкретным автором, а не с абстрактной нормой.
Плюс шесть жанровых пресетов под канал публикации (Habr, Telegram, email, vc.ru, LinkedIn, документация). Каждый пресет описывает, какие правила обязательны в этом контексте, какие применяются с оговорками, какие игнорируются.
Чек-лист для тех, кто пишет про AI-паттерны
Из всего этого выходит короткий практический список. Если хотите, чтобы текст-каталог про AI прошёл автомодерацию.
Минимум блоков AI-цитат. Лучше инлайн в одну строку, не таблицами.
Никакого listicle с параллельными секциями одинаковой формы. Меняйте структуру каждого блока.
Личные истории вперемежку с разбором. Длина абзацев скачет.
Длинных тире нет вовсе. Коротких мало, как акцент.
Цифры рассыпаны по тексту, не пачкой.
Заголовки разные по структуре, не все «N + существительное».
Половину этих требований описывает мой же скилл, но в применении к фразам, не к документу. Это и было слепое пятно, о котором я не знал, пока не получил по носу.
Постскриптум
Репозиторий, SergeNS-mne/humanizer-ru. Лицензия MIT. Ставится в ~/.claude/skills/ для Claude Code или ~/.config/opencode/skills/ для OpenCode. Работает через слэш-команду /humanizer-ru. Если поймаете AI-паттерн, который скилл пропускает, открывайте issue с примером «было / стало».
Эту статью я тоже прогнал через свой скилл и прошёлся по чек-листу выше. Сократил блоки цитат, сломал параллельные секции, выкинул длинные тире, заменил точки с запятой на точки. Все семь метрик в норме.
Отправляю на повторную модерацию. Пройдёт или нет, узнаем по факту публикации.