2023年因為OpenAI GPT模型的爆發，一方面跟著多數人一樣朝聖的使用著ChatGPT，另一方面在下半年因為寫了一本面向開發的書，進而關注到由 Microsoft 主導開源的 Semantic Kernel SDK(用於開發LLM應用)，這半年來我持續關注SK的發展，從0.x版到目前終於釋出第1個正式版。前幾天在保哥的直播活動上，我介紹了從開發面向如何使用SK，而這篇文章我打算從不那麼技術的層面來看這一年LLM 與 Semantic Kernel 對未來軟體樣貌可能的轉變(純個人觀點)。
時間先拉回到幾年前 Microsoft 推出了一個 Azure AI 服務- LUIS 服務，用AI模型在自然語言中推測使用者意圖以及擷取文字中重要的關鍵字詞，我還記得當年(沒記錯的話，莫約是2016年) Microsoft CEO Satya 喊出 Conversation as a platform 的口號，不難發覺當時就透漏出 Conversation 可能會是未來軟體的樣貌，那個時候除了 LUIS 服務之外還有 Bot Framework、QnA Maker等各種與 Conversation 相關的 Azure AI 服務，這些服務可以協助你處理自然語言以及串接各種社交平台，像是 Linebot等，可惜的是後來這方面的發展有些雷聲大雨點小，並沒有太大量的應用轉向以 Conversation 為主的樣貌。
雖然當時有著 LUIS 服務，但對於自然語言的預測還是得依賴特定情境資料的訓練，這形成了一個門檻，特別是對大多數開發者來說，AI的原理或概念是不熟悉的。再者即便有了資料也並不保證訓練後的模型其能力是好的，受資料的影響，模型可能有過擬的情況造成實際上線與測試情境的效果差距。再著當時的AI模型對於自然語言的理解及處理，都還無法支撐一個功能稍複雜的應用，所以多數看到的實現還是非常侷限特定的任務，離理想上的目標還滿遠的，因此幾年下來 Conversation as a platform 的願景可以說並沒有真正的被實現。
Conversation as a platform 的想像
Conversation as a platform 的願景，其實是想打造一個全新的軟體樣貌，以Conversation 取代應用軟體的使用者介面(按鈕、選單、輸入框之類的)，透過文字對話實現對應用軟體的操作，舉例來說：當我想查詢東京旅遊景點，我需要先找到查詢功能，然後輸入東京這個關鍵字，再按下查詢按鈕，然後等待結果顯示，而如果是 Conversation 的情境，就像是我用說的或文字去問專業旅行社，然後它能明確懂得我的需求，然後給我回應。一切就像真實生活上的對話那麼自然。但這件事想要在應用軟體上實現其實是很難的，因為程式要面對的是不可控的文字（也就是自然言語），不再是固定的參數值，可以輕易用規則去判斷（例如if..else）。
時間再拉回到2023年 OpenAI GPT 模型的爆發，當我發現到它的能力與過去我所熟悉的 LUIS 根本不是同一個量級時，耳邊那個 Conversation as a platform 又重新響起，以 GPT-4 來說它是一個熟讀許多基礎知識的助理，你可以賦予它任何的角色扮演（嘿,我可不是說它一定能演好那個角色），然後就像你的朋友、同事一樣可以輕易與你對談交流，而這一切你完全不需要做什麼模型的再訓練，就是很自然的使用它，並且用的還是文字，而不是固定的使用者介面。
接下來就是 meta、google 也都推出了 OpenAI GPT 模型的競爭品模型，也有其它開源模型，也就是俗稱的LLM，他們或許能力上、技術上有所不同，但共同的特性就是它從文字上懂的你想要做什麼（使用者意圖），然後神奇的給你很好的回應（我想LUIS或CLU應該不久後會涼透了吧）。
簡單點可以想像成，我要請假，以前你必須進入系統畫面，輸入該有的資訊，然後送出，現在你只需要說出＂我明天下午3點到5點休假＂，然後接下來的一切就是有人會幫你自動產生假單，發送假單簽核流程。一切就這麼自然，而操作介面可以一個簡單的對話框（就像ChatGPT網頁一樣），或是Line、Teams介面（UX以後會不會也涼了?）。
面對LLM應用開發的改變
做為一名軟體開發者，幸運的是我們擁有比一般使用者更好的機會，能用LLM來開發 GPTs 應用，不管是你想要自用或是發展產品用，就連 OpenAI 都開始搞起了 GPTs Store，甚至 Microsoft 也推出針對一般 M365 訂閱戶的GPT Pro 訂閱方案也能支援自訂 GPTs，市場開始頗有一股當年 Apple Store的味道。而當我開始投入試著動手做 LLM 應用開發時，很快的，我就理解到它絕對不只是呼叫 LLM API 這麼簡單而已。
我在先前幾場的 Semantic Kernel 演講中都提過一個例子，就是當你問 GPT模型”今天的日期”，LLM 是回答不出來的（我指的是直接以 API 方式連結LLM 模型，而非透過中介層介面，例如GPT網頁或GPTs）。
不可思議吧，對的，LLM 有它做不到的事，最直接的就是當下現實場景的資訊，它是無法自行獲得的，別忘了 LLM 還是脫離不了做為一個 AI 模型該有的資料訓練過程，它的大腦還是只能知道過去的事。
但是當我把今天的日期值做為 Prompt 內容的一部份時，再對 LLM 做 API 的呼叫，這時候，LLM 不只可以回答我今天的日期，甚至你問它距離月底還有幾天，它都可以算出來給你。
這個LLM應用場景顯示出幾件事：
- 首先 LLM 不是全能的，必須仰賴 Natvie Code 去協助它發揮，所以 LLM應用的程式碼會是混合式的，一部份是依賴 Prompt（LLM模型自帶的能力），一部份是原生程式碼例如 C#、Python（LLM模型辦不到的能力）
- 程式面對的 Input 會一改過往從制式的 command 變成是 Prompt，並且進一步必須使用 LLM 去預測意圖，分析參數值
- LLM 具有自走砲的能力，不再依賴程式碼，像上面提到的計算到月底還有幾天，程式邏輯內並沒有寫這個計算，甚至並沒有預先規劃有這個功能，然而在 LLM 的應用，面對使用者各種樣式的 Prompt，LLM 是有機會自動完成任務，但是帶來也是另一種風險，因為 LLM 的不可控，因此無法預知會輸出什麼樣的回應，甚至相同的需求會得到不同的輸出，因此如果不對 LLM 的輸出做風險控管，則可能會為企業帶來傷害，例如做為一個銀行客服的 LLM 應用，它自動免除了客戶的手續費或是自動承諾客戶給予賠償
除此之外，更複雜的應用，還可能涉及了以下層面：
- 任務拆解組合，現階段 LLM 的一些研究都表明了，把大的任務拆解成小任務再做組合，能有效提升 LLM 回應的品質，因此如何拆解任務，如何銜接上下任務鏈的輸出入資料，是在開發 LLM 應用中必定會遇到的問題，我在之前的演講也舉了一個相似場景的範例，一個臉書貼文小幫手，先做貼文的生成再處理英文版本的翻譯，英文的翻譯必須基於前項任務貼文的產生結果
- 基於 LLM 訓練資料的不足，以 RAG 設計架構注入參考資料於 Prompt，藉以擴展LLM的認知能力，而這個就會延伸出涉及到向量資料庫的應用
- 不同時期版本的 LLM 模型，對相同的 Prompt 可能會有得到不同的成效，也就是 Prompt 無法制式化，因此改天出現另一種 Ops 叫PromptOps，我們也不用太意外
從上述的分析觀點，不難發現要開發一個 LLM 應用真的不是只有叫用 LLM API 而已，我們需要一個指引、一個框架、一個典範來引導，畢竟 LLM 的應用才剛開始，Semantic Kernel 剛好滿足了這樣的需求，Microsoft 基於過去開發 Copilot 的經驗，設計 SK 這個開源 SDK，試圖引領如何設計與開發 LLM應用，也因此在去年我從 LLM API 的呼叫到 Prompt engineering 後，便持續關注SK的發展。
Semantic Kernel 的助力
而對於 Semantic Kernel ，我個人覺得目前有3個主要的關注點
- Connectors：做為模型或其它服務（例如向量資料庫Qdrant、Chroma…等）的連接，並且不据限於只有 OpenAI 的模型，像 HuggingFace 上可以落地的模型也行
- Plugins （早期版本稱為Skill）：一或多個 function 的集合，而 function 又分成了 Semantic function（語義function）或 Native function，說白了就是用來驅動 LLM 模型做事情的關鍵，Plugins 決定了你的 LLM 應用的能力，Semantic function考驗的是 Prompt engineering 能力，Native function考驗的是寫程式的能力
- Planner：實現模型全自動理解，由 LLM 模型自我理解該做什麼事，自動呼叫 Plugins，這是一個理想願景，然而 LLM 模型目前還有極大的不穩定性，無法確保每次模型的理解都是正確的，並且自動的每次依正確的流程順序執行任務，所以 Planner 目前算處於很前期的階段，不太建議真的實作於生產環境，而 Planner 也非常依賴 Prompt，因為 LLM 模型是藉由每個 Plugins 裡的 function description 來理解 function 功能，才足以能在需要時自動決定該呼叫哪些 function。整個 Planner 可以理解成這樣實現，一個旅行安排助手，從接收到一個旅行安排任務（Prompt請求）開始，LLM 模型開始針對你的旅遊景點、你有空閒的日期規劃天數、然後機票、預訂飯店等各項任務自動化依序展開，程式邏輯完全不需要決定這些項目的先後順序以及相關資料的傳遞（前題是旅行安排助手已預先設定好完成這些任務所需的對接 function），最後生成或完成整個旅行的規劃。
Semantic Kernel的這 3 個關鍵恰巧對應了 LLM 應用開發時所面對的問題，並且從 Semantic Kernel 的設計看到了對於 LLM 應用發展的面向，未來（其實也就是現在）開發者寫 Code 會是基本中的基本，對於 Prompt engineering 的掌握，理解 LLM 的能與不能，改變軟體應用建構方式，恐怕會是另一種拉開 developer 層次的指標。當然，這只是我個人的看法，誰知道明天起床會不會 GPT-5 就出現，然後又把我們拉到另一個不可思議的世界呢？別忘了，這世界唯一不變的就是每天都在改變，我們要面對的不只是客戶需求的改變，現在我們要面對是AI正在改變我們所處的世界，而且是地震式的改變。
後語與參考
除了技術層面，LLM 目前還面臨著成本高、運算力需求高的現象，以 GPT-4來說，還玩不起落地的實現，就連雲端服務的申請及用量都還是有限制的，企業老闆願不願意投入雲費用這樣的成本，建構私有 LLM 應用的服務還有待觀察。相對的也不是每個開發者都那麼幸運的有機會接觸或投入成本去模索 LLM 應用開發。未來還充滿很多空間跟挑戰，老實說一切未知，但有一點是確定的，就是有機會就多試試總是沒錯的。
先前上保哥直播的內容，影片錄影已在保哥的 yt 發佈，有興趣了解 Semantic Kernel 的朋友，可以參考 https://www.youtube.com/watch?v=fM9MrxqgbU4&t=2s
