Desenhando uma plataforma RAG orientada a configuração para suporte ao cliente

O suporte ao cliente é um dos poucos lugares onde RAG e agentes ganham seu pão imediatamente: as perguntas são reais, o conhecimento muda constantemente e uma resposta errada tem um custo. Eu construí uma plataforma RAG agentic de código aberto para automação de suporte, e a escolha de design à qual continuo voltando é que quase tudo deve ser configuração, não código.

Repo: https://github.com/ahmet-ozel/agentic-rag-customer-support

Por que orientado a configuração

Um assistente de suporte nunca está "pronto". Você adiciona um novo produto, uma nova regra de escalonamento, uma nova fonte de dados, um novo tom de voz. Se cada uma dessas mudanças significar editar Python e redistribuir, o sistema apodrece. Portanto, o comportamento do agente, as ferramentas que ele pode chamar, as fontes de dados e as regras de roteamento vivem todas na configuração. Adicionar uma fonte de conhecimento ou uma nova ferramenta é uma edição na configuração, não uma mudança de código.

Isso também torna o sistema mais fácil de entender. Você pode ler um arquivo de configuração e saber o que o agente pode fazer, de onde ele obtém seu conhecimento e como decide o que responder.

As peças

A plataforma conecta alguns componentes por trás de um servidor FastAPI:

• Um LLM como o núcleo de raciocínio
• Servidores MCP como a camada de ferramentas (postgres, qdrant, docling, paddleocr), para que o agente possa consultar um banco de dados, pesquisar em um armazenamento vetorial, analisar documentos e executar OCR através de uma interface de ferramenta uniforme
• Um banco de dados vetorial (Qdrant) para recuperação
• Um pipeline de documentos que ingere e processa a base de conhecimento
• Um roteador de intenções que decide que tipo de solicitação chegou
• Um loop de agente que planeja, chama ferramentas, verifica resultados e responde

O roteador de intenções importa mais do que o modelo

A intuição é enviar tudo para um grande agente e deixá-lo resolver as coisas. Na prática, um roteador de intenções leve na frente do agente faz muito trabalho: uma simples consulta de FAQ não precisa de um agente de múltiplas etapas, e uma pergunta de cobrança precisa de ferramentas diferentes de uma pergunta de como fazer. Roteamento primeiro mantém os custos baixos e a latência previsível, e apenas envia as solicitações genuinamente difíceis para o loop completo do agente.

O loop do agente

Para as solicitações que realmente precisam, o agente executa um loop iterativo de chamada de ferramentas: lê a solicitação, decide qual ferramenta usar (recuperar do armazenamento vetorial, consultar postgres, analisar um documento), avalia se o resultado é suficiente e, ou responde ou dá outro passo. O MCP é o que mantém isso limpo. O agente raciocina sobre qual ferramenta chamar; ele não precisa saber como cada backend funciona.

O que eu faria diferente

A maior lição foi investir na avaliação desde o início. É fácil demonstrar um agente de suporte que responde bem a três perguntas. É difícil saber se uma mudança de configuração o tornou melhor ou pior em cem perguntas reais. Se eu começasse de novo, construiria o sistema de avaliação antes do segundo recurso.

Repo e configuração: https://github.com/ahmet-ozel/agentic-rag-customer-support

Se você construiu automação de suporte com RAG, gostaria de saber como você lida com roteamento e escalonamento para um humano. Onde você traça a linha entre deixar o agente responder e passar para outro?