Se seu modelo "começou a se comportar diferente" do dia pra noite sem mudança de modelo, provavelmente é drift de tokenização. Mesmo tokenizer, entrada semanticamente idêntica, sequências de tokens completamente diferentes. Um exemplo GPT-2 do artigo da MarkTechPost: `" classify"` com espaço antes tokeniza para um único ID, `[36509]`; `"classify"` sem o espaço tokeniza para dois IDs, `[4871, 1958]`. Pro modelo, essas não são a mesma palavra — são entradas diferentes aterrissando em regiões diferentes do espaço de tokens. Seu prompt ser "quase o mesmo" do que o modelo viu durante fine-tuning não é a mesma coisa que ser igual.

O artigo quantifica o modo de falha. Usando o tokenizer do GPT-2 e um classificador fine-tunado, o formato de prompt alinhado-SFT atinge ~83% de accuracy. Tire as quebras de linha e cai para 40-50%. Reescreva a instrução e a sobreposição Jaccard de tokens com o formato de treino cai pra ~50%, empurrando a entrada fora-de-distribuição e afundando a accuracy. O fix proposto é APO (Automated Prompt Optimization): testar cinco-plus variantes de template, pontuar cada uma por sobreposição Jaccard de conjuntos de tokens contra o template SFT original, escalar accuracy de validação por uma penalidade OOD proporcional à sobreposição, e escolher o template vencedor na métrica combinada. A implementação são umas linhas de HuggingFace `AutoTokenizer.encode()` mais comparação de conjuntos.

O padrão maior é que regressões de prompt em produção geralmente não são regressões de modelo — são descompassos no nível do tokenizer entre o que o modelo aprendeu durante instruction tuning e o que sua aplicação está mandando agora. Esse é o tipo de bug que sobrevive a cada teste que você tem, a menos que você esteja explicitamente checando sequências de tokens contra uma distribuição de referência. Também é por isso que "o mesmo prompt" copiado de um Notion pra um editor de código pode degradar silenciosamente — o editor normalizou seu whitespace ou tirou uma quebra de linha final, e agora você está a uma distância diferente dos dados de treino. Modelos RLHF e instruction-tuned são extra sensíveis porque o formato vira parte da representação da tarefa, não só decoração ao redor.

O que fazer segunda: logue sequências de tokens cruas para prompts de produção (não compare strings, compare IDs de token) e dife contra o prompt original que você testou no deploy. Adicione um teste de regressão Jaccard-overlap no seu pipeline CI de prompts. Se você roda fine-tunes, salve a tokenização exata do seu formato de treino e valide entradas de inferência contra isso. Pra devs em modelos de pesos fechados que você não pode retreinar, o movimento prático é o loop APO do artigo: busque empiricamente variantes de prompt que maximizem a sobreposição de tokens com formatos que o modelo claramente já viu. A pergunta "meu prompt tá funcionando?" vira uma pergunta no nível do tokenizer, não no nível da redação.