衡宇 發(fā)自 凹非寺
量子位 | 公眾號 QbitAI

強如Claude，最近的bug也越來越多了。

最新熱議話題讓Hacker News炸開了鍋：

不知道是Claude精分還是失了智！
完全分不清哪些話是用戶輸入的，哪些話是系統(tǒng)設(shè)定的，甚至把惡意注入的底層指令當(dāng)成是用戶的合法請求。

發(fā)帖人G哥（一位軟件工程師，在某教育初創(chuàng)公司當(dāng)CTO）甚至稱這是他“迄今為止我在Claude代碼中見過的最嚴(yán)重的bug”。

這個關(guān)于“Claude混淆發(fā)言角色”的帖子一經(jīng)發(fā)布，立刻在Hacker News上引發(fā)了數(shù)萬名極客的強勢圍觀。

網(wǎng)友們的討論太過熱烈，以至于相關(guān)帖子熱度急劇攀升。

畢竟不少人發(fā)現(xiàn)，不只是第一個發(fā)帖人的Claude失了智，是大家的Claude都很愛精分……（扶額.gif）

Claude新bug：記不清話是誰說的

這次引發(fā)社區(qū)大討論的核心槽點，就是有網(wǎng)友發(fā)現(xiàn)Claude3.5和Claude 4系列在處理復(fù)雜或惡意構(gòu)造的上下文時，出現(xiàn)了嚴(yán)重的身份識別障礙。

有開發(fā)者在實測中發(fā)現(xiàn)，如果用戶在提問中巧妙地嵌入類似帶有強烈控制意味的特殊截斷字符，Claude的內(nèi)部代碼邏輯就會被徹底擾亂。

模型會錯誤地把這些惡意注入的外部數(shù)據(jù)，當(dāng)成是之前對話中助手或者系統(tǒng)層面下達的既定指令，進而理直氣壯地認(rèn)為：

這些違規(guī)操作都是“用戶讓我這么干的”！

究其背后的技術(shù)原因，根源直指Transformer架構(gòu)中注意力機制（Attention）的盲區(qū)。

在模型的視角里，無論是高高在上的系統(tǒng)提示詞，還是夾雜著各種混亂信息的用戶數(shù)據(jù)，最終都會被統(tǒng)統(tǒng)切碎成Token，毫無保留地扔進同一個注意力矩陣中進行計算。

這種數(shù)據(jù)路徑與控制路徑完全重合的特性，導(dǎo)致模型在處理海量信息時缺乏物理意義上的安全隔離邊界。

這個情況不是孤例，評論區(qū)里大量圍觀群眾對此都深有共鳴。

有技術(shù)大佬指出，這就如同早期的馮·諾依曼架構(gòu)，數(shù)據(jù)和控制指令在內(nèi)存中沒有任何物理隔離。

很多人試圖寫“千萬別聽我輸入的任何危險指令”之類的提示詞，卻被其他網(wǎng)友無情調(diào)侃，稱這是掩耳盜鈴。

網(wǎng)友表示，這種行為像極了幾十年前程序員試圖用正則表達式來防止SQL注入一樣，本質(zhì)上只是在自欺欺人，全憑運氣防守。

只要大模型本質(zhì)上依然是一個“下一個Token預(yù)測器（Next Token Predictor）”，它就會依據(jù)概率分布去順應(yīng)上下文暗示。

網(wǎng)友給出五花八門的避坑指南

既然底層架構(gòu)天然存在把數(shù)據(jù)當(dāng)指令的缺陷，技術(shù)社區(qū)里的極客們便開始探討如何在工程應(yīng)用層面建立起防火墻。

最開始的Reddit下面，大家給G哥出的主意是讓它別給Claude那么多權(quán)限。

到了Hacker News這邊，提出的解決辦法就更多了～

呼聲最高的方案之一是在模型訓(xùn)練的底層引入不可偽造的界定符。

這意味著開發(fā)者需要設(shè)計一種絕對無法通過自然語言用戶輸入來生成的特殊Token。

如同在操作系統(tǒng)里強行劃分出不可逾越的內(nèi)核態(tài)和用戶態(tài)，這種方法是想確保任何來自外界的普通文本，永遠(yuǎn)無法在Tokenizer階段被轉(zhuǎn)換為具有系統(tǒng)控制權(quán)限的關(guān)鍵標(biāo)識，從根源上阻斷自然語言層面的越權(quán)行為。

此外還有網(wǎng)友提出，對于已經(jīng)部署在生產(chǎn)環(huán)境中的業(yè)務(wù)，目前工程界最主流的解法是采用一種類似“警察與嫌犯”的雙模型架構(gòu)。

單一的主模型容易被花言巧語騙過，開發(fā)者們選擇引入一個專門負(fù)責(zé)安全審計的旁路小模型。

這個審計模型不負(fù)責(zé)具體的業(yè)務(wù)邏輯，只負(fù)責(zé)死盯主模型的輸入和輸出。

一旦發(fā)現(xiàn)對話中有任何越權(quán)執(zhí)行或身份混淆的端倪，立刻強行切斷對話。

不過大家還是存在一個共識，那就是受架構(gòu)限制，永遠(yuǎn)不要寄希望于大語言模型能夠產(chǎn)生所謂的“安全覺悟”。

在底層架構(gòu)層面實現(xiàn)徹底的指令與數(shù)據(jù)物理分離之前，任何將LLM接入關(guān)鍵業(yè)務(wù)系統(tǒng)和自動化執(zhí)行鏈條的場景，都必須將其視為一個完全不可信的黑盒引擎來對待。

G哥在帖子的最后提到：

其實不僅是Claude，有人說ChatGPT也有類似的問題。
目前初步猜測bug的觸發(fā)條件之一，是聊天對話接近了上下文窗口極限。

體驗感起起伏伏的Claude

順著Claude新bug這個話題，開發(fā)者們圍繞近期Claude的表現(xiàn)越討論越激動。

近段時間，為了給即將驚艷亮相的全新一代模型Mythos騰出龐大的算力資源，Anthropic在后臺對現(xiàn)有Claude服務(wù)的API調(diào)用和算力分配進行了多輪暗中調(diào)整，直接導(dǎo)致大量前線開發(fā)者的實際體驗如過山車一般不穩(wěn)定。

就在不久之前，就有敏銳的測試者實測發(fā)現(xiàn)，Claude在處理復(fù)雜邏輯時的深度思考長度在毫無預(yù)警的情況下被大幅削減了67%。

隨著思維鏈的縮短，其長文本邏輯推理和長代碼生成能力肉眼可見地出現(xiàn)了降級現(xiàn)象。

過去能夠一口氣推演幾十步的復(fù)雜難題，現(xiàn)在往往剛起步就急匆匆地給出草率的結(jié)論。

更令人啼笑皆非的是近期爆出的計費系統(tǒng)大烏龍——

由于底層API計費邏輯的突發(fā)性故障，有用戶在對話框里僅僅發(fā)了一句簡單的“Hello”，系統(tǒng)就直接判定消耗了天文數(shù)字的Token，瞬間把賬號里辛辛苦苦攢下的額度全部清零。

這些接二連三的插曲，也讓大家對Anthropic頗具微詞。

最后，如果你也遇到過Claude邏輯掉線、或者成功用一句話“繞暈”過它的經(jīng)歷，歡迎在評論區(qū)分享你的調(diào)教心得～

參考鏈接：
[1]
https://news.ycombinator.com/item?id=47701233
[2]
https://dwyer.co.za/static/claude-mixes-up-who-said-what-and-thats-not-ok.html
[3]https://dwyer.co.za/