IA Compendium — Filter & Quality Criteria

Filtro "Para o Kode" + critérios de qualidade por seção do topic *A* 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)
├── 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 (01fundamentos/papersfundacionais.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 (04treinamento/datapipeline.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 tradeoffs entre build, finetune e API
• Ajuda a planejar roadmap de modelo (quando escalar, quando parar)

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

Regras de escrita por arquivo

* 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

* 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

*ormato do texto:*

• Prosa e comentários em *ortuguês brasileiro*
• Nomes técnicos, identificadores, nomes de modelos e ferramentas em *nglê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