作者 | 【新程式設計師】編輯部
出品 | AI 科技大本營（ID：rgznai100）
從 BERT、GPT、T5 等通用大模型展示了令人矚目的語言理解和 NLP 任務解決能力，到 ChatGPT 驚艷釋出，再到國產大模型的百花齊放，我們目睹了大模型透過海量參數和強大的學習能力，不僅在問答、對話、摘要、轉譯等任務上取得了不錯的成果，更是推動了人工智慧的邊界不斷擴充套件。
而在百模大戰之後，國內也迅速進入套用爆發的階段，無論是建立逼真的聊天機器人、GPTs，還是垂直行業的大模型工程實踐，這些套用都展示了大模型在實際場景中的巨大潛力。
在 7 月 4 -5 日於北京正式拉開帷幕的 2024 全球軟體研發技術大會（SDCon）上，我們特設的「大模型智慧套用開發」論壇，邀請了來自騰訊、去哪兒、京東、美圖、eBay、衍數科技、賓夕法尼亞州立大學的一線技術專家和行業領袖，深度探討智慧套用最新的研究成果和開發經驗。同時，我們期待與會者能夠在這場思想的盛宴中，獲得啟發與洞見，推動自身及整個行業的創新與發展。
騰訊：智慧數據研發技術分享
大模型改變很多公司的研發範式，其中也包含了騰訊。
騰訊大數據 AI 演算法負責人黎洋在發表【智慧數據研發技術分享】演講時表示，傳統的數據研發全過程涉及了數據接入、後設資料采集與治理、數據地圖、數據分析、視覺化和洞察等多個環節，形成了一個漫長而復雜的鏈路。每個環節都需要數據工程師和分析師的人工幹預，導致研發成本居高不下。
黎洋 騰訊大數據 AI 演算法負責人
如今，擁有強大的語言理解、推理、生成和知識能力，甚至湧現出類似人類的能力的大模型技術，為我們帶來了新的機遇。黎洋指出，特別是 AI Agent 技術的發展，使得以自然語言互動方式高度自動化執行復雜任務成為可能。
基於這些維度，黎洋分享道，倘若把大模型技術帶入數據研發全流程中，借助它的知識推理、知識壓縮、資訊理解等能力無疑可以有效解決傳統數據研發中需求排期慢、開發效率低、取數流程長以及治理效果差等問題。
進而，也可以基於大模型相關的技術為處理數據研發的整個流程打造一個AI智慧體，即大數據智慧體，可以用它來接收使用者的自然意圖（文字，截圖，語音等） 作為輸入、以大語言模型作為規劃中樞大腦、整合現有大數據平台的數據知識與數據服務工具。同時，在數據工程、數據科學、數據分析環節提供自動化的智慧決策和智慧分析服務。
在演講中，黎洋表示，智慧數據研發也沒有想象中那麽簡單，至少需要「過三關」：
第一，在數據接入和數據地圖環節的「找數」問題。 對於許多數據開發工程師來說，這個過程非常困難，因為他們可能不了解底層數據儲存的詳細資訊。因此，當需要獲取上層套用的數據時，他們往往不知道應該尋找哪些資料庫、哪些表以及哪些欄位。此外，後設資料品質參差不齊、知識整理標準不一、人力維護消耗、答案正確性評價難、指標加工的復雜 SQL 邏輯理解難度大都是難點。
第二，在數據地圖和數據分析的使用環節中的「用數」問題。 使用者在用數據時，最大的難點之一就是口語化表達的不一致，導致大模型在理解這些名詞時會出現偏差。其次，大模型對於深度業務知識理解、分析方言的相容都有所不同。
第三，在數據視覺化和數據洞察環節的「懂數」問題。 包括類似於增長分析這樣的業務的場景，它的難點在於它是完全業務導向的一個深度的分析，同時需求多變、需要客製化建設。
基於這些機遇與挑戰，騰訊大數據團隊在智慧化方向進行了一系列能力建設，包括沈澱領域原子能力、理解業務私域知識、最佳化領域模型、整合專用工具等等。在此基礎上，黎洋分享道，騰訊開發了三大智慧體系統套用： Chat Data、Chat BI 和數據洞察。 Chat Data 作為智慧找數助手，實作了數據資產智慧尋找和 SQL 生成等功能，有效解決了海量數據和復雜欄位指標帶來的挑戰；Chat BI 則透過對話式分析大幅降低了數據分析門檻，支持多輪對話、意圖辨識和問題聯想等功能；數據洞察系統更是實作了從簡單趨勢分析到深度業務洞察的能力演進，能夠支持增長分析等復雜分析任務。
在技術實作上，騰訊大數據團隊綜合運用了領域知識庫建設、意圖辨識與最佳化、任務規劃、工具呼叫、RAG 技術套用、數據增強與自動標註、模型微調和後處理策略等多項關鍵技術。黎洋表示，借助 AI Agent 加速研發只是一個起點，未來其也將在更多方面持續推進相關能力的建設，進一步提升大數據智慧化的套用水平。
去哪兒旅行機票主流程 AIGC 探索實踐
在本次論壇上，去哪兒旅行技術總監李佳奇坦言，帶領一個業務研發團隊，推進 AIGC 計畫落地和探索也面臨層層壓力：一是公司高層對這一顛覆性技術的關註和焦慮，他們關心在 AIGC 時代如何保持技術團隊的競爭力；二是團隊的迷茫，擔憂技術儲備是否足夠以及是否會被 AI 取代；三是市場使用者對創新套用的期盼，期待著殺手級套用的問世。
李佳奇 去哪兒旅行技術總監
李佳奇認為壓力往往是推動進步的動力。為此，去哪兒業務研發團隊給出了三個應對策略，如開發 Langchain4J Qunar 框架、RAG/LlamaIndex4J 框架來打基建，結合既有的業務去找機會點，以及增強團隊成員的 AIGC 技術儲備，實作團隊的整體升級。
針對初接觸 AIGC 的團隊該如何尋找落地點的問題，李佳奇分享了三個步驟：
標記階段。 嘗試 AI 業務矩陣法，基於文本生成、影像生成、視訊生成、邏輯推理分析等 AI 能力，探索搜尋、預定、交易、出行、售後、使用者體驗和行銷等業務場景的套用可能性，結合技術可行性和成本確認機會點。
探索階段。 這一階段需要研發團隊事先準備數據和測試集，因為數據品質直接決定計畫最終的落地效果。再透過人工與程式碼結合的 Demo 驗證結果，並送出給產品團隊和業務團隊進行確認，確保效果符合預期。
落地階段。 推出 MVP 版本並上線。內部上線驗證和流程控制後，釘選技術資源進行封閉開發。整個過程通常周期較長（大約幾個月），並進行自動化測試和小流量驗證。
基於此，去哪兒在 AIGC 方面做了一些探索實踐，其中之一是機票主流程的探索。李佳奇表示，這裏的核心邏輯是：大模型在機票業務中被賦予業務專家、行銷專家、售前導購、使用者本身等角色，讓大模型即時觀察使用者操作行為和看到的結果，透過大模型強大並且不斷提升的思考、推理能力，來挖掘目前機票主流程在使用者體驗、產品力、行銷等提升潛力並給出方案，再結合 Agent 的執行能力來執行有效動作。
如下圖所示，使用者行為和業務結果都會經過主流程閘道器。該閘道器具備一些能力，如掛載不同的代理（Agent）。利用這個功能，研發團隊可以掛載推薦 Agent、行銷 Agent、客服 Agent 等。這些代理不僅能接收到使用者行為和數據，還能修改使用者請求的響應結果，並將修改後的內容呈現給使用者。
這些代理能夠與大模型或多模態模型進行互動，並觸發業務動作，如發放優惠券或彈窗通知使用者。基於這套基礎設施，去哪兒研發團隊在主流程的探索就是透過不斷擴充套件和更新代理的邏輯來實作的。每當其增加一個探索場景時，只需更新現有代理或添加新的代理，以外掛程式式方式擴充套件即可，無需額外成本。
最後，對於正在帶領業務研發團隊且想要轉型 AIGC 的負責人，李佳奇根據自己多年的經驗，提供了三點建議，「作為團隊負責人，提升自己的認知至關重要，並在團隊內營造良好的技術氛圍，確保團隊對 AIGC 技術有深刻理解；打好基礎設施，基礎設施建設包括開發、測試和執行基建；團隊建設需要一些技術領袖起到示範作用。配合機制和流程，確保團隊有足夠的 AIGC 技術儲備。如果沒有相關經驗，計畫周期會拉長，且可能無法成功落地。」
京東：大模型時代的演算法服務體系演進
緊接著，京東物流神機妙算演算法平台架構師檀江華帶來了【大模型時代的演算法服務體系演進】的主題演講。
檀江華 京東物流神機妙算演算法平台架構師
檀江華為我們深度分享了京東物流神機妙算演算法平台在大模型技術基礎上的叠代歷程。他介紹，神機妙算演算法平台已經從 1.0 階段過渡到 2.0 階段，如今該平台的核心包括四個要素：數據服務、實驗評估、模型部署和演算法服務。
在數據方面，進入 2.0 階段的神機妙算演算法平台引入了更多文本數據、離線特征、即時特征、上下文特征和向量數據。檀江華提到，傳統特征工程有一定的缺陷，因為特征按計畫 case by case 開發，不僅效率低，且無法保證數據口徑一致，很難沈澱、復用和維護。對此，神機妙算演算法平台希望透過端到端的方式進行改進，於是，其使用動態 PB（Protocol Buffers）作為數據傳輸的「鑰匙」，實作了數據的序列化和反序列化，支持版本管理和向前回溯相容。同時，平台采用一套程式碼生成同步引擎任務和特征服務程式碼，支持 Spark 和 Flink 平台，提供多維度批次查詢介面。
此外，檀江華表示，檢索增強生成，透過在大模型呼叫時引入現有知識庫，或者即時數據，是一種 ROI 比較高提升大模型效能的方式。
其次，實驗評估是確保演算法價值的關鍵環節。為了解決傳統 AB 實驗中存在的設計不規範、報告不中立、技術重復造輪子等問題，京東物流開發了一個專門的 AB 實驗平台。這個平台允許使用者建立實驗、進行版本管理和合規性檢查。結合實驗配置庫會下發到演算法線上服務或離線建模平台，最終產出實驗報告。
在模型部署方面，檀江華指出，神機妙算演算法平台實作了模型托管，使用者可以一鍵部署和自動更新模型，解決了復雜的執行環境和依賴問題。同時，透過模型描述檔解決模型校驗、預熱等，支持模型自動預處理邏輯，保證線下線上一致性。
演算法服務是將演算法套用到實際業務中的最後一步。京東物流的演算法服務平台分為兩類：運籌最佳化演算法服務和統計學習演算法服務。
運籌最佳化演算法服務針對網路規劃、排程場景，平台開發了一個智慧工具箱和套用包部署框架，支持 Python、Java 和常用求解器環境，並透過資源排程中心動態管理執行環境。平台還在開發一個基於多智慧體的架構，用於重構網路規劃演算法業務，包括意圖辨識、洞察、規劃和執行等多個智慧體，以智慧化處理復雜的規劃任務。
統計學習演算法服務平台開發了一個線上處理外掛程式框架，將演算法業務邏輯單獨抽出為一個獨立包。這個框架偏好設定了特征、模型預測、資料來源呼叫等能力，演算法工程師只需要關註業務邏輯。平台支持熱部署和演算法灰度釋出，還提供了線上 debug和測試能力。透過這種方式，實作了工程和演算法工作的解耦，提高了開發效率。
在穩定性保障方面，該演算法平台還提供了運維值班、故障演練、壓測和擴縮容、套用健康度監控等工具和手段。檀江華透露，神機妙算平台賦能演算法研發團隊自主進行演算法計畫的開發、測試和上線。內部推行了類似自動駕駛的 L1-L4 等級，鼓勵演算法團隊實作完全自助研發。
衍數科技：垂直行業大模型工程實踐
從研發通用大模型到行業垂直大模型，這一轉變中存在諸多難點。衍數科技的 CTO 吳岸城指出，在做垂直大模型時，企業在構建垂直數據往往主要面臨三個問題：
高品質數據集的短缺：許多使用者提供的數據集非常有限，通常只有單一的文章，且這些文件通常是未經處理的 Word 或 PDF 檔。這樣的單一文件往往缺乏足夠的品質和多樣性，難以支撐高效的數據分析和建模工作。
數據預處理的瓶頸：在處理涉及企業私有數據的計畫（如銀行計畫）時，企業無法將敏感數據上傳到閉源平台（如 ChatGPT）進行數據增強。
數據多樣化的挑戰：面對更復雜的場景時，簡單的數據集將使模型難以應對復雜問題。
吳岸城 衍數科技的 CTO
為了應對這些問題，企業需要在數據預處理和數據生成方面采取有效措施。吳岸城分享了在實踐中使用的一些解決方案：
對於高品質數據集較少，可以使用大模型生成數據，然後進行脫敏處理。
對於生成的數據和目標數據存在很大差別問題，不妨試試給這些大模型一些 Prompt，如這段文字的主語是什麽、這段文字主要在說什麽、根據這段文本起10個不同問句。
在平衡通用數據與垂直領域數據時，可以選擇一些訓練方法，如 Fine tune、P-tuning、Lora、Q-Lora 等。
進而，確認大模型微調目標，如改變輸出格式、學習新知識、提高精度、增強個人化推薦、最佳化決策支持、增強自然語言處理能力、提升數據安全與私密保護，以及適應特定行業需求等。根據微調目標的不同，選擇合適的技術方法。 在選擇微調方式時，吳岸城表示，可以考慮參數量與資源需求、客戶需求與偏好等因素。
在垂直行業大模型工程實踐中，做 RAG 也會涉及到數據的偏向性、及時性和準確性等問題。在吳岸城看來，普通 RAG 透過向量召回存在諸多局限性，如檢索結果的品質參差不齊、精度不高，無法完全替代結構化資訊提取的需求，也不能支持條件查詢和統計功能。
對此，吳岸城表示，可以透過數據清洗和人工標註兩種方法進行處理。 在模型選擇方面，使用者可以根據 Hugging Face 趨勢和評估結果來選擇合適的模型。
至於如何提升產品的資訊豐富度，針對未檢索和難檢索的問題，吳岸城提出了幾種解決方案，如 Prompt 的追問、關鍵詞檢索和召回和重排序，混合檢索。這些方法幫助企業從文本中提取關鍵資訊，提升查詢的精度和廣度。
代理人工智慧編程框架 AutoGen 的套用與實踐
立足「未來的人工智慧套用是什麽樣的，我們如何讓每個開發者都有能力構建它們？」兩個問題的思考，賓夕法尼亞州立大學助理教授、AutoGen 聯合創始人吳清雲及其團隊聯合微軟共同研發並開源了 AutoGen（https://github.com/microsoft/autogen）這個 Agentic AI 通用編程框架。
吳清雲表示，AutoGen 的核心概念之一是對話式智慧體，這 意味著任何一個 Agent 都可以透過對話的方式與滿足框架下的其他 Agent 進行交流。這種設計賦予框架極高的靈活性、擴充套件性和易用性。有了對話式智慧體，任何復雜的套用理論上都可以分解成兩個步驟：第一步是定義一些智慧體，第二步是讓它們以某種方式進行交流，這些方式包括常見的順序對話、巢狀對話、群組對話和層次對 話等。
在論文中，吳清雲及其團隊實作並研究了以下六種套用場景。
以第一個數學問題的解決套用場景為例，吳清雲表示，可以直接利用 AutoGen 提供的兩個原生智慧體來構建一個雙智慧體系統。這個系統類似於對話式智慧體系統，可以根據人類輸入模式的不同，選擇自主解題或在人類參與下進行解題。值得註意的是，構建這個系統只需要幾行程式碼，並且直接使用了 AutoGen 提供的兩個智慧體，沒有針對特定套用進行任何最佳化，便能取得良好的效果。
其中，吳清雲強調，AutoGen 的模組化設計使其支持的多智慧體系統具有極高的擴充套件性。例如，在之前提到的雙智慧體系 統基礎上，我們可以輕松擴充套件，允許額外的智慧體參與解題，只需要透過函式呼叫的方式實作擴充套件。舉一個例子，如果使用者是一名學生，他不僅希望有人工智慧助手幫助解題，有時還希望能夠與人類指導老師交流。在這種情況下，我們可以透過函式呼叫讓 Assistant Agent 決定何時呼叫人類指導老師，從而實作更靈活和個人化的解題體驗。
此外，吳清雲還分享了一個供應鏈場景的範例。當使用者提出一些假設性問題，例如「如果某個地區的咖啡烘焙成本上漲5%，會怎樣？」時，單純依靠一個大語言模型很難有效解決這些問題，因為這通常需要進行一系列復雜的計算和推理。 如果由專家或人類來解決，通常會先將問題建模為一個最佳化問題，然後呼叫相關的最佳化演算法進行求解，最後根據最佳化結果進行進一步的推理和解釋，以回答終端使用者的假設性問題。
使用 AutoGen 框架，可以輕松實作上述解決問題的流程。具體來說，在這個套用場景中，可以設計一個 Commander Agent，負責與終端使用者直接對話。同時，引入一個 Coding Agent，負責將問題建模並編寫相應的程式碼。由於這個問題需要進行建模和最佳化，Coding Agent 透過與 Commander Agent 的對話進行程式碼的執行和偵錯。
為了更貼近實際的工業場景，吳清雲表示，這裏還引入了一個 Safeguard Agent，負責安全檢查，確保智慧體編寫的程式碼能夠安全執行。透過 Autogen 框架，我們可以高效地解決供應鏈中的復雜最佳化問題。
展望未來，吳清雲透露，AutoGen 正在深入研究和開發多項新功能，包括基於智慧體的評估工具、降低編程門檻的低程式碼工具、智慧代理的最佳化以及多模態模型的整合等。
eBay 風控即時特征平台
eBay 支付風控部門高級經理李傑在【eBay 風控即時特征平台】主題演講分享 了線上交易欺詐對特征平台的嚴苛要求以及 eBay 風控即時特征平台如何來應對這些要求。
他提到，線上交易欺詐涉及的風控檢查會涉及 AI 模型和風控規則的即時推理和批次推理：即時推理大多用在使用者在場的風控檢查（比如同步阻止可疑的下單、綁卡或者提款操作），對模型和規則的響應速度要求高；批次推理則主要用在使用者不在場的風控檢查（比如稽核使用者已經上架的商品並下架可疑商品），對響應速度要求低。
李傑 eBay 支付風控部門高級經理
國內支付體系的實名認證為線上交易風控帶來了極大便利。eBay 交易風控場景由於缺乏這些實名資訊支持，主要依靠 AI 模型和風控規則等技術手段來捕捉可疑的欺詐活動。為更好支持 AI 模型和風控規則的智慧訓練、仿真和低延遲的即時推 理，eBay 開發了 eBay Risk Real-Time Feature Store 平台，它在風控系統中扮演著重要角色。
李傑表示，AI 模型對平台的要求分為離線和線上兩個方面。離線階段需要準備大規模特征瞬時值（Point-in-Time Value）供 AI 模型訓練和仿真使用；線上階段則需要即時生成準確的特征值並支持高效的特征批次獲取以滿足即時推理的低延遲要求。平台的關鍵目標之一是實作離線與線上數據的一致性。
此外，風控規則也對特征平台有幾個關鍵要求。首先是自助服務功能使風控團隊能夠針對線上最新的欺詐活動作出快速響應。其次是 快速和自動化的特征冷啟動。基於高效的大規模仿真回溯能力和線上離線數據一致性，該平台對新特征提供完善的冷啟動機制，讓需要回看一兩年時間視窗的特征數據也能在數小時內完 成冷啟動並開始服務線上AI模型和規則。
在技術細節上，李傑分享了該平台的一些亮點：
高效的數據儲存模型和 DSL 。針對 Sliding Window 和 Lastk 這兩種最為廣泛使用的特征型別，該平台提供先進的儲存模型達到高效的讀寫和儲存效能。針對 Sliding Window 特征，透過將「天」、「小時」和「分鐘」不同維度數據存入同一個數據儲存單元，減少特征批次讀取時的資料庫 IO 開銷；針對 Lastk 特征，相較於對特征物件整體進行編解碼的傳統方案，重新設計了一種基於索引塊的數據模型來達成計算和儲存模型統一，從而避免特征值更新時的反復編解碼。除 Min、Max、Count、Sum、Distinct、Average、Standard Deviation、Time Decay、ZScore 等標準算子之外，借助於該平台提供的 DSL，演算法團隊可以按需定義任意計算邏輯。
該平台的線上計算引擎是基於 Flink 構建，透過在 Flink Check Point 中儲存 Kafka Offsets 、 Unique Delta ID list （業務層面去重） 和 Unapplied Delta List 來確保數據至少被處理一次，以及在特征數據模型中儲存已經處理過的 Delta 值的 K afka 偏移量來確保特征值的冪等更新（最多處理一次）。最終確保數據業務層面的數據準確性。
該平台的離線瞬時值仿真引擎基於 Spark 構建。 透過 DSL 構建的特征和數據欄位的關聯關系以及 Driver set 中的瞬時值範圍來精確定位 Event 快照數據範圍，極大提升大規模瞬時值的仿真效率。
基於 離線瞬時值仿真引擎而構建的離線到線上的自動回填能力，可以幫助特征在幾個小時內完成冷啟動。
正如上文所提到的，李傑強調，設計平台的最終目標是確保線上和離線數據的一 致性。至於如何保證一致性，他覺得可以從下面三方面保證：
使用 DSL 來定義特征，並能動態被Flink和Spark執行達成線上離線任務執行邏輯的一致性；
線上 Flink 任務消費的 Event 數據快照被存入離線 HDFS 檔作為離線 Spark 任務資料來源，確保了線上離線計算引擎資料來源的一致性；
線上 Flink 任務透過一種智慧快照數據模型，結合先進的特征數據模型，來保證即使在基礎元件如快照儲存檔案系統、資料庫系統等不穩定情況下仍能保證所有 Event 數據處理的恰巧一次和業務層面的去重，離線 Spark 任務則透過去重機制結合 Event 快照落庫任務的至少一次機制來確保離線數據處理的恰巧一次。離線批次處理和線上流處理殊途同歸，各自確保了數據的高度準確性。
美圖在 AIGC 運維道路上的探索和挑戰
前有工程師奮戰在 AIGC 開發的一線，而在幕後，站點保障工程同樣至關重要。 在業務革新的浪潮中，如何有效地實施這些保障措施成為關鍵。美圖資深 SRE 李彬在【美圖：雲原生架構構建AIGC業務堅實後盾】的主題演講中，深入分享了這些關鍵技術和實踐經驗。
李彬 美圖資深 SRE
李彬透露，美圖是為數不多透過 AI 規模化盈利的公司。在 AI 的驅動下，美圖全球 VIP 會員數突破千萬。
在將 AIGC 整合到業務流程中，他們也發現了在新模式下，業務傳播速度快，留給工程師反應時間短；數據增長迅猛，容易產生爆款，所以對資源的需求也是巨大的、突發的；企業需要快速搶占市場，以獲得有利競爭，因此需要快速交付資源。
在算力方面，李彬表示，美圖將集群分為推理集群和訓練集群。推理集群註重彈性伸縮、周邊設施完善程度、業務穩定性、雲原生成熟度以及資源供給；而訓練集群專註於數據安全、計算能力、高效能儲存、高效能網路以及故障自愈能力。
這些集群共同構成了美圖的萬卡集群，主要依賴 GPU 和 NPU 作為 AIGC 的算力支持。
起初，美圖在 GPU 算力布局方面采用了單雲架構，但後來發現資源競爭激烈、價格高昂、容災能力不足等問題，因此轉向多雲架構。然而，多雲架構也帶來了新的挑戰，如服務穩定性提升後，成本壓力增大。因此，美圖開始與 IDC 廠商合作，不過，IDC 廠商雖然價格便宜，但是周邊設施不太完善，需要其投入更多的人力物力進行周邊建設。
在這一過程中，美圖圍繞基準測試、廠商交付、內部交付和持續的協作等維度制定了一套交付標準。一旦資源交付完成，美圖便開始最佳化資源的使用效率。盡管采用了多元算力和多元管理策略，仍面臨諸多挑戰，如復雜的管理與維護、資源排程與最佳化、相容性問題、供應鏈問題、故障恢復與災備以及穩定性與成本之間的權衡。
為此，李彬表示，美圖在多雲管理和穩定性營運方面做了大量工作：
在架構選型上充分利用雲原生技術，以K8s作為底座，構建多雲生態，並根據網路拓撲、資源型別、規格配比等標準進行最佳化。
多雲納管方面，美圖內部研發了多雲容器管理平台 Matrix，統一管理所有生產集群。
在基礎設施層面，其建立了統一的模型庫、映像分發平台、監控數據匯總、日誌查詢和多雲告警系統等。
美圖還開發了穩定性營運平台，定期生成所有核心業務的執行狀態和監控數據。
除此之外，在多營運流量排程和彈性伸縮方面，美圖采用了兩種典型的演算法業務模型：同步演算法和異步演算法。在同步演算法中，流量進入演算法閘道器後，會根據比例分流至不同容器集群，確保資源高效利用。而異步演算法則將任務寫入訊息佇列，待其他雲端任務啟動後，訊息佇列中的任務進行本地處理和上傳操作。
最後，為了實作更高效、智慧和成本最佳化的多因管理，美圖持續進行精細化營運，透過數據驅動業務決策，評估業務 ROI，並針對虧損業務提出轉化或下線的建議，進而對資源供給、包月策略持續最佳化。
大模型套用落地實踐
本次論壇的最後，在 Boolan 首席咨詢師李沫南的主持下，衍數科技 CTO 吳岸城、去哪兒旅行技術總監李佳奇、eBay 支付風控部門高級經理李傑齊聚一堂，深度剖析了 AI 如何重塑業務形態，分享了各自在 AI 賦能業務方面的獨到見解與實踐經驗，為與會者呈現了一場思維碰撞與智慧交融的盛宴。
大模型經過一年半的發展，從最初的高度期待到發現諸多問題，經歷了過山車式的變化。李沫南指出，這引出了一個重要問題：在技術峰值時期，許多公司可能做出了一些承諾或啟動了一些計畫，但現在卻面臨在當前大語言模型能力下如何順利完成這些計畫、確保這些計畫成功交付的挑戰。
對此， 吳岸城認為，關鍵在於計畫管理，而不僅僅是技術問題。計畫管理涉及多個方面：事前的客戶預期管理、事中的需求溝通和調整、以及後期的復盤和問題解決。這些才是更為關鍵的部份。其次才是技術問題。技術問題本質上是對大模型認知的逐步深化和經驗的逐漸積累。例如，在為金融保險領域的客戶落地計畫時，我們會進行 LoRa 微調或全參數微調。隨著時間的推移，我們對大模型的理解不斷變化和提升，這自然會帶來一些技術上的挑戰。
最後， 如果在計畫初期設定了過高的目標，現在卻發現難以實作，那麽最好的解決辦法就是坦誠面對，承認目前的技術水平確實達不到預期。不論是數據還是演算法層面，都有其局限性。在承認這一點的基礎上，應盡最大努力貼近預期目標，這樣的態度才是良好的乙方態度。
緊接著，李傑在對話中分享了他對企業更廣泛地擁抱 AIGC 技術的看法和見解。他表示，在重新面向大語言模型設定業務，或者吸收新的革命性技術時，我們應盡量把宏大的目標和敘事拆分成可落地的小任務。這些小任務能夠讓相關方，尤其是那些出錢並有決策權的人，看到短期的成果，從而增強他們的信心並持續投入。
另一方面，在用大語言模型改進業務流程時，可能會觸及業務部門的利益。例如，提高效率後，某些人工稽核的工作可能會減少，從而導致裁員等問題。在這種情況下，我們該如何應對？我認為關鍵在於讓這些相關方站在未來的角度思考問題。
隨著技術的發展，對於未來是否可能出現「一家公司只有一個自然人，其余的全都是 AI 代理」的設想，李佳奇表示，在深入研究和學習 AI 技術的過程中，當第一次看到 GPT、ChatGPT，甚至最早的 AutoGPT 時，它們能自主完成如此復雜的任務，他的團隊確實被震撼到了。因此，李佳奇堅信未來一定會有「一人公司」的出現，因為大模型的能力確實非常強大。
不過，李佳奇認為工程師不會因為 AI 而被替代。在實際業務落地過程中，仍然需要工程能力和技術手段來確保大模型按預期工作。工程師的角色可能會發生變化，從執行者轉變為編排者。他們不再是簡單的操作人員，而是從更高層面來設計和管理整個流程。工程師們也需要撰寫合理的劇本，安排角色的分工與協作方式，制定故事的主線和核心矛盾，並確保整個過程朝著解決核心問題的方向推進。
至於何時能實作「一個人公司」，「老實說，這目前有點超出我的認知範圍。我認為我們需要持續關註 AI 的發展，才能更好地回答這個問題」，李佳奇說。
以上，便是本場論壇的精彩內容。
立即掃碼預約全球軟體研發技術大會 PPT
↓↓ 點選「 閱讀原文 」，了解「2024 全球軟體研發技術大會」更多資訊！
