Demo：兩份規則都撈到了，答案還是錯

問題：計畫執行期滿後，什麼時候要完成結報？

Retrieval 成功，不代表 decision 成功。

這是第一次用可以現場跑的程式，具體展示規則判定層和 baseline RAG 的差異。

當時的資料流程已經能跑，但還不夠受控

法規 PDF → 純文字 → 結構化 JSON → 人工複核 → 規則判定

當時最大的弱點在「PDF → 結構化規則」：

• 主要還是讓 AI 看內容後自行抓欄位。
• 有人工複核，但沒有一套保證每個面向都被檢查過的固定程序。
• 規則欄位是從現有文件「看到什麼就加什麼」，完整性仍靠人的直覺。

引擎可以是 deterministic，但如果進去的規則本身漏了條件，最後仍然會穩定地判錯。

覆蓋率也開始暴露另一個問題：資訊不完整時怎麼辦？

測試題當時分成 A–E 類：

• A–D：大多已經有規則可判。
• E 類：使用者情境不完整，需要系統反問。

這類還沒有完成。

下一步不只是增加更多規則，而是讓系統知道：

目前缺哪個案件事實？這個事實會不會改變判定？如果會，就先問。

老師的核心要求二：抽取流程不能整包交給 LLM

老師區分了兩件事：

• judge.py：已經是固定規則邏輯。
• PDF → 結構化規則：仍太像讓 LLM 自由發揮。

要改成：

程式決定每一步一定要檢查什麼 → LLM 只回答這一步 → 程式再驗證答案

不是相信模型「應該有想到」，而是讓流程本身保證每個檢查都被執行。