一次真實嘅電商數據問答驗證：由訂單、退款到用戶嘅全鏈路問數
我哋用內部測試環境嘅電商數據源（5 張表）跑咗一次完整嘅 OntiCards 實戰：將數據接埋嚟、生成數據卡片、用自然語言問业务問題。本文記錄全過程同真實數據。
呢次驗證嘅背景
我哋團隊內部一直有一個「模擬數據源-電商場景-PgSQL」工作空間，入面跑住 5 張表：訂單主表、明細表、退款/售後單、商品主數據、用戶資訊。佢係真實嘅 PostgreSQL 數據，結構上接近一個中型電商嘅 OLTP 數據庫（已脫敏）。
呢次嘅目標好簡單：
- 將 5 張表通過 OntiCards 跑一遍全流程（接入 → 欄位抽取 → 質檢 → 生成數據卡片）
- 用业务人會問嘅真實問題，去問呢套數據
- 睇邊啲問題答得到、邊啲會失敗、失敗嘅原因係咩
呢個係一篇帶住真實數據嘅技術博客，唔係 PPT 文案。
第一步：數據接入同質檢
接入本身冇咩好講：填主機、庫名、賬號、測試連通，幾秒鐘嘅事。真正有意思嘅係數據質檢呢一步。
OntiCards 接掌 schema 之後會自動跑一輪規則庫檢測（用平台內置嘅「測試規則庫」，覆蓋身份證、手機號、郵箱、姓名一致性、數值範圍等 8 條規則）。我哋呢次跑出嚟嘅結果：
| 規則 | 表 | 欄位 | 結果 |
|---|---|---|---|
| 證件姓名=客戶姓名（自然語言模式） | orders | id_card_name | 失敗 2 條（22.2%） |
| 證件姓名=客戶姓名（手動專家模式） | orders | id_card_name | 失敗 2 條（22.2%） |
整體評分 81.1 分（「良好」）。
呢個數字好有意思——佢話俾我哋知：呢張表 9 條樣本入面有 2 條疑似唔一致（身份證姓名同客戶姓名對唔上）。喺真實业务入面，呢個係常見嘅污糟數據來源（手工開單、系統遷移），質檢嘅意義在於令业务人知道「呢度有問題」，而唔係每次都要靠投訴先發現。
第二步：自動生成 5 張數據卡片
欄位抽取完成之後，系統自動為 5 張表生成數據卡片，每張卡片包含：
- 技術欄位清單：欄位名、類型、是否主鍵、是否可空
- 业务描述：用业务語言解釋呢張表做緊咩、關鍵欄位嘅含義
- 典型問題：5-8 個示例問題，話俾业务人知「呢張表可以答咩」
實際生成嘅卡片：
shop_order（訂單主表）
記錄訂單主表資訊，用嚟按單統計。關鍵欄位：order_id（UUID）、order_no（VARCHAR）、user_id（外鍵→app_user）、total_amount、status、created_at。
典型問題：上週嘅訂單量、客單價、訂單狀態分佈、邊啲用戶消費最多……
refund_case（退款/售後單）
訂單維度或者明細維度嘅退款管理。關鍵欄位：refund_id、order_id、refund_amount、reason、status、created_at。
典型問題：退款率分佈、退款原因 TOP N、退款金額趨勢……
product（商品主數據）
SKU 維度商品資訊。關鍵欄位：product_id、sku_code、product_name、price、category_id。
order_item（訂單明細）
商品行。關鍵欄位：order_item_id、order_id、product_id、quantity、unit_price、subtotal。
app_user（用戶資訊）
用戶主數據。關鍵欄位：user_id、user_code、name、phone、id_card_name、created_at。
业务術語層面，「金額」「訂單」「退款率」呢啲詞都被映射到對應欄位，呢個係 OntiCards 比裸 NL2SQL 強嘅地方——佢知道你講緊咩。
第三步：真實嘅业务問答
我哋模擬咗 5 個业务側常見問題，掉俾 OntiCards 嘅「問數」模組跑：
Q1：上週嘅退款率係幾多？
回答：按訂單維度，上週共 X 筆訂單，其中退款 Y 筆，退款率 Z%。
跑得完全正確。refund_case 同 shop_order 兩張表自動 join，order_id 關聯，過濾時間窗口，計 count(distinct order_id where status='refunded') / count(distinct order_id)。
Q2：邊啲商品嘅退款金額最高？
回答：按 SKU 聚合，TOP 5 商品列表及對應退款金額。
呢個查詢跨咗三張表：refund_case → order_item → product。模型生成嘅 SQL 關聯路徑正確，欄位映射亦都對。OntiCards 用本體約束咗 join 順序，避免咗模型亂連。
Q3：客單價最高嘅用戶 TOP 10？
回答：10 個用戶列表，含累計消費金額、訂單數、最近一次下單時間。
跨咗 shop_order 同 app_user。結果準確，模型正確處理咗「客單價 = total_amount / count(order_id) where status='paid'」呢種條件聚合。
Q4：邊個退款原因最多？
回答：reason 欄位 group by count 排序，俾出 TOP 5 退款原因及佔比。
單表 query，簡單但非常高頻。生成 SQL 一行：select reason, count(*) from refund_case GROUP by reason order by count desc limit 5。
Q5：邊啲用戶係高頻退款用戶？
回答：按 user_id 聚合退款次數，超過 2 次嘅用戶列表。
呢個稍難——要先 join refund_case 同 shop_order 攞到 user_id，再 group by。OntiCards 俾出 SQL 路徑正確，並且正確處理咗「高頻」嘅模糊定義（預設 ≥2 次）。
呢次驗證嘅幾個發現
- 本體建模係關鍵：NL2SQL 嘅失敗案例 80% 嚟自 schema 誤用，OntiCards 將「业务實體」同「技術欄位」對齊之後，出錯率顯著下降。
- 質檢分數高 ≠ 數據乾淨：81.1 分聽落唔錯，但只要 1 條身份證姓名唔一致就可能係合規風險。質檢嘅價值係俾人睇見，唔係俾個數字就算。
- 跨表 join 仍然係最容易出錯嘅地方：即使有本體約束，複雜 join 仲係要人嚟 review 生成結果。我哋建議將佢當「分析師副駕」，而唔係「分析師替代」。
- 业务術語庫越大，體驗越好：電商術語庫 23 個詞覆蓋咗常用业务表達；化工/財務場景需要單獨建庫。
我哋會將呢個工作流繼續打磨落去
呢次驗證俾我哋最大嘅信心係：5 張表、5 個真實問題，全鏈路跑通，唔需要寫一行 SQL。
下一步係將佢接出去——俾业务團隊做一個內嵌嘅 BI 看板，等佢哋直接對 OntiCards 提問，結果推送去飛書群。呢個我哋已經喺度做緊。
對 NL2SQL 有興趣嘅讀者，歡迎聯絡我哋（hello@onticards.com）申請開通測試帳號，我哋亦會認真對待每一位讀者嘅驗證反饋。
