Alfred Zhao 從Oracle起航，領略精彩的IT技術。

最近刷到一個脫口秀，表演者調侃自己的領導最近把AI看成“全能員工”或“終極救星”，甚至還沒用過就信仰上頭。

于是跟風投資建設了一套企業內部AI平臺，搭建好之后呢，興奮無比地給AI甩了一堆材料，然后就跟往常對人類員工布置任務一樣，跟AI講，“你給我弄下。”

結果AI自然get不到領導的真實意圖，究竟是要弄啥嘞，只能一通胡亂輸出。

其實呢，AI確實很強大，但前提是：你得會用、會說清楚你的目標、會給清晰的數據或上下文。

那如今AI應用的真實場景是什么樣的呢？

今天我們就聊一個AI應用中的真實案例，小小的揭露下AI的神秘面紗。

最近在測試AI文生SQL的場景中，遇到因數據日期格式不符合最佳實踐的情況，導致AI無法直接得到預期結果。

這類問題比較典型，因為各種各樣的原因，即便在很多客戶的生產環境中也廣泛存在，就是在業務表中的某個時間類型的字段，對應的數據類型設置不符合規范，經常被錯誤設置為字符串數據類型，從而導致一些潛在問題。

下面我們就來模擬下這個場景。

注意：本文并不是標準答案，因為實際場景可能涉及更多的細節和個性化設置，所以本文只是提供一個調試思路，當大家未來遇到類似問題時，參考使用。

構造測試表，插入7條典型的測試數據，代表常見場景：

--創建測試表，指定日期格式為varchar2，模擬客戶環境
create Table test (id number, delivery_date varchar2(20), content varchar2(50));

--插入幾行測試數據
insert into test values (1,'20250722','normal');
insert into test values (2,'20250511','normal');
insert into test values (3,'20250518','normal');
insert into test values (4,null,'null值');
insert into test values (5,' ','space空格'); --模擬數據質量問題"空格"
insert into test values (6,'20250230','非法日期');--模擬數據質量問題
insert into test values (7,'20251301','非法日期');--模擬數據質量問題
--delete from test where id=6; --刪除2月30號非法日期（測試過程中會用到）
--delete from test where id=7; --刪除13月1號非法日期

commit;

這里也可以看到，因為字段不是date時間數據類型，如果程序邏輯再處理不當或有bug，后臺表中就可能存在被插入任意非法值，導致一系列的數據質量問題。

select id, length(delivery_date), content from test;

可以看到，如果是null值（正常），length長度也是null，如果是錯誤的space空格這種，長度就是1：

--ORA-01840: 輸入值對于日期格式不夠長。 "input value not long enough for date format"
select to_date(' ','yyyymmdd') from dual;

--注意：null值不算有問題，因為null值不會報錯，返回也是null：
select to_date(null,'yyyymmdd') from dual;

--針對空格的workaround，使用trim函數，這樣也會返回null：
select to_date(trim(' '),'yyyymmdd') from dual;

這類數據其實相對比較好過濾，比如通過length函數來過濾，只取length(delivery_date) = 8的數據即可。

--過濾掉長度不為8的無效數據
select * from test where length(delivery_date) = 8;

--嚴謹角度也可以加入trim，過濾掉極端場景，比如恰好有8個空格的情況..
select * from test where length(trim(delivery_date)) = 8;

但是，另外一些符合長度8的非法日期，依然存在，
比如這里模擬構建的2個非法日期，分別都會報錯，而且可以看到錯誤描述非常精細，具體區別到究竟是月份無效還是月份中沒有這一天，如下：

--ORA-01839: 指定月份的日期無效。 "date not valid for month specified"
SELECT TO_DATE('20230230', 'YYYYMMDD') FROM dual; 
--因為你傳入的字符串，年份和月份是合法的，但對應的日期 在該月中并不存在。

--ORA-01843: 指定的月份無效。 "An invalid month was specified."
SELECT TO_DATE('20251301', 'YYYYMMDD') FROM dual; 
--因為你傳入的字符串，經過解析后發現 月份部分不是 01~12 的有效值。

如果我們使用簡單過濾規則，比如限定月份和天數的合法數值：

select * from test 
where length(delivery_date) = 8 
and SUBSTR(delivery_date,5,2) BETWEEN '01' AND '12'
AND SUBSTR(delivery_date,7,2) BETWEEN '01' AND '31'

不過上述過濾其實不夠嚴謹，例如沒有對年份檢查，同時也僅能過濾類似13月這種明顯錯誤數據。

如果使用正則表達式來過濾（這里多校驗了年份）：

select * from test 
where length(delivery_date) = 8 
AND REGEXP_LIKE(delivery_date, '^(19|20)\d{2}(0[1-9]|1[0-2])(0[1-9]|[12]\d|3[01])$')

正則表達式中雖然加了年份過濾，也把20251301這種明顯違法范圍值的無效數據就會被過濾掉了，但是像20250230這種特殊的情況，表面上滿足定義的基本規律，但因為2月份壓根就沒有30號，所以就依然存在漏洞。

這個當然也可以寫復雜規則來過濾，但過濾起來就比較麻煩了，這也是為何強烈建議要用date數據類型存儲時間格式數據的原因之一。

下面我們來具體測試AI文生SQL場景下這類問題的影響：

場景：要求查詢2025年上半年的數據

自然語言轉成SQL，LLM默認過濾時間基本都會使用標準的to_date()函數操作，這也是情理之中，符合正常情況下的最佳實踐。但是因為我們這里的時間是字符串存儲的，屬于非正常情況，可能會因此報各種錯誤信息：

--使用to_date函數來過濾時間列，查詢2025年上半年的數據：
--該查詢會報錯：ORA-01840: 輸入值對于日期格式不夠長
select * from test 
where TO_DATE(delivery_date, 'YYYYMMDD') >= TO_DATE('20250101','YYYYMMDD') and to_date(delivery_date,'YYYYMMDD') < to_date('20250701','YYYYMMDD')

此時，如果想繼續查詢，就需要添加各種過濾限制條件，比如：

--報錯變成：ORA-01839: 指定月份的日期無效
--這是因為表中還有20250230這樣的非法日期沒過濾掉，但如果沒有這條數據，就可以成功執行了：
select * from test 
where TO_DATE(delivery_date, 'YYYYMMDD') >= TO_DATE('20250101','YYYYMMDD') and to_date(delivery_date,'YYYYMMDD') < to_date('20250701','YYYYMMDD')
and length(delivery_date) = 8 
AND REGEXP_LIKE(delivery_date, '^(19|20)\d{2}(0[1-9]|1[0-2])(0[1-9]|[12]\d|3[01])$')

而一般使用字符串定義日期格式的用戶，通常對應的程序也都是直接使用字符串來比較時間的：

--這樣雖然不會報錯，但是例如20250230這樣的非法日期數據，也會被查詢出來
--只能依靠程序來控制不要輸入此類非法數據
select * from test 
where delivery_date >= '20250101' and delivery_date < '20250701'

現在問題就明朗了，要么還是選擇to_date方式，要額外增加各種過濾條件，要么干脆直接選擇字符比較。

二者各有利弊，前者寫法復雜，但會校驗日期格式，如果有非法日期問題還是會報錯；后者是直接出結果，不會過多考慮數據是否正確的問題。

而至于如何讓AI文生SQL按你的實際場景生成想要的SQL，本質就是通過提示詞工程。好的文生SQL軟件會提供非常靈活的各種配置選項，來應對適配各類復雜場景，最終在相互配合下就可以做到相對精確的影響到LLM的處理行為邏輯，從而生成符合實際用戶需求的SQL并執行得到預期結果。

另外通過這個典型場景也可以切身領悟到，就算AI再強大，但對那些讓人類實際工作都踩過坑的事情，對于AI來說同樣是挑戰，你不跟他通過“提示詞”交流說清楚具體是個啥情況，對于特定場景下那些稀奇古怪的彎彎繞它一樣無法理解。

所以呢，AI雖然厲害，但也不必迷信AI，有了它，工作效率的確是大大提升了，但我們依然還是要面臨處理很多意料之外的事情，這其實也是我們人類身處于這個豐富多彩的現實世界的魅力所在。