SemIf 展示瀏覽器內的選項分數讀取，決策機率仍須另外校準

9 月 18 日進入 Hacker News 討論的 OpenJev 瀏覽器實驗，目前以 SemIf 名稱展示本機決策推論。它讓同一款模型比較兩條路徑：直接讀取允許選項的分數，或逐個 token 生成包含機率的 JSON。專案明示與 TypeSafe 無關，技術焦點在於省去答案文字生成的成本。[討論紀錄](https://news.ycombinator.com/item?id=49752041)、[實驗頁面](https://openjev.com/)

直接讀取路徑把可選答案映射為 A 至 T 等標籤，取得 logits 後，只在使用者提供的選項間做 softmax 正規化。從這個流程可推知，它仍須處理輸入上下文，但不必為輸出完整 JSON 反覆解碼。對分類與工作流路由而言，這提供了值得量測的實作方向；若任務需要長篇推理才能判斷，省略生成步驟是否影響品質仍須另測。[方法說明](https://openjev.com/)

執行層採用 wllama 與固定版本的 GGUF 權重。wllama 是 llama.cpp 的 WebAssembly 綁定，已支援 WebGPU，並可用 n_gpu_layers 調整卸載至 GPU 的層數；上游也提醒，部分瀏覽器相容模式會明顯降低效能。因此測試結果必須附上瀏覽器、模型量化與硬體條件，不能僅以參數量推算延遲。[wllama 文件](https://github.com/ngxson/wllama)

上游另建議將大型權重切成每份最多 512 MB 的檔案，以改善下載並減少記憶體不足問題，量化則建議從 Q4、Q5 或 Q6 取捨。這些部署條件意味著，單次決策即使很快，首次下載與模型常駐的資源需求仍可能主導使用體驗，小模型也不能只憑載入成功就視為適合任務。[模型準備指南](https://github.com/ngxson/wllama)

頁面分開顯示下載、載入、暖機、輸入處理與生成時間，兩種方法依序執行，直接讀取先跑。這避免同時爭用 GPU，卻仍需檢查快取與執行順序是否影響比較。更關鍵的是，選項間的機率並未校準，也排除了選項以外的答案；數值接近一，不能直接當成答案可靠的保證。[測量與限制](https://openjev.com/)

開發者若要把這類讀取接進正式路由，應用獨立標註集檢驗錯誤率、選項順序敏感度及拒答門檻，並另外測試繁體中文與領域詞彙。本次查核時，網站連出的實作說明回傳 404，尚不足以完整重驗其評測流程；目前較適合視為可操作的推論實驗，不能據此認定與 Jev 具有相同能力或已達到可部署的信心校準。