Automação de documentação técnica serverless com Amazon Bedrock

Problema

A Techne roda sessões de treinamento e repasse técnico gravadas em vídeo, algumas com mais de três horas. Transformar cada gravação em documentação utilizável (manual de operação, troubleshooting, regras de negócio) era trabalho manual de dias: alguém assistia, transcrevia o que importava e redigia. Não escalava, e o gargalo não era escrever, era extrair com fidelidade o que foi dito sem inventar o que não foi.

Documentação técnica gerada por IA tem um risco específico que a torna inútil quando falha: alucinação. Um comando, um código de erro ou um nome de tabela inventado não é detalhe cosmético, corrompe o material e engana quem segue o procedimento. O problema de arquitetura, então, não era ligar um modelo a uma fila; era construir a rede que separa o que a IA pode divergir do que ela não pode.

Abordagem

Desenhei um pipeline serverless e orientado a eventos. O upload de um vídeo no S3 dispara, via EventBridge, uma máquina de estados no Step Functions, que roda o processamento pesado num container ECS Fargate (2 vCPU, 8 GB) e não deixa nenhum servidor de pé entre as execuções.

A primeira parte é transcrever. Vídeos acima de 3,5 horas são fatiados em blocos, cada bloco vai para o AWS Transcribe com diarização (até 10 falantes, pt-BR) e as transcrições parciais são remontadas com os offsets de tempo corrigidos. Essa etapa é a mais cara e a mais lenta, então ela é idempotente: antes de transcrever, o processador procura no S3 uma transcrição já pronta (ou blocos já transcritos) para aquele job e reaproveita, de modo que uma reexecução depois de uma falha não paga de novo a conta da transcrição.

A segunda parte é onde a fidelidade é decidida. Em vez de pedir “gere um documento” numa única chamada, quebrei a geração em sete estágios encadeados.

Cada estágio faz uma coisa e passa adiante um artefato explícito: limpeza da transcrição com os timestamps preservados, extração do conteúdo técnico em JSON, mapeamento de problema para solução, estruturação do esqueleto, redação do Markdown e, então, o estágio que sustenta a promessa de fidelidade, a auditoria. O orçamento de tokens é distribuído por estágio conforme a necessidade (a redação usa toda a capacidade do modelo; a extração, um quarto dela), o que evita truncar uma seção no meio.

A contenção de alucinação é feita em três camadas, não numa só. A primeira é um system prompt estrito de fundamentação, que proíbe o modelo de fabricar URLs, hashes de commit, códigos de erro, números de versão, comandos ou código que não apareçam na transcrição; se o instrutor clicou num botão, o texto descreve a ação de interface, não inventa um comando de terminal equivalente. A segunda é o estágio 6, um auditor: o rascunho volta ao modelo sob um prompt cético, a temperatura zero, com a transcrição original ao lado, e cada afirmação técnica precisa ter suporte num timestamp da fonte; o que não tem, é removido ou generalizado. A terceira é determinística: um glossário aplicado por regex corrige termos que a transcrição automática sempre erra (nomes de produtos e módulos que ela transforma em quase-homófonos em português), sem depender da interpretação do modelo.

A terminologia oficial vem de uma base de conhecimento por RAG. Documentos de referência ficam num vector store pgvector sobre RDS PostgreSQL, indexados pelo embedding Titan v2 em blocos de 300 tokens com 20% de sobreposição; os estágios de redação e auditoria consultam essa base (recuperação top-5, score mínimo 0,5) para escrever os nomes técnicos na grafia canônica. Escolher RDS single-AZ como vector store, em vez de OpenSearch Serverless, derrubou o custo dessa camada de centenas para dezenas de dólares por mês, aproximadamente 85% mais barato, com folga de performance para o volume de vetores em jogo.

Tecnologia

AWS Step Functions para orquestração; ECS Fargate (2 vCPU, 8 GB) para o processamento; AWS Transcribe com diarização; Amazon Bedrock com Claude Sonnet 4.5 na geração; RAG com Amazon Bedrock Knowledge Base sobre pgvector no RDS PostgreSQL 16 (embeddings Titan v2). DynamoDB rastreia o status de cada execução, SNS notifica a conclusão, e o processador roda em container Python 3.12. Resiliência com retry exponencial (3 tentativas), circuit breaker (abre em 5 falhas, rearma em 5 minutos) e polling de transcrição com teto de 2 horas. Saída em Markdown e DOCX. Custo estimado em torno de um dólar por vídeo de 3 horas.

Resultado

O pipeline transforma uma sessão de vídeo de horas em documentação técnica estruturada em minutos, e a mesma transcrição alimenta sete tipos de documento (troubleshooting, guia operacional, manual de operações, regras de negócio, configuração e migração, guia conceitual, responsabilidades e FAQ) sem transcrever de novo.

O que torna isso usável não é a velocidade, é a fidelidade. As três camadas contra alucinação (prompt de fundamentação, auditor com verificação por timestamp e glossário determinístico) existem justamente porque documentação técnica errada é pior que documentação nenhuma. O ponto de arquitetura não foi plugar um modelo numa fila; foi decidir onde a IA pode divergir (redigir, resumir) e onde ela não pode (nomes, comandos, códigos), e construir a rede que garante essa fronteira.