最(zui)近刷到一(yi)個脫口(kou)秀(xiu)，表(biao)演者調侃自(zi)己的領導最(zui)近把(ba)AI看(kan)成(cheng)“全能(neng)員(yuan)工(gong)”或“終極救星”，甚至還(huan)沒用過就信仰上頭(tou)。

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

結(jie)果(guo)AI自(zi)然get不到(dao)領導的真實意圖，究竟是要弄(nong)啥嘞，只能(neng)一通(tong)胡亂輸出。

其實(shi)呢，AI確(que)實(shi)很強大，但前(qian)提是：你得會(hui)(hui)(hui)用(yong)、會(hui)(hui)(hui)說清楚你的目標(biao)、會(hui)(hui)(hui)給(gei)清晰(xi)的數據或(huo)上下文。

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

今天我們就聊(liao)一個AI應(ying)用中的真實案例，小(xiao)小(xiao)的揭露(lu)下(xia)AI的神秘面紗。

最(zui)近在測(ce)試AI文(wen)生SQL的(de)場(chang)景中，遇(yu)到(dao)(dao)因數據日期格(ge)式不符合最(zui)佳實踐的(de)情(qing)況，導(dao)致(zhi)AI無法直接(jie)得(de)到(dao)(dao)預期結果。

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

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

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

構造測試表，插入7條典型(xing)的測試數據(ju)，代表常(chang)見(jian)場景：

--創建測試表，指定日期格式為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;

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

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

可以(yi)看到，如果(guo)是(shi)null值（正常），length長度(du)也是(shi)null，如果(guo)是(shi)錯誤的space空格這種，長度(du)就是(shi)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個非法日(ri)期，分別(bie)都(dou)會報錯，而且可以看(kan)到錯誤(wu)描述(shu)非常精細，具體區別(bie)到究竟是(shi)月份(fen)無效(xiao)還是(shi)月份(fen)中沒有這一天，如下(xia)：

--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 的有效值。

如(ru)果我們使用簡單過濾規則，比如(ru)限定月(yue)份(fen)和(he)天(tian)數的(de)合(he)法(fa)數值：

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'

不過上述(shu)過濾其實(shi)不夠(gou)嚴謹，例(li)如沒(mei)有(you)對年(nian)份檢查，同時也僅能(neng)過濾類(lei)似(si)13月這(zhe)種明顯錯誤數據。

如(ru)果使用正(zheng)則表達(da)式(shi)來(lai)過濾（這里多校驗了年份(fen)）：

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這種特殊的情況(kuang)，表面上滿足定義的基本規(gui)律，但因為(wei)2月份壓根(gen)就沒有30號(hao)，所(suo)以就依然(ran)存在(zai)漏洞。

這個當然也可以寫復(fu)雜規則來過(guo)濾，但過(guo)濾起(qi)來就(jiu)比較(jiao)麻煩了，這也是(shi)為何強烈建議(yi)要(yao)用date數據(ju)類型(xing)存儲時間(jian)格式數據(ju)的(de)原(yuan)因(yin)之(zhi)一(yi)。

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

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

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

--使用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')

此時(shi)，如(ru)果想繼續查詢，就需要添加(jia)各(ge)種(zhong)過濾限制(zhi)條件，比(bi)如(ru)：

--報錯變成：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])$')

而一(yi)般使用(yong)字(zi)符串定義日(ri)期格式(shi)的用(yong)戶，通常(chang)對應的程(cheng)序也都是直接使用(yong)字(zi)符串來比(bi)較時間(jian)的：

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

現在(zai)問題就明朗了，要么還是(shi)選(xuan)擇to_date方式(shi)，要額(e)外(wai)增加各種(zhong)過濾條(tiao)件，要么干(gan)脆(cui)直接選(xuan)擇字符比(bi)較(jiao)。

二者(zhe)各有利弊，前者(zhe)寫(xie)法復雜，但會(hui)(hui)校驗日(ri)期格(ge)式(shi)，如(ru)果有非法日(ri)期問(wen)題還是會(hui)(hui)報錯；后(hou)者(zhe)是直(zhi)接出結(jie)果，不會(hui)(hui)過多考慮數(shu)據(ju)是否正確(que)的問(wen)題。

而至于如(ru)何讓AI文(wen)生(sheng)SQL按你的(de)(de)(de)實際(ji)場(chang)景生(sheng)成想(xiang)要的(de)(de)(de)SQL，本質就是通過提示詞(ci)工程。好的(de)(de)(de)文(wen)生(sheng)SQL軟(ruan)件會提供(gong)非常靈活的(de)(de)(de)各種配(pei)置選(xuan)項，來(lai)應(ying)對適配(pei)各類復雜場(chang)景，最終在相互配(pei)合(he)下(xia)就可以做到(dao)相對精確的(de)(de)(de)影響到(dao)LLM的(de)(de)(de)處(chu)理行為邏(luo)輯，從而生(sheng)成符合(he)實際(ji)用戶需求的(de)(de)(de)SQL并執(zhi)行得到(dao)預期(qi)結果。

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

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