LangChain vs Semantic Kernel

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

在 ChatGPT 之前，構建集成AI的應用程序的主要分爲兩個步驟：

有了GPT以後構建與 AI 集成的應用程序過去要簡單得多，應用程序員開發人員直接訪問OpenAI的REST API，將它集成到我們的應用中，但是真正開始集成的時候才發現挑戰不僅僅是調用API，例如：

這中間需要有一個業務流程協調程序。該服務編排來自各種依賴項（OpenAI、Azure 搜索、數據庫等）的輸入和輸出，並將其拼接在一起。

這種模式可以從微軟最近發佈的Copilot服務中看出。請注意，GitHub Copilot、M365 Copilot、D365 Copilot 和Security Copilot的架構之間都有一個“Copilot Service”，用於將應用程序與LLM模型和其他服務鏈接起來。
另請注意，微軟在架構圖中提到了的是“LLM”，而不是“GPT-4”。這是因爲業務流程協調程序服務同時使用不同的 LLM 來實現其目的。

這就是像Semantic Kernel和LangChain這樣的庫的用武之地。這些庫可幫助開發人員：

LangChain目前是“最成熟”（但相當新的）擁有大型開源社區的。第一次提交是在 2022 年10月。

它支持Python和TypeScript，其中Python具有更多功能[2]。
大多數在線文章都使用Jupyter筆記本演示 LangChain，LangChai也不把自己被稱爲“SDK”，它是爲習慣於使用筆記本的ML工程師構建的。
應用程序開發人員需要弄清楚如何組織代碼和使用 LangChain，軟件工程方面的組織相對SK 顯得差了很多。
LangChain由Harrison Chase[3]創立，他的職業是ML工程師，更多是從ML 工程師角度架構應用。
LangChain開源社區的貢獻非常活躍，目前已經有29k star。
採用MIT開源協議

Semantic Kernel（SK）是相對“較新的”，但它是爲開發人員構建的。第一次提交是在 2023 年 2 月。

它主要面向 C# 開發人員，它也支持 Python，（功能另請參閱功能奇偶校驗文檔[4]）。
因爲它是爲開發人員構建的，所以它被稱爲輕量級 SDK，可幫助開發人員將代碼組織到內置於 Planner 中的技能、記憶和連接器中（在此處閱讀更多內容）。
示例代碼中有很多業務流程協調程序 Web 服務的示例。
SK由一個以軟件開發工程能力超強的組織（微軟）創立。開源社區規模也相當活躍，目前已經有5.7k star。
它是由微軟創立的，文檔方面做的也非常好，它有一個官方的支持頁面[5]和LinkedIn學習課程[6]。
由於 SK 在構建時考慮了應用，因此有一個 MS Graph連接器工具包[7]，適用於需要與日曆、電子郵件、OneDrive 等集成的方案。
微軟絕對是接入 OpenAI 最快也是最早的大型公司，他們發佈的“Semantic Kernel” 是工程實踐的結晶，同時發佈了LLM創建軟件的九項原則，稱之爲Schillace Laws of Semantic AI[8]https://learn.microsoft.com/zh-cn/semantic-kernel/howto/schillacelaws

這兩個庫我們選擇使用哪一個，我覺得主要的考慮因素是開發人員的技能，LLM 已經將機器學習的門檻降低到普通開發人員就可以開發AI應用，SK 在幫助應用開發人員開發AI方面的幫助會比LangChain更大，我會選擇採用SK來構建AI應用。

相關鏈接