當(dāng)大模型成為數(shù)據(jù)流水線的一環(huán)

「當(dāng)原始數(shù)據(jù)不再是整齊的JSON，而是原始HTML；當(dāng)轉(zhuǎn)換工具不再是SQL，而是大模型——數(shù)據(jù)工程會變成什么樣？」這是作者設(shè)計Sentinel時的核心問題。

正方：LLM作為轉(zhuǎn)換層，解耦了理解能力與工程架構(gòu)

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

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

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

反方：把LLM放在關(guān)鍵路徑，是架構(gòu)債務(wù)還是未來標(biāo)準(zhǔn)？

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

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

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

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

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

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

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