Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
As aplicações podem usar modelos de diferentes serviços de inferência para diferentes rumos de uma conversa. Por exemplo, uma aplicação pode mudar de modelo com base na escolha do utilizador, capacidades do modelo, disponibilidade ou custo.
Alterar o destino para o próximo pedido é apenas uma parte do encaminhamento. O novo modelo também exige que a conversa anterior continue com o mesmo contexto. Se pode receber esse contexto depende de onde o histórico de chat está armazenado e quem o controla.
O armazenamento do histórico de chat determina a portabilidade
Os serviços de inferência suportam diferentes abordagens ao estado da conversa. Algumas APIs esperam que o chamador forneça o histórico de mensagens relevante em cada pedido. Outras APIs armazenam a conversa no serviço de inferência e permitem que o chamador a continue passando um identificador.
| Modelo histórico | Onde as mensagens são armazenadas | O que o chamador envia |
|---|---|---|
| Gerido pelo autor da chamada | Em memória controlada por aplicações ou armazenamento durável | O histórico de mensagens relevante, mais quaisquer novas mensagens com cada pedido |
| gerido pelo serviço de inferência | Em armazenamento controlado pelo serviço de inferência | Um identificador específico de conversa ou resposta do serviço, além de quaisquer novas mensagens. |
Alguns serviços de inferência suportam ambas as abordagens através de APIs ou opções diferentes. Por exemplo, as respostas da OpenAI têm o parâmetro store, que pode definir como true para histórico de conversação gerido pelo serviço de inferência, e como false para gestão pelo autor da chamada.
O histórico gerido pelo autor da chamada permite o encaminhamento
Quando o chamador gere o histórico, tem acesso às mensagens dos turnos anteriores. Um router pode selecionar outro modelo ou serviço de inferência, e o chamador pode enviar essas mensagens com o próximo pedido.
A história não tem de permanecer na memória do processo. Pode vir de armazenamento durável pertencente à aplicação, desde que a aplicação consiga carregá-lo e enviá-lo para o serviço selecionado. O destino deve também suportar o conteúdo da mensagem e as funcionalidades usadas anteriormente na conversa.
O histórico gerido de serviços de inferência limita o encaminhamento
Quando um serviço de inferência gere a história, é a fonte da verdade para a conversa. O chamador normalmente mantém um identificador opaco em vez das mensagens em si.
Esse identificador refere-se ao estado detido pelo serviço de origem. O acesso também pode depender da conta ou projeto, endpoint e credenciais usadas para criar a conversa. Um cliente de outro serviço não pode usar o identificador para recuperar as mensagens. Outro cliente do mesmo serviço também pode não conseguir aceder à conversa se utilizar um escopo diferente.
Um serviço pode suportar a mudança de modelos dentro de uma das suas próprias conversas armazenadas. Esse comportamento é específico do serviço e não é roteamento portátil. Um router geral não pode transferir a conversa do lado do serviço para outro fornecedor sem antes recuperar ou reconstruir as mensagens.
| Cenário de roteamento | Modelo histórico | Result |
|---|---|---|
| Alternar entre modelos de um único fornecedor | Gestão de chamadas | O chamador pode reproduzir o histórico do novo modelo. O novo modelo deve suportar os tipos de mensagem e conteúdo usados em turnos anteriores. |
| Alternar entre diferentes fornecedores de inferência | Gerido pelo autor da chamada | O interlocutor pode reproduzir o histórico para o novo fornecedor. O novo fornecedor deve aceitar os papéis, tipos de conteúdo, mensagens de chamada de ferramenta e mensagens de resultado de ferramenta usadas em turnos anteriores. |
| Alterar modelos numa conversa no lado do serviço | gerido pelo serviço de inferência | A opção só funciona se o serviço de inferência permitir que a conversa existente continue com o novo modelo. O cliente de roteamento não consegue ativar este comportamento. |
| Mude para um serviço de inferência diferente | gerido pelo serviço de inferência | O novo serviço não consegue aceder ao identificador de conversa do serviço original. Recupere ou reconstrua as mensagens e inicie a nova rota com histórico gerido pelo chamador. |
Para mais informações sobre estes modelos de armazenamento, consulte Armazenamento.
Como o Agent Framework implementa o encaminhamento durante o tempo de execução
O Agent Framework pode fornecer o histórico gerido pelo chamador necessário para o encaminhamento portátil. Neste padrão de roteamento, um serviço de histórico da conversação é a fonte fidedigna da conversa. Pode armazenar mensagens na sessão do agente ou em armazenamento pertencente à aplicação.
No Agent Framework, o histórico gerido pelo chamador inclui o estado local da sessão e o armazenamento personalizado do histórico de chat. O histórico gerido pelo serviço de inferência corresponde ao armazenamento gerido pelo serviço.
Para um ChatClientAgent, um cliente de chat de roteamento situa-se na camada cliente-chat do pipeline do agente. O agente e a sua sessão mantêm-se iguais enquanto o cliente de encaminhamento seleciona uma de várias instâncias nomeadas IChatClient para cada pedido.
Um pedido encaminhado segue esta sequência:
- O fornecedor de histórico de chat carrega o histórico de conversas.
- O agente combina o histórico com a entrada para o turno atual.
- O cliente de roteamento seleciona o cliente de chat ativo para a sessão.
- O cliente selecionado recebe o pedido completo.
- O fornecedor de histórico de chat armazena as novas mensagens após a execução.
Como o cliente selecionado recebe o histórico carregado pelo fornecedor, a aplicação pode alterar rotas sem reconstruir manualmente a conversa.
O SDK .NET fornece o experimento RoutePersistingRoutingChatClient. Defina a rota inicial com RoutePersistingRoutingChatClientOptions.DefaultRoute, inspecione a rota de uma sessão com GetActiveRoute, e altere-a com SetActiveRoute. Se não definires uma rota por defeito, o cliente usa a primeira rota especificada durante a construção.
No Microsoft.Extensions.AI, existem outros clientes de encaminhamento que permitem outras estratégias de encaminhamento.
Consulte o exemplo de encaminhamento multi-modelo para uma implementação completa em C#.
Importante
Cada cliente de chat registado como rota tem de usar o histórico gerido pelo chamador fornecido por um fornecedor do histórico de chat. O fornecedor pode armazenar esse histórico na sessão ou num armazenamento pertencente à aplicação. Não registe uma rota que utilize histórico de conversas gerido pelo serviço de inferência.
O suporte para Python não está atualmente disponível.
O suporte do Go não está disponível neste momento.