Databricks 的 Spark Declarative Pipelines 基準測試：讓 Agent 犯錯成本更低的理據
Databricks 在 10 月 23 日發布 Spark Declarative Pipelines 基準測試，指出以宣告式方式由 Agent 建立的管道，executor 時間約少 34 倍。比較聚焦於數據管道，即把原始紀錄轉換為可用數據集的程式。其核心論點在於：錯誤在哪個階段開始變得昂貴——驗證期間，還是執行開始後。
宣告式程式設計描述所需輸出，並把執行細節交由框架處理。程序式程式設計則直接指定步驟。Databricks 認為，當 AI Agent 生成程式碼時，這項分別值得獲得更多關注。眼前的壓力落在工程團隊身上：他們須決定讓這些 Agent 如何建立及修訂生產環境的工作。
相關比較不止於 Spark 語法。Apache Airflow 用於組織工作流程，而 dbt 提供轉換及測試工具。兩者都不是每一種 Spark 工作負載的直接替代品。合起來看，它們提供有用參照：團隊早已把職責分配給編寫者、驗證者、排程者及審核者。採用 Agent 令這些界線成為實際的採購及架構問題。
Spark Declarative Pipelines 基準測試實際量度甚麼
Databricks 要論證的是迭代成本，而非最終答案準確度出現決定性提升。
該公司的管道編寫基準測試涵蓋 22 項任務、共 528 次建立；每項任務使用 12 個輸入數據集，並比較兩種程式設計方法。報告指，程序式建立消耗 596 executor-seconds，宣告式建立則為 17。Executor-seconds 量度累積工作節點執行時間，而非經過時間或完整基礎設施帳單。
在已完成的建立之中，程序式程式碼長度中位數為 131 行，宣告式則為 64 行。宣告式編寫所用模型 token 約多 2.3 倍；token 是語言模型處理的單位。這些數字描述的是受測設定，並不證明所有生產系統均可節省成本。
當基準測試從工程文章進入採購討論時，這個分別尤其重要。工作節點時間量度所回答的問題，比總營運開支狹窄得多。買方還須計及開發環境、平台服務、模型使用量、維護及人力注意力。
同樣地，累積執行時間並不能說明工程師要等多久才得到可接受的結果。一次評估或許只消耗少量工作節點時間，卻需要與 Agent 進行冗長對話。另一次則可能很快完成，但使用更多平行資源。這些結果值得分開量度。
程式碼長度結果帶出另一個問題。較短的提交內容讓審核者需要檢視的文字更少，但行數較少不代表推理必然更簡單。一個精簡的轉換，仍可能隱藏對客戶、日期或交易狀態的錯誤假設。
因此，對工程經理而言，有用的解讀是有條件的。若框架移除了重複的執行程式碼，審核者便可把更多注意力投向餘下的業務決策。能否做到，取決於審核流程及框架行為的可見度。
宣告式與程序式管道的比較亦需要清晰基線。具備周詳檢查的程序式實作，與不受限制的腳本並不相同。在把結果視為架構結論前，團隊應詢問每種實作獲得了哪些保障措施。
這篇文章最適合被理解為一項設計假設的證據：較早取得回饋，可減少不成功嘗試所消耗的資源。這是檢視 Agent 工作環境、而非只看其生成輸出的理由。
這種框架能令新聞維持實用，而不會把供應商實驗化為對所有部署的承諾。營運問題因此變得具體：你的平台可在消耗昂貴資源前，拒絕哪些失敗情況？
採用 Agent 令驗證界線承受壓力
承受壓力的是那些容許生成程式碼在尚未確立平台可驗證內容前便投入執行的團隊。
Databricks 表示，現時其平台上逾 70% 的 SDP 管道由 Agent 建立。這項說法涉及特定產品群組，並非所有企業管道。
重要的組織影響關乎責任。當一個人編寫變更時，同事可以問為何選擇特定執行策略。使用生成程式碼時，組織仍需要一名可問責的擁有人，能夠解釋及批准該策略。
Agent 管道驗證成為這個擁有權模式的一部分。它界定系統自動檢查哪些特性，以及哪些決定仍由審核者負責。一句含糊的指示，例如要求產出可運行的程式碼，並未解決這種劃分。
試想一個示範性的銷售報告管道。Agent 收到請求，要把訂單與客戶紀錄合併，並按地區匯總收入。任務聽來簡單，但驗收標準包含多個彼此獨立的決定。
工程團隊必須決定已取消訂單是否計算在內、哪個客戶地址用來界定地區，以及退款如何影響收入。無論 Agent 寫程式碼有多流暢，這些決定仍然必要。
平台可協助確認被引用的物件是否存在，但無法自行決定銷售團隊所指的收入是甚麼。把兩個問題視為同一個批准步驟，會令成功執行看似比實際更具結論性。
壓力亦延伸至平台買方。展示產生看似合理數據集的效果很容易理解。要評估系統如何處理不完整需求、無效引用及被拒變更，則需要要求更高的展示。
因此，買方應要求供應商展示不成功的嘗試。相關證據包括回傳給 Agent 的回饋、所消耗的資源，以及修訂期間可使用的權限。完成得光鮮的最終結果，會令這些營運細節無從看見。
這改變了有效評估的樣貌。Agent 的第一個答案仍然重要，但從錯誤嘗試走到已批准成品的過程同樣重要。周邊系統決定了這條路徑可以觸及甚麼。
審核能力亦值得同等重視。若生成的變更抵達速度快過審核者可評估的速度，較短提交內容只能帶來部分紓緩。團隊仍需要清晰的驗收標準、擁有權，以及每項變更背後假設的紀錄。
因此，架構辯論不只涉及數據工程專家。分析師及業務擁有人同樣參與，因為他們界定何謂正確結果。他們的決定會成為驗證的輸入，而非部署後的非正式說明。
實際做法是在擴大 Agent 存取權前，先明確這些責任。否則，自動化只會加快提交，卻令組織的批准流程維持不變。
較早拒絕改變重試的經濟效益
技術優勢在於：先檢查受約束的描述，才投入完整數據操作。
Apache Spark 的宣告式管道指南記載了 dry run，即不讀取或寫入管道數據的驗證執行。它會檢查包括無效語法、無法解析的資料表或欄位，以及循環相依關係等問題。框架亦會分析數據集相依關係以安排執行。
這種有文件記載的行為，為架構論點提供了具體基礎。管道描述揭示了框架可在產生輸出前檢查的資訊。Agent 會收到關於該描述的回饋，並可在要求完整運行前修訂它。
經濟問題在於，每類回饋應放在哪個環節。若問題可從已宣告的關係中識別，透過較大規模的執行才發現它，便增加了可避免的工作。即使作者是人，這個推理同樣適用。
Agent 令這項設計選擇尤其重要，因為修訂是其工作流程的一部分。一項請求可產生候選方案，驗證器可拒絕它，而 Agent 可提交替代方案。這個交換的成本取決於所涉及的工具。
組織應區分低成本拒絕與免費拒絕。驗證仍需要軟件執行、中繼資料及支援基礎設施，亦需要時間解讀回饋。即使成本低於完整運行，仍應納入評估。
有用的比較是：取得可採取行動資訊所需的資源承諾。能指出無效引用的精確拒絕，可引導針對性的修正；泛泛的失敗訊息，則可能令 Agent 猜測應修改甚麼。
這令錯誤品質成為架構功能。平台即使偵測到問題，卻解釋得不好，仍可能促成不必要的修訂。評估 Agent 管道驗證的團隊，應在檢視最終成功率之餘，同時檢視回饋本身。
可重現性亦是一個問題。若驗證及執行使用不同假設，即使被接受的描述亦可能在較後階段失敗，原因是早前檢查從未考慮過。買方應詢問每個階段共享哪些環境細節。
因此，宣告式與程序式管道的辯論，受益於更精確的詞彙。相關特性包括可檢查的意圖、有用的回饋、受控制的執行，以及清楚說明的限制。單憑程式設計標籤，不能確立全部這些特性。
框架限制可透過收窄可接受操作的範圍來提供幫助。然而，限制亦會塑造哪些工作負載能自然配合。具有不尋常執行需求的團隊，須評估由此帶來的取捨，而非假定每個現有腳本都能直接對應。
對 Spark Declarative Pipelines 基準測試最有力的解讀是，編寫架構值得獨立評估。選擇一個 Agent，然後把其執行環境視為次要細節，會令一個重要成本驅動因素未被檢視。
這是仔細量度重試、如同量度已完成工作般的實際理據。從提交到接受之間所消耗的資源，構成產品行為的一部分。
dbt 與 Airflow 顯示為何標籤須審慎使用
競爭方法應按責任與覆蓋範圍比較，而非置於宣告式勝出、程序式落敗的簡單排名中。
Airflow 的工作流程相依模型說明排程、任務、執行相依關係及營運行為。其文件明確把這種編排與各個任務內執行的工作分開。編排是指協調工作在何時及甚麼條件下運行。
這個區分十分重要。組織可以改善轉換邏輯的編寫方式，同時保留更廣泛的工作流程協調機制。僅限於轉換程式碼的比較，並不能證明周邊的排程系統已不再需要。
這可避免一種常見的分類錯誤。一條管道可以包含宣告式轉換，而該工作流程則由另一項工具定義。不同元件可以負責同一生產流程中的不同部分。
對採購方而言，關鍵問題是哪些元件驗證哪些屬性。排程器知道任務次序，並不自動代表其所產生的記錄正確。反過來說，轉換有效亦不能解決交付流程周邊的每一項操作相依關係。
dbt 的資料測試斷言提供了另一個有用參考。這些檢查會評估唯一性、缺失值、可接受值，以及記錄之間的關係等屬性。團隊亦可透過識別失敗資料列的查詢，表達組織特定的斷言。
這些功能說明，驗證覆蓋範圍比「平台會檢查管道」這類籠統說法更值得關注。不同檢查回答的是不同問題。結構檢查和輸出斷言可以同時成功，但所檢視的屬性並不相同。
假設示例銷售資料集要求每張訂單均須參照一名已知客戶。關係斷言可以處理這項要求，但它仍未能判定所選取的客戶記錄，是否代表該筆銷售在歷史上的正確狀態。
這正是產品比較對從業者有用之處。它們揭示尚待決定的事項，而非暗示某一個框架消除了所有判斷需要。採購方因而可以評估，自身要求還需要多少額外工程工作。
因此，相關的競爭壓力是具體的。供應商必須說明生成的工作如何通過結構檢查、業務檢查及操作控制。一般而言「更易編寫」的承諾，並不能回答這些問題。
現有團隊亦面對相關的遷移決定。取代熟悉的程式碼，本身會引入審查、培訓和營運工作。任何預期節省，均應與這項轉換一併評估，而非獨立呈現。
毋須為每個元件選擇單一程式設計風格。較可辯護的做法，是把每項責任分配予團隊理解並可檢視其行為的系統。
這亦讓供應商定位保持恰當比例。該基準測試關乎特定的編寫方式比較，並未衡量每一個競爭平台、每種工具組合，或更換既有資料技術堆疊的全部成本。
結構有效性仍未涵蓋業務邏輯及存取決策
一條管道可以符合框架的結構規則，但仍產生錯誤的業務答案。
Databricks 報告指出，在每種方式各 264 次建置中，程序式建置有 73 次靜默錯誤，宣告式建置則有 85 次。這些執行會在未失敗的情況下傳回錯誤輸出。該公司並未把宣告式編寫描述為這類問題的解決方案。
這項限制應影響部署決策。一次成功檢查，代表提交的工作符合該檢查所審視的條件；它不應被默認賦予更廣泛的含義，即組織的要求已經得到滿足。
dbt 的 SQL 單元測試提供了相關比較。它們會在建立完整的生產模型前，根據小型、預先定義的輸入評估轉換邏輯。這類範例可以測試邊界情況和預期結果，但覆蓋範圍仍取決於測試作者所指定的內容。
獨立規格至關重要。若同一錯誤假設同時塑造了生成的程式碼和生成的測試，兩者之間的一致性只能提供有限保證。審查者需要外部依據，以判定預期結果。
回到銷售報告的例子。測試可以刻意加入已退款訂單，並定義其對收入的預期貢獻。其價值來自已核准的會計規則，而非代理對一般慣例的信心。
日期亦同樣如此。轉換可以使用有效的時間戳欄位，卻把交易分配到錯誤的報告期間。圍繞期間分界的明確例子，能讓審查者有具體內容可供評估。
這些是示例情況，並非基準測試所報告的失敗案例。它們說明了為何結構正確性和業務正確性需要各自的驗收標準。把兩者合併為單一的綠色狀態，會掩蓋其中分別。
存取決策需要另一道界線。Apache Spark 的部署安全指引說明，安全性取決於配置和部署環境。它警告，驗證及其他保護措施並非普遍預設啟用。這些說法涉及一般 Spark 部署，而非針對 Databricks 託管服務的發現。
對採用代理而言，含義很直接：驗證功能並不能定義完整的安全模型。組織仍須決定哪些身分可以提交工作、檢視中繼資料、執行變更及發布結果。
這項責任在試點期間應保持清晰可見。限制代理的操作範圍，有助團隊評估其行為，而不會把編寫能力與廣泛的生產權限混為一談。合適範圍取決於部署方式。
人工審查亦需要持久的依據。要求、已知例外情況及過往決策，應存放於審查者可與程式碼一同查閱的可搜尋知識庫。文件有助解釋為何某結果符合預期；測試則判定既定預期是否成立。
尚未解決的問題，是完整工作流程能提供多少保證。較早拒絕可處理一個重要的失敗類別，而組織仍須負責圍繞成功執行的要求和權限。
關注重現、正式環境核算及審查結果
下一項有用證據應顯示，這種架構優勢能否在更廣泛的工作負載下持續存在，並改善審批流程。
未來數月，首個值得關注的訊號是獨立重現。評估者應公布任務定義、代理指示、驗證規則及停止條件。缺乏這些細節，看似相近的比較可能實際衡量不同工作環境。
若重現結果能在不同任務中保留優勢，將加強提早取得結構性回饋的論據。若結果隨程序式基準而急劇改變，則會收窄結論，並指出哪些保障措施最為重要。
第二個訊號是正式環境核算。團隊需要衡量從初始要求到已接受變更的整個路徑。這意味著應把模型使用量、驗證活動、執行資源、耗用時間及後續修復工作，分別記錄為不同類別。
相較於單一資源比率，整體工作量降低的證據更能直接支持採用決定。若把整合及審查成本納入後，節省消失，效益仍然較為有限。無論結果如何，都有助採購方作出更準確決定。
第三個訊號是部署後的審查質素。組織應追蹤審查者是否在發布前識別錯誤假設，以及已接受的管道其後是否需要語義修正。語義修正改變的是含義，而不只是修復執行問題。
改善的審查結果會加強以下論點：受約束的編寫格式有助團隊管理生成的工作。若錯誤結果沒有改變，效率論點仍然成立，但對可靠性的主張便應受到限制。這些是觀察準則，而非已公布的發布里程碑。
這個區分十分重要，否則供應商和採購方可能各說各話。供應商可能描述執行浪費減少，而採購方卻假設業務風險降低。雙方均須說明正在評估哪一種結果。
Spark Declarative Pipelines 基準測試為團隊提供了具體理由，以審視這個落差。其更廣泛的相關性，在於執行系統如何接收、檢查及審批所提出的工作。隨著代理愈來愈參與實作，這些設計選擇仍然影響深遠。
對工程主管而言，下一項決策應是與實際要求掛鈎的有限評估。選擇業務方已了解其預期輸出的工作。在檢視每種方法所需資源和注意力時，保持驗收規則穩定。
把失敗嘗試與成功提交一同保留作為證據。記錄每個驗證器檢查了甚麼、審查者仍須決定甚麼，以及哪些假設需要澄清。這份記錄將揭示，更快迭代是否同時令審批更容易。
在擴大代理存取權限之前，請團隊界定已接受管道的確切含義。驗收涵蓋結構、業務結果、權限，還是僅涵蓋其中一部分？利用這些答案，將 Spark Declarative Pipelines 與現有工作流程作比較，並要求每項更廣泛的主張均有證據支持。
