Правка 10% слов снижает обнаружение водяного знака OpenAI с 92% до 66%

Водяной знак для текста звучит как удобное решение: модель незаметно помечает свой ответ, а специальный детектор потом определяет его происхождение. На практике всё упирается в знакомую продуктовую проблему — пользователь не обязан публиковать ответ без изменений. Он сокращает его, переставляет фразы, переводит или просит другую модель переписать текст. После такой обработки скрытый сигнал быстро слабеет.

OpenAI представила метод textGrain, рассчитанный в том числе на выполнение требований статьи 50 европейского AI Act. В испытаниях компании он находил метку примерно в 95% текстов длиной 400 токенов, но лишь в 80% текстов длиной 200 токенов. Ещё показательнее редактура: замена 10% слов синонимами снизила обнаружение 400-токенных фрагментов с 92% до 66%, а замена 25% слов — до 17%.

Как текст получает невидимую метку

Языковая модель на каждом шаге выбирает следующее слово или его часть из нескольких вероятных вариантов. Допустим, после фразы «сегодня погода…» она может продолжить словами «тёплая» или «прохладная». Водяной знак с помощью секретного ключа слегка влияет на такой выбор. Для читателя ответ выглядит обычно, но в последовательности слов появляется статистический узор, известный детектору.

Особенность textGrain — управление энтропией, то есть запасом допустимой вариативности. Разработчик задаёт, сколько свободы можно потратить на встраивание сигнала, а система пытается сохранить баланс между заметностью метки для детектора и естественностью ответа. Это не штамп и не запись в каждом предложении: уверенность возникает только после накопления достаточного количества статистических признаков.

Отсюда проблема коротких сообщений. В ответе на пару предложений данных может просто не хватить. При заявленной доле ложных срабатываний в 1% детектор будет ошибочно помечать примерно один из ста текстов без водяного знака. Положительный результат при этом не показывает, сколько написал человек, а отрицательный не доказывает человеческое авторство.

Почему обычная правка ломает проверку

Сигнал зависит не только от отдельного слова, но и от предшествующей последовательности. Если редактор заменил одно слово, измениться может сразу несколько следующих участков статистического узора. Поэтому даже спокойная литературная правка — без специальной попытки обмануть систему — заметно ухудшает обнаружение.

Представим сервис, который генерирует описание товара на 150 слов. Менеджер меняет заголовок, сокращает повторы и заменяет десяток формулировок. Текст по-прежнему в основном создан моделью, но детектор уже может вернуть отрицательный результат. Обратная ошибка тоже болезненна: при проверке тысяч студенческих работ или заявок 1% ложных срабатываний превращается в десятки необоснованных подозрений.

Независимой оценки textGrain пока нет. OpenAI предоставила доступ ограниченной группе исследователей, которым ещё предстоит проверить разные языки, темы и длины. Заявление компании о сопоставимости или превосходстве над Google SynthID Text также пока не подтверждено внешними испытаниями.

Что делать разработчикам и продуктам

Европейские правила требуют машинно читаемой маркировки синтетического контента, которая должна быть эффективной, совместимой, устойчивой и надёжной настолько, насколько это технически возможно. Но измеримых порогов для этих характеристик пока нет. Добровольный кодекс практики при этом не требует водяных знаков для текстов короче 200 токенов.

Практический вывод простой: нельзя превращать результат детектора в единственное основание для блокировки, обвинения или санкции. В генеративном продукте лучше сочетать несколько уровней происхождения: водяной знак, подписанные метаданные, идентификатор модели, журнал генерации и явную маркировку интерфейса. Для спорных случаев нужна ручная проверка и возможность обжалования.

Разработчикам стоит отдельно тестировать реальные пользовательские сценарии: сокращение, перевод, исправление стиля, замену слов и повторную генерацию. Метрика на нетронутом лабораторном тексте мало говорит о работе функции после публикации. textGrain выглядит полезным дополнительным сигналом, но не универсальным детектором правды — и проектировать продукт нужно именно с этим ограничением.