Semantic Kernel VS LangChain

每当向他人介绍 Semantic Kernel，会得到的第一个问题就是 Semantic Kernel 类似于 LangChain 吗？或者是 C# 版本的 LangChain 吗？因此我总结了这篇文章。

微软MVP实验室研究员

张善友

深圳友浩达 CTO & 首席架构师，微软最有价值专家，微软 SWAT 专家，超过20年的软件研发经验，曾在腾讯工作12年，.NET 基金会成员，.NET 云原生顾问和解决方案专家，运营微信公众号“dotnet跨平台”和“分布式应用运行时”

在 ChatGPT 之前，构建、集成 AI 的应用程序主要分为两个步骤：

1. 机器学习工程师/数据科学家创建模型，然后通过 REST API 终结点发布此模型。

2. 应用程序开发人员通过传递确定性参数来调用 REST API 终结点。

有了 GPT 以后，构建与 AI 集成的应用程序要简单得多，应用程序开发人员直接访问 OpenAI 的 REST API，将它集成到我们的应用中，但是真正开始集成的时候才发现挑战不仅仅是调用 API，例如：

• 如何将 OpenAI 与内部知识搜索（内部文档，数据库，SharePoint 等）集成

• 如何将 OpenAI 与其他系统集成，如 SAP，ERP，CRM，HR 系统，IT 票务系统等

• 如何有效地跟踪聊天对话历史记录

• 如何以可配置的方式将提示实现到代码中（而不是使它们看起来像魔术字符串）

• 如何最小化使用 Token

• 如何在服务限制内和围绕服务配额和限制[1]工作 - 更具体地说，围绕最大请求数/分钟

• 以及更多...

这中间需要有一个业务流程协调程序。该服务编排来自各种依赖项（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

LangChain 目前是“最成熟”（但相当新的）拥有大型开源社区的。第一次提交是在2022年10月。

• 它支持 Python 和 TypeScript，其中 Python 具有更多功能[2]。

• 大多数在线文章都使用 Jupyter 笔记本演示 LangChain，LangChain 也不把自己称为“SDK”，它是为习惯于使用笔记本的 ML 工程师构建的。

• 应用程序开发人员需要弄清楚如何组织代码和使用 LangChain，软件工程方面的组织相对 SK 显得差了很多。

• LangChain 由 Harrison Chase[3]创立，他的职业是 ML 工程师，更多是从 ML  工程师角度架构应用。

• LangChain 开源社区的贡献非常活跃，目前已经有29k star。

• 采用 MIT 开源协议。

▍Semantic Kernel

Semantic Kernel（SK）是相对“较新的”，但它是为开发人员构建的。第一次提交是在 2023 年 2 月。

• 它主要面向 C# 开发人员，也支持 Python（功能另请参阅功能奇偶校验文档[4]）。

• 因为它是为开发人员构建的，所以被称为轻量级 SDK，可帮助开发人员将代码组织到内置于 Planner 中的技能、记忆和连接器中。

• 示例代码中有很多业务流程协调程序 Web 服务的示例。

• SK 由微软创立。开源社区规模也相当活跃，目前已经有5.7k star。

• SK 在文档方面做得也非常好，它有一个官方的支持页面[5]和学习课程。

• 由于 SK 在构建时考虑了应用，因此有一个 MS Graph 连接器工具包[6]，适用于需要与日历、电子邮件、OneDrive 等集成的方案。

• 微软绝对是接入 OpenAI 最快也是最早的大型公司，他们发布的“Semantic Kernel” 是工程实践的结晶，同时发布了 LLM 创建软件的九项原则，称之为 Schillace Laws of Semantic AI[7]。

这两个库我们选择使用哪一个，我觉得主要的考虑因素是开发人员的技能，LLM 已经将机器学习的门槛降低到普通开发人员就可以开发 AI 应用，SK 在帮助应用开发人员开发 AI 方面的帮助会比 LangChain[8]更大，我会选择采用 SK 来构建 AI 应用。

相关链接

• [1] 服务配额和限制：

  https://learn.microsoft.com/zh-cn/azure/cognitive-services/openai/quotas-limits

• [2] Langchain 特性：

  https://langchain.com/features.html

• [3] Harrison Chase：

  https://github.com/hwchase17

• [4] SK 功能奇偶校验文档：

  https://github.com/microsoft/semantic-kernel/blob/python-preview-archived-dont-delete/python/FEATURE_PARITY.md

• [5] SK 支持页面：

  http://aka.ms/sk/support

• [6] MS Graph 连接器工具包：

  https://learn.microsoft.com/en-us/semantic-kernel/concepts-sk/connectors#whats-the-ms-graph-connector-kit

• [7] Schillace Laws of Semantic AI：

  https://learn.microsoft.com/zh-cn/semantic-kernel/howto/schillacelaws

• [8] LangChain：Model as a Service 粘合剂，被 ChatGPT 插件干掉了吗？:

  https://mp.weixin.qq.com/s/3coFhAdzr40tozn8f9Dc-w