簡短回答。 NVIDIA 內部代理飛輪的案例是最清晰的實例：495 個不滿意響應，其中由一個大語言模型作為評判者標記出140 個路由錯誤，隨後領域專家手動進行了審查。該精選數據集共685 個數據點，按 60/40 比例劃分為訓練集和測試集，顯著提升了小模型的性能。關鍵細節在於評判者的用途——自動化評估是一種篩選手段，用於減少需要人工審查的樣本數量，而非最終結論；將評判結果視為真實基準，正是飛輪開始基於自身錯誤進行訓練的起點。
訓練數據？
NVIDIA 公佈的內部代理飛輪說明中有一組數字，比任何圖表都更清楚地揭示了其運作機制。
他們從生產環境中提取了 495 個不滿意響應。一個自動化的大語言模型作為評判者識別出 140 個是由於路由錯誤導致的。隨後，領域專家手動審查了這 140 個案例，並確認了其中 32 個確實是真正的路由錯誤。
標記出 140 個。真正存在 32 個。
這大約相當於自動化分類步驟的 77% 假陽性率，是在一個資源充足、由專業人員長期構建該基礎設施的項目中得出的。但這並非該方法的失敗，而是該方法本應實現的目標：自動化評估的作用是將 495 個樣本篩選至 140 個，從而讓昂貴的人工審查僅針對 140 個而非全部 495 個樣本。
最終產出是一個經過精心整理的真實基準數據集，包含 685 個數據點，按 60/40 比例劃分為訓練集和測試集。藉助該數據集，他們顯著提升了小模型的性能。
685 個示例。這是另一個值得深思的數字，因為它挑戰了‘飛輪’通常被認為依賴大量數據的直覺。
數據飛輪實際上是什麼
定義非常直接：一個反饋循環，其中從交互或流程中收集的數據被持續用於優化AI模型，而優化後的模型又會產生更好的結果和更有價值的數據。
複合性論點使其極具吸引力。更多數據會提升模型性能，模型性能提升後會改善應用效果，從而帶來更高的業務價值，吸引並留住更多用戶，進而產生更多數據。
最常被引用的類比是特斯拉：數百萬英里行駛里程，捕捉到的邊緣案例，被反饋到訓練中。汽車變得更好，數據質量提升，循環速度加快。
但其背後的戰略主張比循環圖更有趣，它正是業務案例所在之處。核心論點是：AI代理的持續改進並不需要不斷升級到更大的模型。它只需要系統性的反饋循環，使較小、更便宜、更快的模型能夠達到或接近大型模型的準確率。
這將飛輪從一個質量舉措重新定義為一個成本計劃。你不再追求更強大的模型，而是追求在更低延遲和更低總擁有成本的情況下實現相同的準確率。
循環的各個階段
捕捉。推理日誌、提示詞、響應、檢索軌跡、工具調用、延遲以及用戶反饋信號。這些數據被存儲在某個可查詢的位置，常見的架構中使用Elasticsearch（如NVIDIA和MLRun架構）。
監控和檢測。持續跟蹤性能、穩定性和資源使用情況，主動發現需要審查的候選案例，而不是等待投訴出現。
自動化分揀。利用大語言模型作為裁判和在線評估，縮小候選案例池。這是從495到140的步驟。
人工審查。領域專家確認哪些標記案例是真實的，並正確標註它們。這是從140到32的步驟，也是真實基準實際被建立的地方。
構建數據集。經過確認的案例成為訓練和評估數據集，並進行劃分。
定製化。通過LoRA、p-tuning或監督微調，針對已構建的數據集進行微調。
評估。候選模型在生產日誌和預留數據上運行，採用零樣本、檢索增強生成（RAG）和大語言模型作為裁判的評估方式。
重新部署。優化後的模型上線運行，並生成下一輪日誌。
協調是將這一流程從項目轉變為系統的關鍵。在參考實現中，協調器會封裝整個循環，當日志滿足預定義條件時，觸發評估和定製化流程，並在需要人工決策時升級至人工參與。
為什麼速度才是真正的約束
在從業者文獻中，有一個論點我認為被低估了，它解釋了為什麼手動飛輪會失敗，而不是僅僅表現不佳。
手動流程在規模化時會崩潰。當你已經審查了示例、標註了數據、重新訓練並部署後，生產系統已經發生了變化。需求發生了改變，新的邊緣案例出現了。你總是處於追趕狀態。
這是一種不同於‘數據不足’的失敗模式。一個需要十一週才能完成一個循環的飛輪，並不是一個慢的飛輪，而是一個靜止的飛輪，其改進程度是基於一個已經不存在的分佈進行校準的。
因此，真正重要的是閉環週期，而不是數據集大小。圍繞200個樣本、幾天內就能完成一輪改進的閉環，優於圍繞20,000個樣本卻要一個季度才能完成一輪的閉環。
飛輪悄然出錯的地方
四種失敗模式，這些模式在供應商的圖表中均未出現。
日誌中的倖存者偏差。你的生產日誌包含的是那些持續使用系統的用戶交互。那些用戶提出問題後系統處理得不好，然後就不再回來，只留下一條壞日誌，之後便沒有記錄。而那些發現系統有用並持續使用的用戶，則會生成數百條日誌。因此，日誌的分佈過度反映了已經有效的情況，飛輪會最優化那些需要最少幫助的案例。
這是結構性的，不會通過數據量的增加自行修復。它需要有意識的反向平衡：採樣被放棄的會話、追蹤首次交互流失情況、將某個群體缺乏日誌記錄視為發現而非數據缺失。
自動化分類被當作真實基準。140到32的漏斗是警告。如果NVIDIA在所有140個標記案例上進行了微調，那麼大約四分之三的訓練信號將是錯誤的，模型就會學會糾正那些本已正確的路由決策。自動化評估縮小了搜索空間，但它並不做出判斷。
在未驗證的情況下，僅基於自身輸出進行訓練。一個捕捉模型響應、用模型進行評判並基於結果進行訓練的飛輪，是一個沒有外部錨點的遞歸循環。模型崩潰文獻明確指出，基於合成數據的遞歸訓練會損害模型性能，罕見案例會最先消失，而緩解方法是引入驗證和積累真實的人類錨定數據，而不是簡單地用新數據替代。在該循環中，人工審核不是質量上的附加項，而是阻止飛輪自我吞噬的關鍵錨點。
隱私與地域管轄權，幾乎沒有人真正關注。生產日誌屬於用戶數據，其中包含個人信息，有時涉及敏感類別，因此同樣受跨境數據傳輸規則的約束。一個在某一司法管轄區採集日誌、在另一司法管轄區用於訓練的飛輪，無論流程中是否有人將其稱為數據傳輸，本質上都構成數據跨境流動。為服務交付設計的同意條款，並不自動涵蓋模型訓練，而事後補上這些條款，比在數據採集階段就正確設計要困難得多。
沒有人明確說明的限制
這裡就是結構性約束，我認為在投資飛輪之前，理解這一點最為關鍵。
飛輪會放大你已有的能力，但它無法從零開始構建你尚未具備的內容。
如果您的產品在印度尼西亞沒有用戶，那麼您的日誌中就不存在印度尼西亞用戶的交互記錄。飛輪無法提升印度尼西亞語言的性能，因為沒有數據可以輸入。而由於模型在印度尼西亞語言上表現不佳，用戶採納率也保持低下，導致日誌持續為空。這個循環是反向運行的：薄弱的覆蓋範圍導致低使用率，進而導致無數據，最終導致持續的薄弱覆蓋範圍。
同樣的情況適用於任何你服務得不夠好以至於用戶離開的領域、任何你尚未進入的市場，以及任何罕見到幾乎不會出現的邊緣情況。
這意味著，飛輪機制是提升你已經擅長領域的絕佳工具，而在你尚未涉足的領域，它則毫無用處。這些領域需要專門採集：數據是刻意生產出來的，而不是從尚未存在的流量中採集而來。
這正是我們自身工作的現狀，因此我將聲明利益關係。Lifewood 在超過50種語言中收集並標註數據，我們反覆觀察到的模式是：一個客戶在兩種或三種語言上擁有成熟飛輪，但在其希望拓展的市場中表現平平。飛輪正完全按照設計運行，但它無法為尚未存在的用戶生成日誌。
我們實際採用的框架是：對於你已經擁有的語言，使用飛輪機制；對於你希望進入的語言，則採用專門採集。一旦某個市場達到足夠使用量，飛輪機制便接管，採集成本隨之停止。在此之前，沒有任何內容可以被“轉動”。
人工層，以及為何685個示例就足夠了
回到NVIDIA的數據，因為其中包含了本領域最有用的教訓。
685個精心挑選的數據點顯著提升了小型模型的性能。不是685,000個。價值完全集中在‘篩選’環節：自動化流程篩選出候選數據，領域專家則判斷哪些是真實存在的，以及正確的行為應如何體現。
這正是數據工作領域反覆出現的發現：一個規模小、準確、目標明確的數據集，其表現優於一個規模大但雜亂無章的數據集，而成本主要體現在使其準確，而非使其規模擴大。
對於飛輪而言，三個需要人工參與的角色是承載負載的：
領域專家，能夠判斷被標記的故障是否確實屬於故障。這需要領域知識，而非標註培訓。
評審員，他們需要定義正確的行為，而不僅僅是識別錯誤行為。知道路由是錯誤的只是標籤的一半；知道它應該走向哪裡才是另一半，而這部分更難。
負責制定採樣策略的人，因為被評審的內容決定了被修復的內容，而自動標記繼承了判斷模型所存在的任何偏見。
這些角色都不是一般標註池能夠勝任的工作，這與推理軌跡工作和偏好數據的結論一致。模式是統一的：隨著數據越來越接近判斷層面，標註員的資質從經過培訓轉向具備專業資格。
在不構建完整系統的情況下起步
從業界實際運行這些系統的實踐者那裡獲得的建議異常具體，值得嚴格遵循。
選擇一個高價值的改進領域。安全、準確性或響應風格。僅選擇其中之一。
為該特定問題設立在線評估，而非進行一般性的質量監控。
收集100到200個標註示例。這是推薦的初始樣本量，NVIDIA的案例表明，對有用結果而言，實際有效上限低於大多數團隊的預期。
將從日誌到重新部署的週期時間作為您的主要運營指標進行衡量。
在自動化標記和數據集納入之間始終設置人工確認步驟，140比32的比例是論據。
監控缺失的內容，而不僅僅是失敗的內容。例如被中止的會話、未得到回應的查詢、未產生流量的片段。
在數據採集時就解決同意和居住地問題，因為事後為一年積累的日誌數據補充合法使用依據，遠比在第一天就正確編寫要困難得多。
關鍵要點
- NVIDIA內部代理的飛輪機制處理了495個不滿意響應，通過LLM作為裁判標記了140個路由失敗案例，領域專家最終確認僅有32個是真實情況，自動化分類的誤報率大約為77%。
- 由此產生的精煉數據集包含685個數據點，按60/40比例劃分為訓練集和測試集，並顯著提升了小模型的性能。
- 自動化評估是一個過濾器，用於減少審核樣本量。它並非判斷，不應被視為真實基準。
- 數據飛輪是一種反饋循環，其中交互數據持續優化模型，從而產生更優的結果和更有價值的數據。
- 戰略主張是：持續改進無需更大規模的模型，而是通過系統性的反饋循環，使較小模型在更低延遲和成本下達到與大模型相當的性能。
- 該循環運行流程為：採集、監控、自動化分層、人工審核、精選、定製、評估、重新部署，通過流程編排將其從一個項目轉變為一個系統。
- 週期時間是關鍵制約因素，而非數據集規模。手動流程會失效，因為等到你完成審核、標註、重新訓練和部署時，生產環境的分佈已經發生了變化。
- 倖存者偏差是結構性的：日誌過度反映了留存用戶，因此飛輪會最優化那些實際上所需幫助最少的場景。
- 在模型輸出由無人工錨定的模型進行評判的情況下，訓練過程是遞歸的，而模型坍塌文獻表明，這種做法會導致模型性能下降，且罕見案例會最先丟失。
- 生產日誌屬於用戶數據，受數據傳輸和同意規則的約束。服務交付的同意並不自動涵蓋訓練用途。
- 飛輪會放大你已有的能力，卻無法為不存在的東西提供啟動動力。市場中沒有用戶意味著沒有日誌數據，進而沒有改進機會，這將導致低採納率。
- 為已有語言和細分市場構建飛輪；為希望進入的新領域委託專項數據採集。
- 三個關鍵的人類角色承擔著核心職責：領域專家用於判斷真實失敗案例，評審員負責定義正確行為而非僅標記錯誤行為，以及負責制定採樣策略的負責人。
- 實踐者初始建議：選擇一個改進方向，為其專門搭建在線評估體系，並收集100到200個標註示例。
資料與進一步閱讀
- ZenML LLMOps數據庫，"Nvidia: Data Flywheels for Cost-Effective AI Agent Optimization"，在NV Info Agent架構、495到140到32的分層篩選流程、685個點的精選數據集以及小型模型研究論文上的應用
- NVIDIA術語表，"Data flywheel: What it is and how it works"，關於飛輪的定義、AT&T的部署案例以及飛輪項目的核心商業目標
- NVIDIA，"Build an Enterprise Data Flywheel" 戰略藍圖，關於自動循環收集生產流量日誌、評估、微調並重新部署的流程
- Iguazio，《使用MLRun和NVIDIA NeMo微服務構建面向生產環境的可觀測數據飛輪》，介紹流程編排、日誌存儲、NeMo Customizer中的LoRA和p-tuning等技術，以及NeMo Evaluator的評估方法
- Iguazio 術語表，"什麼是數據飛輪？"，關於複合循環和持續改進機制
- Arize AI，"利用 Arize AX 和 NVIDIA NeMo 構建更智能的 AI 系統的數據飛輪"，關於週期時間作為約束條件、人工流程分解論點以及 100 到 200 個示例的起點
- "人工參與閉環：面向基於大語言模型的客戶支持的持續改進數據飛輪"，arXiv
- Shumailov 等人，"當 AI 模型在遞歸生成數據上訓練時會發生崩潰"，Nature，關於遞歸訓練退化問題，此前本系列已討論過。DOI 10.1038/s41586-024-07566-y Lifewood，多語言數據收集和人工參與閉環 AI 數據服務