Habilidade de Arquitetura AlphaGo
Pontos de Decisão
Quando Usar Avaliadores Únicos vs. em Cascata
Características do problema:
├── Espaço de busca tratável (b^d < 10^9)
│ └── Use o melhor avaliador único → otimização padrão
└── Espaço de busca intratável (b^d > 10^12)
├── Orçamento de avaliação uniforme disponível
│ └── Use aproximação em cascata:
│ 1. Prunning rápido (rede de política) → feixe estreito
│ 2. Avaliação média (rede de valor) → estimar qualidade
│ 3. Exploração barata (rollouts) → cobertura de amplitude
└── Orçamento de avaliação não uniforme
└── Alocação adaptativa:
├── Posições críticas → avaliação cara
└── Posições rotineiras → heurísticas baratas
Árvore de Decisão de Requisitos de Precisão vs. Latência
Requisitos do sistema:
├── Latência crítica (resposta <1ms)
│ ├── Tolerância de precisão alta (erro >10% aceitável)
│ │ └── Apenas rollouts rápidos (2µs/avaliação)
│ └── Tolerância de precisão baixa (erro <5%)
│ └── Rede de política em cache + fallback heurístico
├── Latência moderada (resposta 1-100ms)
│ ├── Alta precisão necessária
│ │ └── Rede de valor (3ms) + orientação da rede de política
│ └── Precisão/velocidade equilibradas
│ └── Avaliação mista: λ=0,5 valor + rollouts
└── Tolerante a latência (>100ms)
└── Cascata completa: política → valor → rollouts com MCTS
Avaliação de Diversidade de Modos de Erro
Ao escolher múltiplos avaliadores:
├── Todos os avaliadores têm modos de falha semelhantes
│ └── Use o melhor avaliador único (nenhum benefício de diversidade)
├── Avaliadores têm erros complementares
│ ├── Par rápido/ruidoso + lento/preciso
│ │ └── Misture em λ=0,3-0,7 (viés para o preciso)
│ ├── Par conservador + exploratório
│ │ └── Misture em λ=0,5 (pesos iguais)
│ └── Par aprendido + artesanal
│ └── Mistura dinâmica baseada em pontuações de confiança
└── Correlação de erro desconhecida
└── Teste empírico: meça o desempenho em conjunto de validação
Modos de Falha
Inchaço de Esquemas (Detecção: >5 camadas de aproximação)
Sintoma: Adicionar mais camadas de aproximação, mas ver retornos decrescentes Causa raiz: Cada camada adiciona sobrecarga sem ganho proporcional de precisão Correção: Perfilar custo computacional vs. melhoria de precisão; remover camadas com ROI baixo Regra de detecção: Se adicionar a camada N melhora a precisão <5%, mas aumenta a latência >20%, você tem inchaço de esquemas
Acoplamento Síncrono (Detecção: Componentes rápidos ociosos esperando)
Sintoma: Utilização da CPU cai enquanto espera pela avaliação da GPU Causa raiz: Acoplamento apertado entre busca rápida e avaliação lenta da rede neural Correção: Implementar filas assíncronas com tolerância a valores desatualizados Regra de detecção: Se componentes rápidos (busca, rollouts) têm tempo ocioso >50%, você tem acoplamento síncrono
Fixação em Métrica Proxy (Detecção: Métrica melhora, mas desempenho piora)
Sintoma: Precisão de predição de movimento melhora, mas taxa de vitória diminui Causa raiz: Otimizar para imitação humana em vez de sucesso objetivo Correção: Trocar de aprendizado supervisionado para aprendizado por reforço com objetivo verdadeiro Regra de detecção: Se a métrica proxy e a métrica de resultado tendem em direções opostas por >10 avaliações, você tem fixação proxy
Falácia do Avaliador Único (Detecção: Rejeitar componentes individuais "piores")
Sintoma: Descartar rollouts porque a rede de valor tem maior precisão individual Causa raiz: Supor que o melhor componente individual faz o melhor componente do sistema Correção: Testar o desempenho da mistura empiricamente; a diversidade muitas vezes supera a qualidade individual Regra de detecção: Se você está selecionando componentes pelo desempenho individual sem testar combinações, você tem a falácia do avaliador único
Alocação Uniforme de Orçamento (Detecção: Mesmo computação para todas as decisões)
Sintoma: Gastar tempo igual de avaliação em movimentos óbvios e posições críticas Causa raiz: Não adaptar o orçamento computacional à importância da decisão Correção: Implementar alocação adaptativa baseada na incerteza da posição e sensibilidade do resultado Regra de detecção: Se a variação do tempo de avaliação entre posições <20% da média, você tem alocação uniforme
Exemplos Práticos
Implementando Aproximação em Cascata para Revisão de Código
Cenário: Projetar sistema de IA para revisar pull requests com 50-500 linhas alteradas, necessidade de resposta <10s, deve detectar 95% dos bugs.
Passo 1: Analisar restrições computacionais
- Análise estática: 10ms por arquivo
- Detector de bugs ML: 2s por arquivo
- Análise semântica profunda: 30s por arquivo
- Orçamento disponível: 10s total
Passo 2: Aplicar árvore de decisão em cascata Seguindo o caminho "espaço de busca intratável", pois a análise exaustiva excede o orçamento:
- Camada de prunning rápido (análise estática): Eliminar arquivos sem alterações de complexidade
- Camada de avaliação média (detector ML): Pontuar arquivos restantes quanto à probabilidade de bugs
- Camada de análise cara (semântica): Mergulho profundo apenas nos arquivos com maior pontuação
Passo 3: Estratégia de alocação de orçamento
- Reservar 2s para avaliação ML de todos os arquivos restantes
- Alocar os 8s restantes para análise semântica baseada nas pontuações ML
- Arquivos com pontuação >0,8: recebem 4s cada (máx 2 arquivos)
- Arquivos com pontuação 0,5-0,8: recebem 2s cada
- Arquivos com pontuação <0,5: recebem apenas a pontuação ML
Passo 4: Implementação de avaliação mista Em vez de usar o "melhor" avaliador (análise semântica), misturar pontuações ML + semânticas:
- Detector ML: rápido, bom em correspondência de padrões, perde bugs novos
- Análise semântica: lenta, detecta erros lógicos complexos, alta taxa de falsos positivos
- Mistura em λ=0,6:
pontuacao_final = 0,6 * semantica + 0,4 * ml
Abordagem iniciante: Executar análise semântica em tudo → timeout após os primeiros arquivos Insight do especialista: A cascata permite gastar computação cara apenas onde mais importa, enquanto garante que todo arquivo receba alguma avaliação
Portões de Qualidade
[ ] N avaliadores testados: Mínimo de 3 avaliadores com diferentes perfis de velocidade/precisão implementados e avaliados [ ] Correlação de erro medida: Matriz de correlação pareada calculada mostrando avaliadores com correlação <0,7 no conjunto de teste [ ] Mistura vs. único avaliado: Comparação empírica mostrando que a mistura supera o melhor componente individual em >5% [ ] Requisitos de latência atendidos: Tempo de resposta no percentil 95 abaixo do limite especificado com cascata completa [ ] Requisitos de precisão atendidos: Taxa de erro no conjunto de validação atende ao limite especificado (por exemplo, <5% de taxa de falso negativo) [ ] Alocação de orçamento perfilada: Detalhamento de custo computacional mostra orçamento distribuído de acordo com a importância da decisão [ ] Teste de modo de falha: Sistema testado sob condições adversas (mudança de distribuição, restrições de recursos, casos extremos) [ ] Coordenação assíncrona verificada: Componentes rápidos mantêm utilização >80% mesmo quando componentes lentos estão saturados [ ] Escalabilidade validada: Desempenho degrada-se graciosamente ao aumentar a carga em 10x além da capacidade nominal [ ] Instrumentação de monitoramento: Métricas rastreiam alinhamento proxy vs. resultado, utilização de componentes e eficácia da cascata
Limites de NÃO USO
NÃO use esta habilidade para:
- Problemas de otimização simples com espaços de busca tratáveis → use otimização-padrão
- Treinamento ou ajuste de modelo único → use treinamento-deep-learning
- Sistemas em tempo real que exigem latência <1ms → use sistemas-de-baixa-latência
- Problemas onde um avaliador é claramente superior e outros não agregam valor → use implantação-modelo-único
- Processos de decisão sequenciais sem estrutura de árvore de busca → use fundamentos-de-aprendizado-por-reforço
Delegue para outras habilidades quando:
- Precisar implementar arquiteturas específicas de redes neurais → arquiteturas-deep-learning
- Projetar infraestrutura de sistemas distribuídos → design-de-sistemas-distribuídos
- Otimizar o desempenho de componentes individuais → otimização-de-desempenho
- Lidar com coleta e rotulagem de dados de treinamento → engenharia-de-dados
- Implementar algoritmos de busca específicos → algoritmos-de-busca
Esta habilidade foca especificamente em: Padrões arquiteturais para coordenar múltiplos avaliadores imperfeitos sob restrições computacionais, e não nos detalhes de implementação de componentes individuais.