跳至主要内容
Knowledge 累積企業自己的查詢慣例：Question-SQL pairs 教 Mimir 組織慣用的 SQL 寫法，Instructions 規範答題時要遵守的定義與格式，兩者都綁在特定語意模型底下。

Knowledge 知識設定

同一個問題可以有很多種 SQL 寫法都查得出答案，但每間企業對指標的定義、慣用的欄位、期望的呈現方式都不一樣。Knowledge 就是把這些慣例存下來，讓 Mimir 的產出貼近實際期待，而不是每次都要在對話裡重新交代。

頂端的 Knowledge 分頁進入後，左側分成 Question-SQL pairs 與 Instructions 兩個區塊，左上角的 Back to project 回到專案畫面。

知識綁在語意模型底下

Knowledge 的內容屬於當前選定的那一份語意模型，不是整個 Project 共用。在 POS 門市語意模型底下建立的知識，切到 CRM 會員語意模型時看不到，畫面會顯示沒有資料。要新增或查看知識前，先確認頂端選的是正確的語意模型。

Question-SQL pairs：教 Mimir 你們怎麼寫 SQL​

一組 pair 就是一個問題加上你們認可的 SQL 寫法。存下來之後，Mimir 遇到類似的問題會參照這個寫法，而不是每次自己重新推導。

以零售專案的門市庫存為例，store_inventory 這張表同時有 store_id / store_name 與 sku / sku_name 兩組欄位，也同時有 on_hand 與 safety_stock。缺口要用哪兩個欄位相減、門市要顯示代號還是名稱，全都是團隊約定而不是資料本身能決定的事。把約定寫成一組 pair：

Question

哪些門市的聯名鈦保溫瓶低於安全庫存？

SQL statement

SELECT store_name, sku_name, on_hand, safety_stock, safety_stock - on_hand AS shortage
FROM retail_pos.store_inventory
WHERE sku = 'SKU-8801' AND on_hand < safety_stock
ORDER BY shortage DESC

這組 pair 一次交代了三件事：缺口的算法是安全庫存減現有庫存、篩選條件是現有量低於安全庫存、輸出用 store_name 與 sku_name 而不是代號。

已儲存的 Question-SQL pair 清單：問題、SQL 與建立時間

新增時點右上角的 Add question-SQL pair。Question 欄位填問題本身，SQL statement 是一個支援語法高亮的編輯器。填完可以先按 Preview data 實際跑一次確認查得出東西，再按 Submit 存下來。

新增 Question-SQL pair：Question 欄位與 SQL 編輯器

清單每一列的選單提供 Edit 與 Delete，刪除會再確認一次並提醒無法復原。

清單列的 Edit 與 Delete 選單

Instructions：規範答案怎麼給​

Instruction 存的是規則而不是查詢範例，適合數字沒錯但呈現方式不對的情況。延續上面的例子，把同一組約定寫成一條通則，就不必為每個相關問題都準備一組 SQL：

回答門市庫存問題時，缺口一律定義為安全庫存減現有庫存，並以件為單位；
門市一律顯示 store_name 而不是 store_id，商品一律顯示 sku_name 而不是 sku。

已儲存的 Instruction：規則內容、生效範圍與建立時間

新增時點 Add an instruction，表單有兩個部分：

  • Apply instruction to：決定生效範圍。選 Global 代表套用到所有問題，選 Matched to relevant questions 則只在偵測到相似問題時才生效。清單的 Matching questions 欄位顯示的就是這個設定，上面那條規則存成 Global，所以顯示 Global (all questions)。
  • Instruction details：規則內容本身，上限 3000 字，欄位提示是輸入一條 Mimir 產生 SQL 時應該遵守的規則。

Add an instruction 表單：Global 與 Matched 兩種生效範圍，以及規則內容欄位

範圍的選擇有實際差別。像上面那條欄位顯示慣例，適合設成 Global，因為任何門市庫存問題都該遵守；如果是只在特定情境成立的規則，例如某個活動期間的特殊算法，設成 Matched 才不會污染其他問題的答案。

該用哪一個​

兩者影響的階段不同：Question-SQL pairs 影響查詢怎麼寫，Instructions 影響答案怎麼給。

  • 某個指標一直算錯、或每次都查錯資料表，補 Question-SQL pairs，直接給它正確的寫法。
  • 數字對但呈現不合期待，例如一直顯示代號而不是名稱、單位不一致、少了你們慣用的欄位，補 Instructions。
  • 一個約定同時涉及算法與呈現時兩者都補：pair 負責把這個問題查對，instruction 負責讓其他相關問題也遵守同樣的規則。