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

責(zé)編 | 王啟隆

出品丨AI 科技大本營（ID：rgznai100）

主持人：大家好，我是 NVIDIA 開發(fā)者工具 AI 技術(shù)軟件工程總監(jiān)，馬特·弗雷澤（Matt Frazier）。

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

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

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

• 有多少人特別在 CUDA 調(diào)試中使用過 AI 驅(qū)動的代碼工具？

• 大約有多少人遇到過 CUDA 性能問題，并且花了超過一天的時間來解決？

• 有沒有人嘗試過將這兩者結(jié)合，把 AI 代碼生成應(yīng)用于你們的 CUDA 問題？有人成功過嗎？

• 有多少人的代碼庫，特別是 CUDA 代碼庫，規(guī)模超過了大約一萬行？

• 接下來是大家可能最關(guān)心的問題。在使用 AI 代碼生成工具時，你們遇到的最大挑戰(zhàn)是什么？是準(zhǔn)確性，還是生成速度？

• 如果你正在用 CUDA 編寫加速代碼，你會選用 C++ 還是 Python？或者兩者都用？

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

莎娜·達(dá)馬尼（Sana Damani），她是 NVIDIA 架構(gòu)研究組的研究科學(xué)家，致力于提升 GPU 上并行應(yīng)用程序的性能，以及提高調(diào)試和優(yōu)化工作的易用性。

妮哈·巴特拉（Neha Batra），GitHub Copilot 的工程副總裁，她領(lǐng)導(dǎo)的核心生產(chǎn)力組織，專注于貫穿整個軟件開發(fā)生命周期（SDLC）的工具以及開發(fā)者的日常工作流程。她尤其關(guān)注 AI 編碼助手如何從領(lǐng)導(dǎo)大型團(tuán)隊和產(chǎn)品項目的視角出發(fā)，變革開發(fā)者的工作流程。

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

伊索·康德（Eiso Kant），Poolside 的創(chuàng)始人，他是一位工程師，在 AI 和開發(fā)者工具領(lǐng)域擁有十余年創(chuàng)辦初創(chuàng)公司的經(jīng)驗。在創(chuàng)立 Poolside 之前，伊索曾是 Athenian 和 sourcek96zbhq 的創(chuàng)始人兼 CEO。

最后是阿比納夫·巴特勒（Abhinav Bhatele），他是馬里蘭大學(xué)帕克分校計算機(jī)科學(xué)系的副教授，兼任并行軟件與系統(tǒng)組主任。他的研究重點是用于大規(guī)模訓(xùn)練、微調(diào)大語言模型（LLM）以完成編碼任務(wù)（如并行代碼生成）的基礎(chǔ)設(shè)施。

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

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

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

第二個項目名為WarpDrive，這個項目更具實驗性質(zhì)，我們?nèi)ツ暝?NeurIPS 會議上進(jìn)行了展示。它是一個 AI 智能體解決方案，目標(biāo)是自動化 CUDA 性能調(diào)優(yōu)的完整流程，涵蓋從性能分析、識別恰當(dāng)?shù)膬?yōu)化策略、執(zhí)行代碼轉(zhuǎn)換，到最終測試等各個環(huán)節(jié)。當(dāng)然，這個領(lǐng)域仍然面臨諸多挑戰(zhàn)，尤其是在驗證生成代碼的正確性方面。

但總的來說，通過這兩個項目，我們的目標(biāo)不僅是減少 GPU 性能調(diào)優(yōu)所需的人力投入，更是要讓不同水平的開發(fā)者都能更輕松地利用 GPU 的強(qiáng)大性能，而不僅僅局限于那些頂尖的專家。

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

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

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

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

伊索（Poolside）：文件結(jié)構(gòu)的問題本身可能不會持續(xù)存在太久。但是，談到構(gòu)建系統(tǒng)以及 CUDA 優(yōu)化或任何加速計算的優(yōu)化，我們目前推動基礎(chǔ)模型前沿發(fā)展的主要方式，是通過強(qiáng)化學(xué)習(xí)讓模型在真實的軟件開發(fā)環(huán)境中進(jìn)行學(xué)習(xí)。

舉例來說明我們公司正在做的工作：我們在一個強(qiáng)化學(xué)習(xí)環(huán)境中運行了超過一百萬個完全容器化的 GitHub 項目，這些項目包含了數(shù)千萬次的修訂記錄。我們讓模型在這些真實環(huán)境中執(zhí)行各種開發(fā)任務(wù)，然后實際運行項目自帶的測試以及我們設(shè)置的其他驗證檢查，以此來反饋和改進(jìn)模型。

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

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

艾蘭（Tabnine）：將強(qiáng)化學(xué)習(xí)應(yīng)用于 CUDA 優(yōu)化這類任務(wù)的部分挑戰(zhàn)還在于正確性驗證。對 CUDA 代碼進(jìn)行測試本身就非常困難，僅僅是為 CUDA 內(nèi)核運行測試并確保其計算結(jié)果正確，就已經(jīng)相當(dāng)具有挑戰(zhàn)性。你需要有效控制并發(fā)執(zhí)行，并確保對不同的執(zhí)行交錯（execution interleavings）有良好的測試覆蓋率。因此，為這些涉及并發(fā)和同步的工作負(fù)載設(shè)計并執(zhí)行充分的正確性測試，本身就是一個巨大的難題，這還僅僅是為了驗證代碼的功能正確性，尚未涉及性能。

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

我們特別關(guān)注的一個研究領(lǐng)域是，識別那些適合在整個代碼庫范圍內(nèi)進(jìn)行的更改類型。例如，如果要實施一項安全改進(jìn)，需要修改或檢查哪些不同的文件？如果要進(jìn)行可訪問性方面的改進(jìn)，又需要涉及哪些類型的文件？以及我們?nèi)绾文軌蚋到y(tǒng)化地處理這些跨文件的操作？我們正在研究那些可以通過 AI 進(jìn)行全局性處理的問題類別。

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

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

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

妮哈（GitHub）：我想補(bǔ)充一點：代碼創(chuàng)建、測試編寫和代碼審查是軟件開發(fā)中的三個關(guān)鍵環(huán)節(jié)。這三者對于提高代碼質(zhì)量、確保最終產(chǎn)品符合預(yù)期都至關(guān)重要。具體在哪些環(huán)節(jié)實現(xiàn)自動化、減輕哪些負(fù)擔(dān)、側(cè)重于哪些方面，往往取決于不同公司的具體需求和策略。讓所有這三個環(huán)節(jié)完全由 AI 自動化，我認(rèn)為風(fēng)險相當(dāng)大，但利用 AI 進(jìn)行輔助則非常有價值。

我特別關(guān)注的領(lǐng)域之一是 Copilot 代碼審查功能，即探索如何讓 AI 輔助進(jìn)行初步的代碼審查。另一個領(lǐng)域是測試生成，AI 在生成單元測試方面表現(xiàn)得相當(dāng)不錯。但當(dāng)涉及到端到端測試時，正如艾蘭之前提到的，你需要確保自己真正理解成功的標(biāo)準(zhǔn)是什么、期望的結(jié)果是什么、以及需要特別注意哪些方面，因為這些都需要在委托 AI 執(zhí)行任務(wù)時明確指定。

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

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

伊索（Poolside）：這個領(lǐng)域最初是從代碼補(bǔ)全功能開始的，隨后發(fā)展到基于聊天的交互模式，而當(dāng)前最新的趨勢是朝著智能體（Agent）的方向發(fā)展。但許多人可能尚未完全意識到的是，基礎(chǔ)模型的改進(jìn)速度非常之快，以至于從我們的視角來看，實現(xiàn)具備真正自主行動能力的 AI 系統(tǒng)——也就是能夠端到端完成任務(wù)的環(huán)境——已經(jīng)為期不遠(yuǎn)。這意味著 AI 將能夠執(zhí)行完整的端到端操作：從自動解決構(gòu)建錯誤，到獨立執(zhí)行大型、復(fù)雜的多步驟開發(fā)任務(wù)，最終交付一個已經(jīng)完成或準(zhǔn)備好供人工審查的成果。

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

回想起來，如果是在 2016 年，我們都剛進(jìn)入這個行業(yè)時你問我這個問題，我可能會說，這或許需要 30 年才能實現(xiàn)。如果是在兩年前我創(chuàng)辦這家公司時問我，我大概會說 5 到 10 年。而現(xiàn)在你問我這個問題，我的預(yù)測是 24 個月、30 個月、36 個月——這個時間范圍變得非常具體了。這一點值得我們注意。隨著 AI 能力的指數(shù)級增長，它的形態(tài)和應(yīng)用方式將發(fā)生巨大變化，從簡單的編輯器助手演變?yōu)楦咦灾餍缘闹悄荏w。這種轉(zhuǎn)變將有望解決我們目前關(guān)心的許多關(guān)于端到端自動化能力的問題。

艾蘭（Tabnine）：我想立即就此提出一點不同的看法。端到端的自動化能力或許會實現(xiàn)，但其中存在一個我們目前可能有所低估的關(guān)鍵差距，那就是信任問題。我們?nèi)绾文軌蛐湃我粋€ AI 智能體交付的結(jié)果？我個人是絕對不會愿意坐下來審查由智能體生成的 3 萬行代碼（尤其是審查復(fù)雜的 CUDA 代碼）。

我們已經(jīng)觀察到，在 AI 驅(qū)動的軟件開發(fā)生命周期（SDLC）中，瓶頸正在從代碼生成轉(zhuǎn)向代碼審查。生成大量代碼變得非常容易，但我們無法確定這些生成的代碼是會累積成技術(shù)債務(wù)，還是可以真正信任并集成到項目中的高質(zhì)量代碼。

這涉及到幾個關(guān)鍵點：首先是AI 需要理解整個現(xiàn)有的代碼庫，確保生成的內(nèi)容與組織內(nèi)已有的代碼、庫和規(guī)范兼容。其次，需要有某種機(jī)制來控制生成過程，確保產(chǎn)出的代碼在一定程度上遵循團(tuán)隊的最佳實踐和編碼標(biāo)準(zhǔn)。而這些僅僅是挑戰(zhàn)的開始。正如妮哈提到的，我們需要明確的規(guī)范和標(biāo)準(zhǔn)：由誰來負(fù)責(zé)審查這些 AI 生成的代碼？對于這 3 萬行代碼，其正確性的基準(zhǔn)（ground truth）又是什么？

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

但是，當(dāng)未來我們開始擁有能力足夠強(qiáng)大的 AI 系統(tǒng)和模型，并且我們能夠持續(xù)觀察到它們的產(chǎn)出質(zhì)量達(dá)到了與我們組織中值得信賴的人類同事難以區(qū)分的水平時，那么信任問題將在很大程度上自然緩解。因此，我們或許并不需要刻意去“解決”信任問題本身，而是要關(guān)注于提升 AI 的能力和可靠性。

當(dāng)然，在現(xiàn)階段，我們必須維持現(xiàn)有的軟件開發(fā)生命周期（SDLC）、代碼審查流程以及其他成熟的工程實踐。例如，我目前并不建議用戶通過 API 調(diào)用我們的模型來執(zhí)行全局性的代碼重構(gòu)，我甚至?xí)鞔_建議我們的客戶不要這樣做。這有點像我們有時會看到一些開發(fā)者為代碼倉庫自動提交大量單元測試的 Pull Request——這可能并非當(dāng)前技術(shù)下最恰當(dāng)?shù)膽?yīng)用方式。

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

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

妮哈（GitHub）：“智能體”（Agent）無疑是未來幾年的熱門概念和重要發(fā)展趨勢。它本質(zhì)上描繪了一種場景：我們可以將任務(wù)分配給 AI，然后暫時離開，待任務(wù)完成后再回來檢查結(jié)果。有趣的是，作為一個從工程師轉(zhuǎn)變?yōu)楣芾碚叩娜耍疑钪笆跈?quán)”是一項關(guān)鍵的管理技能。而現(xiàn)在，我們實際上是在嘗試學(xué)習(xí)如何清晰地定義一個任務(wù)，并將其有效地“委托”給一個 AI 智能體，無論是通過聊天界面還是其他交互方式。我們需要找到更優(yōu)化的方法，將 AI 無縫地嵌入到我們的工作流程中，讓它在真正有價值的環(huán)節(jié)發(fā)揮作用。

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

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

主持人：伊索剛才提到需要理解我們的意圖、完整的開發(fā)生命周期以及最終目標(biāo)，這聽起來與產(chǎn)品需求文檔（PRD）或詳細(xì)設(shè)計規(guī)范有相似之處。那么艾蘭，你對于利用這類更結(jié)構(gòu)化的輸入（比如計劃或規(guī)范文檔），甚至從這些文檔出發(fā)來指導(dǎo) AI 執(zhí)行任務(wù)（而不僅僅是生成代碼片段），例如讓 AI 根據(jù)計劃生成集成測試、單元測試等，有什么看法？

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

現(xiàn)實中，規(guī)范幾乎永遠(yuǎn)是不充分的。我們不可能編寫一份長達(dá)一萬頁的 PRD 來詳盡說明如何構(gòu)建一個應(yīng)用程序的每一個細(xì)節(jié)。幾乎所有的開發(fā)工作都是基于不充分的規(guī)范進(jìn)行的，而將這些不充分的規(guī)范具體化為實際代碼的過程，目前很大程度上依賴于人類開發(fā)者的理解和判斷。

這正是當(dāng)前開發(fā)流程能夠有效運作的原因之一。你通常不會給初級開發(fā)人員一份極其詳盡的 PRD，而是會給出相對高層次的指令，比如“我需要在這里添加一個按鈕”，然后期望他們能夠根據(jù)上下文進(jìn)行合理的推斷和實現(xiàn)。在我們擁有能夠被充分信任、并且能夠準(zhǔn)確推斷我們高層次意圖的 AI 之前，信任問題將持續(xù)存在。

再次強(qiáng)調(diào)，我們觀察到的現(xiàn)象是，AI 驅(qū)動開發(fā)的瓶頸正顯著地轉(zhuǎn)移到代碼審查環(huán)節(jié)。這對在座的各位可能都有體會。我們實際上看到了一種類似“分布式拒絕服務(wù)攻擊”（DDoS）的效應(yīng)：代碼生成者（可能是一些經(jīng)驗不足、傾向于直接接受 AI 建議的初級開發(fā)者）產(chǎn)生了大量的代碼，涌向負(fù)責(zé)審查的高級工程師，使得后者的審查負(fù)擔(dān)可能比以前增加了百倍。這些高級工程師疲于應(yīng)對，竭力確保涌入的代碼不會引入問題，不會破壞代碼庫的穩(wěn)定性。這是我對信任問題的一個普遍觀察。將這些 AI “助手”或“員工”引入組織的挑戰(zhàn)，核心在于如何使它們變得足夠值得信賴。我們最終會達(dá)到那個目標(biāo)，但這需要一個過程，需要我們找到方法將 AI 的可靠性提升到等同于值得信賴的人類員工的水平。

主持人：談到引入 AI “員工”——我剛加入 NVIDIA 時，CUDA 經(jīng)驗也并不豐富。這讓我思考，我們?nèi)绾巫?AI 系統(tǒng)，特別是當(dāng)它們更深入地集成到 SDLC 中、我們對其依賴程度越來越高時，獲得必要的領(lǐng)域知識？這既包括為了建立信任而進(jìn)行的某種形式的“入職培訓(xùn)”，也包括如何讓 AI 在那些專業(yè)知識要求高、或者可用訓(xùn)練數(shù)據(jù)相對稀疏的新領(lǐng)域（如 CUDA）中表現(xiàn)良好？

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

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

如果我們能夠利用這些高質(zhì)量的代碼構(gòu)建一個專門的知識庫，那么我們就可以將其用于強(qiáng)化學(xué)習(xí)、模型微調(diào)，或者直接作為高質(zhì)量的示例（few-shot examples）提供給 AI 智能體。這將是一種非常有價值的方法。即使在我們 WarpDrive 項目的探索中，我們的目標(biāo)也不僅僅是應(yīng)用已知的、有大量數(shù)據(jù)的優(yōu)化技術(shù)。

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

阿比納夫（馬里蘭大學(xué)）：我先快速回應(yīng)一下關(guān)于信任的問題，盡量簡短。特別是在科學(xué)計算領(lǐng)域——我相信在工業(yè)界的生產(chǎn)級軟件開發(fā)中同樣如此——確保代碼的正確性是至關(guān)重要的。通常，科學(xué)計算團(tuán)隊中既有物理學(xué)家也有計算機(jī)科學(xué)家，有時物理學(xué)家甚至對計算機(jī)科學(xué)家編寫的代碼也持謹(jǐn)慎態(tài)度，他們傾向于親自進(jìn)行驗證和測試。

主持人：他們所處的領(lǐng)域確實要求極高的嚴(yán)謹(jǐn)性，不能輕易信任。

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

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

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

https://arxiv.org/pdf/2312.02120

這篇論文也有清華學(xué)子的身影

主持人：那么，對于更大規(guī)模的代碼生成工具來說，你們?nèi)绾翁幚頂?shù)據(jù)稀疏的問題？

伊索（Poolside）：我可以談?wù)労铣蓴?shù)據(jù)（synthetic data）這個概念。在我們目前從頭開始訓(xùn)練的基礎(chǔ)模型中，已經(jīng)有大約 25% 的訓(xùn)練數(shù)據(jù)是合成生成的。

我們的預(yù)測是，在未來 12 到 18 個月內(nèi)，我們用于訓(xùn)練模型的數(shù)據(jù)中，合成數(shù)據(jù)的比例可能會高達(dá) 90%。但這其中有一個非常關(guān)鍵的前提，這也呼應(yīng)了莎娜剛才提到的觀點：有效的合成數(shù)據(jù)生成，必須基于少量但質(zhì)量極高的“基準(zhǔn)真相”（ground truth）數(shù)據(jù)。

打個比方：假設(shè)我找到一位沒有 CUDA 背景，但具備很強(qiáng)推理能力和扎實 C++ 基礎(chǔ)的優(yōu)秀軟件工程師，然后讓他去處理一個復(fù)雜的 CUDA 任務(wù)。雖然我本人并非來自科學(xué)計算背景，但我們公司內(nèi)部為了優(yōu)化模型訓(xùn)練和推理代碼，也編寫了大量的 CUDA 代碼。假設(shè)任務(wù)是優(yōu)化一個注意力（attention）機(jī)制的 CUDA 內(nèi)核。為了幫助這位工程師學(xué)習(xí)，我需要提供給他高質(zhì)量的 API 文檔、清晰的示例代碼，以及任何能夠簡化學(xué)習(xí)過程的資源（就像一本好的教科書），并假設(shè)他有足夠的時間（可能需要很長時間，比如數(shù)年，去解決一個 CUDA 專家半天就能搞定的問題）。

關(guān)鍵在于，如果存在可供學(xué)習(xí)的高質(zhì)量基準(zhǔn)真相數(shù)據(jù)，那么以此為起點，我們實際上可以通過模型自身的推理能力，結(jié)合強(qiáng)化學(xué)習(xí)以及我們使用的一系列其他技術(shù)，來綜合生成和推斷出大量的相關(guān)知識和代碼模式。但是，明確哪些是可靠的真實樣本、哪些是模型需要通過探索來學(xué)習(xí)的內(nèi)容，這一點至關(guān)重要。因為一旦有了這個堅實的基礎(chǔ)，我們就可以引導(dǎo)模型進(jìn)行類似人類開發(fā)者的“體驗式學(xué)習(xí)”：讓模型去嘗試不同的方法，運用其推理能力，在實踐中學(xué)習(xí)哪些嘗試是有效的（做對了），哪些是無效的（做錯了）。

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

因此，我們實際上并不一定需要海量的原始訓(xùn)練數(shù)據(jù)才能處理低資源語言。我們過去之所以需要海量數(shù)據(jù)，主要是因為第一代訓(xùn)練模型的技術(shù)嚴(yán)重依賴于大規(guī)模的“下一個標(biāo)記預(yù)測”（next token prediction）范式。而現(xiàn)在，隨著強(qiáng)化學(xué)習(xí)等新技術(shù)的引入，我們獲得了新的能力，使得模型對原始數(shù)據(jù)量的依賴性有所降低。

當(dāng)然，我們?nèi)匀幌Ｍ@得盡可能多的高質(zhì)量數(shù)據(jù)——如果你有大量的 CUDA 代碼，我非常樂意將其納入我的訓(xùn)練數(shù)據(jù)集中。但這不再是絕對的必需品。然而，正如莎娜和阿比納夫所強(qiáng)調(diào)的，整理和提供高質(zhì)量的基準(zhǔn)真相數(shù)據(jù)——這項工作將是極其關(guān)鍵的。將這些高質(zhì)量的樣本提供給模型，將極大地提升它們在后續(xù)探索、學(xué)習(xí)和合成數(shù)據(jù)生成方面的效率和效果。

主持人：你提到基準(zhǔn)真相（ground truth）對于合成數(shù)據(jù)生成（SDG）和解決一般問題都至關(guān)重要。那么，請區(qū)分一下“基準(zhǔn)真相”和“數(shù)據(jù)可用性”（data availability）這兩個概念。

我理解，傳統(tǒng)的機(jī)器學(xué)習(xí)方法（比如一兩年前的技術(shù)）可能需要海量的樣本數(shù)據(jù)，而現(xiàn)在合成數(shù)據(jù)可以在一定程度上彌補(bǔ)數(shù)據(jù)量的不足。但是，當(dāng)你談?wù)摗盎鶞?zhǔn)真相”時，你主要指的是某種形式的、可信賴的驗證標(biāo)準(zhǔn)或高質(zhì)量樣本，對嗎？

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

第一種是針對具有明確規(guī)則和目標(biāo)的確定性系統(tǒng)，例如棋類游戲（圍棋、國際象棋）或許多編程任務(wù)。在這些場景下，存在清晰的成功標(biāo)準(zhǔn)或優(yōu)化目標(biāo)。例如，對于一個需要分析性能瓶頸的 CUDA 內(nèi)核，其優(yōu)化目標(biāo)（如降低延遲、提高吞吐量）通常是明確且可量化的。

第二種，我們可以稱之為“與已知事實保持一致性”（consistency with ground truth knowledge）。打個比方，假設(shè)我明天需要涉足量子物理學(xué)領(lǐng)域（一個我完全不了解的領(lǐng)域），如果有人給了我一個關(guān)于量子物理學(xué)的陳述，我要判斷其真?zhèn)危托枰ゲ殚喸擃I(lǐng)域的基準(zhǔn)知識來源，比如教科書、權(quán)威論文等，然后檢查這個陳述是否與這些已知的、公認(rèn)的事實相符。

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

主持人：我知道我們剛才的討論深入到了一些非常技術(shù)性的細(xì)節(jié)，希望大家還能跟上節(jié)奏——當(dāng)然，深入探討技術(shù)細(xì)節(jié)也正是大家來參加本次討論的目的。現(xiàn)在，讓我們轉(zhuǎn)換一下話題，談?wù)勥z留代碼（legacy code）的問題。這是一個普遍存在的重大挑戰(zhàn)。具體到 CUDA，遺留代碼往往受到硬件更迭、API 演進(jìn)等多種環(huán)境因素的影響。但更廣泛地說，所謂的“棕地”（brownfield）項目——即在現(xiàn)有代碼基礎(chǔ)上進(jìn)行開發(fā)和維護(hù)——是我們所有開發(fā)者都必須面對的現(xiàn)實。

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

阿比納夫（馬里蘭大學(xué)）：對于大型的 CUDA 代碼庫，特別是那些 CUDA 內(nèi)核散布在整個項目中的情況，目前比較有效的方法通常是聚焦于單個內(nèi)核進(jìn)行處理，例如，嘗試將其移植到新的硬件架構(gòu)或?qū)ζ溥M(jìn)行性能優(yōu)化。

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

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

主持人：比如更改依賴關(guān)系或重構(gòu)以使用某個庫。莎娜，根據(jù)你在我們更大規(guī)模項目上的經(jīng)驗?zāi)兀?/strong>

莎娜（NVIDIA）：我個人通常不直接處理規(guī)模極其龐大的代碼庫，但即使在單個 CUDA 內(nèi)核的層面上，情況也可能變得相當(dāng)復(fù)雜。因為對于 CUDA 而言，當(dāng)新的 GPU 架構(gòu)問世時，你原有的舊代碼雖然通常仍然可以運行，但其性能往往不再是最優(yōu)的。如果性能不是最優(yōu)，那么使用 CUDA 加速的意義就大打折扣了。因此，開發(fā)者確實需要針對每一代新的 GPU 重新審視和調(diào)整之前的優(yōu)化策略。

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

主持人：所以，這聽起來似乎需要在應(yīng)用層面進(jìn)行某種評估或檢測（可能是在運行時，也可能是在進(jìn)行大規(guī)模重構(gòu)或更改之前），以確定需要進(jìn)行的調(diào)整。妮哈，這種持續(xù)適應(yīng)和更新的需求，與你之前描述的 AI 輔助開發(fā)的愿景是如何契合的？

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

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

在處理遺留代碼的軟件開發(fā)生命周期（SDLC）中，“理解”（Understanding）是一個至關(guān)重要的環(huán)節(jié)。我確實認(rèn)為 AI 在這方面可以發(fā)揮重要作用。雖然目前可能還沒有足夠成熟的工具，但未來 AI 具備遍歷代碼庫、篩選關(guān)鍵信息、并輔助開發(fā)者進(jìn)行探索性理解的能力，將對學(xué)習(xí)和上手過程非常有幫助。

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

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

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

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

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

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

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

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

“智能體”（Agent）這個術(shù)語在我們的領(lǐng)域確實有些被濫用。但其核心思想——讓模型采用多步驟的方法來解決復(fù)雜問題，模擬人類開發(fā)者打開文件、檢查代碼、跟蹤依賴等行為——是解決大規(guī)模代碼理解和修改問題的關(guān)鍵組成部分。我們正看到 AI 在這個方向上展現(xiàn)出良好的發(fā)展?jié)摿ΑＨ欢@并不意味著它不受當(dāng)前模型固有局限性的影響，即模型即使在單一步驟上的可靠性也并非 100%，并且在多步驟任務(wù)中，準(zhǔn)確性可能會迅速下降。因此，我們當(dāng)前的核心工作——持續(xù)推動基礎(chǔ)模型能力的提升——就顯得至關(guān)重要。

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

不過，對于在座的各位——我毫不懷疑從事加速計算開發(fā)的專業(yè)人士可能是目前對 AI 持懷疑態(tài)度最強(qiáng)烈的群體之一，并且你們完全有理由如此，因為這恰恰是當(dāng)前 AI 表現(xiàn)相對薄弱的領(lǐng)域之一——我有一個具體的建議：找出三到四個對你們來說至關(guān)重要的、代表性的開發(fā)任務(wù)，這些任務(wù)是當(dāng)前 AI 模型還無法很好完成的，將它們作為你們個人的“黃金評估集”（golden evaluation set）。

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

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

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

那么，在你們各自的領(lǐng)域，你們會使用哪些關(guān)鍵任務(wù)或標(biāo)準(zhǔn)來判斷一個 AI 智能體或代碼生成系統(tǒng)是否取得了實質(zhì)性的進(jìn)展或達(dá)到了可用的水平？我知道對于 CUDA 和加速計算領(lǐng)域的專家來說，這些標(biāo)準(zhǔn)可能與通用編程領(lǐng)域有所不同。

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

我期望未來能達(dá)到這樣一種狀態(tài)：我可以不斷提高對工程團(tuán)隊的要求和標(biāo)準(zhǔn)，賦予他們更多的職責(zé)，而 AI 能夠有效地輔助他們。當(dāng)我考慮我的團(tuán)隊（大約有 500 名工程師）時，我希望在提升標(biāo)準(zhǔn)（例如，要求他們同時負(fù)責(zé)高性能代碼、數(shù)據(jù)容量管理、可訪問性，并確保代碼功能正確且可擴(kuò)展）的同時，不會讓他們負(fù)擔(dān)過重。我希望 AI 能夠在這方面提供支持，比如在代碼審查環(huán)節(jié)提供有價值的建議，甚至成為他們學(xué)習(xí)和探討技術(shù)方案的“伙伴”。所以，總結(jié)來說，我的兩個關(guān)鍵測試領(lǐng)域是代碼重構(gòu)和語言轉(zhuǎn)換。我們正在取得進(jìn)展，但尚未完全達(dá)到理想狀態(tài)。

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

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

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

因為我們觀察到，也許幾個月前，某些復(fù)雜的代碼轉(zhuǎn)換任務(wù) AI 完全無法完成，即使我們嘗試提供調(diào)試信息。但隨著時間的推移，模型在理解和應(yīng)用這些信息方面有所改進(jìn)，我們希望看到達(dá)到正確結(jié)果所需的迭代次數(shù)能夠逐漸減少。

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

我希望 AI 智能體能夠準(zhǔn)確理解這個需求中的關(guān)鍵概念：什么是“客戶數(shù)據(jù)”？什么是“加密”？哪些操作構(gòu)成了“傳輸”行為？這項任務(wù)的挑戰(zhàn)在于，相關(guān)的邏輯可能完全分散在代碼庫的不同層面和模塊中。要完成這項任務(wù)，AI 需要具備伊索之前提到的那種在代碼庫中進(jìn)行導(dǎo)航和推理的能力。它需要能夠理解所有這些分散的部分，并將它們聯(lián)系起來，作為一個整體流程進(jìn)行驗證。我們目前還沒有完全達(dá)到這個水平，但我認(rèn)為我們正在逐步接近。

主持人：好的，接下來我們直接進(jìn)入提問環(huán)節(jié)。

觀眾提問：我的問題是關(guān)于帶有自動驗證的強(qiáng)化學(xué)習(xí)。特別是在處理復(fù)雜軟件項目（例如您提到的在 Docker 容器中運行的完整代碼倉庫）時，您如何設(shè)計自動驗證規(guī)則，以防止模型找到“取巧”或“鉆空子”（gaming the system）的方法來滿足規(guī)則，而不是真正解決問題？

對于 CUDA 加速，目標(biāo)通常很明確（例如提升性能指標(biāo)），但對于更廣泛的、涉及整個軟件項目的復(fù)雜任務(wù)，如何設(shè)定有效的、不易被“游戲化”的驗證標(biāo)準(zhǔn)呢？

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

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

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

當(dāng)然，最終我們會遇到一個挑戰(zhàn)：如何為那些非常高層次、抽象的，并且難以找到現(xiàn)成示例的目標(biāo)任務(wù)定義有效的學(xué)習(xí)信號？這時，之前提到的“套利”方法又可以發(fā)揮作用。例如，你可以選取一個現(xiàn)有的復(fù)雜項目（比如一個性能分析器的代碼庫），讓一個強(qiáng)大的模型去深入理解它，然后嘗試讓模型反向生成該項目的目標(biāo)描述或高級設(shè)計規(guī)范。本質(zhì)上，我們是在不斷地以真實世界的復(fù)雜數(shù)據(jù)作為“種子”，從不同角度對其進(jìn)行加工和利用，目標(biāo)是生成可用于訓(xùn)練的任務(wù)描述、用于驗證的測試用例，或者作為示例的解決方案代碼。理論上，甚至可以嘗試同時合成這三者，并且這種方法在一定程度上是可行的。但是，如果能獲得一些高質(zhì)量的真實基準(zhǔn)真相數(shù)據(jù)作為基礎(chǔ)，效果通常會更好。同時，我們也希望模型能夠在真實、多樣化的環(huán)境中學(xué)習(xí)，而不僅僅是局限于某些特定類型的、可能被過度簡化的任務(wù)。

觀眾提問：我想向 GitHub 的嘉賓提問。您之前提到了代碼重構(gòu)，并表示在這個領(lǐng)域正取得進(jìn)展。對于小規(guī)模的軟件或應(yīng)用程序，AI 輔助重構(gòu)或許是可行的。但對于非常大規(guī)模的系統(tǒng)（例如數(shù)十萬行甚至更多代碼），尤其是那些包含混亂的“意大利面條式代碼”（spaghetti code）或復(fù)雜遺留結(jié)構(gòu)的系統(tǒng)，您認(rèn)為 AI 未來將如何處理這類大型系統(tǒng)的重構(gòu)挑戰(zhàn)？

妮哈（GitHub）：我認(rèn)為，一個非常重要的原則是，只要人類開發(fā)者仍然是開發(fā)流程中的關(guān)鍵一環(huán)——而且我個人傾向于在可預(yù)見的未來保持這種“人機(jī)協(xié)作”的模式——我們就應(yīng)該確保 AI 的工作方式不應(yīng)過度偏離人類的最佳實踐。因此，即使是在與純?nèi)祟悎F(tuán)隊合作時，我也通常不希望看到一次性涉及上百個文件的大規(guī)模、原子性的重構(gòu)提交，除非有極其充分的理由。我更傾向于鼓勵開發(fā)者將大型重構(gòu)任務(wù)分解成更小、更易于管理和審查的步驟。

類似地，當(dāng)涉及到與 AI “隊友”協(xié)作進(jìn)行重構(gòu)時，我認(rèn)為正確的方式也應(yīng)該是從小規(guī)模、可控的重構(gòu)開始，然后逐步擴(kuò)展其應(yīng)用范圍。我們需要確保在這個過程中，人類開發(fā)者能夠理解、驗證并對結(jié)果感到“舒適”或有信心，因為歸根結(jié)底，我們是在與這些 AI 系統(tǒng)協(xié)同工作。

所以我目前并不認(rèn)為我們能夠、或者應(yīng)該期望 AI 一次性完成涉及兩三百個文件的重大重構(gòu)。主要原因在于，我們?nèi)匀恍枰獙ψ罱K合并到代碼庫中的代碼負(fù)責(zé)，這意味著我們需要能夠理解這些更改。因此，我的回答是，在設(shè)計和應(yīng)用 AI 輔助重構(gòu)方案時，我們必須始終考慮到最終使用和審查這些代碼的人類開發(fā)者。這又回到了信任和責(zé)任的問題上。即使未來 AI 的能力發(fā)展到足以處理非常大規(guī)模的重構(gòu)任務(wù)，我們可能仍然需要將其分解成人類可以理解、審查并最終負(fù)責(zé)的較小單元。

觀眾提問：我有一個關(guān)于生成式 AI 模型能力的問題。我們看到一些報道或基準(zhǔn)測試聲稱，最新的模型能夠在編程競賽中取得非常好的成績，甚至“擊敗”頂尖的人類競賽選手。但與此同時，當(dāng)我們在真實的、復(fù)雜的軟件開發(fā)場景中測試這些模型時，它們似乎又經(jīng)常失敗。

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

伊索（Poolside）：原因其實相對直接。與真實世界的軟件開發(fā)相比，編程競賽是一個更容易針對性優(yōu)化的任務(wù)領(lǐng)域。這是因為競賽編程的問題域通常范圍更窄，目標(biāo)更明確（例如，通過所有測試用例并優(yōu)化時間和空間復(fù)雜度），更容易將其轉(zhuǎn)化為一個清晰的強(qiáng)化學(xué)習(xí)目標(biāo)，從而可以通過大量訓(xùn)練顯著提升模型在該特定任務(wù)上的表現(xiàn)。

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

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

艾蘭（Tabnine）：我完全同意伊索的觀點。如果允許我補(bǔ)充一點，那就是為真實世界的企業(yè)級軟件開發(fā)任務(wù)（例如，執(zhí)行一項復(fù)雜的代碼變更）創(chuàng)建有效的、有代表性的基準(zhǔn)測試本身就極其困難。其難度遠(yuǎn)超創(chuàng)建編程競賽類型的基準(zhǔn)測試。因此，我們看到的差異，部分也源于評估真實世界能力的基準(zhǔn)測試本身的構(gòu)建難度。

主持人：正好借此機(jī)會宣傳一下，如果大家感興趣，可以去 GTC 大會 NVIDIA 展位的 AI 開發(fā)者工具團(tuán)隊展臺了解一下。我們正在發(fā)布一個名為ComputeEval的新基準(zhǔn)測試。這個基準(zhǔn)測試旨在更準(zhǔn)確、更全面地反映企業(yè)級規(guī)模的軟件開發(fā)問題，特別是針對 CUDA 編程的挑戰(zhàn)，并且充分考慮了剛才討論的這些因素。當(dāng)然，這個基準(zhǔn)測試是否真正有效，還有待業(yè)界的檢驗和反饋。在此也呼吁所有致力于評估方法研究的同仁們，繼續(xù)努力為我們的行業(yè)創(chuàng)建更好、更貼近實際的評估標(biāo)準(zhǔn)。

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

* 歡迎回顧這篇經(jīng)典討論：《》

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

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

但是，你提出的核心問題是對的：從根本上驗證一個復(fù)雜智能系統(tǒng)的內(nèi)部狀態(tài)或“真實意圖”，很可能是一個不可判定的問題，因為它本質(zhì)上是一個極其復(fù)雜的驗證（verification）問題。

妮哈（GitHub）：我想到了一個俗語——“手里拿著錘子，看什么都像釘子”。這個比喻之所以適用，是因為我們有時會陷入一種思維定式：當(dāng)我們初次接觸 AI 時，可能會預(yù)設(shè)“只有當(dāng)它完全可信時，我才會這樣或那樣使用它”。但即使一個系統(tǒng)并非完全可信（就像邏輯謎題中那些已知總是在說謊的角色），我們?nèi)匀豢梢詮闹蝎@取有用的信息或洞見。

人類的適應(yīng)性非常強(qiáng)，關(guān)鍵在于我們能否找到有用的方式來利用這些不完美的工具，并讓它們幫助我們做出更好的決策。我不認(rèn)為我們應(yīng)該因為潛在的不可信風(fēng)險就完全放棄 AI。即使一個系統(tǒng)在某些方面不完全可靠（當(dāng)然，我個人對未來是樂觀的），它仍然可能在其他方面幫助我們編寫更好的代碼或提高效率。最終，這取決于我們?nèi)绾卧O(shè)計與 AI 的交互方式，如何明智地選擇應(yīng)用場景，而這需要我們進(jìn)行深入的研究，并不斷探索最佳實踐。

伊索（Poolside）：我了解你提到的那篇論文，這觸及了 AI 安全（AI Safety）的核心議題。那么，在信任問題之外（我基本同意艾蘭和妮哈的觀點），我們確實必須在不遠(yuǎn)的將來正視一個現(xiàn)實：我們正在創(chuàng)造出智能水平可能與人類相當(dāng)甚至超越人類的系統(tǒng)，并且這些系統(tǒng)很快將具備規(guī)劃和執(zhí)行長期復(fù)雜任務(wù)的能力。

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

但是，隨著我們越來越接近通用人工智能（AGI）或其他形式的強(qiáng)大 AI 的“臨界點”，我們亟需加強(qiáng)關(guān)于 AI 安全和對齊的討論與研究。就我個人而言，我對此持謹(jǐn)慎樂觀的態(tài)度，因為我們參與了模型訓(xùn)練的全過程，并且正通過強(qiáng)化學(xué)習(xí)等技術(shù)，越來越多地嘗試為模型施加更嚴(yán)格的倫理和行為約束。我相信這些是可以通過持續(xù)努力來改進(jìn)和解決的問題。

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

我想提及我們一個非常值得尊敬的競爭對手——Anthropic，他們在探索 AI 安全的“黃金標(biāo)準(zhǔn)”方面，為整個行業(yè)樹立了很好的榜樣。但總的來說，我們所有人都還處于這個征程的早期階段。

* 本文由 CSDN 精編整理。

* 本場對話源自 GTC 2025，日程為北京時間 2025 年 3 月 22 日 0:00 AM - 1:00 AM。

點擊鏈接回顧：

5. AI 軟件開發(fā)生命周期的瓶頸

【活動分享】2025 全球機(jī)器學(xué)習(xí)技術(shù)大會（ML-Summit）將于 4 月 18-19 日在上海舉辦。大會共 12 大主題、50+ 位來自學(xué)術(shù)界和一線技術(shù)實戰(zhàn)派的頂尖專家，聚焦下一代大模型技術(shù)和生態(tài)變革技術(shù)實踐。詳情參考官網(wǎng)：http://ml-summit.org/。