Fan-out especulativo: fazer todas as perguntas a um modelo de decisão numa única requisição e decidir no código

O que é

Uma requisição à API da TypeSafe carrega um estado e um mapa de perguntas. A documentação afirma que cada pergunta é avaliada em paralelo e de forma isolada contra o mesmo estado, que adicionar perguntas quase não altera o tempo de resposta e que adicionar perguntas não gera context rot, porque nenhuma pergunta vê a resposta de outra. O padrão de fan-out decorre daí: em vez de perguntar primeiro a categoria e, só depois de conhecê-la, perguntar a severidade numa segunda chamada, fazem-se as duas perguntas ao mesmo tempo e lê-se a severidade apenas se a categoria for um relato de bug.

Por que importa

Cadeias sequenciais de decisão em um loop de agente custam uma ida e volta de rede por etapa, e cada etapa é um ponto em que uma falha parcial deixa o fluxo de trabalho decidido pela metade. Uma única requisição com todas as perguntas tem uma só latência, um só modo de falha e uma só entrada de log. O cookbook de perguntas paralelas do fornecedor executa um briefing regulatório de treze perguntas sobre o artigo da Wikipedia sobre o GDPR e relata que agrupar todas as perguntas em uma chamada foi 12,2x mais barato e 10,0x mais rápido do que chamadas separadas, sem mudança nas respostas. A página de modelos afirma que o estado é ingerido uma vez por requisição e que cada pergunta é avaliada contra ele, e daí vem a diferença de custo entre uma requisição e várias, já que o preço é por token de entrada.

Como aplicar

• Reúna todas as perguntas de que um fluxo de trabalho possa precisar para um dado estado, incluindo as especulativas para ramos que talvez não sejam seguidos, e envie-as juntas.
• Use como chave de cada pergunta aquilo que ela decide e leia as respostas no código na ordem que o fluxo exige; ignore as respostas cuja pré-condição não se verificou.
• Mantenha no estado apenas aquilo de que as perguntas precisam. O fan-out multiplica o valor de um estado enxuto, e o orçamento é de 64k tokens para o estado mais todas as perguntas, com 32k para o estado mais a pergunta mais longa.
• Use o mesmo estado em todas as perguntas; se duas decisões precisam de material diferente, são duas requisições, não um estado grande.
• Registre a resposta completa em log, para que uma dúvida posterior sobre por que um ramo foi seguido possa ser respondida a partir das probabilidades gravadas.

Armadilhas

A independência tem dois lados: uma pergunta de acompanhamento não pode depender de uma resposta anterior dentro da mesma requisição. Por isso, uma pergunta realmente condicional (a severidade de um bug, dado que é um bug) é feita de forma incondicional e filtrada depois. As respostas a perguntas cuja pré-condição é falsa continuam sendo saídas reais, com probabilidades reais; trate-as como ruído, não como evidência. Os fatores do cookbook são números do próprio fornecedor, obtidos no exemplo do fornecedor.