Несколько часов назад антропики [анонсировали], что будут помечать сгенерированный контент вотермарками из-за очередных регуляций Евросовка
Чисто технически понятно, как можно помечать файлы через метаданные, но как они планируют помечать текст? Пока подробности не раскрыты, но можно предположить, отталкиваясь от существующих решений.
Самый наивный и очевидный вариант - через [unicode homoglyphs]. Claude Code уже использует подобный механизм для того, чтобы помечать китайские лабы через системный промпт [разбор]. Но, опять же, это слишком наивный вариант, который убирается одним вызовом sed на клиенте. Поэтому, скорее всего, они впихнут к себе в пайплайн статистический вотермарк в сэмплере. Существует куча реализаций, но ключевых идей всего две - KGW и Christ.
KGW [ссылка] - делит словарь на “зеленый” и “красный” по
hash(ключ, предыдущие токены)
Логиты зеленых токенов повышаются на δ, со временем накапливается статистически значимый перекос, и затем с помощью ключа и токенизатора можно посчитать z-test на долю зеленых. Основная проблема такого подхода - искажение распределения: модель выбирает не то, что выбрала бы без метки (проще говоря - “пишет странно” при большой δ).
Christ - второе семейство, одну из его реализаций (SynthID-Text [ссылка]) используют в Gemini. Работает как турнир на вылет: из исходного распределения берется 2^m кандидатов и разбиваются на пары. Каждый раунд для каждого токена считается бит:
hash(ключ, предыдущие токены, номер раунда, id токена) -> 0 или 1
и в паре проходит дальше тот, у кого 1. После m раундов остаётся один победитель - он и становится следующим токеном. Турнир можно настроить так, чтобы распределение сохранялось, но разнообразие между разными ответами на один промпт все равно падает.
Но, как можно догадаться, оба этих варианта ломаются через простой запрос “перефразируй”, обращенный к локальному квену. Плюс ко всему из-за детерминированного ключа можно статистически оценить поведение схемы. И из этого вытекают такие вещи как [watermark stealing], [watermark distilation] и т.п., через которые можно потенциально атаковать токены-вотермарки (в том числе чтобы дистилить модель).
Короче хз, больше похоже на очередной выстрел в ногу конечным пользователям, потому что теперь модели могут начать писать еще менее оптимальный код в угоду этим маркерам
Чисто технически понятно, как можно помечать файлы через метаданные, но как они планируют помечать текст? Пока подробности не раскрыты, но можно предположить, отталкиваясь от существующих решений.
Самый наивный и очевидный вариант - через [unicode homoglyphs]. Claude Code уже использует подобный механизм для того, чтобы помечать китайские лабы через системный промпт [разбор]. Но, опять же, это слишком наивный вариант, который убирается одним вызовом sed на клиенте. Поэтому, скорее всего, они впихнут к себе в пайплайн статистический вотермарк в сэмплере. Существует куча реализаций, но ключевых идей всего две - KGW и Christ.
KGW [ссылка] - делит словарь на “зеленый” и “красный” по
hash(ключ, предыдущие токены)
Логиты зеленых токенов повышаются на δ, со временем накапливается статистически значимый перекос, и затем с помощью ключа и токенизатора можно посчитать z-test на долю зеленых. Основная проблема такого подхода - искажение распределения: модель выбирает не то, что выбрала бы без метки (проще говоря - “пишет странно” при большой δ).
Christ - второе семейство, одну из его реализаций (SynthID-Text [ссылка]) используют в Gemini. Работает как турнир на вылет: из исходного распределения берется 2^m кандидатов и разбиваются на пары. Каждый раунд для каждого токена считается бит:
hash(ключ, предыдущие токены, номер раунда, id токена) -> 0 или 1
и в паре проходит дальше тот, у кого 1. После m раундов остаётся один победитель - он и становится следующим токеном. Турнир можно настроить так, чтобы распределение сохранялось, но разнообразие между разными ответами на один промпт все равно падает.
Но, как можно догадаться, оба этих варианта ломаются через простой запрос “перефразируй”, обращенный к локальному квену. Плюс ко всему из-за детерминированного ключа можно статистически оценить поведение схемы. И из этого вытекают такие вещи как [watermark stealing], [watermark distilation] и т.п., через которые можно потенциально атаковать токены-вотермарки (в том числе чтобы дистилить модель).
Короче хз, больше похоже на очередной выстрел в ногу конечным пользователям, потому что теперь модели могут начать писать еще менее оптимальный код в угоду этим маркерам