Um dos meus clientes vende produtos regulamentados no Canadá. A fila de suporte estava cheia das mesmas perguntas: como devo tomar isso, posso tomar junto com meu remédio, onde está meu pedido? Um chatbot parecia óbvio. O que não era óbvio era como construir um que não alucinasse dosagem pra alguém perguntando sobre interação medicamentosa.
Essa restrição, precisão vale mais que conveniência, moldou cada decisão de arquitetura.
A versão curta, pra quem só quer o desenho: três workflows no n8n (agente, consulta no WooCommerce, tickets no HelpScout), dois índices no Pinecone (produtos e base de conhecimento), embeddings da OpenAI, um prompt de sistema que não deixa o modelo responder sem buscar antes, e uma planilha que recolhe tudo que o bot não soube responder. O lado de negócio do mesmo projeto, com os números de tickets, está na página do projeto. O resto deste post é o porquê de cada uma dessas decisões.
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. Se não existir cadastro pra esse e-mail, o workflow retorna "Nenhum usuário encontrado" e o agente responde de acordo.
Essa consulta não é autenticação, e nunca foi pensada pra ser. Qualquer pessoa consegue digitar o e-mail de outra. O que protege os dados do pedido de verdade é que o widget do chat roda dentro da sessão logada da loja e o e-mail precisa bater com uma conta verificada. O sub-workflow do WooCommerce só dispara pra um cliente que já provou quem é pra loja; o e-mail é chave de busca, não senha. Se você for montar isso num chat público e anônimo, resolva identidade antes de ligar a ferramenta de pedidos, não depois.
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. Quando isso foi construído, o agente principal rodava em GPT-4o e a ferramenta de recuperação da base rodava em GPT-4.1-mini, que processava a consulta ao banco vetorial e formatava 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 da recuperação.
De lá pra cá, a geração de respostas migrou pra Claude. Os embeddings continuaram na OpenAI (text-embedding-3-large), os índices continuaram no Pinecone e nenhuma das regras de recuperação acima mudou. Trocar o modelo de geração foi mudar um node no n8n, justamente porque a arquitetura nunca dependeu de qual modelo estava respondendo.
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 veja o trabalho de consultoria RAG.