來聊聊生成式AI的簡單商業應用。

兩種思路，一個是把AI當輔助，以提昇現有作業成本效率為主，另一個則是發展所謂的AGI通用人工智慧，直接用AI徹底取代人力。

傻蛋不談後者，因為那太複雜了，不僅是技術問題，還有倫理哲學問題，以及商業形式的問題。

先把對AI的應用放在輔助人類現在的運作，如何提升效率與競爭力上頭吧。

現在的生成式AI主題多半落在模型越大能力越強，毫無邊界，只要繼續堆更大的模型，餵更多訓練數據，通用人工智慧早晚會無所不能，擅長煉金術與黑魔法這個方向吧。

傻蛋不會去否定這種可能性，不過對於一般正常沒有魔法體質的人來說，這種需要通靈能力的道路是很難走通的，所以還是專注於眼前能做到的部分吧。

以下會簡單介紹，現況的生成式大模型API可以怎麼使用，以及對於服務提供商的應用方式的一些建議。

首先，讓我們先忘掉聊天室對話的使用者介面一下吧。

生成式AI大模型的API調用，基本上，就是API調用。

廢話不是?

每一次有人類邏輯智能的內容生成，就是一次API調用。

就像是一次函數呼叫。

當你輸入，請問一加一等於多少，模型就會針對你的輸入進行思考推理，然後生成較可能的回答，有一定的隨機性，可能會收到一個中文的二，或阿拉伯數字的2，也可能收到答案當然是2，您還有甚麼問題嗎?這類的回覆。

根據模型受的訓練不同，模型回答的能力與方式也會不同，不過基本上就是我問模型答，一問一答，模型針對我們的提問做文字接龍。

比較冗長點，技術點的說法，則是(你可以不用太在乎細節跳過這個長句子，因為不是很重要)，你輸入的內容會先透過分詞器轉換成模型使用的語意向量，然後這組語意向量會進行推理生成，進行很多層的多頭注意力與訓練出來的神經網路權重向前傳導的運算，最終得到一組張量，算是思考的過程的階段結果，再來逐字根的進行生成，根據張量提供的機率選擇第一個字根，然後再把選中的字根當下一個已知的輸出預測下下一個輸出的字根，如此一直反覆直到結束的字根被預測挑選出來或是超過對話窗口限制而終止，那些推理出來的字根透過分詞器還原成輸入格式，就是我們得到的AI輸出。

可以去讀論文或看開源的程式碼，上述的過程其實還是挺多細節與複雜度的，較先進的大語言模型融合各種新的研究算法，時時變化與改進，像傻蛋這樣的外行人要一個人徹底研究弄懂，到可以自己從頭實現一個大語言模型的程式代碼，可能要好幾年不眠不休的努力才行。

但如果只是要拿來用，就不用管過程是怎麼設計的，只要管怎麼用，與目前使用的對象的特性與注意事項就好了。

實際上可以抽象成就是我問AI答的函數調用這樣就好。

最早期的API介面叫做Text Completion，文字完成，是真的如其名稱，就是AI做推論進行文字接龍完成。

函數的輸入是一連串的文字，而通常會約束最後要放AI:做結尾，讓AI知道從這個地方往下預測接龍，如:

用戶:喜馬拉雅山的高度是幾公尺高?

AI:

然後我們可能會得到8848公尺，或喜馬拉雅山高度為8848公尺，或口語話點的就我目前的數據，喜馬拉雅山高度為8848公尺高，不同模型對同樣輸入的回應有所不同，並具有一些隨機性。

你可能會碰到Llama3的未進行中文微調的模型會有機率用中文問然後用英文回答，或是回答時中英夾雜，大模型用其母語英文思考，沒訓練好的話很容易會冒出相同語意的英文回覆來。

同樣的，這也不重要，我們只要知道那是一問一答即可。

一問一答，一次模型推論的API調用，收到生成的內容(基本上是文字)，就這樣。

生成式AI基本上就是這樣在生成內容。

AI的能力，則體現在訓練結果的神經網路各層節點的權重參數，輸入的請求會經過這個訓練過的神經網路那大量的權重參數，做向前傳導產生一個張量，作為思考過程，最後再逐字根的進行機率推理生成。

大模型的訓練會包含一組指令遵循的訓練資料，來教AI由輸入內容分辨各種任務形式，它們應該有的輸出該是怎樣，來訓練神經網路內有完成任務需要的知識。

對於沒在玩AI的人來說，上面一堆內容可能像天書，一堆專有名詞，不好理解，但對有在關注AI技術的人來說，上述的內容只能說太淺，而且是早期的形式，有很多東西沒提到，如串流的回應方式，或是函數調用等等，且目前主流的API呼叫也不是這個介面。

但請忽略那些複雜的細節，請先理解現在的生成式AI主要就是這個文字完成Text Completion，一問一答的API調用就好，這一點是繼續往下閱讀理解的基礎。

早期的ChatGPT也是調用這些API在與我們互動的，我們在網頁上輸入我們的問題，實際上呢，網站會幫我們組一段請求，那個請求文字會包含你是OpenAI訓練的ChatGPT，你的訓練數據截止日是某一天的內置的提示，接著是這個對話之前的對話記錄，最後面才是我們輸入的內容，以及最後一行的AI:讓AI繼續往下接龍完成生成。

沒有使用串流的話，就是會看到畫面轉圈圈，輸入分詞做注意力計算需要運算處理，思考完成逐字根生成完畢後我們收到結果，如果有啟用串流機制，就只是推論過程每次選一個新字根就馬上即時輸出給前端更新畫面而已，那個模型推理機制與過期是相同的，還是那個一問一答的。

對，最開始的大語言模型大概就這樣了，主要用途就是用來瞎聊的，一問一答。

模型就是根據訓練的權重結果，把新的請求輸入做一次推論，然後產生思考結果張量，一機率逐字根選擇輸出內容。

其實新的API介面，也是從舊的API介面疊加出來的，甚至，可以在沒有調整模型結構，訓練資料的結構的情況下，設計出新的API介面的。

第二代也是目前較成熟，主要被使用的API介面叫Chat Completion，聊天完成的生成，也是如其名，主要用途是多輪對話使用情境的使用。

它和上一代概念本質上是一樣的，差別主要在格式。

由上一代的一整坨文字輸入，改為結構話的對話訊息列表方式來作為請求的格式。

這一版的介面其實也就是，第一條通常是角色為系統的提示詞，由我們告訴AI這個生成任務有什麼指示，我們需要它怎麼處理使用者請求。

接下來是一條一條的訊息，當然主要還是一問一答的對話歷程，簡單的案例，下一條是用戶第一次的問題，再下一條是當時AI做的生成回答，所有對話歷程都塞完，最後一條是這一次用戶的問題，到此為止。

不用再塞一句AI:提示AI該你了，這個傻蛋猜是這個新接口自己幫我們偷塞的。

注意到了吧，其實這個結構化的新結構也就只是做了結構化，我們完全可以用這個結構組出和舊的API一模一樣的請求格式，一樣的那一坨文字，不需要重新訓練，就能做出完全一樣的請求輸入，那麼輸出當然也和原本一樣啦，這個OpenAI就透過這個Chat Completion的新介面，讓其API調用的介面更加的物件導向了喔，看起來變專業與高深了點吧。

本質的一問一答是不變的，一次調用就對應一次生成，這一點是沒變的。

再來我們來拆解OpenAI的魔法，那麼function calling吧。

Chat Completion如果只是改請求介面而已，那就有點Low了吧?

有的，有個新發明，叫function calling，函數呼叫。

好棒棒，這下大語言模型可以呼叫外部Function，於是能做更多事了吧?

就某種角度來說，這個說法也沒錯啦，但這個函數呼叫的新介面與機制，其名詞是有些誤導的，我們需要除魅一下，才能了解其本質。

剛開始接觸時傻蛋也是以為這個功能就是讓AI自己判斷情況，主動呼叫需要的功能。

但看完接口介面與範例後才發現，其實不是那回事。

這個Function是我們要寫，要實現的，而調用這個我們寫的Function，也是我們開發的API要做的事。

這個function calling的機制是這樣的，我們在請求的訊息列表之外，額外提供一組我們給AI可以調用的Function，包含名稱定義用途描述與參數介面與每個參數的意義用途描述，用結構化的json方式傳遞。

然後AI會在有收到可使用的function定義時，自行判斷是否需要呼叫。

如果無須呼叫，則AI會直接在這次請求回傳生成的內容。

如果判斷需要呼叫我們提供的function才能完善的完成這次請求的生成，此時我們的調用會收到特殊的回傳格式，不是收到生成結果內容，而是收到需要採取行動，與需要調用哪幾個function，每個調用要使用的參數是什麼。

簡單情境時，通常我們只提供一個function當選項，也只期待被呼叫一次，而且我們也會在提示詞裡告訴AI這次的請求處理該怎麼判斷function呼叫的需求處理邏輯，就期待呼叫一次，我們收到需呼叫的function名稱與調用的參數值，然後我們動態的調用我們寫好的function取得文字內容的結果後，這個接口要求我們再把結果用它給我們的調用方式再送出一次，這一次AI除了收到提示詞與聊天歷程與這次的問題之外，訊息中間還會插入調用function得到的我們送給它的內容，然後再來做一次判斷回答，一般來說就是綜合額外資訊後完成這一次的一問一答的請求生成這樣。

這一坨流程很噁心吧?

實際上這就是讓AI判斷它可以直接回答，或是需要用問題內的線索取得額外資訊後才能作答，先做一次判斷，然後該查就查，查到該查的資料後重新再請求生成一次而已。

看起來function calling好像做了巧妙的介面與呼叫流程，但實際上呢，背後其實也是調用兩次或更多次，做和我們人工判斷後我們自行調用多次是一樣的，不論在實際推論與API和我們依使用token數量收費，都是一樣的。

唯一增加的是，我們宣告了支援function的請求時，一旦AI判斷我們應該要執行查詢並繼續生成時，我們需要把事情做完再調用一次接口讓AI繼續完成任務而已。

可以想見的，當我們使用function calling時API的呼叫流程會變得很複雜，例外處理要小心，除錯會變困難，整個複雜度就咻一下的整個提高起來了。

而實務上呢，我們照需求去整和AI的API時這個function calling並不常用，反而早期有另一個需求情境在大量使用function calling。

那是什麼需求呢?

就是我們需要AI具有基本邏輯理解與綜合判斷力的特性，來為變化性較大的輸入做分析判斷，並產生依照需求規則的結構化數據，讓我們用來串接後面的程式流程。

例如，我們希望AI能分析輸入的內容，找出適合貼到此客戶的標籤，讓我們更新到客戶關係管理系統內，提升我們對客戶的掌握度，然後同時又希望後續流程可隨機抓取多個同客戶標籤規則的其它幾個客戶，做和本次行為事件相關的指定訊息推播。

這樣的任務人可以做，就用肉眼去閱讀輸入的資訊，照著給好的規則，仔細分析，決定該怎麼做，然後照規則小心確實的執行就好了。

這也是常見的工作流程，工作就是一個一個步驟流程的組合，其中某些關鍵步驟需要判斷力，需要小心的照規則作複雜的靈活判斷，太笨或太粗心的員工做不來，需要細心又有耐心的員工來處理，把服務流程做好也能提升商業上的價值，如更貼心的服務體驗，更完善的錯誤預防等等。

所以我們可以在這種需要大量重複且複雜辛苦人工判斷的情境下，使用生成式AI來做判斷，然後我們期待AI給我們結構化的結果，我們可以當作參數去方便的去調用後續的程式流程，把整個自動化串起來。

嗯，早期的語言模型AI行為，它常常無法穩定的遵循指令產生需要的json格式，常常就是死也要給你markdown格式，或是控制不了自己要多插一句話解釋自己的生成讓輸出的文字不是一個有效直接可用的結構。

噹噹，早期function calling就是這個時候拿來誤用的，因為它不是生成文字內容結果，而是要我們再呼叫一次的請求格式，並且把合適的參數提供給我們，讓我們自己調用，調用完再拿結果讓AI完成請求的內容生成。

對，就是借用來讓AI產生結構化輸出而已，然後不會再繼續跑完函數調用後的生成流程了，做一半就跑了那樣。

沒辦法，因為我們主要的商業與管理面的應用就是使用大模型的模糊輸入的依照規則的綜合分析判斷能力，來做一些本來要人才能做的關鍵流程節點。

自動化就能省人力了，而且自動化後可以管理控制，有問題也可以抓出來加以改善，這種應用情境，還真別說，用AI可能比用人工更合適。

人會累會眼花，但AI不會，複雜問題需要的人力成本也高，但良好訓練的AI模型可以複製成功，成本相對低很多，甚至可以更穩定，品質更好。

所以這裡引出來我們需要AI的主要需求情境，就是高複雜度的判斷邏輯需求，可以用AI來強化這部分的流程，無論是成本面還是品質面，都有優勢的。

判斷完該麼走就怎麼走，不需要額外的創新，只要把原本的流程改善與自動化機制加入高階的生成式AI的輔助，就能創造相當的價值出來了。

所以傻蛋看懂並試用一次那個function calling後就再也沒有使用它了，簡單需求就讓AI生成第一個token是判斷選項答案，後面生成的是那個選項的對應需求參數，並在提示詞告訴AI不要多嘴，我們後面就自己串流程即可。

所以現況來說，傻蛋認為生成式AI目前可以穩定產生效益的地方就在自動化的輔助。

只要分析工作到位，工作的拆解與設計有做好，在合適的關鍵位置用AI來取代，是可以有不小的效益的。

而要滿足這種需求，去年中的GPT-4其實就夠用了，後續這一年來的發展，除了我們看不到的，可能的架構與成本改善，大模型的API調用體驗，其實進步很有限，甚至還有時候會出現不穩定與倒退的情況。

不久前測試新的GPT-4o，儘管OpenAI說新模型又快又便宜又更優秀，但傻蛋當時測試的體感是，變笨了，變不聽話了。

就一陣一陣的，有時候又突然變聰明了，過一陣子可能又變成有Bug，OpenAI的API調用起來是方便，但服務品質不是很可靠。

而其他開源的，開發階段可以免費的替代大模型，基本上還是不如GPT-4的，不過小心調整提示詞的話，還是一定程度上可以使用。

傻蛋覺得那些大模型公司可以改善的部分則是，或許可以像程式語言的語法糖一樣，提供一組常用情境的提示詞糖。

只要分析幾種常用的商業用例，看其提示詞使用的模式，有沒有常常出現，又必需寫得很詳盡才能達成目的的提示詞，這種情況可以設計一組針對分析出來的目的，用保留關鍵字來壓縮這種需求的定義描述，這樣用起來也方便，使用的token數也可以減少，且大概率的能減少運算數量與網路傳輸的流量，還能節約能源吧。

達成一些精心設計的功能，現況那個提示詞常常很長很長，還要小心模型更新後可能又不靈，在那改來改去的，而且這些提示詞也常常是重複的大量的在每次請求都重新傳遞當作輸入，設計一組提示詞糖的設計對於商業應用應該會很有幫助，而且實現難度應該不高吧。

好了，正題講完了，剩下的是繼續幹古講廢話了。

我們繼續來看看大模型的 API調用的故事。

剛剛是說到那個，function我們要自己寫，呼叫也要我們自己呼叫，被綁死要再呼叫一次function查詢結果來做生成的function calling吧。

聽起來就難用沒錯吧。

如果希望生成的互訂顯示比較即時，使用生成階段串流回傳的設計，搭配這個function calling，大夥可以想像一下那個整合串接會有多複雜吧。

就是那麼可怕的複雜。

而且AI萬一失控，你幫忙查了資料，讓AI再判斷一次作答，如果AI還是判斷要繼續調用function不然不夠作答，這是會陷入循環的。

好比說，我們提供網路查詢引擎的關鍵字查詢回傳列表，與提供指定連結取得頁面內容的兩個function給我們的AI模型來針對某個問題作答，理想情況是關鍵字查詢結果列表給AI看一次，AI選一個連結讓我們查內頁詳細內容給它，然後第三次的調用，第二次送出function結果時AI就應該完成回答的生成了。

但第一頁找不到合適的參考資料怎麼辦?

AI可以查下一頁吧?

如果看了內頁發現和問題解答無關，可以再回頭找其他上一次查詢結果列表的連結吧?

如果我們讓AI自行判斷，完全不做干涉與控制，則有風險，是AI一直找不到合適的參考資料，於是無窮循環的在一直要你查資料給它。

陷在裡面是很可怕的，你如果發現請求次數異常，成本費用異常，你該做的是停掉你的程式，來打斷這種無窮迴圈的調用。

不然你有再多錢都不夠噴的。

這些反覆嘗試通通會收費，提示詞與對話歷程，送上去的查詢結果文字，都會算輸入的token，別看我們能打的問題沒幾個字，精細的提示詞可能會上千個字根，查詢結果依格式也可能很大，對話歷程也同樣有使用大量token的潛力。

早期有些人可能就是設計不好，然後出現這種情況，儲個一百美金一下子就噴完了，甚至還持續扣錢，必須說，得小心，這服務還是有點瞎的。

而聊天API介面其實也可以看做是文字完成接口的包裝，因為我們完全可以自己封裝一層，底層調用Text Completion，然後做出一模一樣的調用Chat Completion介面。

即使是function calling也不例外。

只有需要AI長篇大論輸出大量內容時，那個即時串流才有使用的需求，這一點才算得上是進步。

但我們前述的商業流程自動化應用情境，看起來也是用不到串流的吧。

而大模型的API介面，直接調用的介面，目前大部分廠商都是OpenAI compatable，完全相容OpenAI的Chat Completion，所以只要串過一家，其他家就不難整合串接了。

被大量使用的AI的API調用，主流也就是調用Chat Completion，一來一回，直接簡單，到這裡為止你都跟得上的話，你基本上就會用了，API打個幾次就知道了。

請求一次，就生成一次，就收這一次生成的輸入與輸出的token數量的費用。

現在的大模型沒記憶，沒狀態，你請求丟什麼給它，它就根據收到的請求做生成。

如果你的請求沒有放進對話歷程，就會被當成新的對話，你的對話歷程放什麼內容，它就信你是在那個歷程後繼續對話的在進行後續生成。

如果你在請求時沒有提供它參考資訊如function調用的結果，它就無法用那個內容作答，如果你給它某個相關資料卻沒在提示說這資料的始末與用法，那它也只能看到什麼就用什麼作答，你沒頭沒尾的調用，它也給你沒頭沒尾的幻覺生成。

其實故事到這裡是可以結束了。

但值得吐嘈的卻是在這之後的事。

大家都知道去年11月7號OpenAI出了一個開發者大會，推出了助手API與那個現在已經涼涼的GPT Store吧?

再來就是說這個助手API，Assistant API的故事。

當初傻蛋開始碰與開始串接就大約是從這個時間點開始的。

想說，這設計很好啊，只要定義一次助手的指示，之後讓同一個助手作生成回答，就無須重複再指定那個提示詞了。

而對話歷程的設計初看也很方便，建立對話後，和以往每次請求自行維護對話歷程並重複把之前歷程放在下一次請求，助手API的對話機制只要往對話加新訊息，然後指定助手對當前的對話做一次生成回答就好，同一個對話的新請求只要繼續加入新對話歷程，再調用指定助手做生成回答就好，省略了大量的重複輸入。

還可以切換助手，或是添加用戶提問後，讓第一個助手先回答一句，再讓第二個助手接著再回答一句，可以混合使用，更加靈活方便。

除此之外還有上傳檔案給助手，讓助手AI可以根據內建的知識來進行回答，很好很強大很方便。

第一印象就是這貌似很牛。

然後就去嘗試整合串接這個新的API介面做一些演示的應用。

當時是因為生成速度太慢所以才不使用的。

助手API剛推出時不支持串流，所以當時要做AI聊天應用，基本上就只能用舊的Chat Completion接口。

然後繼續深入了解後，才發現，這個助手API基本上是騙人的低劣包裝。

在會話裡會多次生成，每一次生成叫作一次執行，一個Run，可以查每次執行的步驟，來看實際上到底做了什麼，與和使用者收多少錢。

結果呢?

助手的指令的確建立時宣告設定一次就好，使用指定助手做回答生成時無須再傳送一次提示詞，但我們去看實際執行，每一次的請求都會重複的傳送完整的提示詞，每一次都重複收費的喔。

對話歷程也是，在執行歷程裡也是每次重複傳送，錢是照收的，雖然我們沒有放進呼叫的請求接口裡，但實際底層調用還是會自動被串起來，然後照樣向使用者收費。

而且還因此增加無法控制的限制，以前透過Chat Completion時因為請求大小是有限的，我們不能無限制的把對話歷程一直串進去，請求超過大小就無法呼叫了，所以我們會有一些策略，如對話歷程不超過某個最大的token數或字數，超過就從最舊的截掉，又或是當對話歷程成長到一定大小時，就另外呼叫一次大模型做對話歷程摘要壓縮，並用壓縮過的摘要取代之前的對話歷程來避免請求超過上限。

而助手API剛推出時是強制的，對話歷程會一直累積到對話請求的上限為止，超過上限就自動取消最舊的對話歷程直到可以滿足請求大小為止。

與此同時，這一版的模型還大幅的放大請求大小的上限，由4k/8k/16k/32k一口氣放大到128k，對話請求塞滿時一次請求就當時的收費，印象中大約就近一美金的樣子，那是貴得嚇死人的。

金玉其外，敗絮其中，第三代的助手API其實去翻它底層的執行步驟來看，它也是調用無狀態的Chat Completion在內部運作的，那些節約成本的可能性其實都沒有，就是調用起來方便點，而看當時的設計，是怎麼浪費怎麼實現來著的。

開發者論壇上很多人試用了後發現怎麼會那麼貴，於是又退回去用上一代的介面。

基本上要等過了大半年之後，當初不支持串流，與對話視窗無法自行控制的缺陷才在大改版更新陸續改善彌補。

但本質還是不變，背後還是調用上一代的Chat Completion的，成本問題只能從模型本身降價來實現，減少重複呼叫參數節約成本仍是不存在的。

而無論是助手API第一代還是第二代的知識問答設計，上傳檔案，做知識問答時，其實也都是OpenAI背後自己做上傳檔案的文字轉化，然後把文字切小塊，對每一塊文字編向量索引，再針對用戶知識問答的關鍵字做向量化，再做語意相似度排序，找出最相關的幾塊文字，用這些文字當參考資料讓AI再做回答而已。

過程中只要需要請求AI模型的，如解析關鍵字，與最後作答階段，用拿到的參考資料一起送進去讓模型生成答案，每次調用的費用都是照token計算的，那個知識問答的參考資料取樣取得少，只有破碎資訊自然容易因為資訊不足而胡亂回答，而取樣多的話，不相關的資訊也會被放進去，傳多少資料就收多少錢喔，即使我們表面上看不到，底下都是照算的，完全沒有幫你省錢的。

所以呢，這一堆新功能，花裡胡哨的，大多是中看不中用，只是平白的增加複雜度而已。

可以完全不需要助手API，而我們不想重複定義的提示詞，存我們數據庫就好了，可以做版本控制，依照我們的需求來管理與控制，只會比新版的API簡單方便的。

而不提OpenAI，還有許多的AI開發框架，其實也是做差不多的抽象封裝的工作。

實際上呢，一些看起來厲害的自動執行，就是反覆調用很多次API實現的。

在提示詞給AI目標，讓AI分析需求，擬定下一個行動計劃，然後在封裝好的函式庫做對應的調用，得到結果後再問一次AI，讓AI判斷任務完成可以說一句話結束，或是要再進行下一個步驟，就持續反覆的調用與執行反饋，直到目標被達成為止，這叫作AI自動化吧。

有些框架就提供相對簡單的使用方式，讓你的AI可以做到這種效果。

你應該會想到，需要設定最大步驟數，超過設定的步驟數後無論如何都要失敗結束，否則AI就會在那調用個不停，一些夾資料回傳的機制又很吃輸入的大小，沒控制好你的錢包就會破一個洞，源源不絕的燒錢了。

AI應用有各種酷炫的案例，其本質大多是依賴AI已有一定程度的人類邏輯思考力，然後就無腦的連續串接，自我調用，擴充AI可能呼叫存取的功能，不斷的在反覆請求中自我實現啦。

如果只是針對具體的需求與問題，要來做流程優化與效率改善，其實根據需求，調用必要的AI判斷輔助自動化的順暢，只要調用Chat Completion甚至快被淘汰的Text Completion就夠了，簡單可控，把調用歷程紀錄在自己的數據庫，還能做效果分析檢討，以及可能的訓練資料的抽取，而這些，基本上都沒啥技術難度的。

不需要懂機器學習，不需要懂那些統計理論與模型設計，你只要會用就夠了。

至於OpenAI的那些新演示，如Sora能用提示文字生成影片，以及最新的GPT-4o可以即時影音互動，這些東西推出了好一段時間，API都是沒得試用的，不好多說什麼。

傻蛋個人的感覺是OpenAI這公司除了早期弄出ChatGPT引爆風潮，以及GPT-4剛推出時的高光時刻，後面的表現都乏善可陳，看起來像是公關與謀略點滿，但技術面的基本功是令人質疑的。

AI技術上真正的領先者，傻蛋覺得Google，甚至Apple都可能會很快趕超OpenAI，把目標放在更有經濟效益的小模型，更適合做商業化落地，成本較低，對環境也較友善。

而那個AGI，就真的不在討論範圍內。

如果想入局大模型，想作機器學習的研究，想嘗試各種想法，這個不是一般人可以玩的，沒算力，一個嘗試要等很久才能出結果，一次嘗試就要不少費用，不如預期就全打水漂。

所以真的需要一大堆機器學習的專家嗎?

平庸的機器學習專家搞不出東西吧。

中小企業研究大模型，用自己的資料訓練自己的大模型，划算嗎?

不管是開源還是閉源的，直接用最新的模型，那些用海量數據與海量算力訓練出來的模型，效果可能都比自己摳摳索索沒啥資源投入搞的大模型要好用吧?

還是大家都要做AGI的夢嗎?　

還是務實點，認真做好行銷與創新，把生意做好吧，對大多數人來說，現在的生成式AI只要會用就好了，該怎麼用就怎麼用，現在暫時還輪不到AI來主導世界吧?