用自然語言查詢數據，為何會出錯？
問題幾乎從來不在於模型不懂推理，而在於模型被要求同時做三件事：理解問題、找到正確的數據，以及產生準確的查詢或事實。第一件事正是語言模型擅長的。另外兩件事每次都要做對，而一個 95% 時間正確的模型，每星期都會在客戶面前出錯。
我們在四種截然不同的數據上建立過這個模式，故障出現的方式每次都一樣。答案很有自信，卻建立在模型猜出來的欄位、被當作文字閱讀的表格，或只記得一半的代碼上。
| 數據 | 用戶會問 | 缺乏防護時在哪裡出錯 |
|---|---|---|
| 附有圖表和表格的長篇 PDF 報告 | 「把 2024 年風險框架的更新整理成表格」 | 表格在行中間被切開、圖表從未被索引、來源遺失 |
| 欄位眾多的交易資料庫（100+ 欄） | 「西南部、LTV 低於 70% 的工業物業」 | 捏造欄位、同義詞出錯、自由格式 SQL |
| EDI 交易（X12） | 「發票 4471 的付款期限是多少？」 | 讀錯 segment 位置、猜測代碼 |
| 內部 wiki | 「我們如何為新學校辦理加入手續？」 | 網上結果沒有標籤便混入、以猜測填補空白 |
哪些交給模型，哪些交給程式碼？
寫提示詞之前，先劃清界線。我們的分工如下：
| 語言模型 | 確定性程式碼 |
|---|---|
| 理解問題及其業務詞彙 | 建立並執行查詢 |
| 把多部分的要求拆成子問題 | 驗證欄位、運算符、範圍和代碼 |
| 選擇使用哪個工具或來源 | 跨系統比對記錄（PO 對發票、EDI 對 ERP） |
| 用日常語言寫出答案並附上來源 | 阻止任何寫入操作，並記錄每一個查詢 |
在一個交易搜尋項目中，這代表模型完全不寫 SQL。它輸出一個篩選計劃，例如 {"primary_asset_type": "Industrial", "proposed_loan_to_value__lt": 70}。Schema 會拒絕任何不存在的欄位，再由受版本控制的程式碼把計劃轉成唯讀查詢。同一個問題，每次都得出同一句 SQL、同一批資料列。
如何填補詞彙落差？
在系統回答第一個問題之前，先剖析並描述數據。以資料庫為例，即每一欄的類型、空值比率、基數、數值範圍和最常見的數值。然後由模型以 temperature 0 為每欄寫一句描述和幾個同義詞，讓「loan amount」、「LTV」和「southwest」都能對應真實的欄位和數值。
檢索以這份剖析為基礎，而不是原始 schema。做法是用實體索引處理精確名稱，對描述做向量搜尋，對數值做模糊比對（「york」可找到 New York）。輸出是一份簡短摘要，列出問題需要的表格、欄位和數值，再交給規劃查詢的步驟。
EDI 的詞彙落差在團隊之間：業務團隊說「發票 4471」，EDI 團隊說「810」。第一步是把業務用語對應到交易類型，再由一個以 EDI 詞彙微調的模型翻譯回日常英文。
附有表格和圖表的文件應如何解析？
按版面解析，而且要在任何內容進入向量資料庫之前完成。先偵測每頁的區域：文字、表格、圖像、圖說。把每個表格和圖表連同圖說裁出，用視覺模型讀取，再把結果連同圖片路徑、頁碼和檔案名稱一併索引。文字按意思分塊，而不是按字元數。
這樣做有兩個結果。關於圖表的問題終於可以回答，而每個答案都能指出出自哪一頁。在一個合規資料庫項目中，這正是重點：審計師無法引用的答案是一種負債，算不上答案。
檢索會混合關鍵字搜尋和語義搜尋，我們大約以 30/70 分配權重。原因是名稱、代碼和規則編號，正是純嵌入模型最容易錯過的。
用戶問得含糊，怎麼辦？
用戶會問得含糊，而受影響更大的是檢索，不是模型。我們為一家資產管理公司的研究助手比較了三種改寫策略，每種都以檢索結果與未改寫的問題作比較：
| 問題類型 | 策略 | 作用 |
|---|---|---|
| 含糊、沒有關鍵字 | 假設答案（HyDE） | 先草擬一個用詞與文件相近的合理答案，再用它搜尋 |
| 一次問幾個問題 | 改寫、檢索、閱讀 | 搜尋前把要求拆成獨立查詢 |
| 探索性 | 多角度追問（STORM） | 提出用戶下一步會問的追問 |
沒有一種策略在所有情況都勝出。按問題類型分流，並在檢索階段而不是最終答案量度成效。
如何處理多部分的問題？
真實的問題往往以指示的形式出現：「總結風險更新，然後整理成表格，欄目為更新內容、受影響對象和日期。」拆解步驟會把這些要求分成子問題。每個子問題執行前，都會檢查是否與原問題相關，避免推理鏈偏離。
Agent 為每個部分選擇工具，例如檢索、整理成表格、搜尋 wiki 或計算。最後再檢查合併後的答案是否涵蓋所有要求。
如果答案是表格，我們會為表格和普通檢索答案分別評估相關性，保留較好的一個，或根據檢索到的文字改進表格。用戶只看到一個答案；系統已靜靜地在兩者之間作出選擇。
如何在正式環境中保持可信？
- 檢索前先篩查。每則訊息在觸及任何數據之前，都會先經過安全檢查。
- 為每個來源加上標籤。內部文件、網上資料和參考來源在上下文中分別標註，並在答案中引用，從不靜靜混在一起。
- 好好拒絕。數據未涵蓋問題時，便直說。在一個內部 wiki 機械人上，這些拒絕作答的紀錄，成了團隊需要補寫的頁面清單。
- 逐個組件做基準測試，而不是只測整體。我們按每個步驟並排測試模型。在一個項目中，較大的模型負責欄位描述，因為描述質素決定配對效果；便宜約 90% 的模型則負責實體分組，表現相同甚至更好。
- 記錄計劃，不只是答案。參數、實際執行的查詢、使用的來源。答案受到質疑時，你可以展示推算過程。
常見問題
Text-to-SQL 適合直接開放給業務用戶嗎？
不適合以自由格式 SQL 的方式開放。讓模型輸出一個由 schema 驗證的結構化篩選計劃，再由程式碼據此建立唯讀查詢。未知欄位會被拒絕，同一個問題每次都得出同一結果。
RAG 能回答 PDF 內圖表和表格的問題嗎？
可以，前提是文件先按版面解析。表格和圖像連同圖說一併裁出，由視覺模型讀取，並連同來源頁碼和檔案一起索引。如果當作普通文字處理，這些內容便會無聲無息地遺失。
我們需要微調模型嗎？
通常不需要。剖析和描述數據，已能填補大部分詞彙落差。微調在 EDI 等專門格式上才值回成本，因為這類詞彙與一般訓練數據截然不同。
如何防止 AI 捏造答案？
讓它少做決定。模型負責理解和解釋；確定性程式碼負責查詢、驗證和比對；每個答案都附有來源；而「數據沒有提及」是容許的答案。
本指南背後的項目，逐步拆解。
何時平台已經足夠。
在給予工具權限之前。
以引用為先的檢索，由建立到運行。
關於作者
Cat Yung是 Super Cat Technology 創辦人，團隊在香港及倫敦開發 AI Agent，並以 AI 專家、Data Scientist 及兼職 CTO 身份與企業合作。擁有逾十年生產級 AI、NLP 及機器學習經驗；Upwork Expert-Vetted 前 1%，Job Success Score 100%（來源：Upwork 個人檔案，2026 年 10 月）。