評估與品質 · 實作指南
從真實工作建立評估集，而不是從示範開始
用有標記的小型測試集，把檢索問題與回答問題分開診斷。
收集有代表性的問題
請員工提供最近難以回答的問題，取得同意後轉成去識別或合成測試。包含例行問題、例外、沒有答案及意思模糊的請求。Bedrock 評估文件介紹預期答案與來源文字，但「正確」的業務定義仍由團隊決定。不要只把章節標題改成問句，因為員工通常不會使用政策作者完全相同的語言，真實用法也更容易暴露檢索缺口。
標記證據與可接受行為
以假設的營運助手為例，每筆測試應包含問題、授權角色、預期來源及可接受行為。有些問題應要求澄清，不應直接產生唯一答案。標記必須出現的關鍵事實，以及不應出現的主張，讓人工審核保持一致。這樣可以防止流暢卻沒依據的內容，只因聽起來熱心便獲通過，也方便不同審核者討論分歧。
流程一覽
保留未用來調整的題目
把一部分題目用於診斷，另一部分保留到方案準備好才測試，避免提示詞只記住可見例子。每次執行都記錄資料庫、解析器、模型與設定版本，分別比較檢索成功、證據支持及總審核投入。單一平均分可能掩蓋少數但後果重要類別的退步。因此報告應按問題類型拆開，並清楚列出未通過的情況，而不只展示總分上升。
從失敗逐步擴充
試點後，把已確認事件與新流程變化加入評估集，避免儲存不必要的個人資料。過時問題可以附理由退役，不要因它難答而偷偷刪掉。評估資料應被視為需要維護的業務資產。它不能保證不會出現罕見錯誤，但能讓未來每次變更，都比隨意跟最新模型聊幾句更有紀律，也更容易向客戶說明接受或拒絕更新的原因。
讓評估直接支持發布決定
發布會議先展示幾個失敗案例，再看總分。請營運負責人判斷剩餘問題在擬定範圍內是否可接受，記錄已接受限制及禁止用途。這讓評估成為決策工具，而不是部署後才附上的裝飾報告。若有人只看到分數提高卻不了解失敗後果，就應暫緩簽核，直到責任與人工後備處理都已說清楚。
來源與延伸閱讀
編輯原則
本系列以 AI 輔助原創撰寫，並對照連結的公開來源。實作建議與假設情境屬編輯分析，並非客戶實績。來源發布日期及產品細節可能與本系列整理日期不同。