Semantic Kernel 完成服务类型选择策略演进从 prompt_type 属性到智能服务解析【免费下载链接】semantic-kernelIntegrate cutting-edge LLM technology quickly and easily into your apps项目地址: https://gitcode.com/GitHub_Trending/se/semantic-kernel导读本文以 Semantic KernelSK官方架构决策记录 ADR-0015 Completion service type selection strategy 为主线梳理 SK 在一个 Prompt 究竟该交给文本补全、对话补全还是图像生成服务这个问题上的设计决策与演进脉络。你将理解两种候选方案的取舍逻辑显式prompt_type属性 vs 基于 Prompt 内容的自动识别、为何初版选择了后者以及该决策后来如何被 ADR-0038 取代最终演变为今天基于IAIServiceSelector的对话优先、文本兜底服务解析机制——同时结合仓库源码给出可直接验证的实现细节。一、背景为什么需要完成服务类型选择在 Semantic Kernel 早期2023 年 10 月见 ADR-0015 的元数据SK 运行所有文本 Prompt 时一律使用文本补全服务text completion service。随着对话补全 Promptchat completion prompt的出现以及图像image等更多 Prompt 类型的规划一个核心问题浮出水面当 SK 拿到一个 Semantic Function 时它应该如何决定用哪一类 AI 服务来执行这个 Prompt这个问题的本质是选择服务类型type而不是选择服务实例instance——即先决定是走ITextCompletion、IChatCompletion还是IImageGeneration再由既有机制从注册表中解析出具体的服务实例。决策驱动因素Decision DriversSemantic Function 必须能够标识自己处理文本、对话还是图像 Prompt 时所需的完成服务类型。二、候选方案一由prompt_type属性显式标识第一个方案是在提示模板配置模型类PromptTemplateConfig上新增一个prompt_type属性。该属性由 Prompt 开发者一次性声明SemanticFunction类据此决定解析哪一类完成服务。Prompt 模板配置JSON 形态{ schema: 1, description: Hello AI, what can you do for me?, prompt_type: text|chat|image, models: [...] }Semantic Function 伪代码C# 形态if(string.IsNullOrEmpty(promptTemplateConfig.PromptType) || promptTemplateConfig.PromptType text) { var service this._serviceSelector.SelectAIServiceITextCompletion(context.ServiceProvider, this._modelSettings); //render the prompt, call the service, process and return result } else (promptTemplateConfig.PromptType chat) { var service this._serviceSelector.SelectAIServiceIChatCompletion(context.ServiceProvider, this._modelSettings); //render the prompt, call the service, process and return result }, else (promptTemplateConfig.PromptType image) { var service this._serviceSelector.SelectAIServiceIImageGeneration(context.ServiceProvider, this._modelSettings); //render the prompt, call the service, process and return result }典型应用示例同一个ComicStrip连环画插件中文本型函数与图像型函数并存name: ComicStrip.Create prompt: Generate ideas for a comic strip based on {{$input}}. Design characters, develop the plot, ... config: { schema: 1, prompt_type: text, ... } name: ComicStrip.Draw prompt: Draw the comic strip - {{$comicStrip.Create $input}} config: { schema: 1, prompt_type: image, ... }优点Pros确定性地指明要使用的完成服务类型图像 Prompt 绝不会被文本补全服务渲染反之亦然——类型与能力严格绑定不存在歧义。缺点Cons给 Prompt 开发者增加了一个必须维护的额外属性且该属性与 Prompt 内容存在潜在的重复描述问题。三、候选方案二由 Prompt 内容自动识别服务类型第二个方案不引入新属性而是对渲染后的 Prompt 文本做正则分析通过是否存在特定标记来判断 Prompt 类型。例如渲染结果中出现message role*/message标签即可判定为对话 Prompt交给对话补全服务处理。if (Regex.IsMatch(renderedPrompt, message.*?/message)) { var service this._serviceSelector.SelectAIServiceIChatCompletion(context.ServiceProvider, this._modelSettings); //render the prompt, call the service, process and return result }, else { var service this._serviceSelector.SelectAIServiceITextCompletion(context.ServiceProvider, this._modelSettings); //render the prompt, call the service, process and return result }典型应用示例同样的连环画插件在方案二下无需任何新增配置name: ComicStrip.Create prompt: Generate ideas for a comic strip based on {{$input}}. Design characters, develop the plot, ... config: { schema: 1, ... } name: ComicStrip.Draw prompt: Draw the comic strip - {{$comicStrip.Create $input}} config: { schema: 1, ... }优点Pros无需为识别 Prompt 类型新增任何属性配置保持精简。缺点Cons可靠性存疑。只有当 Prompt 含有唯一标识其类型的标记时才可靠当服务类型只有 text 与 chat 两种时有 message 标签就走 chat否则走 text的二分支逻辑尚可成立一旦加入图像等新类型且这些 Prompt 没有专属的唯一标记就无法与文本 Prompt 区分——文本与图像的边界会变得模糊。四、决策结果选择内容识别并预留修订空间ADR-0015 的**最终决策Decision Outcome**明确选择方案二由 Prompt 内容识别完成服务类型并约定当遇到该方案无法支持的新完成服务类型或形成了改用其他选择机制的明确需求时将重新审视此决策。这是 SK 在当时阶段的一次务实取舍为了不给 Prompt 开发者增加配置负担优先采用零配置的内容识别方案同时把重新评估作为显式承诺写入决策记录。五、演进从内容识别到对话优先、文本兜底ADR-0038该决策后来确实被触发重新评估。2024 年 3 月的 ADR-0038 Completion Service Selection Strategy 正式宣告其superseded被取代状态并记录了两次关键行业变化Chat 补全服务在行业内占据主导例如 OpenAI 已弃用大部分文本生成text generation服务Chat 补全通常提供更好的响应质量且支持工具调用tool calling等高级能力。ADR-0038 描述的现行行为是IAIServiceSelector的当前实现会返回一个对话补全服务、一个文本生成服务或一个同时实现两者的服务Prompt默认先用对话补全运行文本生成作为备选回退方案。从源码看现行选择机制当前实现可以在仓库中直接验证选择器接口IAIServiceSelector.cs定义TrySelectAIServiceT方法根据KernelFunction与KernelArguments从Kernel中解析出IAIService实例及其关联的PromptExecutionSettings。默认实现OrderedAIServiceSelector.cs这是Kernel.ServiceSelector的默认选择器见 Kernel.cs未显式注册IAIServiceSelector时使用OrderedAIServiceSelector.Instance。其选择顺序为优先使用KernelArguments.ExecutionSettings调用级设置优先于函数级设置先按 service id 查找执行设置字典的 key 即 service id通过 keyed service 解析再按 model id 查找遍历执行设置中非空的ModelId与注册服务的模型 ID 比对最后回退到默认服务DefaultServiceId返回任意已注册的同类型服务。对话优先、文本兜底的执行点KernelFunctionFromPrompt.csPrompt 函数在解析 AI 服务时先尝试TrySelectAIServiceIChatCompletionService失败后再尝试TrySelectAIServiceITextGenerationService两者都失败则抛出NotSupportedException并明确提示受支持的三种类型IChatCompletionService、ITextGenerationService与IChatClient。这也印证了 ADR-0038 中chat 优先、text 兜底的描述。执行阶段的分发逻辑KernelFunctionFromPrompt.cs解析出的服务在调用时按类型分发——IChatCompletionService走对话补全路径ITextGenerationService走文本生成路径其余类型抛出NotSupportedException。从显式类型到注册表解析的转变值得注意的是ADR-0015 中设想的prompt_type属性候选方案一最终并未进入PromptTemplateConfig的公开 API。对照当前 PromptTemplateConfig.cs 的[JsonPropertyName]序列化清单name、description、template_format、template、input_variables、output_variable、execution_settings、allow_dangerously_set_content其中并不存在prompt_type字段。从源码结构看服务类型的选择职责被完全移交给了IAIServiceSelector机制函数不再自我声明类型而是通过execution_settings按 service id / model id 表达偏好由选择器与 Prompt 函数调用链共同决定最终解析到的服务。六、对开发者的实践启示梳理这条决策链路对使用 Semantic Kernel 的开发者有三点直接可用的经验不要让 Prompt 承担类型声明职责现代 SK 中无需也不应手写prompt_type之类的字段服务选择由注册表与执行设置驱动配置更精简、也更贴近 DI 的既有心智模型。善用execution_settings的优先级当同一个函数可被多个模型服务执行时利用 PromptTemplateConfig.ExecutionSettings 按 service id 组织多套执行设置字典 key 即 service id默认键为DefaultServiceId调用时也可通过KernelArguments.ExecutionSettings覆盖函数级设置。选择器将依次按 service id → model id → 默认服务解析。理解对话优先的兜底语义如果你同时注册了对话补全与文本生成服务Prompt 函数默认走IChatCompletionService只有对话服务不可用时才回退到ITextGenerationService见 KernelFunctionFromPrompt.cs。需要精确控制时请通过execution_settings显式绑定 service id 或 model id。延伸阅读本决策的完整背景与前后文可进一步参阅 ADR-0015 原文 与其取代记录 ADR-0038以及仓库中同主题的相关决策 0016-custom-prompt-template-formats.md、0020-prompt-syntax-mapping-to-completion-service-model.md。对话补全的实际用法可参考 Step5_Chat_Prompt.cs 与 01-basic-loading-the-kernel.ipynb。【免费下载链接】semantic-kernelIntegrate cutting-edge LLM technology quickly and easily into your apps项目地址: https://gitcode.com/GitHub_Trending/se/semantic-kernel创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
