Como treinei uma IA de suporte com histórico real de atendimento: da conversa bruta ao RAG em produção

Complete pipeline for extracting knowledge from 8,400 raw customer support conversations to build a production-ready RAG (Retrieval-Augmented Generation) AI assistant. The process uses LLMs, embeddings, and a hybrid search system with a reranker, filtering conversations by CSAT score and resolution status to reduce noise without manual annotation. The final knowledge base contains 2,200 structured question-answer pairs, designed to automate responses for approximately 70% of recurring support inquiries.

Esse artigo é a documentação completa do pipeline que construí para extrair conhecimento do histórico real de atendimento de um cliente e transformá-lo em base vetorial para uma IA de suporte em produção. A linha do tempo: 8.400 conversas brutas viraram 2.200 pares de conhecimento na base final. Sem anotação manual. Antes de começar: os conceitos LLM Large Language Model . O modelo de linguagem em si, como Claude, GPT ou Gemini. Ele é poderoso, mas tem dois problemas: não sabe nada sobre o seu negócio específico, e alucina quando não sabe. RAG Retrieval-Augmented Generation . A solução para isso. Antes do LLM responder, você busca o contexto relevante numa base própria e injeta esse contexto no prompt. O modelo deixa de adivinhar e passa a responder a partir de informação real e verificável. Embedding. A peça que faz a busca funcionar. É um vetor, ou seja, uma lista de números no nosso caso, 1.536 deles que representa o "significado" de um texto num espaço matemático. Frases parecidas geram vetores próximos. "Como gerar relatório?" e "Onde vejo o resumo financeiro?" ficam vizinhas no espaço vetorial mesmo sem dividir palavras. Vetor store. O lugar onde esses vetores ficam armazenados de forma que você consegue perguntar "me dá os 10 mais parecidos com esse aqui" em milissegundos. No nosso caso, Postgres com a extensão pgvector . Busca semântica vs full-text. Semântica é via embedding: captura sentido. Full-text é match de palavras: captura termos exatos. Cada uma falha em coisas diferentes. A combinação é o que chamam de busca híbrida . Reranker. Um modelo menor que, depois da busca, reordena os resultados pela relevância real para a query. A busca é boa em achar candidatos. O reranker é bom em decidir a ordem final. O problema concreto Plataforma de atendimento ao cliente customizada Postgres por baixo , meses de histórico de conversas. Duas fontes de conhecimento precisavam alimentar o agente de IA: - Documentação técnica — já processada num pipeline de RAG separado, com chunking hierárquico por seção - Histórico de conversas — o desafio desse artigo O objetivo nunca foi substituir atendentes humanos. Era criar uma primeira camada de resolução automática para as dúvidas recorrentes, que representam cerca de 70% do volume da operação. Visão geral: o pipeline em 5 estágios 1 Coleta + filtro de qualidade ↓ 2 Classificação estruturada com LLM ↓ 3 Geração de embeddings ↓ 4 Deduplicação vetorial greedy clustering ↓ 5 Busca híbrida full-text search com ts rank + semântica + reranker Cada estágio resolve um problema específico que o anterior não resolve. Vou destrinchar um por um. Estágio 1 — Coleta e filtro de qualidade O maior obstáculo de aprender com histórico real é o ruído . Nem toda conversa terminou em resolução. Muitas foram escaladas. Algumas o cliente ficou insatisfeito e nem disse nada. Se você joga tudo na base, ensina o agente a errar do mesmo jeito que o pior atendente do time. A pergunta é: como filtrar qualidade sem precisar anotar manualmente milhares de conversas? A resposta pragmática: CSAT Pontuação de Satisfação do Cliente como proxy de qualidade . Não é perfeito, já que nem todo bom atendimento recebe avaliação, mas é o sinal mais confiável que já está no banco, de graça. Além do CSAT, dois filtros adicionais: - Número mínimo de mensagens: conversas muito curtas raramente contêm resolução real. Mínimo de 4 mensagens. - Status só conversas que a plataforma marcou como resolvidas. resolved : Resultado: de ~8.400 conversas brutas, sobraram ~2.100 qualificadas. Estágio 2 — Classificação estruturada com LLM Essa é a parte central do pipeline. Cada conversa qualificada é enviada para um LLM com um prompt de extração estruturada. O modelo recebe o histórico completo de mensagens e devolve JSON com um ou mais qa pairs . Por que LLM e não regras? Porque um único ticket pode conter múltiplos problemas diferentes. O cliente começa perguntando sobre relatório, no meio reclama de uma cobrança, no fim pergunta sobre integração. Três tópicos, três pares de conhecimento independentes. Regras de regex não resolvem isso de forma confiável. O LLM identifica os tópicos, separa em pares e classifica cada um individualmente. Modelo escolhido: Claude Haiku . Rápido e barato o suficiente para processar 2.100 conversas em batch sem virar projeto orçamentário. A anatomia de um qa pair Cada par tem campos com função muito específica: | Campo | Função | |---|---| question | Pergunta essencial reescrita, sem nome de cliente e sem dados do caso específico | answer | Solução em prosa, anonimizada. Não é transcrição, é síntese do que resolveu | resolution steps | Array de passos ordenados. O agente usa pra guiar o cliente step-by-step | domain | Classificação de alto nível fechada, que define qual setor resolveria | module | Área do produto em snake case livre ex: financeiro app , agenda | intent freetext | Intent em snake case ex: gerar relatorio mensal | resolution actor | Quem resolve: client self service / agent in app / agent backend / external team | user confirmed resolution | O cliente confirmou que foi resolvido? Boolean | confirmation type | explicit / implicit no return / informational only / none | confidence | 0.0 a 1.0. Certeza do LLM na extração. Governa o que entra na base | pii found | Boolean. Havia dados pessoais identificáveis na conversa? | pii audit | Detalhamento do PII encontrado e como foi anonimizado | Um exemplo real anonimizado do output: { "qa pairs": { "question": "Como gerar relatório de entradas separado por centro de custo?", "answer": "Acesse Financeiro Demonstrativo Financeiro. Selecione o período e o centro de custo desejado. O sistema permite filtros por forma de entrada e separação entre recebimentos e pagamentos. Exportação disponível em PDF.", "resolution steps": "Acessar menu Financeiro", "Selecionar Demonstrativo Financeiro", "Configurar filtro de período e centro de custo", "Aplicar filtros adicionais se necessário", "Exportar em PDF" , "domain": "tecnico", "module": "financeiro app", "intent freetext": "gerar relatorio por centro de custo", "topic tags": "relatorio", "financeiro", "centro de custo" , "resolution actor": "client self service", "user confirmed resolution": true, "confirmation type": "explicit", "pii found": false, "pii audit": , "confidence": 0.94 } , "should extract": true, "quality concern": null } O sistema de domínio em dois níveis Essa escolha de arquitetura é deliberada e resolve um problema real. domain é fechado. Só pode assumir valores pré-definidos: tecnico , comercial , assinatura , nfse . Serve pra roteamento e filtro grosso na busca. module é livre em snake case. Captura granularidade do produto. O agente de IA usa para filtrar retrieval por área funcional sem depender de uma taxonomia rígida que precisa ser mantida. O maior erro inicial foi misturar "dúvida sobre o módulo financeiro do app" com "assinatura do serviço". O módulo financeiro do produto é técnico, porque o cliente aprendeu a usar uma feature. Assinatura é sobre o que ele paga pra empresa . Domínios separados, lógicas completamente diferentes, atendentes diferentes. O papel do confidence na qualidade da base O confidence não é decoração. Ele governa o que entra na base final. O LLM atribui confidence baixo quando: a conversa não tinha resolução clara, o cliente saiu sem confirmar, a dúvida era ambígua entre dois domínios, ou havia informação contraditória no histórico. Threshold estabelecido: 0.75 . Pares abaixo disso vão pra fila de revisão manual. Não são descartados automaticamente, mas também não entram direto na base. Distribuição real após classificação: - confidence ≥ 0.90 → ~43% dos pares - 0.75 ≤ confidence < 0.90 → ~38% dos pares - confidence < 0.75 → ~19% fila de revisão ~80% do conhecimento aproveitado com qualidade alta, sem anotação humana. O schema que sustenta o pipeline Todo esse JSON do LLM precisa virar linhas numa tabela. Toda a engenharia dos próximos estágios embeddings, deduplicação, busca híbrida depende de como esse schema é desenhado. Aqui está a tabela de staging que sustenta o pipeline inteiro: CREATE EXTENSION IF NOT EXISTS vector; CREATE SCHEMA IF NOT EXISTS rag sandbox; CREATE TABLE rag sandbox.case knowledge staging staging id BIGSERIAL PRIMARY KEY, source conversation id BIGINT NOT NULL, extracted at TIMESTAMPTZ DEFAULT now , -- Conteúdo extraído do LLM question TEXT NOT NULL, answer TEXT NOT NULL, resolution steps JSONB, -- Classificação domain TEXT NOT NULL CHECK domain IN 'tecnico','comercial','assinatura','nfse' , module TEXT, intent freetext TEXT, topic tags TEXT , resolution actor TEXT CHECK resolution actor IN 'client self service','agent in app', 'agent backend','external team' , -- Sinais de qualidade user confirmed resolution BOOLEAN, confirmation type TEXT, confidence NUMERIC 3,2 CHECK confidence BETWEEN 0 AND 1 , -- Privacidade pii found BOOLEAN DEFAULT false, pii audit JSONB, -- Embeddings preenchidos no estágio 3 embedding input TEXT, embedding vector 1536 , answer embedding vector 1536 , -- Controle de deduplicação preenchido no estágio 4 dedup status TEXT DEFAULT 'pending' CHECK dedup status IN 'pending','canonical','duplicate','unique' , duplicate of BIGINT REFERENCES rag sandbox.case knowledge staging staging id , dup similarity NUMERIC 5,4 , -- Coluna full-text estágio 5 fts tsvector GENERATED ALWAYS AS to tsvector 'portuguese', coalesce question,'' || ' ' || coalesce answer,'' STORED ; -- Índice ANN Approximate Nearest Neighbor para busca semântica CREATE INDEX idx staging embedding ON rag sandbox.case knowledge staging USING hnsw embedding vector cosine ops ; -- Índice GIN para full-text search CREATE INDEX idx staging fts ON rag sandbox.case knowledge staging USING gin fts ; -- Índices de filtro CREATE INDEX idx staging domain ON rag sandbox.case knowledge staging domain ; CREATE INDEX idx staging dedup ON rag sandbox.case knowledge staging dedup status ; Três decisões: O embedding é vector 1536 . Essa dimensão vem do modelo text-embedding-3-small da OpenAI. Se trocar de modelo, a dimensão muda. Não dá pra "só rodar o novo modelo" sem reconstruir a coluna e rebuildar o índice. O índice é HNSW Hierarchical Navigable Small World . É um algoritmo de busca aproximada que sacrifica precisão mínima por velocidade gigante. Com volume maior, HNSW é o que viabiliza retrieval em milissegundos. O fts é uma coluna GENERATED ALWAYS AS. O Postgres gera e mantém atualizado o tsvector automaticamente baseado em question + answer , com stemming em português. Combinado com o índice GIN, é o que faz o full-text search do estágio 5 ser instantâneo. Optamos por ts rank nativo em vez de BM25 por dois motivos: escala atual de ~2k pares não justifica a complexidade adicional, e o ganho marginal de recall não compensa o overhead operacional. A tabela de produção que o agente realmente consulta é uma view filtrada dessa staging: CREATE VIEW rag.case knowledge AS SELECT FROM rag sandbox.case knowledge staging WHERE dedup status IN 'canonical', 'unique' AND confidence = 0.75; Essa separação entre staging e produção é o que permite reprocessar o pipeline reclassificar, recalibrar threshold, regerar embeddings sem mexer no que o agente está consultando em tempo real. Estágio 3 — Geração de embeddings Aqui tem um detalhe sutil que faz diferença grande. O texto que vai para o modelo de embedding não é só o question . É a concatenação de question + intent freetext .Por quê? Porque perguntas reais são genéricas. "Como faço isso?", "Não está funcionando", "Tá dando erro". O embedding dessas frases sozinhas é fraco, porque vetorialmente elas ficam todas amontoadas numa região do espaço. O intent freetext , que o LLM gerou em snake case durante a classificação, ancora a semântica. "como faço isso" combinado com "gerar relatorio por centro de custo" gera um vetor muito mais útil do que só "como faço isso?". O campo answer recebe embedding separado . Isso permite busca bidirecional : pelo lado da pergunta usuário perguntando algo ou pelo lado da solução agente buscando "como resolvo X" . UPDATE rag sandbox.case knowledge staging SET embedding input = question || ' ' || replace intent freetext, ' ', ' ' WHERE confidence = 0.75; -- Após geração via API batch : -- modelo: text-embedding-3-small -- dimensão: 1536 Estágio 4 — Deduplicação vetorial com greedy clustering 2.100 conversas filtradas geraram ~3.400 qa pairs após classificação. Mas muitos eram semanticamente idênticos : a mesma dúvida resolvida por atendentes diferentes, em palavras diferentes, em meses diferentes. Jogar tudo na base cria um problema concreto: a busca retorna 5 versões da mesma resposta ocupando o contexto do LLM. Você desperdiça tokens e dilui a qualidade da resposta final. A solução foi aplicar greedy clustering por distância de cosseno via pgvector . A lógica é simples: - Ordena todos os pares por confidence decrescente - O par com maior confidence vira canonical - Todos os pares com similaridade ≥ threshold viram duplicate , apontando pro canonical - O canonical carrega o melhor conhecimento. Os duplicatas ficam como referência, mas não entram na busca bash DO $$ DECLARE threshold float := 0.92; -- 92% de similaridade = duplicata pair record record; similar count integer; BEGIN FOR pair record IN SELECT staging id, embedding, confidence FROM rag sandbox.case knowledge staging WHERE embedding IS NOT NULL AND dedup status = 'pending' ORDER BY confidence DESC, staging id LOOP -- Se já foi marcado como duplicate em iteração anterior, pula IF SELECT dedup status FROM rag sandbox.case knowledge staging WHERE staging id = pair record.staging id < 'pending' THEN CONTINUE; END IF; -- Marca similares como duplicate desse canonical WITH similares AS UPDATE rag sandbox.case knowledge staging SET dedup status = 'duplicate', duplicate of = pair record.staging id, dup similarity = 1 - embedding <= pair record.embedding WHERE staging id < pair record.staging id AND dedup status = 'pending' AND embedding IS NOT NULL AND embedding <= pair record.embedding < 1 - threshold RETURNING staging id SELECT count INTO similar count FROM similares; -- Vira canonical tem similares ou unique sem similares UPDATE rag sandbox.case knowledge staging SET dedup status = CASE WHEN similar count 0 THEN 'canonical' ELSE 'unique' END WHERE staging id = pair record.staging id; END LOOP; END $$; Vale entender o operador: <= no pgvector é distância de cosseno . Retorna 0 para vetores idênticos e 2 para opostos. 1 - distância te dá a similaridade. O threshold de 0.92 foi calibrado empiricamente. Abaixo disso, pares de fato distintos começavam a ser marcados como duplicata. Ajuste conforme a diversidade do seu domínio. Estágio 5 — Busca híbrida com RRF e reranker A base final ficou com ~2.200 pares: só os marcados como canonical ou unique , com confidence ≥ 0.75. Mas a base é só metade da equação. Como você busca importa tanto quanto o que tem dentro. A arquitetura combina dois métodos complementares: Busca semântica. Boa pra capturar intenção e variação de linguagem. "Como vejo o histórico financeiro?" e "relatório de entradas" têm embeddings próximos, mesmo sem compartilhar palavras. Full-text. Bom pra termos específicos do produto, como nomes de módulos, botões e telas. "Demonstrativo Financeiro" retorna muito melhor no full-text search com ts rank do que na busca semântica. Cada uma falha em coisas diferentes. Sozinhas, deixam buracos. Juntas, se cobrem. Fundindo os rankings com RRF O problema de combinar duas buscas é que os scores estão em escalas incomparáveis. Score de ts rank é uma coisa, score de cosseno é outra. Somar não faz sentido. A solução elegante é o Reciprocal Rank Fusion RRF . Em vez de combinar os scores, você combina as posições no ranking. A fórmula: RRF d = Σ 1 / k + rank i d Onde k é uma constante geralmente 60 e rank i d é a posição do documento d no ranking do sistema i . Documento que aparece no top de ambos os rankings ganha pontuação alta. Documento que só aparece num ranking ganha pontuação média. Documento que não aparece em nenhum, zero. Adaptável a diferentes escalas. Resolve o problema sem hiperparâmetro arbitrário. O reranker como camada final Depois do RRF, ainda tem uma jogada. Uma segunda passagem com um modelo reranker sobre os top-20 do RRF. Reordena pela relevância contextual real considerando a query completa. Por que vale o custo extra? Porque o reranker vê pergunta e candidato juntos, diferente do embedding, que codifica cada um isoladamente. A diferença entre top-5 do RRF e top-5 do reranker era perceptível nas respostas do agente em produção. Vale. Os números finais 8.400 conversas brutas no banco 2.100 qualificadas CSAT + status + tamanho mínimo 3.400 qa pairs extraídos pelo LLM 2.200 pares na base final após confidence + dedup A redução de 35% via clustering não perdeu cobertura . Perdeu redundância. Os 1.200 pares eliminados eram semanticamente cobertos pelos que ficaram. Aprendizados Confidence threshold em 0.75 foi o ponto de equilíbrio. Testamos 0.80 e eliminava conhecimento útil. Testamos 0.70 e ruído real entrava. Esse hiperparâmetro vale o tempo de calibrar, não chute. Busca híbrida + RRF superou semântica pura , especialmente em termos técnicos específicos do produto. Se a sua base tem jargão, nomes próprios ou rótulos de UI, full-text não é opcional. resolution actor virou peça de roteamento, não só metadado. O agente não tenta resolver o que precisa de ação de backend, encaminha direto. Estruturar o conhecimento com esse campo desde a classificação evitou implementar uma camada de orquestração depois. Embedding de question + intent é melhor que question sozinho. Sutil, mas é a diferença entre busca que funciona e busca que parece funcionar nos testes e falha em produção. Se você está construindo algo parecido e tem perguntas ou sugestões sobre alguma decisão específica, me chama e vamos conversar.