LLM-eval-survey：一份論文清單，不是一套評測工具
The official GitHub page for the survey paper "A Survey on Evaluation of Large Language Models".
秒懂
- 它是什麼？
- 這個倉庫是綜述論文 A Survey on Evaluation of Large Language Models 的官方索引頁，用主題分類整理 LLM 評測相關文獻。它解決的是找論文與建立分類座標的問題，不提供任何可執行的評測程式碼。
- 適合誰用？
- 如果你需要的是在動筆寫評測方案前，先確認某個能力維度上已經有哪些工作、別人的評測設計長什麼樣，這個倉庫可以直接用，從 What to evaluate 的分類一路點進 arXiv 或 ACL 的原文即可。如果你要的是能跑出分數的程式，這裡沒有，README 只把 microsoft/promptbench 列為相關專案，實際的評測執行要另外去找。
- 可以商用嗎？
- 未經許可不行。GitHub 在這個儲存庫中沒有找到授權檔案；沒有授權，預設即「保留所有權利」：你可以閱讀程式碼，但不能重複使用。使用前請看看 README，或先取得作者同意。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 3 天前。
- 用什麼語言寫的？
- GitHub 沒有提供這個儲存庫的主要語言。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
這份倉庫的產物是清單，不是分數
打開 README，第一個實質內容區塊是作者名單與機構，接著是一句定位說明：A collection of papers and resources related to evaluations on large language models。整個倉庫的產出就是一串論文條目，每條包含標題、作者、發表場合或年份，以及一個指向 arXiv、ACL Anthology 或 SSRN 的連結。沒有安裝指令，沒有 API，沒有測試資料，也沒有任何模型輸出的數值。
它服務的對象因此很明確。正在設計評測方案的研究者與工程師，可以在這裡快速看到某個能力維度上已經被做過哪些題目，避免重複造輪子。需要為內部評測挑選現成 benchmark 的人，也能從分類架構反推自己漏掉了哪一類。反過來說，如果你的需求是「把模型跑一遍、拿到一個可比較的數字」，這個倉庫幫不上忙，它連一份範例輸入輸出都沒有。
README 裡有一句提醒值得注意：因為 arXiv 上的論文沒辦法即時更新，請以倉庫為準，論文之後可能再改。這句話把倉庫的定位說得很清楚，它是活的索引，論文是凍結的快照。
分類軸線照著綜述論文的骨架走
倉庫的目錄結構直接對應論文的章節。Table of Contents 底下分成 What to evaluate 與 Where to evaluate 兩大塊，前者再細分為自然語言處理、穩健性與倫理偏誤與可信度、社會科學、自然科學與工程、醫療應用、Agent 應用、其他應用。自然語言處理這一支又往下切成自然語言理解、推理等子項，理解之下再列情感分析、文本分類、自然語言推理、其他。
這個三到四層的樹狀結構本身就是倉庫最有價值的部分。它提供了一套座標，讓你知道「情感分析」在整個評測版圖裡被擺在自然語言理解之下，而不是跟推理或穩健性混在一起。對照條目內容可以看出收錄標準偏寬：情感分析底下同時放了 Holistic Evaluation of Language Models 這種通用評測框架，也放了 Is ChatGPT a Good Sentiment Analyzer? 這種單一任務的檢驗。一條論文可能同時出現在多個小節，例如 Holistic evaluation of language models 在情感分析與文本分類都出現過，A Systematic Study and Comprehensive Evaluation of ChatGPT on Benchmark Datasets 也重複出現在多處。
這種重複在人工維護的清單裡很常見，好處是順著任一條路徑都能找到它，代價是清單長度會膨脹，而且沒有去重機制告訴你哪些是同一篇。使用時把它當成多入口的索引，不要當成去重後的資料集。
怎麼把它接進你的工作流程
這個倉庫沒有建置步驟，取得方式就是一般的 git clone，或直接在 GitHub 網頁上瀏覽 README。真正需要操作的是裡面的錨點連結：Table of Contents 用的是 #what-to-evaluate、#where-to-evaluate、#natural-language-processing、#robustness-ethics-biases-and-trustworthiness 這類 HTML 錨點，在 GitHub 上點擊會直接跳到對應小節。
如果你打算把清單轉成自己的參考文獻庫，可以抓 README 的原始 Markdown，條目格式相對固定，開頭是編號，接著是斜體標題、作者、發表資訊，最後是 [[paper](...)] 形式的連結。用腳本抽出這些連結後再匯入 Zotero 或類似的工具是可行的，但要注意兩個坑：一是部分條目的作者或年份寫法不一致，二是同一篇論文在不同小節重複出現，匯入前需要自己去重。
另一個實用入口是 Related projects。README 列出兩個：microsoft/promptbench，說明為 Prompt benchmark for large language models，以及 llm-eval.github.io。前者是微軟的提示詞穩健性評測專案，如果你要的是能執行的評測程式碼，那個倉庫比這個索引頁更接近你的需求。這個倉庫本身不提供安裝指令，也不提供任何設定檔，所以沒有 config key 可以調。
授權與維護狀態在素材裡是空白的
這是採用前必須自己確認的地方。你給我的倉庫資訊中，License 欄位標示為 unknown，Primary language 也是 unknown。README 全文沒有出現任何授權聲明，沒有 LICENSE 區段，沒有引用授權條款，也沒有說明條目內容是否允許再散布。
這對不同用途的影響不一樣。純粹閱讀與點擊原文連結，不涉及授權問題。但如果你想批次抓取 README 內容、把清單併入自家產品的文件、或做成對外的資料集，就需要先確認倉庫是否附有 LICENSE 檔案，以及各條目指向的論文本身採用什麼授權。倉庫的授權狀態與論文的授權狀態是兩件事，不能互相推定。這裡不提供法律意見，只指出這個欄位目前是空的。
維護方面，素材顯示最後一次 push 是 2026 年 9 月，倉庫未被歸檔，也沒有檢索到任何 release。沒有 release 對這類清單型專案是正常的，因為它沒有版本化的產物。真正的維護訊號是 News and updates 區段，目前只記錄了兩筆：2023 年 7 月論文第一版上 arXiv，2023 年 12 月第二版上 arXiv 並附上中文部落格。README 開頭寫著歡迎 pull request 與 issue，貢獻者會被列進 acknowledgements，這是它宣稱的更新機制。至於這個機制實際上有多活躍，素材裡沒有任何可以佐證的資訊，我沒有查證，也不做推測。
清單型專案的三個結構性弱點
第一個弱點是時效。LLM 評測領域的論文產出速度很快，一份靠人工提交與合併的清單，覆蓋範圍取決於維護者的投入。README 自己承認 arXiv 版本會落後於倉庫，但倉庫本身同樣可能落後於領域。當你在清單裡找不到某個近期熱門的評測方法時，無法判斷是它不夠重要，還是還沒有人提交。
第二個弱點是沒有品質篩選的說明。條目混雜了 arXiv 預印本、ACL Findings、SSRN 工作論文，README 沒有交代收錄門檻是什麼。對照之下，Holistic Evaluation of Language Models 這類被廣泛引用的工作，和一篇單一任務的初步研究，在清單裡以相同的格式並列。這不代表收錄有問題，而是說使用者必須自己判斷每條的份量，清單不會幫你排序。
第三個弱點是它與論文之間的關係是單向的。倉庫說論文之後可能更新，但沒有給出更新週期或版本對應關係。如果你在論文中引用某個分類，再回到倉庫對照，兩者的條目可能已經不一致。要用它做正式引用時，應該以 arXiv 上的論文版本為準，倉庫當成補充。
跟 LiveBench、HELM 這類可執行評測框架的差別
把這個倉庫跟 HELM 或 LiveBench 放在一起比較，差別不在功能多寡，而在產物型態。HELM 是一套評測框架，會定義場景與指標、跑模型、產出可比較的結果表，它的 README 給的是安裝與執行指令。LLM-eval-survey 給的是論文的連結清單，執行結果不在它的範圍內。
這個差別決定了兩者的使用時機。當你要回答「我的模型在情感分析上表現如何」，你需要的是 HELM 這類能跑出數字的工具，或 README 提到的 microsoft/promptbench。當你要回答「情感分析這個任務，學界目前用哪些資料集與什麼指標在評」，這個倉庫才是對的入口。
值得注意的是，這個倉庫的分類架構本身可以當成挑選評測框架的檢查表。HELM 覆蓋了哪些維度、漏掉哪些，對照 What to evaluate 的樹狀結構就能看出缺口。這種用法不需要倉庫提供任何程式碼，只需要它的分類。這也是我認為它對工程團隊最實際的價值：不是給你答案，是給你一份問題清單。
誰該用、誰不該用，以及先查什麼
適用的人有三類。正在撰寫 LLM 評測相關論文或技術報告的研究者，可以用它做文獻回顧的起點。要為團隊設計內部評測方案的人，可以用它的分類確認自己有沒有漏掉某個維度，例如社會科學或 Agent 應用這兩個容易被忽略的分支。需要向非技術同事解釋 LLM 評測版圖的人，這份樹狀目錄比任何一張自製圖表都有依據。
不適用的人同樣清楚。想要現成 benchmark 程式碼或資料集的人，這裡沒有。需要一份去重、附帶品質評分、可程式化查詢的結構化資料的人，這個倉庫的格式不支援，你得自己解析 Markdown。需要保證收錄完整性的團隊也不適合，因為它的更新依賴外部提交。
決定採用前，先確認 LICENSE 檔案是否真的存在，這決定你能不能把清單內容搬進自己的文件或產品。再確認 News and updates 的最新一筆是什麼時候，這是你判斷整份清單新鮮度的唯一線索。最後，直接點進你最關心的那個小節，看它最近收錄的論文年份分布，如果多數停在 2023 年，就把它當成一份歷史座標而不是現況索引來用。
編輯結論
如果你需要的是在動筆寫評測方案前，先確認某個能力維度上已經有哪些工作、別人的評測設計長什麼樣，這個倉庫可以直接用，從 What to evaluate 的分類一路點進 arXiv 或 ACL 的原文即可。如果你要的是能跑出分數的程式，這裡沒有，README 只把 microsoft/promptbench 列為相關專案，實際的評測執行要另外去找。採用前先確認三件事：倉庫的 LICENSE 檔案是否存在、News and updates 是否仍反映最新一版 arXiv 論文、以及你要用的那個小節（例如 Agent applications 或 Medical applications）收錄的論文是否還在更新，因為這份清單的價值完全取決於它跟不跟得上新論文。
社群筆記