谷歌工程師花3個月填的坑：LLM過得了類型檢查

你的大語言模型（LLM）輸出通過了Pydantic驗證，JSON格式完美，字段一個不少。然后它給用戶回了句："我寧愿挖掉自己的眼睛。"

類型檢查全綠，用戶體驗全崩。這就是"語義鴻溝"——結構正確和意思正確之間的那道裂縫。每個上線LLM功能的團隊遲早都會踩進去。谷歌工程師Yoav Hebron踩了太多次，干脆自己造了個工具叫Semantix。

現在的驗證，只查"長得像不像"

大部分團隊的驗證代碼長這樣：定義一個Response類，規定message必須是字符串，tone必須是"polite"、"neutral"或"firm"三選一。Pydantic會確保返回的JSON格式對、類型對、枚舉值也對。

但它完全不管這句話到底什么意思。

模型可以返回{"message": "滾開。", "tone": "polite"}，Pydantic照單全收。你的系統日志一片祥和，用戶已經截圖發推特了。

Hebron在GitHub上吐槽過這個痛點：「我們花了太多時間寫正則表達式來抓"抱歉，我不能"這種委婉拒絕，結果發現模型換個說法就繞過去了。」

這是結構性驗證的死穴——它只保證語法樹正確，不保證語義樹正確。

Semantix的解法：讓文檔字符串當合同

Semantix把驗證邏輯整個翻轉。不再檢查輸出長什么樣，而是檢查輸出想干什么。

用法很Pythonic：你寫一個繼承自Intent的類，文檔字符串（docstring）就是驗收標準。比如ProfessionalDecline的docstring寫清楚——"必須禮貌拒絕邀請，不能粗魯或攻擊性"。然后加個@validate_intent裝飾器，完事。

底層有個"裁判"（judge）來執行這個合同。可以是另一個LLM、自然語言推理模型（NLI），或者嵌入向量相似度。裁判讀輸出，讀要求，然后判定：這段文字真的做到了它聲稱的事嗎？

v0.1.3版本的核心功能是"知情重試"（informed retries）。驗證失敗時，裝飾器不會盲目重發請求，而是給LLM一份結構化的Markdown診斷報告。

報告里有什么：意圖名稱、置信度分數、未通過閾值、裁判的具體理由、原始要求原文、被駁回的輸出全文。LLM拿到這份反饋，相當于考試完立刻知道哪道題錯了、為什么錯、正確答案長什么樣。

Hebron在發布說明里打了個比方：「以前的重試像蒙眼扔飛鏢，現在把靶子畫在墻上了。」

從LLMJudge到NLIJudge：默認裁判換了人

Semantix最近把默認裁判從LLMJudge換成了NLIJudge。NLI是自然語言推理（Natural Language Inference）的縮寫，專門判斷"前提是否蘊含假設"——正好匹配"輸出是否符合意圖"這個需求。

換裁判的原因是成本和延遲。LLMJudge每次驗證都要調一次大模型，NLIJudge用輕量模型就能跑。Hebron在issue里提過數據：同樣驗證1000條輸出，NLIJudge把成本從$4.7壓到$0.3，延遲從2.3秒降到180毫秒。

但NLI也有 trade-off。它對明確的蘊含/矛盾判斷很準，遇到灰色地帶會保守地判"中立"。有些團隊需要更細膩的語義理解，還是會選LLMJudge，或者自己訓一個。

Semantix的設計留了接口，換裁判就是改個參數的事。

反饋循環：LLM能從自己的錯誤里學習嗎

知情重試的真正價值，在于把驗證失敗變成了訓練信號。

傳統做法里，LLM輸出錯了，系統要么直接報錯給用戶，要么默默重試幾次然后放棄。LLM不知道自己錯了，更不會知道錯在哪。下次遇到類似場景，繼續犯同樣的錯。

Semantix的反饋報告讓LLM在單次請求內完成"嘗試-失敗-學習-再嘗試"的循環。雖然不是真正的權重更新，但上下文里的錯誤示例和修正指導，對in-context learning很有效。

Hebron放了個例子：第一次調用返回"Go away."，裁判判"too vague"。第二次調用帶上反饋報告，LLM學會了，輸出變成"I appreciate the invitation, but I won't be able to make it." 通過。

這個機制對提示工程（prompt engineering）也有副作用。以前要花大量時間寫"不要XX""避免YY"的負面指令，現在可以把要求寫在Intent的docstring里，讓裁判去抓違規。提示詞變干凈了，維護成本也低了。

誰在用它，以及邊界在哪

從GitHub倉庫的issue和討論看，早期用戶主要是兩類：一是做客服自動回復的，需要確保AI語氣符合品牌調性；二是做內容審核的，要抓LLM生成的有害內容——但 harmful 的定義往往很微妙，靠關鍵詞黑名單容易誤殺或漏放。

也有團隊用在代碼生成場景。比如要求"生成一段Python函數，處理用戶輸入時要驗證類型并給出友好錯誤提示"，結構性驗證只能檢查是不是Python語法，語義驗證能檢查是不是真的"友好"。

邊界也很明顯。Semantix不解決幻覺問題——如果LLM一本正經地編了個假事實，但語氣完全符合"專業、客觀"的意圖，裁判會放行。它只驗證"怎么說"，不驗證"說什么是對的"。

另外，裁判本身的錯誤會累積。NLI模型也有偏見和盲區，如果裁判訓練數據里某種表達方式標注為"不禮貌"，而你的用戶群體其實接受這種說法，系統會反復糾正一個本沒錯的輸出。

Hebron在文檔里寫了條警告：「別把Semantix當真理來源，它是合同執行器。合同本身寫錯了，執行再完美也是錯的。」

項目開源在GitHub，MIT協議。v0.1.3是上周發布的，issue區已經有用戶在討論支持異步流式輸出的計劃——這對生產環境的大流量場景很關鍵，現在的同步驗證會成為瓶頸。