一:LangChain和Semantic Kernel对比
https://blog.csdn.net/xiaoqi270620903/article/details/138334622 Semantic Kernel 适用于需要快速构建 LLM 应用的场景,如智能客服、智能问答等。由于其组件关系简单,开发人员可以快速实现 LLM 模型的应用,并且可以根据需求进行定制化开发。 LangChain 适用于需要构建更加复杂的对话系统的场景,如聊天机器人、智能助手等。其丰富的功能和模块化的设计可以满足开发人员对于对话系统的多种需求,需要一定的学习和开发成本。了解即可,没有必要非得对比谁好,都在发展中,文档都不全面,以自己最熟悉的为主即可!!而且两者可以相互调用,各有优点
二:Azure OpenAI是什么
(一)Azure OpenAI简介
https://learn.microsoft.com/zh-cn/azure/ai-services/openai/overview Azure OpenAI服务提供对OpenAI强大语言模型的REST API访问。OpenAI本身也提供了API给我们使用。Azure OpenAI和OpenAI相当于对相同模型提供了不同API,后面强调的也是(Azure的API更加安全,因为人家家大业大),Azure OpenAI也集成私有部署功能,私有部署的好处显而易见,它稳定可靠速度快,最重要的是再也不用担心被 OpenAI 无厘头的风控政策反复折磨了。(二)Azure OpenAI和OpenAI的关系
- Azure OpenAI与OpenAI共同开发API,确保兼容性并且可以平稳过渡
- 通过Azure OpenAI,客户可以在运行与OpenAI相同的模型的同时获得Microsoft Azure的安全功能。
- Azure OpenAI提供专用网络、区域可用性和负责任的AI内容过滤。
- 国内可直接调用Azure的接口域名,不用套代理。不担心OpenAI风控
- OpenAI产生的费用可直接用Azure每个月额度抵扣
(三)Azure OpenAI的使用和环境部署
https://learn.microsoft.com/zh-cn/azure/ai-services/openai/how-to/switching-endpoints https://blog.csdn.net/YopenLang/article/details/131051962 https://blog.csdn.net/alex_yangchuansheng/article/details/130518019三:SK的简介
Semantic Kernel 也是一种便于使用 LLM 开发应用的框架。 https://learn.microsoft.com/en-us/semantic-kernel/concepts/planning?pivots=programming-language-pythonSK核心特性主要包括:
-
Kernel:依赖管理容器,管理所有运行AI 应用所需的服务(Services)和插件(Plugins)。
-
Agent:提供了构建任何类型的 Agent(ChatBot、Copilot、Autonomous)的能力。
-
AI Service:支持主流 AI 服务 OpenAI、Azure OpenAI 和 Hugging Face 等便捷接入。
-
Plugin:一类工具的集合。可便捷实现复杂功能,包括本地代码插件、OpenAPI接口插件等。
-
Planning:将函数调用作为规划(plan)和执行(execute)任务的主要方式。
-
Persona:通设置 System Prompt 实现设定的,而且实现方式也非常的方便。
(一)Kernel核心组件
Kernel 是 Semantic Kernel 的核心组件。Kernel是一个依赖管理容器,管理那些运行AI应用里所需的所有服务(Services)和插件(Plugins)。只需要将 AI 应用所有依赖的服务和插件提供给Kernel,在需要的时候 AI 应用会自动使用它们。组件 | 说明 |
服务 | 包括所需的 AI 服务(OpenAI)和其他服务(例如日志记录、HTTP 服务等),因此可以支持跨所有语言的服务依赖项引入。 |
插件 | 是一类工具函数的集合,被 AI 服务用来执行,例如,搜索插件可以包含google搜索、bing搜索等工具 |
- 选择最佳的 AI 服务来运行 Prompt
- 使用提供的 Prompt 模板构建 Prompt
- 将 Prompt 发送到 AI 服务
- 接收并解析响应结果
- 最后将来自LLM的响应结果返回给你的应用程序。
在 Semantic Kernel 中定义Kernel十分方便:
from semantic_kernel import Kernel
from semantic_kernel.connectors.ai.open_ai import AzureChatCompletion
from semantic_kernel.core_plugins.time_plugin import TimePlugin
#初始化kernel
kernel = Kernel()
#最后,您可以添加必要的服务和插件。
#下面是一个如何添加OpenAI聊天服务和时间插件的示例。
# Add the Azure OpenAI chat completion service
kernel.add_service(OpenAIChatCompletion(
ai_model_id="my-deployment", #模型name
api_key="my-api-key", #openAI的key
))
# Add a plugin
kernel.add_plugin(
TimePlugin(),
plugin_name="TimePlugin",
)
(二)Agent:支持任何类型 Agent 构建
Agent 是基于软件的实体,利用 AI 模型为你完成工作。它们被构建用来执行广泛的任务,并根据它们的工作性质有不同的称呼:- ChatBot:一个被构建用来回答问题的 Agent 称为“ChatBot”,因为它提供了聊天的体验,这些Agent通常依托于自己的数据,比如公司的文档
- Copilot: 一个被构建来协助你完成工作的 Agent 通常被称为“Copilot”。这些 Agent 通过提供建议帮助你完成任务,如编写电子邮件或创建其他办公文档,你可以选择接受或拒绝这些建议
- Autonomous:一个被构建来处理重复任务的 Agent 通常被称为“Autonomous”。它可以在不需要干预的情况下响应你的请求并执行操作,它是代替你工作,而不是与你一起工作。
在 Semantic Kernel 中,一个 Agent 主要由三个核心构建模块组成:插件(Plugin)、规划器(Planner===Planning)和角色(Persona)。
(三)AI Service:支持主流 AI 服务 OpenAI、Azure OpenAI 和 Hugging Face 等便捷接入
AI 服务是指基于大模型等能力提供的一系列服务,比如ChatGPT等。 Semantic Kernel 的主要功能之一是其能够将不同的AI服务(Services)添加到 Kernel 中,包括 OpenAI、Azure OpenAI 和 Hugging Face 等。这使你可以轻松地替换不同的AI服务,以比较它们的性能,并利用最适合你需求的服务。 在我们选取一个聊天生成模型时,需要考虑下面几个方面:- 模型支持哪些模式(文本、图片、音频...)
- 是否支持function calling(最重要!如果没有,您将无法使用该模型调用现有代码)
- 接收和生成token的速度
- 每个token花费多少
from semantic_kernel import Kernel
from semantic_kernel.connectors.ai.open_ai import OpenAIChatCompletion
# Initialize the kernel
kernel = Kernel()
# Add the Azure OpenAI chat completion service
kernel.add_service(OpenAIChatCompletion(
ai_model_id="my-deployment",
api_key="my-api-key",
org_id="my-org-id", # Optional
service_id="my-service-id", # Optional; for targeting specific services within Semantic Kernel
))
(四)Plugin:灵活的插件架构
插件(Plugin)是 Semantic Kernel 的一个关键组成部分。如果你已经使用过 ChatGPT 或 Microsoft 365 中的 Copilot 扩展的插件,那么你就已经对它有所了解。通过插件,可以将现有的 API 封装成一个集合,供 AI 应用使用。这使 AI 应用能够执行它原本无法执行的操作。 本质上是在利用函数调用(function calling)功能让 LLM 进行规划并调用 API。通过函数调用,LLM 可以请求(即调用)特定的函数。Semantic Kernel 随后将请求发送给你定义的合适的函数,并将结果返回给 LLM,以便 LLM 生成最终结果。在 Semantic Kernel 中定义插件主要有两种方式:
- 使用代码定义 functions ,在代码库中编写函数的具体功能和细节,可以利用您已有的依赖和服务
- 使用 OpenAPI 规范的 API,可以十分方便的跨不同的编程语言和平台共享
(五)Planning:AI 驱动的插件规划
Semantic Kernel 将函数调用作为规划(plan)和执行(execute)任务的主要方式。当 AI 应用拥有多个插件时,就需要一种方法让 AI 应用能够自主的选择合适的一个或多个插件来解决问题,这就需要Planning了。 那 Semantic kerenl 是如何知道什么时候该调用什么工具、什么时候调用结束的呢。这其实是通过一个反馈循环来实现的,LLM 会根据用户问请求和插件功能的描述,决定当下需要调用的插件以及具体的函数和参数,Semantic Kernel 会将函数执行结果反馈给 LLM,由 LLM 决定下一步是继续调用插件还是直接回复。以下就是 Semantic Kernel 基于插件的 AI 驱动的规划过程:
- 为每个函数创建一个 JSON 格式的函数描述
- 为 LLM 提供聊天历史记录和上述函数描述
- 分析 LLM 的响应结果,确定它是回复消息还是调用函数
- 如果 LLM 想要调用函数,则需要分析 LLM 响应结果中的函数名称和参数
- 使用正确的参数调用函数
- 返回函数的结果给 LLM,以便决定它接下来应执行的操作
- 重复步骤2-6,直到 LLM 已完成任务
(六)Persona:必不可少角色(prompt)
角色(Persona)通常称为“元提示(Meta Prompt)”或“指令(Instruction)”,用于定义 AI 应用的响应方式或风格。 通过角色的设定,你可以定义 Agent 规划任务、生成回复以及与用户交互的方式和风格。例如,如果agent不知道该做什么,您可以使用persona明确地告诉agent去寻求帮助,或者在解释某事时更加细节。 在Semantic Kernel中,经常将这些 Prompt 描述为“角色”,主要是通设置 System Prompt 实现设定的,我们可以创建角色来表示不同类型的agent和他们负责的任务。 而且实现方式也非常的方便,通过system messages去设置角色:chat_history = ChatHistory()
chat_history.add_system_message("""
You are a technical support specialist for a software company.
Your primary task is to assist users with technical issues,
such as installation problems, software bugs, and feature
inquiries. Use technical jargon appropriately, but ensure that
explanations are easy to understand. If a problem is too complex,
suggest advanced troubleshooting steps or escalate to a higher-level
support team using the escalate tool.
""")
也可以为角色追加信息:
chat_history.add_system_message("Remember to ask for help if you're unsure how to proceed.")