當大模型成為數據流水線的一環

「當原始數據不再是整齊的JSON，而是原始HTML；當轉換工具不再是SQL，而是大模型——數據工程會變成什么樣？」這是作者設計Sentinel時的核心問題。

正方：LLM作為轉換層，解耦了理解能力與工程架構

傳統ETL的瓶頸在于，非結構化數據的清洗需要大量定制規則。Sentinel的架構把"理解"外包給大模型：Fetcher抓取HTML后，LLM Parser直接輸出結構化的實體、情感、摘要。作者用Kafka做緩沖，讓LLM的處理延遲不會阻塞上游。

這種設計的聰明之處在于關注點分離。GDELT和RSS生產者只管發現URL，Redis L1/L2兩層去重（L1是24小時布隆過濾器，L2是7天精確去重），Fetcher保證exactly-once語義。LLM的不可預測性被隔離在獨立消費者里，失敗進DLQ（死信隊列）走指數退避重試，不影響主流程。

Delta Lake在這里的角色也變了。Bronze層存原始解析結果，PySpark做MERGE操作生成Silver層，Change Data Feed記錄版本。作者提到這是"stateful content versioning"——同一篇文章被多次抓取時，可以追蹤內容演變。

反方：把LLM放在關鍵路徑，是架構債務還是未來標準？

質疑的聲音很直接：LLM的延遲（秒級）和成本（按token計費）與數據工程的批處理假設沖突。Sentinel的回應是"本地跑通"——所有組件Docker化，Kafka用KRaft模式省掉ZooKeeper，但生產環境的擴展性存疑。

更深的問題在于語義穩定性。同一個HTML輸入，模型升級后輸出的實體標簽可能變化，這會讓下游的MERGE邏輯失效。作者用Delta Lake的CDF做版本控制，但沒提如何解決跨版本的語義對齊。

另一個被回避的問題是：當"轉換"變成黑箱推理，數據血緣怎么追蹤？SQL模型可以逐行審計，LLM的抽取結果難以解釋。Sentinel的定位是"proof of work"，這些工程債被合理擱置，但產品化時必須面對。

判斷：這不是最佳實踐，但是一次必要的邊界試探

Sentinel的真正價值在于驗證了一種漸進式替換的路徑。作者的前兩個項目Ballistics（批處理）和Pulse（流處理）都用dbt做轉換，Sentinel把最后一環換成LLM，其余基礎設施復用。這種"最小可行改造"比推翻重來更務實。

對于25-40歲的數據工程師，這個案例提供了可落地的參考：Kafka做背壓緩沖、Redis做輕量去重、Delta Lake做版本控制——這些組件的組合比LLM本身更值得借鑒。至于LLM Parser是否該用更便宜的專用模型（如NER小模型+摘要API的混合策略），作者留了開放空間。

如果你正在處理新聞、財報、研報這類半結構化文本，Sentinel的代碼結構（長運行Python服務+事務性消費）可以直接遷移。生產環境的關鍵是監控LLM輸出的schema漂移，以及設計降級路徑——當模型不可用時，能否退回到關鍵詞提取的兜底邏輯。