什麼是 Microsoft Semantic Kernel:
-
Microsoft Semantic Kernel 它能讓我們把一系列面向不同需求的 OPENAI(包含 Azure OpenAI) prompt engineering 以抽象方式打包到這個語意核心(Semantic Kernel)框架上，讓我們能透過簡單上下文設計，讓 OpenAI 與 Python 或 C# Language 互動，完成更複雜細緻的作業。
-
比方說: 我可以寫一系列工作清單輸入到一個以語意核心框架為基底的程式上，這個程式的語意核心會自動解析清單需求，協調相關資源，並產生完成相關標的流程程序，該發信的發信，該寫到行事曆地寫到行事曆，或是同時判斷清單上的事務需求，列出相關準備事項，又或是參照當下天氣，提醒使用者再預測有雨的天氣攜帶雨具等等，它不像我們平時的 prompt engineering，一次只針對單一的任務型態，而是能判斷輸入的文字，幫你分配到核心中不同的 prompt engineering 去完成，並依據需求，進行進一步的作業，例如: 擬稿發信、記錄、總結及製作會議底稿等等。
-
可參考以下 Semantic Kernel 架構圖:
(圖片來自: 什麼是語義內核？ |微軟學習 (microsoft.com))
Semantic Kernel 是如何工作的:
-
Semantic Kernel(後面簡稱 SK) 有幾個新概念，主要是核心(Kernal)，技能(Skills)，規劃器(Planner)，記憶(Memories) 和 連接器(Connectors)。
-
Kernal 核心: 核心是控制整個 LLM 流程的函式(當需要跨接不同的 API，可由核心來串接需要的 API 及 LLM 模型)，換言之，它是整個語意核心框架的協調中心。在編寫應用時，我們透過創建核心的 Instance，然後基於這個 Kernal Instance 來擴展整個應用的程式碼。
-
Skills 技能: 作為單個功能或與技能相關的一組功能提供給內核的專業知識領域，就核心而言，技能是可訂製化的快捷資源，在 skills 中，我們將 prompt engineering 模組化，使得系統能更容易維護。
-
Planner 規劃器: 規劃器是使用技能依據計畫執行步驟的能力，換言之，就是核心其就輸入內容解析並協調相關技能來響應這些輸入內容並完成的順序步驟。
-
Memories 記憶體: 提供了輸入指令以外的進一步的可訂製化的上下文，往小的方面想，其實就是當我們進行 prompt engineering 時，輸入指令以外，要提供給 LLM 的上下文內容，這當中包含輸出格式制定、角色設定、Few-shot 等等的細節內容。
-
Connectors 連接器: 用來連接外部資源，例如: OneDrive、Bing、SeaClight、Azure Server 等等所有 AI 以外的外部資源連接作業。
-
-
如下面這兩張示意圖，第一張是解析我們從輸入指令給程式到程式完成所有指令的概略示意，而第二張圖則是將第一張圖中的程式部分進一步分解，讓我們了解整個 Kernal 是如何使用 Skills、Memories 及 Connectors 等 Elements 來分工作業~
(以上兩張圖取自 Microsoft Semantic Kernel for AI Dev： A Chat with John Maeda - The New Stack)
- 簡言之，SK 以使用者的問題(ASK)輸入作為目標，透過 Kernel 解析需要調度的 API，然後調用 Planner 來去呼叫 API，再將 Plugins(外掛功能函式)、 Memories、Connectors 的彙整，並組成一個個 Pipeline(multiple steps) chains 來完成 Users’ ASK，最後讓使用者得到指令的回饋(GET Response)。
What is Semantic Kernel 影片(日語有中文字幕):
(可觀看上述影片得到更詳細的介紹)
Semantic Kernel 與 LangChain 的比較
(以上圖片來自 [Semantic Kernelとは？【概要 | プロンプトエンジニア向け】 - YouTube]
如何使用 Semantic Kernel 來進行 Prompt Engineering 呢?
- 首先可到 Semantic Kernel GitHub 站台來取得範例資源
- 如果使用 python 的話，可使用以下指令來安裝 Semantic Kernel Library:
pip install semantic-kernel
- 接著是 import library:
import semantic_kernel as sk
kernel = sk.Kernel()
- 然後是讓 SK 串接你的 OPENAI API 或是 Azure OPENAI API，因此你需要 import python-dotenv library，並將 API KEY 設定到專案同資料夾下的 .env 檔案中，以方便在程式中設定 API_KEY 的存取:
.env 內容範例如下:
OPENAI_API_KEY="sk-..."
OPENAI_ORG_ID="..."
程式中則可如下設定來存取 .env 檔案下的 API_KEY:
from semantic_kernel.connectors.ai.open_ai import OpenAITextCompletion
api_key, org_id = sk.openai_settings_from_dot_env()
kernel.add_text_completion_service("dv", OpenAITextCompletion("text-davinci-003", api_key, org_id))
* 如果是串接 Azure OPENAI API KEY，則為如下:
首先是 .env 檔案內容:
AZURE_OPENAI_API_KEY="..."
AZURE_OPENAI_ENDPOINT="https://..."
AZURE_OPENAI_DEPLOYMENT_NAME="..."
然後是 SK 串接 API ，放式和上面直接串接 OPENAI API 方式大同小異:
from semantic_kernel.connectors.ai.open_ai import AzureTextCompletion
deployment, api_key, endpoint = sk.azure_openai_settings_from_dot_env()
kernel.add_text_completion_service("dv", AzureTextCompletion(deployment, endpoint, api_key))
然後是使用 SK 執行 API Completion 查詢:
skill = kernel.import_semantic_skill_from_directory("../../skills", "FunSkill")
joke_function = skill["Joke"]
print(joke_function("time travel to dinosaur age"))
- 以上範例是來自於剛剛 GitHub 中的 Sample 中 getting-started.ipynb
結語
- 如果只看上面範例，讓你以為只是把 API 再包一層 SK 裹在外面跑，那這樣的 SK 就有些多此一舉了，SK 的真正功能及價值主要是要實現 OOP 中的抽象化，將API 泛型化後先抽離出來，然後再透過核心代理來呼叫，此外這個 library 裡面還有很多 plugin 功能，像是寄信、行事曆操作等等，方便你在執行完 AI Completion 將結果再串接到這些 plugin 來進一步處理，甚至可以一路串接多個 API Completion 及 plugin 一路 pipeline 串接所有管路來完成複雜的工作，而這樣分層的做法，也會讓負責的程式執行動作，能夠更有序，維護起來也會更加的容易，我想這才是真正體現 SK 的價值所在。
- 重點是它是開源的，如果你有能力，每個人都可以客製化自己的 Semantic Kernel Framework，如果你對 CHATGPT 很有興趣，也想寫些應用出來，不妨可開始來試試 Semantic Kernel。
參考資料來源
-
Microsoft Semantic Kernel for AI Dev: A Chat with John Maeda - The New Stack
-
Semantic Kernel (SK) 101. 4步驟教你用C#連接Azure Open AI | by Mars Wang | May, 2023 | Medium
-
Semantic Kernel 102— loading kernel | by Mars Wang | May, 2023 | Medium
