簡短版本。我們先固定一組買家問題，再把每次回答與測量情境一起記錄。只有條件一致時才比較前後結果；事實也只對照當前有效且已審批的來源評分。
更新於 2026 年 8 月 24 日。
一次 Clarivy 測量如何變成可用證據
- 先固定問題，再開始測量。
買家問題在運行前取得穩定的情境與提示詞識別碼，避免問題在事後悄悄改變。Scenario Panel v2
- 把回答和測量情境一起保存。
每條觀測都記錄表面、模型、搜尋狀態、問題血緣、時間、來源與原始證據。Observation Contract v2
- 不同類型的證據分開記錄。
回答、原生引用、模型正文鏈接、斷言支撐、錯誤與原始記錄不會被混成一個模糊的信心標籤。
- 先檢查兩次運行是否真的可比。
只有問題面板與觀測條件相容時才報告變化；否則差值會被阻止或加上明確限制。
- 只用已審批來源核驗事實。
來源缺失、過期、衝突或未審批時，Clarivy 會返回「不可用」，而不是猜一個準確度分數。Fact Registry v1
- 讓人和智能體都能檢查同一份證據。
人類與機器文件共用穩定 ID；任何下游行動仍需先確認證據是當前有效的。
把執行與驗收分開
Clarivy 不要求管理層把服務商的工作報告當成改善證明。行動記錄和結果驗收始終分開。
- 驗收規則由客戶掌握。問題、介面、裝置或帳戶條件、重複次數，以及什麼才算「獲得推薦」，都在執行前約定。
- 回執只證明行動發生。它記錄批准、實施、發布、獨立核驗與回退條件，但不把一次改動直接寫成效果成因。
- 復測決定下一步。條件相容的證據支持擴大、修正、觀望或回退；缺失與無法判定的結果仍然保留。
消費端介面邊界。客戶保留的盲測問題與真實設備驗收，只在已批准範圍包含消費端實機驗證時適用。模型 API、消費端 Web 與原生 App 是三組獨立觀測，絕不合併成一個引擎分數。
哪些團隊適合 Clarivy
適合
- 重視真實推薦結果，而不是服務商的工作量報告。
- 願意在執行前共同確定基線與驗收規則。
- 團隊可以批准事實表達並提供官方來源。
- 希望如實看見落選、不確定性與競品替代。
不適合
- 要求保證某個模型在某一次回答中一定推薦品牌。
- 要求偽造評論、隱蔽背書、虛假來源或不符合平台規則的自動化。
- 只允許報告成功截圖，或希望在執行後改變測試規則。