Semantic Kernel .NET 集成 Azure Model-as-a-ServiceAzure AI Inference 连接器设计全解【免费下载链接】semantic-kernelIntegrate cutting-edge LLM technology quickly and easily into your apps项目地址: https://gitcode.com/GitHub_Trending/se/semantic-kernel本文以语义内核仓库中的架构决策记录 0051-dotnet-azure-model-as-a-service.md 为核心系统梳理 Semantic Kernel .NET 如何通过Microsoft.SemanticKernel.Connectors.AzureAIInference连接器接入 Azure AI Studio 的 Serverless APIModel-as-a-Service按 Token 计费的无服务器模型部署方式并结合仓库源码讲解连接器的命名空间决策、能力边界、AzureAIInferencePromptExecutionSettings执行参数与三种注册方式。读完本文你将掌握在 Semantic Kernel 中调用 Azure AI Studio 上各类开源模型的完整方案理解该连接器与 OpenAI / Azure OpenAI 连接器的本质区别并能够直接用代码完成 Chat Completion 与流式输出的接入。一、背景为什么需要一个新的 Azure AI 连接器1.1 Model-as-a-Service 与 Serverless APIAzure AI Studio 提供一种名为Model-as-a-ServiceMaaS的模型消费模式官方也称其为Serverless API无服务器 API按量付费。在这种模式下用户无需管理底层计算资源托管计算/MaaS 计费方式为 Pay-as-you-go计费以 Token 用量为基础客户端通过Azure AI Model Inference API或官方客户端 SDK 访问服务。这条决策链路的源头是更早的 0046-azure-model-as-a-service.mdstatus 为 accepted2024-06-20而 0051 号 ADRstatus 为 proposed2024-08-07决策人 rogerbarreto、markwallace-microsoft则聚焦于.NET 侧的正式落地为 Semantic Kernel 开发一个新的 AI 连接器原生支持 Azure AI Studio 上部署的模型。1.2 为什么不直接复用 OpenAI / Azure OpenAI 客户端库Azure AI Studio 的模型目录Model Catalog涵盖大量非 OpenAI 系的开源模型如 Llama、Phi、Mistral 等。虽然服务 API 是 OpenAI 兼容的但 ADR 明确指出不允许使用 OpenAI 与 Azure OpenAI 客户端库来交互该服务因为它们在模型与模型提供商层面都不是独立的not independent with respect to both the models and their providers。Azure 官方为此推出了全新的 .NET 客户端库Azure.AI.InferenceSDK 路径sdk/ai/Azure.AI.InferenceSemantic Kernel 连接器正是建立在该客户端库之上。仓库中的工程文件 Connectors.AzureAIInference.csproj 印证了这一点——它直接引用了Microsoft.Extensions.AI与Microsoft.Extensions.AI.AzureAIInference两个包程序集名为Microsoft.SemanticKernel.Connectors.AzureAIInference包描述为 Semantic Kernel Model as a Service connectors for Azure AI Studio. Contains clients for chat completion, embeddings and text to image generation.。二、能力边界客户端 SDK 的明确限制ADR 记录了 Azure.AI.Inference 客户端 SDK 首个版本的能力范围这是选择该连接器前必须了解的硬约束能力支持状态Chat Completion聊天补全首个版本支持Text Embedding Generation文本向量生成首个版本支持Image Embedding Generation图像向量生成首个版本支持TextToImage Generation文生图规划中plannedText Generation文本补全明确不支持且无计划0046 号 ADR 对此补充得更直接早期对文本补全text completion的支持计划不明确很可能永远不会支持因此新连接器初始版本不会提供文本补全能力直到出现更多客户需求信号或客户端 SDK 增加支持。这也解释了仓库中Connectors.AzureAIInference目录dotnet/src/Connectors/Connectors.AzureAIInference目前的形态实现集中在ChatCompletion服务上目录内包含Services/、Settings/、Core/、Extensions/四块尚未出现独立的 TextGeneration 服务。三、命名空间决策从候选到定案3.1 候选方案对比0051 号 ADR 给出了三个命名空间候选Microsoft.SemanticKernel.Connectors.AzureAIMicrosoft.SemanticKernel.Connectors.AzureAIInferenceMicrosoft.SemanticKernel.Connectors.AzureAIModelInference3.2 决策结果最终决策为Microsoft.SemanticKernel.Connectors.AzureAIInference。0046 号 ADR 记录了更早期的候选列表Azure、AzureAI、AzureAIInference、AzureAIModelInference并同样收敛到AzureAIInference。选择AzureAIInference而非更宽泛的AzureAI从源码结构看是为了精确对齐 Azure 官方客户端库Azure.AI.Inference的名称避免与未来的其他 Azure 连接器如 Azure OpenAI产生歧义。四、模型特定参数AzureAIInferencePromptExecutionSettings4.1 设计动机不同模型可能携带不属于默认 API 规范的补充参数。服务 API 与客户端 SDK 都支持透传这些模型特定参数用户可以在提交temperature、top_p等通用设置的同时通过一个专用参数传入模型自定义设置。在 Semantic Kernel 的语境下执行参数统一归类到PromptExecutionSettings及其连接器专属子类中。0051 号 ADR 的决策是Azure AI Inference 专属的PromptExecutionSettings将支持这些可自定义参数。0046 号 ADR 则补充了实现细节——连接器设置类将包含一个dictionary类型的成员用于聚合模型特定参数。4.2 源码级实现完整的参数面仓库中的 AzureAIInferencePromptExecutionSettings.cs 是该决策的落地实现。它继承自PromptExecutionSettings类上标注了[JsonNumberHandling(JsonNumberHandling.AllowReadingFromString)]允许从字符串读取数字增强与不同客户端配置的兼容性并覆盖了Freeze()将可变列表冻结为只读集合与Clone()深拷贝所有字段两个虚方法。构造器会将ExtensionData初始化为空的Dictionarystring, object——这正是 ADR 中所说的“模型特定参数字典”。可用属性完整清单如下属性JSON 字段名类型说明与约束ExtraParametersextra_parametersstring?允许值error、drop、pass-through控制额外参数的传递策略Temperaturetemperaturefloat?采样温度控制输出的随机性/创造性支持范围 [0, 1]不建议与 top_p 同时修改NucleusSamplingFactortop_pfloat?核采样仅考虑概率质量占比内的 token范围 [0, 1]不建议与 temperature 同时修改FrequencyPenaltyfrequency_penaltyfloat?依据 token 在生成文本中的累计频率抑制重复正值降低模型逐字复述的概率范围 [-2, 2]PresencePenaltypresence_penaltyfloat?依据 token 是否已出现抑制重复促使模型谈论新话题范围 [-2, 2]MaxTokensmax_tokensint?生成的最大 token 数ResponseFormatresponse_formatobject?输出格式可启用 JSON 模式ChatCompletionsResponseFormatJsonObject或文本模式ChatCompletionsResponseFormatText启用 JSON 模式时部分模型还要求系统/用户消息显式指示输出 JSONStopSequencesstopIListstring?终止生成的文本序列集合ToolstoolsIListChatCompletionsToolDefinition?请求可用的工具定义含调用者自定义函数Seedseedlong?尽力实现确定性采样相同 seed 与参数尽量返回相同结果但不保证绝对确定ExtensionData—Dictionarystring, object模型特定参数透传字典ADR 决策点所有可空属性都配置了[JsonIgnore(Condition JsonIgnoreCondition.WhenWritingNull)]即未显式赋值时不会写入请求体同时全部 setter 都调用ThrowIfFrozen()防止冻结后修改。4.3 与其他设置对象的互转该类提供了静态工厂方法FromExecutionSettings支持三种输入传入null返回默认实例各参数均为 nullExtensionData为空字典传入AzureAIInferencePromptExecutionSettings原样返回传入其他PromptExecutionSettings先序列化再反序列化为AzureAIInferencePromptExecutionSettings使用JsonOptionsCache.ReadPermissive转换失败抛出ArgumentException。单元测试 AzureAIInferencePromptExecutionSettingsTests.cs 验证了这些行为默认值全为 null已有实例直接复用从ExtensionData中的 snake_case 键temperature、top_p、frequency_penalty、presence_penalty、stop、max_tokens、seed可正确映射到强类型属性甚至支持字符串形式的数字如0.7、128。五、连接器落地从 ADR 决策到可运行代码5.1 三种构造认证方式底层核心类 ChatClientCore.cs 封装了对Azure.AI.Inference.ChatCompletionsClient的创建提供三种构造路径API Key 方式modelId apiKey endpoint。当未提供 apiKey 时会默认填入单个空格作为占位密钥——源码注释解释这是为了适配“由网关注入 API Key”的场景如 GitHub Models 等网关服务避免 Azure SDK 的AzureKeyCredential因空字符串抛异常TokenCredential 方式支持DefaultAzureCredential、ManagedIdentityCredential、EnvironmentCredential等托管标识/环境凭据适合服务端无密钥场景自建 ChatCompletionsClient 方式允许调用方传入自定义的ChatCompletionsClientbreaking glass 逃生通道此时客户端诊断配置由调用方自行负责。核心类还会在请求上注入 Semantic Kernel 版本头AddHeaderRequestPolicy并将 Endpoint 与 ModelId 写入服务Attributes对应AIServiceExtensions.EndpointKey/ModelIdKey。若传入自定义HttpClient会自动禁用 SDK 内部重试策略与默认超时源码见GetClientOptions的RetryPolicy(maxRetries: 0)与Timeout.InfiniteTimeSpan将重试/超时策略完全交由调用方管理。5.2 Kernel Builder 与 DI 扩展AzureAIInferenceKernelBuilderExtensions.cs 与 AzureAIInferenceServiceCollectionExtensions.cs 提供两组 APIAddAzureAIInferenceChatCompletion(...)注册IChatCompletionServicekeyed singleton可指定serviceIdAddAzureAIInferenceChatClient(...)注册IChatClient。DI 注册内部还会自动串联UseOpenTelemetry支持openTelemetrySourceName与openTelemetryConfig回调与UseKernelFunctionInvocation函数调用自动执行并在存在ILoggerFactory时启用日志。需要特别留意的一点是AzureAIInferenceChatCompletionService类本身在 AzureAIInferenceChatCompletionService.cs 中已被标记为[Obsolete(...)]其建议写法是Azure.AI.Inference.ChatCompletionsClient.AsChatClient().AsChatCompletionService()即直接基于Microsoft.Extensions.AI的IChatClient抽象接入该服务内部实现正是通过AsIChatClient(modelId).AsBuilder().UseFunctionInvocation(...)构建的。因此新代码推荐优先使用AddAzureAIInferenceChatCompletion/AddAzureAIInferenceChatClient扩展方法或ChatCompletionsClient.AsChatClient()链式调用。5.3 开箱即用的示例代码仓库示例 AzureAIInference_ChatCompletion.cs 演示了两种接入方式示例同时适用于 Azure AI Foundry 与 GitHub Models方式一通过ChatCompletionsClient直接构建聊天服务var chatService new ChatCompletionsClient( endpoint: new Uri(TestConfiguration.AzureAIInference.Endpoint), credential: new Azure.AzureKeyCredential(TestConfiguration.AzureAIInference.ApiKey)) .AsIChatClient(TestConfiguration.AzureAIInference.ChatModelId) .AsChatCompletionService(); var chatHistory new ChatHistory(You are a librarian, expert about books); chatHistory.AddUserMessage(Hi, Im looking for book suggestions); var reply await chatService.GetChatMessageContentAsync(chatHistory);方式二通过 Kernel Builder 集成语义内核首选var kernel Kernel.CreateBuilder() .AddAzureAIInferenceChatCompletion( modelId: TestConfiguration.AzureAIInference.ChatModelId, endpoint: new Uri(TestConfiguration.AzureAIInference.Endpoint), apiKey: TestConfiguration.AzureAIInference.ApiKey) .Build(); var reply await kernel.InvokePromptAsync(chatPrompt.ToString());配置项由TestConfiguration.AzureAIInferenceEndpoint、ApiKey、ChatModelId提供对应仓库样例的测试配置体系。仓库中还有流式对话示例 AzureAIInference_ChatCompletionStreaming.cs 与函数调用示例 AzureAIInference_FunctionCalling.cs以及 AOT 与遥测场景下的使用案例如 dotnet/samples/Demos/AIModelRouter/Program.cs。5.4 目标框架与包发布形态从 Connectors.AzureAIInference.csproj 可以看出该连接器的工程配置目标框架net10.0、net8.0、netstandard2.0覆盖面从现代 .NET 到旧版兼容程序集/根命名空间Microsoft.SemanticKernel.Connectors.AzureAIInference版本后缀beta且NoWarn中放行SKEXP0001实验性 API 警告与NU5104说明该包当前以 beta 形态演进通过InternalsVisibleTo向SemanticKernel.Connectors.AzureAIInference.UnitTests开放内部实现用于测试。单元测试目录 Connectors.AzureAIInference.UnitTests 覆盖了ChatClientCore、KernelBuilder/ServiceCollection 扩展、PromptExecutionSettings 以及 OpenTelemetry 行为测试数据包含chat_completion_response.json与流式响应样本可作为验证连接器行为的参考。六、开发计划与演进路径0051 号 ADR 记录了该连接器的开发组织方式开发工作将在名为feature-connectors-azureaiinference的功能分支中进行独立于主干完成连接器的实现与验证后再合并。结合上文源码可知该特性已随仓库演进落地为dotnet/src/Connectors/Connectors.AzureAIInference目录中的正式连接器并同步配套了单元测试与概念示例。七、实践要点小结围绕这篇 ADR 及其实现在仓库中的对应代码接入 Azure AI Studio MaaS 时需要注意能力边界目前只支持 Chat Completion 与 Text/Image EmbeddingTextToImage 在规划中Text Generation 不支持需要文本补全的场景应选用其他连接器认证选择网关型端点无密钥注入可省略 apiKeySDK 自动以单空格占位服务端环境优先考虑TokenCredential需要精细控制重试/超时时传入自定义HttpClient此时 SDK 内部重试会被关闭模型特定参数通过AzureAIInferencePromptExecutionSettings.ExtensionData字典透传或用 snake_case 键写入通用PromptExecutionSettings.ExtensionDataFromExecutionSettings会自动完成映射接入方式新代码优先使用AddAzureAIInferenceChatCompletion/AddAzureAIInferenceChatClient扩展方法或ChatCompletionsClient.AsChatClient().AsChatCompletionService()链式调用直接实例化已标记 Obsolete 的AzureAIInferenceChatCompletionService仅用于兼容旧代码参数语义temperature与top_p不建议同时修改frequency_penalty/presence_penalty范围为 [-2, 2]seed仅保证尽力确定性。如需深入源码建议按以下顺序阅读先看 AzureAIInferencePromptExecutionSettings.cs 掌握参数面再看 ChatClientCore.cs 理解客户端构建细节最后对照 AzureAIInference_ChatCompletion.cs 跑通第一个示例。【免费下载链接】semantic-kernelIntegrate cutting-edge LLM technology quickly and easily into your apps项目地址: https://gitcode.com/GitHub_Trending/se/semantic-kernel创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考