生成式AI工具鏈大戰白熱化

年底，科技大廠紛紛揭露生成式AI的新戰略，微軟在11月Ignite大會上揭露兩大Agentic AI新戰略，聚焦Copilot生態圈和多代理型AI工具鏈，12月初緊接著登場的AWS年度大會re:Invent，從運算、儲存、資料庫到AI推論產品線的種種升級，也都瞄準了生成式AI的發展需求。

OpenAI同樣展開了為期12周的12天產品發表期，每周一天直播，分階段公布多項模型技術的進展，尤其是年初讓眾人大吃一驚的影音生成模型Sora終於正式推出，ChatGPT則新增了專案管理功能、ChatGPT的Canvas寫作和程式開發工具開始支援Python等，而擅長推理的o1模型開始釋出API，甚至提供了Java和Go的SDK。截至這篇文章完成之際，OpenAI的12天發表，才進行到第9天，但已經推出了許多開發者期待很久的功能，更容易用於開發和管理提示工程應用，或是將生成式AI整合到自家AP中。

相較於2023年，科技巨頭展開激烈的LLM模型技術競賽，到了2024年，企業的目光轉向如何打造更有ROI效益的GAI應用，開始嘗試、尋找各式各樣合適的應用場景。

回頭看2024這一年，相較於LLM模型技術的爆發式進步，相關軟體開發工具相對步調較慢，甚至沒有像Sora模型或o1模型般的突破式進展。GAI輔助軟體開發的相關工具，的確明顯進步了不少，像是GitHub Copilot之類的生成的程式碼品質越來越好，也開始出現了協助開發測試、除錯的GAI助手，甚至出現GAI應用專用的開發工具，不過，主要用於開發獨立的GAI應用，或是生成式AI的代理程式，甚至專門用於幾種特定用途的GAI代理助手的客製化。

這些GAI開發工具的改善，只涵蓋到了軟體開發，或者說只占了企業打造一支應用系統生命周期中的一部分，隨著越來越多企業公開了自家GAI實作經驗，慢慢浮現更多GAI開發工具和方法論的不足。

最常見的挑戰是，用提示工程來開發GAI應用時，IT部門不見得能夠有效檢核模型的生成結果，每一次調整，都需要業務部門來協助評估，導致IT與業務必須多次來回合作，我常提到的經典案例來自永豐金控的經驗，開發人員撰寫出一版提示後，得由業務人員協助測試不同情境，檢核模型回應內容來提供修改建議，再回過頭交給開發人員修改提示，然後同樣過程再來一次，如此反覆十多趟，才能完成這一個專案模型提示指令的調整。業務人員的參與度，成了AI應用開發效率的關鍵。

科技大廠也的確觀察到，許多企業開發GAI應用的挑戰，甚至，開始將GAI視為應用系統和開發的重要元素。微軟執行長Satya Nadella在年度大會上強調：「每一隻App正逐漸變成AI化的App，」未來每一隻應用，都將是AI應用，但現在打造AI應用的技術架構，才剛起步，有待發展，「開發工具還需要增加更多新功能。」這正是微軟的新戰略之一，全力發展通用型GAI技術基礎。

AWS同樣看好未來龐大的GAI應用需求，AWS新任執行長Matt Garman在年度大會更直言：「生成式AI（GAI）將成為每個應用程式的核心！」，如此看重GAI角色的願景，也影響了AWS所有的產品策略。

AWS不只是大力強化GAI開發相關工具鏈，GAI開發工具Bedrock強化提示管理和多代理協作能力，傳統AI開發平臺SageMaker更是大改版，變成了整合資料處理、分析應用和AI工具的大平臺。

AWS原有的三大雲端服務產品線，運算產品線、儲存產品線、資料庫產品線的升級，今年都聚焦了GAI龐大需求來升級。AI開發工具的競爭，從GAI專用工具，開始擴大到傳統的軟體開發工具，甚至開始進入IT基礎架構技術和工具，這將考驗企業原有的軟體開發，甚至是基礎架構維運模式。

 更多相關報導