AlphaFold: Protein Structure Prediction

Olá, daqui é o Alex da DEV STORIES DOT EU. AlphaFold: Previsão da Estrutura de Proteínas, episódio 1 de 21. Durante cinquenta anos, os cientistas conseguiam ler o texto bruto do nosso ADN, mas não conseguiam prever o que esse texto iria realmente construir. Eles tinham o source code da vida, mas não faziam ideia de como ele compilava para as máquinas físicas que operam as nossas células. Este grande desafio é conhecido como o Problema do Enovelamento de Proteínas. As proteínas são as máquinas moleculares que te mantêm vivo. Elas tratam de quase tudo o que acontece dentro do teu corpo, desde o transporte de oxigénio no sangue até ao combate a infeções. Cada proteína começa a sua vida como uma string unidimensional. Esta string é construída a partir de um vocabulário de vinte blocos de construção químicos diferentes, chamados aminoácidos. Pensa na sequência de aminoácidos como o source code bruto da biologia. É uma string linear de caracteres, lida sequencialmente. Mas uma linha reta de aminoácidos não consegue realizar nenhum trabalho real. Tal como um ficheiro de texto simples precisa de ser compilado para um binário executável para correr, a sequência unidimensional de aminoácidos tem de se dobrar numa forma tridimensional altamente específica. No mundo biológico, a forma dita completamente a função. Os contornos físicos de uma proteína determinam com o que ela pode interagir. Uma proteína dobrada em forma de bolsa pode capturar e decompor uma molécula de açúcar específica. Uma proteína dobrada num tubo rígido pode atuar como suporte estrutural para uma célula. Se o processo de dobramento correr mal, o programa biológico dá crash. Nos humanos, proteínas mal dobradas são a causa principal de muitas doenças graves. A sequência de aminoácidos contém todas as instruções necessárias para formar esta estrutura tridimensional exata. Os diferentes aminoácidos têm propriedades químicas diferentes. Alguns carregam cargas positivas ou negativas e agem como ímanes. Alguns repelem a água e tentam esconder-se no centro da estrutura, enquanto outros são atraídos pela água e empurram para o exterior. Estas forças físicas opostas fazem com que a string se emaranhe, torça e encaixe numa configuração única e estável. Aqui está o ponto-chave. A matemática por trás deste processo de dobramento é impressionante. Uma cadeia proteica típica é composta por centenas de aminoácidos. O número de maneiras possíveis de uma cadeia tão longa se dobrar é de cerca de dez elevado a trezentos. Um cientista chamado Cyrus Levinthal observou que, se uma proteína tentasse sequencialmente todas as formas possíveis para encontrar a certa, o processo levaria mais tempo do que a idade do universo. No entanto, dentro das tuas células, uma nova string de proteína encaixa na sua forma correta em poucos milissegundos. O problema do enovelamento de proteínas é a tentativa de preencher esta lacuna. É o desafio de pegar numa sequência unidimensional de aminoácidos como o único input e prever computacionalmente a sua estrutura tridimensional final. Historicamente, os cientistas dependiam de técnicas de laboratório físicas e lentas para mapear estas estruturas. Métodos como a cristalografia de raios X envolviam o congelamento de proteínas em cristais e o disparo de feixes sobre elas para medir os ângulos da luz dispersa. Encontrar a estrutura de uma única proteína podia levar anos de tentativa e erro meticulosos. Como a tecnologia de sequenciação genética ultrapassou o mapeamento físico, a comunidade científica acumulou centenas de milhões de sequências unidimensionais conhecidas, mas mapeou as estruturas 3D de apenas uma pequena fração delas. Tínhamos linhas infinitas de source code, mas nenhum decompiler para nos mostrar a lógica em execução. Resolver o problema do dobramento de proteínas computacionalmente dá-nos os blueprints mecânicos exatos da biologia, transformando a descoberta de medicamentos de um processo lento de adivinhação em laboratório numa engenharia precisa e direcionada. Se gostas do podcast e queres apoiar o programa, podes procurar por DevStoriesEU no Patreon. Ficamos por aqui neste episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui é o Alex da DEV STORIES DOT EU. AlphaFold: Protein Structure Prediction, episódio 2 de 21. Tu queres prever a forma física de uma única sequência de proteína, mas olhar apenas para essa sequência não é suficiente. Para descobrir como ela se dobra, precisas mesmo de examinar a sua árvore genealógica evolutiva para identificar padrões sincronizados de mutações ao longo de milhões de anos. Perceber como um algoritmo processa esses padrões evolutivos é exatamente o que abordamos no Inside AlphaFold 2: Architecture Overview. A arquitetura opera como um fluxo contínuo de dados, a transformar uma string de letras de aminoácidos numa forma 3D. Tudo começa com a target sequence. Antes de qualquer processamento da rede neuronal acontecer, o AlphaFold pesquisa em bases de dados biológicas gigantes para recolher dois inputs específicos com base nessa sequência. O primeiro input é o Multiple Sequence Alignment, ou MSA. Esta é uma coleção de sequências de proteínas semelhantes de outros organismos. Se dois aminoácidos numa sequência sofrem mutações em conjunto constantemente em diferentes espécies, é provável que estejam fisicamente em contacto na estrutura final dobrada. O segundo input consiste em templates estruturais. Estas são estruturas 3D conhecidas de proteínas que são altamente semelhantes à tua target sequence. Estes MSAs e templates raw alimentam diretamente a Embedding layer. A Embedding layer traduz estes dados biológicos em dois formatos matemáticos distintos que a rede neuronal pode processar. Estas são a MSA representation e a Pair representation. A MSA representation é uma matriz que guarda o histórico de mutações evolutivas. A Pair representation é uma grelha bidimensional abstrata que rastreia a distância potencial e a relação física entre cada par possível de aminoácidos na sequência. Uma vez criadas, ambas as representações entram na stack do Evoformer. O Evoformer é o motor do AlphaFold 2, composto por 48 blocos de processamento distintos. Aqui está o insight principal. Dentro de cada bloco, a MSA representation e a Pair representation comunicam entre si. Elas trocam informações para refinar os seus respetivos dados. Se os dados evolutivos na MSA representation sugerirem fortemente que dois aminoácidos interagem, ela atualiza a Pair representation para os aproximar na grelha de distância abstrata. Por outro lado, se a Pair representation perceber que colocar dois aminoácidos juntos viola as restrições de espaço físico, ela atualiza a MSA representation para reavaliar essa ligação evolutiva. Esta comunicação cruzada acontece continuamente à medida que os dados fluem por todos os 48 blocos, a produzir um mapa altamente preciso das relações internas. As pessoas costumam assumir que o Evoformer gera a forma física final, mas não é o caso. O Evoformer apenas constrói representações matemáticas abstratas de distâncias e ligações evolutivas. Ele faz output de matrizes de dados altamente refinadas, não de um objeto físico. Para obter a forma dobrada real, os dados saem do 48º bloco do Evoformer e entram no Structure Module. O Structure Module pega na Pair representation refinada e nos dados da sequência original, e traduz essa grelha abstrata em coordenadas atómicas 3D reais. Ele atribui uma posição X, Y e Z exata no espaço para cada átomo no backbone da proteína e nas suas side chains. O sucesso do AlphaFold 2 depende de o Evoformer forçar continuamente o histórico evolutivo e as restrições espaciais a concordarem entre si antes de uma única coordenada 3D ser desenhada. É tudo por este episódio. Obrigado por ouvires, e continua a construir!

Olá, daqui é o Alex da DEV STORIES DOT EU. AlphaFold: Previsão da Estrutura de Proteínas, episódio 3 de 21. A funcionalidade mais poderosa de um modelo de IA nem sempre é o seu output, mas sim a sua capacidade de te dizer exatamente quando está a adivinhar. Se olhares para um modelo de proteína previsto e assumires que cada loop e domínio está perfeitamente posicionado na realidade, as tuas experiências downstream provavelmente vão falhar. Para usares estes modelos com segurança, precisas de entender a Avaliação de Previsões: pLDDT e PAE. O AlphaFold gera duas métricas distintas para quantificar a sua incerteza. A primeira é o pLDDT, que significa predicted Local Distance Difference Test. Isto avalia a confiança local. Para cada resíduo de aminoácido na proteína, o AlphaFold atribui um score entre 0 e 100. Este score diz-te o quão confiante a rede está na estrutura local do backbone. Quando um resíduo tem um score acima de 90, estás perante uma confiança muito alta. A este nível, até as orientações das side-chains costumam ser fiáveis. Um score entre 70 e 90 ainda representa uma previsão de backbone boa e fiável. À medida que o score desce abaixo de 70, a confiança fica tremida. Aqui está o insight principal. Quando vês um score pLDDT abaixo de 50, o teu primeiro instinto pode ser que o modelo falhou em encontrar o fold certo. Isso normalmente está incorreto. Um score pLDDT muito baixo indica muitas vezes uma região intrinsecamente desordenada. A proteína fisicamente não tem uma estrutura fixa de forma isolada. Pode ser um linker flexível ou uma cauda que só faz fold quando se liga a outra molécula. A IA não está a falhar; está a prever com precisão que este pedaço da proteína é naturalmente flexível. Embora o pLDDT seja excelente para folds locais, tem um grande ponto cego. Avalia as regiões de forma isolada. Considera uma proteína com dois domínios estruturais completamente separados, ligados por uma longa string de aminoácidos. Corres a previsão, verificas o pLDDT e vês que ambos os domínios têm um score acima de 90. As suas estruturas internas são sólidas. No entanto, o pLDDT não te consegue dizer se esses dois domínios estão posicionados corretamente um em relação ao outro no espaço tridimensional. Para resolver isto, o AlphaFold fornece uma segunda métrica chamada Predicted Aligned Error, ou PAE. Esta métrica avalia a posição relativa dos domínios. O PAE mede o erro de distância esperado entre quaisquer dois resíduos específicos na proteína. A lógica faz uma pergunta simples: se alinharmos a previsão com a estrutura real perfeitamente no resíduo X, quantos Ångströms de desvio terá o resíduo Y? Isto dá-te uma grid bidimensional de erros pairwise. Voltando ao cenário da proteína de dois domínios, se verificares o PAE entre resíduos dentro do primeiro domínio, o erro vai ser muito baixo. O mesmo se aplica dentro do segundo domínio. Mas se verificares o PAE entre um resíduo no domínio um e um resíduo no domínio dois, o erro pode ser muito alto. Um PAE alto entre domínios significa que a sua orientação relativa é completamente incerta. O modelo sabe exatamente qual é o aspeto das duas formas separadas, mas não faz ideia do ângulo em que se encontram uma em relação à outra. Tens de avaliar ambas as métricas em conjunto para entenderes o panorama geral. Usas o pLDDT para confiares no folding local e para identificares regiões de desordem natural. Baseias-te no PAE para verificares se o arranjo global dessas partes distintas com fold é realmente fixo, ou apenas um palpite espacial do algoritmo. Nunca trates uma estrutura prevista como uma verdade única e rígida; trata-a como um mapa de probabilidades onde cada domínio e linker traz a sua própria prova de fiabilidade. Obrigado por passares uns minutos comigo. Até à próxima, fica bem.

Olá, daqui é o Alex do DEV STORIES DOT EU. AlphaFold: Previsão da Estrutura de Proteínas, episódio 4 de 21. Treinar um machine learning model inovador é impressionante, mas para um biólogo no ativo, uma neural network em bruto é apenas mais uma ferramenta pesada para configurar. Para realmente mudar a área, tu não publicas apenas o modelo. Usas o modelo para dobrar quase todas as proteínas conhecidas na Terra, e colocas os resultados online gratuitamente. Esta é a AlphaFold Protein Structure Database. Construída em parceria entre a Google DeepMind e o EMBL-EBI, esta base de dados contém mais de 200 milhões de estruturas previstas. Esse número enorme representa quase todo o universo de proteínas conhecido. Em vez de configurares o hardware e executares o algoritmo AlphaFold tu mesmo, ignoras o compute por completo e fazes uma query às previsões concluídas. Considera o workflow para usar a web interface. Se estiveres a investigar o recetor de ácidos gordos livres 2, vais a alphafold ponto ebi ponto ac ponto uk e digitas esse nome na barra de pesquisa. Podes pesquisar pelo nome do gene ou pela sequência, mas o método mais preciso é usar um número de acesso UniProt. Como a base de dados faz o mapeamento direto para o UniProt, cada estrutura está intimamente ligada aos metadados biológicos existentes. Quando selecionas o teu alvo nos resultados, vais parar à página de entrada específica dessa proteína. Esta é a parte que importa. A funcionalidade central da página de entrada é um visualizador 3D interativo, mas não te mostra apenas a geometria física. Representa visualmente a confiança interna do modelo nessa geometria. O AlphaFold pontua a sua própria precisão para cada aminoácido usando uma métrica chamada pLDDT. O visualizador 3D codifica o modelo físico por cores com base nestas pontuações exatas. Azul-escuro indica uma confiança muito alta na estrutura. Azul-claro significa confiante. Amarelo significa baixa confiança, e laranja significa confiança muito baixa. Quando rodas o recetor de ácidos gordos livres 2 no browser, vais ver estruturas helicoidais nítidas em azul-escuro onde a proteína atravessa a membrana celular. Mas as caudas soltas penduradas nas extremidades podem estar em laranja brilhante. Essas regiões laranja raramente são falhas do algoritmo. Geralmente, são regiões intrinsecamente desordenadas, o que significa partes da proteína que não possuem uma forma fixa na realidade biológica. Ver a estrutura no browser é bom para um sanity check rápido, mas o trabalho computacional real requer os dados em bruto. Abaixo do visualizador, vais encontrar a secção de download. Podes fazer o download das coordenadas 3D no formato PDB standard ou no formato mmCIF moderno. Arrastas estes ficheiros diretamente para o teu software de modelação local para medir distâncias ou simular interações moleculares. Juntamente com os ficheiros de coordenadas, também tens de fazer o download dos dados de Predicted Aligned Error. Estes são fornecidos como um simples ficheiro JSON. Enquanto as cores no visualizador 3D te dizem se uma parte local da proteína é precisa, o ficheiro JSON PAE diz-te se as posições relativas de duas partes diferentes são precisas. Contém uma matriz de margens de erro para as distâncias entre cada par de resíduos. Se a tua proteína tiver dois domínios azuis sólidos separados por uma dobradiça flexível, os dados JSON vão dizer-te se podes realmente confiar no ângulo entre eles. A AlphaFold Protein Structure Database muda completamente o teu workflow. Já não passas dias a tentar prever uma estrutura; passas minutos a procurá-la, e o teu trabalho real passa a ser interpretar as métricas de confiança anexadas ao download. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui é o Alex do DEV STORIES DOT EU. AlphaFold: Previsão da Estrutura de Proteínas, episódio 5 de 21. A bioinformática no mundo real não acontece a clicar manualmente em botões de download num web browser. Quando precisas de analisar centenas de proteínas, constróis pipelines automatizados e escaláveis. Isso leva-nos à Automatização da Descoberta: a API da base de dados AlphaFold. Sabes que a base de dados contém milhões de predições estruturais, mas visualizar uma proteína de cada vez num website é inviável para grandes projetos. Se estiveres a fazer uma análise comparativa em toda uma família de enzimas, ou a fazer o screening de alvos para um pipeline de descoberta de medicamentos, precisas que essas estruturas sejam importadas diretamente para o teu ambiente computacional. A base de dados AlphaFold fornece uma REST API para resolver exatamente este bottleneck. Ela permite que o teu código faça uma query à base de dados e recupere dados estruturais de forma programática, sem intervenção humana. A primary key para esta automação é o UniProt ID. Podes pensar num UniProt ID como o código de barras universal para qualquer proteína. O teu pipeline geralmente começa com uma lista destes IDs. Ao usar uma library HTTP standard em Python, envias um request à API a pedir os dados de predição associados a um código de barras específico. Esta é a parte que interessa. Quando fazes esse request, a API não devolve um ficheiro enorme cheio de coordenadas atómicas tridimensionais. Servir ficheiros pesados através de uma API call síncrona é lento e frágil. Em vez disso, a API devolve um manifest. Este manifest é uma response leve que descreve exatamente que recursos estão disponíveis para a proteína que pediste. Conceptualmente, este manifest dá-te a metadata biológica e um diretório de links diretos para download. Ele aponta para os próprios ficheiros de estrutura 3D em formatos standard da indústria. Crucialmente, também fornece links para as métricas de confiança, como o Predicted Aligned Error, ou matriz PAE. Precisas de ambos. Num pipeline automatizado, fazer o download da estrutura é apenas metade do trabalho. Também tens de fazer o download dos dados PAE para que os teus algoritmos downstream saibam que partes da proteína são altamente fiáveis e que partes são flexíveis. Vamos ver como esta lógica flui num script Python típico. Configuras um loop para iterar sobre a tua lista de UniProt IDs. Dentro do loop, fazes o teu network request para o primeiro ID. Antes de fazeres mais alguma coisa, verificas o HTTP status code. Nem todas as sequências de proteínas existentes têm uma estrutura AlphaFold pré-calculada. Se pedires uma proteína não mapeada, a base de dados devolve um erro standard four-oh-four not found. O teu script deve fazer o catch deste erro de forma elegante, fazer o log do ID em falta, e continuar para a próxima iteração. Se ignorares os status codes e tentares fazer o parse de uma response em falta, todo o teu batch job vai crashar na primeira proteína não suportada. Quando o request é bem-sucedido, o teu script lê o manifest devolvido. Escreves a lógica para extrair os links de download específicos que te interessam, que geralmente são o ficheiro de coordenadas primário e o ficheiro da matriz de erros correspondente. O teu script faz então HTTP requests secundários para esses links específicos, fazendo o streaming dos dados pesados diretamente para o teu local storage ou cloud bucket. Ao separar a query do download, a API mantém a fase inicial de descoberta incrivelmente rápida. Podes verificar rapidamente a disponibilidade de milhares de proteínas, construir uma lista validada de links, e depois lidar com os downloads pesados em bulk. O verdadeiro valor da API do AlphaFold é que remove o bottleneck humano, transformando uma vasta base de dados estática num componente totalmente programável da tua arquitetura de pesquisa. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui fala o Alex da DEV STORIES DOT EU. AlphaFold: Previsão da Estrutura de Proteínas, episódio 6 de 21. Quando corres uma previsão de estrutura de proteínas, a rede neuronal raramente é o bottleneck. A verdadeira espera acontece antes mesmo de o modelo arrancar, consumindo horas do teu dia só para pesquisar em bases de dados genéticas. Prever estruturas com o ColabFold muda completamente esta equação. O pipeline standard do AlphaFold depende de uma ferramenta chamada Jackhmmer. O Jackhmmer examina bases de dados locais massivas, na ordem dos terabytes, para encontrar parentes evolutivos da tua proteína alvo. Esta pesquisa constrói o Multiple Sequence Alignment, ou MSA. O MSA é o input crítico que diz ao AlphaFold que partes da proteína têm maior probabilidade de interagir com base na história evolutiva. No entanto, gerar este alinhamento da forma tradicional leva horas de tempo de compute e obriga-te a gerir datasets enormes na tua própria infraestrutura. O ColabFold modifica este pipeline focando-se nesse bottleneck específico. Substitui o Jackhmmer por um algoritmo de pesquisa diferente chamado MMseqs2. O MMseqs2 é altamente otimizado para pesquisa de sequências a alta velocidade. Mas o ColabFold vai um passo mais além do que simplesmente trocar de algoritmos. Em vez de te obrigar a correr o MMseqs2 e as suas bases de dados associadas na tua máquina local, o ColabFold faz o offload completo desta etapa. Ele pega na tua sequência de input e envia-a para um servidor MMseqs2 público e dedicado através de uma API. Este servidor trata do trabalho pesado. Pesquisa nas suas próprias bases de dados geridas centralmente e devolve o MSA finalizado diretamente para o teu environment. Esta mudança de arquitetura significa que não precisas de storage de bases de dados local de todo. É exatamente por isto que consegues correr o ColabFold de forma eficaz num Jupyter Notebook alojado em serviços cloud como o Google Colab ou o UCloud. O setup não requer quase nenhuma infraestrutura. Abres o notebook e colas a tua sequência de aminoácidos. Pode ser uma proteína wild-type, ou uma sequência mutada customizada com a qual estejas a fazer experiências. Quando corres o notebook, a execução acontece em duas fases distintas. Primeiro, o teu environment cloud faz uma API call rápida para o servidor MMseqs2 remoto. O servidor calcula o alinhamento e envia o MSA de volta para o teu notebook. Isto reduz um processo que normalmente levaria horas para meros minutos ou até segundos. Agora, a segunda parte deste workflow entra em ação. O teu notebook passa esse MSA recuperado para a rede neuronal do AlphaFold. É aqui que a previsão de folding realmente acontece. Ao contrário da pesquisa na base de dados, este passo de inferência corre localmente dentro da tua instância cloud. Utiliza a GPU ligada à tua sessão do Google Colab ou UCloud para calcular as coordenadas espaciais da estrutura da proteína. Como a pesquisa lenta na base de dados é externalizada e acelerada, o teu tempo total de iteração é drasticamente reduzido. Obténs a previsão da rede neuronal altamente precisa que esperas do AlphaFold, mas de forma rápida. Se precisares de testar como uma mutação pontual específica altera a forma física de uma proteína, basta editares uma única letra na tua variável de sequência, correres a cell novamente e avaliares o novo output. Aqui está o insight principal. O ColabFold prova que, ao fazer o decoupling completo da pesquisa de alinhamento pesada em dados da inferência da rede neuronal, consegues colocar ferramentas de biologia estrutural de classe mundial num web browser standard. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui é o Alex da DEV STORIES DOT EU. AlphaFold: Previsão da Estrutura de Proteínas, episódio 7 de 21. Prever uma única proteína é como adivinhar a forma de uma peça de puzzle isolada. Mas, em biologia, as proteínas raramente atuam sozinhas. Se atirares duas sequências aleatórias para um modelo de previsão standard, ele muitas vezes vai simplesmente misturá-las no espaço tridimensional, independentemente de elas se ligarem mesmo na natureza. Para descobrires como várias peças flexíveis se encaixam de facto, precisas de uma ferramenta diferente. Essa ferramenta é o AlphaFold-Multimer. O AlphaFold standard está otimizado para cadeias polipeptídicas individuais. O AlphaFold-Multimer é uma versão retreinada do sistema, desenhada especificamente para prever complexos proteicos. Ele foi treinado para reconhecer e modelar tanto interfaces homoméricas, onde múltiplas cópias da mesma proteína se ligam, como interfaces heteroméricas, onde proteínas completamente diferentes interagem. Quando forneces múltiplas sequências ao AlphaFold-Multimer, ele vai sempre retornar um complexo previsto. O desafio crucial é determinar se essa interface prevista é uma interação biológica real ou uma colisão forçada artificial. O modelo faz o que lhe pedes, por isso vai posicionar as cadeias lado a lado. Para resolver o problema das falsas interações, o AlphaFold-Multimer introduz uma métrica de confiança especializada chamada interface predicted Template Modeling score, ou ipTM. Os confidence scores standard avaliam o quão bem um pedaço localizado de uma cadeia se dobra. O score ipTM ignora completamente a estrutura interna das proteínas individuais. Em vez disso, mede a precisão das posições relativas das cadeias. Avalia especificamente a confiança na interface onde as proteínas se encontram. Considera um cenário em que estás a prever um complexo anticorpo-antigénio de duas cadeias. Passas a sequência de aminoácidos do anticorpo e a sequência do antigénio alvo para o modelo. O sistema faz o output de uma estrutura que contém ambas as moléculas. Primeiro, verificas os confidence scores locais standard para cada cadeia. Eles podem ser muito altos, indicando que o modelo sabe exatamente como o anticorpo isolado e o antigénio isolado se dobram. Presta atenção a esta parte. Podes ter cadeias individuais perfeitamente dobradas com um score ipTM próximo de zero. Se o ipTM for baixo, o modelo está a dizer-te que, embora as formas estejam corretas, não faz ideia de como elas se ligam. Ele simplesmente estacionou as duas estruturas dobradas lado a lado porque forneceste duas sequências. A interface não significa nada. No entanto, se o score ipTM for alto, normalmente qualquer coisa acima de zero vírgula oito, o modelo está confiante na interação. Um ipTM alto significa que o sistema encontrou provas estruturais e evolutivas de que estas superfícies específicas se encaixam. O modelo não as está apenas a forçar a juntarem-se; está a prever um evento de ligação genuíno. Para classificar os outputs finais, o AlphaFold-Multimer calcula um confidence score combinado. Esta métrica combinada é fortemente ponderada para a interface, normalmente usando oitenta por cento do score ipTM e adicionando vinte por cento do score estrutural geral. O modelo com o score combinado mais alto é retornado como a tua previsão principal. A precisão estrutural das cadeias individuais não garante uma interação válida. O interface predicted Template Modeling score é a métrica determinante para provar que o modelo descobriu um complexo biológico genuíno, em vez de apenas satisfazer um pedido para agrupar duas sequências. Por agora é tudo. Obrigado por ouvires, e continua a construir!

Olá, daqui é o Alex da DEV STORIES DOT EU. AlphaFold: Previsão da Estrutura de Proteínas, episódio 8 de 21. Um único erro de digitação numa sequência de milhares de aminoácidos pode ser a diferença entre a saúde e uma doença genética grave. Mas quando sequencias o genoma de um paciente e encontras uma nova mutação, como sabes se é a causa raiz ou apenas ruído biológico inofensivo? O AlphaMissense dá uma resposta matemática exatamente a esse problema. Uma variante missense é uma mutação genética em que a alteração de uma única letra de DNA resulta na substituição de um aminoácido por outro na proteína final. O genoma humano médio contém milhares destas variantes. Muitas são totalmente benignas. Alteram uma parte periférica da proteína sem afetar a sua função geral. Outras comprometem totalmente a proteína, levando a doenças genéticas graves. Separar as variantes perigosas das inofensivas é um enorme bottleneck na genética clínica. O AlphaMissense é um modelo construído especificamente para classificar estes efeitos. Precisamos de esclarecer uma ideia errada muito comum logo à partida. O AlphaMissense não prevê as alterações estruturais 3D causadas por uma mutação. Não faz o output de um novo ficheiro que mostre uma forma deformada da proteína. Em vez disso, tira partido do contexto estrutural e evolutivo já aprendido pela rede AlphaFold para calcular uma probabilidade. Devolve um score contínuo de patogenicidade que varia entre zero e um. Este score representa a probabilidade de uma mutação específica causar doença. Pensa num cenário concreto. Estás a analisar o genoma de um paciente e isolas uma nova substituição de um único aminoácido num gene crítico. Uma valina substituiu uma alanina na posição 142. O paciente está doente, mas esta mutação exata nunca foi documentada na literatura médica. Precisas de saber se esta substituição é patogénica. Fazes uma query à base de dados do AlphaMissense para esta variante específica. Internamente, o modelo avalia a conservação evolutiva dessa posição exata, olhando para alinhamentos de múltiplas sequências. Verifica se a natureza tolerou mudanças nesta posição ao longo de milhões de anos de evolução. Também avalia o contexto estrutural. Um aminoácido bem compactado no núcleo hidrofóbico da proteína é muito mais sensível a mudanças do que um a flutuar livremente na superfície exterior. O AlphaMissense processa estes sinais evolutivos e estruturais para devolver o teu score. Um score próximo de zero significa que a variante é provavelmente benigna. A proteína provavelmente dobra-se e funciona normalmente. Um score próximo de um sinaliza-a como provavelmente patogénica. A substituição quase de certeza compromete a estabilidade ou a função da proteína. Para tornar estes dados acionáveis, o modelo aplica thresholds predefinidos. Scores acima do threshold superior são categorizados como provavelmente patogénicos. Scores abaixo do threshold inferior são provavelmente benignos. Qualquer coisa que caia na faixa intermédia é classificada como ambígua. Esta classificação permite-te filtrar instantaneamente o ruído genómico. Em vez de desenhares experiências de laboratório caras e demoradas para testar todas as variantes desconhecidas no genoma do paciente, focas imediatamente os teus recursos clínicos nas poucas mutações que o AlphaMissense sinaliza com um score alto. Aqui está o insight principal. O verdadeiro impacto desta ferramenta é a sua escala. O AlphaMissense não espera por queries. Já calculou o score de patogenicidade para todas as 71 milhões de substituições possíveis de um único aminoácido em todo o proteoma humano, catalogando os resultados antes mesmo de um paciente entrar numa clínica. Se gostas do podcast e queres ajudar a manter o programa a funcionar, podes apoiar-nos procurando por DevStoriesEU no Patreon. É tudo por este episódio. Obrigado por ouvires, e continua a programar!

Daqui fala o Alex da DEV STORIES DOT EU. AlphaFold: Predição da Estrutura de Proteínas, episódio 9 de 21. Podes achar que o maior obstáculo para prever estruturas de proteínas é encontrar uma GPU suficientemente potente. Mas o verdadeiro bottleneck é o armazenamento. Antes de fazeres o fold de um único aminoácido, precisas de consultar bases de dados evolutivas massivas, com vários terabytes. Este episódio aborda como fazer o deploy do AlphaFold 2 localmente. Correr o AlphaFold no teu próprio hardware dá-te privacidade rigorosa para sequências proprietárias e remove os limites de tempo de execução que encontras em servidores públicos. A DeepMind disponibiliza o código open-source diretamente no GitHub. Para o usares, precisas primeiro de replicar o ambiente de referência genética exato que o modelo usa para encontrar sequências semelhantes. Isto requer fazer o download de cópias locais de bases de dados públicas como BFD, MGnify, UniRef90 e PDB70. Combinadas, estas bases de dados não comprimidas consomem aproximadamente três terabytes de armazenamento. Imagina um engenheiro de DevOps a provisionar um novo node de High Performance Computing para uma equipa de investigação. O primeiro requisito é uma drive de três terabytes. Não podes usar discos mecânicos baratos e lentos aqui. Precisas de armazenamento NVMe rápido. Pesquisar em milhões de sequências genéticas gera operações de leitura de disco agressivas. Se o teu armazenamento for lento, o pipeline inteiro engasga-se antes sequer de os dados chegarem à rede neuronal. Aqui está o ponto chave. O pipeline local do AlphaFold consiste em duas fases de computação distintas, e elas exigem perfis de hardware completamente diferentes. A fase um gera o Multiple Sequence Alignment, ou MSA. O sistema pesquisa os teus terabytes de bases de dados locais usando ferramentas de bioinformática externas. Esta fase usa exatamente zero ciclos de GPU. O bottleneck está inteiramente nos cores da CPU, na memória do sistema e na velocidade do disco. A fase dois é a inferência estrutural propriamente dita. É aqui que a rede neuronal assume o controlo para gerar as coordenadas 3D, e esta fase exige estritamente uma GPU com bastante VRAM. Se provisionares um node com uma GPU massiva, mas uma CPU fraca, o teu job de predição vai ficar parado durante horas na fase de alinhamento. Gerir as dependências de software para ambas as fases é notoriamente difícil. Tens de alinhar versões específicas do CUDA, do Jax e das ferramentas de alinhamento de sequências. Para resolver isto, o repositório oficial depende imenso do Docker. A containerização garante que este ambiente de execução complexo se mantém isolado e consistente em diferentes sistemas operativos. Configurar o deploy envolve dois scripts principais. Primeiro, corres um script bash fornecido para fazer o download dos dados. Apontas para a tua drive NVMe e deixas correr. Dependendo da tua ligação à rede, fazer o fetch e extrair estes ficheiros pode demorar alguns dias. Assim que os dados estiverem no teu armazenamento rápido, estás pronto para a execução. Controlas o pipeline usando um script wrapper de Python fornecido, chamado run docker dot py. Corres este script a partir do terminal, passando-lhe alguns argumentos obrigatórios. Forneces o path para o ficheiro FASTA de input que contém a tua sequência de aminoácidos alvo. Forneces o path para o diretório da tua base de dados de vários terabytes. Especificas um diretório de output. Finalmente, defines uma data máxima de lançamento do template, o que impede o modelo de usar templates estruturais conhecidos publicados depois de um momento específico no tempo. O wrapper de Python recebe estes argumentos e faz o build do container Docker. Ele monta os diretórios do teu host local no container como volumes, permitindo que o software isolado leia as tuas bases de dados e grave os ficheiros de output de volta no teu disco. O container depois assume o controlo, orquestrando automaticamente a pesquisa de alinhamento, intensiva para a CPU, e o processo de inferência, intensivo para a GPU. Fazer o deploy do AlphaFold localmente é fundamentalmente um desafio de infraestrutura, exigindo que equilibres a velocidade rápida do disco para a fase de alinhamento, intensiva para a CPU, com VRAM suficiente para a fase de folding, intensiva para a GPU. Obrigado por passares uns minutos comigo. Até à próxima, fica bem.

Olá, daqui fala o Alex da DEV STORIES DOT EU. AlphaFold: Predição da Estrutura de Proteínas, episódio 10 de 21. Durante anos, se quisesses ver como um potencial medicamento interagia com uma proteína-alvo, tinhas de correr a tua sequência, gerar uma estrutura proteica e, depois, usar um software completamente separado para fazer o docking computacional do medicamento no sítio certo. Estavas a forçar um composto químico rígido num modelo rígido. O AlphaFold 3 muda isto completamente, fazendo o folding de tudo ao mesmo tempo. Hoje, apresentamos o AlphaFold 3: Beyond Proteins. As versões anteriores do AlphaFold eram estritamente focadas na predição da estrutura de proteínas com base nas suas sequências de aminoácidos. Eram excecionalmente boas nisso, mas os sistemas biológicos reais não funcionam como proteínas isoladas a flutuar no vácuo. As proteínas interagem com o DNA para ativar e desativar genes. Dependem de iões metálicos para catalisar reações. São bloqueadas ou ativadas por pequenas moléculas de medicamentos. Antes desta atualização, a modelação destas interações complexas exigia uma pipeline fragmentada. Primeiro, previas a estrutura da proteína, depois talvez modelasses o DNA separadamente e, por fim, tentavas calcular como se encaixavam fisicamente. Esta abordagem sequencial tem uma falha grave. Assume que a estrutura da proteína é estática. Na realidade, as proteínas mudam de forma dinamicamente quando se ligam a outras moléculas. O ponto-chave é este. O AlphaFold 3 deixa de ser apenas uma ferramenta de protein folding para se tornar num preditor generalizado de complexos biomoleculares. Expande o seu vocabulário nativo para além dos aminoácidos para incluir três categorias inteiramente novas de moléculas. Primeiro, agora suporta ácidos nucleicos, o que significa que podes passar como input sequências tanto de DNA como de RNA. Segundo, entende nativamente ligandos de pequenas moléculas, o que abrange a grande maioria dos fármacos. Terceiro, suporta a inclusão de iões essenciais que frequentemente se encontram no núcleo de proteínas funcionais. Em vez de prever estes componentes isoladamente, o AlphaFold 3 prevê a estrutura conjunta de todas estas entidades moleculares distintas em simultâneo. Calcula as interações entre cada átomo de todo o complexo numa única pass. Pensa em como isto muda um cenário de modelação padrão. Já não estás a olhar para um alvo isolado. Agora podes definir um input que contém uma sequência de proteína, uma cadeia específica de DNA e a definição química de um pequeno fármaco inibidor. O sistema avalia-os em conjunto. O output resultante mostra a proteína a agarrar ativamente a cadeia de DNA, enquanto a pequena molécula do fármaco fica perfeitamente encaixada no sítio de ligação. Como foi feito o folding de tudo no mesmo espaço computacional, o modelo da proteína reflete automaticamente as mudanças estruturais causadas tanto pelo DNA como pelo fármaco. Este não é simplesmente o antigo engine do AlphaFold com um algoritmo de docking acoplado no fim. É uma arquitetura de modelo completamente distinta, treinada diretamente na forma como diferentes classes de moléculas biológicas interagem no espaço físico. A mudança mais significativa com o AlphaFold 3 é que já não estás a gerar partes biológicas isoladas, mas sim a prever máquinas moleculares completas e em interação, exatamente como existem no mundo físico. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui fala o Alex da DEV STORIES DOT EU. AlphaFold: Predição de Estrutura de Proteínas, episódio 11 de 21. Já não precisas de um curso de engenharia ou de um supercomputador para correr a IA biomolecular mais avançada do mundo. A barreira de entrada desceu para um simples web browser. Esse é o AlphaFold Server, a tua porta de entrada direta para o AlphaFold 3. Historicamente, correr predições de estruturas complexas significava gerir dependências de software, fazer download de terabytes de bases de dados genéticas e manter GPUs potentes. O AlphaFold Server ultrapassa tudo isso. É uma interface web totalmente gráfica que permite a biólogos e químicos correr jobs do AlphaFold 3 sem escreverem uma única linha de código. Todos os alinhamentos de múltiplas sequências, pesquisa de templates e folding baseado em difusão acontecem remotamente numa infraestrutura de compute partilhada. Antes de passarmos por uma predição, precisamos de esclarecer dois limites estritos. Primeiro, o AlphaFold Server é exclusivamente para uso não comercial. Segundo, como depende dos recursos de compute fornecidos, a tua conta está sujeita a limites diários de jobs. Não o podes usar para fazer brute-force a uma pipeline de screening massiva. Foi concebido para um planeamento experimental direcionado, de um único job. Eis como constróis um job de predição complexo e multi-chain na interface. Todo o workflow gira em torno da adição de entidades separadas a um workspace partilhado. Começa com a tua proteína principal. Clicas no botão para adicionar uma entidade de proteína. Aparece um campo de texto. Colas simplesmente a tua sequência de aminoácidos de uma letra diretamente nessa caixa. Se esperas que esta proteína forme um homodímero, não precisas de colar a sequência duas vezes. Apenas alteras a definição do número de cópias para dois, e o sistema trata da estequiometria. Agora, a segunda parte disto é adicionar moléculas interagentes. Supõe que queres ver como essa proteína se liga a um segmento específico de DNA. Clicas para adicionar uma entidade de DNA e colas a sequência da forward strand. Para construir a dupla hélice propriamente dita, adicionas outra entidade de DNA e colas a sequência reverse complementary. O AlphaFold 3 vai modelá-los juntos no mesmo espaço tridimensional, prevendo tanto o emparelhamento de bases do DNA como a sua interface estrutural com a tua proteína. É aqui que fica interessante para componentes não poliméricos. O servidor suporta ligandos, iões e cofatores nativamente. Se a tua proteína requer um ião metálico específico para estabilizar o seu folding, clicas para adicionar uma entidade de ião. Não precisas de procurar identificadores químicos complexos nem de escrever strings SMILES para componentes standard. O servidor fornece um dropdown menu built-in. Pesquisas simplesmente por um ião comum, selecionas Magnésio ou Zinco, defines quantas cópias precisas, e a interface regista a escolha. Assim que o teu workspace contiver a sequência da proteína, as duas strands de DNA e o ião selecionado, clicas no botão de submit. Esse é todo o setup. Nos bastidores, o servidor assume o controlo. Ele gere as pipelines de alinhamento, alimenta a neural network do AlphaFold 3 com os dados e corre o processo de difusão estrutural. Quando o job terminar, os resultados carregam diretamente no teu browser. Ficas com um viewer 3D embedded para inspecionar o complexo previsto imediatamente. Mais importante ainda, tens um package limpo para download, contendo os ficheiros de coordenadas atómicas previstos e todas as métricas de confiança associadas para a tua análise local. O verdadeiro poder do servidor não está apenas no acesso imediato ao modelo, mas na enorme velocidade de iteração que ele proporciona ao testar hipóteses estruturais. É tudo por este episódio. Obrigado por ouvires, e continua a construir!

Olá, daqui é o Alex da DEV STORIES DOT EU. AlphaFold: Protein Structure Prediction, episódio 12 de 21. Prever exatamente como um novo medicamento se liga a uma target protein parece uma descoberta revolucionária, até perceberes que a IA simplesmente colocou dois átomos de carbono sólidos exatamente no mesmo espaço físico. Uma estrutura lindamente renderizada é inútil se desafiar as leis da física. Hoje, abordamos a Interpretação dos Resultados do AlphaFold 3 para te ajudar a separar o insight biológico das alucinações computacionais. O AlphaFold 3 gera um ficheiro de coordenadas tridimensionais juntamente com um conjunto de métricas específicas. Avaliar um resultado requer a leitura conjunta destas métricas, porque um score alto numa área pode mascarar uma falha catastrófica noutra. Primeiro, olhas para a confiança local usando uma métrica chamada pLDDT. Isto classifica cada átomo ou resíduo numa escala de zero a cem. Um score alto significa que o modelo tem muita certeza sobre a geometria local específica dessa chain. Mas a confiança local por si só não é suficiente. Podes ter uma proteína perfeitamente prevista e um ligand de pequena molécula perfeitamente previsto, a flutuar independentemente no espaço. Para saberes se eles realmente interagem, tens de verificar o Predicted Aligned Error, ou PAE. O PAE mede o erro de posição esperado em Angstroms. Valores mais baixos são melhores. Quando prevês complexos, como uma proteína a ligar-se a uma strand de DNA ou a uma molécula de um medicamento, focas-te no cross-PAE. Pensa no output do PAE como uma matriz de heat map. A diagonal mostra o nível de confiança do modelo sobre a estrutura interna de uma única chain. As áreas fora da diagonal mostram a confiança entre diferentes entidades. Se o PAE entre a tua proteína e o teu ligand for baixo, o AlphaFold tem alta confiança nas suas posições relativas. Ele acredita fortemente que o ligand assenta exatamente nesse pocket específico. Aqui está o insight principal. Alta confiança não significa automaticamente realidade física. O AlphaFold 3 é um modelo de deep learning, não um simulador de dinâmica molecular. Ele prioriza padrões espaciais reconhecidos em vez de física estrita. Isto leva-nos ao clash score. Como o AlphaFold 3 modela ligands, ácidos nucleicos e resíduos modificados diretamente, sem um step de relaxamento rigoroso baseado em física, os outputs podem conter steric clashes severos. Um clash acontece quando dois átomos recebem coordenadas que os colocam impossivelmente próximos, sobrepondo-se efetivamente. O servidor calcula e fornece um clash score para o teu output. Um clash score alto é uma red flag massiva. Considera um cenário em que analisas um output e a chain principal da proteína tem um pLDDT acima de 90. O cross-PAE entre a proteína e o teu target ligand é muito baixo. As métricas de interface sugerem um evento de binding forte e confiante. No papel, parece uma previsão de docking perfeita. Depois verificas o clash score e está muito elevado. Se carregares as coordenadas físicas num viewer, vais ver o ligand a passar diretamente através do backbone da proteína. A neural network reconheceu que o ligand pertence àquele binding pocket geral, mas falhou em encaminhar os átomos à volta das side chains existentes. Ela alucinou uma molécula fantasma que ignora a matéria sólida. Quando avalias um resultado do AlphaFold 3, tens de verificar simultaneamente a confiança estrutural e o realismo físico. Usa o pLDDT para verificar a forma das moléculas individuais. Usa o PAE para confirmar se elas interagem onde esperas. Depois, verifica o clash score para garantir que o modelo não violou a química básica para forçar essa interação a acontecer. Lembra-te que um modelo de deep learning produz uma hipótese espacial como output baseada no reconhecimento de padrões, por isso uma previsão com alta confiança só é válida se os átomos realmente respeitarem as leis da física. É tudo por este episódio. Obrigado por ouvires, e continua a construir!

Olá, daqui é o Alex da DEV STORIES DOT EU. AlphaFold: Previsão de Estruturas de Proteínas, episódio 13 de 21. A DeepMind tornou open-source o seu mais recente modelo de biologia estrutural, mas se clonares o repository e tentares correr o código, ele vai falhar imediatamente. O código é totalmente público, mas a rede neuronal que faz as previsões é rigorosamente controlada. Hoje, vamos olhar para o inference pipeline do AlphaFold 3 e como é que podes fazer o seu deploy. Para correres o AlphaFold 3 localmente, tens de juntar duas partes separadas: o código de execução e os parâmetros do modelo. O repository dá-te a lógica do pipeline. Para os parâmetros, especificamente os weights da versão três ponto zero ponto um, tens de pedir acesso separadamente. A Google exige que submetas um formulário a detalhar o teu use case de investigação não comercial. Assim que aprovarem o teu pedido, recebes um link para fazeres o download dos weights pesados do modelo. Esta abordagem dividida permite à DeepMind restringir o uso comercial, ao mesmo tempo que deixa os investigadores inspecionar e correr o pipeline open-source no seu próprio hardware. Depois de fazeres o download dos weights, o teu próximo passo é definir o que queres que o modelo preveja. Versões anteriores do AlphaFold lidavam principalmente com chains de proteínas individuais, por isso podias simplesmente passar uma string de texto simples de aminoácidos. O AlphaFold 3 modela interações complexas entre diversos tipos de moléculas, por isso uma string básica já não é suficiente. Em vez disso, crias um ficheiro de configuração. Este ficheiro funciona como um manifest completo para o teu alvo biológico. Tu especificas as moléculas exatas envolvidas na tua experiência. Pode ser uma proteína standard, uma cadeia de DNA ou RNA, ou um ligando específico de pequena molécula. Neste mesmo ficheiro de configuração, também defines as seeds de aleatoriedade. Como a nova arquitetura do modelo depende de um processo de difusão para gerar a estrutura tridimensional final, introduzir pequenas variações na random seed produz diferentes estados estruturais possíveis. Ao definires múltiplas seeds na tua configuração, instruis o pipeline a gerar previsões distintas para o exato mesmo input. Também declaras uma versão de dialeto neste ficheiro, o que simplesmente diz ao parsing engine para aplicar as regras de validação do AlphaFold 3 ao teu manifest. Com o download dos weights feito e o teu ficheiro de configuração pronto, passas para a execução. Como este pipeline depende de versões muito específicas de libraries de machine learning e drivers de GPU, corrê-lo diretamente no teu sistema operativo host é arriscado. O workflow oficial depende do Docker. Tu fazes build de uma image de container diretamente a partir do repository fornecido, garantindo o ambiente perfeito. Para realmente correres a inference, lanças este container e ligas-o à tua máquina host fazendo o mount de três caminhos críticos. Primeiro, fazes o mount da pasta que contém o teu ficheiro de configuração de input. Segundo, fazes o mount do diretório que contém aqueles weights massivos e aprovados do modelo, que descarregaste anteriormente. Finalmente, fazes o mount de um diretório vazio onde o container pode escrever os seus resultados. Assim que o container arranca, invocas o run script principal. O pipeline valida o teu manifest de input, carrega os weights do diretório onde fizeste o mount para a memória da GPU e começa a previsão estrutural. Quando o processo terminar, a pasta de output onde fizeste o mount vai conter as coordenadas finais das moléculas que pediste, formatadas e prontas para visualização. O principal desafio deste pipeline não é o código subjacente, mas sim gerir a logística de assegurar os weights do modelo e estruturar meticulosamente o teu ficheiro de configuração para mapear interações biológicas complexas. Se quiseres apoiar o programa, podes procurar por DevStoriesEU no Patreon. É tudo por este episódio. Obrigado por ouvires, e continua a programar!

Olá, daqui fala o Alex da DEV STORIES DOT EU. AlphaFold: Predição da Estrutura de Proteínas, episódio 14 de 21. O maior erro que os engenheiros cometem ao fazer o deploy do AlphaFold é deixar GPUs caras paradas enquanto esperam que as queries básicas à base de dados terminem. Provisionas uma A100, arrancas com um job e vês a utilização ficar a zeros durante horas. A solução é separar os teus ambientes de execução, que é exatamente o que vamos abordar hoje com Data Pipelines e Hardware Requirements. O AlphaFold três faz dois tipos de trabalho fundamentalmente diferentes. Primeiro, pesquisa em bases de dados genéticas gigantes para construir Multiple Sequence Alignments e encontrar templates estruturais. Segundo, passa esses dados processados para a rede neuronal para prever a estrutura tridimensional final. A pesquisa na base de dados é totalmente limitada pela CPU e pelas velocidades de leitura do storage. A predição da rede neuronal precisa de uma GPU. Se correres o setup default, o AlphaFold faz ambas as etapas em sequência na mesma máquina. Isto significa que a tua GPU cara não faz absolutamente nada enquanto a tua CPU passa horas a processar terabytes de bases de dados de referência. O ponto chave é este. O repositório fornece duas flags de execução específicas para desacoplar estes workloads. A primeira flag é run data pipeline. Quando executas o run script com esta flag ativada e o run inference desativado, o AlphaFold faz apenas as pesquisas genéticas e de templates. Ele lê a tua configuração de input, faz queries às bases de dados locais e gera todas as sequence features necessárias. A seguir, guarda este estado de dados intermédio no disco. O mais importante é que esta etapa requer zero recursos de GPU. Depende estritamente de uma máquina com muitos cores de CPU e drives SSD NVMe rápidas para lidar com as pesadas operações de input e output. Assim que o data pipeline terminar de construir as features, usas a segunda flag. Executas o script novamente, mas defines o run data pipeline para false e o run inference para true. O AlphaFold vai ignorar completamente a pesquisa na base de dados. Ele carrega diretamente os dados das features em cache que acabaste de gerar, inicializa os pesos do modelo e executa o forward pass da rede neuronal. Esta etapa é completamente GPU bound. Depende exclusivamente do teu acelerador de hardware e da sua memória de alta largura de banda. Esta separação explícita é como desenhas uma infraestrutura enterprise adequada. Em vez de ligares drives gigantes de bases de dados a várias máquinas com GPUs caras, provisionas uma frota de nodes de CPU económicos. Distribuis as tuas requests de predição recebidas por estes nodes de CPU, usando-os para fazer queries agressivamente às bases de dados e gerar alinhamentos em paralelo. Sempre que um node de CPU termina um job do data pipeline, ele larga os ficheiros de features resultantes num sistema de storage partilhado. Entretanto, manténs um único node altamente utilizado com uma GPU poderosa. Esta máquina existe estritamente para inferência. Ela monitoriza constantemente o storage partilhado. Quando um novo ficheiro de features aparece, ela pega nele, corre a predição da rede neuronal em minutos, escreve a estrutura molecular final e puxa imediatamente o ficheiro seguinte. A tua GPU nunca mais fica à espera de um bottleneck de storage ou de uma pesquisa na base de dados. Desacoplar o data pipeline CPU bound da inferência GPU bound é a maneira mais eficaz de escalar a predição da estrutura de proteínas, mantendo os custos de hardware sob controlo. Obrigado por passares uns minutos comigo. Até à próxima, fica bem.

Olá, daqui é o Alex da DEV STORIES DOT EU. AlphaFold: Previsão da Estrutura de Proteínas, episódio 15 de 21. O teu modelo de proteína é surpreendentemente pequeno, com menos de cem milhões de parâmetros. Consegues prever com sucesso a estrutura de uma sequência de 500 resíduos numa GPU standard de 16 gigabytes, mas quando dás como input uma sequência de 1500 resíduos, o processo crasha instantaneamente com um out of memory error, exigindo de repente mais de 80 gigabytes de VRAM. Este scaling catastrófico acontece devido a uma característica arquitetónica específica chamada Memory Bottleneck: Attention O(n³). De acordo com o paper do FastFold de Cheng et al., este consumo explosivo de memória não tem nada a ver com os weights do modelo. Todo o modelo AlphaFold tem apenas 93 milhões de parâmetros. O bottleneck está inteiramente nas activations intermédias geradas durante o forward pass. À medida que o sequence length aumenta, a memória necessária para guardar estes tensores intermédios escala de forma cúbica. Para perceber porquê, temos de olhar para dentro do Evoformer. O Evoformer é o tronco estrutural principal do AlphaFold, composto por 48 blocos empilhados. Dentro de cada bloco, o modelo depende de um mecanismo de attention especializado. Transformers standard, como os usados em language models, tipicamente têm mecanismos de attention onde a memória escala quadraticamente com o sequence length. Eles apenas comparam uma sequência unidimensional consigo própria. O AlphaFold é diferente. Usa uma representação intermédia bidimensional para modelar interações pair-wise entre aminoácidos. Aqui está o insight principal. Para prever com precisão estruturas de proteínas tridimensionais, a network não pode simplesmente olhar para pares de resíduos de forma isolada. Tem de avaliar relações triangulares para garantir que as distâncias previstas entre três pontos são fisicamente possíveis no espaço tridimensional. Para calcular isto, o módulo de attention gera tensores de activation intermédios. O memory footprint destes tensores segue uma fórmula rigorosa. É o sequence length ao cubo, multiplicado pelo número de attention heads, multiplicado pelo tamanho em bytes do data type. O AlphaFold usa precisão BFloat16, que ocupa dois bytes por valor. Vamos seguir a matemática para o developer que crashou a sua GPU. Quando passas uma sequência de 500 resíduos para o modelo, o sequence length é 500. O cubo de 500 é 125 milhões. Se tiveres quatro attention heads, multiplicas 125 milhões por quatro, e depois por dois bytes para a precisão. Uma única attention layer cria cerca de um gigabyte de activations intermédias. A tua GPU de 16 gigabytes lida com isto com espaço de sobra. Agora mudas o input para uma sequência de 1500 resíduos. Apenas triplicaste o input length. Mas como o scaling é cúbico, tens de elevar 1500 ao cubo, o que dá mais de 3,3 mil milhões. Multiplica isso por quatro heads e dois bytes, e exatamente a mesma attention layer agora exige quase 27 gigabytes de memória apenas para guardar as suas activations. Como a network passa estes dados por 48 blocos Evoformer consecutivos, o requisito total de memória ultrapassa instantaneamente os 80 gigabytes. Os tensores aumentam tão rapidamente que o hardware simplesmente aborta o processo. É por isto que o AlphaFold exige uma otimização pesada para sequências mais longas. O parameter count bruto de uma neural network não te diz quase nada sobre os seus requisitos de hardware quando a geometria interna força os dados intermédios a crescer em três dimensões em simultâneo. Se quiseres apoiar o programa, podes procurar por DevStoriesEU no Patreon. É tudo por este episódio. Obrigado por ouvires, e continua a programar!

Olá, daqui fala o Alex da DEV STORIES DOT EU. AlphaFold: Protein Structure Prediction, episódio 16 de 21. Se um tensor intermédio for demasiado grande para uma única GPU, o instinto normal é dividir os parâmetros do modelo por várias placas. Mas quando a tua neural network tem apenas 93 milhões de parâmetros e os teus activation tensors consomem 20 gigabytes, dividir o modelo não resolve nada. Precisas de dividir a geometria dos próprios dados. É exatamente isso que o Dynamic Axial Parallelism resolve. Para perceberes por que é que esta abordagem existe, temos de olhar para os bottlenecks identificados no paper do FastFold. O motor principal do AlphaFold é o bloco Evoformer. Ele processa multiple sequence alignments e pair representations, que funcionam essencialmente como enormes grelhas bidimensionais de dados. O Tensor Parallelism standard tenta lidar com workloads pesados dividindo os linear layer weights por diferentes GPUs. Para o AlphaFold, isto cria ineficiências graves. O Tensor Parallelism exige uma sincronização frequente e pesada, desencadeando até doze passos de comunicação por bloco. Além disso, só se aplica aos módulos de attention e feed-forward. Pior ainda, o seu scaling é estritamente limitado pelo número de attention heads. Na pair stack do AlphaFold, isso limita-te a um máximo de apenas quatro GPUs. O Dynamic Axial Parallelism, ou DAP, abandona completamente a abordagem de weight-splitting. Em vez disso, o DAP mantém os parâmetros completos do modelo intactos em cada um dos devices. O modelo em si nunca é distribuído. As intermediate activations é que são. O Evoformer processa dados ao longo de duas sequence dimensions, mas as operações matemáticas só acontecem ao longo de uma dimensão de cada vez. Este comportamento permite que o DAP divida os dados de forma limpa ao longo da dimensão inativa. Podes imaginar isto num setup multi-GPU. Uma enorme grelha de sequence data entra na layer. O DAP corta este input horizontalmente. A GPU zero fica com o primeiro chunk de linhas, a GPU um fica com o seguinte, e por aí fora. Cada GPU calcula então a attention para a sua fatia específica de dados. Como cada GPU tem uma cópia completa dos model weights, e como a computação está isolada no eixo horizontal, as GPUs não precisam de falar umas com as outras. Elas computam os seus chunks de forma independente. Aqui está o ponto chave. Assim que esse cálculo horizontal termina, o modelo precisa de processar os dados ao longo da sequence dimension vertical. Para que isto aconteça, as GPUs executam um passo de comunicação all-to-all. Elas transpõem a geometria dos dados através da network. A GPU zero faz scatter dos seus fragmentos de coluna para os outros devices e faz gather das peças de que precisa para a fase seguinte. A orientação da divisão inverte-se. Agora os dados são cortados verticalmente ao longo do cluster. As GPUs correm imediatamente a layer seguinte de cálculos de attention, mais uma vez com zero cross-talk durante a matemática em si. Esta estratégia de transposição reduz o volume de comunicação numa ordem de magnitude completa em comparação com o Tensor Parallelism standard. Também possibilita o paralelismo em todos os módulos computacionais do Evoformer. Como os activation tensors massivos estão distribuídos uniformemente pelo cluster, o consumo geral de memória cai drasticamente, evitando que devices individuais crashem sob o peso de sequências longas. Quando o teu bottleneck de hardware é causado pelo simples tamanho físico das intermediate representations, e não pela profundidade da neural network, tu não fragmentas a arquitetura. Distribuis os eixos dos dados. É tudo por este episódio. Obrigado por ouvires, e continua a programar!

Olá, daqui fala o Alex da DEV STORIES DOT EU. AlphaFold: Predição da Estrutura de Proteínas, episódio 17 de 21. E se o teu compilador fosse inteligente o suficiente para fazer o slicing automático das tuas operações matemáticas de matrizes, de forma a encaixar perfeitamente no budget de memória do teu hardware? Imagina um engenheiro a passar dias a fazer profiling e slicing de código manualmente para evitar erros de Out of Memory. Sempre que o tamanho da sequência muda, os slices fixos falham. Compara isso com um sistema que estima dinamicamente o memory footprint e gera código particionado on the fly. O AutoChunk é o algoritmo que faz isto acontecer. No paper do FastFold, os investigadores abordaram os enormes bottlenecks de memória ao correr sequências longas em modelos de predição de proteínas. A abordagem standard para evitar erros de Out of Memory é o chunking. Particionas um tensor ao longo de dimensões que não interagem durante uma computação, processas esses blocos mais pequenos sequencialmente e voltas a juntá-los. Normalmente, este é um processo manual e trabalhoso. Fazes o profiling do código, tentas adivinhar os melhores tamanhos para os slices e fazes hardcode dos limites. O paper do FastFold aponta que os esquemas de chunking fixos são ineficientes porque não se conseguem adaptar a dimensões de sequência variáveis ou a memory spikes operacionais específicos. Aqui está o insight principal. Os investigadores do FastFold observaram que 95 por cento das operações no modelo usam menos de 20 por cento da peak memory. O chunking ao nível do módulo é totalmente desnecessário. Só precisas de fazer chunking das operações específicas que causam os memory spikes. O AutoChunk automatiza isto ao analisar o teu código como um computational graph. Ele recebe esse graph e o teu budget específico de memória de hardware como inputs. Em termos simples, o algoritmo corre um loop contínuo. Enquanto uma estratégia de memória ainda for necessária, ele estima o consumo de memória do graph para encontrar o node único com a maior utilização. Um node aqui é uma operação básica, como uma adição ou uma projeção linear. Assim que sinaliza esse node de peak memory, o AutoChunk determina o chunk range máximo possível a estender-se a partir dele. Ele calcula isto ao verificar todos os nodes ativos que atualmente mantêm dados em memória. A seguir, identifica todas as estratégias de chunking possíveis dentro desse range, fazendo o tracing das dimensões do tensor para cima através do graph. Uma dimensão só pode sofrer chunking se for uma free dimension, o que significa que não ocorre nenhuma computação através dela durante esse range específico de operações. Como fazer o tracing de cada output para cima é computacionalmente dispendioso, o AutoChunk usa uma pesquisa em duas fases. A fase um verifica se os nodes de início e fim de um range cumprem as regras de chunking. Se cumprirem, a fase dois faz uma verificação profunda para todos os nodes intermédios. Depois de mapear as possibilidades, o AutoChunk seleciona a estratégia que mantém a memória estritamente abaixo do budget, minimizando a penalização na velocidade de execução. Finalmente, o algoritmo sai do loop e passa as estratégias escolhidas para um code generator, inserindo a lógica de partição ideal diretamente no graph. Já não precisas de fazer hardcode de slices de matrizes e esperar que aguentem em produção. O sistema analisa o estado da memória ativa e escreve a lógica de partição por ti. A conclusão mais útil é que o chunking nunca deve ser uma configuração estática ao nível do módulo; ao isolar e particionar apenas as operações outlier específicas que causam peak memory spikes, consegues processar sequências muito mais longas sem destruir a velocidade de execução. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui é o Alex da DEV STORIES DOT EU. AlphaFold: Previsão da Estrutura de Proteínas, episódio 18 de 21. Arrancas com um cluster enorme, multimilionário, com mil GPUs para treinar o teu modelo, mas a tua utilização estagna. Todo o teu distributed ring para completamente porque uma única máquina apanhou uma sequência evolutiva altamente complexa e precisa de 100 segundos para gerar um alinhamento. Superar o communication imbalance é como resolves exatamente este bottleneck. O problema subjacente aqui é conhecido como o straggler problem. No treino distribuído, cada GPU no teu cluster processa um batch local de dados. No final de um training step, todas as GPUs têm de chegar a um synchronization point para partilhar os seus gradients. O teu cluster só avança à velocidade da máquina mais lenta. Como detalhado no paper ScaleFold de Zhu et al., a preparação de training batches para protein folding é altamente variável. Algumas sequências de aminoácidos são curtas e simples. Outras exigem multi-sequence alignments massivos, demorando até três ordens de grandeza mais tempo a preparar. Um batch rápido demora uma fração de segundo. Um batch lento demora 100 segundos. Se usares o data loader default do PyTorch, ele gera batches numa ordem estrita e determinística. Se um dos teus workers do data loader ficar preso a preparar uma sequência enorme, o processo de treino espera que esse batch específico termine. Mesmo que outros workers já tenham acabado de preparar os batches subsequentes, o pipeline fica bloqueado. O teu training step termina, a tua GPU local fica idle e, como não consegue chegar ao synchronization point, as outras 999 GPUs no teu cluster ficam completamente idle à espera dela. Os autores do ScaleFold resolveram isto construindo um Non-Blocking Data Pipeline. Em vez de forçar uma sequência rígida, o pipeline faz yield de um batch no momento em que qualquer batch em processamento fique pronto. Aqui está o ponto chave. O sistema desacopla a ordem de preparação de dados da ordem de consumo de dados usando uma priority queue. Primeiro, tu atribuis vários workers do data loader para preparar batches de forma assíncrona. Quando um worker recebe um batch para processar, o sistema marca esse batch com o seu sequence index original. Este index torna-se o seu priority score. Vamos seguir a lógica. O worker um recebe o batch A, uma sequência rápida. O worker dois recebe o batch B, a sequência de 100 segundos. O worker três recebe o batch C, outra sequência rápida. O worker um termina o batch A imediatamente e faz push para a priority queue. O processo de treino consome-o e executa um step. O worker dois ainda está a processar o enorme batch B. No sistema default, a GPU parava e ficava à espera. Mas neste non-blocking pipeline, o worker três termina o batch C e faz push para a priority queue. Como o batch B ainda não está pronto, a queue simplesmente entrega o batch C ao processo de treino. As GPUs continuam o treino sem pausas. Eventualmente, o worker dois termina o batch B e faz push para a queue. Como o batch B tem um original index anterior, a priority queue coloca-o imediatamente na frente absoluta da fila. O processo de treino consome-o logo no step seguinte. Este mecanismo de prioridade garante um best-effort na ordenação das samples. A sequência global exata dos dados varia ligeiramente entre diferentes training runs, mas o paper confirma que isto não afeta negativamente a convergência do treino. Tu eliminas o idle time causado por picos de uso de CPU em background e data samples complexas. O data batch mais lento já não dita a velocidade de execução da tua máquina mais rápida. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui fala o Alex da DEV STORIES DOT EU. AlphaFold: Predição da Estrutura de Proteínas, episódio 19 de 21. Às vezes, a GPU não é propriamente lenta a fazer cálculos matemáticos. Ela simplesmente passa todo o tempo à espera que a CPU lhe dê a próxima instrução, deixando o teu profiler cheio de enormes espaços em branco. A solução para este problema é Kernel Fusion e otimização da GPU. De acordo com o paper do ScaleFold, o treino do modelo AlphaFold requer o lançamento de mais de 150.000 operações individuais por step. A maioria destas são kernels memory-bound, como pequenos LayerNorms ou operações element-wise fragmentadas. Sempre que a CPU diz à GPU para correr uma operação de PyTorch, existe um launch overhead. Quando encadeias 150.000 pequenas operações, esse overhead eclipsa completamente a matemática em si. Olha para a Multi-Head Attention do AlphaFold, que consome cerca de trinta e quatro por cento do tempo total do step de treino. Não é uma attention standard. O AlphaFold adiciona um termo específico de pair bias à matriz de logits mesmo antes da operação de softmax. No PyTorch default, isto cria uma chain de eventos separados. Primeiro, lanças um kernel para a batched matrix multiplication. A GPU lê os dados da memória global, faz os cálculos e escreve o resultado de volta. Depois, a CPU lança um segundo kernel para adicionar o pair bias. A GPU volta a ler a matriz da memória, adiciona o bias e escreve-a de novo. Finalmente, um terceiro kernel é lançado para o softmax. Esta constante ida e volta à memória global causa starvation na GPU. Os autores do paper do ScaleFold resolvem isto ao escreverem custom kernels usando o compiler Triton da OpenAI. Em vez de steps separados, eles fundem toda a sequência num único kernel. Aqui está o ponto chave. Ao fundir as operações, a GPU carrega os dados de input para a sua SRAM on-chip rápida apenas uma vez. Ela faz a matrix multiplication, adiciona o pair bias, aplica o softmax e faz a multiplicação final diretamente dentro da SRAM. Só escreve para a memória global quando todo o bloco de Multi-Head Attention está terminado. Bibliotecas otimizadas standard, como o FlashAttention, não funcionam aqui por causa dessa injeção única de pair bias, tornando um custom kernel de Triton estritamente necessário para contornar o bottleneck de memory bandwidth. Esta abordagem estende-se a outras partes fragmentadas do modelo. O LayerNorm consome catorze por cento do tempo do step porque o AlphaFold usa dimensões pequenas, tipicamente 128 ou 256. Ao usar Dynamic Axial Parallelism, ou DAP, estes tamanhos de problema sofrem um scale down ainda maior, deixando o hardware subutilizado. O ScaleFold introduz um kernel de LayerNorm fused, onde um único thread block de CUDA processa múltiplas rows de input de uma só vez. Ele calcula as estatísticas de normalização numa única pass, em vez de usar métodos iterativos caros, e usa uma reduction de dois steps na backward pass para evitar atomic operations. Até o optimizer é fused. Os autores do ScaleFold combinaram o optimizer Adam e o Stochastic Weight Averaging num único kernel. Os valores intermédios entre os steps do optimizer ficam nos registers da GPU, fazendo bypass completo às leituras de memória. Para o resto do modelo, eles dependem das compiler tools do PyTorch para fazer fuse automático das restantes operações fragmentadas, particularmente em componentes seriais como o Structure Module. Quando estás a lidar com milhares de pequenas operações memory-bound, o teu bottleneck não são os teraflops, é a memory bandwidth e o launch overhead da CPU. Fazer o fuse dessas operações em blocos de execução únicos e contínuos é a única maneira de realmente saturar o hardware. Obrigado por ouvirem, happy coding a todos!

Olá, daqui fala o Alex da DEV STORIES DOT EU. AlphaFold: Previsão da Estrutura de Proteínas, episódio 20 de 21. Escalar um modelo de IA de 128 GPUs para 2000 GPUs não se resume apenas a comprar mais hardware; requer redesenhar completamente a forma como o sistema respira. Quando adicionas tanto compute, descobres bottlenecks enormes na forma como as tuas máquinas host comunicam com os teus aceleradores. Resolver esses bottlenecks requer construir um pipeline de high-throughput, que foi exatamente como os investigadores reduziram recentemente o pretraining do AlphaFold de sete dias para dez horas. O blueprint para esta arquitetura vem do paper ScaleFold. Os autores identificaram uma realidade brutal de scaling. À medida que distribuis um modelo por milhares de GPUs, o workload matemático por cada GPU individual encolhe. As GPUs terminam os seus cálculos tão rápido que o CPU não consegue emitir novas kernel instructions rápido o suficiente para as manter ocupadas. O overhead do CPU torna-se o bottleneck dominante. Para corrigir isto, removes o CPU do execution loop usando CUDA Graphs. Um CUDA Graph captura uma sequência de operações da GPU e as suas memory allocations num único graph estático. Uma vez capturado, a GPU executa o graph inteiro diretamente, sem esperar que o CPU faça o dispatch de cada kernel individual. Aqui está o insight principal. Não podes simplesmente aplicar CUDA Graphs standard ao AlphaFold. A arquitetura do AlphaFold usa um mecanismo de recycling, alimentando as previsões de volta para o modelo de forma dinâmica. Isto cria um computation graph dinâmico. Se as operações mudarem, um CUDA Graph standard quebra e tem de ser recapturado, o que arruína o ganho de performance. O paper ScaleFold resolve isto desenhando uma cache de CUDA Graphs. Em vez de um graph rígido, o sistema captura e armazena múltiplos graphs que representam os diferentes cenários de recycling. Quando a execução dinâmica muda, o sistema simplesmente vai buscar o graph pré-compilado correto à cache. O CPU sofre um bypass completo. Agora, a segunda peça desta arquitetura de high-throughput. Assim que o teu training step time está altamente otimizado, surge um novo bottleneck. Num pipeline standard, os training nodes pausam periodicamente para correr métricas de validação. De acordo com o paper ScaleFold, à medida que os step times encolhem, esta fase de evaluation pode consumir até 43 por cento do tempo total do pipeline. O teu enorme e caro training cluster fica idle durante quase metade do tempo apenas a verificar o seu próprio trabalho. A solução é Asynchronous Evaluation. Desacoplas completamente a validação do training loop. Os training nodes nunca pausam. Eles calculam constantemente gradients, atualizam weights, e fazem stream de model checkpoints para uma pool separada e dedicada de evaluation nodes. Na implementação do ScaleFold, de aproximadamente 2000 GPUs, apenas 32 eram dedicadas a evaluation. O resto não fazia nada além de treinar. No entanto, mover a evaluation para nodes separados introduz uma race condition. Os evaluation nodes têm de terminar de validar um checkpoint antes que os training nodes produzam o próximo. Se a evaluation ficar para trás, o teu pipeline faz stall. Para garantir que os evaluation nodes acompanham o ritmo, o sistema faz um bypass completo ao disk storage. Todo o evaluation dataset é posto em cache diretamente na CPU DRAM nos validation nodes. Ao eliminar o CPU dispatch overhead com cached CUDA Graphs e fazer o offload da validação para asynchronous nodes com cache em memória, o pipeline nunca para. O hardware fica finalmente saturado. Ao desenhar arquiteturas at scale, a tua principal tarefa já não é otimizar a matemática; a tua principal tarefa é evitar que as GPUs fiquem à espera. Por hoje é tudo. Obrigado por ouvires — vai construir algo fixe.

Olá, daqui fala o Alex da DEV STORIES DOT EU. AlphaFold: Previsão da Estrutura de Proteínas, episódio 21 de 21. Durante anos, a indústria assumiu que prever a estrutura de uma proteína exigia designs de redes neuronais incrivelmente especializados e customizados. Precisavas de múltiplos alinhamentos de sequências, representações explícitas de pares e atualizações triangulares computacionalmente pesadas só para obter um resultado viável. Mas e se um transformer standard e genérico pudesse fazer exatamente o mesmo trabalho? A resposta é um conceito chamado flow-matching com o SimpleFold. O paper do SimpleFold da Apple apresenta uma mudança radical em relação às arquiteturas rígidas que vimos nos modelos de folding tradicionais. Elimina completamente as heurísticas específicas do domínio. Os modelos tradicionais fazem hard-code da intuição biológica na rede. Usam múltiplos alinhamentos de sequências para encontrar pistas evolutivas e atualizações triangulares para impor regras geométricas. Isto exige um compute massivo e engenharia altamente especializada. O SimpleFold abandona estas mecânicas, optando antes por um modelo generativo de flow-matching construído exclusivamente com blocos transformer de propósito geral. O SimpleFold trata o folding como uma task generativa condicional. Pensa nos modelos text-to-image, onde um prompt de texto guia a geração de uma imagem. Aqui, a sequência de aminoácidos é o prompt, e o output é a estrutura tridimensional de coordenadas de todos os átomos. Consegue isto usando flow-matching. O flow-matching gera dados definindo um caminho contínuo desde uma distribuição de ruído simples até uma distribuição de dados complexa. Durante o treino, o modelo aprende um campo de velocidade dependente do tempo. Integra uma equação diferencial ordinária ao longo do tempo, movendo gradualmente o ruído aleatório em direção às coordenadas atómicas verdadeiras. O processo começa quando um modelo de linguagem de proteínas pré-treinado e frozen, especificamente o ESM2, converte a sequência de aminoácidos de input num sequence embedding. Ao mesmo tempo, um atom encoder recebe as coordenadas atómicas ruidosas e processa-as em atom tokens. Aqui está o insight principal. Em vez de manter mapas de interação pairwise complexos e pesados na memória, o SimpleFold usa uma operação de grouping. Simplesmente calcula a média dos atom tokens pertencentes ao mesmo resíduo num único residue token. Estes residue tokens são concatenados com os sequence embeddings e passados para o residue trunk. Este trunk contém a maior parte dos parâmetros do modelo. É composto inteiramente por blocos transformer standard com layers adaptativas condicionadas ao timestep do flow. Não há módulos geométricos equivariantes nem matemática triangular. Apenas operações standard de attention e scaling. Finalmente, uma operação de ungrouping faz o broadcast dos residue tokens atualizados de volta para os seus átomos individuais. Um atom decoder prevê então o campo de velocidade para atualizar as posições finais dos átomos. Durante o treino, o sistema não faz sample do tempo de forma uniforme. Faz um oversample forte dos timesteps mais próximos do manifold de dados limpos. Como as estruturas de proteínas têm uma hierarquia estrita coarse-to-fine, este foco na fase final força o modelo a aprender estruturas altamente refinadas, incluindo side chains delicadas. Além disso, como o modelo usa um objetivo generativo em vez de um objetivo de regressão determinístico, captura naturalmente a incerteza. Se passares a mesma sequência pelo SimpleFold várias vezes, ele pode gerar um ensemble de diferentes conformações válidas, refletindo com precisão como as proteínas realmente se movem e existem na natureza. O SimpleFold prova que, se mapeares o problema corretamente, um transformer de propósito geral pode aprender a física subjacente ao protein folding diretamente a partir dos dados. Encorajo-te a ler o paper, a explorar a documentação oficial e a tentar correr o código no teu próprio hardware. Também podes visitar devstories.eu para sugerir tópicos para a nossa próxima série. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!