科技

AI 寫碼一時爽，代碼審查火葬場？GitHub Copilot 副總揭秘新瓶頸 | GTC 2025

03月31日 14:55 新浪網 tech-auto-hilite

我們距離 AI 在絕大多數軟件開發任務中實現人類水平的能力和自主性大約還有 24 到 36 個月的時間。

責編 | 王啟隆

主持人：大家好，我是 NVIDIA 開發者工具 AI 技術軟件工程總監，馬特·費爾澤（Matt Frazier）。

眾所周知，AI 輔助開發者工具，或者說代碼生成、AI 代碼生成——現在有很多叫法——正在從根本上改變我們開發軟件的方式。NVIDIA 自然非常關注這一趨勢如何影響我們處理軟件和加速計算的方法。

為此，在 GTC 2025（英偉達大會）上，我們邀請了來自多家公司和不同行業的 AI 代碼生成通用應用專家，以及 CUDA 優化與相關研究領域的專家，共同探討這個話題。

我想快速問各位讀者幾個問題：

有多少人特別在 CUDA 調試中使用過 AI 驅動的代碼工具？
大約有多少人遇到過 CUDA 性能問題，並且花了超過一天的時間來解決？
有沒有人嘗試過將這兩者結合，把 AI 代碼生成應用於你們的 CUDA 問題？有人成功過嗎？
有多少人的代碼庫，特別是 CUDA 代碼庫，規模超過了大約一萬行？
接下來是大家可能最關心的問題。在使用 AI 代碼生成工具時，你們遇到的最大挑戰是什麼？是準確性，還是生成速度？
如果你正在用 CUDA 編寫加速代碼，你會選用 C++ 還是 Python？或者兩者都用？

如果你對以上任何一個問題感同身受或感到好奇，那麼接下來的討論就值得你關注。下面，我想介紹一下參與本次討論的嘉賓。

莎娜·達馬尼（Sana Damani），她是 NVIDIA 架構研究組的研究科學家，致力於提升 GPU 上並行應用程序的性能，以及提高調試和優化工作的易用性。

妮哈·馬斯巴查（Neha Batra），GitHub Copilot 的工程副總裁，她領導的核心生產力組織，專注於貫穿整個軟件開發生命週期（SDLC）的工具以及開發者的日常工作流程。她尤其關注 AI 編碼助手如何從領導大型團隊和產品項目的視角出發，變革開發者的工作流程。

艾蘭·亞哈夫（Eran Yahav），他是 AI 編碼助手公司 Tabnine 的 CTO，同時也是以色列理工學院（Technion）的計算機科學教授，主要研究方向是代碼機器學習和程序綜合——此外，他還是一位運動員。

伊索·康德（Eiso Kant），Poolside 的創始人，他是一位工程師，在 AI 和開發者工具領域擁有十餘年創辦初創公司的經驗。在創立 Poolside 之前，伊索曾是 Athenian 和 source{d} 的創始人兼 CEO。

最後是阿比納夫·畢特勒（Abhinav Bhatele），他是馬里蘭大學帕加分校計算機科學系的副教授，兼任並行軟件與系統組主任。他的研究重點是用於大規模訓練、微調大語言模型（LLM）以完成編碼任務（如並行代碼生成）的基礎設施。

接下來，我想先從莎娜開始提問。你的研究工作似乎正好處於 AI 和 GPU 性能的交叉點。根據你的研究，你在提高 CUDA 性能方面遇到了哪些主要挑戰？你又採用了哪些方法來應對？

莎娜（NVIDIA）：這是個很好的問題。嘗試過 CUDA 編程的人可能都瞭解，GPU 雖然能提供驚人的計算性能，但要充分挖掘其潛力並非易事。開發者需要付出大量努力，深入理解從算法、CUDA 特性、編譯器選項、各種工具一直到 GPU 架構等多個層面，才能真正掌握其工作原理。因此，即便具備了這些專業知識，逐步定位並解決性能瓶頸、優化代碼，依然需要投入大量的手動工作。

我們正在探索 AI 在這方面提供幫助的可能性，目前有幾個相關的研究項目。第一個項目名為 Nsight Copilot，它已經集成到 NCU 分析器中，大家可以在 GTC 的開發者工具展位觀看演示。這是一個 AI 助手，能夠幫助識別 CUDA 程序中的性能瓶頸，甚至就如何解決這些瓶頸提供優化建議。這是我們的第一個項目。

第二個項目名為 WarpDrive，這個項目更具實驗性質，我們去年在 NeurIPS 會議上進行了展示。它是一個 AI 智能體解決方案，目標是自動化 CUDA 性能調優的完整流程，涵蓋從性能分析、識別恰當的優化策略、執行代碼轉換，到最終測試等各個環節。當然，這個領域仍然面臨諸多挑戰，尤其是在驗證生成代碼的正確性方面。

但總的來說，通過這兩個項目，我們的目標不僅是減少 GPU 性能調優所需的人力投入，更是要讓不同水平的開發者都能更輕鬆地利用 GPU 的強大性能，而不僅僅局限於那些頂尖的專家。

主持人：阿比納夫，你的研究方向與莎娜有相似之處。你如何看待她提到的這些挑戰？特別是在處理更大規模的代碼庫和並行性方面，你正在進行哪些工作？

阿比納夫（馬里蘭大學）：正如大家可能意識到的，使用 AI 工具仍然面臨著嚴峻的挑戰。我想具體指出幾個問題。首先，我們正在研究的是整個程序的翻譯。這意味著，我們能否超越像 GitHub Copilot 這樣的輔助工具，直接讓 AI 處理整個源代碼庫？對於生產級別的代碼，這可能涉及數萬行代碼，並且這些代碼通常分佈在多個文件和目錄中。我們希望 AI 工具能夠優化這樣的代碼庫，或者將其從一種並行模型（如 OpenMP）轉換到另一種（如 CUDA），或者從 CUDA 轉換到 HIP 等其他平台。

這方面存在著重大的挑戰。其中一些挑戰包括：首先，當前的 AI 工具難以充分理解項目的目錄結構、文件組織方式以及它們之間的複雜依賴關係。另一個值得關注的問題是構建系統（無論是 CMake 還是 makefile）。如果 AI 工具生成了新文件或重命名了現有文件，它在自動修正構建系統以適應這些變化方面表現不佳。這看似是一個工程上的細節問題，但實際上是一個非常現實的障礙。因此，如何讓 AI 工具在生成正確代碼的同時，也能生成或更新配套的、能夠正常工作的構建系統，是一個亟待解決的問題。

主持人：所以，這既是一個通用的編碼 AI 問題——即管理構建過程、makefile 和文件結構，同時又是一個非常具體的問題，因為這對於 CUDA 和加速編程來說尤其重要。各位嘉賓在處理這種更普遍的問題時，能分享哪些業界的相關進展？

伊索（Poolside）：文件結構的問題本身可能不會持續存在太久。但是，談到構建系統以及 CUDA 優化或任何加速計算的優化，我們目前推動基礎模型前沿發展的主要方式，是通過強化學習讓模型在真實的軟件開發環境中進行學習。

舉例來說明我們公司正在做的工作：我們在一個強化學習環境中運行了超過一百萬個完全容器化的 GitHub 項目，這些項目包含了數千萬次的修訂記錄。我們讓模型在這些真實環境中執行各種開發任務，然後實際運行項目自帶的測試以及我們設置的其他驗證檢查，以此來反饋和改進模型。

然而，我們目前還沒有專門針對加速計算進行此類強化學習訓練，原因其實很簡單：當我們運行一百萬個代碼倉庫並執行數十億次強化學習任務時，每月在常規計算資源上的花費大約是 1000 萬美元。如果我們要設定一個與提升 CUDA 性能相關的強化學習目標，那麼我們就必須運行極其龐大數量的 GPU 實例——這些 GPU 不是用於模型訓練或推理，而是用於執行模型在學習過程中嘗試完成的任務本身（例如，編譯和運行 CUDA 代碼以獲取性能反饋）。因此，在我們決定將大量計算資源專門投入到針對加速計算領域的強化學習循環之前，許多相關的模型能力改進將難以實現。

但有趣的是，CUDA 優化實際上是一個非常適合強化學習的問題，因為其目標非常明確：我們通常是在嘗試改進性能分析器（profiler）報告中的某些具體數值。我們非常清楚優化的目標是什麼。相比於那些需要模型改進其通用推理和思維過程以提升整體編碼能力的更寬泛任務，針對 CUDA 優化的學習目標要明確和容易衡量得多。因此，我們最終會涉足這個領域，但這目前僅僅是基礎模型研發層面（包括我們自己，以及 Anthropic 和 OpenAI 等其他機構）尚未將資源重點投入到這些特定優化環境中的一個暫時性限制。

艾蘭（Tabnine）：將強化學習應用於 CUDA 優化這類任務的部分挑戰還在於正確性驗證。對 CUDA 代碼進行測試本身就非常困難，僅僅是為 CUDA 內核運行測試並確保其計算結果正確，就已經相當具有挑戰性。你需要有效控制併發執行，並確保對不同的執行交錯（execution interleavings）有良好的測試覆蓋率。因此，為這些涉及併發和同步的工作負載設計並執行充分的正確性測試，本身就是一個巨大的難題，這還僅僅是為了驗證代碼的功能正確性，尚未涉及性能。

妮哈（GitHub）：在 GitHub，當涉及到需要跨越整個代碼庫進行更改時，我們傾向於關注完整的端到端流程。我們目前正在進行的一項工作是擴展 AI 工具能夠處理的上下文窗口大小，以及它們能夠進行全局性操作的能力範圍。例如，Copilot 的編輯功能現在已經能夠跨越單個區域、頁面或文件，實現跨多個文件的更改。我們在這方面正在取得進展。

我們特別關注的一個研究領域是，識別那些適合在整個代碼庫範圍內進行的更改類型。例如，如果要實施一項安全改進，需要修改或檢查哪些不同的文件？如果要進行可訪問性方面的改進，又需要涉及哪些類型的文件？以及我們如何能夠更系統化地處理這些跨文件的操作？我們正在研究那些可以通過 AI 進行全局性處理的問題類別。

主持人：我聽伊索特別提到了強化學習以及使用 GPU 的成本問題。還有一個普遍的問題是硬件支持的多樣性。在加速計算領域，有很多硬件版本和 CUDA 版本需要支持。

我很好奇，想先問問阿比納夫，在大規模維護 CUDA 代碼質量方面，哪些非 AI 技術被證明是最有效的？以及當需要進行性能測試時，你如何管理那個包含硬件、CUDA 版本和所有其他依賴項的龐大組合矩陣？

阿比納夫（馬里蘭大學）：傳統上，在不使用 AI 工具的情況下，維護 CUDA 代碼質量涉及大量的手動工作：例如編寫單元測試、回歸測試、設置和維護夜間構建流程等等。雖然其中部分流程可以實現自動化，但最終程序員仍需編寫大量的測試代碼。未來，部分這類工作或許可以進一步自動化。例如，我們可以利用 AI 工具進行自動化的代碼評審（PR review），或者自動生成更多的測試用例。在這些方面，AI 工具有望提供幫助。目前，程序員確實承擔著巨大的手動工作量，而引入 AI 工具有望減輕這種負擔。

妮哈（GitHub）：我想補充一點：代碼創建、測試編寫和代碼審查是軟件開發中的三個關鍵環節。這三者對於提高代碼質量、確保最終產品符合預期都至關重要。具體在哪些環節實現自動化、減輕哪些負擔、側重於哪些方面，往往取決於不同公司的具體需求和策略。讓所有這三個環節完全由 AI 自動化，我認為風險相當大，但利用 AI 進行輔助則非常有價值。

我特別關注的領域之一是 Copilot 代碼審查功能，即探索如何讓 AI 輔助進行初步的代碼審查。另一個領域是測試生成，AI 在生成單元測試方面表現得相當不錯。但當涉及到端到端測試時，正如艾蘭之前提到的，你需要確保自己真正理解成功的標準是什麼、期望的結果是什麼、以及需要特別注意哪些方面，因為這些都需要在委託 AI 執行任務時明確指定。

否則，這就像進行結對編程：你將代碼交給另一個人，他們進行了一些修改，你必須確保這些修改通過了預定的測試標準。如果你不清楚測試標準是什麼，驗證就會變得非常困難。因此，雖然 AI 在單元測試生成方面潛力巨大，但在端到端測試方面，我們還需要進一步探索和改進與 AI 協作的方式。

主持人：伊索，你們是如何考慮這種端到端問題的？我知道在內部的強化學習訓練中，這是一個核心部分。但是當用戶實際使用時呢？在軟件開發生命週期（SDLC）中，你還看到了哪些自動化可以發揮作用的地方？

伊索（Poolside）：這個領域最初是從代碼補全功能開始的，隨後發展到基於聊天的交互模式，而當前最新的趨勢是朝著智能體（Agent）的方向發展。但許多人可能尚未完全意識到的是，基礎模型的改進速度非常之快，以至於從我們的視角來看，實現具備真正自主行動能力的 AI 系統——也就是能夠端到端完成任務的環境——已經為期不遠。這意味著 AI 將能夠執行完整的端到端操作：從自動解決構建錯誤，到獨立執行大型、複雜的多步驟開發任務，最終交付一個已經完成或準備好供人工審查的成果。

在我們看來，大約再過 24 到 36 個月，AI 就有可能在絕大多數軟件開發任務中達到接近人類水平的能力和自主性。當然，屆時仍然會存在差距，例如在特定領域的系統知識、實際項目經驗等方面，以及在模型尚未充分學習和實踐過的任務上。但這預示著，我們很快將不再僅僅把這些 AI 工具視為屏幕右側的聊天助手或集成在 SDLC 中的某個 API。我們會更多地將它們看作是具備一定自主能力的實體——一個能夠在較長時間跨度內持續行動、能夠操作我們整個開發環境（從控制瀏覽器打開 AWS 控制台，到使用終端、編輯器，乃至操作各種開發工具）的智能體。雖然這還不是我們今天的現實，但認識到這一發展趨勢至關重要。

回想起來，如果是在 2016 年，我們都剛進入這個行業時你問我這個問題，我可能會說，這或許需要 30 年才能實現。如果是在兩年前我創辦這家公司時問我，我大概會說 5 到 10 年。而現在你問我這個問題，我的預測是 24 個月、30 個月、36 個月——這個時間範圍變得非常具體了。這一點值得我們注意。隨著 AI 能力的指數級增長，它的形態和應用方式將發生巨大變化，從簡單的編輯器助手演變為更具自主性的智能體。這種轉變將有望解決我們目前關心的許多關於端到端自動化能力的問題。

艾蘭（Tabnine）：我想立即就此提出一點不同的看法。端到端的自動化能力或許會實現，但其中存在一個我們目前可能有所低估的關鍵差距，那就是信任問題。我們如何能夠信任一個 AI 智能體交付的結果？我個人是絕對不會願意坐下來審查由智能體生成的 3 萬行代碼（尤其是審查複雜的 CUDA 代碼）。

我們已經觀察到，在 AI 驅動的軟件開發生命週期（SDLC）中，瓶頸正在從代碼生成轉向代碼審查。生成大量代碼變得非常容易，但我們無法確定這些生成的代碼是會累積成技術債務，還是可以真正信任並集成到項目中的高質量代碼。

這涉及到幾個關鍵點：首先是 AI 需要理解整個現有的代碼庫，確保生成的內容與組織內已有的代碼、庫和規範兼容。其次，需要有某種機制來控制生成過程，確保產出的代碼在一定程度上遵循團隊的最佳實踐和編碼標準。而這些僅僅是挑戰的開始。正如妮哈提到的，我們需要明確的規範和標準：由誰來負責審查這些 AI 生成的代碼？對於這 3 萬行代碼，其正確性的基準（ground truth）又是什麼？

伊索（Poolside）：請允許我稍微回應一下。我們之所以信任我們的同事和團隊成員，是因為他們通過過往的工作證明了自己具備完成特定任務的能力。而目前，我們確實不應該完全信任 AI，因為它在執行多步驟任務時，存在準確性逐級累積下降的問題。如果一個模型在單步操作上的正確率是 70% 或 80%，那麼讓它連續執行六七個步驟後，最終結果中錯誤累積的概率就會非常高。

但是，當未來我們開始擁有能力足夠強大的 AI 系統和模型，並且我們能夠持續觀察到它們的產出質量達到了與我們組織中值得信賴的人類同事難以區分的水平時，那麼信任問題將在很大程度上自然緩解。因此，我們或許並不需要刻意去「解決」信任問題本身，而是要關注於提升 AI 的能力和可靠性。

當然，在現階段，我們必須維持現有的軟件開發生命週期（SDLC）、代碼審查流程以及其他成熟的工程實踐。例如，我目前並不建議用戶通過 API 調用我們的模型來執行全局性的代碼重構，我甚至會明確建議我們的客戶不要這樣做。這有點像我們有時會看到一些開發者為代碼倉庫自動提交大量單元測試的 Pull Request——這可能並非當前技術下最恰當的應用方式。

我們確實觀察到一些對當前 AI 技術能力的不當使用或期望過高的情況。但我認為，這是一個隨著技術進步會逐漸得到解決的問題。可以將其類比為——我傾向於用擬人化的方式來思考——你目前面對的是一個還不能完全信任的初級實習生。但隨著這位「實習生」能力的提升，最終成長為團隊中值得信賴的高級開發人員時，我們現有的協作和驗證體系就能夠有效地處理信任相關的問題了。

主持人：我想請妮哈接著這個話題討論，因為妮哈之前也提到了開發者角色將如何演變，即思考使用 AI 的開發者如何承擔新的角色。

妮哈（GitHub）：「智能體」（Agent）無疑是未來幾年的熱門概念和重要發展趨勢。它本質上描繪了一種場景：我們可以將任務分配給 AI，然後暫時離開，待任務完成後再回來檢查結果。有趣的是，作為一個從工程師轉變為管理者的人，我深知「授權」是一項關鍵的管理技能。而現在，我們實際上是在嘗試學習如何清晰地定義一個任務，並將其有效地「委託」給一個 AI 智能體，無論是通過聊天界面還是其他交互方式。我們需要找到更優化的方法，將 AI 無縫地嵌入到我們的工作流程中，讓它在真正有價值的環節發揮作用。

例如，設想未來你可以直接將一個 GitHub Issue 分配給 Copilot，然後在流程的另一端獲得一個相應的 Pull Request。這是我們努力的方向之一。當思考這對我們開發者技能組合的影響時，一方面，我們需要提升理解並清晰定義需求的能力。如果一個問題或任務被準確地描述出來，那麼 AI 就更有可能生成符合預期的結果。這最終還是回歸到我們軟件開發的根本目標：創建有用的功能，為用戶解決實際問題，修復軟件缺陷。

另一方面，審查能力變得愈發重要。如果我們越來越多地依賴 AI 進行代碼生成，那麼可被創建的代碼量會增加，相應地，需要被審查的代碼量也會增加。因此，我們必須提升自身的代碼審查技能。雖然可以讓 AI 輔助進行初步審查，但最終的判斷仍然需要人來完成：這段代碼是否有意義？它是否真正解決了我們想要解決的問題？我希望我們始終能回歸到這個核心問題上來進行評估。

主持人：伊索剛才提到需要理解我們的意圖、完整的開發生命週期以及最終目標，這聽起來與產品需求文檔（PRD）或詳細設計規範有相似之處。那麼艾蘭，你對於利用這類更結構化的輸入（比如計劃或規範文檔），甚至從這些文檔出發來指導 AI 執行任務（而不僅僅是生成代碼片段），例如讓 AI 根據計劃生成集成測試、單元測試等，有什麼看法？

艾蘭（Tabnine）：我想從一個更根本的層面來看待這個問題。信任的挑戰在短期內難以完全消除，因為目前我們很大程度上依賴人類的判斷。即使我們將任務外包給人類，我們也是在依賴他們的常識、經驗和判斷力——這些人通常已經融入了組織的文化，瞭解我們的工作方式和偏好，並且擅長從不完全明確的規範中推斷出隱含的需求。

現實中，規範幾乎永遠是不充分的。我們不可能編寫一份長達一萬頁的 PRD 來詳盡說明如何構建一個應用程序的每一個細節。幾乎所有的開發工作都是基於不充分的規範進行的，而將這些不充分的規範具體化為實際代碼的過程，目前很大程度上依賴於人類開發者的理解和判斷。

這正是當前開發流程能夠有效運作的原因之一。你通常不會給初級開發人員一份極其詳盡的 PRD，而是會給出相對高層次的指令，比如「我需要在這裏添加一個按鈕」，然後期望他們能夠根據上下文進行合理的推斷和實現。在我們擁有能夠被充分信任、並且能夠準確推斷我們高層次意圖的 AI 之前，信任問題將持續存在。

再次強調，我們觀察到的現像是，AI 驅動開發的瓶頸正顯著地轉移到代碼審查環節。這對在座的各位可能都有體會。我們實際上看到了一種類似「分佈式拒絕服務攻擊」（DDoS）的效應：代碼生成者（可能是一些經驗不足、傾向於直接接受 AI 建議的初級開發者）產生了大量的代碼，湧向負責審查的高級工程師，使得後者的審查負擔可能比以前增加了百倍。這些高級工程師疲於應對，竭力確保湧入的代碼不會引入問題，不會破壞代碼庫的穩定性。這是我對信任問題的一個普遍觀察。將這些 AI 「助手」或「員工」引入組織的挑戰，核心在於如何使它們變得足夠值得信賴。我們最終會達到那個目標，但這需要一個過程，需要我們找到方法將 AI 的可靠性提升到等同於值得信賴的人類員工的水平。

主持人：談到引入 AI 「員工」——我剛加入 NVIDIA 時，CUDA 經驗也並不豐富。這讓我思考，我們如何讓 AI 系統，特別是當它們更深入地集成到 SDLC 中、我們對其依賴程度越來越高時，獲得必要的領域知識？這既包括為了建立信任而進行的某種形式的「入職培訓」，也包括如何讓 AI 在那些專業知識要求高、或者可用訓練數據相對稀疏的新領域（如 CUDA）中表現良好？

你們認為需要哪些關鍵要素或資源，才能幫助 AI 在像 CUDA 這樣數據相對稀疏的編程領域做得更好？一旦我們擁有了這些要素，又該如何將它們有效地集成到現有的 AI 解決方案中，而無需每次都從頭開始訓練或構建？

莎娜（NVIDIA）：對於 CUDA 編程，尤其是高度優化的 CUDA 代碼，公開可用的高質量示例確實相對較少。因此，一個關鍵的要素是能夠系統地收集這些寶貴的知識，特別是如果我們能從 NVIDIA 內部的庫開發者或 DevTech 工程師那裡獲取——他們擁有深厚的專業技能和編寫得非常出色的 CUDA 代碼實例。

如果我們能夠利用這些高質量的代碼構建一個專門的知識庫，那麼我們就可以將其用於強化學習、模型微調，或者直接作為高質量的示例（few-shot examples）提供給 AI 智能體。這將是一種非常有價值的方法。即使在我們 WarpDrive 項目的探索中，我們的目標也不僅僅是應用已知的、有大量數據的優化技術。

更具挑戰的是，當你提出一種新的代碼轉換方法，但在缺乏足夠訓練數據的情況下，如何讓 AI 能夠自動地將這種新方法應用於各種不同的 CUDA 內核。我們當時嘗試的方法是通過提供明確的指令，將複雜的轉換任務分解成更小的、可管理的步驟，並設計一個引導 AI 執行這些步驟的流程來實現。我個人傾向於從編譯器的視角來思考這類問題。總而言之，我們正在探索的途徑包括：獲取高質量的示例代碼，然後研究如何將其有效地分解和表述，以便 AI 能夠理解和學習。

阿比納夫（馬里蘭大學）：我先快速回應一下關於信任的問題，儘量簡短。特別是在科學計算領域——我相信在工業界的生產級軟件開發中同樣如此——確保代碼的正確性是至關重要的。通常，科學計算團隊中既有物理學家也有計算機科學家，有時物理學家甚至對計算機科學家編寫的代碼也持謹慎態度，他們傾向於親自進行驗證和測試。

主持人：他們所處的領域確實要求極高的嚴謹性，不能輕易信任。

阿比納夫（馬里蘭大學）：確實如此。如果你正在研究像高超音速飛行、火星探測器著陸，或者利用分子動力學進行藥物設計這樣的複雜問題，那麼在進行任何後續工作之前，你都必須絕對確保你的模擬代碼是正確的。

因此，我同樣認為信任問題在短期內不會消失，這是一個非常現實且重要的問題。回到 CUDA 和其他加速計算軟件的話題上，我同意莎娜的觀點，一個核心挑戰在於缺乏足夠的高質量數據來有效訓練或微調 AI 模型。

特別是在科學計算領域，存在大量使用 Fortran 或 Fortran 結合 MPI 編寫的遺留代碼。這些語言和編程模型都屬於典型的「低資源」（low-resource）場景，意味著可用於訓練 AI 的公開代碼數據非常有限。在這種情況下，如何確保 AI 能夠生成高質量、高性能的代碼就成了一個嚴峻的挑戰——因為沒有足夠的數據，模型的生成效果自然會受限。目前，研究人員正在探索合成數據生成技術來緩解這個問題。例如，伊利諾伊大學厄巴納-香檳分校（UIUC）有一篇名為 Magicoder 的論文在這方面取得了一些進展，但它尚未完全解決問題，特別是對於那些數據極其稀缺的語言。因此，這確實是一個亟待解決的難題。

https://arxiv.org/pdf/2312.02120

這篇論文也有清華學子的身影

主持人：那麼，對於更大規模的代碼生成工具來說，你們如何處理數據稀疏的問題？

伊索（Poolside）：我可以談談合成數據（synthetic data）這個概念。在我們目前從頭開始訓練的基礎模型中，已經有大約 25% 的訓練數據是合成生成的。

我們的預測是，在未來 12 到 18 個月內，我們用於訓練模型的數據中，合成數據的比例可能會高達 90%。但這其中有一個非常關鍵的前提，這也呼應了莎娜剛才提到的觀點：有效的合成數據生成，必須基於少量但質量極高的「基準真相」（ground truth）數據。

打個比方：假設我找到一位沒有 CUDA 背景，但具備很強推理能力和紮實 C++ 基礎的優秀軟件工程師，然後讓他去處理一個複雜的 CUDA 任務。雖然我本人並非來自科學計算背景，但我們公司內部為了優化模型訓練和推理代碼，也編寫了大量的 CUDA 代碼。假設任務是優化一個注意力（attention）機制的 CUDA 內核。為了幫助這位工程師學習，我需要提供給他高質量的 API 文檔、清晰的示例代碼，以及任何能夠簡化學習過程的資源（就像一本好的教科書），並假設他有足夠的時間（可能需要很長時間，比如數年，去解決一個 CUDA 專家半天就能搞掂的問題）。

關鍵在於，如果存在可供學習的高質量基準真相數據，那麼以此為起點，我們實際上可以通過模型自身的推理能力，結合強化學習以及我們使用的一系列其他技術，來綜合生成和推斷出大量的相關知識和代碼模式。但是，明確哪些是可靠的真實樣本、哪些是模型需要通過探索來學習的內容，這一點至關重要。因為一旦有了這個堅實的基礎，我們就可以引導模型進行類似人類開發者的「體驗式學習」：讓模型去嘗試不同的方法，運用其推理能力，在實踐中學習哪些嘗試是有效的（做對了），哪些是無效的（做錯了）。

然而，如果缺乏高質量的基準真相數據作為引導，模型需要探索的空間就會變得異常龐大。我們在該領域早期的研究論文中看到過這樣的例子，比如 Google 在早期探索時（大約在 2016 年，當時這個領域被稱為「代碼機器學習」（ML on code），全球關注者可能只有百人左右），最初嘗試的強化學習方法，有點類似於用遺傳算法的方式，讓模型盲目地迭代嘗試所有可能的解決方案。這種方法的計算成本極其高昂——在座的各位對此可能深有體會——因為搜索空間實在太大了。

因此，我們實際上並不一定需要海量的原始訓練數據才能處理低資源語言。我們過去之所以需要海量數據，主要是因為第一代訓練模型的技術嚴重依賴於大規模的「下一個標記預測」（next token prediction）範式。而現在，隨著強化學習等新技術的引入，我們獲得了新的能力，使得模型對原始數據量的依賴性有所降低。

當然，我們仍然希望獲得儘可能多的高質量數據——如果你有大量的 CUDA 代碼，我非常樂意將其納入我的訓練數據集中。但這不再是絕對的必需品。然而，正如莎娜和阿比納夫所強調的，整理和提供高質量的基準真相數據——這項工作將是極其關鍵的。將這些高質量的樣本提供給模型，將極大地提升它們在後續探索、學習和合成數據生成方面的效率和效果。

主持人：你提到基準真相（ground truth）對於合成數據生成（SDG）和解決一般問題都至關重要。那麼，請區分一下「基準真相」和「數據可用性」（data availability）這兩個概念。

我理解，傳統的機器學習方法（比如一兩年前的技術）可能需要海量的樣本數據，而現在合成數據可以在一定程度上彌補數據量的不足。但是，當你談論「基準真相」時，你主要指的是某種形式的、可信賴的驗證標準或高質量樣本，對嗎？

伊索（Poolside）：我們可以從兩個角度來看待驗證或基準真相的作用。

第一種是針對具有明確規則和目標的確定性系統，例如棋類遊戲（圍棋、國際象棋）或許多編程任務。在這些場景下，存在清晰的成功標準或優化目標。例如，對於一個需要分析性能瓶頸的 CUDA 內核，其優化目標（如降低延遲、提高吞吐量）通常是明確且可量化的。

第二種，我們可以稱之為「與已知事實保持一致性」（consistency with ground truth knowledge）。打個比方，假設我明天需要涉足量子物理學領域（一個我完全不瞭解的領域），如果有人給了我一個關於量子物理學的陳述，我要判斷其真偽，就需要去查閱該領域的基準知識來源，比如教科書、權威論文等，然後檢查這個陳述是否與這些已知的、公認的事實相符。

這大致對應了我們目前用於提升模型能力的兩種主要技術路徑：第一種是利用模型日益增強的推理能力，讓其學習與我們已知的、可驗證的真實知識（基準真相）保持一致。我們可以利用這些高質量的基準數據來引導模型，儘管基於推理的一致性檢查在計算上可能成本較高。第二種是強化學習，也就是通過實踐和反饋進行的體驗式學習。實際上，正是這兩種方法的結合，使得我們能夠在提升模型能力方面取得顯著的進步。

主持人：我知道我們剛才的討論深入到了一些非常技術性的細節，希望大家還能跟上節奏——當然，深入探討技術細節也正是大家來參加本次討論的目的。現在，讓我們轉換一下話題，談談遺留代碼（legacy code）的問題。這是一個普遍存在的重大挑戰。具體到 CUDA，遺留代碼往往受到硬件更迭、API 演進等多種環境因素的影響。但更廣泛地說，所謂的「棕地」（brownfield）項目——即在現有代碼基礎上進行開發和維護——是我們所有開發者都必須面對的現實。

我想先請莎娜和阿比納夫分享一些在處理 CUDA 遺留代碼時遇到的具體挑戰。然後，我想將這個問題開放給所有嘉賓：你們認為 AI 在處理遺留代碼方面有何潛力？我們之前聽到艾蘭提到，他可能不會信任 AI 來進行大規模的 API 重構。這背後的原因可能在於，正確的工程實踐要求我們進行模塊化重構並配合充分的測試，但也可能因為對脆弱的遺留代碼進行測試和修改本身就極其困難。

阿比納夫（馬里蘭大學）：對於大型的 CUDA 代碼庫，特別是那些 CUDA 內核散佈在整個項目中的情況，目前比較有效的方法通常是聚焦於單個內核進行處理，例如，嘗試將其移植到新的硬件架構或對其進行性能優化。

主持人：這就像是處理一個個獨立的、封裝好的組件。

阿比納夫（馬里蘭大學）：是的。而目前效果不佳，或者說挑戰更大的，是試圖將整個代碼庫作為一個整體來審視，並嘗試進行全局性的、大規模的更改。

主持人：比如更改依賴關係或重構以使用某個庫。莎娜，根據你在我們更大規模項目上的經驗呢？

莎娜（NVIDIA）：我個人通常不直接處理規模極其龐大的代碼庫，但即使在單個 CUDA 內核的層面上，情況也可能變得相當複雜。因為對於 CUDA 而言，當新的 GPU 架構問世時，你原有的舊代碼雖然通常仍然可以運行，但其性能往往不再是最優的。如果性能不是最優，那麼使用 CUDA 加速的意義就大減價扣了。因此，開發者確實需要針對每一代新的 GPU 重新審視和調整之前的優化策略。

並且，通常情況下，新的 GPU 可能會引入新的硬件特性，而這些特性往往只能通過特定的新 CUDA API 來訪問。這就要求開發者必須修改代碼以利用這些新 API，並可能需要更新所有相關的 CUDA 內核。在某些情況下，為了充分利用某個關鍵的新硬件特性，甚至可能需要對整個代碼結構進行重構，或者從根本上重新設計算法。因此，特別是在 CUDA 領域，為了持續獲得最佳性能，不斷更新和維護代碼是必不可少的。

主持人：所以，這聽起來似乎需要在應用層面進行某種評估或檢測（可能是在運行時，也可能是在進行大規模重構或更改之前），以確定需要進行的調整。妮哈，這種持續適應和更新的需求，與你之前描述的 AI 輔助開發的願景是如何契合的？

妮哈（GitHub）：當我們考慮一個遺留代碼庫時，無論是對於一個 AI 智能體，還是對於一個初次接觸該代碼庫的新人（例如新入職的員工），首要任務都是理解當前的開發環境和代碼庫本身。

設想一下，如果我突然被調到一個全新的項目，需要在一個我從未接觸過的代碼庫（甚至可能使用我不熟悉的語言）中工作，我首先會投入時間去深入研究和理解它。

在處理遺留代碼的軟件開發生命週期（SDLC）中，「理解」（Understanding）是一個至關重要的環節。我確實認為 AI 在這方面可以發揮重要作用。雖然目前可能還沒有足夠成熟的工具，但未來 AI 具備遍曆代碼庫、篩選關鍵信息、並輔助開發者進行探索性理解的能力，將對學習和上手過程非常有幫助。

有趣的一點是，在理解代碼庫的過程中，開發者實際上是在腦海中構建整個代碼庫的「地圖」。對於人類來說，將如此龐大和複雜的上下文完整地記在心裡是非常困難的，但這對於計算機來說則相對容易。因此，計算機和 AI 在輔助理解遺留代碼方面具有天然的優勢。理想情況下，AI 不僅能幫助理解，還能基於理解提出行動計劃，例如明確「接下來需要進行哪些修改」。

至於代碼生成本身，雖然可以讓 AI 生成代碼，但正如莎娜指出的，特別是在 CUDA 領域，生成的代碼必須具備高性能，否則就失去了意義。因此，在性能優化等方面仍然存在挑戰。關於 AI 的能力邊界，我傾向於不輕易斷言「某件事永遠做不到」，因為技術發展的速度往往超出預期。但可以預見的是，像高性能代碼生成和優化這類問題，將是未來需要攻克的更難的挑戰。

艾蘭（Tabnine）：正如妮哈所指出的，這涉及到問題的不同層面。對於大型企業級代碼庫——例如，我們有些客戶的代碼庫規模達到 3000 萬行——即使是看似非常簡單的更改（比如一個 Jira 工單要求添加一個按鈕），開發者也可能需要閱讀數千行代碼，涉及多個不同的代碼層級，才能準確判斷應該在代碼庫的哪個具體位置修改相關的幾行代碼。

代碼生成本身可能相對容易，但準確理解變更的具體位置和影響範圍，即具備充分的上下文感知或代碼庫感知能力（知道在哪裡修改，以及如何修改才能避免破壞其他功能），是極其困難和特定的。我們觀察到，當前的 AI 在這類需要深度理解和精確定位的任務上表現還不夠好，這正是一個巨大的挑戰。這是一個有趣的挑戰，我們以及整個行業都在努力攻克。

主持人：伊索，你似乎對進行這種規模的改變的能力更為樂觀，或者至少我理解是這樣。是什麼讓你對此更有信心？

伊索（Poolside）：首先，我認為我們對於當前 AI 能力的現狀和局限性，大體上是有共識的，因為我們都在實際使用這些工具。目前，一種常見的嘗試讓 AI 理解整個代碼庫的方法是，試圖將全部代碼「塞進」一個巨大的上下文窗口中。但我們一直認為這並非最佳途徑。我們公司主要服務於所謂的「高風險」（high-consequence）軟件開發環境，這些環境通常涉及金融服務、政府、國防或大型科技公司，開發者規模可能從 5000 人到 10 萬人不等。因此，我們幾乎總是需要處理大型、複雜的代碼庫。

我們的觀點是，隨著模型日益展現出智能體（agentic）特性和在環境中行動的能力，我們更期望它們能夠像人類開發者一樣，自主地沿著探索路徑遍曆代碼庫。這與試圖將整個代碼庫一次性加載到上下文窗口中，然後簡單地要求 AI 「找出這項更改會影響什麼」是不同的。

我們可以借鑒人類開發者在面對複雜任務時的做法——這個過程並非完美無缺，當前的 AI 模型也缺乏人類那樣完美的、持續的注意力。但是，如果我們將其視為一個多步驟的任務來處理，讓 AI 模擬這個過程：「我正在考慮進行這項更改，現在我需要去探索代碼庫，跟蹤依賴關係圖，檢查相關文件，並在探索過程中做出判斷和決策。」當我們允許模型在更長的時間跨度內，以一種感知時間序列、分步驟的方式行動時，我們觀察到它們在這方面的表現正逐步提升。

「智能體」（Agent）這個術語在我們的領域確實有些被濫用。但其核心思想——讓模型採用多步驟的方法來解決複雜問題，模擬人類開發者打開文件、檢查代碼、跟蹤依賴等行為——是解決大規模代碼理解和修改問題的關鍵組成部分。我們正看到 AI 在這個方向上展現出良好的發展潛力。然而，這並不意味著它不受當前模型固有局限性的影響，即模型即使在單一步驟上的可靠性也並非 100%，並且在多步驟任務中，準確性可能會迅速下降。因此，我們當前的核心工作——持續推動基礎模型能力的提升——就顯得至關重要。

我們可以看看在非「專家級」或非底層優化（或許可以戲稱為非「忍者編程」）領域已經發生的情況。觀察一下如今的前端應用開發或簡單的 CRUD Web 應用開發，其創建速度已經大大加快。兩年前還難以想像的事情，比如在幾十分鐘內端到端地構建一個基本應用程序（有時被戲稱為「氛圍編碼」（vibe coding）），現在已成為可能。隨著模型能力的不斷提升，這種趨勢正在向其他軟件開發領域擴展。

不過，對於在座的各位——我毫不懷疑從事加速計算開發的專業人士可能是目前對 AI 持懷疑態度最強烈的群體之一，並且你們完全有理由如此，因為這恰恰是當前 AI 表現相對薄弱的領域之一——我有一個具體的建議：找出三到四個對你們來說至關重要的、代表性的開發任務，這些任務是當前 AI 模型還無法很好完成的，將它們作為你們個人的「黃金評估集」（golden evaluation set）。

然後，每隔三到六個月，重新用最新的 AI 工具嘗試完成這些任務。通過這種方式，你可以親身感受 AI 能力的進步，例如發現「哦，現在它的推理能力似乎提高了」，或者「它現在能完成這個任務的 20% 了」。這將幫助你形成自己對於何時、在多大程度上可以信任 AI 的判斷，並對這個領域的發展方向有一個更真實、個性化的感知，而不是僅僅依賴於社交媒體上的信息或公司發佈的基準測試報告。建立並定期評估你自己的黃金任務集，可能是你在關注和應用這項技術時能做的最有價值的事情之一。

主持人：談到智能體能力和更宏觀的開發流程，往往需要依賴某種形式的反饋循環。NVIDIA 特別關注的一個領域，同時也是在座各位專家正在深入探索的一個方向，是如何利用性能分析（profiling）工具產生的反饋信息，並將其更緊密地集成到軟件開發生命週期（SDLC）中。雖然反饋循環對所有軟件開發都很重要，但對於 CUDA 編程而言尤其關鍵，因為在某種意義上，如果 CUDA 代碼性能不佳，它幾乎等同於「錯誤」的代碼——性能正是其存在的根本意義。

基於此，我很想快速聽聽各位嘉賓對於「黃金測試」（golden tests）或「黃金評估任務」的想法，正如伊索剛才提到的。我自己也有一些個人的測試用例，用來檢驗 AI 「現在是否能完成這項任務了？」——如果不行，過段時間再試。

那麼，在你們各自的領域，你們會使用哪些關鍵任務或標準來判斷一個 AI 智能體或代碼生成系統是否取得了實質性的進展或達到了可用的水平？我知道對於 CUDA 和加速計算領域的專家來說，這些標準可能與通用編程領域有所不同。

妮哈（GitHub）：對我個人而言，一個關鍵的測試是代碼重構。我希望 AI 能夠可靠地執行重構任務，例如，嘗試將某段代碼提取成獨立的函數或模塊，並驗證其有效性。另一個重要的測試是跨語言代碼轉換。這是我關注的兩個目前 AI 尚未完全掌握，但我感覺我們正逐步接近目標的領域。

我期望未來能達到這樣一種狀態：我可以不斷提高對工程團隊的要求和標準，賦予他們更多的職責，而 AI 能夠有效地輔助他們。當我考慮我的團隊（大約有 500 名工程師）時，我希望在提升標準（例如，要求他們同時負責高性能代碼、數據容量管理、可訪問性，並確保代碼功能正確且可擴展）的同時，不會讓他們負擔過重。我希望 AI 能夠在這方面提供支持，比如在代碼審查環節提供有價值的建議，甚至成為他們學習和探討技術方案的「夥伴」。所以，總結來說，我的兩個關鍵測試領域是代碼重構和語言轉換。我們正在取得進展，但尚未完全達到理想狀態。

阿比納夫（馬里蘭大學）：你提到其中一個關鍵測試是語言轉換，但更具體地說是從串行代碼自動轉換為並行代碼，例如從串行 C/C++ 轉換為 MPI 或 CUDA 實現。目前 AI 在這方面的表現還很不理想。另一個重要的測試，我認為是整個程序的翻譯或重構，正如我之前提到的。我們也有基於代碼規模的「黃金測試」：例如處理 500 行、1000 行、10000 行的代碼片段或程序。目前的模型在處理 500 到 1000 行規模的代碼時表現尚可，但一旦代碼規模顯著增大，我們往往無法得到任何有意義的生成結果，或者生成的只是無效的代碼。

主持人：看來我們需要私下交流一下關於處理大規模代碼上下文的方法，而不是簡單地依賴巨大的上下文窗口。莎娜，你的看法呢？

莎娜（NVIDIA）：對我而言，一個關鍵的測試是 AI 能否成功執行一項複雜的 CUDA 優化任務。這不僅包括它是否能最終生成正確的優化代碼，還包括評估其效率：即使初始生成的代碼不正確，它需要經過多少輪迭代和修正才能達到正確狀態？以及，我需要提供哪些輔助信息或工具（例如性能分析數據、編譯器反饋）才能幫助它更有效地完成任務？

因為我們觀察到，也許幾個月前，某些複雜的代碼轉換任務 AI 完全無法完成，即使我們嘗試提供調試信息。但隨著時間的推移，模型在理解和應用這些信息方面有所改進，我們希望看到達到正確結果所需的迭代次數能夠逐漸減少。

艾蘭（Tabnine）：對我來說，目前特別感興趣的一個「黃金任務」是執行非常深入且跨越整個代碼庫的符合性審查。例如，給定一個需求：「確保系統在任何情況下都不會在未加密的狀態下傳輸客戶數據」。

我希望 AI 智能體能夠準確理解這個需求中的關鍵概念：什麼是「客戶數據」？什麼是「加密」？哪些操作構成了「傳輸」行為？這項任務的挑戰在於，相關的邏輯可能完全分散在代碼庫的不同層面和模塊中。要完成這項任務，AI 需要具備伊索之前提到的那種在代碼庫中進行導航和推理的能力。它需要能夠理解所有這些分散的部分，並將它們聯繫起來，作為一個整體流程進行驗證。我們目前還沒有完全達到這個水平，但我認為我們正在逐步接近。

主持人：好的，接下來我們直接進入提問環節。

觀眾提問：我的問題是關於帶有自動驗證的強化學習。特別是在處理複雜軟件項目（例如您提到的在 Docker 容器中運行的完整代碼倉庫）時，您如何設計自動驗證規則，以防止模型找到「取巧」或「鑽空子」（gaming the system）的方法來滿足規則，而不是真正解決問題？

對於 CUDA 加速，目標通常很明確（例如提升性能指標），但對於更廣泛的、涉及整個軟件項目的複雜任務，如何設定有效的、不易被「遊戲化」的驗證標準呢？

伊索（Poolside）：這是一個非常好的問題。首先，多樣性（diversity）是緩解這個問題的一個關鍵因素。我們起始於包含多種編程語言的一百萬個真實世界的代碼庫。我們利用這些項目自帶的、由開發者編寫的現有測試（主要是單元測試）作為初步的驗證信號。誠然，單元測試覆蓋率可能存在不足，開發者編寫的測試本身也可能包含錯誤。但是，當你擁有足夠大的規模和足夠高的多樣性時，你就可以通過統計和過濾的方法，篩選出那些測試質量相對較高、更可靠的部分作為訓練信號。

然後，在此基礎上，我們可以利用一種我有時戲稱為「LLM 套利」（LLM arbitrage）的現象：目前的模型在編寫測試用例和解釋代碼方面的能力，往往優於它們直接生成複雜功能代碼的能力。我們可以利用這種能力上的差異，讓模型圍繞特定的任務目標，綜合生成大量的額外測試覆蓋。當然，無論是原始測試還是合成測試，單獨來看都可能不完美。但是，當你在強化學習框架中擁有極其龐大的規模和多樣性時，這些信號足以將模型的學習過程引導到正確的方向上，使得模型在每一輪訓練迭代後都能有所改進。因此我們發現，在進行這類強化學習時，特別是當目標不像「優化某個具體性能數值」那樣清晰明確時（性能優化實際上是強化學習中最容易定義目標的一類問題），例如涉及到在整個代碼庫中進行複雜更改或構建全新功能時，關鍵在於不斷提升用於訓練和評估的問題集（problem set）的規模和多樣性。

實踐表明，隨著模型能力的提升，解決特定類型任務所需的訓練樣本效率會提高（即需要更少的樣本）。這時，訓練策略就會相應調整：逐漸減少對已掌握的簡單任務的關注，將重心轉移到新出現的、更困難的任務類別上——這些任務模型可能只能部分解決，或者完全無法解決。這就像一個不斷迭代提升模型能力的過程，如同將一個「能力窗口」逐步向前推進。

當然，最終我們會遇到一個挑戰：如何為那些非常高層次、抽像的，並且難以找到現成示例的目標任務定義有效的學習信號？這時，之前提到的「套利」方法又可以發揮作用。例如，你可以選取一個現有的複雜項目（比如一個性能分析器的代碼庫），讓一個強大的模型去深入理解它，然後嘗試讓模型反向生成該項目的目標描述或高級設計規範。本質上，我們是在不斷地以真實世界的複雜數據作為「種子」，從不同角度對其進行加工和利用，目標是生成可用於訓練的任務描述、用於驗證的測試用例，或者作為示例的解決方案代碼。理論上，甚至可以嘗試同時合成這三者，並且這種方法在一定程度上是可行的。但是，如果能獲得一些高質量的真實基準真相數據作為基礎，效果通常會更好。同時，我們也希望模型能夠在真實、多樣化的環境中學習，而不僅僅是局限於某些特定類型的、可能被過度簡化的任務。

觀眾提問：我想向 GitHub 的嘉賓提問。您之前提到了代碼重構，並表示在這個領域正取得進展。對於小規模的軟件或應用程序，AI 輔助重構或許是可行的。但對於非常大規模的系統（例如數十萬行甚至更多代碼），尤其是那些包含混亂的「意大利麵條式代碼」（spaghetti code）或複雜遺留結構的系統，您認為 AI 未來將如何處理這類大型系統的重構挑戰？

妮哈（GitHub）：我認為，一個非常重要的原則是，只要人類開發者仍然是開發流程中的關鍵一環——而且我個人傾向於在可預見的未來保持這種「人機協作」的模式——我們就應該確保 AI 的工作方式不應過度偏離人類的最佳實踐。因此，即使是在與純人類團隊合作時，我也通常不希望看到一次性涉及上百個文件的大規模、原子性的重構提交，除非有極其充分的理由。我更傾向於鼓勵開發者將大型重構任務分解成更小、更易於管理和審查的步驟。

類似地，當涉及到與 AI 「隊友」協作進行重構時，我認為正確的方式也應該是從小規模、可控的重構開始，然後逐步擴展其應用範圍。我們需要確保在這個過程中，人類開發者能夠理解、驗證並對結果感到「舒適」或有信心，因為歸根結底，我們是在與這些 AI 系統協同工作。

所以我目前並不認為我們能夠、或者應該期望 AI 一次性完成涉及兩三百個文件的重大重構。主要原因在於，我們仍然需要對最終合併到代碼庫中的代碼負責，這意味著我們需要能夠理解這些更改。因此，我的回答是，在設計和應用 AI 輔助重構方案時，我們必須始終考慮到最終使用和審查這些代碼的人類開發者。這又回到了信任和責任的問題上。即使未來 AI 的能力發展到足以處理非常大規模的重構任務，我們可能仍然需要將其分解成人類可以理解、審查並最終負責的較小單元。

觀眾提問：我有一個關於生成式 AI 模型能力的問題。我們看到一些報導或基準測試聲稱，最新的模型能夠在編程競賽中取得非常好的成績，甚至「擊敗」頂尖的人類競賽選手。但與此同時，當我們在真實的、複雜的軟件開發場景中測試這些模型時，它們似乎又經常失敗。

我想請問各位嘉賓，你們是否認同這種觀察，即當前的某些基準測試（如編程競賽）可能無法完全反映模型在真實世界開發任務中的實際能力？其次，如果認同，你們認為造成這種差異的主要原因是什麼？第三，針對這個問題，你們是否有相應的解決思路或計劃？

伊索（Poolside）：原因其實相對直接。與真實世界的軟件開發相比，編程競賽是一個更容易針對性優化的任務領域。這是因為競賽編程的問題域通常範圍更窄，目標更明確（例如，通過所有測試用例並優化時間和空間複雜度），更容易將其轉化為一個清晰的強化學習目標，從而可以通過大量訓練顯著提升模型在該特定任務上的表現。

因此，目前觀察到的這種（競賽表現與真實世界表現的）差異是符合預期的。在編程競賽中，獎勵信號是明確定義的，問題通常具有確定性（給定輸入，有唯一或可驗證的正確輸出），並且問題的規模和複雜度相對可控。

此外，還有一個可能的原因是，在許多研究實驗室中，參與模型研發的人員本身可能就有很強的競賽編程背景（坦率地說，我的團隊里也有這樣的人才）。他們自然會傾向於關注並優化模型在自己熟悉的競賽任務上的表現，希望「讓模型在這個特定任務上做到極致」。但這並不一定能直接轉化為模型在更廣泛、更複雜的真實世界軟件開發任務中的通用能力。這就像一個頂尖的競賽程序員，如果其經驗僅限於競賽環境，未必能在實際的工程項目中成為最高效或最有價值的開發者。因此，編程競賽是一個有趣的基準測試，它可以為我們提供一些關於模型特定能力的信號，但它不應該被視為衡量模型在所有軟件開發任務中綜合能力提升的唯一或主要標準。

艾蘭（Tabnine）：我完全同意伊索的觀點。如果允許我補充一點，那就是為真實世界的企業級軟件開發任務（例如，執行一項複雜的代碼變更）創建有效的、有代表性的基準測試本身就極其困難。其難度遠超創建編程競賽類型的基準測試。因此，我們看到的差異，部分也源於評估真實世界能力的基準測試本身的構建難度。

主持人：正好借此機會宣傳一下，如果大家感興趣，可以去 GTC 大會 NVIDIA 展位的 AI 開發者工具團隊展台瞭解一下。我們正在發佈一個名為 ComputeEval 的新基準測試。這個基準測試旨在更準確、更全面地反映企業級規模的軟件開發問題，特別是針對 CUDA 編程的挑戰，並且充分考慮了剛才討論的這些因素。當然，這個基準測試是否真正有效，還有待業界的檢驗和反饋。在此也呼籲所有致力於評估方法研究的同仁們，繼續努力為我們的行業創建更好、更貼近實際的評估標準。

觀眾提問：我的問題也與信任有關。我記得去年十二月左右有一篇研究論文（可能來自某個研究小組）引起了一些討論，其結論似乎暗示，隨著模型能力的增強，它們最終可能會發展出某種形式的「欺騙性行為」（scheming or deceptive behavior）。

我知道這還只是初步的研究，可能需要更多時間來驗證其結論。但是，我的問題是：假設我們最終真的面臨這種最壞的情況，即我們發現從根本上無法完全信任 AI 模型（例如，因為驗證其真實意圖的問題最終被證明是像停機問題（halting problem）那樣的不可判定問題）。在那種假想的未來中，您認為我們應該如何繼續利用 AI 技術？我們可以設置什麼樣的「護欄」（guardrails）或採取哪些措施來管理這種風險？

艾蘭（Tabnine）：首先，我們需要認識到，這可能是一個相對的問題。就像自動駕駛技術一樣，未來可能在某些方面，由於人類自身的局限性（例如疲勞、注意力不集中導致的錯誤），依賴人類的風險甚至可能高於依賴經過充分驗證的 AI 系統。AI 在處理某些複雜任務上的能力可能會超越人類。

但是，你提出的核心問題是對的：從根本上驗證一個複雜智能系統的內部狀態或「真實意圖」，很可能是一個不可判定的問題，因為它本質上是一個極其複雜的驗證（verification）問題。

妮哈（GitHub）：我想到了一個俗語——「手裡拿著錘子，看什麼都像釘子」。這個比喻之所以適用，是因為我們有時會陷入一種思維定式：當我們初次接觸 AI 時，可能會預設「只有當它完全可信時，我才會這樣或那樣使用它」。但即使一個系統並非完全可信（就像邏輯謎題中那些已知總是在說謊的角色），我們仍然可以從中獲取有用的信息或洞見。

人類的適應性非常強，關鍵在於我們能否找到有用的方式來利用這些不完美的工具，並讓它們幫助我們做出更好的決策。我不認為我們應該因為潛在的不可信風險就完全放棄 AI。即使一個系統在某些方面不完全可靠（當然，我個人對未來是樂觀的），它仍然可能在其他方面幫助我們編寫更好的代碼或提高效率。最終，這取決於我們如何設計與 AI 的交互方式，如何明智地選擇應用場景，而這需要我們進行深入的研究，並不斷探索最佳實踐。

伊索（Poolside）：我瞭解你提到的那篇論文，這觸及了 AI 安全（AI Safety）的核心議題。那麼，在信任問題之外（我基本同意艾蘭和妮哈的觀點），我們確實必須在不遠的將來正視一個現實：我們正在創造出智能水平可能與人類相當甚至超越人類的系統，並且這些系統很快將具備規劃和執行長期複雜任務的能力。

這是人類社會從未遇到過的情況。因此，如何「對齊」（align）這些強大的 AI 系統，確保它們的目標和行為符合人類的意圖和價值觀（這讓人聯想到經典的阿西莫夫機器人三定律），將成為一個日益關鍵的研究和工程領域。目前，許多從事基礎模型研發的公司（坦率地說，有時也包括我們自己）在這項對齊工作方面仍處於相對早期的階段。

但是，隨著我們越來越接近通用人工智能（AGI）或其他形式的強大 AI 的「臨界點」，我們亟需加強關於 AI 安全和對齊的討論與研究。就我個人而言，我對此持謹慎樂觀的態度，因為我們參與了模型訓練的全過程，並且正通過強化學習等技術，越來越多地嘗試為模型施加更嚴格的倫理和行為約束。我相信這些是可以通過持續努力來改進和解決的問題。

目前我們能做的最重要的事情（這一點你會反復從各大基礎模型公司那裡聽到）是大力投入評估（evaluation）技術的研究，開發出更好的方法來準確衡量和理解模型是否真正按照我們的期望和指令行事。具體到你提到的那篇關於「欺騙性行為」的論文，它進一步凸顯了在可解釋性（interpretability）研究方面投入更多努力的重要性，我們需要更深入地理解模型內部的決策機制。但這仍然是一個非常前沿和開放的研究領域，有大量工作亟待完成。

我想提及我們一個非常值得尊敬的競爭對手——Anthropic，他們在探索 AI 安全的「黃金標準」方面，為整個行業樹立了很好的榜樣。但總的來說，我們所有人都還處於這個征程的早期階段。

* 本文由 CSDN 精編整理。

* 今場對話源自 GTC 2025，日程為香港時間 2025 年 3 月 22 日 0:00 AM – 1:00 AM。