llama.cpp 決策、EmbeddingGemma 2｜10/8

逐字稿

今天挑 3 個有具體工程用途的開源相關消息，從 Agent 分流、程式碼檢索，到本機除錯。先說清楚，這些消息來自最近 7 天，不是全部在今天發布。

先看 llama.cpp。維護團隊在 10 月 2 日介紹新的決策模型支援，對應的程式碼也已合併。這類模型不逐字產生回答，而是讀取輸入，直接替你指定的選項評分。新的 System One 介面能處理選擇、是非與等級問題，回傳結構化結果及機率。像是工單要送給哪個團隊，或 Agent 上一步是否完成，都能用這種方式表達。

llama.cpp 本身採 MIT 授權，但模型要分別核對。文章列出的 Julia-1 與 Kev-4B 採 Apache 2.0，OpenJev 則有非商用限制。不能因為推論工具開源，就假設每個模型都能商用。

編輯觀察，對有固定選項的分流流程，這能省掉生成長篇回答再解析的步驟。但輸出合法，不代表判斷正確。作者的例子顯示，同樣的標籤加上選項說明，就可能改變路由結果；不同模型的信心值也不能直接共用門檻。我的判斷是，這比自由生成更適合邊界清楚的分類工作。若錯誤分流會觸發退款或權限變更，仍需另外設計低信心轉人工與副作用限制。這則的新變化是推論介面，不是重播先前的 Clef 模型發布。

第二個是 Google 在 10 月 6 日發布的 EmbeddingGemma 2。它是 Apache 2.0 授權的開放模型，完整版本有 740M 參數，能把文字、程式碼、影像、影片與音訊轉成共同向量。也可以只載入文字編碼器，減少資源用量。它提供的是檢索表示，不是替你撰寫答案的聊天模型。

官方模型卡有幾個很實際的提醒。程式碼檢索要使用對應的任務前綴；輸出向量可以從 768 維縮到 512、256 或 128 維，但截短後要重新正規化。查詢與文件也必須使用相同維度。數值精度則建議 bfloat16 或 float32，不要用 float16，因為可能出現 NaN 或沒有報錯的品質下降。

編輯觀察，維護內部程式碼搜尋或多模態 RAG 的團隊，可以把它列為自建檢索的候選。模型權重可自行部署，讓檢索層多一個可控的選擇。不過，更換 embedding 模型時，既有文件向量也要重新建立，不能直接沿用舊索引。縮成 128 維雖能減少儲存量，官方也提醒多模態品質會明顯下降。排行榜是供應商測試，真正要確認的是你的查詢能否找回正確檔案，以及前處理與索引版本是否一致。

第三則是一篇新的原創實測。Simon Willison 在台灣時間 10 月 7 日分享，用 Parseable 開源版接收 Datasette 的 OpenTelemetry traces。他實際使用 Parseable 3.2.4 與 Datasette 1.0a41，透過本機執行檔及 tracing 設定，在介面查看每個請求帶出的 SQL 查詢。這是新發表的整合經驗，不是宣稱 Parseable 今天才推出。

編輯觀察，對只想先看清楚一個服務慢在哪裡的工程師，這篇文章提供了可重現的本機起點。它驗證的是這組版本與 trace 流程，沒有測出正式環境的容量、高可用或成本優勢。範例採用預設帳密與本機儲存，不能原封不動搬到對外服務。Parseable 採 AGPL-3.0，另有企業方案，選用前也要核對所需功能屬於哪個版本。

這次最實用的切入點，是把問題縮小：固定選項的判斷、指定資料的檢索，或單一請求的追蹤。先知道工具能解決哪一步，才有辦法判斷它是否值得放進你的流程。