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