# Sistema de Evolução Inteligente EvoX e Práticas de Pesquisa Científica AI Native — Material Didático
Duração: 1 · Páginas do material: 16
## Navegação de Leitura
- [Lição 4｜Tema: Base Computacional Moderna e Evolução Paralela Tensorizada](#lecture-lesson-1)
---
## Lição 4｜Tema: Base Computacional Moderna e Evolução Paralela Tensorizada
### Base Computacional Moderna e Evolução Paralela Tensorizada
*Página 1*
> **Objetivo da página:** Aprender como o EvoX organiza população, avaliação e estado como tensores computáveis em conjunto, superando o gargalo serial tradicional para alcançar aceleração em larga escala.
> **Objetivo da página**
>
> Esta página abre a quarta lição, apontando o problema central que ela resolve — quando o tamanho da população, o número de avaliações e as iterações dos algoritmos evolutivos crescem continuamente, a abordagem tradicional de processamento serial indivíduo por indivíduo e passo a passo torna-se um gargalo evidente. A linha principal desta lição é ver como o EvoX reorganiza população, avaliação e estado em tensores que podem participar integralmente do cálculo, obtendo aceleração substancial em cenários de larga escala.
> **Sequência de exposição**
>
> Pode-se começar lançando uma pergunta intuitiva — "se a população tem cem mil indivíduos, e ainda precisamos processá-los um por um em loop, o que acontece?" — para levar os alunos a perceber o duplo desperdício do loop serial em tempo e utilização de hardware. Em seguida, apresentar a direção da resposta desta lição: tratar toda a população como um lote de dados, tratar a atualização de uma geração como uma operação em lote, permitindo que o cálculo caia integralmente sobre hardware paralelo. Por fim, introduzir o papel da camada Runtime, explicando que ela é responsável por agendar poder computacional heterogêneo enquanto mantém a composabilidade dos algoritmos.
**Pontos-chave de ensino**
- 1. Expressão tensorizada — população, avaliação de aptidão e estado interno do algoritmo não são mais objetos dispersos, mas organizados em tensores com forma unificada, permitindo que uma geração de evolução seja expressa como algumas operações em lote. A vantagem é que o padrão de computação é regular e facilmente vetorizável, e a mesma descrição de algoritmo pode se adaptar a populações de diferentes tamanhos. 2. Superação do gargalo serial — em implementações tradicionais, avaliação e atualização de estado frequentemente ocorrem indivíduo por indivíduo; quando a escala cresce, o custo do loop e a espera por sincronização dominam o tempo de execução
- após a batelização, esses custos são diluídos e a vazão aumenta significativamente. 3. Papel de agendamento do Runtime — o Runtime situa-se entre a descrição do algoritmo e o hardware subjacente, responsável por despachar operações em lote para CPU, GPU e outros recursos heterogêneos, de modo que o autor do algoritmo não precise reescrever a lógica para cada dispositivo. Ao mesmo tempo, mantém a composabilidade dos componentes do algoritmo, permitindo que diferentes operadores e estratégias se combinem livremente sem destruir a capacidade de paralelismo.
**Cobertura de palavras-chave**
- Tensorização, computação em lote, gargalo serial, aceleração em larga escala, agendamento de poder computacional heterogêneo, composabilidade de algoritmos.
**Verificação de compreensão**
Peça aos alunos que expliquem com suas próprias palavras o que "transformar a população em tensor" realmente muda — a resposta esperada deve recair sobre "mudar de loop indivíduo por indivíduo para operação em lote integral, fazendo o hardware paralelo ser realmente utilizado"; se apenas repetirem terminologia sem explicar a causalidade, pode-se sugerir que reorganizem a explicação sob as duas perspectivas: número de computações e utilização de hardware.
> **Dica de transição**
>
> Após confirmar que os alunos estabeleceram a cadeia causal básica "tensorização → computação em lote → aceleração paralela", passar para as páginas seguintes, examinando especificamente como população e estado são organizados em tensores e como o Runtime realiza o agendamento.
### Base Computacional Moderna e Evolução Paralela Tensorizada
*Página 2*
> **Objetivo da página:** O aprendiz deve compreender a contradição entre a demanda de poder computacional em larga escala da computação evolutiva moderna e a arquitetura tradicional.
> **Objetivo da página**
>
> Compreender a contradição entre a demanda de poder computacional em larga escala da computação evolutiva moderna e a arquitetura serial tradicional; dominar a abordagem de organizar população, avaliação e estado como tensores para avançar a evolução em paralelismo em lote; reconhecer a expansão da geração de candidatos por grandes modelos e as escolhas arquiteturais sistêmicas daí decorrentes.
> **Sequência de exposição**
>
> Primeiro apontar a contradição central "diversidade → número de avaliações → custo de gerenciamento de estado e agendamento", depois explicar por que o loop serial atinge o limite primeiro; em seguida desenvolver os três níveis da tensorização — tensor de população, tensor de avaliação, tensor de estado — e sintetizar o termo central "paralelismo em lote"; depois explicar como grandes modelos empurram a geração de candidatos para novas fronteiras; finalmente chegar aos exemplos de cenários EvoX e às escolhas sistêmicas, tratando exercícios e casos.
**Pontos-chave de ensino**
- A evolução depende da diversidade populacional, e a diversidade converte-se diretamente em número de avaliações, gerenciamento de estado e custo de agendamento. No loop serial tradicional de CPU indivíduo por indivíduo, cada indivíduo precisa chamar a função objetivo separadamente, atualizar o estado separadamente, registrar log separadamente
- quando a população cresce de dezenas para milhares, o número de avaliações e o tempo de relógio de parede crescem quase linearmente; uma vez que uma única simulação é custosa, a vazão total fica travada no "ritmo de núcleo único". Quanto maior a diversidade, mais caro cada avaliação, mais evidente o gargalo serial. A abordagem de tensorização reorganiza população, avaliação e estado em tensores computáveis integralmente. O tensor de população empilha todos os parâmetros candidatos em um tensor bidimensional de "número de indivíduos × dimensão", e uma única chamada de operador completa a mutação e atualização de toda a população
- o tensor de avaliação empacota requisições de avaliação em lote, executadas em paralelo por GPU ou serviço de processamento em lote, com os valores de retorno mesclados
- o tensor de estado mantém aptidão, violação de restrições, ranking e outros estados intermediários em forma de tensor, permitindo que seleção, ordenação e atualização sejam calculadas integralmente. Os três juntos formam o "paralelismo em lote", que transforma o volume computacional trazido pela diversidade de fardo em escala absorvível pela vazão; portanto, não é um detalhe de otimização, mas uma questão de infraestrutura da computação evolutiva moderna. Quando a escala computacional é aberta, a questão-chave muda de "é possível computar" para "de onde vêm os candidatos". Grandes modelos podem compreender linguagem natural, código, conhecimento de domínio e contexto do projeto, e a partir disso construir candidatos de estrutura complexa, expandindo o objeto de evolução de parâmetros numéricos para programas, algoritmos e até estados completos de sistemas
- as formas de codificação e mutação que antes dependiam de design manual começam a poder ser geradas com participação de modelos. Duas forças se encontram: a GPU permite que uma grande quantidade de possibilidades seja explorada simultaneamente, o grande modelo permite que o sistema produza possibilidades mais ricas, e o mecanismo evolutivo encarrega-se de enviar candidatos para tarefas reais, decidindo por meio de execução e avaliação quais mudanças merecem ser preservadas. Para engenheiros de algoritmos e desenvolvedores de sistemas, isso não é otimização local, mas escolha arquitetural: é necessário fazer um trade-off sistêmico entre a riqueza da geração de candidatos, a vazão da computação em lote e a complexidade de engenharia. A diversidade é premissa da eficácia evolutiva, mas deve ser digerida pela vazão. No cenário EvoX, se ainda se usar loop serial de CPU avaliando indivíduo por indivíduo, o tamanho da população ficará limitado pela vazão
- mudando para paralelismo em lote tensorizado, na mesma rodada pode-se organizar simultaneamente os parâmetros, estados de avaliação e atualizações de uma grande quantidade de candidatos, tornando "manter diversidade" e "exploração em larga escala" simultaneamente viáveis em engenharia.
**Cobertura de palavras-chave**
- Paralelismo em lote, tensorização, tensor de população, tensor de avaliação, tensor de estado, gargalo serial, geração de candidatos, trade-off sistêmico.
**Tratamento dos exercícios**
Esta página tem 5 questões de múltipla escolha e 1 estudo de caso, totalizando 2 perguntas. As questões de múltipla escolha verificam respectivamente a contradição central, a forma de implementação do paralelismo em lote, o papel dos grandes modelos, o trade-off sistêmico após a migração e as mudanças diretas no cenário EvoX. Ao responder, atentar para duas linhas principais: primeiro, a cadeia causal "diversidade → volume computacional → gargalo serial → paralelismo em lote"; segundo, a divisão "grandes modelos geram candidatos mais ricos, o mecanismo de avaliação julga quais candidatos merecem ser preservados". A primeira pergunta do estudo de caso exige diagnosticar o gargalo serial e explicar como a tensorização muda a forma de organização em três pontos: população, avaliação e estado; a segunda pergunta exige fornecer julgamentos de trade-off nas dimensões de riqueza de candidatos vs. vazão em lote, retorno de exploração vs. complexidade de engenharia, vazão em lote vs. fidelidade de avaliação, etc.
A resposta correta deve conectar-se aos conceitos desta página e explicar a base; se o julgamento estiver errado, retornar à cadeia causal "diversidade → número de avaliações → custo de gerenciamento de estado e agendamento", e distinguir "acelerar o mesmo loop serial" de "mudar a forma de organização do cálculo".
**Verificação de compreensão**
Peça aleatoriamente a um aluno que resuma os pontos principais desta página com suas próprias palavras, especialmente explicando como a diversidade se converte em volume computacional, por que o serial atinge o limite e como o paralelismo em lote tensorizado organiza população, avaliação e estado. Se o aluno só conseguir repetir terminologia sem explicar a causalidade, pode-se guiá-lo de volta à comparação de inclinações no gráfico e à marcação "gargalo serial: vazão no limite".
> **Dica de transição**
>
> Após confirmar que os alunos conseguem expressar a relação central desta página — diversidade traz volume computacional, execução serial atinge o limite, paralelismo em lote tensorizado digere a escala com cálculo integral — passar para a próxima página com exemplos, aplicações ou resumo.
### Desafios de Diversidade Evolutiva e Escala Computacional
*Página 3*
> **Objetivo da página:** O aprendiz deve compreender a pressão computacional trazida por trade-offs multiobjetivo e diversidade de candidatos em problemas reais.
> **Objetivo da página**
>
> Compreender a pressão computacional trazida por trade-offs multiobjetivo e diversidade de candidatos, dominando a fronteira de Pareto, relações de dominância e a tensão entre manutenção da diversidade e custo de avaliação.
**Pontos-chave de ensino**
- Quando o problema tem apenas um objetivo, existe solução ótima única. Problemas reais de engenharia geralmente têm múltiplos objetivos mutuamente conflitantes (sustentação e arrasto, precisão e latência, desempenho e custo); nesse caso, a "boa resposta" é um conjunto de soluções de trade-off mutuamente não dominadas, ou seja, a fronteira de Pareto. Comparar item a item se A não é pior que B em todos os objetivos → se há pelo menos um objetivo em que A é estritamente melhor → ambas as condições devem valer para que A domine B. Basta que em um item A seja pior, e ambos não se dominam, podendo permanecer na fronteira. Eixo horizontal f1, eixo vertical f2, ambos quanto menor melhor
- o agrupamento A tende a f1 baixo, o agrupamento B é intermediário, o agrupamento C tende a f2 baixo
- pontos cinzas são soluções dominadas. O decisor precisa do espaço de trade-off representado por toda a fronteira, não de um único ponto escolhido pelo algoritmo. Refere-se a diferenças estruturais distribuídas ao longo de diferentes direções de trade-off na fronteira de Pareto. Cobertura de direções — preencher a extremidade superior esquerda, o trecho médio e a extremidade inferior direita da fronteira
- preservação de diferenças — candidatos quase idênticos equivalem a um só
- valor de decisão — preferências frequentemente se tornam explícitas a posteriori, e preservar candidatos diferenciados permite reescolha a custo zero. Quanto mais forte a diversidade, mais amplo o espaço de busca, maior o tamanho da população, mais avaliações. Quando a avaliação depende de simulação de alta fidelidade (como cálculo aerodinâmico de aerofólio supercrítico que leva horas), o custo de uma única avaliação é amplificado como gargalo principal. Respostas comuns: modelos substitutos substituem a maioria das avaliações de alta fidelidade
- alocar o orçamento limitado de alta fidelidade prioritariamente aos candidatos que mais expandem a cobertura da fronteira
- redistribuir o orçamento entre tamanho da população e número de gerações. Equiparar diversidade a ruído aleatório ou a executar mais vezes. Diversidade real é diferença estrutural de direção
- perturbação puramente aleatória não expande a cobertura da fronteira nem reduz a dificuldade de decisão. Pistas de exercício (5 questões de múltipla escolha + 1 estudo de caso): A fronteira de Pareto é um conjunto de soluções de trade-off mutuamente não dominadas; quaisquer duas soluções têm vantagens e desvantagens em objetivos diferentes. A é melhor em f1, B é melhor em f2, ambos não se dominam, podendo permanecer na fronteira. Diversidade é diferença estrutural distribuída ao longo de diferentes direções de trade-off na fronteira de Pareto, servindo diretamente à decisão. Cobertura mais ampla de direções de trade-off requer maior espaço de busca, tamanho de população e número de avaliações objetivo; portanto, quanto mais forte a diversidade, maior o desafio de escala computacional. Usar modelos substitutos para assumir a maior parte das avaliações, concentrando o orçamento limitado de alta fidelidade na expansão da cobertura da fronteira, pode mitigar a tensão entre escala e diversidade. Design de aerofólio supercrítico. A entrega deve ser um conjunto de soluções candidatas localizadas na fronteira de Pareto, cobrindo diferentes direções de trade-off, e não uma única solução
- medidas para mitigar a tensão incluem modelos substitutos, alocação prioritária de orçamento, ajuste da proporção entre população e gerações, triagem multifidelidade em estágios, etc.
**Verificação de compreensão**
Peça aos alunos que expliquem com suas próprias palavras a relação de dominância e a fronteira de Pareto, e exemplifiquem por que a diversidade traz pressão computacional. Se o aluno confundir diversidade com perturbação aleatória, pode-se retornar ao "mantra de autoverificação" — não importa quantos candidatos haja, se estiverem amontoados no mesmo canto da fronteira, ainda não há diversidade.
> **Dica de transição**
>
> Após confirmar que os alunos conseguem distinguir ótimo de ponto único de conjunto de soluções de trade-off, e compreendem o custo da diversidade, passar para a próxima página sobre evolução paralela tensorizada.
### Gargalo de Eficiência do Loop Serial Tradicional de CPU
*Página 4*
> **Objetivo da página:** O aprendiz deve reconhecer as limitações de desempenho do loop serial tradicional de CPU ao processar dezenas de milhares de avaliações de candidatos.
**Pontos-chave de ensino**
- Número total de avaliações ≈ tamanho da população × número de gerações; tempo de avaliação serial ≈ número total de avaliações × tempo de uma avaliação. Calcular primeiro essas duas quantidades para então julgar se o gargalo merece esforço de reformulação.
- Loop na camada do interpretador, verificação de limites e despacho de tipos por indivíduo, acesso não contíguo à memória, sincronização e movimentação de dados frequentes acumulam-se como custo constante serial. Apenas otimizar o operador em si só elimina uma pequena parte disso.
- Plotar o tempo de relógio de parede sob diferentes tamanhos de população: uma linha aproximadamente reta indica que a execução ainda é serial; uma forma em degraus indica que já está organizada em lotes. A forma da curva explica melhor a origem do gargalo do que números pontuais.
> **Objetivo da página**
>
> Esta página visa fazer os alunos reconhecerem que, quando as avaliações de candidatos atingem a ordem de dezenas de milhares, o loop serial tradicional de CPU torna-se o trecho mais estreito de todo o pipeline evolutivo; esse gargalo pertence ao nível do modelo de execução, e não à forma de escrita de um operador individual ou a defeitos de código. O processamento em lote, a tensorização e o agendamento paralelo subsequentes são precisamente as direções de reformulação voltadas a esse gargalo estrutural.
>
> Sequência de exposição e pontos-chave de ensino:
>
> A evolução depende da diversidade, e a diversidade traz crescimento multiplicativo no tamanho da população e no número de avaliações. Número total de avaliações ≈ tamanho da população × número de gerações; tempo de avaliação serial ≈ número total de avaliações × tempo de uma avaliação. Quando o número de avaliações atinge a ordem de 10⁵, o tempo de relógio de parede serial cresce aproximadamente linearmente.
>
> O gráfico compara processamento serial indivíduo por indivíduo com processamento paralelo em lote. O eixo horizontal é o número de avaliações de candidatos 10³, 10⁴, 10⁵; o eixo vertical é o tempo de relógio de parede normalizado. A curva serial cresce aproximadamente linearmente; a curva paralela cresce em degraus. Segmentos escuros representam custos de agendamento e movimentação de dados. A conclusão-chave é: sob a mesma carga de trabalho, o crescimento do tempo paralelo é determinado principalmente pelo número de lotes, não pelo número de indivíduos. Usar a forma da curva explica melhor a origem do gargalo do que olhar apenas números pontuais.
>
> A implementação mais ingênua trata toda a população como uma lista, percorrendo em loop cada indivíduo → decodificando para parâmetros concretos → chamando a função de avaliação → escrevendo de volta a aptidão. Iterações adjacentes dificilmente se sobrepõem: sem o retorno do resultado da avaliação, a escrita de volta não avança; sem a conclusão da escrita de volta, o próximo indivíduo não tem onde colocar o resultado. Assim, unidades paralelas como multicore, SIMD e GPU ficam ociosas na maior parte do tempo.
>
> Número de avaliações em expansão linear; execução indivíduo por indivíduo na camada do interpretador, incluindo loop por indivíduo, verificação de limites e despacho de tipos, trazendo custo constante fixo mas elevado; acesso não contíguo à memória e movimentação de dados — indivíduos obtidos um a um frequentemente não são contíguos na memória, com baixa taxa de acerto de cache; sincronização e agendamento — para obter o próximo indivíduo, o fluxo de execução pausa e retoma repetidamente. Apenas otimizar o interior do operador só elimina uma pequena parte disso.
>
> Tomando como exemplo população de 1000 e 100 gerações, o número total de avaliações é cerca de 1000 × 100 = 10⁵. Se cada avaliação leva em média 1 ms, apenas a etapa de avaliação serialmente levaria cerca de 100 segundos, sem contar custos de computação de operadores e agendamento; se para manter a diversidade o número de reinicializações aumentar de 1 para 5, o custo sobe aproximadamente linearmente para cerca de 500 segundos. A mesma carga de trabalho, se organizada em lotes e processada por hardware paralelo, tem o tempo de relógio de parede determinado principalmente pelo número de lotes e pelo tempo de cada lote.
>
> Quando uma única avaliação é extremamente barata (nível de microssegundos) ou a população é muito pequena (abaixo da centena), os custos de agendamento e memória podem superar o custo de cálculo, e a diferença entre serial e paralelo se estreita significativamente; o retorno marginal da tensorização diminui, e o gargalo migra para granularidade de agendamento e largura de banda de memória. Portanto, se vale a pena reformular o modelo de execução deve ser avaliado em conjunto com o custo de avaliação e a escala.
>
> O gargalo de eficiência do loop serial de CPU é estrutural. Para resolver de fato, é preciso refatorar de indivíduo por indivíduo para lote por lote, ou seja, processamento em lote, tensorização e agendamento paralelo, o que constitui a motivação direta para o design subsequente do grafo computacional tensorizado.
**Cobertura de palavras-chave**
- Loop serial de CPU, paralelismo em lote, tempo de relógio de parede, número de avaliações de candidatos, número de lotes, custo da camada do interpretador, acesso não contíguo à memória, sincronização e agendamento, gargalo estrutural, tensorização.
**Tratamento dos exercícios**
Esta página tem 5 questões de múltipla escolha. Recomenda-se que, para cada questão, os alunos primeiro expressem a base do julgamento e depois recebam feedback.
A questão 1 pergunta qual é a principal limitação do modelo de execução do loop serial. A resposta é "iterações adjacentes dificilmente se sobrepõem, e unidades paralelas como multicore, SIMD e GPU ficam ociosas na maior parte do tempo". Ponto de feedback: o fluxo de execução indivíduo por indivíduo — pegar indivíduo → decodificar → avaliar → escrever de volta — faz de cada indivíduo um passo serial independente, e o hardware carece de trabalho independente executável simultaneamente; o gargalo não é não conseguir calcular a aptidão, mas o fato de que em cada momento apenas um indivíduo está sendo processado.
A questão 2 pergunta o tempo de relógio de parede serial apenas da etapa de avaliação quando a população é 1000, as gerações são 100 e cada avaliação leva 1 ms. A resposta é cerca de 100 segundos. Raciocínio: número total de avaliações ≈ 1000 × 100 = 10⁵, multiplicado por 1 ms.
A questão 3 pergunta qual item NÃO é um fator que amplifica o custo constante do loop serial. A resposta é "agendamento de processamento em lote tensorizado". Ponto de feedback: o processamento em lote tensorizado é a direção de reformulação para mitigar o gargalo, não uma fonte de amplificação de custo do próprio loop serial; os custos seriais vêm de acesso não contíguo à memória, verificação de limites e despacho de tipos por indivíduo, loop na camada do interpretador, etc.
A questão 4 pergunta, sob paralelismo em lote, ao completar a mesma carga total de trabalho, o que determina principalmente o tempo de relógio de parede. A resposta é "o número de lotes e o tempo de cada lote". Ponto de feedback: o processamento em lote transforma indivíduo por indivíduo em lote por lote, e o tempo de relógio de parede cresce em degraus com o número de lotes, em vez de crescer aproximadamente linearmente com o número de indivíduos.
A questão 5 pergunta em qual situação é mais provável que julgar o loop serial como gargalo estrutural não se sustente. A resposta é "avaliação única cai para nível de microssegundos, e o tamanho da população é apenas da ordem da centena". Ponto de feedback: nesse caso, os custos de agendamento e memória podem superar o custo de cálculo, e a diferença entre serial e paralelo se estreita; julgar o gargalo requer avaliar em conjunto o custo de avaliação e a escala.
**Atividade em sala**
Pode-se usar o caso desta página "Escolha do modelo de execução sob cem mil avaliações". Primeiro deixar os alunos estimarem, depois discutir os limites da reformulação.
Estimar o tempo de relógio de parede apenas da etapa de avaliação da implementação serial atual, e explicar a mudança após o número de reinicializações aumentar de 1 para 5, julgando com base nisso o foco da otimização. Resposta de referência: 1000 × 100 = 10⁵ avaliações, multiplicado por 1 ms dá cerca de 100 segundos; com 5 reinicializações, cerca de 5 × 10⁵ avaliações, ou seja, cerca de 500 segundos, com tempo de relógio de parede crescendo aproximadamente linearmente. Isso mostra que ajustes de nível constante dentro do operador têm retorno limitado, e o foco da otimização deve estar no nível do modelo de execução, ou seja, processamento em lote, tensorização e agendamento paralelo, fazendo o tempo de relógio de parede ser determinado pelo número de lotes e não pelo número de indivíduos.
Se mudar para o modelo de execução paralela em lote, quais condições de contorno ainda precisam ser consideradas para julgar se a reformulação vale a pena. Resposta de referência: primeiro, custo e escala da avaliação — se a avaliação única cair para o nível de microssegundos, ou a população encolher para abaixo da centena, os custos de agendamento e movimentação de memória podem superar o custo de cálculo, com retorno decrescente do paralelismo; segundo, restrições de número e tamanho de lotes — o tamanho do lote é limitado por memória de vídeo, largura de banda de memória e tempo de cálculo por lote; lote muito grande eleva o tempo por lote e o custo de sincronização; terceiro, layout de dados e acesso à memória — se os indivíduos candidatos não puderem ser organizados em tensores contíguos e vetorizáveis, o processamento em lote ainda será prejudicado por acesso não contíguo. Em suma, só quando tanto o número de avaliações quanto o custo de uma avaliação são suficientemente grandes é que o retorno da reformulação do modelo de execução é significativo.
**Verificação de compreensão**
Peça aleatoriamente a um aluno que resuma os pontos principais desta página com suas próprias palavras, por exemplo, "por que o loop serial é um gargalo estrutural" e "o que determina o tempo de relógio de parede após o paralelismo". Se o aluno só souber dizer "lento", questionar nas duas dimensões: ordem de grandeza e número de lotes. Pode-se complementar com o mantra de cálculo rápido: número total de avaliações ≈ tamanho da população × número de gerações; tempo de avaliação serial ≈ número total de avaliações × tempo de uma avaliação. Lembrar de não olhar apenas para dentro do operador, e usar a forma da curva para autoverificação: aproximadamente reta indica execução ainda serial, em degraus indica organização em lotes.
> **Dica de transição**
>
> Após confirmar que os alunos conseguem dizer "o serial é gargalo do modelo de execução, e após a organização em lotes paralela o relógio de parede é determinado pelo número de lotes", passar para o conteúdo subsequente de design do grafo computacional tensorizado e agendamento paralelo.
**Base de referência**
A evolução depende da diversidade, e a diversidade implica um volume computacional enorme. O loop serial tradicional de CPU é ineficiente ao processar dezenas de milhares de avaliações de candidatos.
### Da Lista de Candidatos ao Grafo Computacional Tensorizado
*Página 5*
> **Objetivo da página:** O aprendiz deve dominar a transição central de converter o processo evolutivo de representação em lista para grafo computacional tensorizado.
> **Objetivo da página**
>
> O aprendiz deve dominar a transição central de converter o processo evolutivo de representação em lista para grafo computacional tensorizado, e ser capaz de explicar por que a evolução precisa de computação tensorial em lote, e como a tensorização muda a forma de expressão do processo evolutivo.
**Pontos-chave de ensino**
- A evolução depende da diversidade e precisa avaliar dezenas de milhares a milhões de soluções candidatas. Se os candidatos forem escritos como arrays de objetos comuns, avaliados em loop item a item, a maior parte do tempo será consumida em agendamento item a item e fluxo de controle da linguagem hospedeira, em vez de operações numéricas reais. A causa raiz da ineficiência do loop serial tradicional de CPU está aqui. O conjunto de candidatos, os resultados de avaliação e o estado do algoritmo são organizados uniformemente como tensores. A geração inteira de candidatos é escrita como um tensor de candidatos de forma [tamanho da população, dimensão da solução]
- um candidato deixa de ser um objeto independente e passa a ser um slice ou uma linha no tensor. O diagrama da página também se desenvolve nessa ordem: à esquerda, a lista de candidatos processada item a item; no meio, o tensor de candidatos; à direita, no grafo computacional, sucessivamente mutação, avaliação, seleção, atualização de estado. Operações como mutação atuam diretamente sobre toda a população, e uma única chamada completa a atualização de todos os candidatos
- a avaliação é escrita como evaluate(tensor de candidatos), obtendo o resultado de toda a geração de uma vez, e a unidade de avaliação muda de "indivíduo" para "lote". Seleção e atualização de estado deixam de ser apenas lógica de controle serial e passam a ser nós no grafo, obtendo oportunidades de otimização de compilação como fusão de operadores e agendamento paralelo. A lógica do algoritmo, como distribuição de mutação e pressão de seleção, não é reescrita
- o que é reescrito é a forma de expressão. Não se trata simplesmente de mover o loop para um dispositivo mais rápido, mas de organizar dados e operadores com o tensor como unidade mínima de processamento. Se ainda se insistir que "um candidato equivale a um objeto independente", hardware paralelo por mais amplo que seja só poderá ser alimentado serialmente com dados. A transição-chave desta página pode ser registrada como "da lista de candidatos ao grafo computacional tensorizado"
- ao ver operadores em lote, pensar em "calcular a população inteira de uma vez".
**Cobertura de palavras-chave**
- Computação tensorizada, tensor de candidatos, operadores em lote, avaliação em lote, grafo computacional, otimização de compilação, tamanho da população, dimensão da solução.
**Tratamento dos exercícios**
A resposta da questão 1 de múltipla escolha deve apontar para o custo fixo de agendamento item a item e fluxo de controle da linguagem hospedeira, e não para falta de poder computacional ou falta de diversidade. No feedback, enfatizar que quanto mais candidatos, maior a proporção desse custo.
Uma solução candidata corresponde a um slice no tensor de candidatos, por exemplo uma linha; ela não é mais vinculada como objeto independente da linguagem hospedeira.
Após seleção e atualização de estado entrarem no grafo computacional, podem obter oportunidades de otimização de compilação como fusão de operadores e agendamento paralelo, reduzindo tensores intermediários e custos de sincronização.
A saída da avaliação é mais provavelmente [tamanho da população] ou [tamanho da população, número de objetivos]; a avaliação produz, ao longo da dimensão da população, uma ou um conjunto de métricas para cada candidato.
O EvoX, no nível de expressão, muda o processamento em lista candidato por candidato para um grafo computacional em lote com o tensor como cidadão de primeira classe.
Busca de 50000 aerofólios candidatos. O gargalo da implementação original está principalmente na camada de organização de dados e agendamento: acesso objeto por objeto candidato, chamada de função item a item, comparação item a item e atualização manual de estado, além de processar apenas um candidato por vez, sem conseguir preencher a largura de paralelismo do hardware. A reformulação tensorizada não muda a pressão de seleção nem a distribuição de mutação, mas unifica candidatos, resultados de avaliação e estado do algoritmo como tensores, fazendo mutação e avaliação atuarem sobre toda a população de uma vez. Se desejar que seleção e atualização de estado também obtenham otimização de compilação, deve-se definir o tensor de candidatos como [50000, 48]; a saída da avaliação como [50000] ou [50000, número de objetivos]; a mutação incide sobre todo o tensor de candidatos; a seleção usa indexação ou máscara tensorial;
a atualização de estado é escrita como nó de redução ao longo da dimensão da população, como pegar o valor mínimo ou calcular a média.
**Verificação de compreensão**
Qual é a forma do tensor de candidatos? Qual é a forma da saída de uma avaliação? Quais dois elos passaram de lógica de controle serial para nós do grafo computacional? Se o aluno acertar os três pontos, significa que dominou a transição central desta página.
> **Dica de transição**
>
> Após confirmar que os alunos conseguem explicar com suas próprias palavras a mudança "da lista de candidatos ao grafo computacional tensorizado", passar para a próxima página de aplicações, exemplos ou resumo.
### Organização Tensorizada de População, Avaliação e Estado
*Página 6*
> **Objetivo da página:** O aprendiz deve compreender como mapear uniformemente dados populacionais, avaliação de aptidão e variáveis de estado para estruturas tensoriais.
> **Objetivo da página**
>
> Compreender como mapear uniformemente dados populacionais, avaliação de aptidão e estado de execução do algoritmo para estruturas tensoriais, formando um contrato de dados unificado que é computável em lote, residente em dispositivo e reproduzível.
> **Sequência de exposição**
>
> Começar com três perguntas — o que é a população, como está a avaliação, em que passo está a execução; depois corresponder a três tipos de contêineres — tensor de população [N, D], matrizes de avaliação e restrições [N, M] e [N, K], contêiner de estado unificado; finalmente explicar como avaliação em lote e residência de estado transformam o loop indivíduo por indivíduo em operação de lote inteiro.
**Pontos-chave de ensino**
- Organizar N soluções candidatas como tensor de codificação [N, D]. N é a dimensão de lote, D é a dimensão de características; geralmente coloca-se N na camada mais externa, para que o mesmo operador atue sobre o lote inteiro de uma só vez. Se o indivíduo é composto de múltiplos segmentos de parâmetros, pode-se dividir em blocos de campos como [N, D1] + [N, D2] + …
- indivíduos de comprimento variável usam preenchimento com máscara ou agrupamento em buckets, evitando que estruturas heterogêneas quebrem o cálculo do lote inteiro. Uma avaliação em lote produz uma matriz de aptidão [N, M]
- múltiplos objetivos, múltiplas restrições e métricas adicionais podem ser colocados lado a lado como [N, M+K] ou armazenados em tabelas separadas; o essencial é evitar chamar a função de avaliação em loop indivíduo por indivíduo. Geração, estado do gerador aleatório, hiperparâmetros de estratégia, melhor solução, cache histórico, ranking ou estado de amostragem também entram em tensores ou contêineres de estado estruturados, garantindo reprodutibilidade, rastreabilidade e atualização em lote. Tensores unificados reduzem idas e voltas entre host e dispositivo, diminuem o custo do loop e fornecem base de dados para paralelismo de operadores subsequente
- mas atenção à validade da máscara, desperdício de preenchimento, aumento do número de objetivos que alarga a matriz de avaliação, e custo de sincronização de estado.
> **Pistas de material**
>
> - O diagrama de layout de memória coloca tensor de população, matriz de avaliação, matriz de restrições e contêiner de estado unificado sob a mesma semântica de memória de dispositivo. Pode-se lembrar os alunos de prestar atenção à seta "avaliação em lote", que indica uma chamada processando o lote inteiro, em vez de chamada indivíduo por indivíduo. Quando N=1024, D=50, M=2, a população é [1024, 50], os valores de avaliação são [1024, 2], as restrições são [1024, K]. generation pode ser armazenado como escalar, best_x pode ser armazenado como tensor unidimensional [D], rng_state pode ser representado por tensor inteiro de comprimento adequado. Cada atualização de geração pode ser completada integralmente sobre a mesma dimensão de lote.
**Tratamento dos exercícios**
A compreensão central é "população, avaliação e estado mapeados uniformemente para estruturas tensoriais". Se o aluno acertar, significa que essa compreensão está alinhada com a linha principal desta página; se errar, retornar ao início da página para revisar o contrato de dados unificado.
Uma afirmação razoável deve enfatizar que a avaliação em lote gera [N, M] e [N, K], em vez de loop indivíduo por indivíduo. Basta que o julgamento conecte formas de matriz e a base da avaliação em lote.
Uma afirmação razoável deve explicar que geração, estado do gerador aleatório, melhor solução, etc. também são incorporados ao contêiner de estado unificado, facilitando checkpoint e reprodução. Se a resposta parar em "colocar dados em tensores", lembrar que também é preciso atentar para gerenciamento de estado e reprodução.
Para o cenário N=2048, D=100, M=3, K=5, sugere-se população [2048, 100], avaliação [2048, 3], restrições [2048, 5]; variáveis de estado como generation usam tensor escalar, best_x usa [100], rng_state usa tensor inteiro, cache histórico pode usar [T, 2048, 100] ou armazenamento comprimido. Na avaliação em lote, vetorizar a função de avaliação para que aceite [N, D] e retorne [N, M] e [N, K]; indivíduos de comprimento variável usam preenchimento com máscara ou agrupamento em buckets, e após o cálculo ignorar as partes inválidas pela máscara.
**Verificação de compreensão**
Peça a um aluno que explique em uma frase por que N deve ser a dimensão de lote mais externa, e diga pelo menos uma variável de estado e por que ela deve ser tensorizada. Se a resposta parar em "colocar dados em tensores", complementar: o essencial é o contrato de dados unificado e a execução de operadores sobre o lote inteiro.
> **Dica de transição**
>
> Após confirmar que os alunos conseguem distinguir os quatro tipos de contêineres — população, avaliação, restrições e estado — passar para a próxima página de exemplos, aplicações ou resumo.
### Paralelismo de Operadores e Otimização de Compilação
*Página 7*
> **Objetivo da página:** O aprendiz deve compreender os mecanismos de otimização de compilação de baixo nível quando operações como mutação e cruzamento atuam sobre toda a população.
> **Objetivo da página**
>
> Compreender que, na base computacional moderna do EvoX, a unidade mínima de execução dos operadores evolutivos muda de "indivíduo" para "tensor de população"; dominar como operadores tensorizados e compilação de grafo computacional aumentam a vazão da evolução em lote, mantendo a semântica do algoritmo inalterada.
> **Sequência de exposição**
>
> Primeiro estabelecer o julgamento "sobre quem o operador atua", depois comparar a diferença de execução entre loop indivíduo por indivíduo e operadores em nível tensorial, em seguida explicar como a compilação de grafo computacional otimiza de sequência de operadores para plano de execução, e finalmente consolidar com casos e exercícios o princípio "a eficiência muda, a semântica não".
**Pontos-chave de ensino**
- 1. O tensor de população tem forma [N, D], onde N é o tamanho da população e D é a dimensão das variáveis de decisão. Operadores como mutação, cruzamento e seleção podem atuar diretamente sobre todo o tensor de população, e uma chamada cobre todos os N indivíduos
- a dimensão do indivíduo atua como dimensão de lote, o dispositivo pode executar em paralelo em larga escala, e a vazão cresce com o tamanho da população. 2. A escrita indivíduo por indivíduo como for ind in population: ind = mutate(ind) divide cada operador em N pequenas chamadas, trazendo agendamento frequente do framework e inicialização de kernels
- cada lote tem apenas tamanho 1, as unidades paralelas do dispositivo dificilmente são preenchidas, e a criação e liberação repetida de resultados intermediários ainda aumenta o custo de alocação de memória de vídeo e movimentação de dados. A chave da reformulação é population = mutate(population_tensor), fazendo o operador executar com o tensor de população como unidade. 3. A compilação de grafo computacional organiza "mutação → cruzamento → seleção" em um grafo computacional e faz otimização global sobre o grafo inteiro: fusão de operadores pode combinar múltiplas operações elemento a elemento em menos kernels, reduzindo tensores intermediários e leitura/escrita
- geração e agendamento de kernels usam menos inicializações de kernel para completar toda a geração de evolução
- reutilização de memória pré-planeja buffers para resultados intermediários, reduzindo custos de alocação e movimentação. A otimização muda apenas "como calcular", não "o que calcular". O número de kernels, a escala de tensores intermediários, as estratégias de memória e agendamento podem mudar, mas o significado lógico de mutação, cruzamento e seleção, a ordem de combinação de operadores e a forma de uso do gerador aleatório devem permanecer consistentes
- com a mesma semente aleatória, as trajetórias por geração e os resultados antes e depois da otimização devem ser consistentes. Confundir tensorização com troca de algoritmo evolutivo, ou achar que a otimização de compilação torna o algoritmo "mais inteligente". A tensorização apenas aplica o mesmo operador sobre todo o tensor de população
- a otimização de compilação também atua apenas na camada de execução. Se após a otimização não se fizer validação de regressão, é fácil confundir diferenças de implementação com melhorias de algoritmo.
> **Pistas de material**
>
> - No diagrama, à esquerda está o tensor de população [N, D] e todos os indivíduos; no meio, o grafo computacional de operadores evolutivos "mutação → cruzamento → seleção"; à direita, a comparação entre antes da compilação — "loop indivíduo por indivíduo, múltiplas inicializações de kernel, dimensão de lote igual a 1" — e depois da compilação — "grafo computacional fusionado, poucos kernels GPU eficientes, uma passagem em lote completando toda a geração de evolução". Pode-se usar esse fluxo para ajudar os alunos a conectar tensorização e otimização de compilação.
**Tratamento dos exercícios**
Os exercícios desta página giram em torno de granularidade de execução e preservação de semântica.
O operador de mutação, em uma única chamada, geralmente atua sobre todo o tensor de população [N, D]; não é o vetor de valores da função objetivo, nem o vetor de decisão de um único indivíduo.
O loop Python/CPU indivíduo por indivíduo é lento porque grande quantidade de chamadas de pequena escala traz custos de agendamento e framework, e a dimensão de lote é 1, com baixa utilização do dispositivo.
O principal benefício da fusão de operadores é combinar múltiplas operações elemento a elemento em menos kernels, reduzindo tensores intermediários e número de inicializações de kernel; ela não muda a distribuição de probabilidade nem o significado do operador.
Muda apenas a forma de execução, não o significado lógico e a ordem de combinação de mutação, cruzamento e seleção.
A reformulação de population[i] = mutate(ind) deve ser population = mutate(population_tensor), e a sequência de operadores deve ser entregue à otimização de compilação de grafo computacional; reduzir N, trocar sintaxe de loop ou usar apenas multithreading de CPU não resolve o problema de granularidade de execução.
Tomando como exemplo uma estratégia evolutiva com tamanho de população N = 4096 e dimensão D = 128, a implementação inicial tem utilização do dispositivo abaixo de 30%, tempo por geração aproximadamente linear com N, e ocupação de memória de vídeo elevada. O diagnóstico deve recair sobre a granularidade de execução: o loop indivíduo por indivíduo amplifica o custo fixo por N, a dimensão de lote degenera para 1, as unidades paralelas não são preenchidas, e resultados intermediários são criados e liberados repetidamente. A reformulação se divide em três passos: primeiro, tensorizar operadores, fazendo mutação, cruzamento e seleção atuarem diretamente sobre o tensor [N, D]; segundo, habilitar compilação de grafo computacional, realizando fusão de operadores, geração de kernels, reutilização de memória e otimização de agendamento; terceiro, fixar a semente aleatória e fazer validação de regressão, comparando as curvas de melhor aptidão por geração e as estatísticas populacionais antes e depois da otimização.
Se as curvas praticamente coincidirem, significa que houve apenas mudança na forma de execução; se divergirem, verificar primeiro se a ordem dos operadores, o número de usos do gerador aleatório ou as regras de seleção foram alterados.
**Verificação de compreensão**
Um operador evolutivo deve atuar sobre um único indivíduo ou sobre todo o tensor de população? Qual é a cadeia de equivalência da fusão de operadores até a utilização do dispositivo? Como verificar que a otimização não alterou a semântica do algoritmo? Resposta esperada: atua sobre o tensor de população [N, D]; quanto mais fusão, menos inicializações de kernel, menos leitura/escrita de tensores intermediários, maior utilização do dispositivo; usar a mesma semente aleatória para comparar as curvas de melhor aptidão por geração e as estatísticas populacionais antes e depois da otimização.
> **Dica de transição**
>
> Após confirmar que os alunos conseguem distinguir tensorização de compilação de grafo computacional, e usar regressão com a mesma semente para verificar que a semântica não mudou, passar para a próxima página de exemplos, aplicações ou resumo.
### Design de Arquitetura de Base Aberta e Desacoplada
*Página 8*
> **Objetivo da página:** O aprendiz deve compreender os princípios de design desacoplado e a divisão dos componentes centrais da arquitetura de base do EvoX.
> **Objetivo da página**
>
> Compreender os princípios de design da base aberta e desacoplada do EvoX e a divisão de responsabilidades dos cinco módulos centrais, sendo capaz de usar "fronteiras de módulo" para julgar onde cada demanda se encaixa.
> **Sequência de exposição**
>
> Primeiro apresentar o julgamento central — pesquisadores não devem gastar tempo com comunicação paralela, alocação de dispositivos e tolerância a falhas distribuída; depois introduzir os cinco módulos de primeiro nível; finalmente usar o diagrama de arquitetura para explicar a relação em camadas entre a lógica evolutiva superior e o agendamento unificado inferior.
**Pontos-chave de ensino**
- O módulo de algoritmo define "como evoluir"
- o módulo de problema fornece interface unificada de avaliação
- o fluxo de trabalho organiza a evolução por estágios
- o módulo de monitoramento observa o processo evolutivo
- o agendador Runtime atua como camada de execução unificada, respondendo "onde calcular e como calcular". Pode-se memorizar o mantra: "lógica evolutiva em cima, agendamento de poder computacional embaixo", na ordem algoritmo → módulo de problema → fluxo de trabalho → módulo de monitoramento → agendador Runtime. O módulo de algoritmo descreve apenas lógica de busca como seleção, cruzamento, mutação e atualização, sem vincular-se a problemas específicos, nem perceber em qual placa o tensor está
- o módulo de problema encapsula simulação, função objetivo ou ambiente em interface unificada de avaliação
- o fluxo de trabalho determina a ordem de estágios como inicialização, iteração evolutiva e critério de convergência
- o módulo de monitoramento coleta métricas, registra estado populacional e curvas de convergência
- o agendador Runtime abstrai as diferenças entre GPU, dispositivos aceleradores e clusters distribuídos, assumindo detalhes de computação em lote, paralelismo e comunicação. Algoritmo e problema são independentes entre si, e problema e poder computacional são independentes entre si. Ao adicionar um novo operador de mutação, basta alterar o módulo de algoritmo
- o módulo de problema continua fornecendo interface unificada de avaliação, o fluxo de trabalho e o módulo de monitoramento mantêm a organização original, e o agendador Runtime completa automaticamente a computação tensorial em lote e a alocação de dispositivos, sem necessidade de modificar o código de execução de baixo nível. Portanto, a mesma base pode suportar cenários como aprendizado por reforço, programação genética e otimização combinatória, evitando a construção repetida de infraestrutura de engenharia de paralelismo, agendamento e distribuição. Desacoplamento não significa necessariamente desempenho mais lento. O que realmente afeta o desempenho é a forma como o agendador Runtime lida com computação em lote e utilização de dispositivos, não o número de módulos. Para julgar se a estratificação é eficiente, deve-se comparar tempo de ponta a ponta, utilização de dispositivos e proporção de comunicação
- se o custo de agendamento aumentar, deve-se otimizar as estratégias de computação em lote e utilização de dispositivos do agendador Runtime, em vez de escrever código paralelo de volta no módulo de algoritmo. Usar "precisa mudar?" para testar o desacoplamento. Trocar hardware ou escala de cluster deve alterar apenas o agendador Runtime
- trocar problema deve alterar apenas o módulo de problema
- trocar operador deve alterar apenas o módulo de algoritmo. Se uma pequena mudança afeta mais de três camadas, significa que a implementação já está excessivamente acoplada. O desacoplamento economiza engenharia repetida, não tempo de computação; ainda é necessário validar com experimentos de referência se o custo de agendamento é aceitável.
**Tratamento dos exercícios**
Os cinco módulos centrais, com exclusão do item (resposta: "buscador de hiperparâmetros", que pertence à configuração experimental ou estratégia de algoritmo, não é um módulo de primeiro nível da base); manifestação precisa de alta coesão e baixo acoplamento (resposta: a lógica interna do módulo de algoritmo é autoconsistente e não vinculada a problemas específicos, e o módulo de problema também não percebe o poder computacional subjacente); responsabilidade central do agendador Runtime (resposta: abstrair diferenças entre GPU, dispositivos aceleradores e clusters distribuídos e agendar a execução uniformemente); escopo de mudança ao adicionar novo operador de mutação (resposta: basta implementar a nova lógica no módulo de algoritmo; problema, fluxo de trabalho, monitoramento e agendamento Runtime permanecem inalterados); significado mais direto da integração aberta unificada (resposta: cada domínio reutiliza o mesmo conjunto de infraestrutura de engenharia).
No feedback, primeiro fazer os alunos voltarem às "fronteiras de responsabilidade dos cinco módulos" para buscar evidências, e depois explicar por que as outras opções quebram fronteiras ou confundem responsabilidades.
Na expansão para cluster GPU multi-nó, o módulo de algoritmo, o módulo de problema, o fluxo de trabalho e o módulo de monitoramento devem permanecer inalterados, pois suas responsabilidades não dependem da forma do poder computacional; o que precisa ser alterado ou reconfigurado é o agendador Runtime. Se houver debate entre "escrita manual de alocação de dispositivos e comunicação dentro do operador" e "dependência total do agendador Runtime", a chave da avaliação é em qual camada a mudança recai: alocação de dispositivos e comunicação pertencem à camada de execução, e escrevê-las no operador acopla detalhes de poder computacional ao módulo de algoritmo. O plano de validação é comparar, no mesmo problema de otimização combinatória, o tempo de ponta a ponta, a utilização de dispositivos e a proporção de custo de comunicação entre agendamento puro via Runtime e agendamento escrito manualmente, e registrar o custo ao migrar para outro tipo de hardware ou tarefa de aprendizado por reforço;
somente quando houver ganho significativo reproduzível que compense o custo de acoplamento e migração, considerar o rebaixamento local.
**Verificação de compreensão**
Peça aos alunos que reproduzam com suas próprias palavras os cinco módulos e as perguntas que cada um responde, e escolham uma demanda qualquer para julgar qual camada deve ser alterada. Dica de transição: após confirmar que os alunos conseguem distinguir "lógica evolutiva" de "agendamento de poder computacional", passar para os detalhes de implementação da evolução paralela tensorizada subsequente.
### Divisão entre Módulo de Algoritmo e Módulo de Problema
*Página 9*
> **Objetivo da página:** O aprendiz deve compreender as responsabilidades e formas de interação entre o módulo de algoritmo e o módulo de problema na arquitetura de base.
> **Objetivo da página**
>
> Compreender as fronteiras de responsabilidade, o contrato de interface entre o módulo de algoritmo e o módulo de problema na base aberta e desacoplada do EvoX, e o significado dessa divisão para problemas multiobjetivo, com restrições e de feedback custoso.
> **Sequência de exposição**
>
> Primeiro ancorar a divisão com uma frase — o módulo de algoritmo responde "como buscar", o módulo de problema responde "o que avaliar e como o ambiente dá feedback". Depois desenvolver as entradas e saídas de ambos, e finalmente chegar à expansão independente, composabilidade e portabilidade trazidas pela estabilidade do contrato de interface.
**Pontos-chave de ensino**
- 1. O módulo de algoritmo encapsula estratégias de busca e mecanismos evolutivos. Ele é responsável pela geração de soluções candidatas, inicialização da população, mutação, cruzamento, seleção, preservação de elite, e controle de busca como número de iterações, tamanho da população, reinicialização e critérios de convergência, agendamento de parâmetros de operadores. O ponto-chave é que ele depende apenas da premissa abstrata "a solução candidata será avaliada", sem se importar com o significado físico e a forma concreta da função objetivo. 2. O módulo de problema define critérios de avaliação e feedback do ambiente. Ele transforma soluções candidatas em feedback comparável, como valores objetivo, aptidão, quantidade de violação de restrições ou resultado de uma interação com o ambiente
- ao mesmo tempo, declara dimensões das variáveis, intervalos de valores e regras de região viável, para que o algoritmo saiba onde gerar soluções candidatas. O módulo de problema fornece avaliação consistente para o mesmo lote de soluções candidatas, permitindo comparação transversal entre diferentes indivíduos, diferentes gerações e até diferentes algoritmos. O módulo de algoritmo submete um lote de soluções candidatas, o módulo de problema retorna resultados de avaliação estruturados (vetor de objetivos, quantidade de violação de restrições e informações diagnósticas opcionais), e o módulo de algoritmo atualiza a população e avança para a próxima geração com base nisso. Um ciclo "submissão—retorno" é uma geração de evolução. A correção da direção é importante: o lado do algoritmo submete soluções candidatas a serem avaliadas, o lado do problema retorna resultados de avaliação. Expansão independente — adicionar ou substituir algoritmos não afeta a definição do problema, e modificar ou adicionar problemas não exige reescrever o módulo de algoritmo
- composabilidade — o mesmo módulo de problema pode ser conectado a diferentes algoritmos evolutivos, e o mesmo módulo de algoritmo pode ser trocado para diferentes módulos de problema
- portabilidade — desde que o contrato seja estável, ambos os lados podem ser reutilizados, substituídos e migrados entre tarefas. Problemas reais de engenharia, como design de aerofólio supercrítico, frequentemente têm múltiplos objetivos mutuamente conflitantes, restrições mutuamente aninhadas e feedback custoso e esparso. O módulo de problema converte uniformemente múltiplos objetivos e restrições em resultados de avaliação comparáveis, recorrendo a modelos substitutos para reduzir custos quando necessário
- o módulo de algoritmo mantém um conjunto de soluções candidatas diversificadas, apoiando especialistas na escolha de preferências entre sustentação, arrasto e margem de segurança. Portanto, o contrato não pode carregar apenas uma única aptidão escalar, mas também vetor de objetivos e quantidade de violação de restrições; caso contrário, informações multiobjetivo e de restrições serão permanentemente perdidas na interface.
**Cobertura de palavras-chave**
- Módulo de algoritmo, módulo de problema, lote de soluções candidatas, resultados de avaliação, vetor de objetivos, quantidade de violação de restrições, contrato de interface, expansão independente, composabilidade, portabilidade, modelo substituto. Escrever a função objetivo, o tratamento de restrições ou regras heurísticas específicas do problema no módulo de algoritmo, ou implementar seleção e atualização populacional no módulo de problema, fará com que ambos os lados se reacoplem. A pergunta de autoverificação é: "se eu mudar apenas o modelo físico, basta substituir o módulo de problema?" A resposta deve ser afirmativa. A interface deve ser "estreita e completa": estreita significa poucos campos e estáveis, transmitindo apenas dois tipos de informação — lote de soluções candidatas e resultados de avaliação
- completa significa que informações-chave não podem estar incompletas; vetor de objetivos, quantidade de violação de restrições, dimensões e limites das variáveis devem ser preservados. Retornar apenas uma única aptidão escalar é o defeito de design mais difícil de remediar posteriormente.
> **Pistas de exercício**
>
> - As cinco questões de múltipla escolha verificam respectivamente — quem é responsável pela busca, responsabilidade central do módulo de problema, direção do fluxo de dados do contrato, expansão independente após desacoplamento, consequências da aptidão escalar única. As respostas corretas apontam sucessivamente para: o módulo de algoritmo gera soluções candidatas e atualiza a população
> - o módulo de problema transforma soluções candidatas em valores objetivo, quantidade de violação de restrições ou resultados de interação com o ambiente
> - o módulo de algoritmo produz lotes de soluções candidatas, o módulo de problema retorna resultados de avaliação
> - desde que o contrato permaneça inalterado, substituir qualquer um dos lados não exige reescrever o outro
> - descartar informações de restrições impede o algoritmo de obter feedback de restrições, e problemas com restrições dificilmente serão tratados corretamente. No feedback, se o aluno acertar, pedir que explique a base
> - se errar, guiar de volta aos dois pontos "quem busca, quem avalia" e "o contrato está completo" para rejulgar. Ao migrar de otimização aerodinâmica de aerofólio para redução de peso estrutural de asa, trocar o algoritmo evolutivo não exige reescrever o módulo de problema, porque o módulo de problema só promete externamente "receber lote de soluções candidatas, retornar resultados de avaliação", independentemente do mecanismo interno de seleção, atualização ou ordenação do algoritmo. Ao reutilizar o mesmo algoritmo para minimização de peso estrutural, o módulo de problema deve retornar pelo menos três tipos de informação: valores objetivo (peso estrutural, ou vetor de objetivos se houver métricas de rigidez), quantidade de violação de restrições (grau de violação de restrições de rigidez e viabilidade geométrica), dimensões e intervalos de valores das variáveis do espaço de busca. Nenhum pode faltar, porque o algoritmo só é responsável pela busca, precisando de valores objetivo para julgar qualidade, de quantidade de violação de restrições para distinguir viável de inviável, e de limites consistentes para gerar soluções candidatas válidas.
**Atividade em sala**
Peça aos alunos que reproduzam usando âncoras de memória — módulo de algoritmo = como buscar (geração, mutação, cruzamento, seleção, controle de iteração); módulo de problema = o que avaliar (valores objetivo, quantidade de violação de restrições, feedback do ambiente). Em seguida, peça a um aluno que responda: "se eu mudar apenas o modelo físico, qual lado deve ser substituído?"
**Verificação de compreensão**
Peça aleatoriamente a um aluno que expresse com suas próprias palavras o fluxo de dados "lote de soluções candidatas ⇄ resultados de avaliação", e explique por que retornar apenas uma única aptidão escalar destruiria o tratamento de problemas com restrições.
> **Dica de transição**
>
> Após confirmar que os alunos conseguem distinguir busca de avaliação e explicar que o contrato deve ser "estreito e completo", passar para a próxima página de exemplos, aplicações ou resumo.
### Gerenciamento do Fluxo de Trabalho e do Módulo de Monitoramento
*Página 10*
> **Objetivo da página:** O aprendiz deve compreender o papel do controle de fluxo de trabalho e do módulo de monitoramento no gerenciamento do processo evolutivo.
> **Objetivo da página**
>
> Após esta página, o aprendiz deve ser capaz de distinguir as responsabilidades do módulo de fluxo de trabalho e do módulo de monitoramento, e explicar como ambos transformam o ciclo evolutivo de "caixa preta desconhecida" em um processo controlado, observável, determinável, intervenível e reproduzível.
> **Sequência de exposição**
>
> Primeiro estabelecer a divisão com uma frase — o fluxo de trabalho responde "em que ordem executar", o monitoramento responde "onde estamos agora, está bom, precisa mudar". Depois desenvolver a ordem, as arestas de retorno e as fronteiras de estágio do fluxo de trabalho, e explicar como o monitoramento coleta estado, expõe métricas e impulsiona decisões. Finalmente convergir para as três fronteiras de responsabilidade e o custo da observabilidade, usando o exemplo de evolução tensorizada em GPU para encadear toda a lógica.
**Pontos-chave de ensino**
- 1. O módulo de fluxo de trabalho orquestra passos e dependências, não a lógica do algoritmo em si. Ele define a ordem, as arestas de retorno e as fronteiras de estágio de "inicialização → avaliação (em lote) → seleção → mutação/cruzamento → atualização de estado → determinação de término", e conecta o módulo de algoritmo e o módulo de problema por interface unificada. A chave da orquestração está na granularidade e nas fronteiras: tratar "uma avaliação em lote" como um estágio agendável integralmente, em vez de avançar indivíduo por indivíduo
- as fronteiras de estágio são simultaneamente pontos de amostragem do monitoramento e pontos de troca de agendamento. 2. O módulo de monitoramento é a camada de coleta e exposição do estado de execução, rastreando continuamente métricas como tamanho da população, número de avaliações, distribuição de aptidão, convergência e diversidade, tempo por geração, memória de vídeo e vazão. Mas o propósito da observação não é registrar, e sim decidir: as métricas são usadas para acionar término, parada antecipada, reinicialização, troca de parâmetros ou estratégia, formando um ciclo fechado "monitorar → julgar → intervir". 3. A controlabilidade também exige que o estado seja serializável. O salvamento e restauração de checkpoints permitem que evoluções de longa duração sejam interrompidas e retomadas, que falhas sejam localizadas e que experimentos sejam reproduzíveis. Ao mesmo tempo, o desacoplamento exige que o monitoramento seja montado por callbacks ou hooks, sem invadir o módulo de algoritmo e o módulo de problema; assim, diferentes backends de monitoramento como console, log e painel de curvas podem ser trocados, sem alterar o algoritmo central. O fluxo de trabalho gerencia "ordem e estágios", o monitoramento gerencia "estado e métricas", o agendador de runtime gerencia "recursos e mapeamento paralelo". Erros comuns são enfiar mapeamento de recursos ou lógica de algoritmo no fluxo de trabalho, ou enfiar controle de ordem no monitoramento, causando acoplamento e irreprodutibilidade. A observabilidade também tem custo: amostragem de alta frequência e retorno sincronizado podem interromper o pipeline paralelo, portanto frequência de amostragem, forma de agregação de métricas e estratégia de gravação assíncrona precisam ser ponderadas conforme o objetivo do experimento. O fluxo de trabalho agenda "avaliação em lote" como um estágio inteiro
- o módulo de monitoramento registra, dentro do mesmo estágio, a melhor aptidão e a média por geração, a diversidade populacional e o tempo por geração
- quando as métricas estagnam por N gerações consecutivas, aciona a determinação de término ou muda para uma estratégia de perturbação maior, e grava checkpoint sincronizadamente, tornando essa evolução tanto reproduzível quanto retomável a partir do ponto de interrupção.
**Cobertura de palavras-chave**
- Módulo de fluxo de trabalho, módulo de monitoramento, passos e dependências, fronteiras de estágio, arestas de retorno, avaliação em lote, observabilidade, monitorar→julgar→intervir, checkpoint, callback/hook, fronteiras de responsabilidade, custo de amostragem.
> **Pistas de exercício**
>
> - Os exercícios desta página giram em torno de cinco julgamentos. O objeto direto de orquestração do fluxo de trabalho são passos e dependências, e não fórmulas de operadores, mapeamento de memória de vídeo ou codificação da função objetivo
> - tratar a avaliação em lote como estágio integral se deve a que granularidade e fronteiras são mais adequadas, e as fronteiras de estágio também assumem amostragem de monitoramento e troca de agendamento
> - o propósito fundamental do monitoramento é a decisão, não o arquivamento a posteriori
> - a montagem por callback ou hook serve ao desacoplamento, permitindo trocar o backend de monitoramento
> - a observabilidade exige ponderar frequência de amostragem, agregação de métricas e estratégia de gravação, porque amostragem de alta frequência pode interferir no pipeline paralelo. Ao acertar, enfatizar que a base vem das duas linhas "ordem e estágios" e "monitorar→julgar→intervir"
> - ao errar, voltar às fronteiras de responsabilidade, distinguindo as quatro categorias: lógica de algoritmo, mapeamento de recursos, controle de ordem e coleta de estado.
**Verificação de compreensão**
Pode-se usar o caso "pausa suspeita em evolução tensorizada de longa duração" para verificar o domínio. Primeiro, usar as fronteiras de estágio para separar o tempo de avaliação em lote, seleção, mutação e atualização de estado, julgando de qual estágio vem o aumento do tempo por geração; depois, sobrepor as duas curvas de estagnação da aptidão média e queda da diversidade, julgando se é convergência estabilizando ou armadilha de ótimo local. O plano de tratamento é organizado por "monitorar → julgar → intervir": a camada de monitoramento coleta número de gerações de estagnação de aptidão, diversidade e tempo por geração; a camada de julgamento define "melhoria abaixo do limiar por N gerações consecutivas e diversidade abaixo do limite inferior" como estagnação, e "tempo por geração acima do limiar" como anomalia de recursos; a camada de intervenção aciona troca de estratégia, parada antecipada ou reinicialização, e ajusta tamanho de lote ou mapeamento paralelo para a anomalia de tempo.
Antes do tratamento, gravar checkpoint para garantir reprodutibilidade do experimento, localização de falhas e retomada de evolução longa a partir do ponto de interrupção.
> **Dica de transição**
>
> Após confirmar que os alunos conseguem dizer "o fluxo de trabalho gerencia ordem e estágios, o monitoramento gerencia estado e métricas, o agendador gerencia recursos e mapeamento paralelo", passar para a próxima página.
### Agendador Runtime e Gerenciamento de Poder Computacional Heterogêneo
*Página 11*
> **Objetivo da página:** O aprendiz deve dominar o papel central do agendador Runtime na alocação de hardware heterogêneo e na composabilidade de algoritmos.
> **Objetivo da página**
>
> Dominar a posição do agendador Runtime no EvoX — ele é o centro de execução que conecta a lógica do algoritmo ao hardware físico, responsável por mapear algoritmos evolutivos superiores, definições de problema e fluxo de trabalho para recursos heterogêneos como GPU, dispositivos aceleradores (TPU/NPU) e clusters distribuídos, mantendo a alta composabilidade dos módulos de algoritmo enquanto abstrai as diferenças de hardware.
> **Sequência de exposição**
>
> 1. Primeiro distinguir a camada de algoritmo da camada de execução. A camada de algoritmo foca em "o que fazer", o Runtime foca em "onde fazer e como fazer". Essa separação é a chave para entender a arquitetura EvoX.
>
> Agendamento de poder computacional heterogêneo, gerenciando uniformemente GPU, dispositivos aceleradores e clusters distribuídos, distribuindo tarefas, operadores e grafos computacionais tensoriais para backends adequados; coordenação de dependências e estado, garantindo sincronização correta de relações de dependência entre tarefas e estado de execução; interface unificada de agendamento, para que a camada de algoritmo submeta tarefas sem se vincular a dispositivos ou formas de cluster específicos; composabilidade de módulos, suportando combinação, substituição e reutilização modular de algoritmos, problemas, operadores e backends de execução.
>
> Ao mudar o mesmo conjunto de algoritmos evolutivos de GPU de máquina única para cluster multi-máquina, o código da camada de algoritmo permanece inalterado, e o Runtime remapeia tarefas computacionais e backends de execução. Pesquisadores podem assim focar na inovação de algoritmos, sem reescrever código para cada tipo de hardware.
>
> A camada superior é a camada de algoritmo e fluxo de trabalho (módulo de algoritmo, definição de problema, fluxo de trabalho); no meio está o agendador Runtime e a interface unificada de agendamento; a camada inferior é a camada de poder computacional heterogêneo (GPU, TPU/NPU, cluster distribuído); para baixo transmitem-se tarefas, operadores e grafos computacionais; para cima retornam-se estados e resultados.
**Pontos-chave de ensino**
- O Runtime não implementa lógica de algoritmo evolutivo, nem define a função objetivo do problema
- sua responsabilidade é agendamento e mapeamento. Os recursos de execução que ele gerencia são recursos de hardware, como GPU, dispositivos aceleradores e clusters distribuídos
- o código-fonte do módulo de algoritmo pertence à camada de algoritmo, e não é objeto de agendamento do Runtime. A camada de algoritmo só precisa descrever o que fazer, sem se preocupar com em qual hardware fazer; assim, o mesmo conjunto de algoritmos pode migrar para ambientes de máquina única, multi-placa ou跨 cluster. Composabilidade significa que algoritmos, problemas, operadores e backends de execução podem ser livremente combinados, substituídos e reutilizados, em vez de ficarem presos a um único backend de hardware.
**Cobertura de palavras-chave**
- Agendador Runtime, agendamento de poder computacional heterogêneo, coordenação de dependências e estado, interface unificada de agendamento, composabilidade de módulos, GPU, dispositivos aceleradores, TPU/NPU, cluster distribuído, camada de algoritmo, camada de execução.
> **Pistas de material**
>
> - Esta página traz um diagrama de arquitetura do agendador Runtime conectando dispositivos de hardware e algoritmos superiores. No diagrama, a camada superior é a camada de algoritmo e fluxo de trabalho; no meio está o agendador Runtime e a interface unificada de agendamento; a camada inferior é a camada de poder computacional heterogêneo
> - as setas indicam tarefas/operadores/grafos computacionais distribuídos para baixo, e estados/resultados retornando para cima. Ao explicar o diagrama, pode-se pedir aos alunos que reproduzam ao longo das setas "o que a camada superior submete, o que o Runtime faz, o que a camada inferior retorna".
**Tratamento dos exercícios**
A resposta correta da questão 1 de múltipla escolha é mapear algoritmos e fluxo de trabalho para recursos heterogêneos de poder computacional, abstraindo diferenças de hardware. Ponto de feedback: o Runtime é o centro de execução, não implementa lógica de algoritmo nem define problemas.
O Runtime gerencia recursos de execução de hardware; o código-fonte pertence ao conteúdo da camada de algoritmo.
A resposta correta da questão 3 de múltipla escolha é que, por meio da interface unificada de agendamento, a camada de algoritmo não precisa se vincular a dispositivos ou formas de cluster específicos. Ponto de feedback: reduzir acoplamento significa que a camada de algoritmo não precisa escrever código diferente para cada tipo de hardware.
A resposta correta da questão 4 de múltipla escolha é que algoritmos, problemas, operadores e backends de execução se combinam, substituem e reutilizam modularmente. Ponto de feedback: a composabilidade se manifesta na livre combinação e substituição de componentes.
A resposta correta da questão 5 de múltipla escolha é remapear tarefas computacionais e backends de execução, com o código da camada de algoritmo permanecendo inalterado. Ponto de feedback: o Runtime ajusta dinamicamente o mapeamento de tarefas, sem necessidade de modificar a camada de algoritmo.
No cenário de design multiobjetivo de aerofólio, a equipe otimiza simultaneamente o coeficiente de sustentação e a razão sustentação/arrasto em cruzeiro, e migra o mesmo código de algoritmo entre GPU de máquina única e cluster distribuído. Ao responder, atentar para dois pontos: primeiro, o Runtime, por meio da interface unificada de agendamento, mapeia tarefas, operadores e grafos computacionais para backends de hardware específicos; quando o hardware muda, o código da camada de algoritmo permanece inalterado, e o Runtime remapeia e divide o grafo computacional, coordenando dependências de tarefas e sincronização de estado. Segundo, no agendamento é preciso considerar características computacionais e relações de dependência das tarefas, capacidades de hardware (como paralelismo de GPU, custo de comunicação do cluster), execução paralela de avaliações multiobjetivo e sincronização sob feedback esparso, além do retorno de estado, garantindo implantação eficiente跨 hardware sem quebrar a composabilidade.
**Verificação de compreensão**
Peça aos alunos que expliquem com suas próprias palavras "a camada de algoritmo foca em o que fazer, o Runtime foca em onde fazer e como fazer", e exemplifiquem qual camada muda e qual permanece inalterada ao trocar de GPU para cluster. Se o aluno só memorizar nomes de hardware sem explicar a relação de agendamento e mapeamento, pode-se guiá-lo de volta às relações de setas do diagrama de arquitetura.
> **Dica de transição**
>
> Após confirmar que os alunos conseguem expressar o papel de agendamento e mapeamento do Runtime, e explicar a migração跨 hardware com interface unificada e composabilidade, passar para a próxima página de exemplos, aplicações ou resumo.
### Aplicações Multidomínio Suportadas pela Base Unificada
*Página 12*
> **Objetivo da página:** O aprendiz deve compreender como essa base unificada suporta tarefas amplas como aprendizado por reforço, programação genética e otimização combinatória.
> **Sequência de exposição**
>
> Começar com uma frase que esclarece "base unificada = integração aberta + execução tensorizada + agendamento Runtime. Ao ver 'aplicações multidomínio', autoverificar com estas três perguntas: por onde a tarefa se integra? Como as soluções candidatas são avaliadas em lote? Quem gerencia uniformemente o poder computacional e o estado?", e depois explicar por que isso é importante com base nos exemplos, diagramas ou palavras-chave da página.
**Pontos-chave de ensino**
- Base unificada = integração aberta + execução tensorizada + agendamento Runtime. Ao ver "aplicações multidomínio", autoverificar com estas três perguntas: por onde a tarefa se integra? Como as soluções candidatas são avaliadas em lote? Quem gerencia uniformemente o poder computacional e o estado?
- Paralelismo de passos de ambiente, evolução de estrutura de árvore de programa e mapeamento tensorial discreto pertencem à camada de adaptação
- fluxo de avaliação, gerenciamento de estado, organização de operadores e agendamento pertencem à camada compartilhada. Se a estrutura proprietária de um domínio for escrita diretamente na lógica de agendamento compartilhada, significa que o nível de abstração foi escolhido errado.
- Esta página responde apenas "o que a base unificada pode suportar". Questões como vazão, custo de agendamento e detalhes de implementação de tensores em lote devem ser deixadas para o escopo de aprendizado posterior sobre eficiência computacional e métodos de tensores em lote, sem se prender aqui.
Aplicações multidomínio suportadas pela base unificada
11
AI999
Base Computacional Moderna e Evolução Paralela Tensorizada
Tarefas de controle e decisão exigem interação contínua com ambientes em mudança; tarefas de design estrutural exigem busca em espaços variáveis de programas e expressões; tarefas de alocação de recursos e planejamento de rotas exigem resolução em permutações e restrições discretas. Se para cada tipo de problema fosse reconstruído um sistema separado, interfaces de avaliação, armazenamento de estado, biblioteca de operadores e agendamento de poder computacional teriam que ser reimplementados, com custo de migração de engenharia extremamente alto. A ideia central da base unificada é usar o mesmo conjunto de infraestrutura evolutiva para suportar essas tarefas heterogêneas, fazendo aplicações multidomínio compartilharem avaliação, estado, operadores e gerenciamento de poder computacional.
Integração aberta (integrar tarefas com especificações unificadas de registro e interface), execução tensorizada (organizar soluções candidatas em lotes, avaliar em paralelo), agendamento em runtime (distribuir tarefas em poder computacional heterogêneo e manter estado). Os três juntos garantem reutilização跨 domínio, e também explicam por que a capacidade "fornecer uma base unificada de integração aberta para aprendizado por reforço, programação genética e otimização combinatória" merece ser discutida separadamente.
Aplicações multidomínio suportadas pela base unificada Mesma base de integração aberta · Fluxo de avaliação, gerenciamento de estado, organização de operadores e agendamento de poder computacional compartilhados Capacidades da base / Domínios de tarefa Aprendizado por reforço Programação genética Otimização combinatória Integração aberta Interface de integração de ambiente Integração de estrutura de programa Integração de solução e restrições Interação paralela com ambiente Amostragem em lote multi-ambiente — — Evolução de estrutura de árvore de programa — Mutação / Cruzamento — Resolução tensorizada Avaliação em lote de políticas Tensorização de estrutura Lotes de candidatos e restrições Agendamento Runtime e gerenciamento de estado Agendamento e estado compartilhados Agendamento e estado compartilhados Agendamento e estado compartilhados Camada de adaptação: absorve diferenças de domínio —— Paralelismo de passos de ambiente · Evolução de estrutura de árvore de programa · Mapeamento tensorial discreto Base unificada: integração aberta · execução tensorizada · agendamento Runtime e gerenciamento de estado Como três tipos típicos de tarefas recaem sobre a mesma base Aprendizado por reforço: a base fornece capacidade de interação paralela com ambientes, suportando amostragem em lote de múltiplas instâncias de ambiente, avaliação paralela em lote de um conjunto de políticas candidatas, e formando um ciclo fechado com a otimização evolutiva.
A base suporta a evolução de estruturas variáveis e hierárquicas como árvores de programa, podendo lidar com representações estruturais e suas mutações e cruzamentos dentro de um fluxo unificado de população e avaliação. Otimização combinatória: adaptar decisões discretas, seleções, permutações e objetivos com restrições para resolução tensorizada, aumentando a vazão de busca por meio de candidatos em lote e avaliação paralela. O que é compartilhado, o que é adaptado As diferenças de domínio são absorvidas pela camada de adaptação: aprendizado por reforço foca no paralelismo dos passos de ambiente, programação genética foca na evolução da estrutura de árvore de programa, otimização combinatória foca no mapeamento de decisões discretas para tensores. Os três compartilham o agendamento Runtime e o gerenciamento de estado subjacentes — compartilham fluxo de avaliação, portador de estado, forma de organização de operadores e gerenciamento de poder computacional, em vez de reconstruir sistemas para cada tipo de problema.
Se a estrutura proprietária de um domínio for escrita diretamente na lógica de agendamento compartilhada, isso indica que o nível de abstração foi escolhido errado. Escopo desta página Esta página foca em "o que a base unificada pode suportar", sem desenvolver comparações específicas de desempenho e detalhes de implementação do agendador; isso fica para a parte posterior sobre eficiência computacional e métodos de tensores em lote.
Qual é o valor primordial de uma base unificada de integração aberta?
Permitir que diferentes domínios reutilizem avaliação, estado, operadores e gerenciamento de poder computacional, reduzindo significativamente o custo de migração de engenharia
Substituir aprendizado por reforço, programação genética e otimização combinatória por um único algoritmo unificado
Comprimir todas as tarefas em uma mesma representação vetorial de comprimento fixo
Reconstruir sistemas e cadeias de ferramentas independentes para cada novo tipo de problema
As formas das tarefas são diferentes, mas especificações de integração, avaliação em lote, gerenciamento de estado e agendamento de poder computacional podem ser compartilhados; novos problemas só precisam descrever suas diferenças na camada de adaptação.
"Reconstruir sistemas para cada tipo de problema" é exatamente o problema que a base visa resolver; ao mesmo tempo, a base também não exige que todas as tarefas compartilhem o mesmo algoritmo ou a mesma representação; as diferenças são absorvidas pela camada de adaptação.
Correto. Esta resposta consegue conectar-se aos conceitos desta página e explicar a base.
Por favor, volte à explicação desta página, encontre evidências-chave ou exemplos antes de julgar.
Em cenários de aprendizado por reforço, qual capacidade-chave a base unificada fornece principalmente?
Operadores de mutação e cruzamento de árvore de programa
Passos seriais suportando apenas uma única instância de ambiente
Amostragem em lote de múltiplas instâncias de ambiente e coleta de trajetórias, com avaliação paralela de um conjunto de políticas candidatas
Interface de modelagem de permutações e restrições discretas
Múltiplas instâncias de ambiente avançam simultaneamente, trajetórias são coletadas em lote, políticas candidatas são avaliadas em paralelo, formando um ciclo fechado com a otimização evolutiva.
A evolução de estrutura de árvore de programa é um ponto de adaptação da programação genética; a modelagem de restrições discretas é um ponto de adaptação da otimização combinatória; a chave do aprendizado por reforço é o paralelismo em lote da interação com o ambiente, não o serial de instância única.
Ao integrar tarefas de programação genética à base unificada, qual característica-chave a base deve suportar?
Processar apenas vetores de números reais de comprimento fixo
Representação e evolução de estruturas variáveis e hierárquicas como árvores de programa, incluindo mutação e cruzamento estruturais
Obrigatoriamente codificar a árvore de programa como cadeia binária de comprimento fixo antes de evoluir
Processar apenas funções objetivo contínuas sem restrições
As soluções candidatas da programação genética são estruturas de programa variáveis e hierárquicas; a base precisa acomodar essa representação em um fluxo unificado de população e avaliação, e suportar mutação e cruzamento correspondentes.
Vetores de comprimento fixo são a representação típica de otimização contínua; a característica central da programação genética é justamente a estrutura de árvore de programa variável e hierárquica, e as operações evolutivas voltadas a estruturas.
Ao integrar tarefas de otimização combinatória à base unificada, qual é o trabalho de adaptação mais crítico?
Eliminar todas as restrições e manter apenas um único objetivo
Reescrever o problema como tarefa de treinamento de rede neural contínua e diferenciável
Compilar um solucionador dedicado separadamente para cada instância do problema
Adaptar decisões discretas, seleções, permutações e objetivos com restrições para resolução tensorizada
Soluções candidatas e restrições são organizadas em lotes, reutilizando a capacidade de candidatos em lote e avaliação paralela da base.
Compilar solucionadores dedicados por instância equivale a voltar ao velho caminho de "reconstruir o sistema"; abandonar restrições também muda o próprio problema; nenhum dos dois é a adaptação exigida pela base.
Sobre a divisão entre camada compartilhada e camada de adaptação, qual das compreensões a seguir está correta?
A lógica de agendamento deve ser escrita separadamente para aprendizado por reforço, programação genética e otimização combinatória
A camada de adaptação só faz exibição de interface, sem participar de nenhuma conversão semântica de tarefas
A camada compartilhada é responsável pela evolução de estrutura de árvore de programa, a camada de adaptação pelos passos de ambiente
As diferenças de domínio são absorvidas pela camada de adaptação; os três tipos de tarefas compartilham o agendamento Runtime e o gerenciamento de estado subjacentes
Paralelismo de passos de ambiente, evolução de estrutura de árvore de programa e mapeamento tensorial discreto pertencem à camada de adaptação; fluxo de avaliação, gerenciamento de estado, organização de operadores e agendamento pertencem à camada compartilhada.
Escrever estruturas proprietárias de domínio na lógica de agendamento compartilhada, ou deixar a camada compartilhada lidar com evolução estrutural específica de um domínio, são erros de divisão de camadas.
O mesmo runtime suporta três tipos de tarefas heterogêneas
Leia o cenário e responda.
Uma equipe de algoritmos está construindo uma plataforma de computação evolutiva. Anteriormente, mantinham três sistemas independentes para controle por aprendizado por reforço, regressão simbólica (busca de estrutura de programa) e planejamento de rotas logísticas: cada um tinha sua própria interface de avaliação, armazenamento de estado e agendamento de poder computacional, com código severamente duplicado, e trocar de tarefa exigia reescrever o fluxo. A nova solução mudou para uma base unificada suportando esses três tipos de tarefas: tarefas de aprendizado por reforço avançam em paralelo múltiplas instâncias de ambiente e coletam trajetórias; tarefas de programação genética avaliam em paralelo populações de árvores de programa; tarefas de otimização combinatória organizam soluções candidatas e restrições em lotes tensoriais, com agendamento unificado distribuindo poder computacional heterogêneo.
1. Por que a equipe abandonou a manutenção de sistemas separados para cada tipo de problema? Explique sob a perspectiva de reutilização e custo de migração.
Integração de tarefas, avaliação em lote de soluções candidatas, gerenciamento de estado de candidatos e população, organização de operadores e agendamento de poder computacional. Manter separadamente significa que essas capacidades são reimplementadas três vezes, e qualquer nova tarefa exige reconstruir todo o fluxo, com custo de migração de engenharia muito alto. A base unificada permite que os três tipos de tarefas reutilizem o mesmo conjunto de fluxo de avaliação, portador de estado, forma de organização de operadores e gerenciamento de poder computacional; novas tarefas só precisam descrever suas próprias diferenças na camada de adaptação para se integrar.
2. Indique as diferenças que os três tipos de tarefas absorvem respectivamente na camada de adaptação, e explique o que eles reutilizam na camada compartilhada.
Aprendizado por reforço foca no paralelismo dos passos de ambiente (amostragem em lote de múltiplas instâncias de ambiente, coleta de trajetórias e avaliação em lote de políticas); programação genética foca na representação e evolução de estruturas variáveis e hierárquicas como árvores de programa (mutação e cruzamento estruturais); otimização combinatória foca em mapear decisões discretas, seleções, permutações e objetivos com restrições para resolução tensorizada. A camada compartilhada reutiliza: especificação de integração aberta, execução em lote tensorizada, agendamento Runtime e gerenciamento de estado, além da alocação unificada de poder computacional heterogêneo. Justamente porque as diferenças são reunidas na camada de adaptação e os pontos comuns ficam na camada compartilhada, não é necessário reconstruir sistemas para cada tipo de problema.
Lembre-se primeiro dos três pilares
Base unificada = integração aberta + execução tensorizada + agendamento Runtime. Ao ver "aplicações multidomínio", autoverificar com estas três perguntas: por onde a tarefa se integra? Como as soluções candidatas são avaliadas em lote? Quem gerencia uniformemente o poder computacional e o estado?
Distinguir camada compartilhada e camada de adaptação
Paralelismo de passos de ambiente, evolução de estrutura de árvore de programa e mapeamento tensorial discreto pertencem à camada de adaptação; fluxo de avaliação, gerenciamento de estado, organização de operadores e agendamento pertencem à camada compartilhada. Se a estrutura proprietária de um domínio for escrita diretamente na lógica de agendamento compartilhada, isso indica que o nível de abstração foi escolhido errado.
Os limites desta página
Esta página responde apenas "o que a base unificada pode suportar". Questões como vazão, custo de agendamento e detalhes de implementação de tensores em lote devem ser deixadas para o escopo de aprendizado posterior sobre eficiência computacional e métodos de tensores em lote, sem se prender aqui.
step-1
O aprendiz deve compreender como essa base unificada suporta tarefas amplas como aprendizado por reforço, programação genética e otimização combinatória.
lesson_4
lesson_4_slide_11
Do rascunho EvoClass
Fornece uma base unificada de integração aberta para aprendizado por reforço, programação genética e otimização combinatória
lesson_id_distribution
67ee25ab22558e4ae0e13f24b7c34c2da1218107cceb1cd331b38fc3521a9743
**Base de referência**
Do rascunho EvoClass (página 4-4)
> **Pistas de material**
>
> - Fornece uma base unificada de integração aberta para aprendizado por reforço, programação genética e otimização combinatória
**Atividade em sala**
Peça aos alunos que reproduzam o conteúdo desta página com um exemplo próximo de sua experiência, e expliquem a relação entre esse exemplo e "base unificada = integração aberta + execução tensorizada + agendamento Runtime. Ao ver 'aplicações multidomínio', autoverificar com estas três perguntas: por onde a tarefa se integra? Como as soluções candidatas são avaliadas em lote? Quem gerencia uniformemente o poder computacional e o estado?".
> **Objetivos correspondentes**
>
> - Dominar o método de expressar o processo evolutivo como computação tensorial em lote
> - Compreender o papel do Runtime no agendamento de poder computacional heterogêneo e na manutenção da composabilidade de algoritmos
**Verificação de compreensão**
Peça aleatoriamente a um aluno que resuma os pontos principais desta página com suas próprias palavras, e o instrutor complementa palavras-chave faltantes conforme a resposta.
> **Dica de transição**
>
> Após confirmar que os alunos conseguem expressar a relação central desta página, passar para a próxima página de exemplos, aplicações ou resumo.
### Prática de Análise Comparativa de Eficiência Computacional
*Página 13*
> **Objetivo da página:** O aprendiz deve compreender, por meio de comparação prática, a diferença de eficiência entre travessia serial em CPU e processamento em lote tensorizado em GPU.
> **Objetivo da página**
>
> Traduzir a comparação de eficiência computacional em uma prática reproduzível, compreendendo a diferença de eficiência de ponta a ponta entre travessia serial de indivíduos em CPU e processamento em lote tensorizado em GPU, esclarecendo de onde vem a aceleração, qual é o custo e onde estão os limites.
> **Sequência de exposição**
>
> Primeiro apresentar as duas linhas de base na mesma tarefa evolutiva, depois observar o gráfico de barras de comparação de eficiência, em seguida explicar o protocolo de medição reproduzível, e finalmente sintetizar fontes de ganho, condições de restrição e conclusões práticas.
**Pontos-chave de ensino**
- Usar loop para chamar a função de avaliação indivíduo por indivíduo; cada geração precisa de N agendamentos independentes, atualizações de estado e agregação de resultados. Controle de loop, custo do interpretador e acesso disperso à memória diluem o poder computacional efetivo
- quanto mais indivíduos, maior a proporção desses custos não computacionais. Organizar população, entradas de avaliação e estado de execução como tensores, executando avaliação e operadores em lote na GPU, com uma chamada cobrindo todo o conjunto de candidatos, reduzindo drasticamente loops seriais e número de agendamentos. Sob condições de mesmo problema, mesma população, mesma semente aleatória, e medição após aquecimento e sincronização de dispositivo, o loop serial de CPU é a referência 1.0×, o processamento em lote GPU com b=64 é cerca de 2.2×, b=256 cerca de 4.5×, b=1024 cerca de 7.1×. O gráfico mostra valores relativos de tempo por geração; quanto maior o tamanho do lote, mais facilmente o custo fixo é diluído. Fixar problema, tamanho da população, número de gerações e semente aleatória
- registrar tempo real por geração, tempo total, vazão (avaliações/segundo), razão de aceleração, utilização de GPU e ocupação de memória de vídeo. Antes de cronometrar, fazer aquecimento, excluindo efeitos de primeira compilação e alocação de memória de vídeo
- os pontos de cronometragem devem fazer sincronização de dispositivo
- separar estatisticamente o tempo de cálculo do tempo de transferência de dados host—dispositivo. Faltando qualquer um desses elos, a razão de aceleração pode ficar distorcida. O ganho vem do paralelismo em lote, operadores tensorizados e paralelismo dentro do dispositivo, fazendo uma chamada processar todo o conjunto de candidatos
- as restrições incluem tamanho do lote, dimensão do problema, grau de vetorização da função de avaliação, custo de cópia host—dispositivo e custo de inicialização de kernel. Lote muito pequeno tem o ganho comido pelo custo de inicialização
- se a função de avaliação não puder ser vetorizada, o processamento em lote quase não terá como atuar. A ordem correta é primeiro verificar se a função de avaliação pode ser batelizada, depois comparar implementações CPU e GPU. A vantagem de eficiência deve, em última análise, recair sobre "obter mais gerações ou mais soluções candidatas sob o mesmo orçamento computacional", e com base nisso decidir a forma de implantação e o design experimental, em vez de buscar apenas o número da razão de aceleração.
**Tratamento dos exercícios**
A resposta correta da questão 1 é "o custo de agendamento, interpretador e acesso disperso à memória trazido por chamar a função de avaliação independentemente para cada indivíduo". A linha de base serial gera N agendamentos e atualizações de estado independentes por geração; controle de loop, custo do interpretador e acesso disperso à memória diluem o poder computacional efetivo; nesse momento ainda não há inicialização de kernel GPU nem cópia.
A resposta correta da questão 2 é organizar população, entradas de avaliação e estado de execução em tensores, com uma chamada cobrindo todo o conjunto de candidatos. O núcleo da aceleração é paralelismo em lote e tensorização, não mudança de precisão, tamanho de população ou número de sementes.
A resposta correta da questão 3 é o protocolo padrão: fixar problema, tamanho da população, gerações e semente, aquecer e fazer sincronização de dispositivo antes de cronometrar, e distinguir tempo de cálculo de tempo de transferência de dados.
A GPU frequentemente executa de forma assíncrona; sem sincronização, a cronometragem pode perder cálculos ainda não concluídos, subestimando o tempo e inflando a razão de aceleração; a sincronização em si não aumenta o poder computacional, nem elimina a transferência de dados.
Quando a função de avaliação tem baixo grau de vetorização, a vantagem do processamento em lote GPU diminui significativamente, podendo até ter retorno limitado devido a custos de cópia e inicialização de kernel; a aceleração não é constante, nem cresce sem limite com o aumento do lote.
Prática do caso:
1. A aceleração de cerca de 9× obtida sem sincronização de dispositivo é provavelmente não confiável. O host, após despachar o kernel, não espera sua conclusão para continuar a execução; se o ponto de cronometragem não sincronizar, o tempo medido pode cobrir apenas a fase de despacho do kernel, omitindo o cálculo real ainda em execução, subestimando gravemente o tempo da GPU e inflando a razão de aceleração. A correção é: chamar sincronização de dispositivo em cada ponto de cronometragem, garantindo que todo o trabalho despachado esteja realmente concluído antes de ler o timestamp; fazer iterações de aquecimento primeiro, e separar estatisticamente o tempo de transferência host—dispositivo do tempo de cálculo puro. Somente o tempo por geração e o tempo total medidos sob condições de semente fixa, aquecimento e sincronização podem servir como base confiável.
2. A razão de aceleração de apenas cerca de 1.2× com lote pequeno b=8 não é contraditória. O ganho do processamento em lote é restringido conjuntamente por tamanho do lote, custo de inicialização de kernel e custo de transferência de dados; lote muito pequeno significa trabalho paralelizável insuficiente no dispositivo, com custo fixo ocupando grande proporção do tempo por geração, e paralelismo efetivo incapaz de diluir esses custos, fazendo a razão de aceleração se aproximar naturalmente de 1. Sugere-se aumentar o tamanho do lote dentro do limite de memória de vídeo, vetorizar ao máximo a função de avaliação e a lógica de pós-processamento, e remedir pelo protocolo padrão, reportando separadamente tempo por geração, tempo total, vazão e razão de aceleração, para julgar se o ganho realmente recai sobre o objetivo de obter mais gerações ou mais candidatos sob o mesmo orçamento.
**Verificação de compreensão**
Peça aleatoriamente aos alunos que expliquem com suas próprias palavras por que verificar primeiro se a função de avaliação é vetorizável antes de comparar CPU e GPU; e digam o que o aquecimento e a sincronização de dispositivo resolvem respectivamente.
> **Dica de transição**
>
> Após confirmar que os alunos conseguem distinguir fontes de ganho e condições de restrição, e converter a aceleração em ganho de orçamento, passar para a próxima página de exemplos, aplicações ou resumo.
### Métodos Centrais de Computação Tensorial em Lote
*Página 14*
> **Objetivo da página:** O aprendiz deve consolidar os métodos centrais de expressar o processo evolutivo como computação tensorial em lote.
> **Objetivo da página**
>
> Consolidar os métodos centrais de expressar o processo evolutivo como computação tensorial em lote, compreendendo a relação entre dimensão de lote, operadores em lote, otimização de grafo computacional e métricas de vazão, sendo capaz de identificar pseudo-batelização.
> **Sequência de exposição**
>
> O tensor de candidatos X é [N × D], os objetivos e restrições F são [N × M], a saída de avaliação Y é [N × M]; a dimensão de lote N está sempre na camada mais externa, e D e M descrevem o número de variáveis e o número de itens objetivo de um único candidato.
>
> Mapear uniformemente população, objetivos/restrições, saída de avaliação e estado evolutivo para tensores com dimensão de lote, mantendo variáveis de estado em escalares ou pequenos buffers tensoriais, em vez de registrá-las indivíduo por indivíduo em objetos Python.
>
> Mutação X′ = X + σ·randn(X), cruzamento pareando e recombinando ao longo da dimensão N, seleção idx = topk(F, k), avaliação Y = fθ(X). O ponto importante não é a expressão individual, mas que todos os candidatos compartilham o mesmo grafo de operações tensoriais, com uma chamada em lote substituindo N chamadas de candidato único; restrições e violações de limites podem ser tratadas na mesma operação em lote com tensores de máscara.
>
> A fusão de operadores reduz inicializações de kernel, o paralelismo dentro do lote faz todos os candidatos executarem simultaneamente, a execução assíncrona sobrepõe cálculo e transferência, e a reutilização de memória reduz alocações de tensores intermediários.
>
> Mudar de latência de passo único para candidatos/segundo ou gerações/segundo, porque uma chamada em lote carrega todo o lote de candidatos, e a vazão total é que reflete a eficiência de busca.
>
> Encaixar operadores em lote dentro de loops Python indivíduo por indivíduo reintroduz o custo do interpretador e o custo de inicialização de kernel, tornando a dimensão de lote ilusória. Método de autoverificação: em um passo evolutivo, o nível de agendamento deve ter apenas "lote", sem "indivíduo".
**Pontos-chave de ensino**
- A dimensão de lote N é o número de candidatos; quando as formas conferem, mutação, cruzamento, seleção e avaliação podem ser executados diretamente em lote ao longo da dimensão N. O ganho direto da tensorização vem da redução do número de chamadas e do custo de agendamento, não de mudar o número de candidatos ou melhorar a precisão pontual. randn(X) gera um tensor de perturbação aleatória com a mesma forma de X; a perturbação é elemento a elemento, e σ controla a intensidade. topk(F, k) seleciona ao longo da dimensão de lote N os índices dos k primeiros candidatos; o objeto de seleção são candidatos, não variáveis ou itens objetivo. A execução em lote muda a posição do gargalo de desempenho; a latência ainda pode ser medida, mas a eficiência de escala deve ser avaliada por quantos candidatos ou quantas gerações são concluídos por unidade de tempo.
**Cobertura de palavras-chave**
- Computação tensorial em lote, dimensão de lote N, contrato de forma, operadores em lote, otimização de grafo computacional, vazão, candidatos/segundo, gerações/segundo, pseudo-batelização.
> **Pistas de material**
>
> - O diagrama desta página tem como tema "processo evolutivo → grafo computacional tensorial em lote", com três colunas: ① organização tensorizada, ② operadores em lote, ③ otimização de compilação e vazão. O quadro-negro ou mapa mental pode ser desenvolvido nessas três colunas, destacando na terceira coluna as métricas de vazão "candidatos/segundo · gerações/segundo".
> **Pistas de exercício**
>
> - As 5 questões de múltipla escolha verificam respectivamente contrato de forma, ganho de desempenho da tensorização, significado da expressão de mutação, semântica de seleção topk, razão da troca de métrica. O feedback pode enfatizar: ao acertar, conectar ao contrato de forma ou à forma de chamada para explicar a base
> - ao errar, voltar à explicação desta página e encontrar evidências-chave antes de julgar. O estudo de caso "migrar loop evolutivo indivíduo por indivíduo para execução tensorial em lote" exige explicar como organizar candidatos, objetivos e estado como tensores e processá-los ao longo do lote N, bem como o trade-off entre otimização de grafo computacional e memória de vídeo insuficiente. Os pontos de resposta incluem X:[N×D], F:[N×M], Y=fθ(X), estado em buffers escalares ou pequenos tensores
> - mutação, cruzamento, seleção e avaliação executados em lote ao longo da dimensão N
> - otimizações possíveis: fusão de operadores, paralelismo dentro do lote, execução assíncrona, reutilização de memória
> - com memória de vídeo insuficiente, pode-se usar execução em blocos ou mini-lotes, reduzir precisão numérica, encurtar o ciclo de vida de tensores intermediários, mas todos os candidatos na mesma geração devem manter critério de comparação consistente.
**Atividade em sala**
Peça aos alunos que expliquem com suas próprias palavras "por que a dimensão de lote N deve estar na camada mais externa", e deem um exemplo simples, como N=4, D=3, M=2, escrevendo as formas de X, F e Y, explicando como uma chamada em lote substitui múltiplas chamadas de candidato único.
**Verificação de compreensão**
Peça aos alunos que resumam o contrato de forma, apontem uma forma de pseudo-batelização e expliquem por que a métrica muda de latência de passo único para vazão. Se o aluno só conseguir repetir termos sem explicar mudanças no número de chamadas e no nível de agendamento, pode-se voltar às partes de operadores em lote e erros comuns para complementar.
> **Dica de transição**
>
> Após confirmar que os alunos conseguem expressar a relação entre contrato de forma e execução em lote, passar para a próxima página de aplicações, resumo ou discussão mais complexa sobre otimização de grafo computacional.
### Agendamento Runtime e Composabilidade de Algoritmos
*Página 15*
> **Objetivo da página:** O aprendiz deve consolidar a compreensão central do Runtime no agendamento de poder computacional heterogêneo e na composabilidade de algoritmos.
> **Objetivo da página**
>
> Estabelecer a posição do Runtime como camada intermediária — ele não é um algoritmo concreto, mas uma camada de agendamento e abstração que faz a ponte: para cima, suporta a combinação flexível de algoritmos, problemas e fluxos de trabalho; para baixo, gerencia poder computacional heterogêneo como CPU e GPU, mantendo a composabilidade de algoritmos e a independência de hardware.
> **Sequência de exposição**
>
> Primeiro apresentar o julgamento de "camada intermediária"; depois decompor objetos de agendamento, recursos heterogêneos e mecanismos de desacoplamento; em seguida explicar os ganhos e custos da composabilidade; finalmente usar exemplos de substituição de algoritmos e exercícios para verificar a compreensão.
**Pontos-chave de ensino**
- Com base no estado do fluxo de trabalho e do módulo de monitoramento, agendar tarefas como população, avaliação e operadores para dispositivos adequados, gerenciando uniformemente execução paralela e uso de recursos. Ele recebe algoritmos, problemas e módulos de fluxo de trabalho, e chama CPU, GPU e aceleradores para baixo. Algoritmos, problemas e operadores se combinam por interfaces modulares, sem vinculação direta a hardware subjacente, estratégias paralelas ou detalhes de compilação. Portanto, substituir algoritmos como DE e PSO ou trocar o problema de otimização não exige reescrever o código paralelo de GPU/CPU subjacente. Diferenças de dispositivo, execução tensorizada e otimização de compilação são absorvidas pelo Runtime, mantendo a camada de algoritmo independente de dispositivo, facilitando substituição e reutilização. A abstração traz custos de agendamento e movimentação de dados, sendo necessário equilibrar flexibilidade, desempenho e complexidade de engenharia, por exemplo com processamento em lote, execução assíncrona ou cache para reduzir movimentação de dados. O mesmo Runtime pode suportar aplicações multidomínio, e também fornece ambiente de execução estável para evolução de métodos e substituição de algoritmos.
> **Pistas de material**
>
> - O diagrama desta página pode ser lido em três camadas. A camada superior é a camada de algoritmo, contendo módulo de algoritmo, definição de problema e fluxo de trabalho, que se integram por interface unificada
> - a camada intermediária é a camada de agendamento Runtime, responsável por agendamento de tarefas, execução paralela, gerenciamento de recursos e isolamento de interface
> - a camada inferior é o poder computacional heterogêneo, incluindo CPU, GPU e aceleradores. As dicas laterais enfatizam respectivamente "algoritmos substituíveis, independentes de hardware" e "trade-off: flexibilidade·desempenho·complexidade"; a dica inferior é "o mesmo Runtime suporta aplicações multidomínio". Ao explicar, pode-se seguir as setas de cima para baixo: a camada de algoritmo não toca diretamente o hardware, mas o Runtime agenda a execução conforme o fluxo de trabalho.
**Cobertura de palavras-chave**
- Agendamento de poder computacional heterogêneo, composabilidade de algoritmos, interface unificada, agendamento de fluxo de trabalho, abstração independente de hardware, isolamento de interface, custo de agendamento, custo de movimentação de dados.
**Tratamento dos exercícios**
As cinco questões de múltipla escolha servem para verificação rápida. A direção correta da questão 1 é "fornecer camada de agendamento e abstração, gerenciar poder computacional heterogêneo e manter a composabilidade de algoritmos"; se o aluno errar escolhendo "implementar diretamente algoritmos de otimização", é preciso enfatizar que o Runtime não implementa algoritmos concretos. A direção correta da questão 2 é "combinar por interfaces modulares, sem vinculação a hardware subjacente e estratégias paralelas"; se errar escolhendo API CUDA ou código paralelo escrito à mão, explicar que isso quebraria o desacoplamento. A direção correta da questão 3 é "absorver diferenças de dispositivo, execução tensorizada e otimização de compilação, tornando a camada de algoritmo independente de dispositivo". A direção correta da questão 4 é "a abstração traz custos de agendamento e movimentação de dados, sendo necessário equilibrar flexibilidade, desempenho e complexidade de engenharia".
A direção correta da questão 5 é "o mesmo Runtime pode suportar aplicações multidomínio e fornece ambiente de execução estável para evolução de métodos". No feedback, retornar uniformemente às três evidências: camada intermediária e não implementação de algoritmo; composabilidade exige desacoplamento de hardware; abstração não é custo zero.
O Runtime, como camada intermediária, combina módulos de algoritmo, problema e fluxo de trabalho por interface unificada, agendando tarefas como população, avaliação e operadores para execução em CPU ou GPU; a camada de algoritmo não se vincula diretamente a hardware, estratégias paralelas ou detalhes de compilação, portanto, ao trocar DE, PSO ou ajustar o tamanho da população, a equipe não precisa reescrever o código paralelo subjacente. A segunda pergunta pode responder: a abstração traz custos adicionais de agendamento e movimentação de dados, podendo afetar o desempenho de ponta a ponta; ao mesmo tempo, a manutenção e depuração do próprio Runtime aumentam a complexidade de engenharia. A equipe pode reduzir a movimentação de dados com processamento em lote, execução assíncrona ou cache, equilibrando flexibilidade, desempenho e complexidade de engenharia.
**Verificação de compreensão**
Peça aos alunos que expliquem em uma frase por que o Runtime permite substituir algoritmos sem tocar no código de hardware; e deem um exemplo de objeto de agendamento e um de recurso heterogêneo, confirmando que não confundem "população, avaliação, operadores" com "CPU, GPU, aceleradores".
> **Dica de transição**
>
> Após confirmar que os alunos conseguem distinguir objetos de agendamento e recursos heterogêneos, e expressar os ganhos e custos da composabilidade, passar para a próxima página de exemplos, aplicações ou resumo.
### Pedra Fundamental da Exploração Evolutiva em Alta Intensidade Paralela
*Página 16*
> **Objetivo da página:** O aprendiz deve resumir de forma abrangente o valor global e o significado prático da base computacional EvoX e da evolução paralela tensorizada.
> **Objetivo da página**
>
> Resumir de forma abrangente o valor global e o significado prático da base computacional EvoX e da evolução paralela tensorizada. O aprendiz deve ser capaz de explicar a transição da lista de candidatos para o grafo computacional tensorizado, dominar os três tipos de objetos tensorizados — população, avaliação e estado — e compreender como o Runtime unificado e a arquitetura desacoplada suportam exploração evolutiva em alta intensidade paralela.
> **Sequência de exposição**
>
> Primeiro apontar o gargalo do fluxo serial tradicional, depois introduzir o grafo computacional tensorizado como pedra fundamental, em seguida desenvolver os três grandes objetos tensorizados, depois falar sobre grafo computacional e arquitetura unificada, e finalmente chegar a ganhos, significado prático e o caso do aerofólio supercrítico.
**Pontos-chave de ensino**
- 1. Experimentos evolutivos tradicionais tratam cada indivíduo como objeto Python independente, modelando e avaliando um por um. Quando a escala de candidatos se expande para milhares ou dezenas de milhares, o verdadeiro gargalo frequentemente deixa de ser o algoritmo em si, e passa a ser o custo de agendamento, sincronização e I/O candidato por candidato. A pedra fundamental do EvoX pode ser resumida como: da lista de candidatos ao grafo computacional tensorizado. Ele reorganiza população, avaliação e estado de execução como tensores computáveis integralmente, e o Runtime unificado agenda para GPU e poder computacional heterogêneo para execução em lote, suportando busca evolutiva de larga escala, multiobjetivo e multi-solução paralela. 2. Três grandes objetos tensorizados: parâmetros de indivíduos, genes ou políticas não são mais percorridos em loop objeto Python por objeto, mas organizados em tensores pela dimensão de lote, com as diferenças entre indivíduos carregadas por uma dimensão do tensor. Aptidão, restrições, métricas multiobjetivo e resultados de avaliação de simulação ou modelo podem ser calculados em lote; candidatos no mesmo lote compartilham uma chamada de dispositivo, reduzindo significativamente o custo de agendamento e I/O candidato por candidato. Estado de execução como geração evolutiva, semente aleatória, cache e métricas de monitoramento são gerenciados uniformemente, tornando experimentos após aceleração paralela ainda reproduzíveis e rastreáveis. A tensorização não é otimização local de um ponto, mas atravessa os três níveis do ciclo evolutivo. Se qualquer nível voltar ao loop objeto por objeto, o paralelismo ficará travado nesse nível. Após elevar a lista de candidatos a grafo computacional tensorizado, o paralelismo de operadores e a otimização de compilação têm espaço para atuar, e o tamanho da população e o paralelismo de avaliação podem escalar com o poder computacional, em vez de ficarem travados pelo loop do interpretador. Acompanha isso a arquitetura unificada — algoritmo, problema, fluxo de trabalho e monitoramento, agendador Runtime mutuamente desacoplados, tornando algoritmos combináveis, problemas plugáveis e poder computacional heterogêneo gerenciado uniformemente. O usuário não precisa se preocupar com agendamento de baixo nível ao escrever algoritmos. Substitui o loop serial tradicional de CPU, alcançando aceleração em larga escala em GPU e poder computacional heterogêneo, fornecendo base de vazão estável para exploração em alta intensidade
- no mesmo tempo de relógio de parede, pode-se explorar mais candidatos, mais combinações de objetivos ou mais repetições aleatórias. Quando a engenharia de loop e agendamento de baixo nível é absorvida pela base, pesquisadores podem direcionar energia para modelagem de problemas, trade-offs de objetivos e design de hipóteses experimentais, sem primeiro mergulhar na engenharia de loop e agendamento de baixo nível. Essa divisão de trabalho é tanto premissa para exploração evolutiva em alta intensidade paralela quanto base de engenharia para evolução de métodos subsequente e pesquisa científica AI Native. Na otimização multiobjetivo de aerofólio supercrítico, a razão sustentação/arrasto em cruzeiro e o coeficiente de sustentação crítico de buffeting são mutuamente conflitantes, sendo necessário preservar um conjunto de soluções candidatas diferenciadas para especialistas ponderarem. Uma única simulação de alta precisão é cara, a escala de candidatos chega a milhares, e o loop serial inicial de CPU levava dias por experimento, com sementes aleatórias e resultados intermediários dispersos, difíceis de reverificar. Ideia de reformulação: primeiro tensorizar a população, organizando os parâmetros dos aerofólios candidatos em tensores pela dimensão de lote
- depois tensorizar a avaliação, avaliando em lote objetivos e restrições como razão sustentação/arrasto e coeficiente de sustentação de buffeting, podendo primeiro prever em lote com modelos substitutos e depois chamar simulação de alta precisão para poucos candidatos
- simultaneamente tensorizar o estado, registrando uniformemente geração, semente aleatória, cache e métricas de monitoramento
- finalmente construir o grafo computacional e agendar com Runtime unificado para execução em lote em GPU e poder computacional heterogêneo. Os elos de aumento de vazão incluem paralelismo de avaliação em lote, paralelismo de operadores e otimização de compilação, remoção do custo de agendamento Python e sincronização candidato por candidato, e exploração simultânea de mais candidatos, mais combinações de objetivos e mais repetições aleatórias no mesmo tempo de relógio de parede. Sobre reprodutibilidade: não se deve emitir cedo uma única solução ótima, porque os objetivos são mutuamente conflitantes e a convergência precoce em um ponto único perderia informações de trade-off
- preservar candidatos diferenciados permite que especialistas escolham conforme ganhos, custos e condições de aplicação. Em termos de reprodutibilidade, geração, semente aleatória, cache e métricas de monitoramento devem ser registrados uniformemente como estado de execução e gerenciados junto ao grafo computacional, permitindo reprodução e rastreamento completos dos resultados da execução paralela em lote; os registros de avaliação dos lotes de candidatos também devem ser rastreáveis até parâmetros e configurações de avaliação específicos.
**Tratamento dos exercícios**
Esta página acompanha cinco questões de múltipla escolha e um estudo de caso, servindo para verificar compreensão conceitual e aplicação em transferência.
A pedra fundamental é ir da lista de candidatos ao grafo computacional tensorizado, com agendamento unificado em lote pelo Runtime. Dica de resposta: o gargalo está no loop Python candidato por candidato, no agendamento e no I/O, e não no algoritmo em si, nem em comprimir a população ou aumentar a frequência de núcleo único.
A tensorização da população é organizar tensores pela dimensão de lote, com as diferenças entre indivíduos carregadas por dimensões do tensor. Dica de resposta: o loop objeto por objeto é justamente o que se quer abandonar; a tensorização não tem relação com o número de objetivos, nem sacrifica a reprodutibilidade.
O principal ganho da tensorização da avaliação é calcular aptidão, restrições e métricas multiobjetivo em lote, reduzindo o custo de agendamento e I/O candidato por candidato. Dica de resposta: ela não melhora a precisão numérica de uma única avaliação, não substitui o modelo de simulação, nem significa abandonar o registro.
O gerenciamento unificado do estado de execução visa aumentar a reprodutibilidade e a rastreabilidade do experimento. Dica de resposta: a tensorização de estado gerencia conjuntamente geração, semente, cache e métricas de monitoramento, sem relação com redução de memória de vídeo, e não cancela sementes aleatórias nem limita o paralelismo.
O significado do desacoplamento é que algoritmos são combináveis, problemas plugáveis e poder computacional heterogêneo gerenciado uniformemente. Dica de resposta: o desacoplamento libera capacidade de reutilização e paralelismo, em vez de limitar algoritmos a implementações seriais, e muito menos cancelar a necessidade de hipóteses experimentais e trade-offs de objetivos.
Primeiro explicar a reformulação em quatro passos — população, avaliação, estado, grafo computacional e Runtime — e depois apontar os elos de aumento de vazão; a segunda pergunta deve explicar por que preservar candidatos diversificados e como garantir reprodutibilidade por meio da tensorização de estado e do registro unificado.
Quando o aluno acertar, elogiar sua capacidade de conectar-se aos conceitos desta página e explicar a base; ao errar, guiá-lo de volta à explicação desta página, encontrando evidências-chave ou exemplos antes de julgar.
**Atividade em sala**
Pode-se pedir aos alunos que escolham um cenário familiar de computação evolutiva ou avaliação em lote, julguem se há loops Python explícitos; se houver, discutir se a tensorização deve priorizar a camada de população, avaliação ou estado, e explicar o motivo.
**Verificação de compreensão**
Peça aleatoriamente a um aluno que resuma os pontos principais desta página com suas próprias palavras, e o professor complementa palavras-chave como três pontos de tensorização, Runtime unificado, superação do gargalo serial, reprodutibilidade e arquitetura desacoplada. Pode-se perguntar: por que a reprodutibilidade não é um item adicional? Se semente aleatória, geração, cache e métricas de monitoramento não forem registrados uniformemente com o grafo computacional, o ganho de aceleração será compensado pela falta de rastreabilidade.
> **Dica de transição**
>
> Após confirmar que os alunos conseguem expressar a relação central da lista de candidatos ao grafo computacional tensorizado, e distinguir os três tipos de objetos tensorizados — população, avaliação e estado — passar para a próxima página de exemplos, aplicações ou resumo.
--- FIM DO TEXTO FONTE ---