O problema: conhecimento preso no histórico de tickets
Equipes de suporte de TI resolvem milhares de chamados por mês. Cada ticket fechado carrega algo valioso: o sintoma relatado, a causa raiz identificada e a correção aplicada pelo engenheiro. O problema é que esse conhecimento fica preso no histórico do ticket — e o próximo profissional que enfrentar o mesmo problema provavelmente não vai encontrá-lo.
A base de conhecimento existente tem o problema inverso: ela cresce, mas cresce de forma desorganizada. Artigos duplicados se acumulam, conteúdos ficam desatualizados e a qualidade varia conforme quem escreveu e quando. Um engenheiro buscando uma resposta precisa vasculhar rascunhos quase idênticos, alguns precisos e outros defasados por várias versões do produto.
Foi para atacar esses dois lados do problema que a AWS desenvolveu o KnowledgeForge: uma solução que minera tickets resolvidos para gerar novos artigos e, ao mesmo tempo, cura a base existente — classificando, desduplicando, pontuando qualidade e reescrevendo conteúdo fraco. Um gestor de conhecimento revisa e aprova o resultado antes de qualquer publicação.
Os blocos de construção AWS por trás da solução
A arquitetura do KnowledgeForge apoia-se em três serviços principais: Amazon Bedrock para geração e melhoria de conteúdo, Amazon S3 Vectors para detecção de duplicatas e AWS Step Functions para orquestração. Os padrões aplicados aqui são reutilizáveis em qualquer pipeline de processamento de documentos em larga escala com IA generativa.
O ciclo fechado de ciclo de vida da base de conhecimento
O KnowledgeForge opera em dois subsistemas que se alimentam mutuamente. A geração transforma clusters de tickets em novos artigos de rascunho. Quando um grupo de tickets relacionados descreve o mesmo problema, o sistema escreve um artigo para a base de conhecimento e um documento de análise de causa raiz a partir desse cluster. A curadoria então leva cada artigo — tanto os recém-gerados quanto os já existentes — por quatro etapas: classificação por tipo, verificação de duplicatas, pontuação de qualidade e melhoria do conteúdo fraco.
O ciclo se fecha porque a curadoria armazena um vetor para cada artigo, e a geração lê esses vetores antes de escrever qualquer coisa nova. Em alto nível, um artigo percorre cinco estágios:
- Ingestão — Tickets resolvidos e artigos existentes chegam ao Amazon S3, rastreados por um catálogo de dados.
- Geração — Clusters de tickets se tornam novos artigos de rascunho no Amazon Elastic Container Service (Amazon ECS) com AWS Fargate.
- Curadoria — Cada artigo é classificado, desduplicado, pontuado e melhorado por um fluxo do AWS Step Functions em AWS Lambda.
- Revisão humana — Artigos enriquecidos vão ao ServiceNow para aprovação do gestor de conhecimento, e a decisão é gravada no Amazon DynamoDB.
- Ciclo fechado — A curadoria incorpora cada artigo ao índice Amazon S3 Vectors, e a geração reutiliza esses vetores na próxima execução.
Gerando artigos a partir de clusters de incidentes
A geração começa com um cluster de tickets que compartilham um tema. Um processo upstream agrupa incidentes resolvidos pelo problema que descrevem e deposita o resultado em um bucket do Amazon S3 como arquivo JSON, com escopo por cliente. Cada tema traz palavras-chave, escopo do artigo e uma amostra de descrições e notas de trabalho dos tickets.
Antes de escrever, o sistema se ancora no que já existe. Para cada tema, ele recupera os cinco artigos existentes mais similares do índice Amazon S3 Vectors daquele cliente e os passa ao modelo como contexto de referência. Essa abordagem de Geração Aumentada por Recuperação (RAG) mantém a terminologia consistente e reduz procedimentos inventados.
A geração roda no Anthropic Claude Sonnet 4.5 via Amazon Bedrock. Para cada tema, o modelo produz dois documentos com estrutura fixa:
- Artigo da base de conhecimento: Título e resumo, sintomas, causa raiz, passos de resolução, prevenção e tópicos relacionados.
- Documento de análise de causa raiz: Resumo executivo, descrição do problema, impacto ao cliente, análise dos cinco porquês, solução de contorno e resolução, ações corretivas e preventivas, linha do tempo dos eventos-chave e código de causa.
O pipeline usa streaming de resposta do Amazon Bedrock para que o container monte cada documento conforme os tokens chegam, sem esperar pela resposta completa.
Por que containers em vez de funções
A geração roda no Amazon ECS com AWS Fargate por causa do perfil da carga de trabalho. Gerar dois documentos completos para um tema pode levar vários minutos, e um arquivo com muitos temas pode manter uma unidade de trabalho rodando por bastante tempo. A carga também chega em rajadas — períodos tranquilos seguidos de grandes lotes de uma vez. Um serviço de containers de longa duração que escala a contagem de tarefas conforme a profundidade da fila, e reduz quando a fila esvazia, se encaixa bem nesse padrão.
Detectando artigos duplicados com Amazon S3 Vectors
Duplicatas aparecem de várias formas: dois artigos descrevem a mesma correção com palavras diferentes, um artigo mais novo substitui um mais antigo, ou um engenheiro copia um artigo, muda duas linhas e salva como novo. A correspondência por palavras-chave não captura essas variações, então o pipeline compara por significado.
Cada artigo recebe um embedding de 1.024 dimensões gerado pelo Amazon Titan Text Embeddings V2, armazenado em um índice Amazon S3 Vectors por cliente. Um novo artigo é incorporado, o índice é consultado pelos vetores mais próximos, e qualquer resultado dentro de um limiar de distância cosseno estreito é considerado duplicata. O sistema começa com distância cosseno de 0,05 (similaridade de 0,95 ou mais) e um top-K de 5, ajustado por amostragem de pares sinalizados.
Quando o sistema encontra um par duplicado, mantém o artigo mais recente e aposenta o desatualizado. A versão mais nova e precisa vence — que é exatamente o comportamento que um engenheiro de suporte espera. Para detalhes sobre o Amazon S3 Vectors, consulte o Guia do Usuário do Amazon S3.
Reutilizar o índice dessa forma também ajuda em reexecuções: embeddings custam uma chamada ao modelo para serem produzidos. Uma reexecução lê o vetor armazenado em vez de recalculá-lo, economizando tempo e gasto com Amazon Bedrock quando um lote precisa rodar novamente.
Orquestrando a curadoria em escala com AWS Step Functions
A curadoria processa lotes de artigos que precisam de orquestração para distribuir o trabalho entre workers e se recuperar de falhas. O AWS Step Functions oferece isso com um mapa distribuído em duas fases, gerenciando o estado do fluxo, aplicando retentativas e tratamento de erros, e distribuindo o trabalho sem código de coordenação customizado. Para entender como o mapa distribuído funciona, consulte o Guia do Desenvolvedor do AWS Step Functions.
Um agendamento diário no Amazon EventBridge inicia a execução. Uma função AWS Lambda encontra clientes com artigos novos ou alterados, agrupa as mudanças em lotes e coloca cada lote em uma fila Primeiro a Entrar, Primeiro a Sair (FIFO) do Amazon Simple Queue Service (Amazon SQS). A fila FIFO ordena lotes por cliente entre execuções, usando o ID do cliente como chave do grupo de mensagens, de modo que clientes diferentes ainda rodem em paralelo.
A máquina de estados roda em duas fases, cada uma como mapa distribuído para que os artigos de um lote sejam processados de forma concorrente:
- Fase 1 — Classificar e incorporar: Cada artigo é classificado por tipo e recebe um embedding vetorial.
- Fase 2 — Desduplicar, pontuar e melhorar: O pipeline encontra duplicatas, pontua qualidade e melhora conteúdo abaixo do limiar.
Passando ponteiros, não payloads
Uma execução do Step Functions carrega estado entre etapas, com limite de 256 KB. Artigos da base de conhecimento com corpo HTML completo ultrapassam esse limite rapidamente. Em vez de passar o conteúdo do artigo pelo estado da máquina, o sistema escreve o lote no Amazon S3 e passa apenas a localização pelo fluxo. Cada worker do mapa lê o que precisa diretamente do Amazon S3, mantendo o payload de estado pequeno independentemente do tamanho dos artigos.
Recuperando-se de falhas
Dois mecanismos impedem que um lote com problema derrube toda a execução:
- Fila de mensagens mortas (DLQ): Um lote que falha repetidamente é separado para investigação em vez de bloquear a fila atrás dele.
- Circuit breaker (melhor esforço): Após três falhas consecutivas, o dispatcher para de iniciar novos lotes e redefine os artigos afetados ao estado inicial. O contador de falhas vive na memória de uma função Lambda aquecida, portanto não é compartilhado entre containers concorrentes e é reiniciado quando um novo job começa.
Tornando as chamadas ao Amazon Bedrock confiáveis em escala
Três controles mantêm a geração previsível sob carga:
- Timeout de tempo de parede: Um limite rígido em cada execução para que uma resposta lenta não mantenha um worker aberto indefinidamente.
- Retentativa automática com backoff: O cliente Amazon Bedrock roda em modo adaptativo, retentando automaticamente ao encontrar throttling, com backoff exponencial em chamadas de melhoria de conteúdo mais longas.
- Fallback de guardrail: Um guardrail do Amazon Bedrock filtra conteúdo indesejado na saída do modelo. Se o guardrail for limitado por throttling, o pipeline processa o artigo sem ele e registra um aviso, mantendo o fluxo durante picos de carga.
Um quarto controle trata saídas truncadas. Respostas de melhoria de conteúdo têm um orçamento de tokens, e um artigo longo pode atingi-lo, deixando a resposta JSON cortada. O sistema detecta o sinal de “parado no limite de tokens” e retenta com o dobro do orçamento, até o teto do modelo.
Pontuando qualidade antes e depois da melhoria
Nem todo artigo precisa de melhoria, e a melhoria nem sempre ajuda. Uma pontuação de qualidade decide. Cada artigo é avaliado em dez dimensões ponderadas, da maior para a menor peso:
- Completude
- Acionabilidade
- Estrutura
- Coerência
- Legibilidade
- Valor para autoatendimento
- Atualidade
- Prontidão para automação
- Gramática
- Segurança
O total ponderado produz uma pontuação única, e um limiar configurável decide se o artigo passa como está ou vai para melhoria. Artigos abaixo do limiar passam por melhoria de conteúdo, também via Amazon Bedrock.
Há um desafio prático aqui: um modelo pedido para melhorar prosa frequentemente também altera tags de imagem e hiperlinks, quebrando-os. Placeholders resolvem isso. Antes da melhoria, o sistema troca cada imagem e link por um token numerado, melhora a prosa ao redor desses tokens e restaura a mídia real depois. O modelo nunca vê a marcação bruta, então títulos e estrutura sobrevivem intactos.
Após a melhoria, o artigo é pontuado novamente. A nova versão só é mantida se sua pontuação superar a original. Caso contrário, o original prevalece. Essa verificação antes e depois permite melhorar conteúdo automaticamente sem silenciosamente piorar a biblioteca.
Isolamento por cliente em infraestrutura compartilhada
O sistema atende muitos clientes em infraestrutura compartilhada, e uma base de conhecimento é exatamente o tipo de dado que os clientes esperam mantido separado. O isolamento é projetado desde o início: cada cliente recebe sua própria cópia de tudo que toca seu conteúdo:
- Um perfil de configuração
- Um índice Amazon S3 Vectors
- Um conjunto de prompts de modelo
- Um guardrail do Amazon Bedrock
- Uma chave de criptografia do AWS KMS
Como esses recursos são por cliente, os dados de cada um ficam dentro de seu próprio limite. A verificação de duplicatas roda apenas contra o índice daquele cliente, a melhoria de conteúdo usa os prompts daquele cliente, e os dados são criptografados sob a chave daquele cliente. Não existe pool compartilhado onde artigos de um cliente possam aparecer nos resultados de outro.
Resultados e lições aprendidas
Como cada cliente flui por seu próprio grupo de mensagens FIFO no Amazon SQS, adicionar um cliente adiciona um fluxo paralelo de trabalho em vez de desacelerar os demais. A vazão real depende do tamanho dos artigos, da latência do modelo e das cotas do Amazon Bedrock de cada conta.
Quatro lições se destacam na experiência de construção da solução:
- Reutilizar o índice vetorial como detector de duplicatas transformou um problema difícil em uma consulta de vizinho mais próximo.
- Passar um ponteiro do Amazon S3 pelo Step Functions em vez do corpo do artigo eliminou uma classe inteira de falhas por tamanho de estado.
- Pontuar qualidade nos dois lados da melhoria tornou seguro rodar o processo automaticamente.
- Tratar o throttling do guardrail como aviso manteve o pipeline saudável durante picos de carga.
O ponto mais amplo é o próprio ciclo fechado: conteúdo gerado alimenta a curadoria, e a curadoria fundamenta a próxima rodada de geração, de modo que a base de conhecimento melhora conforme o sistema roda.
Como começar
Para construir um pipeline similar, a AWS sugere os seguintes passos:
- Crie um índice vetorial usando a documentação do Amazon S3 Vectors.
- Incorpore uma amostra dos seus próprios artigos e carregue os vetores.
- Execute a consulta de vizinho mais próximo para sinalizar duplicatas.
- Adicione o mapa distribuído do AWS Step Functions para processar artigos em lotes.
- Aplique a porta de qualidade pontuação-melhoria-repontuação.
O código completo está disponível no repositório aws-samples/sample-knowledgeforge no GitHub. Para aprofundamento, consulte o Guia do Usuário do Amazon Bedrock, o Guia do Desenvolvedor do AWS Step Functions e o Guia do Usuário do Amazon S3.
Fonte
KnowledgeForge: mining gold from the ITSM ticket graveyard (https://aws.amazon.com/blogs/machine-learning/knowledgeforge-mining-gold-from-the-itsm-ticket-graveyard/)
Leave a Reply