O que é um Plugin?
Os plugins são um componente chave do Kernel Semântico. Se você já usou plug-ins das extensões ChatGPT ou Copilot no Microsoft 365, já está familiarizado com eles. Com plugins, você pode encapsular suas APIs existentes em uma coleção que pode ser usada por uma IA. Isso permite que você dê à sua IA a capacidade de executar ações que ela não seria capaz de fazer de outra forma.
Nos bastidores, o Kernel Semântico aproveita a chamada de função , um recurso nativo da maioria dos LLMs mais recentes, para permitir que os LLMs executem o planeamento e invocar as suas APIs. Com a chamada de função, os LLMs podem solicitar (ou seja, chamar) uma função específica. Em seguida, o Kernel Semântico organiza a solicitação para a função apropriada em sua base de código e retorna os resultados de volta ao LLM para que o LLM possa gerar uma resposta final.
Nem todos os SDKs de IA têm um conceito análogo aos plugins (a maioria apenas tem funções ou ferramentas). Em cenários corporativos, no entanto, os plug-ins são valiosos porque encapsulam um conjunto de funcionalidades que espelha como os desenvolvedores corporativos já desenvolvem serviços e APIs. Os plugins também funcionam bem com a injeção de dependências. Dentro do construtor de um plugin, você pode injetar serviços que são necessários para executar o trabalho do plug-in (por exemplo, conexões de banco de dados, clientes HTTP, etc.). Isso é difícil de realizar com outros SDKs que não possuem plugins.
Anatomia de um plugin
A um nível elevado, um plugin é um grupo de funções que podem ser expostas a aplicações e serviços de IA. As funções dentro dos plugins podem então ser orquestradas por um aplicativo de IA para atender às solicitações do usuário. Dentro do Kernel Semântico, você pode invocar essas funções automaticamente com a chamada de função.
Observação
Em outras plataformas, as funções são muitas vezes referidas como "ferramentas" ou "ações". No Kernel Semântico, usamos o termo "funções", uma vez que elas são normalmente definidas como funções nativas em sua base de código.
Apenas fornecer funções, no entanto, não é suficiente para fazer um plugin. Para alimentar a orquestração automática com chamada de função, os plugins também precisam fornecer detalhes que descrevam semanticamente como eles se comportam. Tudo, desde a entrada, saída e efeitos colaterais da função, precisa ser descrito de uma forma que a IA possa entender, caso contrário, a IA não chamará corretamente a função.
Por exemplo, o exemplo WriterPlugin
plugin à direita tem funções com descrições semânticas que descrevem o que cada função faz. Um LLM pode então usar essas descrições para escolher as melhores funções para chamar para atender à solicitação de um usuário.
Na imagem à direita, um LLM provavelmente chamaria as funções ShortPoem
e StoryGen
para satisfazer as perguntas dos usuários graças às descrições semânticas fornecidas.
Importação de diferentes tipos de plugins
Existem duas maneiras principais de importar plugins para o Semantic Kernel: usando código nativo ou usando uma especificação OpenAPI . O primeiro permite que você crie plugins em sua base de código existente que podem aproveitar dependências e serviços que você já tem. Este último permite importar plugins de uma especificação OpenAPI, que pode ser compartilhada entre diferentes linguagens de programação e plataformas.
Abaixo, fornecemos um exemplo simples de importação e uso de um plug-in nativo. Para saber mais sobre como importar esses diferentes tipos de plugins, consulte os seguintes artigos:
Dica
Ao começar, recomendamos o uso de plug-ins de código nativo. À medida que seu aplicativo amadurece e você trabalha em equipes multiplataforma, você pode considerar o uso de especificações OpenAPI para compartilhar plug-ins em diferentes linguagens de programação e plataformas.
Os diferentes tipos de funções do plugin
Dentro de um plugin, você normalmente terá dois tipos diferentes de funções, aquelas que recuperam dados para geração aumentada de recuperação (RAG) e aquelas que automatizam tarefas. Embora cada tipo seja funcionalmente o mesmo, eles normalmente são usados de forma diferente dentro de aplicativos que usam o Kernel Semântico.
Por exemplo, com funções de recuperação, você pode querer usar estratégias para melhorar o desempenho (por exemplo, armazenamento em cache e uso de modelos intermediários mais baratos para sumarização). Considerando que, com as funções de automação de tarefas, você provavelmente desejará implementar processos de aprovação human-in-the-loop para garantir que as tarefas sejam concluídas corretamente.
Para saber mais sobre os diferentes tipos de funções do plugin, consulte os seguintes artigos:
Introdução aos plugins
Usar plugins dentro do Kernel Semântico é sempre um processo de três etapas:
- Defina o seu plugin
- Adicione o plugin ao seu kernel
- E, de seguida, invoque as funções do plug-in num prompt ou por chamada de função
Abaixo, forneceremos um exemplo de alto nível de como usar um plugin dentro do Kernel Semântico. Consulte os links acima para obter informações mais detalhadas sobre como criar e usar plugins.
1) Defina o seu plugin
A maneira mais fácil de criar um plugin é definindo uma classe e anotando seus métodos com o atributo KernelFunction
. Isso permite que o Kernel Semântico saiba que esta é uma função que pode ser chamada por uma IA ou referenciada em um prompt.
Você também pode importar plug-ins de uma especificação OpenAPI .
Abaixo, vamos criar um plugin que pode recuperar o estado das luzes e alterar o seu estado.
Dica
Como a maioria dos LLM foram treinados com Python para chamada de funções, é recomendado usar snake case para nomes de funções e nomes de propriedades, mesmo se você estiver usando o C# ou Java SDK.
using System.ComponentModel;
using Microsoft.SemanticKernel;
public class LightsPlugin
{
// Mock data for the lights
private readonly List<LightModel> lights = new()
{
new LightModel { Id = 1, Name = "Table Lamp", IsOn = false, Brightness = 100, Hex = "FF0000" },
new LightModel { Id = 2, Name = "Porch light", IsOn = false, Brightness = 50, Hex = "00FF00" },
new LightModel { Id = 3, Name = "Chandelier", IsOn = true, Brightness = 75, Hex = "0000FF" }
};
[KernelFunction("get_lights")]
[Description("Gets a list of lights and their current state")]
[return: Description("An array of lights")]
public async Task<List<LightModel>> GetLightsAsync()
{
return lights
}
[KernelFunction("get_state")]
[Description("Gets the state of a particular light")]
[return: Description("The state of the light")]
public async Task<LightModel?> GetStateAsync([Description("The ID of the light")] int id)
{
// Get the state of the light with the specified ID
return lights.FirstOrDefault(light => light.Id == id);
}
[KernelFunction("change_state")]
[Description("Changes the state of the light")]
[return: Description("The updated state of the light; will return null if the light does not exist")]
public async Task<LightModel?> ChangeStateAsync(int id, LightModel LightModel)
{
var light = lights.FirstOrDefault(light => light.Id == id);
if (light == null)
{
return null;
}
// Update the light with the new state
light.IsOn = LightModel.IsOn;
light.Brightness = LightModel.Brightness;
light.Hex = LightModel.Hex;
return light;
}
}
public class LightModel
{
[JsonPropertyName("id")]
public int Id { get; set; }
[JsonPropertyName("name")]
public string Name { get; set; }
[JsonPropertyName("is_on")]
public bool? IsOn { get; set; }
[JsonPropertyName("brightness")]
public byte? Brightness { get; set; }
[JsonPropertyName("hex")]
public string? Hex { get; set; }
}
from typing import TypedDict, Annotated
class LightModel(TypedDict):
id: int
name: str
is_on: bool | None
brightness: int | None
hex: str | None
class LightsPlugin:
lights: list[LightModel] = [
{"id": 1, "name": "Table Lamp", "is_on": False, "brightness": 100, "hex": "FF0000"},
{"id": 2, "name": "Porch light", "is_on": False, "brightness": 50, "hex": "00FF00"},
{"id": 3, "name": "Chandelier", "is_on": True, "brightness": 75, "hex": "0000FF"},
]
@kernel_function
async def get_lights(self) -> Annotated[list[LightModel], "An array of lights"]:
"""Gets a list of lights and their current state."""
return self.lights
@kernel_function
async def get_state(
self,
id: Annotated[int, "The ID of the light"]
) -> Annotated[LightModel | None], "The state of the light"]:
"""Gets the state of a particular light."""
for light in self.lights:
if light["id"] == id:
return light
return None
@kernel_function
async def change_state(
self,
id: Annotated[int, "The ID of the light"],
new_state: LightModel
) -> Annotated[Optional[LightModel], "The updated state of the light; will return null if the light does not exist"]:
"""Changes the state of the light."""
for light in self.lights:
if light["id"] == id:
light["is_on"] = new_state.get("is_on", light["is_on"])
light["brightness"] = new_state.get("brightness", light["brightness"])
light["hex"] = new_state.get("hex", light["hex"])
return light
return None
public class LightsPlugin {
// Mock data for the lights
private final Map<Integer, LightModel> lights = new HashMap<>();
public LightsPlugin() {
lights.put(1, new LightModel(1, "Table Lamp", false));
lights.put(2, new LightModel(2, "Porch light", false));
lights.put(3, new LightModel(3, "Chandelier", true));
}
@DefineKernelFunction(name = "get_lights", description = "Gets a list of lights and their current state")
public List<LightModel> getLights() {
System.out.println("Getting lights");
return new ArrayList<>(lights.values());
}
@DefineKernelFunction(name = "change_state", description = "Changes the state of the light")
public LightModel changeState(
@KernelFunctionParameter(name = "id", description = "The ID of the light to change") int id,
@KernelFunctionParameter(name = "isOn", description = "The new state of the light") boolean isOn) {
System.out.println("Changing light " + id + " " + isOn);
if (!lights.containsKey(id)) {
throw new IllegalArgumentException("Light not found");
}
lights.get(id).setIsOn(isOn);
return lights.get(id);
}
}
Observe que fornecemos descrições para a função, valor de retorno e parâmetros. Isso é importante para que a IA entenda o que a função faz e como usá-la.
Dica
Não tenha medo de fornecer descrições detalhadas para suas funções se uma IA estiver tendo problemas para chamá-las. Exemplos de poucas imagens, recomendações para quando usar (e não usar) a função e orientação sobre onde obter os parâmetros necessários podem ser úteis.
2) Adicione o plugin ao seu kernel
Depois de definir seu plugin, você pode adicioná-lo ao seu kernel criando uma nova instância do plug-in e adicionando-o à coleção de plug-ins do kernel.
Este exemplo demonstra a maneira mais fácil de adicionar uma classe como um plug-in com o método AddFromType
. Para saber mais sobre outras maneiras de adicionar plug-ins, consulte o artigo adicionando plug-ins nativos.
var builder = new KernelBuilder();
builder.Plugins.AddFromType<LightsPlugin>("Lights")
Kernel kernel = builder.Build();
kernel = Kernel()
kernel.add_plugin(
LightsPlugin(),
plugin_name="Lights",
)
// Import the LightsPlugin
KernelPlugin lightPlugin = KernelPluginFactory.createFromObject(new LightsPlugin(),
"LightsPlugin");
// Create a kernel with Azure OpenAI chat completion and plugin
Kernel kernel = Kernel.builder()
.withAIService(ChatCompletionService.class, chatCompletionService)
.withPlugin(lightPlugin)
.build();
3) Invoque as funções do plugin
Finalmente, você pode fazer com que a IA invoque as funções do seu plugin usando a chamada de função. Abaixo está um exemplo que demonstra como persuadir a IA a chamar a função get_lights
do plugin Lights
antes de chamar a função change_state
para acender uma luz.
using Microsoft.SemanticKernel;
using Microsoft.SemanticKernel.ChatCompletion;
using Microsoft.SemanticKernel.Connectors.OpenAI;
// Create a kernel with Azure OpenAI chat completion
var builder = Kernel.CreateBuilder().AddAzureOpenAIChatCompletion(modelId, endpoint, apiKey);
// Build the kernel
Kernel kernel = builder.Build();
var chatCompletionService = kernel.GetRequiredService<IChatCompletionService>();
// Add a plugin (the LightsPlugin class is defined below)
kernel.Plugins.AddFromType<LightsPlugin>("Lights");
// Enable planning
OpenAIPromptExecutionSettings openAIPromptExecutionSettings = new()
{
FunctionChoiceBehavior = FunctionChoiceBehavior.Auto()
};
// Create a history store the conversation
var history = new ChatHistory();
history.AddUserMessage("Please turn on the lamp");
// Get the response from the AI
var result = await chatCompletionService.GetChatMessageContentAsync(
history,
executionSettings: openAIPromptExecutionSettings,
kernel: kernel);
// Print the results
Console.WriteLine("Assistant > " + result);
// Add the message from the agent to the chat history
history.AddAssistantMessage(result);
import asyncio
from semantic_kernel import Kernel
from semantic_kernel.functions import kernel_function
from semantic_kernel.connectors.ai.open_ai import AzureChatCompletion
from semantic_kernel.connectors.ai.function_choice_behavior import FunctionChoiceBehavior
from semantic_kernel.connectors.ai.chat_completion_client_base import ChatCompletionClientBase
from semantic_kernel.contents.chat_history import ChatHistory
from semantic_kernel.functions.kernel_arguments import KernelArguments
from semantic_kernel.connectors.ai.open_ai.prompt_execution_settings.azure_chat_prompt_execution_settings import (
AzureChatPromptExecutionSettings,
)
async def main():
# Initialize the kernel
kernel = Kernel()
# Add Azure OpenAI chat completion
chat_completion = AzureChatCompletion(
deployment_name="your_models_deployment_name",
api_key="your_api_key",
base_url="your_base_url",
)
kernel.add_service(chat_completion)
# Add a plugin (the LightsPlugin class is defined below)
kernel.add_plugin(
LightsPlugin(),
plugin_name="Lights",
)
# Enable planning
execution_settings = AzureChatPromptExecutionSettings()
execution_settings.function_call_behavior = FunctionChoiceBehavior.Auto()
# Create a history of the conversation
history = ChatHistory()
history.add_message("Please turn on the lamp")
# Get the response from the AI
result = await chat_completion.get_chat_message_content(
chat_history=history,
settings=execution_settings,
kernel=kernel,
)
# Print the results
print("Assistant > " + str(result))
# Add the message from the agent to the chat history
history.add_message(result)
# Run the main function
if __name__ == "__main__":
asyncio.run(main())
// Enable planning
InvocationContext invocationContext = new InvocationContext.Builder()
.withReturnMode(InvocationReturnMode.LAST_MESSAGE_ONLY)
.withToolCallBehavior(ToolCallBehavior.allowAllKernelFunctions(true))
.build();
// Create a history to store the conversation
ChatHistory history = new ChatHistory();
history.addUserMessage("Turn on light 2");
List<ChatMessageContent<?>> results = chatCompletionService
.getChatMessageContentsAsync(history, kernel, invocationContext)
.block();
System.out.println("Assistant > " + results.get(0));
Com o código acima, você deve obter uma resposta semelhante à seguinte:
Funções | Mensagem |
---|---|
🔵 do Utilizador | Por favor, ligue a lâmpada |
Assistente 🔴(chamada de função) | Lights.get_lights() |
🟢 Ferramenta | [{ "id": 1, "name": "Table Lamp", "isOn": false, "brightness": 100, "hex": "FF0000" }, { "id": 2, "name": "Porch light", "isOn": false, "brightness": 50, "hex": "00FF00" }, { "id": 3, "name": "Chandelier", "isOn": true, "brightness": 75, "hex": "0000FF" }] |
Assistente 🔴(chamada de função) | Lights.change_state(1, { "isOn": true }) |
🟢 Ferramenta | { "id": 1, "name": "Table Lamp", "isOn": true, "brightness": 100, "hex": "FF0000" } |
Assistente 🔴 | A lâmpada está agora acesa |
Dica
Embora você possa invocar uma função de plugin diretamente, isso não é aconselhável porque a IA deve ser quem decide quais funções chamar. Se você precisar de controle explícito sobre quais funções são chamadas, considere usar métodos padrão em sua base de código em vez de plugins.
Recomendações gerais para plugins de criação
Considerando que cada cenário tem requisitos únicos, utiliza designs de plug-ins distintos e pode incorporar vários LLMs, é desafiador fornecer um guia único para o design de plugins. No entanto, abaixo estão algumas recomendações e diretrizes gerais para garantir que os plugins sejam amigáveis à IA e possam ser consumidos de forma fácil e eficiente pelos LLMs.
Importe apenas os plugins necessários
Importe apenas os plug-ins que contêm funções necessárias para o seu cenário específico. Essa abordagem não apenas reduzirá o número de tokens de entrada consumidos, mas também minimizará a ocorrência de chamadas erradas para funções que não são usadas no cenário. De modo geral, esta estratégia deve aumentar a exatidão na invocação de função e diminuir o número de falsos positivos.
Além disso, a OpenAI recomenda que você não use mais de 20 ferramentas em uma única chamada de API; idealmente, não mais do que 10 ferramentas. Como afirmado pela OpenAI: "Recomendamos que você use não mais do que 20 ferramentas em uma única chamada de API. Os desenvolvedores normalmente veem uma redução na capacidade do modelo de selecionar a ferramenta correta quando tiverem entre 10 e 20 ferramentas definidas."* Para obter mais informações, você pode visitar sua documentação em OpenAI Function Calling Guide.
Torne os plugins amigáveis à IA
Para melhorar a capacidade do LLM de entender e utilizar plugins, recomenda-se seguir estas diretrizes:
Use nomes de funções descritivos e concisos: Certifique-se de que os nomes de funções transmitam claramente seu propósito para ajudar o modelo a entender quando selecionar cada função. Se o nome de uma função for ambíguo, considere renomeá-lo para maior clareza. Evite usar abreviaturas ou acrónimos para encurtar nomes de funções. Utilize o
DescriptionAttribute
para fornecer contexto e instruções adicionais somente quando necessário, minimizando o consumo de tokens.Minimizar parâmetros de função: Limite o número de parâmetros de função e use tipos primitivos sempre que possível. Essa abordagem reduz o consumo de token e simplifica a assinatura da função, tornando mais fácil para o LLM corresponder aos parâmetros da função de forma eficaz.
Nomeie claramente os parâmetros da função: Atribua nomes descritivos aos parâmetros da função para esclarecer sua finalidade. Evite usar abreviaturas ou siglas para encurtar nomes de parâmetros, pois isso ajudará o LLM a raciocinar sobre os parâmetros e fornecer valores precisos. Tal como acontece com nomes de funções, use o
DescriptionAttribute
apenas quando necessário para minimizar o consumo de tokens.
Encontrar um equilíbrio certo entre o número de funções e as suas responsabilidades
Por um lado, ter funções com uma única responsabilidade é uma boa prática que permite manter funções simples e reutilizáveis em vários cenários. Por outro lado, cada chamada de função incorre em sobrecarga em termos de latência de ida e volta da rede e do número de tokens de entrada e saída consumidos: os tokens de entrada são usados para enviar a definição de função e o resultado da invocação para o LLM, enquanto os tokens de saída são consumidos ao receber a chamada de função do modelo.
Como alternativa, uma única função com várias responsabilidades pode ser implementada para reduzir o número de tokens consumidos e diminuir a sobrecarga de rede, embora isso tenha o custo de uma reutilização reduzida em outros cenários.
No entanto, a consolidação de muitas responsabilidades em uma única função pode aumentar o número e a complexidade dos parâmetros da função e seu tipo de retorno. Essa complexidade pode levar a situações em que o modelo pode ter dificuldades para corresponder corretamente aos parâmetros da função, resultando em parâmetros perdidos ou valores de tipo incorreto. Portanto, é essencial encontrar o equilíbrio certo entre o número de funções para reduzir a sobrecarga da rede e o número de responsabilidades que cada função tem, garantindo que o modelo possa corresponder com precisão aos parâmetros da função.
Transformar funções do kernel semântico
Utilize as técnicas de transformação para funções do Kernel Semântico, conforme descrito na postagem do blog
Alterar o comportamento da função: Há cenários em que o comportamento padrão de uma função pode não estar alinhado com o resultado desejado e não é viável modificar a implementação da função original. Nesses casos, você pode criar uma nova função que encapsula a original e modifica seu comportamento de acordo.
Fornecer informações de contexto: Funções podem exigir parâmetros que o LLM não pode ou não deve inferir. Por exemplo, se uma função precisa agir em nome do usuário atual ou requer informações de autenticação, esse contexto normalmente está disponível para o aplicativo host, mas não para o LLM. Nesses casos, você pode transformar a função para invocar a original enquanto fornece as informações de contexto necessárias do aplicativo de hospedagem, juntamente com os argumentos fornecidos pelo LLM.
Alterar lista de parâmetros, tipos e nomes: Se a função original tiver uma assinatura complexa que o LLM se esforça para interpretar, você pode transformar a função em uma com uma assinatura mais simples que o LLM pode entender mais facilmente. Isso pode envolver a alteração de nomes de parâmetros, tipos, número de parâmetros e achatamento ou desnivelamento de parâmetros complexos, entre outros ajustes.
Utilização do estado local
Ao projetar plugins que operam em conjuntos de dados relativamente grandes ou confidenciais, como documentos, artigos ou e-mails contendo informações confidenciais, considere utilizar o estado local para armazenar dados originais ou resultados intermediários que não precisam ser enviados ao LLM. As funções para tais cenários podem aceitar e retornar uma ID de estado, permitindo que você pesquise e acesse os dados localmente em vez de passar os dados reais para o LLM, apenas para recebê-los de volta como um argumento para a próxima chamada de função.
Ao armazenar dados localmente, você pode manter as informações privadas e seguras, evitando o consumo desnecessário de tokens durante chamadas de função. Esta abordagem não só melhora a privacidade dos dados, mas também melhora a eficiência geral no processamento de conjuntos de dados grandes ou sensíveis.