案例18｜先查資料庫與快取，再決定是否呼叫 LLM

一、案例定位

本案例處理大型語言模型（Large Language Model, LLM）推論的分層策略：不是每個請求都直接交給 LLM，而是先判斷是否可由快取、資料庫、應用程式介面或既有函式處理。

本案例依原書第 8 章的最佳實務、範例或情境重組，並非原書正式案例研究。

二、學習目標

理解分層推論與條件式路由。
辨識可繞過 LLM 的請求。
理解 RPM 與 TPM 門檻的用途。

三、案例情境

原書指出 LLM 計算成本高且會帶來延遲與基礎設施負擔，因此應先執行資料庫搜尋與快取檢索，再於真正需要語言理解或生成時呼叫 LLM。可在 LLM 前加入過濾層，以關鍵字、正規表示式（Regular Expression, Regex）、中繼資料標記或分類模型把請求路由到資料庫、應用程式介面（Application Programming Interface, API）或快取邏輯。若 Redis 快取已有有效向量結果、答案可直接從 Snowflake 等結構化資料庫取得，或既有函式即可產生答案，就可繞過 LLM。原書並建議設定每分鐘請求數（Requests Per Minute, RPM）與每分鐘 Token 數（Tokens Per Minute, TPM）門檻。

四、開始資料

請求狀況	原書路由
Redis 有有效向量快取	可繞過 LLM
結構化資料庫可直接回答	可繞過 LLM
既有函式可產生答案	可繞過 LLM
需要進階語言理解／生成	再呼叫 LLM
端點負載控制	設定 RPM／TPM 門檻

五、Excel／AI 分析方法

在 Excel 建立「請求類型、快取是否命中、資料庫是否可回答、函式是否可回答、是否呼叫 LLM、RPM、TPM」欄位；AI 可依原書條件協助分類，但不得自行捏造門檻值。

六、計算結果

原書沒有提供 RPM／TPM 的具體門檻數字，因此不補造結果。

七、結果分析與管理解讀

原書的核心原則是把昂貴的 LLM 推論留給真正需要的工作，以降低成本與延遲並提高可擴展性。

八、AI 提問詞

請依請求紀錄判斷哪些請求可由 Redis 快取、結構化資料庫或既有函式直接處理，哪些才需要 LLM；不要自行設定原書未提供的 RPM／TPM 門檻。