Почему традиционные детекторы ИИ-текста проигрывают гонку вооружений
Детекторы ИИ-текста, такие как GPTZero и Originality.ai, работают на измерении перплексии (степени «удивления» модели от следующего токена) и burstiness (вариативности длины предложений). Человеческий текст обычно имеет высокую burstiness и непредсказуемые паттерны, тогда как машинный - более равномерен. Проблема в том, что эти метрики - поверхностный сигнал, который легко подделать. Генеративные модели эволюционируют быстрее, чем детекторы, и гонка вооружений здесь проиграна с самого начала: любой школьник с доступом к синонимайзеру или инструкцией «напиши более человечно» обходит защиту за секунды.
Фокус на вопросе «кто написал?» уводит в сторону от реальной задачи. Пользователю неважно, сгенерирован текст нейросетью или написан человеком - ему важно, несёт ли этот текст полезную нагрузку. Альтернативный подход, который мы разбираем, смещает цель с авторства на качество: система не пытается детектировать ИИ, она оценивает, является ли контент слопом - мусорной информацией без смысловой ценности.
Методы обхода: от перефразирования до контролируемой генерации
Существующие методы обхода делятся на три категории. Первая - постобработка: текст прогоняется через синонимайзеры или инструменты вроде Undetectable AI, которые меняют лексику и структуру предложений, сохраняя смысл, но сбивая статистические сигнатуры. Вторая - параметрическая настройка генерации: повышение температуры (temperature) делает вывод менее детерминированным, что снижает перплексию до уровней, характерных для человека. Третья, наиболее сложная - дообучение модели на корпусе человеческих текстов с целевой функцией минимизации детектируемости. Результат: текст, который статистически неотличим от написанного человеком, но по содержанию остаётся пустышкой.
Показателен кейс Substack, где внедрение детектора AI-контента на базе Pangram вызвало волну ложных срабатываний. Авторы, пишущие в структурированном академическом стиле, получали метку «AI-generated», тогда как откровенный спам, сгенерированный с простым промптом «обойди детектор», проходил проверку. Подробнее об этом кейсе и его последствиях для контент-платформ - в разборе интеграции Substack и Pangram.
Слоп как новая цель: оцениваем мусорность, а не авторство
Слоп (slop) - термин, закрепившийся за низкокачественным контентом, который не несёт полезной нагрузки независимо от источника. Это может быть SEO-текст с идеальной грамматикой и нулевым смыслом, сгенерированный нейросетью, или написанная человеком статья с круговыми рассуждениями без фактов. Принципиальное отличие от детекции ИИ: слоп-детектор не спрашивает «кто это написал?», он спрашивает «есть ли здесь что-то ценное?». Такой подход устойчив к обходу, потому что злоумышленнику пришлось бы вкладывать реальные усилия в создание осмысленного контента - а это именно тот результат, которого мы добиваемся.
Метод опирается на три столпа: связность, структуру и фактическую достоверность. В отличие от перплексии, эти метрики не маскируются заменой слов - бессвязный текст останется бессвязным на любом словаре. Исследования по оценке когерентности (например, работы в области TextGraphs) показывают, что графовые представления текста выявляют логические разрывы, невидимые для статистических классификаторов.
Семантический анализ: метрики связности и смысловой целостности
Технически анализ работает на двух уровнях. Локальная связность (cohesion) измеряет, насколько предложения внутри абзаца связаны лексически и грамматически: отслеживаются цепочки местоимений, повтор ключевых сущностей, переходы между темами. Глобальная связность (coherence) оценивает логику всего текста - строится граф утверждений, где узлы - это фактические заявления, а рёбра - логические отношения (причина-следствие, обобщение, противоречие).
Если граф распадается на изолированные кластеры или содержит циклы противоречий - перед нами слоп. Например, текст, который в одном абзаце утверждает «Python - компилируемый язык», а в другом «интерпретатор Python выполняет байт-код», получит низкую оценку целостности из-за логического конфликта. Инструменты вроде TextGraphs позволяют автоматизировать такое построение, но в ClearWater реализован собственный пайплайн, заточенный под скорость работы в браузере.
ClearWater: архитектура плагина для двухэтапной фильтрации
ClearWater - браузерный плагин, реализующий этот подход в виде двухэтапного конвейера. Первый этап выполняется локально, без отправки данных на сервер, и отсеивает очевидный мусор за миллисекунды. Второй этап - серверная глубокая проверка с привлечением LLM и внешних источников - запускается только для текстов, прошедших пре-фильтр. Такая архитектура решает сразу две задачи: сохраняет конфиденциальность (большинство текстов не покидают устройство) и экономит вычислительные ресурсы.
Плагин не просто выносит вердикт «слоп/не слоп», а сохраняет полный отчёт с указанием причин и обменивается им между пользователями. Это краудсорсинговый слой: если один пользователь уже проверил конкретную статью, остальные получают готовый вердикт мгновенно, без повторной проверки. Механика напоминает коллективный антивирус, где сигнатуры угроз обновляются в реальном времени.
Локальный пре-фильтр: быстрые эвристики без LLM
Пре-фильтр оперирует набором детерминированных правил, не требующих машинного обучения. Проверки включают: минимальную длину текста (отсев однострочных комментариев), наличие структурных элементов (заголовки, списки, абзацы - их полное отсутствие характерно для неформатированных выхлопов API), соотношение стоп-слов к значимым (перекос в сторону стоп-слов указывает на «воду»), энтропию распределения символов и слов (патологически низкая энтропия выдаёт шаблонную генерацию).
Каждая проверка возвращает числовой скор, и если агрегированный показатель превышает порог - текст отправляется на сервер. Порог настраивается: для задач фильтрации новостной ленты можно выставить агрессивный режим, для проверки датасетов - более консервативный. Локальная природа пре-фильтра означает, что даже при обрыве соединения базовая фильтрация продолжает работать.
Серверная проверка: глубокий анализ с помощью LLM и внешних источников
Серверный этап использует LLM не как детектор ИИ, а как критика контента. Промпт строится в три шага: сначала модель извлекает из текста все фактические утверждения (claims), затем для каждого утверждения формулирует поисковый запрос и проверяет его через API внешних источников, наконец - оценивает логическую непротиворечивость всего набора утверждений. LLM не принимает решений о достоверности фактов самостоятельно - она лишь сопоставляет утверждения из текста с данными из поисковой выдачи.
Пример: текст утверждает «Gemma 4 показала state-of-the-art на бенчмарке MMLU с результатом 92.3%». Система извлекает claim, ищет актуальные данные по MMLU-бенчмаркам, и если находит, что Gemma 4 набирает 88.7%, а 92.3% - это результат другой модели, фиксирует фактическую ошибку. Текст с несколькими такими ошибками получает высокий slop-score, даже если грамматически и стилистически он безупречен. Этот подход перекликается с методологией, описанной в разборе автоматизации верификации уязвимостей, где многослойная фильтрация отличает реальные проблемы от шума.
Краудсорсинг вердиктов: как коллективный опыт усиливает точность
Каждый серверный вердикт сохраняется в распределённой базе знаний плагина вместе с хешем контента и полным отчётом: какие claims были проверены, какие источники использованы, какие противоречия найдены. Когда другой пользователь открывает ту же статью, плагин сверяет хеш и мгновенно отображает готовый вердикт. Для частично изменённого контента (например, статья обновлена) система перепроверяет только изменившиеся фрагменты.
Накопление вердиктов создаёт карту типичных паттернов слопа: шаблонные структуры, характерные для контент-ферм, циклические рассуждения без выхода на факты, паттерны фальшивой экспертности. Эта база используется для дообучения локального пре-фильтра - со временем он начинает отсеивать всё более хитрые формы слопа без обращения к серверу. Аналогичный подход к накоплению и переиспользованию знаний о проекте мы разбирали в контексте построения единого контура безопасности в DevSecOps.
Ограничения подхода и сценарии, где он может давать сбои
Зависимость от качества внешних источников - главное ограничение. Если поисковая выдача по проверяемому утверждению сама заполнена слопом, система может подтвердить ложный факт. Эта проблема особенно остра для узкоспециализированных доменов, где релевантные источники малочисленны или отсутствуют в открытом доступе. Второй риск - ложные срабатывания на текстах с заведомо нестандартной структурой: художественная проза, поэзия, поток сознания могут получить низкие оценки связности, не будучи слопом.
Мультиязычность - ещё один вызов. Локальный пре-фильтр опирается на списки стоп-слов и паттерны, специфичные для языка. Серверная проверка требует, чтобы внешние источники поддерживали целевой язык. Плагин оптимизирован для английского и русского; на других языках точность снижается. Система не детектирует ИИ-генерацию как таковую - если задача требует строгой идентификации факта использования нейросети (например, для академической политики), ClearWater не заменит специализированный детектор. Его ценность в другом: он отсеивает мусор независимо от происхождения.
Практическое применение: интеграция ClearWater в ваш рабочий процесс
Установка плагина стандартна для браузеров на Chromium: загрузка из магазина расширений, выбор режима фильтрации (агрессивный/сбалансированный/консервативный), опциональная настройка списка доверенных доменов, которые не проверяются. После установки плагин добавляет индикатор в адресную строку: зелёный - контент проверен и чист, жёлтый - есть подозрительные паттерны, красный - обнаружен слоп с указанием причин в выпадающем отчёте.
Три основных сценария использования. Фильтрация новостных лент: плагин подсвечивает статьи-пустышки ещё до того, как вы потратите время на чтение. Очистка датасетов для обучения моделей: перед файнтюнингом на собранном корпусе текстов можно прогнать его через ClearWater API и отсеять слоп, повысив качество обучающей выборки. Проверка статей перед публикацией: редактор видит, какие утверждения требуют дополнительной верификации, и может доработать материал до отправки в продакшен. В дорожной карте разработки - публичное API для интеграции в CI/CD-пайплайны контентных платформ и кастомные правила проверки для специфических доменов. Для команд, работающих с AI-кодингом и генерацией контента, также будет полезен анализ рисков AI slop в кодовой базе.