Metodologia do CertAI: loop fechado

O loop fechado em 4 etapas

Etapa 1: simulado adaptativo de baseline. Você responde entre 30 e 65 questões cobrindo os 4 domínios do CLF-C02 (Cloud Concepts, Security and Compliance, Cloud Technology and Services, Billing). O motor calibra dificuldade conforme acerta ou erra. No fim, você vê score por domínio, não só nota agregada. Saber que tirou 78% em Technology mas 42% em Billing é o ponto de partida real do estudo.

Etapa 2: flashcards SRS criados do erro. Cada questão errada gera um card automaticamente, com a explicação técnica completa, o contexto do domínio fraco, e o link pro material oficial AWS (Exam Guide, FAQ do serviço, documentação relevante). Você não precisa criar deck manualmente. O deck nasce do seu erro real.

Etapa 3: revisão espaçada com intervalos crescentes.Algoritmo SM-2 simplificado (mesmo princípio do Anki). Acertou o card? Próxima revisão em 1 dia, depois 3, 7, 14, 30, 90 dias. Errou? Volta pro início. O efeito prático: você revisa o que está perto de esquecer, não o que já dominou. 15 minutos de revisão diária substituem 2 horas de re-leitura passiva.

Etapa 4: re-teste focado no domínio fraco. Depois de duas ou três rodadas de revisão no domínio que estava ruim, o sistema oferece um mini-simulado de 15 a 20 questões só daquele domínio. Se o score subiu de 42% pra 75%, o flag baixa. Se não subiu, o sistema gera variações adicionais e ajusta a dificuldade.

Diferente de simulado tradicional: erro não é estatística estática. Erro é input pra próxima sessão de estudo. O loop fecha em si mesmo até o domínio sair da lista de risco. O ciclo médio observado em 2026 leva 7 a 10 dias por domínio fraco do baseline ao re-teste validado.

Pipelines de IA

O CertAI usa 5 pipelines de IA, cada um com responsabilidade isolada e validação Zod no output. Modelos: Anthropic Claude Sonnet 4.6 para geração e Haiku 4.5 para revisão e tarefas leves.

• P1, parser de edital. Lê o PDF oficial do AWS Exam Guide via Claude com suporte nativo a PDF, extrai os domínios, pesos (24/30/34/12 para CLF-C02), objetivos de aprendizagem e exemplos, e gera uma taxonomy estruturada que alimenta o resto dos pipelines. Roda offline em script (não em request de usuário).
• P2, gerador de questões. Claude Sonnet 4.6 gera questão + 4 alternativas + explicação por domínio, com prompt engineering específico pro estilo AWS (cenário corporativo, distrator plausível, vocabulário oficial). Validação Zod estrita no output (exatamente 4 alternativas, exatamente 1 correta, explicação entre 80 e 400 palavras, domínio dentro do enum válido).
• P3, flashcards automáticos. Quando o usuário erra uma questão, P3 cria um card SRS a partir da explicação, gera uma variação de pergunta (pra evitar memorização do enunciado literal), e tagueia com o domínio fraco. Card entra na fila de revisão com intervalo inicial de 1 dia.
• P4, critic LLM. Antes da questão chegar ao usuário, P4 (Claude Haiku 4.5) revisa por rubrica de 5 critérios: clareza do enunciado, precisão técnica, ausência de ambiguidade, plausibilidade das alternativas erradas, calibração de dificuldade. Score abaixo do threshold dispara retry no P2 com prompt de correção. Aproximadamente 8 a 12% das questões geradas reprovam no P4 em primeira passada.
• P5, cronograma. Função TypeScript determinística, sem LLM. Input (data do exame, score baseline por domínio, pesos do edital, horas disponíveis por semana), output (plano semanal alocando horas proporcionalmente à fraqueza vezes peso do domínio, com revisão mínima nos domínios fortes). Detalhe da decisão em “Por que o cronograma é determinístico” abaixo.

Validação Zod em todo output de LLM

Todo output de LLM no CertAI passa por schema Zod antes de tocar o banco ou voltar pro usuário. Sem exceção. Modelo nenhum é confiável o suficiente pra dispensar essa camada, nem Claude Sonnet 4.6, nem GPT-4o, nem nenhum outro.

Razão prática: LLM alucina em três eixos previsíveis. Formato(gera 5 alternativas quando o schema pede 4, retorna array dentro de string, omite campo obrigatório). Valor (score 1500 quando o máximo é 1000, domínio “Networking” quando o enum só tem 4 valores válidos, peso negativo). Tipo (string onde devia ser número, objeto onde devia ser array, null onde devia ser obrigatório). Zod pega os três casos no parse e devolve erro estruturado.

Falha de schema não é exceção silenciosa. O sistema loga o output bruto do modelo, monta um prompt de correção (“seu output anterior falhou na validação X, regenere seguindo o schema Y”), e faz retry com o mesmo modelo. Se falha 3 vezes consecutivas, escala pra fallback (modelo diferente ou descarte da geração, dependendo do pipeline).

Em produção, monitor PostHog mostra taxa de retry por pipeline. Hoje (maio 2026) a média fica entre 3 e 5% no P2 (geração de questões), e abaixo de 1% no P4 (critic). Spike acima disso é sinal de drift do modelo ou prompt quebrado, e dispara alerta.

Custo de IA tracked por chamada

Toda chamada a um modelo Anthropic emite um evento PostHog chamadoai_call_completed. Payload do evento inclui: nome do modelo (sonnet-4-6, haiku-4-5), tokens de input, tokens de output, custo em USD calculado pela tabela de preço vigente, pipeline de origem (P2, P3, P4), e ID anônimo do usuário ou job. Nenhum dado pessoal vai no payload.

O motivo é direto: sem essa instrumentação, não dá pra responder perguntas básicas de unit economics. Quanto custa em IA gerar um simulado completo? Quanto custa o ciclo médio de um usuário pagante por mês? Qual pipeline está fora da curva? Sem essa tabela, qualquer decisão de pricing ou otimização é chute.

Custo médio atual (maio 2026): R$ 0,30 por simulado completo de 65 questões (combinação de geração no P2 e revisão no P4). Card SRS individual fica abaixo de R$ 0,02. O custo é repassado em parte via pricing acessível, e em parte absorvido pelo bootstrap.

Plano: expor agregado mensal de custo de IA em página pública/sobre/transparencia (sem timeline definido, depende de volume crítico que torne o número interessante). Por enquanto, o número está visível só pra mim no dashboard interno PostHog.

Spaced Repetition System (SRS)

SRS (Spaced Repetition System) é uma técnica de revisão em intervalos crescentes, fundamentada na curva do esquecimento descrita por Hermann Ebbinghaus em 1885. Ebbinghaus mediu, em si mesmo, a taxa de retenção de sílabas sem sentido ao longo do tempo. Descobriu que a memória decai de forma previsível, e que cada revisão bem-feita reseta a curva e estende o intervalo até a próxima necessidade.

O algoritmo usado no CertAI é uma versão simplificada do SM-2 (mesma família que o Anki, SuperMemo e RemNote). Funcionamento prático: cada card tem um intervalo atual. Acertou com confiança? Intervalo cresce na sequência 1d, 3d, 7d, 14d, 30d, 90d. Acertou com hesitação? Cresce mais devagar. Errou? Intervalo zera e o card volta pro início da fila.

O ganho de tempo é mensurável. Estudante médio que tenta revisar deck de 200 cards “lendo tudo” gasta 90 minutos por sessão e esquece 40% em uma semana. Com SRS, a mesma cobertura sai em 15 a 20 minutos por dia, porque o sistema só mostra o que está perto do limite de esquecimento. Você não desperdiça tempo em card de IAM que já tá automático na cabeça, só nos 12 cards de pricing que ainda estão frágeis.

A técnica é cientificamente validada em domínios variados: estudos com estudantes de medicina (anatomia, farmacologia), aquisição de vocabulário em segunda língua, e treinamento militar. No CertAI, cada card de domínio AWS entra na fila SRS automaticamente depois do primeiro erro do usuário no simulado, sem ação manual.

Limitação honesta: SRS é ótimo pra memorização espaçada (definições, limites de serviço, hierarquia IAM). Não substitui prática hands-on no console AWS pra quem nunca subiu um EC2.

Por que o cronograma é determinístico

Pipeline 5 (geração de cronograma de estudo) é a única peça do CertAI que não usa LLM. É TypeScript puro, função determinística, testada como qualquer outra função de domínio.

Razão técnica: cronograma de estudo é função pura. Input fixo (data do exame, score baseline por domínio, pesos do edital, horas disponíveis por semana, dias da semana preferidos) produz output fixo (plano semanal alocando horas por domínio e por dia). Não há ambiguidade nem criatividade envolvida. Usar LLM nesse caso seria errado em três dimensões.

Primeiro, custo. Cada geração de plano com Sonnet 4.6 custaria entre R$ 0,40 e R$ 0,60. Multiplicado por 5 mil usuários gerando plano recorrente, o número fica relevante. A versão TypeScript custa zero por chamada. Segundo, instabilidade. LLM gera output diferente cada vez, mesmo com temperatura baixa. Usuário regerando o plano veria distribuição diferente sem explicação, o que destrói a confiança na ferramenta. Terceiro, auditabilidade. Quando o plano “está errado” na visão do usuário, eu preciso reproduzir bit a bit o cálculo que gerou aquele output. Com função determinística, eu rodo o teste com o mesmo input e vejo onde está a discrepância. Com LLM, fica arqueologia.

Algoritmo na prática: aloca horas proporcionalmente à fraqueza vezes o peso do domínio no edital, garante mínimo de revisão em domínios fortes (pra não esquecer), respeita as horas disponíveis informadas pelo usuário, e distribui em sessões de no máximo 45 minutos. Quem quiser ler o código, está em packages/scheduler/src/build-plan.ts(público quando o repo abrir).

É open source?

Repositório principal é privado por enquanto. Razão honesta: bootstrap solo precisa de runway, e o motor de geração de questões + os prompts calibrados são o ativo defensável do produto nessa fase.

Considerações pra frente: algumas partes podem virar open source antes do produto inteiro, especialmente schemas Zod compartilhados, taxonomy do edital CLF-C02 já parsed, e o motor SRS, que beneficiariam a comunidade brasileira de cert cloud sem comprometer o produto. Sem timeline definido. Depende da maturidade do produto e da disposição de manter projeto OSS junto com o operacional.