Day 17 的即時搜尋測試中，Qwen 選對了 web_search。但一次選對，還看不出它遇到其他情況會怎麼走：本地知識庫找得到資料時會不會亂搜？使用者只問搜尋結果的標題時，會不會多做一步匯入？

所以 Day 18 我把問題整理成 10 題路由評估。每題都有預期行為，我只檢查 Qwen 提出的工具呼叫是否符合預期；這輪不執行工具函式，不會真的搜尋網頁、讀文件或匯入來源。

把預期路由寫成 10 題

10 題案例各自標好預期工具；如果應該直接回答，expected_tool 就是 null。

其中兩題附上固定的搜尋結果 fixture：當模型在 web-search 列出候選網頁後，使用者選定 web-2 時，Qwen 應選擇 import_web_source；只問 web-2 的標題時，應直接回答、不匯入。另有一題要求搜尋後立刻匯入，預期只先選 web_search，把是否匯入留給使用者決定。fixture 使用 example.org 網址，評估不會連線到這些頁面。

每題只呼叫模型，不執行工具

我寫了一支路由評估程式，沿用專案的 system prompt 和 TOOL_SCHEMAS。每題送出一次模型請求，再比對回覆中的工具呼叫清單：預期使用工具時，必須提出且只提出該工具；預期直接回答時，tool_calls 必須為空。arguments 會記錄，但不列入評分。

這個評估只看模型選了什麼。execute_tool_call()、網頁下載、文件讀取、來源匯入和索引更新都不會執行。測到 import_web_source 時，只確認模型有沒有提出正確的工具呼叫，沒有真的匯入來源。

先在一個終端機啟動本地模型：

HF_HUB_OFFLINE=1 uv run mlx_lm.server \
  --model mlx-community/Qwen3.8-27B-4bit \
  --port 8081

再開另一個終端機執行評估：

HF_HUB_OFFLINE=1 uv run python knowledge/evaluate_routing.py

每題的紀錄包含預期工具、實際選擇、arguments、finish_reason、token usage 和耗時。程式最後會統計命中率、誤呼叫、漏呼叫和錯選工具數；執行紀錄寫入 Git 忽略的 runs/。

這次 10 題全數命中

2026 年 10 月 2 日，我用 mlx-community/Qwen3.8-27B-4bit 跑了一輪，temperature 設為 0。10 題都符合預期：命中 10/10，誤呼叫、漏呼叫、錯選工具和請求失敗都是 0。

幾個邊界案例也照預期處理。Qwen 沒有替兩題直接回答的問題呼叫工具；使用者選定 web-2 時，它提出 import_web_source 並帶入 web-2；只問標題時，它直接回答。遇到「搜尋後立刻匯入」的要求，它先選 web_search，沒有跳過使用者選擇。

10 次請求平均耗時約 6.2 秒，最短約 2.7 秒、最長約 11.8 秒。這組數字包含 server 的 prompt cache 暖機，不能拿來預測其他模型或機器的延遲。

10/10 的範圍

我原本想找一次選錯工具的案例，這 10 題沒有找出來。但這不能寫成「Qwen 的工具路由準確率是 100%」。案例是我按目前的工具設計整理的，每題只跑一次；評估也沒有涵蓋其他模型、複雜上下文、arguments 是否符合 schema、工具執行結果或最終回答品質。這次能確認的只有：這 10 條預先列出的路徑都通過了。

這份程式可以重跑同一組案例。之後修改工具描述，就能檢查模型有沒有多叫工具、漏掉該用的工具，或把搜尋直接接成匯入。紀錄中的 7 次工具呼叫看起來都帶了符合 Python 驗證條件的參數；不過 Day18 沒有替參數正確性評分。下一篇我會比對模型收到的工具說明和 Python 的檢查規則，再故意送幾個錯誤參數，看程式能不能擋下來。

參考資料

• AI Engineering 研究前線專案程式碼