優化 LLM 模型分派策略：Reasoning vs. Fast

隨著新一代模型（如 Grok 4.1, Gemini 3, GPT-5）的推出，我們擁有更多元化的選擇。這些模型不再是單一維度的「強 vs. 弱」，而是分化為 「深度推理 (Reasoning)」 與 「極速反應 (Fast/Extraction)」 兩種特化型態。

為了在 履歷生成品質 與 系統響應速度/成本 之間取得最佳平衡，我們對 Career Knowledge Base 的模型分派策略進行了全面優化。

核心策略：適材適所

我們將系統中的 LLM 任務分為兩大類：

這類任務需要模型具備邏輯判斷、多步思考、或是生成高品質自然語言的能力。錯誤的判斷或平庸的寫作會直接影響最終產出的品質。

任務特徵：邏輯推演、創意寫作、歧義判斷
選用模型：grok-4-1-fast-reasoning
應用場景：
- 履歷反思 (Reflection) (reflection.py)：Writer-Critic-Reviser 循環需要高度的自我修正與寫作能力。
- 技能驗證 (NLI) (nli.py)：判斷「證據是否支持技能」需要精確的語意理解與邏輯推論，避免誤判。

這類任務通常定義明確，主要是資訊提取、格式轉換或簡單總結。這這類場景中，低延遲與高吞吐量比深層推理更重要。

任務特徵：結構化輸出、摘要、資訊抽取、大量並行
選用模型：grok-4-1-fast-non-reasoning
應用場景：
- 實體抽取 (Entity Extraction) (entity_extractor.py)：從文字中識別技能與公司名。
- 證據壓縮 (Compression) (compression.py)：將冗長段落濃縮為 bullet points。
- 教練提問 (Coaching) (coaching.py)：生成標準化的 STAR 追問。
- 全域檢索 (Map-Reduce) (global_retrieval.py)：並行處理數十個社區摘要，速度與成本是關鍵。

我們更新了各個模組的 get_model() 或 get_chat_model() 函式，將預設值指向最新的 Grok 4.1 系列（同時兼容 Gemini 3 與 GPT-5）：

雖然這次調整優化了模型選擇，但目前的實作仍有改進空間：

目前的模型選擇邏輯（如 if XAI: use grok-4-1...）是寫死在程式碼中的。雖然可以透過環境變數覆蓋（例如 XAI_MODEL），但使用者必須手動在 .env 中為每個模組設定不同的環境變數才能實現精細控制（這很麻煩）。

改善方向：建立統一的 ModelConfig 或 LLMFactory，支援設定檔配置，例如：

models:
  reasoning: "grok-4-1-fast-reasoning"
  fast: "grok-4-1-fast-non-reasoning"
tasks:
  nli: "reasoning"
  extraction: "fast"

目前的選擇是靜態的。有時候簡單的 NLI 任務其實不需要 Reasoning 模型，或者複雜的實體抽取可能需要更強的模型。

改善方向：引入「路由模型 (Router Model)」。使用一個極小模型（如 0.5B - 1B 參數，或甚至是簡單的分類器）先分析 Prompt 的複雜度，再動態決定要呼叫 Reasoning 模型還是 Fast 模型。

如果 Reasoning API 暫時不可用或達到 Rate Limit，目前的程式碼可能會崩潰或需要依賴全面 fallback。

改善方向：實作更強健的 Fallback 機制。例如當 grok-4-1-fast-reasoning 失敗時，自動降級使用 grok-4-1-fast-non-reasoning 甚至其他供應商的模型。

目前我們只有全域的 token 估算。將模型分化後，Reasoning 模型的 token 單價通常較高。

改善方向：在 db-info 或 logs 中區分 reasoning_tokens 與 fast_tokens，讓使用者能更精確地掌握成本分佈。

Career Knowledge Base 持續演進，致力於用最有效率的方式幫助您構建完美的職涯履歷。