一個團隊讓 API 推薦供應商，把答案存下來，加到一個標著“ChatGPT 可見性”的看板裡。請求成功了。響應裡有一些能認出來的公司。看板看起來可信。
問題出在那個標籤上。API 響應是關於某一次具體請求及其配置的觀察結果。它本身並不顯示某人在使用 ChatGPT 搜尋時看到了什麼。把兩者混為一談，會讓產品團隊去最佳化錯誤的系統，讓市場團隊報告一個它從未測量過的曝光。
對與多個模型打交道的開發者來說，這種區分不只關乎品牌監測。模型名只是應用的一部分。所提供的上下文、指令、檢索工具以及周邊產品行為，共同決定使用者收到的答案。
在比較答案之前先定義系統
當一個 API 測試的輸入是明確的，它才最容易解讀。你可以記錄所請求的模型、messages、工具定義、可用文件以及受支援的生成引數。你也能控制應用在展示響應之前如何處理它。
消費級產品有它自己的配置和介面。其中一些行為可能是可見的；另一些可能沒有被記錄到足以復現的程度。即使兩種體驗指的是同一個模型家族，prompt 相同也不能證明它們使用了完全相同的上下文或檢索。
這不是放棄 API 測試的理由，而是準確命名結果的理由。“我們的應用在開啟網頁檢索的情況下返回了這些供應商”是一個有用的觀察。“ChatGPT 向買家推薦這些供應商”是另一個主張，需要來自那個被點名產品的證據，以及一組定義明確的買家任務。
把它們當作兩個獨立的測試專案。應用測試回答的是你的產品行為是否正確。產品觀察測試回答的是在外部體驗中、在你記錄的條件下顯示了什麼。兩者都不能自動替代對方。
生成的答案不是發生過搜尋的證明
模型可以在那次請求中完全不開啟某公司的網站，就產出關於這家公司的答案。認出一個名字不能確立資訊的新鮮度，而普通生成文本里的一個 URL 本身也不是檢索痕跡。
當你的應用需要最新資訊時，配置一條合適的檢索路徑，並檢查它是否真的被用上。OpenAI 的網頁搜尋文件描述了在 Responses API 中啟用相關選項的情況，包括 web_searchsearch-call 輸出項以及 URL 引用註解。它還指出，啟用該工具後，模型可以根據 prompt 自行決定是否搜尋。[2]
這意味著“工具可用”和“工具被使用”在測試記錄裡應該是兩個不同欄位。儲存返回的工具呼叫資訊，而不是從自信的措辭去推斷髮生過搜尋。如果請求失敗、返回不完整結果，或者沒有走預期的檢索路徑，也要把這個結果保留下來。
在渲染有搜尋支援的答案時，保留引用註解。OpenAI 的文件要求，在向用戶展示其網頁結果中的資訊時，必須提供清晰可見、可點選的行內引用。[2] 把所有內容壓成一個純文本字串，可能會丟掉你的介面需要展示的證據。
引用仍然需要檢查。看被引用的頁面是否支撐它所附著的陳述，而不是僅僅因為答案裡有個連結就給它質量分。
把供應商調研與可見性測量分開
假設一個團隊在研究人們如何找到 geo agency singapore。開發測試可能會讓一個由 API 驅動的助手識別服務、解釋選擇標準，或比較提供的服務商頁面。這些測試可以揭示應用是否檢索到了有用的證據，以及是否準確地描述了它。
可見性研究問的是另一件事：在一組相關的使用者任務中，某個服務商是否、以及以何種方式出現在某個指定的 AI 產品裡。觀察結果應當區分三種情況：答案提到了這個品牌、有一處引用連結到它的網站、以及給出帶明確理由的推薦。被用於某個事實點的來源，不一定就是被推薦的供應商。
如果測試 prompt 明確問的是某一家公司，那麼在答案裡找到這家公司，幾乎說明不了它在一次不帶品牌的發現類任務中出現的可能性。帶品牌和不帶品牌的 prompt 都可能有用，但它們屬於不同組。
不要把一次缺席的提及變成一次事故，或變成一個對服務商可見性的終局判決。把它儲存為既定測試條件下的一個結果。同樣，也不要把一個漂亮的答案變成對每個買家體驗的主張。
保留一份你能復現、或能誠實描述的記錄
對你自己應用來說，一份有用的測試記錄包括：
- 確切的使用者輸入，以及隨它一起傳送的任何應用指令；
- 端點、請求的模型識別符號，以及返回的版本資訊；
- 提供給該請求的文件或對話上下文；
- 哪些工具可用，哪些真正運行了；
- 可能影響答案的受支援設定，包括所用到的檢索過濾或位置配置；
- 請求時間、返回的答案、引用、錯誤以及重試歷史；
- 用於給輸出打分的規則，以及對此分數的任何人工修正。
存足夠的細節，以便在調查差異時用得上，同時不要隨意保留敏感的客戶資料。使用經批准的測試素材，限制日誌的訪問許可權，並決定原始輸入需要保留多久。
對於外部產品的觀察，記錄產品、可見的模式、查詢措辭、時間、對話設定、你能觀察到的相關設定，以及顯示出來的答案。把未知的配置標為未知。把一次測試稱作可復現，並不會讓隱藏的產品設定變得可用。
把失敗的觀察與有效但未提及的答案區分開。頁面載入失敗或響應中斷不是乾淨的陰性結果。把這兩類結果混在一起，會讓可靠性問題看起來像是品牌可見性的變化。
一次只改應用的一個部分
評估新模型時，保持證據包和評審標準不變。評估檢索時，儘可能保持模型和其他受支援設定穩定。如果你同時改動 prompt、模型、文件和搜尋配置，你比較的是整套工作流，而不是隔離出某一個原因。
兩類比較都合理，關鍵是標對名字。完整的工作流比較幫助團隊決定上線什麼；受控的元件測試幫助解釋為什麼某種配置表現不同。
把有代表性的任務跑不止一次，並保留差異。在報告比例時，記錄嘗試次數和有效觀察次數。來自一個有意挑選的測試集的結果描述的是那個集合；它們不會自動成為所有使用者看到某品牌頻率的估計。
不要把模型之間的一致當作驗證。多個系統可能重複同一個來自同一來源的說法，或者共享一個沒有依據的假設。就事實準確性而言，決定性的證據仍然是底層材料和任務本應滿足的標準。
既要測模型，也要測閘道器
String AI 記錄了一個共享的 API 入口，以及面向受支援整合的 OpenAI 相容認證。[1] 這對通過統一連線方式來比較模型的團隊很有用。但它不應被理解為承諾：每個上游功能、託管搜尋工具或響應物件在每條路徑上都完全一致地工作。
在依賴檢索或引用處理之前，測試你應用實際會用的那個端點與模型組合。確認預期的工具受支援、請求保留了它的配置、響應暴露了你介面需要的資訊。並決定功能不可用時怎麼辦：返回明確的限制說明、使用顯式配置的替代方案，或者停止任務。靜默退回一個沒有檢索的答案，會改變應用能主張的東西。
API 評估可以既嚴謹又有商業價值，而不必假裝復現一個消費級產品。命名你測試的系統，保留它的配置，把它的證據附著在結果上。這樣開發者拿到的是可以改進的東西，市場團隊拿到的是可以解釋的測量。
來源
[1] https://www.string.ink/docs
[2] https://developers.openai.com/api/docs/guides/tools-web-search