半個月前，知識星球中有個關于 text2sql 的討論，后續又陸續有成員私信溝通。這篇節取了個目前手頭項目的 MVP (最小可行化)版本，來和各位做個分享交流，也希望聽到來自不同場景的最佳實踐。

這篇試圖說清楚：

信貸風控策略迭代場景的標準流程、Text2SQL 三類技術方案，MVP 版本的 Coze text2sql 工作流，以及對人機協同的一些碎片思考。

以下，enjoy：

1、業務場景剖析

因為過去幾年混跡在金融科技圈的原因，這篇就選擇我相對熟悉的，線上企業信貸產品的風控策略調優場景展開聊聊。為了方便各位更好理解，我會先花點篇幅介紹下標準企業信貸風險策略迭代的完整流程，以及技術門檻對企業信貸風控效率的影響。（不感興趣的，可以直接跳到下一章 text2sql 技術方案）

1.1企業信貸風險策略迭代的完整流程

傳統消費貸產品的風控三板斧，已經有大量的行業最佳實踐。但純線上的企業信貸產品，因為企業經營狀況更加復雜多變，數據維度也更加多元，對于風險策略的更新維護也有了更高的專業要求。舉個例子來說，比如某城商行的稅貸產品，上線三個月后發現批發零售行業的 M3 逾期率達到 4.2%，遠超 2.5%的風險容忍度。風險策略經理面對這種情況，一般會遵循如下策略迭代流程： 

多個維度問題診斷：

企業違約往往有跡可循，可以從多個數據源交叉驗證，策略經理編寫的第一批 SQL 可能類似于：

-- 企業基礎畫像分析
SELECT 
    a.行業細分, a.注冊資本, a.成立年限,
    b.近12月開票金額, b.開票穩定性系數,
    c.被執行人次數, c.最近被執行時間,
    d.納稅信用等級, d.近期納稅金額波動率,
    COUNT(DISTINCT a.企業ID) as 企業數,
    AVG(CASE WHEN e.M3_flag = 1 THEN 1 ELSE 0 END) as M3逾期率
FROM 企業基礎信息表 a
LEFT JOIN 發票數據表 b ON a.企業ID = b.企業ID  
LEFT JOIN 司法數據表 c ON a.統一社會信用代碼 = c.統一社會信用代碼
LEFT JOIN 稅務數據表 d ON a.納稅人識別號 = d.納稅人識別號
INNER JOIN 貸款表現表 e ON a.企業ID = e.企業ID
WHERE e.放款日期 BETWEEN '2024-01-01' AND '2024-03-31'
GROUP BY 1,2,3,4,5,6,7,8,9

進一步歸因分析：

假設初步發現問題是集中在"成立時間 2-3 年"且"近期開票金額下滑"的企業 中，考慮到批發零售行業的季節性波動確實很大，簡單的環比下降也可能是正常現象，需要結合行業特性進一步深挖。因此，風險策略經理一般需要進一步的構建更復雜的查詢，例如：

-- 剔除季節性因素的真實經營變化
WITH 行業季節性因子 AS (
    SELECT 月份, AVG(開票金額環比) as 行業平均環比
    FROM 歷史開票數據 
    WHERE 行業 = '批發零售' AND 年份 IN (2021, 2022, 2023)
    GROUP BY 月份
)
SELECT 
    企業ID,
    (實際開票環比 - 行業平均環比) as 剔除季節性后的變化,
    法人近3個月征信查詢次數,
    上下游集中度指標,  -- 前5大客戶/供應商占比
    庫存周轉率變化
FROM ...

行業特色變量設計

經過上述兩步分析，策略經理往往會設計出一系列針對批發零售行業的風險特征，例如：

經營穩定性指標群：

開票客戶數變化率（反映客戶流失）

開票金額集中度趨勢（大客戶依賴風險）

進銷項匹配度（識別虛假貿易）

還款能力預警指標：

應收賬款周轉天數拉長預警

存貨周轉率惡化指數

現金流覆蓋倍數（基于開票和納稅數據估算）

還款意愿識別指標：

法人個人負債上升速度

企業訴訟案件增長率

關聯企業風險傳染指數

這些細化的行業風險特征設計，會帶來一些很大的工作量進行驗證。實際場景中，可能每個指標的開發都需要關聯 5-10 張表，處理至少幾十萬條記錄。（比如一個"進銷項匹配度"指標的計算就需要近 200 行 SQL。）

1.2技術門檻對企業信貸風控效率的影響

為了更好的說明下述要介紹到的基于 LLM 驅動的工作流好處，這里再適當擴充描述下時效性的問題。同樣的，還是舉一些實際場景中的案例進行說明。例如當一個風險策略經理發現一個紡織企業客戶逾期后，他想分析下是個案還是行業性風險，就可能慧聰以下方向考慮衍生變量加工：

• 所有紡織行業客戶的風險表現
• 這些客戶的上下游關系網絡
• 近期原材料價格波動對其影響

現實情況中，第一個查詢可能就要關聯 15+張表，因為企業數據分散在不同系統。例如工商數據在 A 庫，稅務數據在 B 庫，司法數據存在C庫。

到最后的劇情往往是，寫完 SQL 花了兩天，跑的時候因為數據量太大超時了，最后只能分批查詢，手工拼接結果。等分析完已經是一周后的事情。但如果是行業性、區域性的風險，從出現異常信號到實質性違約，窗口期可能只有 30-60 天。如果類似市場環境變化的時候，策略調整總是慢半拍，就可能會導致批量違約的發生。

2、Text2SQL 三類技術方案

text2sql 這個名次其實由來已久，遵循講清楚來龍去脈的文章風格，下面通過一些具體的對比來說明下我了解到的三個階段的技術方案對比。

2.1基于規則的方法：詞典映射與模板匹配

早期的 Text2SQL 類似一個翻譯詞典。公開信息可查的是，早在 2010 年前后，各大銀行的 IT 部門流行過建立一個龐大的映射規則庫的做法，類似：

"客戶" → "customer_table"
"上個月" → "date >= DATEADD(month, -1, GETDATE())"
"逾期" → "overdue_flag = 1"

然后當用戶輸入"查詢上個月逾期客戶"時，系統會進行分詞和映射：

1.分詞：[查詢] [上個月] [逾期] [客戶]

2.映射：SELECT * FROM customer_table WHERE overdue_flag = 1 AND date >= DATEADD(month, -1, GETDATE())

這個做法看起來很符合暴力美學，只要組織人手盡可能的窮盡常用的一些映射關系即可。但實際的問題是，只要用戶的表達稍微靈活一點，系統就無法處理。比如用戶說"最近表現不太好的企業客戶"，系統完全不知道"表現不太好"對應什么字段。另外維護成本也是個坑，每次新增一個業務術語，都要手動添加規則，還要保證和既有規則不能沖突。

2.2基于深度學習的方法：讓機器學習"翻譯"

18 年前后隨著 BERT 這些模型的出現，Text2SQL 開始進入深度學習時代。 核心邏輯從依賴人工規則，升級成了讓模型從大量的"問題-SQL"對中學習映射模式。 訓練過程類似教小孩說話：

輸入："查詢上海地區的企業客戶"
標注：SELECT \* FROM enterprise WHERE city = '上海'


輸入："統計上海的制造業企業數量"  
標注：SELECT COUNT(\*) FROM enterprise WHERE city = '上海' AND industry = '制造業'


...（準備10萬條這樣的訓練數據）

模型比如會學習到："查詢"通常對應 SELECT，"統計...數量"對應 COUNT(*)，地名通常出現在 WHERE 子句中。我查到國內有家金融科技公司基于 Seq2Seq 架構訓練了一個模型，在標準數據集上準確率號稱達到了 85%。演示效果也很驚艷，類似效果：

輸入："過去三個月新增的優質客戶有多少"
輸出：SELECT COUNT(\*) FROM customer 
      WHERE create_date >= DATEADD(month, -3, GETDATE()) 
      AND customer_level = 'A'

但這種方法對沒見過的表達方式準確率會明顯下降（"優質"在訓練集里對應 customer_level='A'，但用戶說"高價值"時就會識別不了），同時對于復雜查詢（比如 3 個表以上的 JOIN）基本生成不對。但最麻煩的是，這種黑盒子的方法，錯了也不知道錯在哪。

2.3大語言模型時代：理解語義而非記憶模式

ChatGPT3.5 發布到現在也兩年半的時間了，尤其是年初 DeepSeekR1 讓公眾開始熟悉的 LLM 慢思考能力，可以在 text2sql 這個場景中，從以往學習"問題→SQL"的映射的路線，變成真正理解用戶意圖和數據庫語義的方法。舉個具體例子來說，

用戶說："幫我看看最近經營狀況惡化的紡織企業"

規則方法：error（沒有定義"經營狀況惡化"）

深度學習：可能輸出 SELECT * FROM enterprise WHERE status = 'bad'（瞎猜）

而LLM可能會這樣推理:

"經營狀況惡化"→需要對比不同時期的經營指標

紡織企業→需要過濾行業

可能的指標：營收下降、利潤率降低、現金流緊張

最后生成的 SQL 例如：

WITH 企業經營指標 AS (
  SELECT 
    企業ID,
    (本期營收 - 上期營收) / 上期營收 as 營收增長率,
    (本期利潤率 - 上期利潤率) as 利潤率變化
  FROM 財務數據表
  WHERE 統計期間 IN ('2024Q1', '2023Q4')
)
SELECT 
  a.企業名稱, 
  b.營收增長率,
  b.利潤率變化
FROM 企業信息表 a
JOIN 企業經營指標 b ON a.企業ID = b.企業ID
WHERE a.行業分類 = '紡織業'
  AND (b.營收增長率 < -0.1 OR b.利潤率變化 < -0.05)
ORDER BY b.營收增長率

當然，必須要說明的是，這種基于 LLM 驅動的推理做法也有其自身的局限性，例如可能生成不存在的字段名，同樣的問題可能生成不同的 SQL 等。這也是為什么在工作流中，需要考慮結合知識庫和驗證機制的方法，既利用 LLM 的理解能力，又通過規則確保準確性和一致性。

3、基于扣子的工作流實現方案

因為目前這個項目方內部使用 Coze 作為主要的工作流平臺，所以下述工作流的演示也以 Coze 為例，各位可以如果要復現，也可以選擇通過 Dify 或者其他類似工作流平臺。

3.1整體架構設計思路

節取的這個 MVP 版本保持了原方案的"理解-增強-生成-驗證"四層架構，一些可以重點關注的節點：

雙知識庫前置：在生成 SQL 前先檢索相關知識，大幅提升首次生成準確率

SQL生成預處理：在正式生成SQL前，設置專門LLM節點結合知識庫輸出進行SQL生成方案規劃

分層驗證機制：語法驗證、語義驗證、安全驗證等多重校驗

3.2核心節點功能拆解

字段參考庫查詢節點：動態 schema 映射

這個節點解決了企業數據庫的一個普遍痛點——同一個業務含義在不同表中的字段名不一致，例如：

{
  "企業標識": {
    "主鍵字段": \["enterprise_id", "ent_id", "company_id"\],
    "工商信息": \["unified_social_credit_code", "uscc", "社會信用代碼"\],
    "稅務信息": \["taxpayer_id", "nsrsbh", "納稅人識別號"\]
  },
  "經營指標": {
    "營業收入": {
      "字段名": \["revenue", "income", "營業收入", "銷售額"\],
      "所在表": \["financial_data", "tax_report", "invoice_summary"\],
      "計算說明": "如無直接字段，可通過發票金額匯總估算"
    }
  }
}

模糊匹配：用戶說"收入"，能匹配到 revenue、income 等

同義詞擴展：用戶說"營收"，自動關聯"營業收入"、"銷售額"

跨表提示：告知 LLM 某個指標在多個表中都有，需要選擇或關聯

SQL 模板庫查詢節點：場景化最佳實踐

不同于簡單的 SQL 片段，這里存儲的是經過驗證的業務場景解決方案，例如

-- 模板名稱：企業關聯風險全景圖
-- 適用場景：查詢目標企業的關聯方風險暴露
-- 輸入參數：{enterprise_id}


WITH 關聯企業 AS (


  -- 通過共同法人找關聯方
  SELECT DISTINCT b.企業ID as 關聯企業ID
  FROM 企業基礎信息 a
  JOIN 企業基礎信息 b ON a.法人身份證 = b.法人身份證
  WHERE a.企業ID = {enterprise_id} AND b.企業ID != {enterprise_id}
)
SELECT 
  風險類型,
  COUNT(DISTINCT 關聯企業ID) as 涉險企業數,
  SUM(風險金額) as 風險敞口總額,
  GROUP_CONCAT(企業名稱) as 具體企業清單
FROM (
  -- 各類風險匯總邏輯...
) 
GROUP BY 風險類型

模板元數據：

使用頻率：記錄被調用次數，高頻模板優先推薦

效果反饋：記錄查詢耗時、結果準確率

適配性標記：標注適用的數據庫版本、表結構版本

SQL 生成預處理節點

這是一個關鍵的中間節點，位于知識庫查詢和 SQL 生成之間，負責把用戶的自然語言需求轉化為結構化的查詢計劃。好處就是降低了下一個 sql 生成節點的壓力，實測確實對于最后的準確度提升有所幫助，但是也會帶來更多的耗時和 tooken 消耗。

SQL 生成節點

這是整個流程的核心，選擇有思維鏈的最新 LLM（例如 DeepSeek-R1-0528），并且通過精心設計的 Prompt 充分發揮 LLM 能力。

SQL 驗證節點

這個節點是設置了六道驗證：空值檢查、查詢類型限制、危險關鍵字過濾、表名白名單、語法校驗、長度限制，確保 SQL 的安全性。同時還設計了自動為非聚合查詢添加 LIMIT 限制、清理格式、適配特定數據庫平臺的特性。這個節點完美詮釋了"防御性編程"思想，不僅可以攔截惡意或錯誤的 SQL，還能將合法的 SQL 優化得更加規范和高效。

HTTP 請求節點

為了演示所需，這個工作流中所使用的數據我存在了 supabase 數據庫中，可以通過 POST 請求把上游節點中輸出的 sql 放在請求體中實現查詢。

3.3問答案例演示

測試問題1：

{"user_query": "以查詢日期按月分組，統計不同月份的違約客戶數占比"}

生成的SQL語句：

SELECT 
    to_char(查詢日期, 'YYYY-MM') AS 月份,
    COUNT(CASE WHEN 是否違約 = '是' THEN 1 END) AS 違約客戶數,
    COUNT(*) AS 總客戶數,
    ROUND(COUNT(CASE WHEN 是否違約 = '是' THEN 1 END) * 100.0 / COUNT(*), 2) AS 違約占比
FROM enterprise_info 
GROUP BY to_char(查詢日期, 'YYYY-MM') 
ORDER BY to_char(查詢日期, 'YYYY-MM') DESC;

按月統計企業違約情況
計算每月的違約客戶數量
計算每月的總客戶數量
計算違約占比（百分比，保留2位小數）
按月份降序排列結果

測試問題2：

{"user_query": "企業名稱中包含“工程”的企業數量，以及其中違約客戶的占比"}

生成的SQL語句：

SELECT COUNT(*) AS "企業總數", 
       SUM(CASE WHEN "是否違約" = '是' THEN 1 ELSE 0 END) AS "違約企業數", 
       (SUM(CASE WHEN "是否違約" = '是' THEN 1 ELSE 0 END) * 1.0 / COUNT(*)) AS "違約占比" 
FROM enterprise_info 
WHERE "企業名稱" LIKE '%工程%';

篩選企業名稱包含"工程"字樣的企業
統計工程類企業的總數量
計算工程類企業中的違約企業數量
計算工程類企業的違約占比（小數格式）
通過單行匯總展示整體風險水平

3.4后續更新預告

預計6月中下旬，等手頭項目告一段落后，我會再寫篇文章介紹下如何在目前演示 的MVP版本基礎上，實現包含以下四個維度的增強方案：

1. 架構升級：引入Neo4j圖數據庫構建企業關系圖譜，通過知識圖譜增強LLM對復雜多表關聯和業務實體關系的理解，支持更深層次的關聯分析和風險傳導路徑挖掘；
2. 分析智能化：在SQL取數基礎上集成Python自動化分析節點，實現KS、IV、PSI等風險指標的自動計算，支持變量分箱、WOE編碼、相關性分析等策略開發全流程的代碼自動生成；
3. 可視化增強：基于分析結果自動生成交互式圖表和策略效果監控Dashboard，支持策略表現的實時追蹤和多維度對比分析；
4. Agent化演進：構建支持多輪對話的策略分析Agent，具備上下文記憶、策略版本管理、A/B測試設計等高級功能，實現從單次查詢到持續策略優化的智能化轉變。

4、寫在最后

雖然目前 LLM 的能力還沒有明顯收斂，但底座 LLM 的推理水平也已經在很多場景下被驗證有效。這也是上述這個扣子工作流試圖演示的技術賦能業務打開方式。

不過文章中演示的案例只是個MVP版本，實際使用需要各位結合自身的業務場景進行大量測試后針對性調優。LLM 可能會生成語法完美，但業務邏輯錯誤的查詢，比如將"經營狀況惡化"簡單理解為"status = 'bad'"，忽略了需要對比不同時期的財務指標。這種深層的業務理解，依然是這個領域專業人士的價值所在。當技術門檻被 AI 逐漸抹平后，風險策略經理的核心競爭力也就正在從"如何寫 SQL"轉向"如何定義問題"。

LLM 時代的專業價值正在被慢慢重塑，LLM 能力邊界與人類專業判斷的平衡是我們每個人工作中都要面對的課題，技術賦能專業，而非替代專業，猜想未來人機協作的最佳實踐模式是人負責 WHY 和 WHAT，AI 負責 HOW。