LangChain vs Semantic Kernel

每當向他人介紹 Semantic Kernel， 會得到的第一個問題就是 Semantic Kernel 類似於LangChain嗎，或者是c# 版本的LangChain嗎？ 為了全面而不想重複的回答這個問題，因此我寫下這篇文章。

在 ChatGPT 之前，構建 整合AI的應用程式的主要分為兩個步驟：

1. 機器學習工程師/資料科學家建立模型，然後通過 REST API 終結點發布此模型。
2. 應用程式開發人員通過傳遞確定性引數來呼叫 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應用。