Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Os aplicativos podem usar modelos de diferentes serviços de inferência para diferentes turnos de uma conversa. Por exemplo, um aplicativo pode alterar modelos com base na escolha do usuário, recursos de modelo, disponibilidade ou custo.
Alterar o destino da próxima solicitação é apenas uma parte do roteamento. O novo modelo também precisa que a conversa anterior continue com o mesmo contexto. Se ele pode receber esse contexto depende de onde o histórico de chat é armazenado e quem o controla.
O armazenamento de histórico de chat determina a portabilidade
Os serviços de inferência oferecem suporte a diferentes abordagens para o estado da conversa. Algumas APIs esperam que o chamador forneça o histórico de mensagens relevante a cada solicitação. Outras APIs armazenam a conversa no serviço de inferência e permitem que o chamador continue passando um identificador.
| Modelo de histórico | Onde as mensagens são armazenadas | O que o chamador envia |
|---|---|---|
| Gerenciado pelo chamador | Na memória controlada pelo aplicativo ou no armazenamento durável | O histórico de mensagens relevante mais as novas mensagens com cada solicitação |
| Gerenciado pelo serviço de inferência | No armazenamento controlado pelo serviço de inferência | Um identificador de conversa ou de resposta específico do serviço, além de quaisquer novas mensagens. |
Alguns serviços de inferência oferecem suporte a ambas as abordagens por meio de APIs ou opções distintas. Por exemplo, as respostas da OpenAI têm o parâmetro store, que você pode definir como true para o histórico de chat gerenciado pelo serviço de inferência e como false para o histórico gerenciado pelo chamador.
O histórico gerenciado pelo chamador dá suporte ao roteamento
Quando o chamador gerencia o histórico, ele tem acesso às mensagens de turnos anteriores. Um roteador pode selecionar outro modelo ou serviço de inferência e o chamador pode enviar essas mensagens com a próxima solicitação.
O histórico não precisa permanecer na memória do processo. Ele pode vir do armazenamento durável de propriedade do aplicativo, desde que o aplicativo possa carregá-lo e enviá-lo para o serviço selecionado. O destino também deve dar suporte ao conteúdo da mensagem e aos recursos usados anteriormente na conversa.
Roteamento de limites de histórico gerenciados pelo serviço de inferência
Quando um serviço de inferência gerencia o histórico, ele é a fonte da verdade para a conversa. O chamador normalmente retém um identificador opaco em vez das próprias mensagens.
Esse identificador refere-se ao estado mantido pelo serviço de origem. O acesso também pode depender da conta ou do projeto, do endpoint e das credenciais usadas para criar a conversa. Um cliente para outro serviço não pode usar o identificador para recuperar as mensagens. Outro cliente do mesmo serviço também poderá não conseguir acessar a conversa se usar um escopo diferente.
Um serviço pode dar suporte à alteração de modelos em uma de suas próprias conversas armazenadas. Esse comportamento é específico para o serviço e não é roteamento portátil. Um roteador geral não pode transferir a conversa do lado do serviço para outro provedor sem primeiro recuperar ou reconstruir as mensagens.
| Cenário de roteamento | Modelo de histórico | Result |
|---|---|---|
| Alternar entre modelos de um provedor | Gerenciado pelo chamador | O chamador pode reproduzir o histórico para o novo modelo. O novo modelo deve dar suporte aos tipos de mensagem e conteúdo usados em turnos anteriores. |
| Alternar entre diferentes provedores de inferência | Gerenciado pelo chamador | O chamador pode reproduzir o histórico para o novo provedor. O novo provedor deve aceitar as funções, os tipos de conteúdo, as mensagens de chamada de ferramenta e as mensagens de resultado da ferramenta usadas em turnos anteriores. |
| Alterar modelos em uma conversa no servidor | Gerenciado pelo serviço de inferência | A opção só funcionará se o serviço de inferência permitir que a conversa existente continue com o novo modelo. O cliente de roteamento não pode habilitar esse comportamento. |
| Alternar para um serviço de inferência diferente | Gerenciado pelo serviço de inferência | O novo serviço não pode acessar o identificador de conversa do serviço original. Recupere ou reconstrua as mensagens e inicie a nova rota com o histórico gerenciado pelo chamador. |
Para obter mais informações sobre esses modelos de armazenamento, consulte Armazenamento.
Como o Agent Framework implementa o roteamento de runtime
O Agent Framework pode fornecer o histórico gerenciado pelo chamador necessário para o roteamento portátil. Nesse padrão de roteamento, um provedor de histórico de chat é a fonte da verdade para a conversa. Ele pode armazenar mensagens na sessão do agente ou no armazenamento de propriedade do aplicativo.
No Agent Framework, o histórico gerenciado pelo chamador inclui o estado da sessão local e o armazenamento de histórico de chat personalizado. O histórico gerenciado pelo serviço de inferência corresponde ao armazenamento gerenciado pelo serviço.
Para um ChatClientAgent, o cliente de chat de roteamento fica na camada de cliente de chat do pipeline do agente. O agente e sua sessão permanecem os mesmos enquanto o cliente de roteamento seleciona uma das várias instâncias nomeadas IChatClient para cada solicitação.
Uma solicitação roteada segue esta sequência:
- O provedor 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 a solicitação completa.
- O provedor de histórico de chat armazena as novas mensagens após a execução.
Como o cliente selecionado recebe o histórico carregado pelo provedor, o aplicativo pode alterar rotas sem recriar manualmente a conversa.
O SDK do .NET fornece o recurso experimental RoutePersistingRoutingChatClient. Defina a rota inicial com RoutePersistingRoutingChatClientOptions.DefaultRoute, inspecione a rota de uma sessão e GetActiveRoutealtere-a com SetActiveRoute. Se você não definir uma rota padrão, o cliente usará a primeira rota fornecida na construção.
Existem mais clientes de roteamento em Microsoft.Extensions.AI que permitem mais estratégias de roteamento.
Consulte o exemplo de roteamento de vários modelos para uma implementação completa do C#.
Importante
Cada cliente de chat registrado como uma rota deve usar o histórico gerenciado pelo chamador fornecido por um provedor de histórico de chat. O provedor pode armazenar esse histórico na sessão ou no armazenamento de propriedade do aplicativo. Não registre uma rota que use o histórico de conversas gerenciadas por serviço de inferência.
O suporte ao Python não está disponível no momento.
No momento, o suporte ao Go não está disponível.