Ограничения автоматического детектора ИИ-текста: что ловит код, а что требует редактора
Habr AI · оригинал
Материал подготовлен автоматизированной редакционной системой. Факты можно сверить по указанному первоисточнику.
Автор разработал локальный скрипт для выявления признаков неотредактированного нейросетевого текста, который позволяет спорить с каждым срабатыванием. Анализ показал, что алгоритмы способны поймать лишь часть стилистических ошибок, тогда как смысловые и синтаксические нюансы остаются прерогативой живого редактора.
Материал демонстрирует практические границы автоматизации в сфере контроля качества контента, объясняя, почему процентные оценки онлайн-сервисов часто ненадёжны и как конкретные правила могут заменить абстрактные метрики.
Вопрос о том, как отличить текст, сгенерированный нейросетью, от человеческого, остаётся сложной задачей. Автор статьи предлагает альтернативу популярным онлайн-детекторам, которые часто возвращают лишь непонятный процент вероятности. Ссылаясь на исследование Лианга и соавторов, где семь детекторов ошибочно приняли за машинные 61% эссе TOEFL, написанных носителями других языков, а также на закрытие классификатора OpenAI в 2023 году из-за низкой точности, автор обосновывает необходимость более прозрачного подхода. Его решение — локальный скрипт на Python, который не определяет авторство, а ищет конкретные следы невычитанного текста, называя проблемную фразу и правило.
Детектор работает по принципу 12 признаков «нейрослопа». Пять из них поддаются автоматизации: анонсы вместо содержания, пустые вводные части, монотонный ритм абзацев, кавычки вокруг обычных слов и кальки с английского. Код анализирует структуру предложений, например, проверяя короткие фразы на наличие глаголов-обещаний в начале или подсчитывая стандартное отклонение длины предложений для выявления монотонности. При этом алгоритм учитывает исключения: если в предложении есть цифра, код или латинское слово, оно считается «фактическим якорем» и не помечается как шаблонный анонс.
Однако автоматизация имеет пределы. Семь признаков детектор не ловит: отсутствие проверяемых деталей, придуманные числа, взвешенность без позиции, антитезы с перечислением, тройки ради ритма, рубленые концовки и избыточное использование тире. Скрипт не способен понять, считал ли автор проценты или взял их наугад, а также не распознаёт смысловые кальки, где слова русские, но оборот заимствован из английского. Эти аспекты требуют человеческого восприятия и редактуры.
Тестирование на пробном тексте из образцов «слопа» показало, что скрипт поставил 18 баллов из 80, что ниже порога в 20, но вердикт всё равно потребовал доработки из-за срабатывания правила об анонсах. Это демонстрирует гибкость системы: отдельные категории могут блокировать текст даже при низкой общей сумме. Автор отмечает, что детектор не отличает примеры плохих фраз, приведённые в статье для разбора, от их реального употребления, что является известным ограничением таких инструментов.
Для создания собственной проверки автор рекомендует писать отдельные функции под каждый признак, возвращающие найденную фразу, а не только балл. Это позволяет проверять каждое срабатывание вручную. Также важно прогонять новые шаблоны на старых текстах, чтобы избежать ложных срабатываний. Например, узкий шаблон для фразы «в этой статье мы рассмотрим» оказался надёжнее широкого поиска глаголов в начале предложения.
Подсчёт тире также требует осторожности: простой лимит в три тире на тысячу знаков может отметить до половины нормальных статей, поэтому порог нужно подбирать индивидуально. Автор планирует закодировать проверки на тройки и тире, но пока не нашёл надёжного шаблона для антитезы «не А, а Б». Этот материал полезен для редакторов и авторов, которые хотят внедрить автоматическую проверку стилистики без потери контроля над смыслом текста.