許多討論生成式 AI 應用時，經常會聯想到 Chatbot。不可否認，Chatbot 確實符合人類的慣用操作體驗，因為它能模擬自然對話。然而，對話模式也充滿不確定性。即使如今的 LLMs（大型語言模型）非常強大，但它們仍無法保證每次都能提供完全正確的回應。

舉例來說，當我想請假時，傳統的 Web 介面透過幾個輸入框就能快速、精準完成請假單的申請。如果將這個場景轉換成 Chatbot 的對話模式，可能會面臨以下挑戰：

• 必須從對話中提取請假的關鍵資訊。LLMs 模型是否能保證每次提取的資料都完整無誤，且不會遺漏重要訊息？
• 請假資訊通常涉及具體的日期和時間，這是 LLMs 模型本身不具備的精準處理能力。雖然可以透過 Plugin 提供參考資訊，但模型是否能每次正確理解「後天」或「下週三」等模糊日期的具體含義？
• 如果提取的必要資訊有所遺漏，對話就必須進行多次補充輸入，這增加了操作的複雜度，甚至拖慢流程（即便現在可用語音輔助）。

Chatbot UI 介面

Chatbot 的多輪對話模擬了人類之間的自然交流，能立即根據使用者的輸入回應，特別適合需要個人化回應或引導的場景，例如客服和諮詢。然而，對於一些簡單的需求，多輪對話可能會拖延操作時間。使用者可能需要經過多步驟才能達到目的，效率不如傳統的表單或選單來得有效率。而且，當問題過於複雜時，Chatbot 有時無法給出精確的答案，甚至需要多次詢問來釐清需求。

在順利的情況下，使用者可能一次對話就能完成操作，但如果不順利，可能需要反覆來回溝通。這樣一來，Chatbot 的操作時間甚至可能比傳統 UI 還要長。雖然這些問題可能會隨著 LLMs 技術的發展而得到解決，但現階段，所有應用是否都應該完全轉向 Chatbot 模式取代傳統的 UI 操作，是值得思考的。

傳統 UI 介面

相較於 Chatbot，生成式 AI 也能透過表單、選單或條件輸入來生成內容。這種操作方式可以避免來回的多輪對話，讓使用者快速完成任務。使用者可以直接輸入特定條件，AI 會立即生成符合需求的結果，不需要進行逐步的對話澄清。

以請假為例，傳統的 Web UI 操作具有明顯的優勢。使用者可以精準控制和輸入請假資訊，確保所有必要資料都正確無誤。瀏覽器上的操作效率通常比 Chatbot 來得更快。然而，若相同的場景發生在如 Line 這樣的通訊軟體上，使用 Chatbot 可能反而更適合。因此在合適的場域用合適的解決方案，就現階段來說應該是比較好的選擇。

以下情境是不是傳統 UI 介面更適合呢

• 進行翻譯：使用者只需貼上文字並點擊按鈕，就能立即獲得 LLM 的翻譯結果。
• 修改文案：輸入原始文案後，按下按鈕，AI 便會給出修正建議。
• 內容生成：使用者可以選擇主題、風格或輸入關鍵字，LLM 將根據這些條件自動生成結果，無需進行多輪互動。

這些場景屬於一次性請求與回應的操作模式，適合那些已經有明確需求的情境，不需要多次來回的對話操作。因此，生成式 AI 的應用不僅多元，且展示在不同需求與場景。

示範 - 英文小老師應用

假設想開發一款英文小老師應用，讓使用者決定"主題"、"場景"、"學習者"三個要素，接著交由 LLMs 模型進行創作生成，可以想像這個 UI 可以是個網頁、視窗、觸控主機、平版APP。

• 建立 Kernel，使用OpenAI GPT-4o-mini 模型

var kernel = Kernel.CreateBuilder()
            .AddOpenAIChatCompletion(
                modelId: Config.openai_modelId,
                apiKey: Config.openai_apiKey)
            .Build();

• 建立 Prompt Template
  這裡考驗著 Prompt 的能力，可以多嘗試看看，可以看到在這個 Prompt Template裡，安排了 3 個變數，可以預期這3個變數值會在呼叫 kernel InvokePromptAsync 方法時，藉由 KernelArguments 傳入。

var prompt = """
你是一位英文教育專家，擁有30年的教學經驗，擅長引導非英文系母語的學習者學習英文，
現在請你根據以下資訊，提供5個範例句，並且在每一個範例句後面，都要進行講解，你必須假設學習者對重點單字可能不熟悉或不認識

主題：{{$subject}}
場景：{{$content}}
學習者：{{$ta}}

你的回答必須採取以下格式

例句：The teacher gives us homework.

講解：這句話的意思是「老師給我們作業」。
"teacher" 是「老師」，在學校教導你的人。
"gives" 是「給」的意思，表示老師把某樣東西交給學生。
"homework" 是「作業」，老師讓學生回家做的功課。

""";

• 配置 LLMs API 服務參數
  考慮到創造性，因此 Temperature 設高一點，讓模型發燒，展現創意風格，此外預期這個應用場境的生成內容文字會比較多，所以也把 MaxTokens 值放大

OpenAIPromptExecutionSettings promptExecutionSettings = new()
{
    MaxTokens = 1000,
    Temperature = 0.7
};

• 配置 Kernel參數以及Prompt Template 裡變數值

var arguments = new KernelArguments(promptExecutionSettings);
arguments.Add("subject", subject);
arguments.Add("content", content);
arguments.Add("ta", ta);

• 執行

var result = await kernel.InvokePromptAsync(promptTemplate: prompt, arguments: arguments);

Console.WriteLine(result.GetValue<string>());

執行結果：

例句：We learn new things every day.

講解：這句話的意思是「我們每天學習新東西」。
"learn" 是「學習」，意思是獲得新知識或技能。
"new things" 是「新東西」，指的是我們每天接觸到的不同的知識或資訊。
"every day" 是「每天」，表示這個行為是每天都在進行的。

例句：My friends and I play games during recess.

講解：這句話的意思是「我和我的朋友們在課間玩遊戲」。
"friends" 是「朋友」，指的是和你一起玩的同學或夥伴。
"play" 是「玩」，表示進行一種有趣的活動。
"games" 是「遊戲」，可以是各種有趣的活動或比賽。
"recess" 是「課間休息」，指的是學校中讓學生休息和玩耍的時間。

例句：We read books in the library.

講解：這句話的意思是「我們在圖書館裡讀書」。
"read" 是「讀」，表示看文字並理解它的意思。
"books" 是「書」，指的是用來學習或娛樂的印刷材料。
"library" 是「圖書館」，是一個可以借書和閱讀書籍的地方。

（以下略....）

因此可以想像一下，只要把上述的程式碼封裝成一個類別庫裡的方法後，就可以搭配各種 UI 介面，設計對應參數的輸入介面，輕輕鬆鬆就能為你的應用加上了生成式 AI 的能力，有了 Semantic Kernel 用不到 50 行的程式碼就能實作出來，很方便吧。而且這類型的應用完全不需要 Plugin ，都是直接使用 LLMs 模型本身的生成能力，而誘發 LLMs 模型能力的引子，就是 Prompt Template 的設計，依賴提示工程的能力。

結語

本篇透過反思，重新思考生成式AI與Chatbot的結合運用，並透過入門範例，一方面理解 Semantic Kernel 的基礎使用方式，一方面展示在現有應用上與 LLMs 模型的能力相結合是無門檻的，其實生成式AI離我們都滿近的。