• 大模型上線：在大模型應用上線前，透過評測瞭解大模型的能力，判斷大模型應用是否具備上線條件。
• 大模型升級切換：因為需要切換模型廠商、更換模型尺寸、模型微調或模型版本升級等原因，使用者需要透過評測對新舊模型的效果進行比對，從而決策是否進行切換。
• 大模型最佳化：透過評測發現的bad case，持續提升大模型效果。透過分析bad case的原因，可以進行諸如最佳化知識庫、最佳化提示詞、最佳化工作流、引入或最佳化MCP以及對模型進行微調等方式最佳化效果。

大模型評測相關工具平臺隨著各大模型平臺廠商的持續投入以及開源社群的火爆，相關功能也在持續完善，目前已經不是主要的困難點。目前的主要困難更多聚焦在如何結合自己的業務場景開展大模型評測。

• 評測維度：評測維度如何設計才能更好的衡量大模型效果，並推動大模型最佳化？
• 評測集：如何設計評測集才能更好地模擬實際的線上場景。如何平衡不同場景的比例失衡的問題，確保不同場景的覆蓋？
• 標註：標註人員質量參差不齊，不同人對標準的理解不一致。同一個人不同時間標註，也會導致結果不同，最終導致標註準確性穩定性差。除了標註效果外，人工標註非常耗時且需要投入額外的人工成本，導致無法開展大規模評測。
• 業務變化：隨著技術方案和業務場景的變化，大模型本身也在持續迭代演進。不同大模型特點不同，評測標準和評測集的構成也各不相同。

• 大模型被使用在什麼業務裡？
• 這個業務都有哪些業務流程，大模型在其中哪個流程中，起到什麼樣的作用？
• 在這個業務場景裡，大模型的使用者是誰。是否包含C端使用者。
• 使用者使用大模型需要解決什麼問題。使用者會提供什麼資訊，並期望大模型輸出什麼？
• 目前大模型是否已經投產了？還是處於測試階段？

• 我們要評測的物件是模型（基礎模型/微調模型），還是大模型應用。
• 物件=基礎模型：具體的模型名稱，是否是經過微調。
• 物件=模型應用：請提供大模型的技術架構。
• 如果是基於百鍊呼叫，請提供測試賬號方便了解技術細節。
• 是需要對單一大模型物件進行評測，還是需要和其他的大模型進行比較評測結果。如果是需要比較的話，對比物件是什麼？

• 使用者最常見的使用大模型都會分哪幾種場景，這些場景的呼叫量分佈是怎麼樣的？
• 每個場景裡大模型的輸入輸出是怎麼樣的，請分別提供一些示例。
• 本次評測的目標是什麼？是希望評估模型對實際場景的業務效果，還是需要評測特定子場景的效果，或是希望能對歷史bad case做迴歸？

• 如何判斷大模型效果好不好？業務人員會關注哪些維度？
• 針對其中的每個維度，是如何評估的，是定性的對錯，還是有打分的機制。如果是打分，分別打幾分。每個檔次之間的評分標準是什麼。
• 對於多維度的評價，是否可以透過一個公式（比如透過加權）將結果量化成一個數字，還是必須每個維度分別分析？

• 當前大模型的實際效果表現如何？這些效果評估是來自哪裡？是感性的反饋還是有數字支撐。
• 當前系統如何收集使用者的bad case，是否有日誌可以分析？
• 當前都有哪些原因可能導致bad case，都是什麼樣的原因？
• 是否分析過bad case，都是哪些原因導致結果不滿意，分佈如何。

• 企業內部是否有評測平臺，還是計劃使用百鍊進行評測？
• 是否有人工評測團隊，還是希望透過“AI評測器”（指透過大模型進行評測）或“自動化指標”自動完成評分（自動化指標僅適用於文字分類等客觀性任務）？
• 自動評測：自動對於推理完成的時效性是否有要求，是否可以接受離線的推理方式？使用這種方式的模型不執行線上推理，因此可以顯著降低推理成本。

基於評測目標確認資料來源

• 端到端評測集：
• 實際場景效果：為了實現實際場景效果評估的目標，需要選擇評測集儘量接近選擇實際線上資料。這裡典型的有兩種方法。一種是選擇歷史某天的歷史記錄。另外一種是選擇接入線上流量進行“雙跑”，僅僅是結果只做記錄分析但是不輸出給線上環境。區別在於接入歷史資料更方便做分析統計，“雙跑”方案方便後續做灰度以及切換。
• 特定子場景效果：為了實現特定子場景的評估目標，需要定義特定場景並設計對應的評測集。比如讓大模型做小學生數學題，五年級的題目、奧數題、壓軸題就是其中的一個子場景。從具體的需求出發，選擇整體的評測集中的子集。
• 分層評測集：
• bad case迴歸：使用線上問題中的使用者的負面反饋，或者在測試、質檢等環節形成的案例，經過標註形成Bad Case作為評測集。目的是為了驗證最佳化工作對bad case的最佳化效果。
• 功能模組評測：比如評測模型應用中的意圖識別模組的準確率、知識庫部分的召回準確率等。透過評測識別各功能的效果方便後續進一步最佳化。這種情況下可以針對評測物件的各種功能針對性設計評測集。
• 安全評測集：專注於科技倫理、資料安全和內容安全的各項指標，確保模型滿足安全合規要求。建議由安全或風控團隊提供。

確認評測集場景範圍

• 結合業務場景分析：從業務場景出發來設計評測場景是最基本的做法。大模型在不同場景下可能有不同的表現，模型評測需要覆蓋不同業務以獲得完整的評測結果。假設阿里雲售後支援大模型可以在提供雲產品異常問題診斷的能力的同時，也提供協助售後支援小二回答服務流程規範、服務排班的問題。實際評測的時候就不能遺漏對應的功能。而且應用服務異常診斷也需要針對不同雲產品的故障診斷能力準備評測集。
• 結合技術架構分析：不同的業務場景下可能在技術實現上會有不同。比如透過意圖識別針對不同的情況走不同的技術鏈路的，可能是不同的場景。或者使用了不同的元件、MCP或知識庫，或者有不同的工作流的，很可能是不同的場景。

確認評測集數量

• 線上評測集：需要考慮“雙跑”持續的時間。雙跑的時間取決於業務人員覺得多久足夠證明業務效果。一方面考慮評測集樣本數量；另外一方面考慮是否覆蓋業務週期（比如是否覆蓋常態和大促態、覆蓋工作日和週末等）。一般建議可以評測3-7天。為了更準確評估，可以提前統計單日的呼叫量。
• 離線評測集：離線資料集的數量主要考慮場景覆蓋度、樣本數量足夠以及與成本效能的均衡。場景覆蓋度需要不存在某個場景沒有評測集樣本的情況。樣本數量足夠包括總體樣本數量足夠，也包括各評測場景的樣本也需要有足夠的樣本數量。成本效能的均衡主要考慮樣本數量不能太大，以免評測需要消耗過多的時間、人力和算力成本。為了更準確評估，可以提前統計單日的總呼叫量及分場景的數量。

• 增加樣本數量。透過提升樣本數量（即增加時間範圍）來獲得更多負樣本。
• 適用場景：評測目標是為了實現“以XX日到XX日實際案例評測結果”，評測集需要儘可能接近真實資料。
• 注意事項：無法實際規避樣本分佈不均衡的問題，只是透過提升總體樣本數量來確保小場景有最低數量的樣本。而且過度的增加樣本會導致大場景的樣本過多浪費資源。此外需要關注某段時間範圍是否已覆蓋所有場景（比如要考慮業務場景下工作日和週末是否存在不同），而不是單純只考慮數量。這不是一個特別好的方法，只是在特定場景下約束下的選擇。
• 調整權重比例。比如每個場景按需要生成足夠數量的樣本進行評測，分場景計算平均分，分析各個場景的模型表現。
• 適用場景：需要用數字量化總體效果，但是又存在樣本分佈不均勻的情況。
• 調整損失函式。引入諸如召回率、F1分數等指標，選擇更加符合業務需求的指標。
• 適用場景：在樣本分佈不均衡時關注小場景的效果。另外小樣本數量過小時資料也可能失真。

評測集初稿生成

• 歷史請求：透過解析一段時間內的歷史訪問日誌等方式，獲得歷史訪問請求。
• 優點：接近真實資料，樣本數量充足。
• 缺點：資料可能同質化嚴重。特定日期/業務場景等無法控制。不支援冷啟動。
• bad case日誌：需要模型輸出給使用者使用時，收集使用者的反饋。比較典型的做法是在模型輸出時讓使用者反饋。如果使用者點踩，可以進行分析後納入bad case案例庫。
• 優點：在有埋點時獲取難度接近歷史請求。
• 缺點：主要適用於問題迴歸場景，需要對使用者反饋做埋點。不支援冷啟動。

• 人工生成：人工生成評測集在有專家經驗輸入的情況下可能可以獲得比較好的效果，但是缺點在於成本過高，一般無法獲得特別多的評測集樣本。
• 優點：資料質量高，可以考慮到多種異常場景。支援無使用者使用下的冷啟動。
• 缺點：耗費人力，對人員的要求高。無法進行高頻率更新。
• 歷史請求+人工調整：透過對特定問題進行調整，比如減少簡單問題的比例甚至直接過濾，針對bad case做重點補充等。
• 優點：重點問題突出。
• 缺點：破壞了線上的比例，無法透過評測集的測試效果驗證推出線上效果。
• 大模型自動生成：在冷啟動場景裡，可能無法足夠的線上真實案例作為評測集，除了人工去造之外，透過大模型自動生成評測集也是比較好的做法。
• 優點：樣本數量充足。在沒有線上實際使用時冷啟動方便。
• 缺點：效果最差，需要人工篩選，並且需要基於效果不好的部分最佳化生成提示詞。
• 人工生成+大模型自動生成：在實際的冷啟動場景裡，為了能同時保障評測集的質量和數量，一般的做法是由人工生成一部分評測集後，以few-shot的方式作為prompt的一部分，進行大模型自動生成。

評測集最佳化

• 資料安全脫敏：針對評測集裡有涉及資料安全資訊時，根據需要進行脫敏。如使用者的個人身份敏感資訊，公司內部諸如金鑰資訊等內部資料，都需要根據公司的要求進行處理。
• 資料集分佈不合理：比如生成的評測集正負樣本比例、各場景樣本分佈等不符合評測集的預定設計，則需要透過刪除過多的樣本或補充缺少場景的樣本的方式進行調整。
• 持續迭代最佳化：評測集需要結合實際的業務場景持續最佳化迭代的。基於過程中的bad case持續最佳化評測集，透過刪除過程中發現的低質量的評測集樣本，補充優質樣本，或對業務的新增場景以及評測集數量比較少的小場景補充樣本等方式，持續完善評測集。需要注意的是，如果是透過大模型自動生成的評測集，則不只是最佳化評測集，也需要根據不合理的部分最佳化提示詞，以生成更高質量的評測集。

案例參考

設計方法

• 模型是否有統一的評價維度，還是需要從多個維度去判斷模型的能力。
• 對於具體的某個維度，分幾檔（量級）。
• 每個量級的定義，以及區分不同量級的標準。

• 對於選擇題或判斷題，業務人員的期望就是“選得準”。那一般可以設計維度數量=1，評測量級=2，分別為正確和錯誤。
• 對於生成類場景，由於沒有標準答案，需要業務人員根據場景設計評測維度。比如翻譯場景，“信、達、雅”是最經典的三個標準。

模型效果量化

透過權重調整各個維度的重要性，最終透過加權後的得分來量化模型的最終效果，是一種相對比較簡單的實現方案。對於總分，透過加權

計算總體效果。其中n表示場景數量，

表示某個場景的平均分，

表示該場景樣本的權重，可以設定為該場景樣本的佔比，也可以都是1，或者業務人員根據業務需求設定。

評測配置設計

• 評測方式
• 人工評測：透過人員手工評測的方式進行評測。一般用於評測集數量較少或評測準確性要求較高或者不具備自動評測條件的場景。
• 自動評測：自動評測分AI評測和自動化評測，可以極大提升評測效率。其中AI評測為使用大模型進行評測的方式。自動化評測適用於文字分類等客觀性任務，透過自動計算BLEU、Rouge、F1等自動化指標評估模型效果。
• 基線評測：針對基礎模型的評測，使用基線評測集進行測試。
• 評測型別：單個評測VS對比評測。評測物件只有1個模型還是多個模型。

AI評測

案例參考

集團某業務自動化評測

評測資料分析

評測報告編寫

集團某業務qwen-max評測

• 增強項：NL2Frame、NL2SQL、上下文理解、摘要總結、CoT、謎題解惑、數學和工具
• 減弱項：程式碼編寫

• 評測方案最佳化
• 持續最佳化評測集
• 最佳化評測維度
• 最佳化AI評測Prompt
• bad case最佳化
• 決策模型上線或者切換