Um dos meus clientes vende produtos regulamentados no Canadá. Sua fila de suporte ao cliente estava cheia das mesmas perguntas: como devo tomar isso, posso tomar junto com meu medicamento, onde está meu pedido? Um chatbot parecia óbvio. O que não era óbvio era como construir um que não alucinasse informações de dosagem para alguém perguntando sobre interações medicamentosas.
Essa é uma restrição — precisão importa mais que conveniência — que moldou cada decisão de arquitetura.
Por Que RAG Em Vez de um Prompt do Sistema Preenchido
O primeiro instinto com chatbots LLM é despejar todo o conhecimento do produto no prompt do sistema e chamar de pronto. Para um catálogo pequeno e conteúdo de FAQ estático, funciona. Até não funcionar mais e o chatbot alucinar.
O conteúdo de FAQ aqui incluía orientações médicas: quais medicamentos interagem com os produtos do cliente, quem não deveria usar esses produtos de forma alguma, e cronogramas de dosagem para diferentes condições. Esse conteúdo muda conforme a empresa aprende mais, recebe novas orientações de conformidade, ou atualiza produtos. Codificar isso em um prompt do sistema significa que cada atualização de conteúdo requer uma edição do workflow n8n e um re-deploy.
Também significa que a janela de contexto se enche rapidamente, e em algum ponto, o modelo começa a desistir de conteúdo enterrado no fundo de um prompt de 10.000 tokens. O que pode criar respostas erradas.
Uma configuração RAG apropriada inverte isso. A base de conhecimento vive em um banco de dados de vetores. O agente a consulta em tempo de execução. Atualizar a base de conhecimento é apenas um workflow de ingestão.
A abordagem retrieval-augmented generation também oferece algo que um prompt preenchido não consegue: um rastro de auditoria limpo do que o modelo recuperou antes de responder. Quando um cliente pergunta sobre misturar psilocibina com ISRSs e o bot erra, você pode verificar se o documento certo foi retornado. Com um prompt, você está adivinhando.
Dois Índices Pinecone, Não Um
O workflow de ingestão cria dois índices Pinecone separados: products e knowledge-base.
Essa separação é deliberada. O catálogo de produtos e o conteúdo de FAQ têm cadências de atualização diferentes. Um produto é adicionado ou reprercebido a cada poucas semanas. O conteúdo de FAQ, especialmente a orientação médica, muda com menos frequência mas importa mais quando muda. Mantê-los em índices separados significa que você pode re-embedar o catálogo de produtos sem tocar nos embeddings de FAQ, e vice-versa.
Também significa que a recuperação fica limpa. Um cliente perguntando "o que tem nas cápsulas do Produto X" deve acessar dados de produtos. Um cliente perguntando "posso tomar isso se tenho transtorno bipolar?" deve acessar o FAQ. Misturá-los em um único índice corre o risco de o modelo exibir uma descrição de produto em resposta a uma pergunta de segurança.
O modelo de embedding é text-embedding-3-large em 3072 dimensões. Isso é mais caro por token que o text-embedding-3-small padrão. Para informações de dosagem precisa e orientação médica em um contexto regulamentado, a qualidade de recuperação não é onde você corta custos.
A Camada n8n
O chatbot principal é executado como um único workflow n8n com um agente de IA em seu centro. Mas a arquitetura real é três workflows: o agente principal, um sub-workflow de busca de pedidos WooCommerce, e um sub-workflow de ticket de suporte HelpScout.
Essa separação importa mais do que pode parecer. O agente tem cinco ferramentas disponíveis: a base de conhecimento Pinecone, o sub-workflow WooCommerce, o sub-workflow HelpScout, um logger Google Sheets, e um utilitário de data/hora. Cada sub-workflow é independentemente testável, independentemente depurável, e pode ser atualizado sem tocar no agente principal.
Se a API WooCommerce mudar, vou atualizar um workflow. Se HelpScout adicionar um novo campo que quero capturar, vou atualizar um workflow. O workflow do agente principal não precisa saber de nada disso.
n8n lida com isso com o tipo de nó toolWorkflow, que permite ao agente chamar outro workflow como uma ferramenta, passando parâmetros estruturados e recebendo saída estruturada. O agente decide quando chamar qual ferramenta — mas o prompt do sistema é explícito sobre a ordem de prioridade.
A Integração WooCommerce
A busca de pedidos é uma chamada de API em duas etapas. O agente recebe um email de cliente da conversa e o passa para o sub-workflow WooCommerce. Esse workflow acessa /wp-json/wc/v3/customers?email=... para resolver o email para um ID de cliente, depois acessa /wp-json/wc/v3/orders?customer=... para recuperar os pedidos.
Duas chamadas, mas limpas. A etapa de ID de cliente também serve como um controle de autenticação natural: se nenhum registro de cliente existir para esse email, o workflow retorna "Nenhum usuário encontrado" e o agente responde de acordo. O agente apenas exibe informações de pedido quando o cliente fornece seu próprio email, o que lida com a preocupação de privacidade sem precisar construir um fluxo de autenticação separado.
Os dados de pedido retornados são filtrados para os campos que importam para suporte: ID do pedido, status, data de criação, data de modificação, e endereço de envio. O agente é instruído a resumir os últimos três pedidos concluídos em linguagem simples, não a despejar uma bagunça JSON no cliente.
A Ponte HelpScout
Quando o bot não consegue responder uma pergunta, ele não apenas encerra a conversa: ele oferece criar um ticket de suporte. Essa oferta rota para o sub-workflow HelpScout.
O sub-workflow recebe três parâmetros: email, uma flag de função (check_ticket ou create_ticket), e um corpo de mensagem. Se check_ticket, ele consulta HelpScout para conversas existentes desse email e as retorna. Se create_ticket, ele cria uma nova conversa com status "pendente".
A parte mais importante é: O prompt do sistema instrui o agente a incluir a conversa completa em formato de transcrição, não um resumo. O time de suporte recebe um registro completo do que o cliente perguntou, o que o bot disse, e onde ficou preso.
Essa é a parte que times de suporte realmente se importam. Um ticket que diz "cliente teve uma pergunta que o bot não conseguiu responder" é inútil. Um ticket com uma transcrição completa é acionável em 30 segundos.
A Parte Que É Fácil de Perder
Modelos LLM modernos são modelos capazes. Também são, por padrão, ansiosos em ser úteis. Deixado por sua conta, o modelo vai responder perguntas de produtos a partir de seus dados de treinamento em vez de chamar a ferramenta de base de conhecimento primeiro. Para a maioria dos casos de uso, isso é ótimo. Para uma loja vendendo psicodélicos regulamentados, "a partir de dados de treinamento" e "preciso" não são sinônimos.
O prompt do sistema passou por várias iterações e testes para abordar isso. A versão atual inclui uma seção chamada MANDATORY WORKFLOW em letras maiúsculas, uma seção STRICT RULES com instruções explícitas para não responder perguntas da empresa ou produtos sem buscar na base de conhecimento, e uma declaração de que o agente está "falhando em sua função principal" se responder sem consultar a Base de Conhecimento Pinecone primeiro.
Isso não é apenas para mostrar. É uma afirmação de que o modelo deve responder com confiança perguntas sobre dosagem ou uso com informações que estão na página do produto ou no FAQ.
A lição: a chamada da ferramenta de base de conhecimento tem que ser tratada como uma restrição, não uma preferência. LLMs usam seu conhecimento paramétrico por padrão porque é rápido e geralmente suficiente. "Geralmente" não é bom o suficiente quando a pergunta é sobre interações medicamentosas.
A configuração de dois modelos ajuda. O agente principal é executado em GPT-4o. A ferramenta de recuperação de base de conhecimento é executada em GPT-4-turbo, que processa a consulta de armazenamento de vetores e formata os chunks retornados. Essa divisão de custo também cria um limite claro: o modelo caro raciocina e orquestra, e o modelo mais barato faz o processamento de recuperação.
O Loop de Feedback
Qualquer pergunta que o bot não consegue responder é registrada em uma Google Sheet, com o texto exato da pergunta, a resposta do bot, o email do cliente se fornecido, um timestamp, e uma categoria que o modelo atribui (Envio, Produto, Médico, Devoluções, Geral, Outro).
Essa sheet é como a base de conhecimento melhora ao longo do tempo. O time a revisa semanalmente, identifica padrões em perguntas não respondidas, e adiciona novas entradas de FAQ. Essas entradas são re-embedadas e adicionadas ao Pinecone. O próximo cliente que faz a mesma pergunta recebe uma resposta real.
Sem esse loop, a base de conhecimento estagna em seu estado inicial. Você obtém um chatbot que lida com as perguntas que você antecipou e falha em todo o resto. Com ele, o bot melhora mensuravelmente nas perguntas que seus clientes reais estão fazendo.
A arquitetura é o produto
Um chatbot que é preciso sobre questões sensíveis de saúde, busca pedidos WooCommerce ao vivo, cria tickets de suporte com transcrições completas, e registra suas próprias lacunas de conhecimento não é um widget simples. O valor não está na interface do chat — essa é duas linhas de código de embed. O valor está na orquestração: os índices que se mantêm atualizados, os sub-workflows que lidam com cada preocupação isoladamente, e o loop de feedback que diz o que construir a seguir.
Construir um chatbot de suporte para uma loja WooCommerce onde a precisão importa — produtos regulamentados, orientação médica, dados de pedidos específicos do cliente — é exatamente o tipo de problema de IA em produção que assumo. Entre em contato comigo ou leia como funciono.