系統全解與現場拷問

回答上面那一行小字（「已完成分析 · 1.6 秒」）點開，會看到這一輪經過的步驟、每一步的結果、耗時， 最底下還有一組請求編號。典型的一題長這樣：

理解問題      期間 2022 年 11 月（2022-11）    preprocess   完成
判斷意圖      分析 · LLM 124 ms               intent       完成
查資料        1 筆，38 ms                     sql          完成
統整回答      108 字                          synthesize   完成

（這是問「2022 年 11 月有多少張訂單」時的實際畫面。） 左邊是這一步的中文名稱，中間是這一步實際得到什麼，右邊灰色小字是這一步的程式代號 （preprocess／intent／sql／synthesize）， 最右邊是狀態。

順序是固定的，而且有理由：一定是先「理解問題」再「判斷意圖」。 因為前處理要把「第二名呢」這種追問補成完整問句，而意圖分類器只看得到那一句話—— 沒補的話它只收到三個字。詳見 §02。

為什麼要給使用者看？因為這套系統的賣點是「講得出依據」。 如果只回一段話，使用者沒辦法判斷該不該相信；把經過攤開，他至少知道系統查了什麼、用什麼條件查。

總共只有四類：

• 分析 —— 要查公司資料、數字、文件。絕大多數問題都落在這裡。
• 系統說明 —— 在問這個助理本身（你是誰、你用什麼模型、資料會不會外流）。
• 一般對話 —— 只有招呼、道謝、寒暄，完全沒在問資訊。
• 業務操作 —— 要系統去做一件事（目前就是建訂單）。

分成四類的目的是決定接下來走哪一條流程。問候語不需要去翻資料庫； 問「你用什麼模型」不需要去查知識庫（以前沒分這類的時候，這一題會跑去翻公司的 AI 使用政策文件）。

這一步同時還做了第二件事：順便選好要走哪一條流程。所以它不是「先分類、再另外選流程」兩次呼叫，是一次解決。

LLM 是指這一步用語言模型判的。旁邊還可能出現另外兩種字樣：

• 規則 —— 模型連不上時的備援，用關鍵字判（招呼語、「你是誰」這類字串）。整條鏈不會因為分類器掛掉就死。
• 附件 —— 使用者傳了圖，直接判成業務操作，連問都不用問模型，所以是 0 毫秒。

一百多毫秒大約就是一次網路來回的時間（實測穩定約 130 ms）。 冷啟動第一次會比較久，實測約 250 ms。

「理解問題」那一行的規則不一樣：抽到什麼就列什麼 （期間、客戶、商品、單號、「補上前文 →⋯」），一個都沒抽到就寫「無特別條件」。 所以那一行其實是在告訴你「我從你這句話裡聽懂了哪些條件」。

• 名字來自兩個地方：流程 YAML 裡每一步的 label （而且是寫成中／英／日三語的），以及後端程式裡的固定字串（理解問題、判斷意圖）。
• 順序就是事件到達的順序——前端收到一則沒看過的步驟就往清單尾端加一筆， 不排序、不重組。

這件事的意義：畫面上看到的順序，就是後端真的執行的順序。 要改順序只能改後端，改不動前端。這也是為什麼「進度列是真的不是動畫」這句話站得住。

為什麼要有上限：一個沒寫好的查詢可能回幾十萬列，那會把畫面、記憶體、 以及送進統整的內容全部撐爆。

為什麼要明說：如果默默只給前 200 列，使用者會以為那就是全部， 然後根據不完整的資料做判斷。寧可讓畫面難看一點，也不要讓人算錯。

這跟「查無資料」是同一個原則的兩面——系統寧可少答、寧可承認限制，也不要講一個 看起來完整但其實不完整的答案。

這一步把人話換成機器用得上的條件，做四件事：

• 時間詞換成日期區間：「這個月」「上個月」「上季」「去年」「2026年8月」都換成起訖日。
• 公司／商品的俗名換成代號：查一張別名表。長的名字先比，「宏達精密」不會被「宏達」搶走。
• 單號補齊：「訂單 104705」補成十位數的 0000104705（SAP 的單號是固定十碼）。
• 追問沿用上一輪：上一題問了 8 月，這題只問「那毛利呢」，期間就沿用 8 月。

那一行顯示的就是它從你這句話裡聽懂的東西，三種可能：

• 抽到了就列出來 —— 例如「期間 2022 年 11 月（2022-11）」「客戶 大同材料（C-1088）」。
• 你沒講期間 —— 寫「未指定期間，預設全期間」。 意思是「我自己補了一個，而且我把補的內容告訴你」。 這句話存在的唯一理由就是——預設值要說出來，不能默默假設。
• 什麼都沒抽到 —— 寫「無特別條件」（例如問「你好」或純文件類的問題）。

分界線是：猜錯了還救得回來的，就猜並講出來；猜錯會給出一個看起來合理但錯誤的答案的，就停下來問。

• 期間沒講 → 預設並標示。使用者看到「預設全期間」，不對就改口再問一次，成本很低。
• 問「這張單出貨了嗎」但沒給單號 → 停下來問。隨便挑一張單回答，使用者根本看不出來那不是他要的那張。

後者在畫面上的樣子是：不給表格，直接回「請告訴我訂單號碼」。

這一步的完整經過是：把問句原文送給 AI team 的 text-to-SQL 服務 → 他們的模型當場產出一句 SQL → 在他們那邊執行 → 把「實際跑的那句 SQL」和「查到的資料列」一起回來。

同一行還可能多出兩段括號，都是值得多看一眼的訊號：

• （重修 2 輪） —— 模型第一次產的 SQL 跑不起來，自己改了兩次才成功。 遇到這個，前端會把 SQL 預設展開。
• （已截斷） —— 資料超過一次帶回的上限（200 列），只給了前面那些。

資料在一顆叫 middledb 的 PostgreSQL（192.168.170.31）， 裡面是 SAP 銷售模組 12 張表的鏡像子集——不是 SAP 本尊。 為什麼不直接連 SAP，見 §03。

這一步是唯一一個「讓模型寫字」的步驟。有引用到證據的題目，這一格還會多一個數字： 321 字，引用 3 片——引用了幾片證據。

那個「引用幾片」才是真正有用的訊號：如果一段答案寫了 300 字卻一片證據都沒引用， 那就是模型在自由發揮，是要抓出來的狀況。實體的監控系統就有一條固定查詢在找這種案例 （引用數 = 0 而且有回答）。

實體：每一則進度都是後端真的執行到那一步才送出來的，內容是那一步的實際結果 （命中幾片、判斷結果是什麼）。技術上是用 SSE 一則一則推給前端的。

雛形：沒有後端，進度列的毫秒數是腳本裡寫死的示範值。 被直接問「這是真的嗎」，照實講——而且緊接著補一句：但知識庫的檢索是真的在瀏覽器裡算的 （見下面 tf-idf 那題），可以當場換一個沒準備過的問題試。

ChatGPT 那類產品的目標是讓你忘記背後有流程；這套的目標相反—— 使用者必須看得到它查了什麼、用什麼條件查、依據是哪幾片文件， 因為它回答的是會被拿去做決策的公司數字。

更實際的理由：text-to-SQL 的正確率是 76%，不是 100%。 所以判斷「這個答案對不對」的責任，一部分必須留在看的人身上。 系統能做的是把依據完整攤開，讓他有東西可以判斷——這就是為什麼 SQL 也給看。

使用場景很具體：使用者說「剛剛那題答錯了」。沒有這串編號，你要從幾千筆紀錄裡猜他問的是哪一題； 有這串，貼進查詢介面就直接跳到那一次的完整經過——他問了什麼、系統理解成什麼條件、 產出哪句 SQL、撈到哪幾片文件、每片分數多少、最後答了什麼。

所以畫面上它旁邊有一顆複製鈕：設計上就是要使用者截圖或複製回報用的。

流水號需要有人負責發號，而且只能有一個人發，否則兩台機器會發出同一個號。 這套系統橫跨後端、模型服務、text-to-SQL 服務，未來還會更多。 改成 128 位元的隨機值，每台機器各自產生也幾乎不可能撞號——128 位元寫成十六進位就是 32 個字。

而且它的用途不是給人記的，是給人複製的，所以長度不重要。

雛形沒有後端，所以沒有真正的追蹤系統；它只是產一個「格式一模一樣」的 32 位十六進位字串， 讓畫面跟實體長得一樣。

實體那邊是 OpenTelemetry 這套追蹤工具在請求進來時產生的， 而且會寫進後端每一行日誌，所以日誌跟畫面上那串對得起來。

被問到時的答法：「雛形這一格是演給你看格式；實體那邊它是真的可以拿去查的。」 不要說「這是真的」——現場如果有人要你當場拿它去查，就下不了台。

知識庫裡有十幾份文件，被切成幾十到上百個小段落（每段約 450 字）。 使用者問一句話，系統要從這些段落裡挑出最相關的五段，交給後面統整成答案。 「怎麼挑」就是 tf-idf 在做的事。

tf-idf 的邏輯用一句話講：一個詞如果在這一段裡出現，而且它在其他段落裡很少出現， 那這個詞就很能代表這一段。

• 「的」「我們」「公司」到處都是 → 幾乎不加分
• 「達交率」只出現在兩三段裡 → 一旦命中，分數很高

所以問「達交率怎麼定義」，講達交率定義的那幾段自然浮上來，而講資訊安全的那幾段沉下去。

這一點值得講清楚，因為它正好示範了這套系統的態度： 能用確定的方法做的事，就不要用模型做。

tf-idf 的好處是：零依賴（不用另外架一個服務）、速度極快、結果完全可重現、 而且可以解釋為什麼這一段被選中——因為它命中了哪幾個詞、每個詞值多少分，全都算得出來。

代價是它只看字面：問「交貨慢了怎麼辦」，文件裡寫的是「延遲交付的處理程序」， 字不一樣就對不上。這正是後面要換成向量檢索的理由。

它在程式裡的名字就叫「本地假 RAG」，而且註解直接寫著 「等 AI team 的 API 上線就刪」——不是偷偷留一套自己的實作，是明確標示的過渡。

為什麼要先做一個頂著？因為這樣整條路可以先跑通：意圖、流程、證據池、統整、引用、 監控全部都能驗，不用等別人。而且因為回傳的形狀跟對方 API 的規格一模一樣， 換過去的時候畫面與流程完全不用動。

三個常見的誤會，一個一個拆：

正確的圖像：檢索與生成是兩格，而且永遠不會合併

幾百片文件 ──[ 檢索 ]──> top 5 ──[ LLM ]──> 一段有引用的話
                ↑                        ↑
             tf-idf 站這格            統整站這格
         （之後換成向量檢索）        （永遠是 LLM）

所以接上 AI team 的正式服務時，被換掉的是「用什麼方法比對相關度」 （字面比對 → 語意比對），不是「這一格改成給 LLM 做」。 那一格未來也不是 LLM，是嵌入模型加向量比對——那是另一種模型，不是語言模型。

順帶一提它為什麼現在夠用：知識庫目前是幾百片的規模，線性掃就夠快； 而且 tf-idf 的結果可以解釋（命中哪幾個詞、各值多少分）， 向量檢索反而說不清楚為什麼這片排前面。等文件量上千，才輪到向量檢索的優勢。

「達交率定義」會被拆成 達交、交率、率定、定義。 英數字則整個詞取（vbak、s4hana）。

為什麼不用正規的中文斷詞工具？因為那要多一個函式庫、多一份詞典， 而且專有名詞（料號、客戶代號）反而容易被斷錯。 bigram 的做法雖然土，但不需要詞典也不會漏，對這個規模剛剛好。

實體程式與雛形用的是同一套演算法（雛形搬到瀏覽器裡跑），所以兩邊的檢索行為一致。

設計上這兩者是可以直接替換的：介面（送什麼、回什麼）已經定好寫成規格交給 AI team， 本地這版回傳的形狀跟他們的 API 一模一樣。 換過去只要改一個設定值 aibrain.rag.provider=http，其他一行都不用動。

這正是「先把流程跑通、能力之後再換」這個設計的實例： 沒有向量模型也能演完整條路，而且之後換上去，畫面與流程完全不變。

這件事很重要，因為它很容易被誤讀成「系統只有 52% 的把握」。不是。 這個分數是排序用的，不是信心度。

系統真正用它做的判斷只有一個：如果最高分的那一片都低於門檻，就當作查無資料， 而且不呼叫模型寫答案。雛形的門檻是 0.1，另外還要求至少命中 2 個不同的詞 （實測發現完全不相關的問題偶爾也能拿到 0.11，但它只命中 1 個詞，真命中都是 2～6 個）。

之後接上正式的檢索服務，如果對方有「重排」（reranker）這一層，分數的性質會變成校正過的、 可以用絕對門檻；現在沒有，所以只能用相對的。

先講數字本身，兩邊還不一樣：

為什麼要加「至少命中 2 個詞」——這是實測記在程式註解裡的，可以直接當答案講：

所以誠實的答法是：「這個數字沒有理論依據，是拿實際問題試出來的。 而且試的過程發現單看分數不可靠，所以加了一個更穩的條件。」

這件事本身也回答了「為什麼分數不能當信心度」： 0.11 的雜訊跟 0.14 的真命中差不多高，這個分數根本沒有絕對意義， 它只能在同一次檢索裡排序。

滑過去會浮出預覽卡（標題＋那一段原文＋章節／頁碼／來源），點下去會打開右側面板並高亮那一片。

這是整套系統「可稽核」最具體的證明：使用者不需要相信模型，他可以自己去看原文。

編號是程式給的不是模型給的——證據被撈回來時就依序編號了，模型只能引用存在的編號， 超出範圍的編號會被程式過濾掉。所以不會出現「引用了一個不存在的來源」這種事。

已完成分析 · 1.6 秒                      ← 點這一行展開
┌──────────────────────────────────────┐
│ 查結構化資料 · data_query              │  ← 走哪條流程
│ 期間 2018-10-29 ~ 2024-11-15（未指定，  │  ┐
│ 預設全期間）  幣別 USD  基準日 …        │  ┘ ← 「我理解的條件」在這排
├──────────────────────────────────────┤
│ 理解問題    期間 …            完成      │  ┐
│ 判斷意圖    分析 · LLM 124 ms  完成     │  │ ← 步驟清單
│ 查資料      1 筆，38 ms        完成     │  ┘
│ …                                     │
│ 請求編號  abbe4831…            ⧉        │  ← 最底下
└──────────────────────────────────────┘

所以它跟「走哪條流程」並排，在步驟清單前面——順序是有意義的： 先告訴你「我理解成什麼、要走哪條路」，再讓你看「我實際做了哪幾步」。

• 前處理抽出來的：期間、客戶、商品——規則算出來的。
• text-to-SQL 回報的：對方在產 SQL 時，順便用查詢計畫結構化產生的條件短句。

第二個來源特別值得講：因為它沒有經過語言模型，所以即使這一題查無資料，它也可以安全地顯示出來。 使用者就看得到「系統是照什麼條件去查的、才查不到」，而不是只拿到一句冷冰冰的「查無資料」。

為什麼這一排是整個畫面最該先看的東西：實務上答錯最多的不是 SQL 寫錯， 而是條件理解錯——問的是 8 月、它算成全期間；問的是甲客戶、它對到乙客戶。 這一排就是拿來當場抓這種錯的。

不是出錯——它最後成功了。但這是一個值得多看一眼的訊號：模型卡過， 代表這一題對它來說不直觀，產出的 SQL 比較可能語意上偏掉。

所以前端的處理是：一旦重修超過一輪，就把 SQL 區塊預設展開， 讓使用者第一眼就看到它到底查了什麼。這是對方（AI team）建議的做法。

兩個理由：

• 對懂的人：那是唯一能驗證「這個數字對不對」的東西。76% 的正確率之下， 不給 SQL 等於要人盲信。
• 對不懂的人：他不會展開，但他知道有。「這套系統敢把它查的每一句都給你看」， 這件事本身就在傳達可稽核。

順帶一提：正因為我方沒有連線，模型產的 SQL 再糟也碰不到任何東西—— 這是拔掉資料層的附帶好處，可以接著講。

每一張卡可以展開完整片段，也可以開啟整份來源文件（會標出這次引用的是哪一段）。

「撈到但沒用上」這一組看起來多餘，其實是檢索品質的指標： 如果長期撈五片只用一片，代表檢索抓得不夠準。 實體程式的監控紀錄就有逐片記「這片有沒有被引用」這個欄位，用途正是這個。

整段等完再一次顯示，使用者要盯著轉圈好幾秒；逐字送出則是一有內容就看得到。

技術上用的是 SSE（見 §08），一條單向的通道，後端有東西就推一則過來。 進度列能一步一步亮起來也是同一條通道。

順帶一提，逐字生成時 Markdown 會有一瞬間的中間狀態（粗體還沒收尾之類）， 那不是壞掉，實體程式也一樣。

這一點在實體程式是刻意做的：前端斷線（按停止、關分頁）會通知後端， 調度層每跑一步、串流每送一個字都會檢查這個旗標。 理由很實際——不要讓模型和資料庫替一個沒人在看的請求繼續跑，那張 GPU 是共用的。

被放棄的請求在紀錄裡會標成 cancelled，所以事後統計得出「有多少題使用者等不下去」。

「重新產生」只出現在最後一則回答。它會原樣重送當初那次請求—— 這在建單流程特別重要：在草稿卡那一步按下去，是「再辨識一次」，不會變成一句普通閒聊。

實體程式開機會自動載入 15 份示範文件（出貨與交期 SOP、達交率定義、分批交貨規範、 開票與請款規範、客戶分級與信用政策、資安規範、AI 使用政策……），切成片放進檢索索引。

目的是讓 demo 一開機就有東西可以查，不必先上傳。真文件到了，從這一頁上傳取代即可。

可以現場演的一段：在這一頁匯入一份 .md，回到聊天室馬上就問得到、引用得到。 這一段雛形是真的（在瀏覽器裡真的切片、真的重建索引），不是腳本。

實測案例（Adam 記在程式註解裡）：使用者先問「2025 年營業費用最高的五個科目」， 接著問「第二名呢」。

• 沒還原：意圖分類器與 text-to-SQL 都只收到「第二名呢」三個字， 產出的查詢跑去查客戶營收——完全不相干。
• 有還原：補成「2025 年營業費用金額最高的前五個科目中，第二名是哪個科目？」， 後面每一步都看得懂。

關鍵在於一次請求裡有三個地方需要上下文，但只有統整拿得到對話歷史； 意圖分類與 text-to-SQL 都只收到一句話。所以脈絡必須在入口就補進那一句裡。

已經對齊的（每一項都指得回程式碼）：

還沒對齊、而且被問到要答得出理由的：

問題：哪些訂單有交貨但還沒開票？
查詢條件：期間 2018-10-29 ~ 2024-11-15（未指定，預設全期間）；幣別 USD

資料片段（只能根據這些回答）：

[1] 查詢結果：履約分類（5 筆）（WrenAI text-to-SQL，2026-09-15）
分類 | 項目數 | 金額
已開票 | 1,204 | …

[2] 開票與請款規範 › 第三節 開票時點（規範，財務部，2026-05-04）
…原文…

請依規則回答。

另外還有一份「規則」（system prompt），六條，關鍵的是這幾條：

• 只能根據片段回答；片段沒有就說「片段中沒有提到」，不要推測、不要補外部知識。
• 每個論點句尾標片段編號 [1]；沒有依據的句子不要寫。
• 不要自己計算或編造數字，數字只能照原文引用。
• 查詢結果的表格前端會完整顯示，所以最多只點名前三筆，其餘一句總結——逐列複述整張表是錯的。
• 條件若是預設值（例如未指定期間），在第一句順帶說明。

還會附上最近四輪對話，讓它接得上追問。

COUNT、SUM 這種聚合查詢永遠回一列。 所以「0 列＝查無資料」擋不住「回一列 {count: 0}」這種情況。

實測發生過：問「這個月有多少張訂單」，對方把它對成 COUNT(會計憑證) 回了一列 0， 統整很有自信地寫出「本月訂單數量為 0 張」。 而事實是那套系統裡根本還沒有訂單資料——系統斷言了一個業務事實，這比說查無資料糟得多。

修法是把判斷條件收窄成：單列、而且每一個欄位都是 null／0／空字串，才算查無資料。 只要有任何一欄帶著資訊（例如分組用的公司名）就當成真的有資料。

代價誠實地寫在程式註解裡：真正答案就是 0 的題目（例如本月逾期 0 張）也會被說成查無資料。 這個方向是故意的——寧可少答，不要講錯。

逾時設定：text-to-SQL 給 60 秒（對方上限 120 秒、內部會重試 2～3 輪，實測一輪 9～13 秒， 60 秒涵蓋三輪），調度層總預算 90 秒。不跟到 120 秒是刻意的—— 等到那時才失敗，連前面成功的查詢都會被一起丟掉。

前端直接打模型，能做到的只有「把問題丟給模型、把回答顯示出來」。 這樣做會失去四件事：

• 取證 —— 誰去查資料庫？誰去翻文件？誰決定查哪個？
• 控制 —— 誰決定查不到就停？誰守住步數與逾時上限？
• 稽核 —— 誰記下這一輪查了什麼、依據是哪幾片？
• 安全 —— 模型端點不能直接暴露給瀏覽器。

用 Tom 那張架構圖的說法：應用層管 WHAT NEXT 與 WHEN STOP，AI 能力服務管 HOW TO EXECUTE。 能力服務不准自己決定整個任務完成沒有。

這是刻意的取捨，理由寫得很直白：決策要可預期、可稽核。

• 可重現 —— demo 每次走同一條路，不會這次查三次、下次查五次。
• 可測試 —— 給定假數字就能斷言它應該走哪一條分支。
• 可搬移 —— YAML 的流程定義對得上 BPMN，之後搬去 UiPath Maestro 搬的是流程不是程式。
• 出錯知道怪誰 —— 走錯分支是流程設計的問題，答錯話是統整的問題，兩件事分得開。

保留的彈性是一格「AI 判斷」：只在資料不足時被問一次「還能查什麼」， 而且只能從已定義的能力裡選，步數上限仍然由調度層守著。它是流程裡的一個節點，不是流程本身。

具體的壞處，每一個都是真的發生過或會發生的：

• 使用者說「你好」→ 如果沒分類，就會去翻知識庫、跑檢索、叫統整，花掉一整輪的資源回一句寒暄。
• 使用者問「你用什麼模型」→ 這題真的發生過：沒有「系統說明」這一類的時候， 它被當成分析題丟進知識庫，撈出公司的 AI 使用政策文件來回答。 答案確定的東西不該每次重新生成。
• 使用者傳了一張訂單圖 → 那是業務操作，要走建單流程，跟查資料完全不同。

意圖這一層的產出其實是一句話：「接下來走哪一條 pipeline」。

三個選項的比較：

四類這個規模下，130 ms 已經夠快，而且是同一顆模型順手做的，不增加任何依賴。 規則版沒有丟掉，它留著當模型連不上時的備援（畫面上會顯示「規則（LLM 不可用）」）。

• 該是閒聊卻分成分析 → 多查一次、可能回查無資料。無害。
• 該是分析卻分成閒聊 → 模型會憑空回答，因為閒聊那條路不取證。這是要避免的。

所以 prompt 明寫「不確定時回分析」，程式解析不出模型回覆時也預設回分析。 分析是「有證據才回答」的安全方向。

這是一個很好用的答題模式：被問「XX 出錯會怎樣」時， 先講兩種錯的後果不對稱，再講設計往哪邊倒、為什麼。

入口這一層其實有兩條路，走哪條看請求長什麼形狀，不問任何模型：

好處有三個，都很實際：

• 不會分錯 —— 沒有機率就沒有錯誤率。
• 不花錢 —— 省一次模型呼叫，進度列上那一格是 0 ms。
• 不會被話術帶走 —— 使用者打「幫我建一張訂單」但沒附件， 模型會判成業務操作，但流程解析器找不到對應的建單流程，就當一般對話回、請他把文件傳上來。 光靠一句話不會真的去建單。

可以濃縮成一句：「能從請求本身確定的事，就不要交給模型猜。」 這跟「數字歸程式、語意歸模型」是同一個原則往入口延伸。

檔案裡只有三種步驟：

• tool —— 做事（查資料、檢索文件、統整、OCR、打 SAP、寫流水帳）
• gateway —— 分岔（一個數值比較，例如 hits == 0）
• render —— 結束，並告訴前端要畫成什麼（答案／表格／查無資料／草稿卡）

實體目前啟用 11 條：

基礎 3 條   knowledge_search  查文件（分析類選不到專屬流程時的預設）
            general_chat      閒聊
            about_system      問系統本身（固定答案，不進 RAG、不生成）

資料 1 條   data_query        所有結構化資料問題都走它

綜合 3 條   ontime_rate       達交率：先查數字 → 再取規範文件 → 一起統整
            orders_idle       閒置訂單
            split_delivery    分批交貨

建單 3 條   order_intake / order_extract / order_create

附件 1 條   attachment_chat   繼續問剛剛傳的那份文件

加一條情境＝寫一個 YAML、在設定檔加上代號、需要新能力就實作一個 tool。主幹一行都不用改。

1. 改門檻不用改程式 —— 「幾天算閒置」「達交率怎麼算」這種口徑， 改的是 YAML 裡的一個數字或知識庫裡的一份文件，不是 Java。
2. 訂門檻的人不是寫程式的人 —— 那是業務要拍板的事。 用 Adam 的比喻：像溫度計，讀數是程式讀的，幾度算發燒是人事先訂的。
3. 加情境不用動主幹 —— 十個情境就是十個檔，彼此不會互相影響。
4. 為了第二版 —— 十月要評估接 UiPath Maestro。 Maestro 取代的正好就是「照步驟跑、分岔、等人確認」這一塊。 流程寫在 YAML，搬過去搬的是流程定義；寫死在 Java 裡就得重寫。

不做 Dynamic 的理由一句話：客戶面前不能讓模型臨場發明查詢步驟。 不可預期、不可重現、出錯不知道怪誰。Fixed ＋ Generic ＋ 一次 AI 判斷已經涵蓋這階段的情境； Dynamic 是之後有明確需求再開的選項。

問句原文直接交給 text-to-SQL，選哪個資料模型、產什麼 SQL、在哪執行都是他們的事。 我們這邊分成兩條，只是把同一個判斷做兩次，而且兩邊會不一致。

這條設計已經兌現過一次：2026-09-15 AI team 把語意層整個換版 （原本 5 個彙總模型清空，改成直接對應 middledb 的 12 張原表）， AI-Brain 一行都不用改。因為它從來沒有假設過對方有哪幾張表。

歷史包袱也值得講：原本訂單那七題各有一條寫死 SQL 的 YAML，打本機的假資料庫。 那是 text-to-SQL 還沒交付之前的過渡，後來整個拔掉—— 留著會變成同一份業務口徑有兩套定義（我的 SQL 一套、他們的語意層一套）， 不一致的時候沒人知道該信哪個。

以達交率為例：數字（準時幾張、延遲幾張）來自 text-to-SQL， 但「達交怎麼算」——以計畫出貨日還是客戶要求日為準、缺實際出貨日的要不要進分母—— 寫在規範文件裡，要靠檢索取回來。

統整的時候：數字照查詢結果，口徑掛文件引用。 所以門檻改了改文件，不用改程式。

這三題（達交率、閒置訂單、分批交貨）也是最能展示這套架構價值的題目—— 單純的 text-to-SQL 工具答不出「怎麼算才算達交」。

1. 讀 YAML，從第一步開始跑
2. 呼叫 tool，把回傳結果變成具名變數（例如 hits、rows、failed）
3. 遇到 gateway 就拿那些變數做一次數值比較，決定跳到哪一步
4. 命中停止條件就停

模型只在它呼叫的 tool 裡面（llm tool、之後的 AI 判斷 tool）。 這樣切的好處是責任清楚：它是一個 Java 類別，不是一個模型， 所以它的行為完全可預測、可以寫單元測試、每次執行都一樣。

停止條件有三個，每一個都回明確訊息：

• 短路 —— gateway 判定 0 筆／查不到，直接跳到「查無資料」那一步
• 逾時 —— 預設 90 秒
• 步數上限 —— 預設 20 步

每一步還會開一個追蹤節點（span），所以在監控畫面上看得出來是卡在哪一步。

gateway 的條件長這樣，全部是 SQL 或檢索回來的數字在比大小：

hits == 0            檢索命中 0 片 → 回查無資料
failed == true       產不出 SQL → 回「這題沒辦法轉成查詢」
empty_result == true 查到但整列都是空的 → 回查無資料
due_orders == 0      該出貨的單有 0 張 → 短路

Adam 的說法：訂門檻是人做的（設計時一次），算數字是程式做的（每次執行）， 模型在這兩層都不出現。好處是可重現、可測試、快、而且之後可以直接對應到 Maestro 的流程變數。

實作上刻意做得很陽春：只支援單一比較（變數 運算子 值）， 不支援 and／or／算式。程式註解自己寫著「條件變複雜再換運算式引擎」—— 先做剛好夠用的。

三個不做的事，每一個都是刻意的：

• 不重試打爆對方 —— 對方的併發上限是 2，重試只會讓事情更糟
• 不把半成品當答案 —— 沒查完就不要統整
• 不吞掉錯誤 —— 錯誤訊息（例如模型回的 HTTP 400 內容）會帶到前端截 300 字

雛形有一題「模擬錯誤」就是在演這個：錯誤卡、狀態列寫「處理中斷」而不是「已完成」。

證據池就是這一輪所有取回來的東西的集合，每一片都帶著： 編號、種類（查詢結果／文件碎片）、標題、原文、來源、日期、相關度分數。

三個它必須存在的理由：

• 混來源 —— 達交率那題同時有 2 次 SQL 結果與 5 片文件碎片， 它們要一起進統整，數字照 SQL、口徑照文件。沒有一個共同的池子，這件事做不了。
• 編號要穩定 —— 答案裡的 [1] 必須永遠指向同一片。 編號是進池子時就發的，模型只能引用已存在的編號。
• 稽核 —— 這一輪的依據整包留在紀錄裡，事後可以回放、可以算「撈到但沒用上的比例」。

這一點常被誤會成「引用只能指文件」。實際上每次查完資料，那張表會被包成一片證據， 帶著標題、實際跑的 SQL、資料列、筆數、來源（text-to-SQL）與日期， 然後跟文件碎片排在同一個編號序列裡。

所以達交率那種題目的答案可以長這樣：

整體交貨準時率是 88.6%（374 / 422）⋯⋯ [1]     ← [1] 是查詢結果
這是相對計畫出貨日的準時率，跟客戶要求日
是兩個口徑，不能互相代替 [2]                   ← [2] 是規範文件

數字照查詢結果、口徑掛文件引用——同一段話裡兩種來源各自掛得回去。 這正是「綜合判斷」那幾條流程的價值，也是單純的 text-to-SQL 工具做不到的事。

1. 只給它證據 —— 統整的 prompt 裡只有問題、條件、證據，沒有資料庫連線、沒有搜尋工具。
2. 要求每句標編號 —— 沒有依據的句子不要寫；範圍外的編號會被程式過濾掉。
3. 0 筆根本不呼叫模型 —— 查不到就短路回「查無資料」。 模型沒有被叫醒，所以它連編的機會都沒有。

實測可以當例子講：問「採購政策對供應商調價怎麼規定」， 撈回來的片段裡沒有直接規定，它的回答是「片段中沒有提到具體規定」， 然後列出相關的兩點並標上 [1]、[4]。這正是要的行為。

還有一條容易被忽略的：數字誰算。統整規則明寫「不要自己計算」， 毛利率、下降幅度都是查出來的欄位，模型只負責把它寫成句子。 連小數的格式都處理過——690801320.97 若用程式預設的方式轉成文字會變成 6.9080132097E8，模型就照抄進答案裡了，所以有一段程式專門把它轉回十進位。

1. 混不了 —— 複合分析要把查詢結果與文件碎片放在一起統整， 檢索服務單獨統整時看不到數字那一半。
2. 掛不回去 —— 引用要能點回原文；已經統整過的段落沒辦法對應到某一片。
3. 品質責任 —— 「只看證據、標編號、不算數字」這套規則是我們的品質責任， 放在我們這邊才管得住。

順帶回答一個常見誤解：撈五片不是為了丟進模型五片。 檢索是漏斗——幾千片初篩到 30，重排取 5，進模型的永遠只有 top 5。 多要幾片是為了之後接重排器有東西可排。

原本是有一顆的：本機 PostgreSQL、140 張假訂單、十題的 SQL 寫在各自的 YAML 裡。 後來整個拔掉，連資料庫相依一起。

拔乾淨的理由寫得很清楚：「達交」怎麼算、「前十大」依什麼排， 我的 SQL 一份、他們的語意層一份，遲早不一致，而且不一致的時候沒人知道該信哪個。

有一個例外，而且它正好證明了原則：order_ledger 建單流水帳。 Adam 的答法值得原樣記起來——

好在哪：分析查詢打在鏡像上，不影響生產系統； 模型產生的 SQL 再糟也碰不到 S/4——它根本連不到。

代價要誠實講。原本的評估是走 SAP 的 CDS view（一種官方的資料視圖）， 它會免費幫你解掉四個地雷；但現在的路徑是「SAP 匯出 CSV → 灌進 PostgreSQL」，中間沒有 CDS view， 所以那四件事都得自己補：

這也是為什麼前處理要把「訂單 104705」補成十位數——就是在補這個。

• 不用一般請求回應 —— 統整要等模型逐字生成，整包回會讓使用者盯著空白轉圈。
• 不用 WebSocket —— 雙向通道在這裡用不到：使用者送出之後到答案寫完， 中間沒有東西要往上送。SSE 走的是普通 HTTP，不用額外的連線升級。

SSE 還順帶解決了另一件事：因為使用者已經看得到進度，後端呼叫 text-to-SQL 就可以同步等， 不需要做成非同步再輪詢。等 13 秒但一路看得到進度，跟等 13 秒看著空白，是兩種體驗。

它的限制也直接決定了建單的設計：SSE 是單向的，沒辦法中途停下來等人回答。 所以建單拆成三次獨立請求，見 §05。

sessionId 是前端產生的，使用者重新整理就換一顆新的。 所以後端重啟清掉上下文，不會比使用者按 F5 更嚴重。

後端每個 session 只留最近 20 則，追問時帶最近四輪給模型。 畫面上看得到的對話紀錄存在瀏覽器本機，不在後端。

程式註解自己寫著：「記憶體版；要跨重啟或多台才需要外部儲存」—— 這是明確標示的簡化，不是疏忽。要上正式環境時換掉那一個類別即可。

因為系統裡有三段東西是中文的，而且改不動：

• 知識庫文件是中文
• 別名表、時間詞（「上個月」「本季」）是中文規則
• 語意層的指標名稱是中文

英文句子直接送進去，這三段全部失效。 所以做法是在邊界翻一次：非中文問句先由模型翻成中文（順便補前文，同一通呼叫）， 中間所有規則與流程一行不改，只有進度文字、固定文案與最後統整換語言。

代價寫得很誠實：非中文問句多約 300 ms，中文問句零成本。 比起讓每一段各自支援三種語言，這樣便宜也不會漏。

判斷語言不用模型：有假名一定是日文；有漢字看介面語言；只剩拉丁字母就是英文； 什麼都沒有（只打一個單號）就跟介面走。

Tom 的責任邊界主張值得記：應用層管 WHAT NEXT／WHEN STOP，能力服務管 HOW TO EXECUTE。 「AI 判斷」那一格被切出去給 AI team，正是照這條線切的。

Maestro 是商業流程編排工具，它取代的正好是 Java 那條「照步驟跑、分岔、等人確認」。 對應關係很乾淨：

• YAML 的 gateway 門檻 → Maestro 的流程變數
• 「等人確認」→ Action Center 的人工節點
• 每個 tool → Maestro 呼叫的 API 節點

右邊每一格能力 API 都不用動，前端、知識庫、檢索契約、統整、資料層全部沿用。

為了那條縫，Java 端才刻意不把流程寫死在程式裡。 這是「為什麼用 YAML」的第四個理由，也是最現實的那個。

算總數：一題純文件問答＝我方 2 次（意圖＋統整）。 一題資料問答＝我方 2 次＋對方 1～3 次。

建單那條線另外還有三個，而且其中一個不是 Qwen：

• 看圖判讀 —— Qwen 多模態，判斷「這是不是訂單」
• OCR —— PaddleOCR-VL，不是 Qwen，是同事的另一個服務（192.168.170.28）
• 標籤對應 —— Qwen，但只有規則認不得的標籤才問，而且用選單鎖答案、看不到值

目前這幾種用法的需求其實都在同一顆 27B 模型的能力範圍內： 做單選題、補一句話、翻譯、寫一段有引用的文字、看一張圖說是不是訂單。 沒有一項需要專門的模型。

真正省下來的是營運成本：一個端點、一套監控、一張 GPU。 而且介面是 OpenAI 相容的，之後真的要換或要加一顆，改設定檔兩行就好。

唯二用了別的技術的地方，都是因為那件事 Qwen 做不好或不該做： OCR（認字是專門的活）與檢索（那是排序不是生成）。

• 跑在哪：192.168.170.31:7100，用 vLLM 這套推論伺服器架起來， 對外提供 OpenAI 相容的介面。
• 量化：NVFP4（一種把模型壓小、讓它塞得進顯卡記憶體並跑更快的技術，代價是精度略降）。
• 可以吃多長：context 80k（約八萬 token 的上下文）。
• 誰維護：AI team（Ian 那邊），不是 Adam。

選它的實際理由：開源可自架（資料不出公司）、中英日都行、有多模態版本可以看圖。

「OpenAI 相容」只是指介面格式跟 OpenAI 的 API 長得一樣（方便換）， 不是指會連到 OpenAI。這個詞很容易被誤會，講的時候要補一句。

因為介面是 OpenAI 相容的，任何 vLLM、Ollama 或雲端 API 都接得上。 統整用的那份規則（prompt）也是中性的，沒有綁 Qwen 的特性。

唯一要注意的是看圖那一段：換的模型要支援多模態， 否則會退回「先 OCR 成文字再讓模型讀」的路徑——程式已經寫好這個退路， vLLM 的圖片配額被關掉時會自動走。

關掉思考模式後，統整一次約幾百 token；一天幾百次問答對一顆 27B 模型是輕載。

要盯的地方要講出來：text-to-SQL 跟統整共用同一張顯卡。 多人同時問的時候會排隊，這已經提醒過 AI team。 緩解手段是關思考模式（省六成 token）與 SSE（讓使用者看得到進度，等待比較不難受）。

0 上傳     POST /api/attachments → 拿到一個附件編號（存記憶體）

1 判讀     order_intake    模型看圖 → 是不是訂單 → 問「要用這份文件建立訂單嗎」
   ↓ 人按「要」（這一輪請求已經結束了，按鈕送出的是新的一次請求）
2 辨識     order_extract   OCR 讀成「標籤：值」清單 → 規則對進欄位 → 草稿卡
   ↓ 人核對／修改（草稿整包在前端）
3 建單     order_create    先佇一列 → 打 SAP 拿單號 → 補回流水帳 → 顯示單號

「等人確認」不是後端的一個狀態，是這一輪回出一個問題，下一次請求把答案帶回來。 所以使用者關掉分頁、重整、隔天再來，伺服器這邊沒有半張單要清。

每一次請求都是完整的一輪：一樣先走前處理、再判意圖，然後才進建單那一段。 進度列上三次都看得到「理解問題 → 判斷意圖」，只是這兩步在建單時幾乎不花錢—— 意圖是看請求形狀直接決定的，0 ms，沒問模型。

換來的是三件事：

• 伺服器上沒有半張單 —— 沒有 pending 狀態要存、要清、要設過期。
• 斷了不會壞 —— 「中間斷掉怎麼辦」的答案是「沒有中間可以斷」，最差就是重來一次。
• 重整不會掉 —— 草稿整包在前端，改完整包送回。

真正的代價是每段都要重跑一次前置：按「要建單」那一步會再 OCR 一次。 這件事程式裡有處理——每則訊息記著當初送出的參數， 所以按「重新產生」是「再辨識一次」而不是變成閒聊； 已經建完的那則按下去，因為冪等，拿回的是同一個單號。

「我們刻意不給信心度分數。因為值是 OCR 原文照抄、欄位對應是規則或模型二選一， 中間沒有一個可以量的連續量。給一個數字只會讓人以為它是量出來的，反而不去檢查。」

「取而代之的是可追溯：每一格都標它來自文件上哪個標籤、會寫到 SAP 哪個欄位。 對錯一眼看得出來，而且是人在確認，不是機器打分數。」

舊版曾經有過：讓模型自己回報信心度，前端拿 0.85 當門檻標黃。 拿掉的理由是——那個數字是模型自己說的，不是量出來的。 模型說 0.94 不代表它有 94% 的機率是對的，同一份文件跑兩次還可能給不同分數。 給一個看起來精確的假數字，比不給更危險。

• 判讀：這份文件是不是要建訂單（回一個是非題＋一段說明）
• 對標籤：這個沒看過的標籤是哪個欄位——只能從欄位清單裡選，而且看不到值

值永遠是 OCR 原文照抄。這句話可以直接拿來講： 「模型負責理解，程式負責搬運。值從頭到尾沒有經過模型的手。」

為什麼要這樣改？因為舊做法（把 OCR 整包丟給模型填成 JSON）實測出三個問題： 長文件輸出會被截斷、鎖了結構之後模型會在空白處打轉直到上限、 而且模型會順手改值——把數量印成 $120。

每張草稿在辨識那一步會拿到一個唯一編號。要建單就得先用這個編號在流水帳表插入一列， 而那個欄位是資料庫層級的唯一鍵——插得進去代表這張草稿是你的，插不進去代表別人先拿走了。

• 已經建過 → 直接回原本的單號，不再打 SAP
• 兩個請求同時進來 → 插入失敗的那個回「這份訂單正在建立中，請稍候」，絕不打第二次

順序也是刻意的：先佇一列，再去打 SAP。 萬一 SAP 成功但寫紀錄失敗，至少看得到有人試過這一單， 不會變成「SAP 有單、我們完全沒紀錄」的孤兒。

兩層原因：

1. text-to-SQL 的語意層只掛了那 12 張銷售表，流水帳不在裡面。
2. 就算真的寫進 SAP，middledb 是鏡像、整批重建，不是即時同步。

中間缺的那一段（建單後要回寫中繼資料庫哪幾張表、哪些欄位）連規格都還沒定， 歸 Tom／Brandon。

建議的講法：「辨識、判讀、欄位對應、流水帳都是真的在跑； SAP 建單那一步目前發模擬單號，真的連線程式已經寫好，等帳密與主檔對照就能切過去。」

「已經寫好等切換」本身是加分，不用心虛。技術細節（如果被追問）： 走 S/4HANA 的標準銷售訂單 API、憑證釘選、只跑 TLS 1.2、 切換只要改一個設定值加上帳密。

2026-09-15 對真機（192.168.170.23）實跑的結論： 11 張單全部建成，4 張金額錯，其中一張正好是兩倍（OCR 把品項區塊吐了兩次）。 而且沿路每一步的狀態都是正常的——每個欄位都合法、必填全過、SAP 也收下並回了單號。

這催生了一道新的檢查，叫對帳守衛：建完單之後， 拿單據自己印的合計對SAP 用自己的定價算出來的淨額， 差超過 0.01 就把警告接在完成訊息後面。

為什麼這道檢查非有不可：它擋的是欄位檢查看不到的一整類錯—— 品項多讀、少讀、重複讀。每個欄位都正常，只有總額對不起來。

為什麼做成事後警告而不是事前攔截：因為價格是 SAP 算的， 在我們這邊自己算價等於養第二套定價邏輯。 模擬模式沒有定價引擎所以回空值——空值是「沒得對」，不是「對過了」。

這套系統從頭到尾的設計主張就是這句話：它不要求你信任它，它把依據攤開讓你自己驗。 所以「怎麼知道對不對」不是一個尷尬的問題，是這個產品的賣點。

四層驗法，由粗到細

照這個順序看，越前面越容易錯、也越容易看出來：

系統已經替你擋掉的錯

• 查不到不會硬掰 —— 0 筆直接短路回「查無資料」，連模型都不叫醒，所以沒有編的機會。
• 「整列都是空的」也算查無資料 —— 擋的是「回一列 0 然後很有自信地說本月 0 張」這種 最危險的假答案（實測真的發生過）。
• 數字不給模型算 —— 統整的規則明寫不准自己計算，數字只能照查詢結果原文引用。
• 引用編號是程式給的 —— 模型引用不存在的編號會被過濾掉，不會出現掛不回去的來源。

系統擋不掉、只能靠人的錯

被問到時的三段式答法

還沒做、但被追問要說得出來的

「你們有量化的驗收標準嗎？」——目前沒有，但機制已經備好了。 每一次請求的問題、條件、SQL、撈到的碎片、答案、引用全部留成紀錄， 所以只要有一份「標準答案題庫」，就能回放算出：SQL 對不對、引用有沒有掛回、 答案有沒有超出證據。這是請求紀錄存在的主要理由，不只是除錯。

要讓這件事成立，缺的不是工程，是業務端先把口徑定義下來—— 沒有定義就沒有正確答案，沒有正確答案就沒有準確率可以算。

對方（AI team）自己在介面規格裡特別註明「這句要照實講給客戶聽，不能當成查得到就是對的」。

接下來這句才是重點：「所以畫面上一定看得到實際執行的 SQL 與系統理解的條件。 判斷對不對的責任在看的人身上，系統的責任是把依據攤開。」

可以再補一個技術性的緩解：用訂單編號精確查一筆這種簡單的條件查詢相對穩 （實測一次就對、8 秒）；複雜的聚合與多表關聯才是風險區。

1. 條件攤開 —— 系統理解到的條件（期間、客戶、指標）直接顯示。 錯最多的是條件理解錯，這一層擋得住大部分。
2. SQL 攤開 —— 懂的人可以直接驗。而且模型重修過的會自動展開。
3. 不確定就不說 —— 查不到說查不到；整列都空的算查無資料； 統整不准自己算數字。

擋不住的那一類也要講得出來：SQL 語法正確、條件也對，但業務口徑理解錯 （例如「前十大客戶」依金額還是依張數）。這一類只能靠把口徑寫進規範文件， 讓系統取文件來回答，而不是讓模型自己決定——那正是「綜合判斷」那三條流程在做的事。

• 哪一套：SAP Best Practices 模型公司示範資料，美國銷售組織 1710、幣別 USD、腳踏車系列產品。
• 期間：2018-10-29 ～ 2024-11-15。
• 知識庫那幾份文件：自己寫的示範文件，虛構的公司，不是任何一家公司的正式規範。

為什麼這件事不能含糊：如果讓人以為那是自家報表，任何一個數字被拿去引用都是問題。 而且真實資料進來之後，數字一定會變，先講清楚就不會有落差。

這不是壞掉，是兩件事撞在一起：時間詞換算用的是真實的今天， 而資料是 2018～2024 的歷史快照。

反過來也成立，而且對 demo 有利：新建的單如果是當天日期，問「這個月」只會查到那幾張， 舊資料一張都不出現——畫面很乾淨。要知道那是這個機制造成的，不是系統特別聰明。

雛形這邊的處理方式不同：預設「全期間」而不是「本月」，正是為了避開這個問題。

時序是這樣：

• 之前：對方的語意層裡只有總帳、帳齡、預實差異，沒有訂單事實表，所以訂單題一律查無資料。 這個狀態被寫進了好幾份文件。
• 2026-09-15：對方換版，把 5 個彙總模型清空，改成直接對應 middledb 的 12 張銷售表 （vbak、vbap、kna1、likp、lips…）。 實測「訂單 0000004826 的客戶是誰」一次就對，8 秒回。

那一頁在實體程式裡藏著（左上標誌兩秒內點五下解鎖）， Adam 把「每一格怎麼達成、被問到時怎麼答」都寫在那裡，所以它很容易被當成權威答案。

被問到的答法：「那一頁是開發方的內部說明，有幾節還沒跟上最新的程式， 已經整理好要回報給他們了。」然後照這份文件講實際的做法。 不要當場改口說雛形是對的——雛形演的是實體，不是另一套設計。

開發方在 2026-09-12 自己做過一份資安健檢，把發現分成高／中／低。 「有一份寫得出來的清單」本身就是答案的一部分——這是「知道要做但還沒做」，不是「沒想到」。

高：上正式環境前一定要處理

開發方自己排的順序是 H1 先做——因為身分驗證一解，下面好幾條的風險同時降下來。

中：現在可接受，但要知道

• SQL 只剩對方一層防護 —— 見前面 SQL 那題。
• 知識庫文件可以做提示注入 —— 文件原文會進統整的 prompt， 有人上傳一份寫著「忽略以上指示」的文件就有機會影響答案。 配上 H1（任何人都能上傳）風險放大。 現有的緩解不是為了防注入設計的但有幫助：只能引用片段、每句掛編號、0 筆短路不進模型。
• 沒有速率限制 —— 而 text-to-SQL 的併發上限只有 2。 一個人開個迴圈就能讓整個服務對所有人不可用。
• 業務內容落在三個地方、都沒有保留政策 —— 後端日誌檔（輪替上限 500 MB）、Elasticsearch（沒有自動刪除，無限成長）、 瀏覽器本機儲存（對話明文，共用電腦看得到）。

低／已經做對的——被問資安時要主動講這些

已知還沒做的：沒有病毒掃描；沒有擁有者——拿到附件編號的人就能用它建單。 後者要等身分驗證一起解，不是這一塊能補的。

被問到時的答法：「全部在內網，沒有一段出公司。 但誠實講，文件會經過兩台我們不擁有的內網服務（模型與 OCR）， 它們的日誌政策要跟那兩個團隊確認——這一條已經寫在資安清單上了。」

1. text-to-SQL 對真實資料的正確率 —— 靠平坦的事實表與語意層的定義壓低風險。
2. GPU 排隊造成的延遲 —— text-to-SQL 與統整共用同一張卡。 靠關思考模式與逐步進度緩解。
3. 名詞沒有定義 —— 「這個月」「前十大」「達交」各人講的不一樣。 沒有定義就沒有正確答案可以驗收。這是現在最需要業務端拍板的東西， 而且它不是工程問題，錢和人都解決不了。

第三點很值得主動講，因為它把球丟回給業務方，而且是真話。

直接用它，四件事會斷掉：

一句話版本：「WrenAI 回答『資料是什麼』，AI-Brain 回答『這個問題該怎麼被回答』。」

1. 資料不能出去。這是前提不是偏好。這套系統的模型、資料庫、OCR 全部在內網網段， 沒有任何一段送到外部雲端。
2. 它回答不了公司內部的數字。它不知道 VBAK 是什麼、 不知道你們的「達交」怎麼定義、也連不到那顆資料庫。要接上去， 你要做的正好就是這套系統在做的事——語意層、取證、流程。
3. 它不會說「我查不到」。沒有依據的時候它會寫得很流暢。 這套系統的核心主張是反過來的：查不到就短路，連模型都不叫醒。

可以再補一句軟的：「通用助理解決的是『我不會寫』；這套解決的是『我不知道公司的數字』。 兩者不衝突，但後者只能自己做。」

• 跨到 SAP 以外 —— 公司的規範文件、SOP、外部新聞不在 SAP 裡。 這套系統的價值有一半在「數字＋規範一起回答」。
• 口徑是你們自己的 —— 「達交」「前十大」「閒置」怎麼算， 沒有任何外部產品知道，只能自己定義並維護。
• 現在的限制 —— 老闆的限制是不直連 S/4，資料是匯出的鏡像。 在這個前提下，SAP 原廠的方案本來就用不上。

更務實的講法：這套架構的每一格都是可替換的。 哪天原廠方案成熟了，它可以變成右邊泳道的一格能力， 左邊的流程、稽核、知識庫全部沿用。賭的不是哪個模型贏，是流程要握在自己手上。

兩者不是替代關係：固定要看的指標就該做成報表，快又準，不需要 AI。

這套系統的位置是報表的縫隙：

• 沒人預先做過的切法 —— 「2022-02 那批延遲是怎麼回事」不會有現成報表。
• 要跨資料與文件 —— 數字在資料庫、口徑在 SOP，報表工具跨不過去。
• 問了才知道要問什麼 —— 追問是連續的，報表是一次性的。

而且這套系統不取代報表的權威性——它每個答案都附 SQL 與引用， 正是因為它知道自己不是權威報表。

兩條線的成本結構完全不同：

所以如果要分階段，先做建單是合理的——它的效益最好量化。 但要講清楚：共用的那一層（意圖、流程、調度、稽核、前端）兩條線都要， 所以先做一條省下來的不是一半，大概是三分之一。

這一題答錯的代價很高，因為它同時碰到「資安」與「期待管理」。

• 模型是固定的。公司的資料只在回答那一瞬間被放進 prompt 裡， 回答完就沒了，不會進到模型的參數裡。
• 對話也不留。後端的對話紀錄在記憶體，重啟就沒了； 留下來的請求紀錄是給監控用的，不會回頭餵給模型。

那它怎麼變好？靠人改三個地方：語意層的定義、知識庫的文件、流程 YAML 的門檻。 這反而是優點——改哪裡、誰改的、什麼時候改的，全部說得出來， 不像微調完之後沒人知道它為什麼改變了。

能這樣分，本身就是這個架構的賣點。如果整套是一顆模型直接回答， 答錯了只能說「模型不夠好」，沒有第二句可以講。

而且每一次請求的完整經過都留著（問題、條件、SQL、撈到哪幾片、答案、引用）， 所以要判斷是哪一層錯，是查得出來的，不用猜。

一列裡有：問題、抽出的條件、意圖、走哪條流程、每一步耗時、 實際執行的 SQL、撈到的碎片與分數、每一片有沒有被引用、答案、引用編號、狀態。

可以直接查出來的幾種問題：

答案沒掛任何引用          → 模型在自由發揮
回了查無資料的比例        → 覆蓋率不足
某一步超過 10 秒          → 哪個服務在拖
分類方式是「規則（LLM 不可用）」 → 那段時間模型連不上
撈到卻沒被引用的比例      → 檢索品質的訊號

更進一步的用法（還沒做）：拿一份情境題庫定期回放， 算 SQL 對不對、引用有沒有掛回、答案有沒有超出證據。 請求紀錄存在的主要理由就是這個，不只是除錯。

所以「同時問數字的人」超過兩個就會開始排隊。 AI-Brain 這側因此刻意不做任何並行呼叫——多打只會讓對方更慢。

另一個共用瓶頸是那張 GPU：text-to-SQL 產 SQL 與統整寫答案共用它。

誠實的講法：「目前是 demo 規模，沒有做過壓力測試。 瓶頸在哪我們知道（text-to-SQL 併發 2、GPU 共用），要放大是加資源的問題，不是改架構。」

要放大之前已知還要補的：請求紀錄轉送目前沒有上限保護（流量大時會往記憶體堆）， 這一點程式註解自己寫著「目前靠流量低不會發生，不是設計保證」。

「整批重建」的意思是：重建時會先刪掉那些鏡像表再重灌， 所以任何直接寫進鏡像表的資料，重建時會一起消失。

頻率目前沒有定案，這是要跟資料那條線（Tom／Joey）確認的事。 被問到就照講「目前是匯出的快照，更新頻率還在定」，不要編一個數字。

有一件事是確定的、而且值得講：建單流水帳不受重建影響， 因為重建只刪它自己的表名。這個保證是開發方明確確認過的。

不用改的：意圖、流程、調度、證據池、統整、前端、知識庫、監控。

要換的：

• 資料來源 —— text-to-SQL 指向另一顆資料庫。
• 語意層 —— 要重新定義那套系統的表與指標。這是最大的工項。
• 建單 —— 換一個 SAP 連線程式的實作，流程不用動。

所以答案是：「架構本身不綁 SAP，但語意層必須重做， 而那正是這類專案最花時間的地方。不要以為換個資料庫就搬得過去。」

三件事分開講：

1. 路已經通了 —— 從提問到答案、從上傳圖片到 SAP 建單，整條路都跑得起來， 而且對真機建過單。
2. 還缺的是資料與定義 —— 語意層要把該有的表放進去、 業務口徑（達交、閒置、前十大）要有人拍板、規範文件要換成真的。
3. 還缺的是正式化 —— 權限、保存期限、壓力測試、對話紀錄的持久化。 每一項都已經列出來了，不是還沒想到。

最該強調的那句：「沒有定義就沒有正確答案可以驗收。」 這不是工程能解決的，加人加錢都沒用。

• 應用層（流程、意圖、調度、前端、知識庫）→ 開發方（Adam）
• 模型端點、text-to-SQL、語意層、檢索服務 → AI team（Ian）
• SAP 介接、鏡像資料 → Tom／Brandon
• 業務口徑與情境定義 → 業務端，沒有人可以代打

怎麼知道是誰的問題？靠請求編號查那一輪的完整經過： 走錯流程是應用層、SQL 查錯是語意層、口徑錯是業務定義。 這套系統的稽核設計，同時也是一套除錯的分工表。

• 手機 —— 前端是響應式的，窄螢幕會自動調整（側欄收成窄軌）。沒有專門的 App。
• 知識庫 —— 目前單檔上限 2 MB，支援 .md 與 .txt，PDF 與 Word 交給檢索服務那邊做。 現在是幾百片的規模，線性掃就夠；上千份時會換成正式的檢索服務。 目前存在記憶體，重啟會重載預設那 15 份——這是明確標示的簡化。
• 匯出 —— 目前沒有做。表格可以排序、SQL 可以展開複製，但沒有「下載 Excel」。 這是可以加的功能，不是架構限制。

可以當場開的：實體程式的 /internals 運作說明頁（左上標誌兩秒內點五下）。 但先讀過 §06 那張表——那一頁有五處停在舊版本， 被問到要能說明哪幾處是舊的。

建議不要主動開。它是內部技術文件，含「還沒做的」清單，對外場合通常不演。

不需要裝的：SAP。建單是打對方既有的 SAP API，分析是查鏡像， 兩者都不需要在這台機器上裝 SAP。

1. 知識庫與對話紀錄在記憶體，重啟會清。 開機會自動重載那 15 份示範文件，所以「開箱能問」沒問題； 但客戶自己上傳的文件重開機就沒了。要落地必須先接上正式的檢索服務或改成持久化。
2. 雛形需要公有 CDN。函式庫與字型走外網， 對方內網若擋 CDN 會開出一片空白。要交檔出去之前一定要先確認， 或把函式庫抓成本機檔。（實體程式是自己打包的，沒有這個問題。）
3. SAP 憑證會過期。目前釘選的那張憑證有效期到 2026-11-22 （讀憑證本體確認，不是只看設定檔的註解）。
   但要講準：那是 SAP CAL 示範機的自簽憑證 （CN=vhcals4hci.dummy.nodomain、簽發者 cal.dummy.nodomain）， 不是正式機。所以正確的說法是 「切到客戶自己的 SAP 時，憑證本來就會換掉」—— 到期日是示範環境的限制，不是產品缺陷。 真正要排進維護計畫的是「換憑證這件事有沒有人負責、怎麼換」。
4. 沒有權限控管。三層都沒有（見 §06）。 自己人 demo 可以，交給客戶天天用之前必須先做。

已經完成的：

• 介面三語（中／英／日），回答語言跟問句走不跟介面。
• 語言判斷不用模型：有假名→日文；有漢字→看介面；只剩拉丁字母→英文。
• 日文問句會先翻成中文再走流程，所以中間所有規則一行都不用改。
• 進度文字、固定文案、統整的語言都會跟著換。

還沒完成、而且是真正的工：

一句話版本：「翻譯不是問題，定義才是。介面與回答的語言已經做好了， 真正要花時間的是把他們的資料與口徑放進語意層——而那件事需要他們的人一起做。」

建議的答法：

為什麼不要給數字：這件事的工期不由我方單方面決定。 現場給一個數字，之後對方投入不如預期，超期會被算在我們頭上。

如果一定要給個量級，可以拆成三段講，讓對方自己感覺得到比例：

• 裝機與跑通 —— 最短的一段。路已經通了，對真機建過單。
• 語意層與知識庫 —— 最長的一段，而且跟對方投入成正比。
• 正式化（權限、保存期限、壓力測試、持久化）—— 已經列得出清單，不是未知數。

把第二段點名成瓶頸，而且說明它為什麼是雙方共同的工， 比給一個會被拿來對帳的數字安全得多——而且這是真話。

已經有的：每一次請求留一列完整紀錄（問題、條件、SQL、撈到什麼、答案、引用、耗時、狀態）， 而且畫面上有可複製的請求編號。對方回報問題時只要給那串編號，就查得到那一次的完整經過—— 這是遠端支援最實際的基礎。

還沒決定的（不要自己承諾）：

• 紀錄要不要回傳、回傳到哪（目前含問題與答案的業務內容，要送出內網之前有兩個開關要先關掉）
• 保存期限與存取權限
• 更新機制：模型、語意層、知識庫各自怎麼更新
• SAP 憑證到期（2026-11-22）的更換流程

這幾條列出來本身就是答案的一部分——「知道要做但還沒決定」跟「沒想到」是兩件事， 現場講得出清單，對方就知道是前者。