Skip to content

Explore: integrating TypeSafe Jev as a cheap decision gate #201

Description

@mroops0111

Background

TypeSafe AI 的 Jev 是一個回傳 typed decision 的模型 (是非加機率、固定選項、分數),不產生文字。這個 issue 記錄把它放進 Braid 的初步想法,以及目前還說不通的地方,留待後續討論。

Candidate Fits (候選位置)

Jev 不能取代 Claude Code,因為它不會呼叫工具,也寫不出附出處的內容。比較可能的位置是在昂貴的 run 之前做一次便宜的判斷。

  • Reactor Pre-Dispatch Filter:ReactorService 對每個新增或修改的 unit 都派發一次完整的 run,上限預設每小時 5 次。先問 Jev「這個 diff 有沒有碰到領域模型」,答否就不派發。
  • Semantic Search Rerank:EmbeddingService.search 取回候選節點後,由 Jev 對問題與節點逐一打分數再排序。
  • Secondary Ideas:判斷 View 是否真的過時,或判斷 Ask 的問題能否從 graph 回答。

Open Questions (待釐清)

整體還是覺得哪裡怪怪的,以下是目前想到的疑點。

  • Problem Evidence:Reactor 預設關閉,沒有資料顯示每小時 5 次的上限真的被打滿。這可能是先有解法才找問題。
  • Unreviewed Decisions:Braid 的前提是 AI 起草、人決定。過濾器說「否」,等於 AI 在沒有人審核、沒有出處的情況下決定 graph 看不到某個變更。即使把跳過記錄成 filtered 狀態,也和這個前提有張力。
  • Missing Context:一個 diff 是否影響領域模型,取決於 ontology 和現有 graph。只看 diff 的小模型可能根本判斷不了。
  • New Axis Cost:README 定義了五個可替換的軸,為了一個用途新增 Gate 或 Decider 介面算是擴張範圍。
  • Vendor Necessity:同樣的判斷用一次 Haiku 呼叫也做得到,不必多接一個供應商。Jev 的優勢 (延遲、價格) 在每小時個位數的呼叫量下可能不重要。
  • Unverified Specs:目前的規格都來自第三方頁面,價格數字彼此不一致,也還沒實測過。

Possible Spike (可能的實驗)

若要繼續,可以先做一個不動產品程式碼的實驗。

  • Replay:用 examples/conciergent 的歷史 diff 重播,讓判斷模型決定每個 unit 是否派發
  • Metrics:對照該次 run 是否實際產生 proposal,算出省下的 run 數與漏掉的有效 proposal 數
  • Baseline:同一組資料也跑 Haiku,確認 Jev 是否真的比較好

References

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions