The first lot fell to Jehoiarib, the second to Jedaiah, the third to Harim, […] and the twenty-fourth to Maaziah.

— 1 Chronicles 24:7–19

Các công ty AI đang rục rịch nhét watermark vào văn bản. Gay cấn hơn, họ có lẽ sẽ bán detector cho trường học, tạp chí, những nơi đang combat với AI-generated content. Nghĩa là họ tạo ra những con dấu vô hình (lẫn tình), rồi đưa cho người khác một cái máy dò dấu bị giấu. Chuyến này các vibe scientist như tôi lành ít dữ nhiều… Nghe đâu mỗi hãng có “một công thức bí mật,” thành ra tôi không rõ watermark kiểu này hoạt động thế nào, nên thôi thì thử làm một cái.

Ta chọn một câu đơn giản, và thay đổi nó sao cho người đọc không nhận ra, nhưng một chương trình có thể nhận ra sau này:

We postponed the launch because the database failed overnight.

TEXT = "We postponed the launch because the database failed overnight."
MARK = "\u200b"
marked = TEXT + MARK

print("human sees:    ", marked)
print("detector sees:", MARK in marked)

human sees:    We postponed the launch because the database failed overnight.​
detector sees: True

Easy. Cho đến khi ta thử tiện tay làm đẹp một tí theo nguyên tắc you get what you see, giữ lại phần plaintext có thể hiển thị:

cleaned = "".join(c for c in marked if c.isprintable())
print("detector sees after:", MARK in cleaned)

detector sees after: False

Hình dung ta có một tấm kính trong suốt được dán decal, rồi đổ một ít nước lên mặt kính. Nhìn nghiêng, ta nhận ra lớp nước đang ở đó. Nhưng khi rọi ánh sáng qua kính và nhìn bóng trên tường, thứ hiện rõ là bóng của decal; còn nước không để lại dấu vết gì.

Zero-width character tồn tại trong văn bản và detector bắt được. Nhưng sau khi câu văn đi qua một representation chỉ giữ phần plaintext hiển thị, thì marker coi như mất. Thậm chí còn chả buồn biết vị trí của watermark để phá. Ta vô tình encode dấu vết vào nước, trong khi thứ detector nhận ở bước tiếp theo là cái bóng. Thế là 404.

Cách giấu watermark này thất bại không hẳn vì detector ngu, mà vì ta đang cược khả năng phát hiện vào một vật thể lạ được chèn vào text. Một dấu vết có mặt trong văn bản gốc không đảm bảo nó sẽ tồn tại trong các hình thức biểu diễn khác của văn bản.

Take 2: Can thiệp vào quá trinh sinh text

Để ý một câu văn chứa nhiều lựa chọn. Ta có thể chọn sao cho ngữ nghĩa ổn định, trong khi bề mặt có thể biến hóa khôn lường:

We postponed the launch because the database failed overnight.

• postponed hay delayed;
• because hay after;
• the database failed hay database went down.

Thay vì chèn ký tự mới để detector tìm, ta có thể dùng chính những lựa chọn xảy ra khi câu được viết không? Giả sử ở một vị trí, model đang cân nhắc bốn chữ: postponed, delayed, deferred, moved. Bốn chữ này khác nhau, và Anthropic cũng chả ưa chúng nó như nhau. Nhưng cả bốn đều có một xác suất nào đó được chọn, ta thử biểu diễn bằng một phân phối xác suất (classic Nhatism Distribution):

weights = {
    "postponed": .40,
    "delayed":   .30,
    "deferred":  .20,
    "moved":     .10,
}

Để ý nhé, đây chính là cục xúc xắc mà bạn đã học ở trường, có điều các mặt có khả năng xuất hiện khác nhau. "postponed" vốn là chữ nghe thuận tai nhất. Ta không can thiệp ở đây. Ta chỉ bí mật chọn một vài chữ để ưu tiên hơn, rồi tăng weight:

preferred = {"postponed", "moved"}

for word in preferred:
    weights[word] *= 1.5

Sau pha này, "postponed" vẫn là lựa chọn tự nhiên nhất; còn "moved" dù được bias nhưng vẫn đội sổ như ban đầu. Gieo xúc xắc 1 2 lần thì chả có gì bí hiểm; nhưng gieo 1000 lần với cùng phân phối bias, thì luật số lớn cho biết khoảng 600 lần sẽ rơi vào nhóm preferred. (Lưu ý: 600 rolls cho ra either "postponed" or "moved", không phải riêng "postponed".)

Detector lúc này chỉ thực hiện đọc-chép đáp án. Có sẵn danh sách preferred; đọc qua đoạn văn thấy chữ nào nằm trong cái danh sách kia thì count += 1; sau cùng đếm ra preferred xuất hiện tới 60%–67% số lần thì hú.

Cơ chế watermark đơn giản đến mức hơi xúc phạm. Về bản chất, ta không chèn watermark vào bề mặt, mà giấu vào độ lệch thống kê của các lựa chọn; sau đó detector phát hiện cục xúc xắc bị nghiêng đúng như đã thiết kế.

Giao tiếp giữa embedder và detector

Code trên đang ăn gian ở chỗ: preferred = {"postponed", "moved"}. Ai đã quyết định hai chữ đó là preferred? Detector biết phải đếm hai chữ này vì ta vừa viết thẳng câu trả lời vào code. Thực tế, chỉ có đứa nào dở người mới hard-code một từ điển khổng lồ vào code.

Embedder và detector cần một luật chơi để cùng nhìn một chữ và đi đến cùng kết luận preferred or nah. Ta cần một secret key theo quy tắc:

same key + same word → same yes/no answer

Chính xác! 2 bartender ở 2 quầy Saobucks, xài cùng công thức pha chế và nguyên liệu giống nhau, sẽ cho ra 2 ly nước giống nhau dù họ chưa gặp nhau bao giờ. Hiển nhiên bạn và tôi không uống công thức. Secret key ở đây cũng vậy. Trong lập trình, để “mix” key và word thành 1 chuỗi thỏa yêu cầu, ta có hàm băm (hash function).

import hashlib

def is_preferred(word, key):
    digest = hashlib.sha256((key + word).encode()).digest()
    return digest[0] < 128

Hàm sha256() nhận key + word rồi trả về một dãy byte tất định: cùng input thì luôn ra cùng output. Ta lấy byte đầu tiên (vốn nằm từ 0 đến 255), rồi chia khoảng đó làm đôi: 0–127 là preferred; 128–255 thì nah. Với key essay-key-220 hiện tại:

is_preferred("postponed", "essay-key-220")  # True
is_preferred("delayed",   "essay-key-220")  # False
is_preferred("deferred",  "essay-key-220")  # False
is_preferred("moved",     "essay-key-220")  # True

See? Đố tìm thấy gì giấu trong postponed. Preferred bây giờ không phải một thuộc tính của bản thân chữ postponed mà là kết quả của cặp (key, word). Giữ nguyên word, đổi key:

is_preferred("postponed", "essay-key-220")  # True
is_preferred("postponed", "another-key")    # False

Đổi key, kết quả hash đổi, và cách chia vocabulary cũng đổi theo:

Detector từ key có thể tái tạo preferred list riêng mà cơ chế vẫn y nguyên.

Tôn Hành Giả, Giả Hành Tôn

Ở Take 2 ta đã watermark đơn giản trên chữ riêng lẻ. Hệ quả là với một key cố định, nếu một chữ được preferred thì nó mãi mãi là preferred; sau đó generator đẩy bias về nó. Gọi green kí hiệu $G$ là hàm cho ra chữ được ưu ái (không xài preferred $P$ để tránh nhầm hàm xác suất), khi có secret key $K$ thì ta có một cách đơn giản để quyết định chữ $w$ nào được ưu tiên. Mỗi chữ có một trạng thái cố định:

Detector ở đầu dây bên kia chỉ có secret key để tái tạo preferred list, nó không quan tâm generator bias bao nhiêu. Detector nhìn vào văn bản hiện tại và đếm tổng:

Nếu $S$ cao bất thường, detector bắt đầu nghi ngờ có watermark.

Ở suốt câu chuyện, ta đang quan tâm nhúng watermark thế nào để detector dễ dàng nhận ra. Nhìn kỹ cách làm ta nhận ra có một mối quan tâm khác. Green hay red hay whatsoever là tính chất của bản thân chữ đó chứ không dính dáng gì quyết định. Nếu $ G_K(\text{“postponed”})=1 $ thì "postponed" là green ở mọi nơi. Hai câu này đều cho "postponed" cùng một green bit:

We postponed the launch because the database failed overnight.

The team postponed the migration after several warnings.

Giả sử có một lĩnh vực quái đản sử dụng “postponed” thường xuyên; hoặc một người có thói quen thích viết chữ đó. Cứ mỗi lần họ viết “postponed”, detector lại được cộng thêm điểm. Khi đủ nhiều thiên hướng sử dụng từ vựng tình cờ khớp với green set, $S$ có thể tăng đơn giản là vì phong cách, chứ không phải vì generator đã cài watermark. Chỉ cần một người viết văn tự nhiên có gu dùng từ lệch vô tình va chạm với bảng màu cố định của secret key, tự thân sự kết hợp đó đã tạo ra một tín hiệu giả.

Nếu detector hú lên, chúc mừng bạn đã quay vào ô false positive. Nói cách khác, dấu hiệu nhận biết đang dính với bản thân các chữ, chứ chưa thực sự phản ánh lựa chọn của watermark.

Giả sử người thật việc thật viết một văn bản hoàn toàn ngẫu nhiên, đều đặn và không nghiện từ nào, tổng này sẽ quanh quẩn ở mức $0.5$ (50% green, 50% red). Detector nghĩ rằng hễ tỉ lệ green $> 0.5$ nghĩa là generator đã cố tình bịp phân phối để chọn green nhiều hơn.

Bây giờ xét văn bản không watermark nhưng có có thiên hướng dùng chữ $w$ theo phân phối $p(w)$. Ta kì vọng tỉ lệ chữ đó rơi vào green là:

Nếu green set tình cờ chứa nhiều những chữ mà văn bản này thích dùng, thì:

Ví dụ $ p(\text{“postponed”})=0.30 $ và hàm băm cũng xếp chữ này vào green list: $ G_K(\text{“postponed”}) = 1 $. Chỉ riêng một thiên hướng chọn chữ đã đóng góp $0.3$ vào green rate. Nếu 70% dung lượng còn lại chỉ cần đóng góp thêm $> 0.20$ điểm green nữa (quá dễ xảy ra) cũng tình cờ rơi vào green set, thì tỉ lệ quan sát có thể lệch khá xa khỏi $0.5$.

Chúng ta biết rằng văn bản là một chuỗi các word/token. Thay vì băm chữ riêng lẻ và hỏi chữ này có green không, thì ta thử băm nốt cả chùm dây phía trước nó và hỏi tiếp:

Ở context này, chữ này có green không?

Để quyết định chữ thứ $i$, ta xét thêm một khoảng context gồm $n$ chữ đứng trước nó:

Hàm quyết định ưu ái green khi có thêm context là

Bây giờ cùng một chữ có thể có trạng thái khác nhau tùy vào context. Tức “postponed” tự nó không còn mang một trạng thái green cố định nữa. Cách nhận diện watermark đã phức tạp lên đáng kể. Tức một chữ thuộc green ở chỗ context này có thể là red ở chỗ khác (tôi gọi red cho nó đủ cặp). Vì vậy detector sẽ chú ý thằng generator cứ chọn đi chọn lại chữ green trong context nào đó:

Giả sử một người thật viết một văn bản $T$ có độ dài $N$, hoàn toàn không được watermark:

Ta xét tính chất pseudorandom của hàm băm. Một thay đổi rất nhỏ ở input, thậm chí chỉ một bit có thể làm output thay đổi mạnh và khó đoán. Giờ xét null hypothesis: văn bản không chứa watermark. Ta giả sử hàm băm sẽ chia vùng green/red cân bằng, tức với một cặp context–word bất kỳ:

Điểm quan trọng là mỗi lần một chữ xuất hiện, nó đi cùng một context $C$ có thể khác nhau. Vì vậy, hàm băm nhìn vào toàn bộ cặp $(C,w_i)$. Dưới null hypothesis, xác suất để input đó rơi vào green hoặc red xấp xỉ cân bằng:

Từ đó, với cách detector tính thống kê:

ta có:

Một văn bản có thể thích dùng “postponed” bao nhiêu cũng được. Mỗi lần xuất hiện của “postponed” lại được đánh giá trong context khác, chứ không còn được ánh xạ trực tiếp thành tín hiệu green. Nói đơn giản, context càng giàu, watermark càng ít phụ thuộc vào ý chí chọn chữ của người viết. Băm cùng context, dưới giả định hàm băm ngẫu nhiên, vì thế loại bỏ một nguồn false positive do thiên hướng dùng từ vựng.

Hooman has entered the chat

Dĩ nhiên tâm lý con người xài AI thì phải sửa xóa vài chỗ. (Lí do tại sao thì tôi và bạn ngầm hiểu với nhau là được). Thử táy máy sửa:

A B C D E F G
    ↓
A B X D E F G

Nhắc lại: lúc nhúng watermark, ta hash chung với context, nên quyết định green tại vị trí $i$ phụ thuộc vào một đoạn lịch sử lựa chọn nằm kề trước nó. Vấn đề là các context này chồng lấn nhau:

[A B C D] -> E
    [B C D E] -> F
        [C D E F] -> G

Một thay đổi nhỏ trong input có thể làm output hash thay đổi mạnh, từ đó cho ra một watermark state hoàn toàn khác. Vì các context chồng lấn nhau, thay đổi ở một token không chỉ ảnh hưởng đến quyết định ngay tại nó, mà còn có thể kéo theo các context phía sau. Giả sử context là $n$ chữ kề trước, thì phụ thuộc của một token có dạng:

với $G_j = G_K(C,w_j)$. Nói cách khác, một chỉnh sử ở $w_j$ có thể làm thay đổi tới $n+1$ watermark decisions, dẫn đến một chuỗi thay đổi trong watermark signal.

Ở chiều ngược lại, static hash đơn thuần $G_K(w_i)$, quyết định tại vị trí $i$ chỉ phụ thuộc vào chính $w_i$, nên đối với chỉnh sửa ở $i$ những quyết khác không ảnh hưởng; nhưng phải trả giá bằng việc signal phụ thuộc khá mạnh vào word identity, dễ gây false positive hơn.

Quay lại vấn đề của context. Dù có thêm context giúp giảm false positive song lộ ra điểm yếu ở chỗ mọi thứ trong context đều có quyền ảnh hưởng tới quyết định hiện tại. Vậy nếu ta vẫn muốn giữ context, nhưng chỉ cho một (hoặc vài) vị trí làm input cho hàm băm thì sao? Ta gọi các vị trí này là anchor/điểm neo cho quyết định:

Context:
[A B C D E F G H]

Full contextual:
[A B C D E F G H] -> X
 ^ ^ ^ ^ ^ ^ ^ ^

Anchor-based:
[A B C D E F G H] -> X
       ^       
    anchor

Miễn hooman thay đổi chữ ở những vị trí khác anchor thì X hiển nhiên vẫn bảo toàn tính mạng green/red.

Random, but not arbitrary

Ta không muốn anchor là một vị trí cố định trong context. Giả sử context gồm 8 chữ mà ta lấy cố định vị trí 4 luôn thì sao? Chúng ta đã quay lại băm context thuần ở mức cục bộ, chỉ khác là băm một thay vì băm cả 8 =)) Cách này không tận dụng được context như một cái hồ chứa bằng chứng watermark nữa. Btw, chúng ta cũng không nên tặng attacker bia tập bắn.

Anchor linh động cho phép các phần khác nhau của context, nói rộng ra là lịch sử, có cơ hội tham gia vào watermark. Nhưng. Nếu chọn anchor bừa thì detector sau này sẽ hoạt động bằng niềm tin. Vì vậy ta cần một cách để chọn anchor mà cả embedder và detector đều bói ra được. Cụ thể yêu cầu thuật toán chọn vị trí sao cho:

• ngẫu nhiên về mặt vị trí;
• và detector vẫn có quy luật để biết.

Thật tình cờ hàm băm sẽ băm 8 chữ trong context thành 8 giá trị digest ngẫu nhiên. Nhưng ngẫu nhiên cỡ nào thì chắc chắn trong phạm vi đó ta luôn xác định được một phần tử có digest nhỏ nhất / lớn nhất. Voilà!

Giả sử context ta lấy 8 chữ:

[A, B, C, D, E, F, G, H]
hash(key,A) = 82
hash(key,B) = 14  <- min
hash(key,C) = 95
hash(key,D) = 41
hash(key,E) = 73
hash(key,F) = 56
hash(key,G) = 31
hash(key,H) = 67

anchor position = 2
anchor word     = B

Đối với context khác thì thứ tự có thể thay đổi, nên anchor có thể cũng đổi theo. Vậy lúc này quyết định green hay không sẽ là:

với $a$ là vị trí anchor trong context $C$ và $c_a$ là chữ đóng vai trò anchor.

Anchor có thực sự làm statistic của detector “sạch” hơn dưới null hypothesis hay không thì không còn hiển nhiên nữa. Lúc này phải nhìn vào variance, correlation, và cuối cùng là empirical test.

Sinh văn bản

Để thí nghiệm trò nhúng watermark này, chúng ta cần bộ sinh văn bản, bản chất là streaming các lựa chọn nối nhau, thì mới có cái để can thiệp. Nhắc lại weights ở đầu bài này chứa các options cho một lựa chọn, một cục xúc xắc có các mặt nặng nhẹ khác nhau chờ được bịp. Tôi đã nhét vào những con số rất đẹp, nhưng nó từ đâu ra, nếu như không phải tuân theo Nhatism distribution? Chẳng hạn đang xổ văn bản ở vị trí “far as I…” thì lựa chọn tiếp theo là:

# "far as I..."
weights = {
    "can": 0.2857, "am": 0.2143, "know": 0.1429,
    "have": 0.1071, "could": 0.1071, "was": 0.0714,
    "recollect": 0.0357, "knew": 0.0357}

Đó là kết quả của quá trình training (nói trắng ra là đếm) trong một tập văn bản tiếng Anh đủ dài. Model nhìn vào 3 token kề nhau, gọi là context, lấy danh sách các chữ từng xuất hiện kèm tần số của chúng nó. Mỗi khi tập training có chuỗi context là "far as I" thì "can" xuất hiện ngay sau đó với số lần nhiều hơn "am" nên nó có weight nặng hơn. Ví dụ

A B C D E
└───────┘

ta quan tâm bao nhiêu lần:
[A, B, C] → D
[B, C, D] → E

Khi đem chia tần số mỗi option cho tổng lần context xuất hiện trên toàn tập train, thì ra được xác suất tương đối, lưu vào weights. Đến lúc sinh chữ, thì cái context đó lại trượt sang phải, 3 token mới nhất lại được dùng để lookup chữ tiếp theo.

Chính xác! Mô hình n-gram / Markov model: nhìn vào n-1 token gần nhất để tính xác suất cho token tiếp theo. Ví dụ trên tôi đã dùng 4-gram, train trên vài quyển sách, và tôi cam đoan những con số đó là công trình nghiên cứu của tác giả và hoàn toàn trung thực.

Model chả cần hiểu nó đang nói gì, và cũng chả buồn viết đúng ngữ pháp. Nó chỉ cần tạo ra đủ nhiều options ở mỗi bước để chúng ta nghịch. We are NOT building our own LLM.

Nhúng watermark

Ta trước tiên cần hàm quyết định green/red và hàm thống kê cơ bản.

def is_green(anchor, key, word):
    h = hashlib.sha256(f"{anchor}|{key}|{word}".encode()).digest()
    return h[0] < 128
    
def normalize(weights):
    total = sum(weights.values())
    if total <= 0:
        return {k: 1.0 / len(weights) for k in weights}
    return {k: v / total for k, v in weights.items()}
    
def sample_token(probs):
    roll = random.random()
    cum = 0.0  # not the cum you think
    for word, p in probs.items():
        cum += p
        if roll < cum:
            return word

Hàm lấy lựa chọn khả dĩ cho word/token tiếp theo, chính là các mặt của cục xúc xắc, trả về danh sách lựa chọn kèm xác suất của chúng.

# context = tokens[pos-3:pos]  model looks here to predict next word
# history = tokens[pos-8:pos]  watermark looks here to choose anchor
# model = pickle.load(f)       a dict you may ignore
def get_next_token_probs(model, context, pre=3):
    context = context[-pre:]
    key = " ".join(context)
    counts = model["context_counts"][key]
    total = sum(counts.values())
    return {  # probs
        word: count / total
        for word, count in counts.items()
    }

>>>> get_next_token_probs(model, ['far', 'as', 'I'])
{'can': 0.2857142857142857, 'am': 0.21428571428571427, 'know': 0.14285714285714285, 'have': 0.10714285714285714, 'could': 0.10714285714285714, 'was': 0.07142857142857142, 'recollect': 0.03571428571428571, 'knew': 0.03571428571428571}

Tiếp theo là gương mặt thân quen ở đầu bài, nhận cái cục xúc xắc và bơm chì vào những mặt green cho nó nặng hơn:

def watermark(probs, anchor, key="essay-key-220", boost=2.5):
    rigged = {}
    for word, p in probs.items():
        if is_green(anchor, key, word):
            p = p * boost
        rigged[word] = p                
    return normalize(rigged)  # weights

Hàm tìm anchor là phần tử có hash nhỏ nhất:

def get_history_window(tokens, pos, W=8):
    return tokens[max(0, pos-W):pos]

def select_anchor(history):  # min
    anchor = history[0]
    anchor_hash = hashlib.sha256(anchor.encode()).digest()

    for word in history[1:]:  # sliding
        h = hashlib.sha256(word.encode()).digest()
        if h < anchor_hash:
            anchor = word
            anchor_hash = h

    return anchor

>>>> history = ["Sherlock", "Holmes", "was", "at",
     "breakfast", "in", "Baker", "Street"]
>>>> for w in history:
>>>>    h = hashlib.sha256(f"{w}".encode()).digest()
>>>>    h = int.from_bytes(h[:4], byteorder="big")
>>>>    print(f"  hash('{w:<10}') = {h}")
hash('Sherlock  ') = 1704073805
hash('Holmes    ') = 263963812
hash('was       ') = 3057359350
hash('at        ') = 2983639323
hash('breakfast ') = 2086201893
hash('in        ') = 1479108435
hash('Baker     ') = 3082403423
hash('Street    ') = 3328596253

>>>> select_anchor(history)
'Holmes'

Bây giờ chỉ việc đọc prompt mồi, tìm token hợp lý, bịp, sinh chữ…

def generate(model, prompt, length, key, boost=2.5, pre=3, W=8):
    tokens = prompt.split()

    for _ in range(length):
        context = tokens[-pre:]        # 4-gram so pre = 3
        history = tokens[-W:]          # watermark history

        probs  = get_next_token_probs(model, context)
        anchor = select_anchor(history)
        probs  = watermark(probs, anchor, key, boost)  # rig it

        word = sample_token(probs)
        tokens.append(word)

    return tokens

>>>> " ".join(generate(model, "far as I", 30, "essay-key-220"))
'far as I could see in the clouds . Manderson , ” said he . ' " The solicitors had , in fact , faintly sulky . ” A step was heard on'

Người phán xử

Ôn nhanh một chút về kiểm định giả thuyết (hypothesis testing). Ta bắt đầu với một giả thuyết gốc $H_0$, ở đây là “văn bản tự nhiên con người viết”. Từ $H_0$, ta biết hoặc ước lượng được phân phối của một statistic nếu dữ liệu thực sự chỉ là ngẫu nhiên. Sau đó ta xem statistic quan sát được lệch khỏi kỳ vọng của $H_0$ bao nhiêu. Nếu độ lệch đủ lớn, ta có bằng chứng để bác bỏ $H_0$ tức là văn bản có watermark.

Ở đây statistic của ta là số token green, $G$. Dưới $H_0$, tức là văn bản không được watermark, model cho ta kỳ vọng $\mu$ và variance $V$ của số green. Ta chuẩn hoá độ lệch bằng z-score:

Nói nôm na, $z$ trả lời một câu số green mà tôi vừa thấy cách kỳ vọng tự nhiên bao nhiêu (độ lệch chuẩn)? Một $z$ nhỏ có thể dễ dàng xảy ra do ngẫu nhiên; một $z$ lớn thì ngày càng khó giải thích nếu $H_0$ là đúng. Vì vậy detector không chỉ hỏi “có nhiều green không?”, mà hỏi “có nhiều green hơn mức model tự nhiên kỳ vọng, đến mức đáng ngờ không?”

def green_indicator(anchor, key, word):
    return int(is_green(anchor, key, word))

def green_probability(probs, anchor, key):
    return sum(
        p for word, p in probs.items()
        if is_green(anchor, key, word)
    )

def detect(tokens, model, key, W=8, pre=3):
    G = mu = V = 0.0

    for t in range(pre, len(tokens)):
        context = tokens[t-pre:t]
        history = tokens[t-W:t]

        probs = get_next_token_probs(model, context)
        anchor = select_anchor(history)

        G += green_indicator(anchor, key, tokens[t])

        q = green_probability(probs, anchor, key)
        mu += q
        V += q * (1 - q)

    z = (G - mu) / math.sqrt(V)
    return z

Với vị trí $i$, ta có $C =(w_{i-n},\ldots,w_{i-1})$. Khi đó:

Tức giữ nguyên context $C$, nhìn vào toàn bộ phân phối từ mà model có thể sinh ra, rồi cộng xác suất của những token được hash thành green. Ví dụ nếu ở context hiện tại model cho:

thì:

Tức là ngay cả khi không watermark, với context này model vốn đã có $60\%$ xác suất chọn một token green. Đây chính là lý do ta không thể chỉ nhìn $S$ rồi phán “nhiều green = watermark”. Từ đó nối thẳng sang detector, thì số green quan sát được là:

Còn số green model tự nhiên kỳ vọng là:

Mỗi token thứ $i$ được xem như một phép thử Bernoulli độc lập có xác suất thành công (màu green) là $q_i$. Phương sai của một biến Bernoulli là $q_i(1-q_i)$.Vì các bước được giả định là độc lập (detector nhận văn bản chết cố định), tổng phương sai $V$ đơn giản là tổng các phương sai thành phần:

Cuối cùng:

Detector thấy $S$ green. Nhưng với chính những context này, model vốn đã kỳ vọng $\mu$ green. Vậy phần green dư ra có lớn đến mức bất thường không.

Detector Output for 30 streamed words:
  tokens_evaluated    : 30
  green_count         : 24
  green_rate          : 0.8
  expected_green      : 20.85
  variance            : 3.15
  std_dev             : 1.77
  excess              : 3.15
  z_score             : 1.777
  detected            : False

Oops. Chẳng phải ta đã watermark rồi hay sao. Nhưng detector bảo là False? 24/30 green không hề đồng nghĩa với “đã phát hiện watermark”. Với sample chỉ có 30 token, một vài lựa chọn green thêm vào đã có thể đẩy tỷ lệ từ 50% lên 80%. Detector phải tự kiềm chế và nói có tín hiệu hơi đáng ngờ, nhưng chưa đủ dữ liệu để kết luận. Cái False vì thế là ví dụ rất phản trực giác but but 80% green. Muốn có bằng chứng thống kê, ta cần tín hiệu đủ lớn và sample đủ dài.

Xóa dấu vết

Cả bài ta đã đi qua 3 cách quyết định một chữ/token có được ưu ái hay không: Static Word Hash (Take 2), Full Contextual Hash, và Anchor. Cả ba đều tạo ra cùng một loại tín hiệu là tăng xác suất chọn một nhóm token, nhưng khác nhau ở một điểm quan trọng: bao nhiêu phần của history có quyền ảnh hưởng đến quyết định hiện tại.

Vì vậy, thay vì chỉ hỏi watermark có detect được không? ta muốn xem chuyện gì xảy ra khi văn bản bị sửa. Một watermark tốt là watermark sống sót sau những lần hooman cố tình sửa.

Ta dùng cùng một language model và cùng prompt để tạo các văn bản mẫu. Sau đó tiến hành chỉnh sửa và đo tín hiệu watermark còn sót lại. Robustness:

Baseline: Với cùng cấu hình trên, cả ba scheme đều đạt 100% detection trên 5 clean generations: Static $z=6.93$, Contextual $z=8.10$, Anchor $z=6.78$.

Ở 5% edit, Anchor giữ được khoảng 87–95% signal, trong khi Full Contextual chỉ khoảng 75–84%. Khi edit nặng 20%, cả ba đều suy giảm; Anchor không miễn nhiễm, nhưng đặc biệt giữ lợi thế rõ rệt trước insertion và mixed edits.

Tập trung vào riêng Anchor toi còn tò mò edit làm hỏng history (8 token phía trước) đến mức nào, và trong số đó anchor thực sự đổi bao nhiêu. Ở mức 5% edit, history của một token bị thay đổi ở khoảng 34% vị trí, nhưng anchor chỉ thay đổi khoảng 6–8%. Nói cách khác, phần lớn những thay đổi của history không đủ mạnh để thay đổi “token đại diện” mà watermark đang bám vào. Anchor làm cho watermark ít quan tâm đến những thay đổi nhỏ của history.

Bonus: lexical preference

Ở bảng đầu tiên Static Word Hash chiếm ưu điểm khá lớn, nhưng nên nhớ ta vẫn còn false positive. Một câu hỏi ngược lại: liệu một văn bản không hề biết key nhưng có một thiên hướng từ vựng nào đó vô tình trông giống watermark hay không?

Setup: 100 văn bản × 500 keys, Static Word Hash. False positive nghĩa là có một văn bản vượt ngưỡng ($z \ge 4$) cho ít nhất 1 key.

Với văn bản bình thường, detector vẫn khá ổn áp, không có sample nào vượt $z=4$. Seems right. Nhưng tôi chơi key-blind lexical-preference test: trong lúc generate, tôi cố tình tăng xác suất của một nhóm verb (hành văn của tôi là verb-centric btw) như speech verbs, perception verbs, motion verbs, hoặc các nhóm mixed mà không hề nhìn vào watermark key hay green/red labels. Kết quả mới này lộ ra failure mode: một số lexical preference tình trùng với green vocabulary và đẩy $z$ vượt 4.

Tôi đã xài thêm fox stoplist để chặn những signal từ stopwords (các từ hầu hết chả mang tí thông tin gì) và các chữ mang tính grammar / structural… Người hay máy thì cũng xài mấy chữ này thôi, nên chả có nhiều giá trị để mà phân biệt.

Để ý preference motion từ ×2 lên ×3 không chỉ đơn giản là “thêm signal”. Preference mạnh hơn làm phân phối token thay đổi nhiều hơn dẫn đế trajectory của cả văn bản cũng đổi, nên dù có ×3 có thể vô tình đi vào những vùng ít thuận lợi cho một static green partition nào đó. Vì vậy con số FP ở bảng trên không nhất thiết tăng đơn điệu.

Đồ chơi

Đồ chơi có sẵn ở Github: nhatism/toys. Cơ bản là chạy train ngrams -> lưu pkl -> vào notebook nghịch. Mọi người muốn chạy thí nghiệm phá phách gì đó thì prompt AI. Chuyện muỗi ấy mà.

watermark/
      ├── corpus/ (txt files + license)
      ├── notebooks/
      │    └── anchor-watermark.ipynb
      └── src/
           └── train.py

Mọt sách

• Green-list / red-list: Kirchenbauer et al. (2023) — cách tiếp cận kinh điển: hash context để chia vocabulary thành Green/Red rồi bias sampling về Green tokens.
• Distortion-free watermarking: Kuditipudi et al. và SynthID-Text — thay vì bias token distribution, watermark nằm trong cách sampler sử dụng keyed randomness, hướng tới giữ nguyên chất lượng sinh.
• Semantic watermarking: SemStamp và SIR — chuyển signal từ token identity sang semantic representation, với mục tiêu sống sót tốt hơn qua paraphrase.
• Post-hoc watermarking: PostMark — không cần can thiệp trực tiếp vào sampler; signal được thêm sau generation dựa trên semantic content.
• Robustness: Đây là trade-off xuyên suốt các hướng trên: token-level schemes khá đơn giản nhưng dễ mất signal khi rewrite mạnh, trong khi semantic schemes robust hơn nhưng thường đắt và phức tạp hơn.
• Survey: Liu et al., A Survey of Text Watermarking in the Era of Large Language Models — nếu muốn nhìn toàn bộ landscape trong một chỗ.

Bài viết từ 2019 nên có thể lỗi thời hoặc tác giả chưa đủ chín chắn tại thời điểm đó. Read at your own risk.

Giới thiệu

Bài toán phân loại (classification)

Giả sử chúng ta cần chia khách hàng ra làm hai loại/lớp (category/class) dựa vào nguồn lợi họ đem lại cho công ty: khách hàng nhỏ và khách hàng lớn. Về cơ bản, nguồn lợi được tính theo giá mặt hàng và số lượng khách mua. Như vậy, ta sẽ biểu diễn khách hàng theo hai yếu tố trên trên mặt phẳng:

Bài toán của chúng ta là từ những điểm xanh và đỏ cho trước (tức marketer đã xác định), hãy xây dựng một quy tắc phân loại để dự đoán class của điểm màu xám. Nói cách khác, chúng ta cần xác định một biên giới để chia lãnh thổ của hai class này, rồi với điểm cần phân loại màu xám ta chỉ cần xem nó nằm ở phía bên nào của đường biên giới là xong. Biên giới đơn giản nhất (theo đúng nghĩa toán học) trong mặt phẳng là một đường thằng (đường màu đen trong hình), trong không gian ba chiều là một mặt phẳng, trong không gian nhiều chiều là một siêu phẳng (hyperplane, một không gian có số chiều nhỏ hơn không gian chứa nó một chiều).

Lưu ý rằng các khái niệm lớp, nhãn, danh mục ở bài toán phân loại là tương tự nhau.

Perceptron

Perceptron Learning Algorithm, gọi ngắn là Perceptron, là một thuật toán giúp chúng ta thực hiện công việc phân loại với hai lớp như trên, ta sẽ gọi hai lớp này là {+1, -1}. Thuật toán ban đầu được Frank Rosenblatt đề xuất dựa trên ý tưởng mô phỏng neuron sinh học, nó nhanh chóng tạo nên tiếng vang lớn trong lĩnh vực AI. Không giống như Naive Bayes - một thuật toán phân loại bằng cách tính xác xuất trên toàn bộ tập dữ liệu (batch learning), Perceptron sẽ đọc từng dữ liệu và điều chỉnh biên giới sao cho tất cả các điểm nằm cùng một phía của biên giới có nhãn giống nhau (online learning).

Linear Separability

Một nhược điểm của Perceptron là nó chỉ hoạt động thực sự tốt khi dữ liệu phân tách tuyến tính (linearly separable), tức có thể dùng đường thẳng, mặt phẳng, siêu phẳng để làm biên giới, nếu dữ liệu không thỏa điều kiện này, không những Perceptron mà bất kì thuật toán phân loại tuyến tính nào cũng sẽ fail “nhè nhẹ”. Điều này dẫn đến một khái niệm quan trọng là Linear Seperability.

Cho vector $ \bold{x}_i $ biểu diễn một dữ liệu, $y_i$ là nhãn của $\bold{x}_i$ và $f(\bold{x}_i, y_i) = y_i \bold{x}_i$ là feature function của dữ liệu, tập dữ liệu này được gọi là linearly separable nếu tồn tại một vector trọng số $\bold{w}$ và một margin $p > 0$ sao cho:

\(\forall (\bold{x}_i, y_i) \in Dataset, \ \ \bold{w} \cdot f(\bold{x}_i, y_i) \geq p + \bold{w} \cdot f(\bold{x}_i, y')\) với $y’$ khác $y_i$, là nhãn của lớp còn lại. Điều này khá dễ hiểu vì khi $\bold{x}_i \cdot \bold{w}^\top$ cùng dấu với $y_i$, tức phân lớp đúng, thì tích của chúng không âm.

Ví dụ ta có vector trọng số $\bold{w} = [1, 1]$ và vector $\bold{x} = [2, 2]$ có nhãn $y = 1$, như vậy thay vào công thức trên ta được:

\(1 [2, 2] \cdot [1, 1] \geq p + (-1)[2, 2] \cdot [1, 1]\) \(\Leftrightarrow 4 \geq p + (-4) \Leftrightarrow p \leq 8\)

Nói cách khác, dữ liệu là linearly separable khi hai tập bao lồi các điểm của hai lớp không giao nhau.

Dữ liệu trên thực tế thường hiếm khi linearly separable là một hạn chế cho Perceptron, tuy nhiên Perceptron vẫn là nền tảng cho các thuật toán Neural Network hay Deep Learning sau này.

Thuật toán Perceptron

Chúng ta có đường nét đứt là biên giới phân lớp. Thuật toán sẽ dùng đường biên giới để thử phân loại dữ liệu, với mỗi lần phân loại thử bị sai, thuật toán sẽ điều chỉnh lại biên giới. Ở hình bên trái, có một điểm xanh nằm cùng lãnh thổ với các điểm màu đỏ, do đó nó bị thuật toán phân loại sai. Thuật toán sẽ điều chỉnh biên giới sao cho điểm này dần được đưa về lãnh thổ của các điểm xanh.

Trước đó ta đã đề cập: \(y_i \bold{x}_i \cdot \bold{w}^\top \geq p + y' \bold{x}_i \cdot \bold{w}^\top\)

Vì $p > 0$ nên \(y_i \bold{x}_i \cdot \bold{w}^\top > y' \bold{x}_i \cdot \bold{w}^\top \ \ \ \ \ (1)\) Vì $y’ = -y_i$, từ $(1)$ suy ra $y_i \bold{x}_i \cdot \bold{w}^\top > 0$, do đó $y’ \bold{x}_i \cdot \bold{w}^\top < 0$.

Ta có hàm $\cos$ của hai vector:

Quay về $(1)$, với vế trái là tích của hai vector $y_i \bold{x}_i$ và $\bold{w}$ là không âm ta có: \(y_i \bold{x}_i \cdot \bold{w}^\top \geq 0 \Leftrightarrow \cos(y_i \bold{x}_i, \bold{w}) \geq 0 \ \ \ \ \ (2)\) Vế bên phải cũng tương tự: \(y' \bold{x}_i \cdot \bold{w}^\top < 0 \Leftrightarrow \cos(y' \bold{x}_i, \bold{w}) < 0 \ \ \ \ \ (3)\) Gọi $\alpha$ là góc giữa hai vector $y_i\bold{x}_i$ và $\bold{w}$. Theo định nghĩa, góc giữa hai vector nằm trong đoạn $[0\degree,180\degree]$.

Ở (2), $\cos(y_i\bold{x}_i,\bold{w}) \geq 0$, nên:

Tương tự với (3), nếu góc giữa $y’ \bold{x}_i$ và $\bold{w}$ là $\alpha’$, thì:

Như vậy các feature vector $y_i \bold{x}_i$ và $y’ \bold{x}_i$ phải hợp với $\bold{w}$ một góc lần lượt là $\alpha$ và $\alpha’$, ta hình dung được lãnh thổ của mỗi class:

$\bold{w}$ vuông góc với biên giới phân lớp. Do đó với mọi vector nằm cùng một phía của biên giới, tích vô hướng của chúng với $\bold{w}$ có cùng dấu và mô hình sẽ dự đoán chúng thuộc cùng một class. Khi vector $\bold{w}$ xoay bao nhiêu thì biên giới cũng xoay bấy nhiêu để đảm bảo chúng vuông góc nhau, đây là câu trả lời tại sao $\bold{w}$ quyết định biên giới phân lớp.

Cập nhật

Việc cập nhật sẽ diễn ra khi thuật toán đoán sai nhãn của dữ liệu học. Khi phải đoán một điểm dữ liệu, thuật toán không hề biết trước nhãn/lớp của nó, thuật toán sẽ tính nhãn dự đoán từ dấu của $\bold{x}_i \cdot \bold{w}^\top$.

Chúng ta có hai trường hợp phải cập nhật:

• Khi nhãn dữ liệu là +1 và đoán thành -1.
• Khi nhãn dữ liệu là -1 và đoán thành +1.

Ta sẽ xem xét trường hợp đầu tiên, $y_i = +1$ và $y’ = -1$. Ở phần trên đã đề cập, khi dự đoán đúng nhãn $y_i$: \(y_i \bold{x}_i \cdot \bold{w}^\top \geq 0 \ \ \ \ \ (4)\) Vì $y_i = +1$ nên để thỏa (4), thì $\bold{x}_i \cdot \bold{w}^\top \geq 0$. Nhưng vì dự đoán sai nên hiện tại $\bold{x}_i \cdot \bold{w}^\top < 0$, dẫn đến không thỏa $(4)$. Cũng có:

Mục đích cập nhật ở trường hợp này là điều chỉnh lại (\bold{w}) sao cho:

Vậy phải điều chỉnh $\bold{w}$ làm sao để $\alpha \leq 90\degree$? Ta có quy tắc hình bình hành:

Khi cập nhật $\bold{w} \leftarrow \bold{w} + \bold{x}_i$, ta có $\bold{x}_i \cdot (\bold{w} + \bold{x}_i)^\top = \bold{x}_i \cdot \bold{w}^\top + |\bold{x}_i|^2$. Vì $|\bold{x}_i|^2 > 0$, phép cập nhật làm tăng giá trị $\bold{x}_i \cdot \bold{w}^\top$, tức đưa điểm dữ liệu theo hướng dễ được phân loại đúng hơn. Như vậy công thức cập nhật khi nhãn dữ liệu là +1 và đoán sai thành -1 là: \(\bold{w} \leftarrow \bold{w} + \bold{x}_i\)

Suy luận tương tự với trường hợp nhãn dữ liệu là -1 và đoán sai thành +1, công thức cập nhật: \(\bold{w} \leftarrow \bold{w} - \bold{x}_i\) Ta có công thức cập nhật tổng quát mỗi khi thuật toán đoán sai, với $y_i$ là nhãn chính xác của dữ liệu: \(\bold{w} \leftarrow \bold{w} + y_i\bold{x}_i\)

Thuật toán

Thuật toán được viết gọn như sau:

Với hàm $sgn(x) = 1$ nếu $x \geq 0$ và $sgn(x) = -1$ nếu $x < 0$.

Averaged Perceptron

Nếu dữ liệu linearly separable, Perceptron sẽ dừng lại một khi tìm được biên giới phân loại chính xác, còn không nó sẽ luẩn quẩn giữa các trọng số mà không hội tụ lại. Một giải pháp cho trường hợp này là lấy trung bình các vector $\bold{w}$ trong quá trình học để thu được một trọng số ổn định hơn. Thông thường thuật toán được chạy trong một số vòng lặp xác định trước, sau đó sử dụng trọng số trung bình để dự đoán. Cách làm này cần thêm chi phí để duy trì trọng số trung bình, nhưng vẫn có thể cài đặt khá hiệu quả.

Một cách khác là ta sử dụng một tập kiểm tra ở ngoài, khi độ chính xác trên tập này bắt đầu giảm, có thể thuật toán đang dần overfit và ta dừng ở đây. Cách làm này gọi là early stopping.