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应用。

自由、创新、研究、探索