Data Team 嘅 SQL 救星：Altimate Code 用 deterministic parsing 打敗 LLM pattern matching

每個俾過 LLM 呃嘅 data engineer 都經歷過同一種沮喪：你問 ChatGPT 或 Claude 幫你 review 一段 SQL，佢回你一段睇落好有道理嘅 output，然後你仔細一睇——佢話你個 JOIN 有問題嘅地方其實完全正確，反而真係有 bug 嘅 correlated subquery 佢完全走漏眼。呢種「好似識、其實唔熟」嘅感覺，喺 production SQL 面前特別致命。

Altimate Code 最近嘅 benchmark 數據直接將呢個問題攤上檯：用純 LLM pattern matching 做 SQL review，基本係靠唔住嘅。而佢哋嘅解決方案異常 direct——寫一個 Rust 底層嘅 deterministic SQL engine，成個分析過程唔經 LLM，直接 parse AST，逐條 rule 硬判斷。結果係 1,077 條 benchmark query、19 條 anti-pattern rules、零假陽性、零假陰性、F1 精準度 100%。

Deterministic 先係 data engineering AI 嘅正確 architecture

Altimate Code 嘅核心 insight 好簡單但好多人唔肯面對：LLM 擅長 creative work——理解自然語言 intent、生成 code skeleton、解釋概念——但 SQL analysis 係 deterministic 嘅問題。一個 SELECT * 係咪 anti-pattern？唔使「覺得」，直接睇 AST 有冇 wildcard 就得。一個 JOIN 有冇 cartesian product？睇 WHERE clause 有冇足夠 condition 就知。呢啲係真偽分明嘅是非題，唔係作文題。

佢哋嘅做法係將 LLM 放喺 strategy layer，deterministic tools 放喺 execution layer。LLM 負責接收用戶嘅自然語言指令，然後 call 對應嘅 deterministic tool 去做實際分析。呢個 architecture 同一般「用 LLM 直接分析 SQL」嘅做法最大分別係：LLM 永遠唔需要「估」一個 SQL query 有冇問題——佢 call 一個 function，個 function 回一個 deterministic 嘅答案。

呢個 pattern 對香港嘅 data team 特別有意義。我哋好多 startup 同中小企嘅 data infrastructure 本身就係唔同 dialect 嘅 warehouse 拼埋一齊——Snowflake 做 analytics、BigQuery 做 ad-hoc、MySQL 做 OLTP。一個 query 喺三個 platform 嘅行為可以好唔同。Altimate Code 嘅 engine 支援 34 個 SQL dialect，仲做到 cross-dialect query equivalence checking，即係同一條 logic 喺唔同 warehouse 嘅行為係咪一致，engine 可以直接 prove。

100% F1 背後嘅工程細節

19 條 rules 涵蓋嘅範疇好 practical：SELECT_STAR、CARTESIAN_PRODUCT、CORRELATED_SUBQUERY、FUNCTION_IN_FILTER（即 non-sargable predicate）、LIKE_LEADING_WILDCARD、NOT_IN_WITH_SUBQUERY、WINDOW_WITHOUT_PARTITION——全部係 production SQL review 最常見嘅問題。

每條 rule 仲有 confidence scoring 機制，confidence 係基於 AST 嘅結構複雜度去決定，唔係 LLM 嘅「我覺得」。例如一個 SELECT * 喺簡單 query 入面係 high confidence warning，但如果個 query 本身有複雜嘅 subquery 同 dynamic SQL，confidence 會自動降級做 medium，叫用戶自己 review 多次。

最令我印象深刻嘅唔係 F1=1.00 個數字，而係佢哋點樣定義 ground truth。Benchmark 嘅 1,077 條 query 全部係 synthetically generated，用 deterministic seed 生成，每條 query 都 pre-annotated 咗 expected_rules（應該 trigger 嘅 rule）同 unexpected_rules（唔應該 trigger 嘅 rule）。Ground truth 係由 AST structure 決定，唔係 human judgment。呢個方法論好重要——即係你唔需要信某個「專家」話呢條 query 有冇問題，個 definition of correctness 本身就係 deterministic 嘅。

成個 benchmark 行完 1,077 條 query 只係用咗 0.518 秒，平均每條 0.48 毫秒。呢個 latency 意味住你可以將佢放喺 pre-commit hook 或者 CI/CD pipeline 而完全唔影響 developer experience。相比之下，每次 call LLM 做 SQL review 起碼幾秒至十幾秒，仲未計 hallucination 嘅風險。

對香港 data team 嘅實際建議

如果你嘅 team 有用 LLM 幫手寫或 review SQL，我建議認真考慮 deterministic layer 嘅角色。唔係要你放棄 LLM——Altimate Code 本身就係 model-agnostic，支援十幾個 provider——而係要你重新劃分咩嘢交俾 LLM、咩嘢交俾 deterministic engine。

一個實戰 workflow 會係咁：developer 用自然語言問 LLM「幫我寫個 query 計 monthly active users」，LLM 生成 SQL。跟住 deterministic engine 做 linting，check 有冇 anti-pattern。發現問題之後 feedback 俾 LLM 去修正。最後 deploy 之前再行一次 equivalence check，確保 refactored query 同 original query 嘅 semantic 一致。呢個 loop 入面 LLM 做 creative part，deterministic engine 做 validation part，各司其職。

Altimate Code 嘅存在本身亦證明咗一件事：data engineering AI 嘅 moat 唔係模型能力，而係底層 infrastructure。Model 會愈來愈勁、API 會愈來愈平、prompt technique 會愈來愈好——但兩個 SQL query 係咪 semantically equivalent，呢個係一個關於 code 嘅 fact，可以由 code 去決定。呢個認知，可能係 2026 年 data team 最重要嘅 infrastructure decision。