LangChain vs Semantic Kernel

Posted 2023-04-21 自由、创新、研究、探索

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了LangChain vs Semantic Kernel相关的知识，希望对你有一定的参考价值。

每当向他人介绍 Semantic Kernel，会得到的第一个问题就是 Semantic Kernel 类似于LangChain吗，或者是c# 版本的LangChain吗？为了全面而不想重复的回答这个问题，因此我写下这篇文章。

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

机器学习工程师/数据科学家创建模型，然后通过 REST API 终结点发布此模型。
应用程序开发人员通过传递确定性参数来调用 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目前是“最成熟”（但相当新的）拥有大型开源社区的。第一次提交是在 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应用。

[工作积累] D3D10+ 中 Pixel Shader 的input semantic和参数顺序

由于semantic的使用，我们有理由相信 vertex shader的output 和 pixel shader的input是按照semantic来匹配的，而跟传入顺序无关。印象dx9时代是这样。

虽然习惯上使用共用的sruct (VS_OUTPUT)来保证senamtic修改的同步，便于维护，但这个不是必须的。

但是最近工作中，在UE4的dx11上写自定义shader，因为VS和PS分开两文件，所以干脆没有用struct，而是直接写到parameter 里，但是遇到一个诡异的问题：参数的值不匹配！

最后发现是虽然参数semantic匹配，但是参数顺序不匹配导致的。

所以查了一下文档：Shader Signatures

https://msdn.microsoft.com/en-us/library/windows/desktop/bb509650(v=vs.85).aspx

In Direct3D 10, adjacent stages effectively share a register array, where the output shader (or pipeline stage) writes data to specific locations in the register array and the input shader must read from the same locations. The API uses shader signatures to bind shader outputs with inputs without the overhead of semantic resolution

也就是说d3d10以上，为了提升性能，相邻的stage不做semantic resolution，直接按参数顺序绑定。

所以建议使用公共声明的struct。。

如果想用分开的struct （或者直接用parameter list），注意下面的是兼容的（元素个数不同但参数顺序一致）

// Vertex Shader Output Signature
Struct VSOut
{
  float4 Pos: SV_Position;
  float3 MyNormal: Normal;
  float2 MyTex : Texcoord0;
}

// Pixel Shader Input Signature
Struct PSInWorks
{
  float4 Pos: SV_Position;
  float3 MyNormal: Normal;
}

下面的不兼容（顺序不一致）

// Vertex Shader Output Signature
Struct VSOut
{
  float4 Pos: SV_Position;
  float3 MyNormal: Normal;
  float2 MyTex : Texcoord0;
}

// Pixel Shader Input Signature
Struct PSInFails
{
  float3 MyNormal: Normal;
  float4 Pos: SV_Position;
}

以上两个例子在上面的链接中有。

MSDN在这里也有简单的说明：

Direct3D 9 to Direct3D 10 Considerations (Porting Shaders: Shader Signatures and Linkage)

以上是关于LangChain vs Semantic Kernel的主要内容，如果未能解决你的问题，请参考以下文章

吴恩达教授AI课程：LangChain扩散模型，用ChatGPT API搭建系统

大语言模型集成工具 LangChain

[工作积累] D3D10+ 中 Pixel Shader 的input semantic和参数顺序

ChatExcel?

windows semantic怎么用

Semantic Kernel 工具箱： Semantic Kernel Tools