KnowledgeForge: minerando conhecimento no “cemitério” de tickets de TI
Equipes de suporte de TI resolvem milhares de tickets por mês, e cada ticket guarda algo valioso: um sintoma, uma causa raiz e a correção que o engenheiro aplicou. O problema é que esse conhecimento fica trancado no histórico de tickets — o próximo engenheiro que enfrentar o mesmo problema não vai encontrá-lo. O KnowledgeForge, solução publicada no blog da AWS, ataca exatamente essa lacuna usando IA generativa.
Os dois lados do problema
A base de conhecimento tem o problema oposto ao dos tickets: ela cresce, mas cresce bagunçada. Artigos duplicados se acumulam, conteúdo fica desatualizado e a qualidade varia conforme quem escreveu cada artigo. Um engenheiro em busca de resposta atravessa rascunhos quase idênticos — alguns precisos, outros três versões de produto atrás.
O KnowledgeForge trabalha os dois lados da lacuna: mina tickets resolvidos para gerar novos artigos e, ao mesmo tempo, cura a base existente — classificando por tipo, removendo duplicatas, pontuando qualidade e reescrevendo conteúdo fraco. Um gerente de conhecimento revisa e aprova o resultado, então uma pessoa continua sendo dona do que vai ao ar.
A arquitetura em dois subsistemas
A solução é um ciclo fechado com dois subsistemas que se alimentam:
| Estágio | O que acontece |
|---|---|
| Ingestão | Tickets resolvidos e artigos existentes chegam ao Amazon S3, rastreados por um catálogo de dados. |
| Geração | Tickets agrupados viram novos artigos em rascunho no Amazon ECS com AWS Fargate. |
| Curação | Cada artigo é classificado, deduplicado, pontuado e melhorado via AWS Step Functions e Lambda. |
| Revisão humana | Artigos enriquecidos vão para o ServiceNow, e a decisão volta ao DynamoDB. |
| Ciclo fechado | A curação embute vetores de cada artigo no Amazon S3 Vectors, reutilizados na próxima geração. |
Geração com RAG e Claude Sonnet 4.5
Antes de escrever, o sistema se ancora no que já existe: para cada tema, recupera os cinco artigos mais similares daquele cliente no índice de vetores e os passa ao modelo como contexto. Esse Retrieval Augmented Generation (RAG) mantém a terminologia consistente e reduz procedimentos inventados. A geração roda no Anthropic Claude Sonnet 4.5 no Amazon Bedrock, produzindo dois documentos com estrutura fixa: o artigo da base de conhecimento e um documento de análise de causa raiz.
Um detalhe técnico que merece destaque: a geração usa containers (Amazon ECS com Fargate) em vez de funções, porque gerar dois documentos completos pode levar minutos e chega em rajadas. O Fargate escala pelo tamanho da fila e recolhe quando ela esvazia.
Detecção de duplicatas por significado, não por palavra
Achar duplicatas por correspondência de palavras-chave falha: dois artigos descrevem a mesma correção com palavras diferentes, ou um engenheiro copia um artigo, muda duas linhas e salva como novo. O KnowledgeForge usa o Amazon S3 Vectors para guardar embeddings de 1.024 dimensões (Amazon Titan Text Embeddings V2) diretamente no S3, evitando um banco vetorial separado. O mesmo índice que alimenta a recuperação também serve como detector de duplicatas: qualquer artigo dentro de uma distância de cosseno apertada (0,05) conta como duplicata.
Orquestração resiliente com Step Functions
A curação roda em lotes via AWS Step Functions com um mapa distribuído em duas fases. Duas escolhas chamam atenção: o processador usa STANDARD (não EXPRESS) porque as chamadas ao Bedrock excedem o limite de 5 minutos; e o conteúdo dos artigos passa como ponteiro no S3, não como payload inline, para respeitar o limite de 256 KB de estado. A deduplicação é sequencial dentro de cada lote, enquanto pontuação e melhoria rodam em paralelo. Uma fila FIFO garante ordenação entre execuções, e um circuito de proteção (dead-letter queue + circuit breaker) impede que um lote ruim derrube toda a execução.
Por que isso importa
O padrão do KnowledgeForge — gerar, curar, deduplicar e revisar em ciclo fechado, com um humano no controle final — é uma das aplicações mais práticas de IA generativa para operações de TI. Para empresas brasileiras que operam ITSM com volumes crescentes de tickets, o caso oferece um roteiro concreto: comece pelo agrupamento de tickets, ancore a geração em vetores do que já existe e mantenha a revisão humana como etapa obrigatória antes de qualquer publicação.
A lição central é que IA generativa em conhecimento corporativo não é “escrever tudo automaticamente” — é fechar o ciclo entre o que os engenheiros sabem e o que fica documentado, sem deixar a qualidade ao acaso.
Descubra mais sobre noticiAI
Assine para receber nossas notícias mais recentes por e-mail.



