{"slug": "como-treinei-uma-ia-de-suporte-com-historico-real-de-atendimento-da-conversa-ao", "title": "Como treinei uma IA de suporte com histórico real de atendimento: da conversa bruta ao RAG em produção", "summary": "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.", "body_md": "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.\n\nA linha do tempo: 8.400 conversas brutas viraram 2.200 pares de conhecimento na base final. Sem anotação manual.\n\n## Antes de começar: os conceitos\n\n**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.\n\n**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.\n\n**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.\n\n**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`\n\n.\n\n**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**.\n\n**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.\n\n## O problema concreto\n\nPlataforma de atendimento ao cliente customizada (Postgres por baixo), meses de histórico de conversas. Duas fontes de conhecimento precisavam alimentar o agente de IA:\n\n- *\n*Documentação técnica **— já processada num pipeline de RAG separado, com chunking hierárquico por seção -\n**Histórico de conversas**— o desafio desse artigo\n\nO 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.\n\n## Visão geral: o pipeline em 5 estágios\n\n```\n[1] Coleta + filtro de qualidade\n        ↓\n[2] Classificação estruturada com LLM\n        ↓\n[3] Geração de embeddings\n        ↓\n[4] Deduplicação vetorial (greedy clustering)\n        ↓\n[5] Busca híbrida (full-text search com ts_rank + semântica) + reranker\n```\n\nCada estágio resolve um problema específico que o anterior não resolve. Vou destrinchar um por um.\n\n## Estágio 1 — Coleta e filtro de qualidade\n\nO 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.\n\nA pergunta é: como filtrar qualidade sem precisar anotar manualmente milhares de conversas?\n\nA 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.\n\nAlém do CSAT, dois filtros adicionais:\n\n-\n**Número mínimo de mensagens:** conversas muito curtas raramente contêm resolução real. Mínimo de 4 mensagens. -\n**Status** só conversas que a plataforma marcou como resolvidas.`resolved`\n\n:\n\nResultado: de ~8.400 conversas brutas, sobraram ~2.100 qualificadas.\n\n## Estágio 2 — Classificação estruturada com LLM\n\nEssa é 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`\n\n.\n\n**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.\n\nModelo escolhido: **Claude Haiku**. Rápido e barato o suficiente para processar 2.100 conversas em batch sem virar projeto orçamentário.\n\n### A anatomia de um qa_pair\n\nCada par tem campos com função muito específica:\n\n| Campo | Função |\n|---|---|\n`question` |\nPergunta essencial reescrita, sem nome de cliente e sem dados do caso específico |\n`answer` |\nSolução em prosa, anonimizada. Não é transcrição, é síntese do que resolveu |\n`resolution_steps` |\nArray de passos ordenados. O agente usa pra guiar o cliente step-by-step |\n`domain` |\nClassificação de alto nível fechada, que define qual setor resolveria |\n`module` |\nÁrea do produto em snake_case livre (ex: `financeiro_app` , `agenda` ) |\n`intent_freetext` |\nIntent em snake_case (ex: `gerar_relatorio_mensal` ) |\n`resolution_actor` |\nQuem resolve: `client_self_service` / `agent_in_app` / `agent_backend` / `external_team`\n|\n`user_confirmed_resolution` |\nO cliente confirmou que foi resolvido? Boolean |\n`confirmation_type` |\n`explicit` / `implicit_no_return` / `informational_only` / `none`\n|\n`confidence` |\n0.0 a 1.0. Certeza do LLM na extração. Governa o que entra na base |\n`pii_found` |\nBoolean. Havia dados pessoais identificáveis na conversa? |\n`pii_audit` |\nDetalhamento do PII encontrado e como foi anonimizado |\n\nUm exemplo real (anonimizado) do output:\n\n```\n{\n  \"qa_pairs\": [\n    {\n      \"question\": \"Como gerar relatório de entradas separado por centro de custo?\",\n      \"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.\",\n      \"resolution_steps\": [\n        \"Acessar menu Financeiro\",\n        \"Selecionar Demonstrativo Financeiro\",\n        \"Configurar filtro de período e centro de custo\",\n        \"Aplicar filtros adicionais se necessário\",\n        \"Exportar em PDF\"\n      ],\n      \"domain\": \"tecnico\",\n      \"module\": \"financeiro_app\",\n      \"intent_freetext\": \"gerar_relatorio_por_centro_de_custo\",\n      \"topic_tags\": [\"relatorio\", \"financeiro\", \"centro_de_custo\"],\n      \"resolution_actor\": \"client_self_service\",\n      \"user_confirmed_resolution\": true,\n      \"confirmation_type\": \"explicit\",\n      \"pii_found\": false,\n      \"pii_audit\": [],\n      \"confidence\": 0.94\n    }\n  ],\n  \"should_extract\": true,\n  \"quality_concern\": null\n}\n```\n\n### O sistema de domínio em dois níveis\n\nEssa escolha de arquitetura é deliberada e resolve um problema real.\n\n** domain é fechado.** Só pode assumir valores pré-definidos:\n\n`tecnico`\n\n, `comercial`\n\n, `assinatura`\n\n, `nfse`\n\n. 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.\n\nO 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.\n\n### O papel do confidence na qualidade da base\n\nO `confidence`\n\nnão é decoração. Ele governa o que entra na base final.\n\nO 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.\n\nThreshold 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.\n\nDistribuição real após classificação:\n\n-\n`confidence ≥ 0.90`\n\n→**~43%** dos pares -\n`0.75 ≤ confidence < 0.90`\n\n→**~38%** dos pares -\n`confidence < 0.75`\n\n→**~19%**(fila de revisão)\n\n~80% do conhecimento aproveitado com qualidade alta, sem anotação humana.\n\n### O schema que sustenta o pipeline\n\nTodo 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:\n\n```\nCREATE EXTENSION IF NOT EXISTS vector;\n\nCREATE SCHEMA IF NOT EXISTS rag_sandbox;\n\nCREATE TABLE rag_sandbox.case_knowledge_staging (\n    staging_id                BIGSERIAL PRIMARY KEY,\n    source_conversation_id    BIGINT NOT NULL,\n    extracted_at              TIMESTAMPTZ DEFAULT now(),\n\n    -- Conteúdo extraído do LLM\n    question                  TEXT NOT NULL,\n    answer                    TEXT NOT NULL,\n    resolution_steps          JSONB,\n\n    -- Classificação\n    domain                    TEXT NOT NULL CHECK (\n                                domain IN ('tecnico','comercial','assinatura','nfse')\n                              ),\n    module                    TEXT,\n    intent_freetext           TEXT,\n    topic_tags                TEXT[],\n    resolution_actor          TEXT CHECK (\n                                resolution_actor IN (\n                                  'client_self_service','agent_in_app',\n                                  'agent_backend','external_team'\n                                )\n                              ),\n\n    -- Sinais de qualidade\n    user_confirmed_resolution BOOLEAN,\n    confirmation_type         TEXT,\n    confidence                NUMERIC(3,2) CHECK (confidence BETWEEN 0 AND 1),\n\n    -- Privacidade\n    pii_found                 BOOLEAN DEFAULT false,\n    pii_audit                 JSONB,\n\n    -- Embeddings (preenchidos no estágio 3)\n    embedding_input           TEXT,\n    embedding                 vector(1536),\n    answer_embedding          vector(1536),\n\n    -- Controle de deduplicação (preenchido no estágio 4)\n    dedup_status              TEXT DEFAULT 'pending' CHECK (\n                                dedup_status IN ('pending','canonical','duplicate','unique')\n                              ),\n    duplicate_of              BIGINT REFERENCES rag_sandbox.case_knowledge_staging(staging_id),\n    dup_similarity            NUMERIC(5,4),\n\n    -- Coluna full-text (estágio 5)\n    fts                       tsvector GENERATED ALWAYS AS (\n                                to_tsvector(\n                                  'portuguese',\n                                  coalesce(question,'') || ' ' || coalesce(answer,'')\n                                )\n                              ) STORED\n);\n\n-- Índice ANN (Approximate Nearest Neighbor) para busca semântica\nCREATE INDEX idx_staging_embedding\n    ON rag_sandbox.case_knowledge_staging\n    USING hnsw (embedding vector_cosine_ops);\n\n-- Índice GIN para full-text search\nCREATE INDEX idx_staging_fts\n    ON rag_sandbox.case_knowledge_staging USING gin (fts);\n\n-- Índices de filtro\nCREATE INDEX idx_staging_domain ON rag_sandbox.case_knowledge_staging (domain);\nCREATE INDEX idx_staging_dedup  ON rag_sandbox.case_knowledge_staging (dedup_status);\n```\n\nTrês decisões:\n\n**O embedding é vector(1536).** Essa dimensão vem do modelo\n\n`text-embedding-3-small`\n\nda 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.\n\n**O fts é uma coluna GENERATED ALWAYS AS.** O Postgres gera e mantém atualizado o\n\n`tsvector`\n\nautomaticamente baseado em `question + answer`\n\n, 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.\n\nA tabela de produção (que o agente realmente consulta) é uma view filtrada dessa staging:\n\n```\nCREATE VIEW rag.case_knowledge AS\nSELECT *\nFROM rag_sandbox.case_knowledge_staging\nWHERE dedup_status IN ('canonical', 'unique')\n  AND confidence >= 0.75;\n```\n\nEssa 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.\n\n## Estágio 3 — Geração de embeddings\n\nAqui tem um detalhe sutil que faz diferença grande.\n\nO texto que vai para o modelo de embedding **não é só o question**. É a concatenação de\n\n`question`\n\n+ `intent_freetext`\n\n.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.\n\nO `intent_freetext`\n\n, 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?\".\n\nO campo `answer`\n\nrecebe 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\").\n\n```\nUPDATE rag_sandbox.case_knowledge_staging\nSET embedding_input = question || ' ' || replace(intent_freetext, '_', ' ')\nWHERE confidence >= 0.75;\n\n-- Após geração via API (batch):\n-- modelo: text-embedding-3-small\n-- dimensão: 1536\n```\n\n## Estágio 4 — Deduplicação vetorial com greedy clustering\n\n2.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.\n\nJogar 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.\n\nA solução foi aplicar **greedy clustering por distância de cosseno** via `pgvector`\n\n. A lógica é simples:\n\n- Ordena todos os pares por\n`confidence`\n\ndecrescente - O par com maior confidence vira\n`canonical`\n\n- Todos os pares com similaridade ≥ threshold viram\n`duplicate`\n\n, apontando pro canonical - O canonical carrega o melhor conhecimento. Os duplicatas ficam como referência, mas não entram na busca\n\n``` bash\nDO $$\nDECLARE\n  threshold float := 0.92;  -- 92% de similaridade = duplicata\n  pair_record record;\n  similar_count integer;\nBEGIN\n  FOR pair_record IN\n    SELECT staging_id, embedding, confidence\n    FROM rag_sandbox.case_knowledge_staging\n    WHERE embedding IS NOT NULL\n      AND dedup_status = 'pending'\n    ORDER BY confidence DESC, staging_id\n  LOOP\n    -- Se já foi marcado como duplicate em iteração anterior, pula\n    IF (SELECT dedup_status FROM rag_sandbox.case_knowledge_staging\n        WHERE staging_id = pair_record.staging_id) <> 'pending' THEN\n      CONTINUE;\n    END IF;\n\n    -- Marca similares como duplicate desse canonical\n    WITH similares AS (\n      UPDATE rag_sandbox.case_knowledge_staging\n      SET dedup_status   = 'duplicate',\n          duplicate_of   = pair_record.staging_id,\n          dup_similarity = 1 - (embedding <=> pair_record.embedding)\n      WHERE staging_id <> pair_record.staging_id\n        AND dedup_status = 'pending'\n        AND embedding IS NOT NULL\n        AND (embedding <=> pair_record.embedding) < (1 - threshold)\n      RETURNING staging_id\n    )\n    SELECT count(*) INTO similar_count FROM similares;\n\n    -- Vira canonical (tem similares) ou unique (sem similares)\n    UPDATE rag_sandbox.case_knowledge_staging\n    SET dedup_status = CASE\n      WHEN similar_count > 0 THEN 'canonical'\n      ELSE 'unique'\n    END\n    WHERE staging_id = pair_record.staging_id;\n  END LOOP;\nEND $$;\n```\n\nVale entender o operador: `<=>`\n\nno `pgvector`\n\né **distância de cosseno**. Retorna 0 para vetores idênticos e 2 para opostos. `(1 - distância)`\n\nte 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.\n\n## Estágio 5 — Busca híbrida com RRF e reranker\n\nA base final ficou com ~2.200 pares: só os marcados como `canonical`\n\nou `unique`\n\n, com confidence ≥ 0.75. Mas a base é só metade da equação. **Como você busca** importa tanto quanto o que tem dentro.\n\nA arquitetura combina dois métodos complementares:\n\n**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.\n\n**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.\n\nCada uma falha em coisas diferentes. Sozinhas, deixam buracos. Juntas, se cobrem.\n\n### Fundindo os rankings com RRF\n\nO 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.\n\nA solução elegante é o **Reciprocal Rank Fusion (RRF)**. Em vez de combinar os scores, você combina as **posições** no ranking. A fórmula:\n\n```\nRRF(d) = Σ  1 / (k + rank_i(d))\n```\n\nOnde `k`\n\né uma constante (geralmente 60) e `rank_i(d)`\n\né a posição do documento `d`\n\nno ranking do sistema `i`\n\n. 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.\n\nAdaptável a diferentes escalas. Resolve o problema sem hiperparâmetro arbitrário.\n\n### O reranker como camada final\n\nDepois 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.\n\nPor 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.\n\n## Os números finais\n\n```\n8.400  conversas brutas no banco\n2.100  qualificadas (CSAT + status + tamanho mínimo)\n3.400  qa_pairs extraídos pelo LLM\n2.200  pares na base final (após confidence + dedup)\n```\n\nA redução de 35% via clustering **não perdeu cobertura**. Perdeu redundância. Os 1.200 pares eliminados eram semanticamente cobertos pelos que ficaram.\n\n## Aprendizados\n\n**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.\n\n**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.\n\n** 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.\n\n**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.\n\nSe você está construindo algo parecido e tem perguntas ou sugestões sobre alguma decisão específica, me chama e vamos conversar.", "url": "https://wpnews.pro/news/como-treinei-uma-ia-de-suporte-com-historico-real-de-atendimento-da-conversa-ao", "canonical_source": "https://dev.to/gaabrielbrocco/como-treinei-uma-ia-de-suporte-com-historico-real-de-atendimento-da-conversa-bruta-ao-rag-em-2i1l", "published_at": "2026-05-21 22:49:36+00:00", "updated_at": "2026-05-21 23:33:52.634390+00:00", "lang": "en", "topics": ["artificial-intelligence", "machine-learning", "large-language-models", "data", "enterprise-software"], "entities": ["Claude", "GPT", "Gemini", "Postgres", "pgvector"], "alternates": {"html": "https://wpnews.pro/news/como-treinei-uma-ia-de-suporte-com-historico-real-de-atendimento-da-conversa-ao", "markdown": "https://wpnews.pro/news/como-treinei-uma-ia-de-suporte-com-historico-real-de-atendimento-da-conversa-ao.md", "text": "https://wpnews.pro/news/como-treinei-uma-ia-de-suporte-com-historico-real-de-atendimento-da-conversa-ao.txt", "jsonld": "https://wpnews.pro/news/como-treinei-uma-ia-de-suporte-com-historico-real-de-atendimento-da-conversa-ao.jsonld"}}