圖1。 Copilot Arena是一種VSCODE擴展，直接從開發人員那裡收集了人類的代碼偏好。
韋恩·奇（Wayne Chi），瓦萊麗·陳（Valerie Chen），克里斯·多納休（Chris Donahue），ameet talwalkar
隨著模型功能的提高，大型語言模型（LLM）越來越多地集成到用戶環境和工作流中。特別是，軟件開發人員在集成開發環境（例如VS代碼，Intellij或Eclipse）中使用LLM供電工具代碼。儘管這些工具越來越多地用於實踐中，但當前的LLM評估努力捕獲用戶如何在真實環境中與這些工具進行交互，因為它們通常僅限於簡短的用戶研究，只考慮簡單的編程任務而不是現實世界中的系統，或依靠從開發環境中刪除的基於Web的平台。
為了解決這些限制，我們介紹了Copilot Arena，該應用程序旨在通過直接在開發人員的實際工作流程中收集偏好來評估現實世界中的LLM。 Copilot Arena是一個Visual Studio代碼擴展程序，可為開發人員提供代碼完成，類似於GitHub Copilot提供的支持類型。到目前為止，超過11,000名用戶已下載了Copilot Arena，該工具已經完成了100,000多個完成，並積累了25,000多個代碼完成戰。戰斗在LMARENA網站上形成了現場排行榜。自推出以來，Copilot Arena還被用於評估兩種新的代碼完成模型：Mistral AI和InceptionAi的Mercury Coder的新型Codestral模型。
在這篇博客文章中，我們討論了我們如何設計和部署的副競技場。我們還強調了Copilot Arena如何為開發人員代碼偏好提供新的見解。
副駕駛競技場系統設計
為了收集用戶偏好，副柯特競技場展示了一本小說 介面 這顯示了用戶配對的代碼完成來自兩個不同LLM的代碼完成，這是根據一個 抽樣策略 這可以減輕延遲，同時在模型比較中保留覆蓋範圍。此外，我們設計了 提示方案 這允許各種模型以高保真度執行代碼完成。圖1概述了此工作流程。我們將概述以下每個組件：
使用者介面: Copilot Arena允許用戶在不同LLM的代碼完成對之間進行選擇。用戶選擇使我們能夠更好地了解LLMS之間的開發人員偏好。為避免中斷用戶工作流，投票旨在無縫 – 用戶使用鍵盤快捷鍵來快速接受代碼完成。
採樣模型對： 我們探索 採樣策略，以最大程度地減少經驗豐富的延遲。由於我們的界面一起顯示了兩個代碼完成，因此最慢的完成確定了延遲。我們將每個模型的延遲捕獲為對數正態分佈，並調整溫度參數，以在延遲優化的分佈和均勻分佈之間插值，觀察到中位數的潛伏期減少33％（從1.61秒至1.07秒），與統一分佈相比。
提示完成代碼： 在開發過程中，模型需要“填寫中間”，其中需要根據當前前綴和後綴生成代碼。雖然某些模型（例如DeepSeek和Codestral）旨在填充中間，但許多聊天模型卻沒有並且需要其他提示。為此，我們允許該模型生成更自然的代碼段，然後將其後處理為FIM完成。我們的方法如下：除了上面的同一提示模板外，還提供了指令，以重新輸入前綴的一部分，並以後綴的一部分結束。然後，我們在輸入中匹配輸出代碼的部分並刪除重複的代碼。這個簡單的提示技巧允許聊天模型以很高的成功執行代碼完成（圖2）。
部署
我們將Copilot Arena部署為VSCODE擴展商店中可用的免費擴展名。在部署期間，我們記錄了用戶判斷和模型響應的延遲，以及用戶的輸入和完成。鑑於編程的敏感性，用戶可以限制我們對數據的訪問。根據隱私設置，我們還收集了用戶的代碼上下文和模型響應。
根據成對偏好評估的其他工作（例如聊天機器人領域）的標準，我們應用Bradley-Terry（BT）模型來估計每個模型的相對強度。我們引導BT計算中的戰鬥，以構建排名的95％置信區間，該排名用於創建一個排名所有模型的排行榜，其中每個模型的級別都由其他模型的下限降低到其上限以下。我們在lmarena.ai主持了模型排名的實時領先地板（圖3）。
發現
與先驗數據集進行比較
我們將排行榜與現有評估進行比較，後者涵蓋了具有人為反饋和靜態基準測試的實時偏好排行榜（圖4）。我們比較的靜態基準是LiveBench，BigCodebench和LiveCodeBench，它們在各種Python任務上評估了模型的代碼生成能力，並繼續使用新的模型版本來維護。我們還將聊天機器人競技場及其特定於編碼的子集進行比較，這些子集是通過網絡平台收集的聊天響應的人類偏好。
我們發現與大多數靜態基準相關性（r≤0.1）的低相關性（r≤0.1），但與聊天機器人體育館（編碼）（編碼）（r = 0.48）的相關相關性（Spearman的等級相關性（R）為0.62）（r）為0.62）（r = 0.48）。與靜態基準相比，與人類偏好評估的更強相關性可能表明，人類反饋捕獲了靜態基準無法測量的模型性能的不同方面。我們注意到，較小的模型傾向於表現過大（例如，GPT-4O MINI和QWEN-2.5-編碼32B），尤其是在靜態基準中。我們將這些差異歸因於Copilot Arena評估的數據和任務的唯一分佈，接下來我們會更詳細地探索。
與先前的方法相比，評估實際用戶工作流程中的模型會導致編程和自然語言，任務和代碼結構的多種數據分佈（圖5）：
- 編程和自然語言： 雖然多數副競技場用戶用英語（36％）和python（49％）撰寫，但我們還確定了24種不同的自然語言和103種編程語言，這些語言與Chatbot Arena（一般）和基準相當，而基準則集中在多種方面。相比之下，靜態基準傾向於專注於僅以Python和英語編寫的問題。
- 下游任務： 現有的基準傾向於從編碼競爭，手寫編程挑戰或策劃的GitHub存儲庫中提出問題。相比之下，Copilot Arena用戶正在處理各種現實的任務，包括但不限於前端組件，後端邏輯和ML管道。
- 代碼結構和上下文長度： 大多數編碼基準都遵循特定的結構，這意味著大多數基準測試的上下文長度相對較短。同樣，聊天機器人競技場重點介紹從聊天對話中收集的自然語言輸入，許多提示不包括任何代碼上下文（例如，聊天機器人體育館的40％的編碼任務包含代碼上下文，只有2.6％的專注於填充）。與任何現有的評估不同，副副競技場在結構上是多樣的，投入時間更長。
洞悉用戶偏好
- 下游任務顯著影響獲勝率，而編程語言幾乎沒有影響： 更改任務類型會顯著影響相對模型性能，這可能表明某些模型過度暴露於競爭風格的算法編碼問題。另一方面，編程語言對贏率的影響非常小，這意味著在Python上表現良好的模型可能會在另一種語言上表現良好。我們假設這是因為編程語言之間的固有相似性，而學習可以提高另一種性能，與先前的工作中報導的趨勢保持一致。
- 較小的模型可能會超越類似於靜態基準的數據，而較大模型的性能則混合在一起： 現有的基準（例如，圖4中的基準）主要評估有關python算法問題的模型。但是，我們注意到QWEN-2.5編碼器在前端/後端任務，較長的上下文和非Python設置上的表現明顯更糟。我們觀察到其他兩個小型模型（Gemini Flash和GPT-4O Mini）的類似趨勢。我們假設過度暴露可能對較小的模型尤其有問題。另一方面，大型模型之間的性能混合在一起。
結論
儘管Copilot Arena代表了LLM評估的正確方向的轉變，提供了更多的紮根和現實的評估，但仍有重要的工作要做，以完全代表所有開發人員的工作流程。例如，擴展Copilot Arena以說明與GitHub Copilot（例如Github Copilot）的界面差異以及限制數據共享的隱私注意事項。儘管有這些限制，但我們的平台揭示了在現實環境中評估編碼LLMS的排名與靜態基准或基於聊天的評估明顯不同，並突出了針對真實任務測試AI助手的重要性。我們已經開源的副駕駛競技場鼓勵開源社區包括更多細微的反饋機制，代碼軌跡指標和其他交互模式。
如果您認為此博客文章對您的工作很有用，請考慮引用它。
@misc{chi2025copilotarenaplatformcode,
title={Copilot Arena: A Platform for Code LLM Evaluation in the Wild},
author={Wayne Chi and Valerie Chen and Anastasios Nikolas Angelopoulos and Wei-Lin Chiang and Aditya Mittal and Naman Jain and Tianjun Zhang and Ion Stoica and Chris Donahue and Ameet Talwalkar},
year={2025},
eprint={2502.09328},
archivePrefix={arXiv},
primaryClass={cs.SE},
url={https://arxiv.org/abs/2502.09328},
}本文最初發表在ML@cmu博客上，並在作者的許可下出現在此處。
標籤：深水潛水
ml@cmu
