Fluxos Determinísticos vs Agênticos: Lições da Construção de um Assistente de Compras

Lições em Fluxos de Trabalho Determinísticos, Raciocínio Agêntico e Gestão de Estado

A construção de assistentes de AI frequentemente começa com um problema enganosamente simples. Um usuário faz uma pergunta, o sistema recupera informações e um LLM gera uma resposta. A primeira versão geralmente funciona surpreendentemente bem.

O verdadeiro desafio surge à medida que as capacidades se expandem. Conforme novas ferramentas e fluxos de trabalho são introduzidos, os usuários começam a fazer perguntas que abrangem múltiplos domínios. As conversas tornam-se mais longas e contextuais, transformando o assistente de um simples bot de QA em uma ferramenta que ajuda os usuários a concluir tarefas complexas.

Na TrueFoundry, encontramos exatamente esse desafio ao construir um assistente de compras conversacional. O assistente começou como um companheiro de Página de Detalhes do Produto (PDP) capaz de responder a perguntas sobre um único produto. Com o tempo, ele evoluiu para um assistente de compras para todo o catálogo, capaz de lidar com descoberta de produtos, recuperação, sumarização de avaliações, processamento de cupons, descoberta de lojas, checagem de inventário, seleção de atendimento e operações de carrinho.

Embora as capacidades externas tenham se expandido significativamente, os desafios de engenharia mais críticos surgiram em duas áreas:

1. Decidir quando usar fluxos de trabalho determinísticos em vez de raciocínio agêntico.
2. Evoluir a gestão de estado de um modelo de conversa de produto único para uma experiência de compra multiproduto.

1. Visão Geral da Arquitetura do Sistema

O assistente de compras é construído sobre quatro camadas arquitetônicas principais projetadas para equilibrar desempenho, custo e confiabilidade.

A. Camada de Dados

O sistema mantém uma separação rigorosa entre sistemas de armazenamento estruturados e não estruturados:

• Catálogo de Produtos: Armazenado no PostgreSQL (Cloud SQL), contendo metadados de produtos, preços, variantes, informações de categoria e metadados de atendimento.
• Avaliações: As avaliações dos clientes são armazenadas no Qdrant. Isso permite a recuperação semântica do conteúdo das avaliações em vez de depender apenas da correspondência de palavras-chave. Quando os usuários fazem perguntas semânticas como "O que os clientes dizem sobre a duração da bateria?", o sistema recupera avaliações relevantes e gera um resumo baseado em evidências.

B. Pipeline de Ingestão de Dados

Os dados de catálogo e avaliações chegam continuamente através do Google Cloud Storage (GCS) e são processados via pipelines do Google Dataflow:

• Pipeline de Catálogo: GCS → Dataflow → Cloud SQL (Processado diariamente).
• Pipeline de Avaliações: GCS → Dataflow → Geração de Embeddings → Qdrant (Processado em cronogramas diários e de hora em hora para feedback recente dos clientes).

C. Camada de Modelos

Todas as interações de modelos são roteadas através do TrueFoundry AI Gateway. Isso fornece acesso centralizado a modelos, observabilidade, governança, rastreamento de custos, limitação de taxa (rate limiting) e abstração de modelos. O assistente utiliza os modelos Gemini 2.5 Flash e Qwen para equilibrar latência, qualidade e custo operacional.

D. Camada de Orquestração

O fluxo de trabalho conversacional é orquestrado usando LangGraph, que permite transições explícitas de estado e gestão de fluxo de trabalho, suportando caminhos de execução determinísticos e raciocínio agêntico.

2. Desafio nº 1: Fluxos de Trabalho Determinísticos vs. Agênticos

Uma tendência comum em sistemas de AI é tornar tudo completamente agêntico sob a suposição de que, se um LLM pode raciocinar, ele deve lidar com tudo. Em produção, uma abordagem puramente baseada em agentes rapidamente se torna cara, lenta e difícil de controlar.

Dividimos as interações de compra em dois paradigmas de execução distintos com base em trade-offs claros de desempenho e intenção:

Sob o Capô: A Mecânica de Execução

A decisão arquitetônica de separar esses fluxos é fortemente impulsionada pelos loops internos, contagem total de chamadas de LLM e overhead de processamento de tokens.

O Ciclo de Vida do Agente ReAct (Loop de 3 Etapas)

Para fluxos de trabalho complexos, um agente ReAct dedicado lida com a execução dinamicamente através de um ciclo de três etapas:

1. Etapa 1: O Prompt de Planejamento (Chamada de LLM): O sistema passa a consulta do usuário junto com prompts do sistema contendo as definições de todas as ferramentas disponíveis. O LLM deve raciocinar sobre o que o usuário disse, identificar qual ferramenta usar e extrair os parâmetros exatos necessários para essa ferramenta.
2. Etapa 2: A Execução da Ferramenta: O sistema executa a chamada real da ferramenta ou API usando os parâmetros extraídos.
3. Etapa 3: O Prompt de Observação & Síntese (Chamada de LLM): A resposta bruta da ferramenta é enviada de volta ao LLM. O modelo avalia a resposta da ferramenta em relação à pergunta original do usuário e a modifica em uma resposta limpa e contextualizada.

O Ciclo de Vida Determinístico (Atalho de 2 Etapas)

Capacidades como especificações de produtos, avaliações e cupons não precisam raciocinar sobre escolhas de ferramentas ou ordem de execução. Para otimizar o desempenho, ignoramos a fase de planejamento completamente:

1. Etapa 1: Execução Direta da Ferramenta: Como a classificação de intenção se mapeia diretamente para uma ferramenta conhecida, a primeira chamada de prompt do LLM é totalmente ignorada. O sistema executa a ferramenta imediatamente, eliminando um ciclo completo de inferência e reduzindo o time-to-first-byte.
2. Etapa 2: Síntese da Resposta (Chamada de LLM): O sistema passa os dados brutos da ferramenta e a consulta do usuário diretamente para um prompt altamente focado para formatar a resposta final.

A Penalidade de Latência e Complexidade de Prompt

Além de contar o número de chamadas, a complexidade do prompt dita significativamente a velocidade das respostas:

• Carga de Prompt ReAct: Na Etapa 1 de um agente ReAct, o prompt é altamente complexo. O LLM deve analisar múltiplas ferramentas, avaliar a lógica de execução e manter o contexto. Essa alta carga cognitiva aumenta o tempo de processamento de tokens e a latência de geração.
• Eficiência do Prompt Determinístico: Em um fluxo determinístico, o prompt final é direto: "Aqui está a pergunta e aqui está a resposta bruta da ferramenta. Forneça a resposta." Como o modelo não precisa avaliar caminhos nem rastrear ferramentas, a geração de tokens é rápida e leve.

Lição Fundamental: Forçar um loop de raciocínio ReAct em consultas de dados básicas adiciona latência, custo e complexidade operacional desnecessários sem melhorar a qualidade da resposta. Se uma interação pode ser tratada de forma determinística, ela deve sê-lo.

Protegendo (Guardrailing) os Agentes ReAct

Onde os caminhos determinísticos falham (por exemplo, "Posso receber isso hoje?" envolvendo resolução de localização, descoberta de lojas e checagem de atendimento), os agentes ReAct são vitais. No entanto, agentes totalmente autônomos frequentemente produzem experiências inconsistentes para os clientes. Para manter o controle, a TrueFoundry implementou estágios estruturados de fluxo de trabalho dentro dos agentes dinâmicos:

• Estágios do Agente de Inventário: Resolução de Localização → Seleção de Loja → Checagem de Inventário → Explicação do Resultado.
• Estágios do Agente de Compra: Validação de Produto → Verificação de Inventário → Seleção de Atendimento → Operação de Carrinho → Confirmação.

3. Desafio nº 2: Evolução da Gestão de Estado

Evoluir de um assistente de página de produto único para um companheiro de compras para todo o catálogo é fundamentalmente um problema de gestão de estado.

• Fase 1 (Estado de Produto Único): O contexto do produto era derivado implicitamente da página ativa. O modelo de estado era uma thread de histórico de conversa simples e plana.
• Fase 2 (Conversas Multiproduto): A busca no catálogo permite que os usuários introduzam, meçam e alternem entre múltiplos produtos simultaneamente.

Para escalar sem introduzir fragilidade ao sistema, a arquitetura de estado foi completamente reformulada através de quatro princípios de design fundamentais:

1. Separação de Escopos de Estado

Misturar dados do usuário com dados transitórios de produtos cria sistemas frágeis. O estado foi refatorado em limites distintos:

• Estado em Nível de Usuário: Persistente ao longo de toda a sessão de compras (por exemplo, loja favorita, preferências de localização, escolhas de atendimento).
• Estado em Nível de Produto: Vinculado a itens específicos (por exemplo, metadados do catálogo, cupons ativos, avaliações).

2. Rastreamento Explícito de Contexto (current_product_id)

Mudamos o contexto do produto de implícito para explícito, introduzindo o current_product_id como uma variável de estado de primeira classe. Quando um usuário muda o foco para um novo item, a atualização desse único ID limpa e atualiza automaticamente os dados downstream de catálogo, avaliações, cupons e variáveis de inventário.

3. Memória de Thread Específica por Agente

Manter um único array plano conversation_history = [] introduziu um ruído enorme de tokens e degradou o desempenho do modelo. Conversas de busca exigem janelas de contexto inteiramente diferentes de operações de checkout final. A memória foi delimitada diretamente em threads de agentes isoladas (Busca, Inventário, Compra, Produto) para minimizar a contaminação entre contextos.

4. Resolução de Referência de Produto

A classificação de intenção sozinha é insuficiente quando se lida com um catálogo global. Quando um usuário pergunta "Isso está disponível perto de mim?", o sistema conta com uma camada recém-introduzida de Resolução de Referência de Produto para deduzir matematicamente a qual item "isso" se refere, avaliar se a consulta é ambígua e decidir se um prompt de esclarecimento é necessário.

Lição Principal de Arquitetura: O estado deve representar fluxos de trabalho (Busca, Inventário, Compra) em vez de domínios de dados (Avaliações, Cupons, Produtos). Projetar o estado em torno da intenção do usuário e da progressão do fluxo de trabalho simplifica significativamente a orquestração e reduz a complexidade do rastreamento multiagente.