每當向他人介紹 Semantic Kernel， 會得到的第一個問題就是 Semantic Kernel 類似於LangChain嗎，或者是c# 版本的LangChain嗎？ 為了全面而不想重複的回答這個問題，因此我寫下這篇文章。
在 ChatGPT 之前，構建 整合AI的應用程式的主要分為兩個步驟：
- 機器學習工程師/資料科學家建立模型，然後透過 REST API 終結點發布此模型。
- 應用程式開發人員透過傳遞確定性引數來呼叫 REST API 終結點。
有了GPT以後 構建與 AI 整合的應用程式過去要簡單得多，應用程式設計師開發人員直接訪問OpenAI的REST API，將它整合到我們的應用中，但是真正開始整合的時候才發現挑戰不僅僅是呼叫API，例如：
- 如何將OpenAI與內部知識搜尋（內部文件，資料庫，SharePoint等）整合
- 如何將OpenAI與其他系統整合，如SAP，ERP，CRM，HR系統，IT票務系統等。
- 如何有效地跟蹤聊天對話歷史記錄
- 如何以可配置的方式將提示實現到程式碼中（而不是使它們看起來像魔術字串）)
- 如何最小化使用的Token
- 如何在服務限制內和圍繞服務配額和限制工作 - 更具體地說，圍繞最大請求數/分鐘
- 以及更多...
這中間需要有一個業務流程協調程式。該服務編排來自各種依賴項（OpenAI、Azure 搜尋、資料庫等）的輸入和輸出，並將其拼接在一起。
- 這種模式可以從微軟最近釋出的Copilot服務中看出。請注意，GitHub Copilot、M365 Copilot、D365 Copilot 和Security Copilot的架構之間都有一個“Copilot Service”，用於將應用程式與LLM模型和其他服務連結起來。
- 另請注意，微軟在架構圖中提到了的是“LLM”，而不是“GPT-4”。這是因為業務流程協調程式服務同時使用不同的 LLM 來實現其目的。
這就是像Semantic Kernel和LangChain這樣的庫的用武之地。這些庫可幫助開發人員：
- 管理對話歷史記錄，這是ChatCompletionAPI 希望開發人員弄清楚的。
- 根據意圖規劃方法。
- 為該方法實現“連結”
- 管理Memory和服務連線要求（即對話歷史記錄、外部 API 等）
LangChain目前是“最成熟”（但相當新的）擁有大型開源社群的。第一次提交是在 2022 年10月。
- 它支援Python和TypeScript，其中Python具有更多功能。
- 大多數線上文章都使用Jupyter筆記本 演示 LangChain，LangChai也不把自己被稱為“SDK”，它是為習慣於使用筆記本的ML工程師構建的。
- 應用程式開發人員需要弄清楚如何組織程式碼和使用 LangChain，軟體工程方面的組織相對SK 顯得差了很多。
- LangChain由Harrison Chase創立，他的職業是ML工程師，更多是從ML 工程師角度架構應用。
- LangChain開源社群的貢獻非常活躍，目前已經有29k star。
Semantic Kernel（SK）是相對“較新的”，但它是為開發人員構建的。第一次提交是在 2023 年 2 月。
- 它主要面向 C# 開發人員，它也支援 Python，（功能另請參閱功能奇偶校驗文件）。
- 因為它是為開發人員構建的，所以它被稱為輕量級 SDK，可幫助開發人員將程式碼組織到內建於 Planner 中的技能、記憶和聯結器中（在此處閱讀更多內容）。
- 示例程式碼中有很多業務流程協調程式 Web 服務的示例。
- SK由一個以軟體開發工程能力超強的組織（微軟）創立。開源社群規模也相當活躍，目前已經有5.7k star。
- 它是由微軟創立的，文件方面做的也非常好，它有一個官方的支援頁面和LinkedIn學習課程。
- 由於 SK 在構建時考慮了應用，因此有一個 MS Graph聯結器工具包，適用於需要與日曆、電子郵件、OneDrive 等整合的方案。
這兩個庫我們選擇使用哪一個，我覺得主要的考慮因素是開發人員的技能，LLM 已經將機器學習的門檻降低到普通開發人員就可以開發AI應用，SK 在幫助應用開發人員開發AI方面的幫助會比LangChain更大，我會選擇採用SK來構建AI應用。