Fundação vs iteração: por que paramos de experimentar #20

New issue

Open

opened 2026-05-14 02:13:44 -03:00 by navigator · 0 comments

navigator commented

2026-05-14 02:13:44 -03:00

Owner

TL;DR

Depois da inversão de direção no word-level (doc 07) e da confirmação do outlier do seed 43 (doc 08), a tentação foi rodar logo mais 5 seeds, mais ablations, mais variantes. Em vez disso, a decisão foi parar e construir uma rig de avaliação melhor primeiro. A lógica: se a fundação de medição tem erro de 5%, e você itera 10 vezes em cima dela, o erro composto é (1.05)^10 ≈ 1.63 — você se desvia em 63% sem perceber. Investir na medição agora multiplica o valor de cada experimento futuro.

Background

Em qualquer trabalho de pesquisa empírica, existe uma tensão entre duas estratégias:

Iteração rápida: rode mais experimentos, mais variantes, mais ablations. Cobre mais terreno. Risco: se o instrumento de medição é frágil, os resultados são instáveis e as conclusões não se sustentam.
Investimento em fundação: pare de iterar, melhore o instrumento. Mais demorado a curto prazo. Benefício: cada experimento futuro vale mais.

O ponto onde uma vira mais valiosa que a outra depende de quanto você confia no instrumento atual. Se você confia, itere. Se desconfia, conserte primeiro.

O insight do x^n

A intuição de Marcos foi formulada assim: erros em fundação compõem ao longo de iterações. Se o pipeline atual tem 5% de margem de erro num tipo de medida (digamos, PPL como métrica de qualidade), e você toma 10 decisões sucessivas em cima desses números, a deriva composta é:

(1 + 0.05)^10 ≈ 1.63

Isto é: depois de 10 iterações, você está 63% desviado do que pensava medir. Pior, esse desvio é silencioso — não há indicador na tela dizendo "atenção, suas decisões dos últimos 10 experimentos compuseram erro de 60%".

A reverse: se a fundação for sólida (digamos, erro de 1%), 10 iterações compõem (1.01)^10 ≈ 1.10 — só 10% de deriva. Cada ponto percentual de melhoria na fundação tem efeito multiplicativo nas conclusões futuras.

O estado atual da fundação MASHA

Olhando criticamente, várias fragilidades vieram à tona depois dos ablations:

PPL como única métrica. Perplexidade é um proxy pra qualidade do modelo. Não é qualidade. Modelos com PPL parecidas podem ter diferenças enormes em tarefas downstream (geração coerente, parsing, classificação). Precisamos de mais métricas.
Held-out simples. Nosso held-out é 5% aleatório do mesmo Wikipedia. Não testa generalização para domínios diferentes (notícia, literatura, fala).
Sem mascaramento controlado. Não medimos o que o modelo prevê em posições específicas (substantivos, verbos, dependências). Só o agregado.
Hiperparâmetros não trancados. LR, batch, schedule podem estar otimizados pro Baseline e atrapalhando MASHA (ou vice-versa). Sem um sweep formal, qualquer comparação tem essa dúvida latente.
N=3 seeds. Como o doc 08 mostrou, é pouco. Precisamos de mais — mas rodar 10 seeds × 6 ablations × 2K steps custa GPU.

A decisão

Em vez de rodar imediatamente mais 5 seeds do ablation word-level (o caminho da iteração rápida), a decisão foi pausar e construir a rig de avaliação Tier 1:

Métrica BPC (Bits Per Character) além de PPL.
Mascaramento por POS — medir PPL só em substantivos, só em verbos etc.
Tarefas downstream — geração coerente, similaridade semântica, classificação.
Hyperparameter sweep formal com Baseline → trancar config → só depois rodar comparações.
Bootstrap CI nos paired t-tests para amostras pequenas.

Detalhes da rig estão no doc 10.

Por que isso importa

A engenheira humana tem um instinto comum: "tá quase, só mais um experimento". Esse instinto, em pesquisa de ML, é o caminho mais curto pra conclusões falsas com confiança alta. Os papers do campo cheios de "achamos X" que ninguém consegue reproduzir geralmente vieram de iteração rápida sobre fundação fraca.

MASHA tem uma chance real de virar resultado científico defensável se as próximas comparações vierem instrumentadas. Pular esse passo agora salva semana ou duas; cobra meses depois quando outras pessoas tentarem replicar e o castelo cair.

A regra de bolso de Marcos: se a próxima decisão importa, vale a pena pagar pra medir bem agora.

Termos usados

Fundação (em pesquisa): o conjunto de ferramentas, métricas, pipelines e protocolos sobre os quais experimentos são construídos. Análogo à "engenharia de infraestrutura" no mundo do produto.
Composição de erros: pequenos erros se multiplicam ao longo de decisões sucessivas. Matematicamente, (1 + ε)^n cresce exponencialmente em n.
Métrica proxy: número que representa indiretamente o que você quer medir. PPL é proxy de "modelo bom"; loss é proxy de "modelo aprende". Proxies têm vazamentos.
Tarefa downstream: aplicação concreta que usa o modelo treinado (geração de texto, classificação, tradução). Métricas downstream costumam revelar diferenças que perplexidade esconde.
Hyperparameter sweep: experimento que varia configurações de treino (LR, batch, schedule) pra achar combinação ótima. Pré-requisito pra comparação justa.
Tier 1 eval rig: na nomenclatura interna deste projeto, a próxima geração de infraestrutura de avaliação. Lista completa no doc 10.

## TL;DR Depois da inversão de direção no word-level (doc `07`) e da confirmação do outlier do seed 43 (doc `08`), a tentação foi rodar logo mais 5 seeds, mais ablations, mais variantes. Em vez disso, a decisão foi **parar e construir uma rig de avaliação melhor primeiro**. A lógica: se a fundação de medição tem erro de 5%, e você itera 10 vezes em cima dela, o erro composto é (1.05)^10 ≈ 1.63 — você se desvia em 63% sem perceber. Investir na medição agora multiplica o valor de cada experimento futuro. ## Background Em qualquer trabalho de pesquisa empírica, existe uma tensão entre duas estratégias: - **Iteração rápida**: rode mais experimentos, mais variantes, mais ablations. Cobre mais terreno. Risco: se o instrumento de medição é frágil, os resultados são instáveis e as conclusões não se sustentam. - **Investimento em fundação**: pare de iterar, melhore o instrumento. Mais demorado a curto prazo. Benefício: cada experimento futuro vale mais. O ponto onde uma vira mais valiosa que a outra depende de quanto você confia no instrumento atual. Se você confia, itere. Se desconfia, conserte primeiro. ## O insight do x^n A intuição de Marcos foi formulada assim: erros em fundação **compõem** ao longo de iterações. Se o pipeline atual tem 5% de margem de erro num tipo de medida (digamos, PPL como métrica de qualidade), e você toma 10 decisões sucessivas em cima desses números, a deriva composta é: ``` (1 + 0.05)^10 ≈ 1.63 ``` Isto é: depois de 10 iterações, você está 63% desviado do que pensava medir. Pior, esse desvio é silencioso — não há indicador na tela dizendo "atenção, suas decisões dos últimos 10 experimentos compuseram erro de 60%". A reverse: se a fundação for sólida (digamos, erro de 1%), 10 iterações compõem (1.01)^10 ≈ 1.10 — só 10% de deriva. **Cada ponto percentual de melhoria na fundação tem efeito multiplicativo nas conclusões futuras.** ## O estado atual da fundação MASHA Olhando criticamente, várias fragilidades vieram à tona depois dos ablations: 1. **PPL como única métrica**. Perplexidade é um proxy pra qualidade do modelo. Não é qualidade. Modelos com PPL parecidas podem ter diferenças enormes em tarefas downstream (geração coerente, parsing, classificação). Precisamos de mais métricas. 2. **Held-out simples**. Nosso held-out é 5% aleatório do mesmo Wikipedia. Não testa generalização para domínios diferentes (notícia, literatura, fala). 3. **Sem mascaramento controlado**. Não medimos o que o modelo prevê em posições específicas (substantivos, verbos, dependências). Só o agregado. 4. **Hiperparâmetros não trancados**. LR, batch, schedule podem estar otimizados pro Baseline e atrapalhando MASHA (ou vice-versa). Sem um sweep formal, qualquer comparação tem essa dúvida latente. 5. **N=3 seeds**. Como o doc `08` mostrou, é pouco. Precisamos de mais — mas rodar 10 seeds × 6 ablations × 2K steps custa GPU. ## A decisão Em vez de rodar imediatamente mais 5 seeds do ablation word-level (o caminho da iteração rápida), a decisão foi **pausar e construir a rig de avaliação Tier 1**: - Métrica BPC (Bits Per Character) além de PPL. - Mascaramento por POS — medir PPL só em substantivos, só em verbos etc. - Tarefas downstream — geração coerente, similaridade semântica, classificação. - Hyperparameter sweep formal com Baseline → trancar config → só depois rodar comparações. - Bootstrap CI nos paired t-tests para amostras pequenas. Detalhes da rig estão no doc `10`. ## Por que isso importa A engenheira humana tem um instinto comum: "tá quase, só mais um experimento". Esse instinto, em pesquisa de ML, é o caminho mais curto pra conclusões falsas com confiança alta. Os papers do campo cheios de "achamos X" que ninguém consegue reproduzir geralmente vieram de iteração rápida sobre fundação fraca. MASHA tem uma chance real de virar resultado científico defensável **se** as próximas comparações vierem instrumentadas. Pular esse passo agora salva semana ou duas; cobra meses depois quando outras pessoas tentarem replicar e o castelo cair. A regra de bolso de Marcos: **se a próxima decisão importa, vale a pena pagar pra medir bem agora**. ## Termos usados - **Fundação (em pesquisa)**: o conjunto de ferramentas, métricas, pipelines e protocolos sobre os quais experimentos são construídos. Análogo à "engenharia de infraestrutura" no mundo do produto. - **Composição de erros**: pequenos erros se multiplicam ao longo de decisões sucessivas. Matematicamente, `(1 + ε)^n` cresce exponencialmente em `n`. - **Métrica proxy**: número que representa indiretamente o que você quer medir. PPL é proxy de "modelo bom"; loss é proxy de "modelo aprende". Proxies têm vazamentos. - **Tarefa downstream**: aplicação concreta que usa o modelo treinado (geração de texto, classificação, tradução). Métricas downstream costumam revelar diferenças que perplexidade esconde. - **Hyperparameter sweep**: experimento que varia configurações de treino (LR, batch, schedule) pra achar combinação ótima. Pré-requisito pra comparação justa. - **Tier 1 eval rig**: na nomenclatura interna deste projeto, a próxima geração de infraestrutura de avaliação. Lista completa no doc `10`.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

pop/MASHA#20

No description provided.

Rows
Columns