A compatibilidade define a forma; o contrato define o comportamento
Um formato comum de pedido e resposta reduz alterações no cliente e facilita a troca de modelo ou fornecedor. Também permite concentrar o acesso numa interface. Mas campos iguais não revelam se o pedido foi aceite, que fornecedor o executou, quando se pode repetir, como classificar uma resposta parcial ou como reconciliar a utilização final. Quando pessoas dependem do sistema, estas perguntas tornam-se parte do contrato do produto.
Uma gateway precisa, por isso, de definir os limites entre validação, elegibilidade e política, escolha da rota, execução, classificação do resultado e prova de utilização. São responsabilidades de arquitetura, não uma afirmação de implementação idêntica em todas as gateways. Uma troca HTTP bem-sucedida não prova que o trabalho terminou. Inversamente, o cliente pode perder a resposta depois de o fornecedor já ter trabalhado. Chamar simplesmente erro a ambos os casos esconde a decisão operacional necessária.
Um fluxo é uma sequência de provas, não uma resposta única
A transmissão em fluxo deixa a aplicação mostrar texto enquanto o modelo ainda o produz. O fluxo HTTP documentado pela OpenAI, por exemplo, usa eventos enviados pelo servidor e distingue incrementos de texto de um evento de conclusão. A aplicação pode mostrar um início útil antes de saber se a resposta está completa. Se receber dois parágrafos e depois a ligação expirar, o texto visível não prova que a operação terminou. [2]
A gateway deve guardar o que sabe: identidade do pedido, rota escolhida, aceitação pelo fornecedor, eventos observados e confirmação ou ausência de conclusão. Uma resposta parcial visível não é um resultado final. Esta é uma recomendação de arquitetura, não uma promessa de que qualquer fornecedor permita retomar o fluxo. O sistema pode mostrar o resultado incompleto, pedir uma decisão sobre nova tentativa ou consultar um registo do fornecedor quando existir. O essencial é indicar a incerteza, sem a transformar silenciosamente em sucesso ou falha.
Antes de repetir, considerar o trabalho duplicado
Imagine um pedido de redação expressamente ilustrativo. O fornecedor começa a transmitir; a aplicação recebe dois parágrafos e a ligação expira. O fornecedor pode continuar a gerar e cobrar o trabalho realizado. Se a aplicação enviar logo o mesmo pedido, pode haver uma segunda geração e um segundo custo, mesmo que mostre apenas uma resposta. O prazo esgotado não prova que a primeira tentativa nunca ocorreu. A documentação de Chat Completions da OpenAI também avisa que um fluxo interrompido pode impedir a receção do bloco final com a utilização total. [3]
A semântica HTTP esclarece o risco: um cliente não deve repetir automaticamente um pedido não idempotente sem saber que a operação é, de facto, idempotente ou que a primeira tentativa não foi aplicada; um proxy não deve fazê-lo. A geração de modelos é frequentemente chamada por POST, pelo que o aspeto familiar da API não basta. [1] Uma política pode permitir repetição antes do envio, usar idempotência suportada pelo fornecedor ou exigir uma nova tentativa explícita após um fluxo ambíguo. A escolha equilibra rapidez e conveniência contra duplicação e custo incerto.
Decidir se é permitido executar antes de escolher onde
O encaminhamento escolhe onde executar um pedido elegível; a política decide se ele pode ser executado e com que limites. Um trabalho pode exigir determinada modalidade, dimensão de contexto, região, fornecedores aprovados, permissões de ferramentas ou teto de despesa. Se o fornecedor preferido falhar, uma alternativa só ajuda se cumprir as mesmas condições. Mudar silenciosamente para uma rota não elegível altera o acordo com a aplicação.
Um fluxo ilustrativo seria: validar o pedido → avaliar política e orçamento → selecionar uma rota elegível → executar com prazo → classificar o resultado → registar a utilização observada → emitir qualquer evento de faturação no sistema próprio do produto. Não descreve funcionalidades internas do RouterShift já lançadas. Rota, recuperação e contabilidade devem poder ser explicadas separadamente. Regras determinísticas são mais fáceis de auditar; seleção adaptativa pode ajudar com dados fiáveis, mas aumenta a necessidade de justificar cada escolha.
Medir o observado antes de o transformar em dinheiro
Um pedido, uma tentativa e o registo final de utilização do fornecedor são factos diferentes. Quando um fluxo é interrompido, o valor final pode faltar; contar o texto visível não justifica apresentar uma cobrança definitiva. Convém conservar o registo original, a identidade da tentativa e a base de qualquer estimativa. Quando chegam dados autorizados, é possível reconciliá-los; correções devem deixar rasto. [3]
As convenções atuais da OpenTelemetry para IA generativa dão nomes aos tokens de entrada e saída, ao modelo, ao fornecedor e a classes de erro. São vocabulário de telemetria, não um sistema de faturação nem garantia de unidades iguais entre fornecedores. Avisam também que registar mensagens pode expor dados sensíveis. [4] Preço e movimentos de saldo vêm depois da medição, com moeda, versão de tabela e trilho de auditoria. Imagem, áudio e vídeo podem precisar de unidades diferentes de tokens.
Tornar o contrato visível na operação diária
Perante um incidente, a equipa precisa de saber: que pedido foi afetado? Que rota foi escolhida e porquê? O fornecedor aceitou o trabalho? A saída está completa? Que utilização é confirmada, estimada ou desconhecida? Que versões de política e preço foram usadas? Identificadores de pedido e tentativa, estados e ligações de rastreio ajudam a responder sem guardar o conteúdo do prompt por defeito. A interface deve ser compreensível para quem opera o produto, não apenas para quem o desenvolve.
Estas perguntas também permitem avaliar as promessas de uma gateway. Se a falha ocorre antes do envio, outra rota elegível pode ser viável. Se o fluxo falha depois do início, é preciso indicar que o resultado está incompleto ou incerto e explicar as opções. Se faltar utilização, deve ficar por reconciliar. A compatibilidade reduz o custo de entrada; o contrato de produção dá previsibilidade quando o percurso ideal termina. O RouterShift é o produto ativo da SlateMoth para acesso a modelos. Este quadro explica o problema de desenho; não afirma que todos os mecanismos descritos já foram lançados no RouterShift.