IA Compendium — Filter & Quality Criteria

Filtro "Para o Kode" + critérios de qualidade por seção do topic IA. Consumido por /k-compendium ia durante Passo 3 (escrita) e Passo 2 (gap analysis).

Estrutura do compendium IA

docs/ia/compendium/
├── INDEX.md                          ← master index
├── 01-fundamentos/
│   ├── paradigmas.md                 ← taxonomia conceitual (preditivo/generativo, etc.)
│   ├── livros.md                     ← livros essenciais de ML/IA
│   ├── papers-fundacionais.md        ← papers por era (1943–hoje)
│   └── agi-asi-superinteligencia.md  ← definições AGI/ASI/AIXI, caminhos e limites (From AGI to ASI, DeepMind 2026)
├── 02-arquiteturas/
│   ├── transformer-e-atencao.md      ← Transformer, MQA, GQA, MLA, FlashAttention, RoPE, MoE
│   ├── arquiteturas-alternativas.md  ← SSMs, Mamba, xLSTM, RWKV, Liquid, JEPA, híbridos
│   ├── paradigmas-alternativos.md    ← Neurosimbólico, Tsetlin, HDC, Forward-Forward, EBM, Active Inference
│   └── multimodal.md                 ← Flamingo, Chameleon, LLaVA-NeXT, treinamento cross-modal
├── 03-modelos/
│   ├── open-source.md                ← Llama, Qwen, DeepSeek, Mistral, Gemma, Phi e outros
│   └── proprietarios.md              ← GPT, Claude, Gemini, Grok; scores e leaderboards
├── 04-treinamento/
│   ├── pre-treino.md                 ← scaling laws, curadoria, paralelismo, ZeRO, FSDP
│   ├── pos-treino.md                 ← SFT, DPO, GRPO, RLVR, PRMs, test-time compute
│   ├── datasets.md                   ← datasets por categoria com tamanho e licença
│   ├── dados-sinteticos.md           ← Self-Instruct, Orca, Phi Textbooks, MetaMath
│   ├── data-pipeline.md              ← crawler, dedup, filtros, PII scrubbing
│   └── economia.md                   ← custo por escala, build vs buy, roadmap
├── 05-inferencia/
│   ├── quantizacao.md                ← GPTQ, AWQ, GGUF, TurboQuant, BitNet, NVFP4
│   ├── speculative-decoding.md       ← EAGLE, Medusa, Lookahead, MTP
│   ├── kv-cache.md                   ← PagedAttention, RadixAttention, H2O, SnapKV
│   └── servidores.md                 ← vLLM, SGLang, TGI, llama.cpp, Ollama, TensorRT-LLM
├── 06-hardware/
│   ├── gpus-nvidia.md                ← A100, H100, H200, B100/B200/B300, GB200, RTX
│   ├── gpus-outros-asics.md          ← AMD MI, Google TPU, AWS Trainium, Intel Gaudi, Groq
│   ├── memoria-interconexao.md       ← HBM, GDDR, NVLink, InfiniBand, PCIe, CXL
│   ├── neuromorfico.md               ← Loihi 2, NorthPole, SpiNNaker, BrainScaleS, SNN
│   └── energia-refrigeracao-recursos.md ← consumo, PUE, WUE, minerais, sustentabilidade
├── 07-frameworks/                    ← treino distribuído, fine-tuning, inferência local, agentes, protocolos, observabilidade
├── 08-benchmarks/                    ← gerais, código, agentes, multimodal, avaliação contínua
├── 09-aplicacoes/                    ← vida, física/matemática, visão, áudio, vídeo/3D/world models
├── 10-seguranca/                     ← interpretabilidade, alinhamento
└── 11-infraestrutura/                ← cluster self-hosted, MLOps

Critérios de qualidade por seção

Para novos modelos (03-modelos/)

Um modelo merece entrada se atender ≥ 2 dos critérios:

  • Pesos abertos com licença permissiva (MIT, Apache 2.0)
  • Score de benchmark top-5 no domínio (coding, reasoning, multimodal)
  • Inovação arquitetural documentada em paper
  • Relevante para fine-tuning do Kode (código, instrução, raciocínio)

Para novos papers (01-fundamentos/papers-fundacionais.md)

Um paper é fundacional se:

  • Foi amplamente citado (>500 citações) OU
  • Introduziu uma técnica que virou padrão da indústria OU
  • É um marco histórico (primeiro de sua categoria)

Para benchmarks (08-benchmarks/)

Um benchmark merece entrada se:

  • É amplamente usado como referência nos papers mais recentes
  • Testa capacidade não coberta por outros benchmarks
  • Não está saturado (top models <95% de acerto)

Para hardware (06-hardware/)

Hardware merece entrada se:

  • É usado ou acessível para treino/inferência de LLMs
  • Tem specs relevantes (VRAM, bandwidth, TFLOPS) documentadas

Para infraestrutura de cluster (11-infraestrutura/)

Conteúdo merece entrada se:

  • É uma ferramenta ou prática para orquestrar GPUs em escala
  • Resolve problemas reais de networking, storage ou scheduling
  • Tem documentação pública e comunidade ativa

Para data pipeline (04-treinamento/data-pipeline.md)

Técnica merece entrada se:

  • É usada em pipelines de produção (não apenas academic)
  • Tem código aberto ou implementação disponível
  • Resolve problema de escala (dedup em TB+, filtragem automatizada)

Para economia e estratégia (04-treinamento/economia.md)

Conteúdo merece entrada se:

  • Dá números concretos de custo por escala de treino
  • Compara trade-offs entre build, fine-tune e API
  • Ajuda a planejar roadmap de modelo (quando escalar, quando parar)

Para avaliação contínua (08-benchmarks/avaliacao-continua.md)

Técnica merece entrada se:

  • Permite avaliar modelo próprio sem contaminação
  • Automatiza comparação entre versões de modelo
  • Detecta drift de qualidade em produção

Filtro para o Kode

Em todo arquivo, priorizar informações que respondem a:

  1. Qual modelo usar como base para fine-tuning? → Qwen2.5-Coder-32B como padrão; comparar novos challengers
  2. Como treinar com hardware disponível? → 2× RTX 4090 (96 GB total); foco em QLoRA e quantização
  3. Como fazer inferência eficiente? → vLLM + SGLang; quantização AWQ/GGUF
  4. Qual pipeline de pós-treino? → SFT → DPO → RLVR com builds como reward
  5. Que benchmarks medem coding real? → SWE-bench Verified acima de tudo
  6. Como montar um cluster de treino? → Kubernetes/Slurm, InfiniBand, storage distribuído para datasets
  7. Como construir e curar datasets próprios? → crawler, dedup (MinHash/SimHash), filtros de qualidade, PII scrubbing
  8. Quanto custa treinar por escala? → Tabelas de custo 7B30B70B; quando vale build vs fine-tune vs API
  9. Como avaliar modelos continuamente? → eval loop privado, canary strings, LLM-as-a-judge calibrado
  10. Como versionar e deployar modelos? → MLOps: checkpointing, canary deploy, monitoring de drift, rate limiting

Regras de escrita por arquivo

O que SEMPRE incluir:

  • ID do arXiv para todo paper (formato: arXiv:XXXX.XXXXX)
  • Conferência ou venue de publicação (ICLR, NeurIPS, Nature, etc.)
  • Número de parâmetros, contexto, licença para todo modelo
  • Scores de benchmarks com data ("abril 2026") para não envelhecer mal
  • Seção "Para o Kode" ou linha de recomendação quando o item for acionável

O que NUNCA fazer:

  • Inventar arXiv IDs — se não souber, escrever "Relatório técnico" ou "Blog post"
  • Incluir datasets de avaliação (MMLU, SWE-bench, HumanEval) em listas de dados de treino
  • Duplicar conteúdo já coberto em outro arquivo do compendium (referenciar via link relativo)
  • Escrever scores sem indicar qual modelo/sistema os atingiu

Formato do texto:

  • Prosa e comentários em português brasileiro
  • Nomes técnicos, identificadores, nomes de modelos e ferramentas em inglês (ex: "Quantização" é o título, mas "GPTQ, AWQ, GGUF" ficam como estão)
  • Tabelas para specs comparativas — mais legível que listas
  • Seção de benchmarks com tabela no final de cada arquivo de modelo