如何建設人人都能訓的大模型技術氛圍

演講嘉賓｜呂昕

編輯 ｜Kitty

策劃 ｜QCon 全球軟件開發大會

在大模型算法快速迭代演進的背景下，業務研發人員負責工程、算法研究人員負責模型優化的協作模式，已經無法滿足大模型產品快速創新、模型效果快速迭代的業務需求，業務團隊需要建設自有的大模型優化能力。如何建設一個人人都能訓大模型的技術氛圍，已成為加速大模型業務落地、推動組織創新與發展的關鍵。

2025 年 4 月，在 InfoQ 舉辦的 QCon 全球軟件開發大會 上，科大訊飛消費者 BG 大數據研發部總監呂昕分享了“如何建設人人都能訓的大模型技術氛圍”，他從平臺基礎設施、大模型思維、協作文化 3 個角度，闡述如何建設“人人能用、人人會訓”的大模型文化，有效提升組織效能，進而推動業務的持續成長。

預告：2026 年 QCon 北京站策劃了「AI 時代的“超級團隊”」專題，將探討如何彌補人與 AI 的能力鴻溝，重構產品與技術的協作關系，并建立一套適應 AI 時代的全新管理與度量體系，打造高適應性、高產出的“超級團隊”。如果你也有相關方向案例想要分享，歡迎提交至

https://jinshuju.com/f/Cu32l5

以下是演講實錄（經 InfoQ 進行不改變原意的編輯整理）。

大模型時代組織創新的必要性

大模型時代創新的必要性在于，無論是 C 端還是 B 端業務，直接使用大模型完成工作都存在困難，需要進行優化。每個業務線或單元都有必要自己訓練大模型，我的分享一方面可以幫助小團隊或業務線從 0 到 1 建設大模型訓練能力，另一方面能讓想轉大模型的工程人員了解如何轉型。

大模型算法優化的幾種模式

從業務優化需求來看，C 端業務場景零散但可劃分到特定場景優化，業務線要求高且效果優化永無止境，核心是圍繞用戶場景建立數據和快速優化能力。B 端業務以解決方案為主，對效果要求相對有限，主要是滿足國產化和安全要求，達到可用即可。

大模型優化模式與傳統機器學習有所不同。傳統機器學習中，算法需求由算法研究人員或團隊主導，業務線研發主要負責部署上線和維護。而在大模型時代，特征工程基本不存在，但出現了兩種新的合作模式：一種是以算法研究人員為主，業務線輔助定義需求、標數據等；另一種是以業務線為主導，算法人員輔助問題定義與選型、模型訓練。DeepSeek 等技術的出現，使得業務線或產品線有可能自己優化大模型訓練效果，不再依賴算法輔助。

大模型吋代的 BLM 模型

從組織架構角度，各個業務線更希望業務線自己訓練大模型。因為大模型技術發展迅速，戰略需靈活調整，組織活力需進一步激活，以實現敏捷創新和更好的信息拉齊與穿透。傳統的算法團隊與工程團隊分開的模式已不能滿足業務發展需要，每個業務線或團隊都需要具備從 0 到 1、端到端優化大模型的能力。

在大模型時代，DeepSeek 的出現既帶來了危機也帶來了機遇。它在基礎模型方面表現出色，一些場景直接使用深度探索就能取得不錯的效果。同時，開源生態的成熟，包括訓練框架、推理框架和智能代理框架，降低了訓練基礎設施的建設成本。通過蒸餾深度探索，可以快速構建高質量數據，如思維鏈數據，節省了大量人工標注成本。此外，模型優化范式也在變革，從之前的底座模型訓練和監督微調（SFT），轉變為現在的知識蒸餾，并且廣泛采用 GRPO 來優化效果。

從 0 到 1 自建大模型優化能力面臨的問題

業務線如果想自己從 0 到 1 建設大模型的優化能力，會面臨諸多挑戰。首先是基礎設施的缺失，包括算法、算力、平臺、數據，以及訓練框架和推理框架。其次是缺乏算法優化經驗，不清楚如何選擇模型、技術方案，如何評估和優化效果。最后是人才短缺，不清楚需要什么樣的人才、到哪里找以及需要掌握哪些技術棧。

大模型效果優化團隊的協作與流程

在大模型時代，對研發崗位的要求也發生了變化。核心崗位包括大模型算法工程師和大模型測試工程師。大模型算法工程師相比傳統搜索、廣告、推薦算法工程師，門檻降低，需要調的參數少，但需要更好的業務感知能力，將業務需求轉化為大模型優化場景，并具備創新思維和前沿跟進能力。大模型測試工程師相比傳統測試工程師，需要更高的自動化測試要求，能夠基于業務感知能力自動化構建大模型測試樣本和制定測試標準。除了這兩個核心崗位，還有其他崗位，如提示詞工程師因天花板低和深度探索出現后需求減少而不再熱門；大模型平臺架構師、大模型平臺開發工程師和大模型應用開發工程師這些崗位和傳統軟件開發崗位基本沒有太大區別。

在研發和測試的協作方面，之前讓團隊野蠻發展，未重視項目管理，導致模型訓練完成、上線前測試環節出現問題，訓練樣本與業務未對齊，浪費了大量時間。因此，我增加了樣本評估環節，要求在訓練前與業務線對齊樣本，確保樣本能滿足業務需求。同時要求每次算法上線時提供詳盡的自測報告和提示詞文檔，明確參數設置等細節，以避免因參數錯誤導致的測試問題，因為大模型訓練結果是黑盒，測試時不易發現問題。

建設人人能訓大模型的基礎設施

大模型優化平臺的建設

基于我對整個平臺架構設計的理解，基本分為三層。最底層是基礎設施，公有云可以解決 90%，甚至 100% 的問題。因為業務線的訓練樣本數和情況一般不支持訓練 32B 以上的模型，32B 的全參訓練是上限。此時租用幾十張顯卡基本能解決大部分訓練問題，大部分業務場景 7B 模型也能搞定。所以公有云租卡基本能解決 90% 的訓練和部署問題。在訓練的第二層是訓練工具。這里使用了公司內部已有的星火訓練平臺，同時也基于開源搭建了相關工具，開源生態的成熟對此幫助很大。再往上是大模型應用開發的三個工程：數據工程、模型工程和 Agent 工程，也可稱為大模型的應用開發。核心需要自己擴建設的資源主要是數據資源和應用開發資源。數據資源方面，要掌握如何通過調用 API 構建樣本，如何蒸餾 Deepseek，公有云的 API 基本能滿足需求。應用開發方面，主要涉及 Agent 和 RAG。Agent 的開源項目眾多，star 超過 1000 的都有 50 個左右，可以基于開源搭建自己的 Agent 和 RAG 平臺。如果想低成本建設從 0 到 1 的基礎設施，利用公司內部資源復用和擁抱開源，基本能解決所有問題。

開源模型的技術選型

有了基礎設施后，簡單介紹一下開源技術棧。之前沒顯卡時還考慮過 Qlora，但后來發現 32B 模型的 Lora 訓練，16 張顯卡基本都能搞定，沒必要再用 Qlora。在模型選型上，簡單模型用 7B、14B、32B 基本都能滿足，復雜一點的長文本和復雜任務，32B 模型也能差不多應對。使用開源模型進行部署和訓練基本沒什么太大問題。

數據管理平臺

在數據管理平臺方面，我看了所有開源項目并梳理了公司內部所有數據相關平臺后，得出結論是必須由業務線自建，因為沒有任何兩個業務的數據管理需求是一樣的。其核心有兩點：一是 Badcase 驅動，Badcase 管理非常重要，我每次訓練時核心任務是修復 Badcase；二是要進行模型樣本管理，避免引入臟數據，出問題時能追溯模型來源，所以要建設模型溯源能力，而不僅僅是數據管理能力。

培養全員大模型思維與能力

如何培養全員訓練大模型的思維和能力，重點在于提升能力，尤其是讓普通研發人員快速掌握大模型訓練，建設他們的算法能力。大模型訓練流程包括問題定義、提示詞設計、樣本構建、微調（蒸餾、強化學習）、評估和上線。模型優化能力由四個能力疊加而成：模型問題定義能力、樣本構建能力、訓練能力和評測能力。最初認為模型訓練能力最難，但實際上最容易，一周內所有人都能學會調參，且調參不超過 3 個。研發團隊最需要提升的是問題定義和評測能力。

大模型的應用場景和優化方式

我將自己最近半年工作中的教訓和經驗總結，把所有訓練過的大模型場景做了拆分，發現大部分大模型場景都能映射到下表幾個類別中。每次模型訓練時，思考一下可以放到哪個類別，然后按照相應的優化方式去做，基本都能取得不錯的效果。以寫作類為例，這是最常用的大模型優化場景，現在 DeepSeek 效果較好，大家開始廣泛使用。以前不敢碰寫作類，因為需要構建樣本，難度較大。但現在通過 DeepSeek 蒸餾和強化學習（GRPO），基本能取得較好的效果。要素抽取類場景中，公有云模型準確率能達到 90%，自身優化空間不大。問答類場景中，大模型能力很少單獨訓練，大家主要做 RAG 和搜索插件，因為底層工程化可以提升更多效果。還有 API 調用類場景，訓練大模型時將其抽象到某個場景，再看每個場景的優化方式。無論是寫作還是交互，最核心的是要有一套快速構建樣本訓練的鏈路能力，從業務驅動出發，快速構建樣本訓練，再快速進行評測和 Badcase 修復，以及與之相配合的平臺能力。

大模型測試

大模型測試曾是我最不關心的環節，但后來發現它對模型優化迭代效率影響最大。首先，數據來源很重要。如果線上有 Badcase，建議直接使用 Badcase 作為優化數據。性能測試方面，大模型性能測試與普通性能測試存在差距，可能會考慮 GPU 并發等因素。但我認為，同樣 Token 長度和 Size 模型性能差異不大，不要投入過多精力。最核心的是找一個測過的開源的數據源，拿來即用。效果測試很關鍵，就是理解模型效果并進行測試。我的感受是，合作的業務線中，是否有優秀的測試人員對最終模型效果影響很大。優秀的測試人員可以從業務需求出發，將業務標準和測試標準轉化為測試用例，自動化生成樣例，并用大模型自動評測。一個這樣的測試人員對于團隊能力的提升，相當于三個以上的大模型算法人員，而那些配合較差、反復優化效果不好的業務線，往往缺少這樣的人。因此，我在公司內進行大模型測試能力評估，盡管自己做算法工作，但感覺沒有優秀的測試人員，工作開展會很困難。

大模型優化案例 1 一多輪改寫

我最早做搜索時，用戶輸入多輪搜索結果，需要多輪改寫來理解用戶意圖。之前使用傳統方法和一些大模型，都無法很好地理解幾輪對話之間的關系，上下文無關和上下文有關的內容都識別不出來。DeepSeek 出現后，發現其 R1 效果非常好，因為它有思維鏈，能思考上下文關系。于是嘗試用 R1 做蒸餾，結果效果也很好。這個實驗有幾點結論：一是使用 DeepSeek 后，提示詞簡化了很多，這也是提示詞工程師現在市場不大的原因；二是蒸餾時仍需要底座模型，像 1.5B 的底座模型較弱，學不到東西；三是思維鏈加入后，可以做一些以前做不到的事情。舉個例子，用戶在搜索中要求生成雙色球下期中獎號碼，以前在 Query 理解上做了很多嘗試，但都無法解決。DeepSeek 給出的回復是“雙色球號碼不靠譜，遠離賭博，珍愛生命”，這讓我覺得自己之前的嘗試很愚蠢。這個案例說明，當新技術如 DeepSeek 出現后，要勇于探索和嘗試，會得到超出預期的驚喜，也能讓團隊成員感到開心。

大模型優化案例 2 一公文寫作

寫作場景以前是我不敢碰的，因為構建樣本難度大。DeepSeek 出現后，針對政府公文寫作場景，直接使用 DeepSeek，通過公文反推生成大綱，再基于大綱生成要素，然后進行寫作。這個過程中有幾點分享：一是 DeepSeek 可以幫助做樣本構建，節省大量工作量，甚至可以做樣本評測；二是用多輪改寫的成功經驗來訓練和蒸餾 COT，發現寫作類加 COT 后效果更差，說明之前的經驗證到新技術面前可能需要更多實驗來驗證；三是寫作類模型優化并非一次生成文章即可，大部分寫作類模型優化是先生成大綱，再基于大綱寫作，這樣才能取得較好效果，即使使用 DeepSeek，直接一步生成的效果也不如兩步走（先生成大綱再生成文章）的效果好；四是通過嘗試新技術，即使之前在該領域沒有積累，基于 DeepSeek 等最新開源成果，也能實現技術跨越，從原來 30 分的能力提升到 75 分。

構建開放共享的協作文化

在推動工程人員轉向大模型工作時，會遇到一些疑慮。例如，一位有五六年的軟件開發經驗的同學對轉向大模型工作非常抵觸，他提出了兩個疑慮：一是自己不會深度學習理論技術怎么辦，我對此解釋是大模型工作不需要這些，只要會搞樣本、調參數、寫 Python 代碼就行；二是大模型優化與寫代碼差距太大，我展示了一個在 QCon 學到的關于工程師文化的圖，就是李云老師在 2024 年 QCon 上海演講分享的 《AI 時代團隊管理的不變與變》 中的一張圖，該圖將工程師文化的關鍵項總結得很好，指出工程師的工程能力包括設計能力和工程能力兩塊，之前做工程開發可能是 30% 時間設計、70% 時間工程，而大模型優化可能是 80% 時間設計、20% 時間寫代碼，本質上仍是工程師工作，只是比例變化，底層活動也一樣，都是設計、文檔化、寫代碼以及敏捷開發等。

如果有人擔心自己的效果比不上專業的研究團隊，那是因為缺乏經驗，存在知識壁壘和技術孤島。解決方法是打破壁壘，通過開源和分享打破技術孤島，大家團結起來共同成長。遇到問題時，可以找人問、開分享會、開會研討。

一些解決遇到的

大模型優化問題的經驗

我在做多輪搜索時，面臨模型合并、樣本合并問題，如果每個模型都單獨訓練，最后需要維護幾百個模型，這是無法維護的，所以把相似數據放在一起同時訓練，但這樣導致準確率下降很多，當時不知所措，于是向研究院同學請教，對方建議把多輪與單輪的 promot 差異加大，嘗試后發現有效；又向工程同學請教，對方說 VLLM 支持動態的 Lora 加載，每個模型訓練一個 Lora，然后動態加載即可，這兩種方式都能解決問題。

在寫作場景中，出現前面寫得正常，后面突然出不來標點符號的問題，當時甚至想用強化學習設置 Reward 來解決，但訓練底座大模型寫作的人說把 decay 的懲罰從 0.6 設到 0.1，嘗試后發現可以解決。現在回看去年做的事，覺得當時犯了低級錯誤，但認為這不是黑歷史，而是成長之路，想跟大家分享的是遇到問題找別人會得到幫助，能力是逐漸積累的。

工程師文化建設

我在公司負責一些工程師文化建設工作，梳理出工程師文化最核心的幾點是技術過硬、專業靠譜和開放共享。在大模型時代，我個人最認同的是開放和樂于分享，整個團隊、公司或組織需要有更開放共享的文化心態。

總結與展望

從組織氛圍或組織變革角度看，訓練大模型很簡單，只要有平臺、有業務 Sense 就能做起來。大模型基礎平臺可以低成本建設，有眾多開源資源可復用。大模型場景就那幾類，按流程優化就行。要擁抱開源，避免閉門造車。

最后是致敬：一是 QCon 上一位老師的分享，他講的“優化算法最好的辦法就是找 bug”這句話對我后續工作影響很大，認為在大模型時代，找 bug 和 review 數據比調參更有用；二是 Hugging Face，感謝它提供很多優秀的開源模型和數據，每個公司都需要有自己的類似 Hugging Face 的共享平臺，用于模型數據、訓練方法論和經驗的共享，打造開放共享的團隊氛圍。

嘉賓介紹

呂昕，負責科大訊飛消費者 BG 大數據和大模型技術平臺相關工作，先后負責建設了訊飛 C 端用戶數據中臺、大數據分析平臺和大模型應用開發平臺等，目前負責多個 C 端產品的大模型效果優化工作。 在大數據平臺、個性化推薦、廣告算法、商業分析、大模型算法領域有多年經驗。

會議推薦

從基礎設施、推理與知識體系，到研發與交付流程，再到前端、客戶端與應用體驗——AI 正在以更工程化的方式進入軟件生產。2026 年QCon 全球軟件開發大會（北京站）將以「Agentic AI 時代的軟件工程重塑」作為大會核心主線，把討論從「AI For What」，走向真正可持續的「Value From AI」。