半個(gè)月前，知識(shí)星球中有個(gè)關(guān)于 text2sql 的討論，后續(xù)又陸續(xù)有成員私信溝通。這篇節(jié)取了個(gè)目前手頭項(xiàng)目的 MVP (最小可行化)版本，來(lái)和各位做個(gè)分享交流，也希望聽到來(lái)自不同場(chǎng)景的最佳實(shí)踐。

這篇試圖說(shuō)清楚：

信貸風(fēng)控策略迭代場(chǎng)景的標(biāo)準(zhǔn)流程、Text2SQL 三類技術(shù)方案，MVP 版本的 Coze text2sql 工作流，以及對(duì)人機(jī)協(xié)同的一些碎片思考。

以下，enjoy：

1、業(yè)務(wù)場(chǎng)景剖析

因?yàn)檫^去幾年混跡在金融科技圈的原因，這篇就選擇我相對(duì)熟悉的，線上企業(yè)信貸產(chǎn)品的風(fēng)控策略調(diào)優(yōu)場(chǎng)景展開聊聊。為了方便各位更好理解，我會(huì)先花點(diǎn)篇幅介紹下標(biāo)準(zhǔn)企業(yè)信貸風(fēng)險(xiǎn)策略迭代的完整流程，以及技術(shù)門檻對(duì)企業(yè)信貸風(fēng)控效率的影響。（不感興趣的，可以直接跳到下一章 text2sql 技術(shù)方案）

1.1企業(yè)信貸風(fēng)險(xiǎn)策略迭代的完整流程

傳統(tǒng)消費(fèi)貸產(chǎn)品的風(fēng)控三板斧，已經(jīng)有大量的行業(yè)最佳實(shí)踐。但純線上的企業(yè)信貸產(chǎn)品，因?yàn)槠髽I(yè)經(jīng)營(yíng)狀況更加復(fù)雜多變，數(shù)據(jù)維度也更加多元，對(duì)于風(fēng)險(xiǎn)策略的更新維護(hù)也有了更高的專業(yè)要求。舉個(gè)例子來(lái)說(shuō)，比如某城商行的稅貸產(chǎn)品，上線三個(gè)月后發(fā)現(xiàn)批發(fā)零售行業(yè)的 M3 逾期率達(dá)到 4.2%，遠(yuǎn)超 2.5%的風(fēng)險(xiǎn)容忍度。風(fēng)險(xiǎn)策略經(jīng)理面對(duì)這種情況，一般會(huì)遵循如下策略迭代流程： 

多個(gè)維度問題診斷：

企業(yè)違約往往有跡可循，可以從多個(gè)數(shù)據(jù)源交叉驗(yàn)證，策略經(jīng)理編寫的第一批 SQL 可能類似于：

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

進(jìn)一步歸因分析：

假設(shè)初步發(fā)現(xiàn)問題是集中在"成立時(shí)間 2-3 年"且"近期開票金額下滑"的企業(yè) 中，考慮到批發(fā)零售行業(yè)的季節(jié)性波動(dòng)確實(shí)很大，簡(jiǎn)單的環(huán)比下降也可能是正常現(xiàn)象，需要結(jié)合行業(yè)特性進(jìn)一步深挖。因此，風(fēng)險(xiǎn)策略經(jīng)理一般需要進(jìn)一步的構(gòu)建更復(fù)雜的查詢，例如：

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

行業(yè)特色變量設(shè)計(jì)

經(jīng)過上述兩步分析，策略經(jīng)理往往會(huì)設(shè)計(jì)出一系列針對(duì)批發(fā)零售行業(yè)的風(fēng)險(xiǎn)特征，例如：

經(jīng)營(yíng)穩(wěn)定性指標(biāo)群：

開票客戶數(shù)變化率（反映客戶流失）

開票金額集中度趨勢(shì)（大客戶依賴風(fēng)險(xiǎn)）

進(jìn)銷項(xiàng)匹配度（識(shí)別虛假貿(mào)易）

還款能力預(yù)警指標(biāo)：

應(yīng)收賬款周轉(zhuǎn)天數(shù)拉長(zhǎng)預(yù)警

存貨周轉(zhuǎn)率惡化指數(shù)

現(xiàn)金流覆蓋倍數(shù)（基于開票和納稅數(shù)據(jù)估算）

還款意愿識(shí)別指標(biāo)：

法人個(gè)人負(fù)債上升速度

企業(yè)訴訟案件增長(zhǎng)率

關(guān)聯(lián)企業(yè)風(fēng)險(xiǎn)傳染指數(shù)

這些細(xì)化的行業(yè)風(fēng)險(xiǎn)特征設(shè)計(jì)，會(huì)帶來(lái)一些很大的工作量進(jìn)行驗(yàn)證。實(shí)際場(chǎng)景中，可能每個(gè)指標(biāo)的開發(fā)都需要關(guān)聯(lián) 5-10 張表，處理至少幾十萬(wàn)條記錄。（比如一個(gè)"進(jìn)銷項(xiàng)匹配度"指標(biāo)的計(jì)算就需要近 200 行 SQL。）

1.2技術(shù)門檻對(duì)企業(yè)信貸風(fēng)控效率的影響

為了更好的說(shuō)明下述要介紹到的基于 LLM 驅(qū)動(dòng)的工作流好處，這里再適當(dāng)擴(kuò)充描述下時(shí)效性的問題。同樣的，還是舉一些實(shí)際場(chǎng)景中的案例進(jìn)行說(shuō)明。例如當(dāng)一個(gè)風(fēng)險(xiǎn)策略經(jīng)理發(fā)現(xiàn)一個(gè)紡織企業(yè)客戶逾期后，他想分析下是個(gè)案還是行業(yè)性風(fēng)險(xiǎn)，就可能慧聰以下方向考慮衍生變量加工：

• 所有紡織行業(yè)客戶的風(fēng)險(xiǎn)表現(xiàn)
• 這些客戶的上下游關(guān)系網(wǎng)絡(luò)
• 近期原材料價(jià)格波動(dòng)對(duì)其影響

現(xiàn)實(shí)情況中，第一個(gè)查詢可能就要關(guān)聯(lián) 15+張表，因?yàn)槠髽I(yè)數(shù)據(jù)分散在不同系統(tǒng)。例如工商數(shù)據(jù)在 A 庫(kù)，稅務(wù)數(shù)據(jù)在 B 庫(kù)，司法數(shù)據(jù)存在C庫(kù)。

到最后的劇情往往是，寫完 SQL 花了兩天，跑的時(shí)候因?yàn)閿?shù)據(jù)量太大超時(shí)了，最后只能分批查詢，手工拼接結(jié)果。等分析完已經(jīng)是一周后的事情。但如果是行業(yè)性、區(qū)域性的風(fēng)險(xiǎn)，從出現(xiàn)異常信號(hào)到實(shí)質(zhì)性違約，窗口期可能只有 30-60 天。如果類似市場(chǎng)環(huán)境變化的時(shí)候，策略調(diào)整總是慢半拍，就可能會(huì)導(dǎo)致批量違約的發(fā)生。

2、Text2SQL 三類技術(shù)方案

text2sql 這個(gè)名次其實(shí)由來(lái)已久，遵循講清楚來(lái)龍去脈的文章風(fēng)格，下面通過一些具體的對(duì)比來(lái)說(shuō)明下我了解到的三個(gè)階段的技術(shù)方案對(duì)比。

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

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

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

然后當(dāng)用戶輸入"查詢上個(gè)月逾期客戶"時(shí)，系統(tǒng)會(huì)進(jìn)行分詞和映射：

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

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

這個(gè)做法看起來(lái)很符合暴力美學(xué)，只要組織人手盡可能的窮盡常用的一些映射關(guān)系即可。但實(shí)際的問題是，只要用戶的表達(dá)稍微靈活一點(diǎn)，系統(tǒng)就無(wú)法處理。比如用戶說(shuō)"最近表現(xiàn)不太好的企業(yè)客戶"，系統(tǒng)完全不知道"表現(xiàn)不太好"對(duì)應(yīng)什么字段。另外維護(hù)成本也是個(gè)坑，每次新增一個(gè)業(yè)務(wù)術(shù)語(yǔ)，都要手動(dòng)添加規(guī)則，還要保證和既有規(guī)則不能沖突。

2.2基于深度學(xué)習(xí)的方法：讓機(jī)器學(xué)習(xí)"翻譯"

18 年前后隨著 BERT 這些模型的出現(xiàn)，Text2SQL 開始進(jìn)入深度學(xué)習(xí)時(shí)代。 核心邏輯從依賴人工規(guī)則，升級(jí)成了讓模型從大量的"問題-SQL"對(duì)中學(xué)習(xí)映射模式。 訓(xùn)練過程類似教小孩說(shuō)話：

輸入："查詢上海地區(qū)的企業(yè)客戶"
標(biāo)注：SELECT \* FROM enterprise WHERE city = '上海'


輸入："統(tǒng)計(jì)上海的制造業(yè)企業(yè)數(shù)量"  
標(biāo)注：SELECT COUNT(\*) FROM enterprise WHERE city = '上海' AND industry = '制造業(yè)'


...（準(zhǔn)備10萬(wàn)條這樣的訓(xùn)練數(shù)據(jù)）

模型比如會(huì)學(xué)習(xí)到："查詢"通常對(duì)應(yīng) SELECT，"統(tǒng)計(jì)...數(shù)量"對(duì)應(yīng) COUNT(*)，地名通常出現(xiàn)在 WHERE 子句中。我查到國(guó)內(nèi)有家金融科技公司基于 Seq2Seq 架構(gòu)訓(xùn)練了一個(gè)模型，在標(biāo)準(zhǔn)數(shù)據(jù)集上準(zhǔn)確率號(hào)稱達(dá)到了 85%。演示效果也很驚艷，類似效果：

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

但這種方法對(duì)沒見過的表達(dá)方式準(zhǔn)確率會(huì)明顯下降（"優(yōu)質(zhì)"在訓(xùn)練集里對(duì)應(yīng) customer_level='A'，但用戶說(shuō)"高價(jià)值"時(shí)就會(huì)識(shí)別不了），同時(shí)對(duì)于復(fù)雜查詢（比如 3 個(gè)表以上的 JOIN）基本生成不對(duì)。但最麻煩的是，這種黑盒子的方法，錯(cuò)了也不知道錯(cuò)在哪。

2.3大語(yǔ)言模型時(shí)代：理解語(yǔ)義而非記憶模式

ChatGPT3.5 發(fā)布到現(xiàn)在也兩年半的時(shí)間了，尤其是年初 DeepSeekR1 讓公眾開始熟悉的 LLM 慢思考能力，可以在 text2sql 這個(gè)場(chǎng)景中，從以往學(xué)習(xí)"問題→SQL"的映射的路線，變成真正理解用戶意圖和數(shù)據(jù)庫(kù)語(yǔ)義的方法。舉個(gè)具體例子來(lái)說(shuō)，

用戶說(shuō)："幫我看看最近經(jīng)營(yíng)狀況惡化的紡織企業(yè)"

規(guī)則方法：error（沒有定義"經(jīng)營(yíng)狀況惡化"）

深度學(xué)習(xí)：可能輸出 SELECT * FROM enterprise WHERE status = 'bad'（瞎猜）

而LLM可能會(huì)這樣推理:

"經(jīng)營(yíng)狀況惡化"→需要對(duì)比不同時(shí)期的經(jīng)營(yíng)指標(biāo)

紡織企業(yè)→需要過濾行業(yè)

可能的指標(biāo)：營(yíng)收下降、利潤(rùn)率降低、現(xiàn)金流緊張

最后生成的 SQL 例如：

WITH 企業(yè)經(jīng)營(yíng)指標(biāo) AS (
  SELECT 
    企業(yè)ID,
    (本期營(yíng)收 - 上期營(yíng)收) / 上期營(yíng)收 as 營(yíng)收增長(zhǎng)率,
    (本期利潤(rùn)率 - 上期利潤(rùn)率) as 利潤(rùn)率變化
  FROM 財(cái)務(wù)數(shù)據(jù)表
  WHERE 統(tǒng)計(jì)期間 IN ('2024Q1', '2023Q4')
)
SELECT 
  a.企業(yè)名稱, 
  b.營(yíng)收增長(zhǎng)率,
  b.利潤(rùn)率變化
FROM 企業(yè)信息表 a
JOIN 企業(yè)經(jīng)營(yíng)指標(biāo) b ON a.企業(yè)ID = b.企業(yè)ID
WHERE a.行業(yè)分類 = '紡織業(yè)'
  AND (b.營(yíng)收增長(zhǎng)率 < -0.1 OR b.利潤(rùn)率變化 < -0.05)
ORDER BY b.營(yíng)收增長(zhǎng)率

當(dāng)然，必須要說(shuō)明的是，這種基于 LLM 驅(qū)動(dòng)的推理做法也有其自身的局限性，例如可能生成不存在的字段名，同樣的問題可能生成不同的 SQL 等。這也是為什么在工作流中，需要考慮結(jié)合知識(shí)庫(kù)和驗(yàn)證機(jī)制的方法，既利用 LLM 的理解能力，又通過規(guī)則確保準(zhǔn)確性和一致性。

3、基于扣子的工作流實(shí)現(xiàn)方案

因?yàn)槟壳斑@個(gè)項(xiàng)目方內(nèi)部使用 Coze 作為主要的工作流平臺(tái)，所以下述工作流的演示也以 Coze 為例，各位可以如果要復(fù)現(xiàn)，也可以選擇通過 Dify 或者其他類似工作流平臺(tái)。

3.1整體架構(gòu)設(shè)計(jì)思路

節(jié)取的這個(gè) MVP 版本保持了原方案的"理解-增強(qiáng)-生成-驗(yàn)證"四層架構(gòu)，一些可以重點(diǎn)關(guān)注的節(jié)點(diǎn)：

雙知識(shí)庫(kù)前置：在生成 SQL 前先檢索相關(guān)知識(shí)，大幅提升首次生成準(zhǔn)確率

SQL生成預(yù)處理：在正式生成SQL前，設(shè)置專門LLM節(jié)點(diǎn)結(jié)合知識(shí)庫(kù)輸出進(jìn)行SQL生成方案規(guī)劃

分層驗(yàn)證機(jī)制：語(yǔ)法驗(yàn)證、語(yǔ)義驗(yàn)證、安全驗(yàn)證等多重校驗(yàn)

3.2核心節(jié)點(diǎn)功能拆解

字段參考庫(kù)查詢節(jié)點(diǎn)：動(dòng)態(tài) schema 映射

這個(gè)節(jié)點(diǎn)解決了企業(yè)數(shù)據(jù)庫(kù)的一個(gè)普遍痛點(diǎn)——同一個(gè)業(yè)務(wù)含義在不同表中的字段名不一致，例如：

{
  "企業(yè)標(biāo)識(shí)": {
    "主鍵字段": \["enterprise_id", "ent_id", "company_id"\],
    "工商信息": \["unified_social_credit_code", "uscc", "社會(huì)信用代碼"\],
    "稅務(wù)信息": \["taxpayer_id", "nsrsbh", "納稅人識(shí)別號(hào)"\]
  },
  "經(jīng)營(yíng)指標(biāo)": {
    "營(yíng)業(yè)收入": {
      "字段名": \["revenue", "income", "營(yíng)業(yè)收入", "銷售額"\],
      "所在表": \["financial_data", "tax_report", "invoice_summary"\],
      "計(jì)算說(shuō)明": "如無(wú)直接字段，可通過發(fā)票金額匯總估算"
    }
  }
}

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

同義詞擴(kuò)展：用戶說(shuō)"營(yíng)收"，自動(dòng)關(guān)聯(lián)"營(yíng)業(yè)收入"、"銷售額"

跨表提示：告知 LLM 某個(gè)指標(biāo)在多個(gè)表中都有，需要選擇或關(guān)聯(lián)

SQL 模板庫(kù)查詢節(jié)點(diǎn)：場(chǎng)景化最佳實(shí)踐

不同于簡(jiǎn)單的 SQL 片段，這里存儲(chǔ)的是經(jīng)過驗(yàn)證的業(yè)務(wù)場(chǎng)景解決方案，例如

-- 模板名稱：企業(yè)關(guān)聯(lián)風(fēng)險(xiǎn)全景圖
-- 適用場(chǎng)景：查詢目標(biāo)企業(yè)的關(guān)聯(lián)方風(fēng)險(xiǎn)暴露
-- 輸入?yún)?shù)：{enterprise_id}


WITH 關(guān)聯(lián)企業(yè) AS (


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

模板元數(shù)據(jù)：

使用頻率：記錄被調(diào)用次數(shù)，高頻模板優(yōu)先推薦

效果反饋：記錄查詢耗時(shí)、結(jié)果準(zhǔn)確率

適配性標(biāo)記：標(biāo)注適用的數(shù)據(jù)庫(kù)版本、表結(jié)構(gòu)版本

SQL 生成預(yù)處理節(jié)點(diǎn)

這是一個(gè)關(guān)鍵的中間節(jié)點(diǎn)，位于知識(shí)庫(kù)查詢和 SQL 生成之間，負(fù)責(zé)把用戶的自然語(yǔ)言需求轉(zhuǎn)化為結(jié)構(gòu)化的查詢計(jì)劃。好處就是降低了下一個(gè) sql 生成節(jié)點(diǎn)的壓力，實(shí)測(cè)確實(shí)對(duì)于最后的準(zhǔn)確度提升有所幫助，但是也會(huì)帶來(lái)更多的耗時(shí)和 tooken 消耗。

SQL 生成節(jié)點(diǎn)

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

SQL 驗(yàn)證節(jié)點(diǎn)

這個(gè)節(jié)點(diǎn)是設(shè)置了六道驗(yàn)證：空值檢查、查詢類型限制、危險(xiǎn)關(guān)鍵字過濾、表名白名單、語(yǔ)法校驗(yàn)、長(zhǎng)度限制，確保 SQL 的安全性。同時(shí)還設(shè)計(jì)了自動(dòng)為非聚合查詢添加 LIMIT 限制、清理格式、適配特定數(shù)據(jù)庫(kù)平臺(tái)的特性。這個(gè)節(jié)點(diǎn)完美詮釋了"防御性編程"思想，不僅可以攔截惡意或錯(cuò)誤的 SQL，還能將合法的 SQL 優(yōu)化得更加規(guī)范和高效。

HTTP 請(qǐng)求節(jié)點(diǎn)

為了演示所需，這個(gè)工作流中所使用的數(shù)據(jù)我存在了 supabase 數(shù)據(jù)庫(kù)中，可以通過 POST 請(qǐng)求把上游節(jié)點(diǎn)中輸出的 sql 放在請(qǐng)求體中實(shí)現(xiàn)查詢。

3.3問答案例演示

測(cè)試問題1：

{"user_query": "以查詢?nèi)掌诎丛路纸M，統(tǒng)計(jì)不同月份的違約客戶數(shù)占比"}

生成的SQL語(yǔ)句：

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

按月統(tǒng)計(jì)企業(yè)違約情況
計(jì)算每月的違約客戶數(shù)量
計(jì)算每月的總客戶數(shù)量
計(jì)算違約占比（百分比，保留2位小數(shù)）
按月份降序排列結(jié)果

測(cè)試問題2：

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

生成的SQL語(yǔ)句：

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

篩選企業(yè)名稱包含"工程"字樣的企業(yè)
統(tǒng)計(jì)工程類企業(yè)的總數(shù)量
計(jì)算工程類企業(yè)中的違約企業(yè)數(shù)量
計(jì)算工程類企業(yè)的違約占比（小數(shù)格式）
通過單行匯總展示整體風(fēng)險(xiǎn)水平

3.4后續(xù)更新預(yù)告

預(yù)計(jì)6月中下旬，等手頭項(xiàng)目告一段落后，我會(huì)再寫篇文章介紹下如何在目前演示 的MVP版本基礎(chǔ)上，實(shí)現(xiàn)包含以下四個(gè)維度的增強(qiáng)方案：

1. 架構(gòu)升級(jí)：引入Neo4j圖數(shù)據(jù)庫(kù)構(gòu)建企業(yè)關(guān)系圖譜，通過知識(shí)圖譜增強(qiáng)LLM對(duì)復(fù)雜多表關(guān)聯(lián)和業(yè)務(wù)實(shí)體關(guān)系的理解，支持更深層次的關(guān)聯(lián)分析和風(fēng)險(xiǎn)傳導(dǎo)路徑挖掘；
2. 分析智能化：在SQL取數(shù)基礎(chǔ)上集成Python自動(dòng)化分析節(jié)點(diǎn)，實(shí)現(xiàn)KS、IV、PSI等風(fēng)險(xiǎn)指標(biāo)的自動(dòng)計(jì)算，支持變量分箱、WOE編碼、相關(guān)性分析等策略開發(fā)全流程的代碼自動(dòng)生成；
3. 可視化增強(qiáng)：基于分析結(jié)果自動(dòng)生成交互式圖表和策略效果監(jiān)控Dashboard，支持策略表現(xiàn)的實(shí)時(shí)追蹤和多維度對(duì)比分析；
4. Agent化演進(jìn)：構(gòu)建支持多輪對(duì)話的策略分析Agent，具備上下文記憶、策略版本管理、A/B測(cè)試設(shè)計(jì)等高級(jí)功能，實(shí)現(xiàn)從單次查詢到持續(xù)策略優(yōu)化的智能化轉(zhuǎn)變。

4、寫在最后

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

不過文章中演示的案例只是個(gè)MVP版本，實(shí)際使用需要各位結(jié)合自身的業(yè)務(wù)場(chǎng)景進(jìn)行大量測(cè)試后針對(duì)性調(diào)優(yōu)。LLM 可能會(huì)生成語(yǔ)法完美，但業(yè)務(wù)邏輯錯(cuò)誤的查詢，比如將"經(jīng)營(yíng)狀況惡化"簡(jiǎn)單理解為"status = 'bad'"，忽略了需要對(duì)比不同時(shí)期的財(cái)務(wù)指標(biāo)。這種深層的業(yè)務(wù)理解，依然是這個(gè)領(lǐng)域?qū)I(yè)人士的價(jià)值所在。當(dāng)技術(shù)門檻被 AI 逐漸抹平后，風(fēng)險(xiǎn)策略經(jīng)理的核心競(jìng)爭(zhēng)力也就正在從"如何寫 SQL"轉(zhuǎn)向"如何定義問題"。

LLM 時(shí)代的專業(yè)價(jià)值正在被慢慢重塑，LLM 能力邊界與人類專業(yè)判斷的平衡是我們每個(gè)人工作中都要面對(duì)的課題，技術(shù)賦能專業(yè)，而非替代專業(yè)，猜想未來(lái)人機(jī)協(xié)作的最佳實(shí)踐模式是人負(fù)責(zé) WHY 和 WHAT，AI 負(fù)責(zé) HOW。