[IA na veIA nº 41] Odin liga o modo Ragnarok nos grafos com texto

IA na veIA é uma iniciativa que explica os avanços da inteligência artificial com bom humor e analogias divertidas vindas direto do universo Geek. Aqui, conceitos complexos ganham vida através de comparações com filmes, séries, games e HQs, tornando a tecnologia mais próxima e muito mais divertida para todos.

A missão é democratizar o conhecimento sobre inteligência artificial, aproximando a comunidade científica do público leigo sem aquele “tecniquês” que dá sono. Ao usar referências de sagas épicas, super-heróis ou mundos de fantasia, transformamos pesquisas e inovações em histórias que qualquer fã de cultura pop entende e curte.

Essa abordagem cria uma ponte entre especialistas e curiosos, incentivando debates sobre o impacto ético, social e econômico da IA de forma leve, mas consciente. O resultado é uma conversa mais inclusiva, onde qualquer pessoa pode entender e participar da construção do nosso futuro tecnológico.

Se você é fã de IA e também vibra com referências Geek, o IA na veIA é o seu portal para explorar ciência com uma boa dose de risadas e imaginação.

Vamos revisar o paper a seguir:

• Odin: Oriented Dual-module Integration for Text-rich Network Representation Learning
• Link do paper

---

Quem é Celso Sousa?

Celso Sousa é especialista e palestrante de inteligência artificial (IA), com doutorado em IA pela USP. Além disso, ele possui mais de 15 anos de experiência no mercado de IA para negócios.

Celso participou da gestão e/ou desenvolvimento de diversos projetos de IA nos setores financeiro e agronegócio. Alguns dos projetos de inteligência artificial mais relevantes na carreira dele são:

• previsão de produtividade de fazendas;
• reconhecimento visual de nematóides;
• visão computacional para monitoramento de rebanhos por drones;
• identificação de públicos vulneráveis;
• sistema de gerenciamento de pastejo rotacionado;
• identificação de irregularidades em notas fiscais de serviço.

Celso ministrou vários treinamentos e mentorias sobre inteligência artificial nos últimos anos. Ainda mais, ele foi Cientista Chefe na Secretaria das Finanças de Fortaleza-CE na auditoria fiscal.

O foco do Celso é desenvolver soluções de IA para empresas de todos os portes e segmentos. Entretanto, a prioridade é criar soluções de IA de baixo custo para empresas de pequeno e médio porte.

Celso iniciou a sua carreira ao abrir uma consultoria de inteligência artificial em 2009. Portanto, ele adquiriu muita experiência prática de como gerar resultados expressivos para as empresas usando IA.

A pesquisa científica do Celso é sobre classificação em grafos para alavancagem de negócios com marketing analytics. Além disso, ele publicou artigos científicos em diversas conferências internacionais de renome em 4 continentes.

Hoje ele aplica sua experiência na IA para ajudar os empresários a aumentarem os seus lucros. Ainda mais, ele implementa automações com agentes de IA para que os empresários tenham mais liberdade.

Essas automações podem ser aplicadas em diversos setores, como marketing, vendas, recursos humanos, tecnologia, financeiro, atendimento, etc.

Fale com o especialista e palestrante de inteligência artificial Celso Sousa nas redes sociais:

• Instagram: https://www.instagram.com/celsosousaia
• LinkedIn: https://www.linkedin.com/in/celso-sousa/

---

Visão geral do paper

Quando a galera fala de IA em grafos com texto, muita gente ainda está jogando em dificuldade “Normal” enquanto o problema claramente está em “Mítico+”. Text-attributed graphs misturam linguagem natural com topologia de grafo, e se você trata isso como um simples GNN ou um LM isolado, é tipo montar um time só com mago em D&D e reclamar que ninguém tanka. Yang et al já mostraram que é possível enfiar Transformers em cima de grafos, mas o casamento ainda parece mais casamento arranjado do que ship bem construído.

Li et al escancaram que a maior parte dos métodos vive em três caixinhas: LLM-as-Enhancer, LLM-as-Predictor e LLM-as-Aligner, cada um com sua própria side quest, mas nenhum virando “main story” definitivo. Em LLM-as-Enhancer, Chien et al usam modelos de linguagem para dar upgrade nas features, mas o grafo ainda é só o “suporte” silencioso, tipo personagem que só aparece pra entregar item. He et al seguem a mesma linha, pedindo para um LLM explicar textos e depois jogando isso em GNN, o que ajuda, mas continua sendo pipeline em série, não um time realmente sinérgico.

No outro extremo, Chen et al e Huang et al tratam tudo como geração de texto, convertendo estrutura em prompt, mas aí o grafo vira fanfic: rico em narrativa, pobre em garantia de que a estrutura realmente está sendo respeitada. Zhao et al aparecem com variational inference em TAGs, tentando escalar isso para redes enormes, mas ainda dentro do paradigma clássico de GNN com message passing limitado por over-smoothing.

Jin et al já tinham apontado que a combinação PLM + GNN, se feita de forma rígida, cria um abismo de profundidade: poucas camadas de grafo tentando acompanhar uma muralha de camadas Transformer, tipo um estagiário tentando acompanhar o Doutor Estranho lendo 14 milhões de futuros.

Do lado de NLP puro, Devlin et al com BERT, Brown et al com GPT-3 e Beltagy et al com SciBERT mostram o quanto PLMs conseguem cavar semântica em profundidade. Só que Hamilton et al, Kipf & Welling e Velickovic et al lembram que, sem estrutura, a rede vira só um monte de textos soltos, como se cada nó fosse um personagem sem relacionamentos no universo compartilhado.

A consequência é óbvia: ou você tem modelos que entendem bem a língua mas são cegos para o grafo, ou modelos que entendem a estrutura mas tratam texto como feature estática. Resolver essa esquizofrenia entre semântica profunda e estrutura multi-hop não é luxo, é condição mínima para qualquer pesquisa séria em TAGs que não queira continuar brigando com os mesmos benchmarks de sempre.

---

Odin como se fosse um martelo de Mjölnir para grafos com texto

Hong et al entram nesse caos propondo Odin, uma arquitetura que tenta fazer com que Transformers e GNNs conversem em pé de igualdade, sem que um vire sidekick do outro. A sacada é abandonar a ideia de “quantas hops” e focar em “em quais camadas da hierarquia semântica você injeta estrutura”. Em vez de empilhar message passing até o grafo virar mingau, eles inserem módulos de agregação em camadas específicas do Transformer, alinhando low-, mid- e high-level estrutura com low-, mid- e high-level semântica.

Na prática, Odin alterna dois tipos de camadas: TG, que fazem text–graph fusion com uma GNN “de verdade”, e TS, que fazem apenas text encoding mais uma agregação simples de vizinhos. É como montar um time em LoL com power spikes bem distribuídos: TG nas fases críticas, TS garantindo presença de mapa o tempo todo. Quando o modelo está em camadas rasas, recebe sinais de estrutura de baixo nível; nas camadas médias, vê padrões de contexto multi-hop; nas camadas profundas, enxerga estrutura global alinhada com semântica abstrata.

O truque mais ousado é concentrar a agregação na representação global do [CLS], em vez de fazer message passing token a token. Isso quebra o ciclo vicioso do over-smoothing clássico de GNNs e remove a dependência direta de profundidade em hops. Além disso, Hong et al propõem o Light Odin, uma versão “Distil” com apenas 6 camadas de Transformer, reaproveitando a mesma lógica de alinhamento estrutural, mas com custo computacional de herói low-cost em gacha game. A mensagem para a comunidade é clara: dá para ter estrutura multi-hop e semântica profunda sem sacrificar tudo em GPU como se fosse um ritual arcano.

---

E se Odin nunca tivesse saído do papel? Versão universo sombrio

Se Odin não existisse, a gente continuaria preso naquele meta em que PLM e GNN são colados com fita crepe conceitual. Os modelos do tipo GraphFormer ou Patton continuariam sendo o “estado da arte” meio conformado, com uma só camada de GNN tentando representar tudo que é multi-hop e sendo compartilhada por todas as camadas Transformer. É como usar uma mesma build de personagem para early, mid e late game e fingir que está tudo bem.

Sem a ideia de alinhar a posição das camadas de agregação estrutural com a profundidade semântica, o trade-off continuaria binário: ou você injeta pouca estrutura e fica raso, ou injeta estrutura demais e mata o gradiente com over-smoothing. Em TAGs grandes, isso significaria seguir empurrando a fronteira de pesquisa para longe de aplicações práticas, porque ou explode memória ou sacrifica performance. Light Odin, em particular, abre a porta para rodar TAGs text-rich em cenários mais pobres de recurso, e sem ele a narrativa “LLM + grafo só funciona para big tech” continuaria firme.

Em resumo, o universo sem Odin é um universo em que a gente continua discutindo se PLM vem antes do GNN ou vice-versa, enquanto ninguém pergunta se a hierarquia das camadas faz sentido. É literalmente ficar preso na discussão Batman vs Superman sem perceber que o problema é o roteiro.

---

Do grafo ao [CLS]: engenharia de runas no estilo Asgard

Odin é construído em cima de um TAG G = (V, E, X), onde cada nó tem texto associado, e o objetivo é aprender representações que misturem semântica textual com contexto multi-hop. Para isso, Hong et al pegam um Transformer tipo BERT ou SciBERT e o atravessam com camadas TG e TS. Em todas as camadas, o texto é codificado com autoatenção, mas só em algumas a estrutura é injetada com uma GNN estilo GraphSAGE; nas outras, só entra uma agregação simples para manter o grafo “respirando” ao longo da profundidade.

Mini-batch em estilo raid de WoW

Antes de tudo, entra o GraphSAGE minibatch para amostrar subgrafos A-hop ao redor do batch atual de nós. Isso evita ter que carregar o grafo inteiro na memória, algo que em OGBN-Products seria tão viável quanto rodar Crysis em um PS2. A ideia é caminhar de A até 1 hop, agregando vizinhos e formando um subgrafo razoavelmente denso mas ainda treinável. Essa estratégia mantém o comportamento indutivo do GraphSAGE de Hamilton et al, deixando Odin pronto para lidar com nós nunca vistos.

Camadas TG: cross-over entre GNN e Transformer

Nas camadas TG, o fluxo é: primeiro o texto passa pelo bloco Transformer normal, produzindo Tᶩᵥ. Depois, o [CLS] daquele nó vira o representante node-level, e a GNN agregadora computa um aggᶩᵥ com base na média dos vizinhos ponderada por pesos W₁ e W₂. Em seguida, esse vetor é concatenado de volta à sequência de tokens do nó e passado para a próxima camada. É tipo chamar um NPC de outro mundo para participar da sua campanha, deixar ele falar, e em seguida incorporar o que ele contou na narrativa do personagem principal.

Camadas TS: suporte estrutural low-cost

Nas camadas TS, não dá para encher de GNN em tudo porque cada camada dessas custa caro em vizinhos, memória e tempo. Então Hong et al definem quatro estratégias de SimpleAggregate: VA, que não faz nada; ME, que só tira a média dos [CLS] de vizinhos; PE, que reutiliza o agg da TG anterior; e PG, que reutiliza os próprios pesos da TG anterior. PG é particularmente interessante: reaproveita o módulo GNN sem criar novos parâmetros, fazendo espécie de “reutilização de runa” como em sistemas de magia minimalistas. O objetivo é manter a estrutura influenciando todo o stack, sem explodir o orçamento de GPU.

Text encoding como motor principal

A parte de texto segue o esquema clássico de Transformer, com atenção multi-cabeças assimétrica e MLP com residuais e LayerNorm. Cada camada recebe a sequência enriquecida com aggᶩᵥ concatenado, ou seja, o [CLS] e os demais tokens passam a interagir com um vetor que representa o contexto estrutural multi-hop do nó. É como se o token [CLS] carregasse um “buff de grafo” que vai sendo refinado à medida que passa pelas camadas. No fim, o [CLS] da última camada vira a representação do nó para classificação, link prediction, retrieval ou reranking.

Teorema anti-over-smoothing e poder de expressão

Hong et al formalizam que Odin evita oversmoothing porque nunca roda a típica operação de média iterativa das GNNs tradicionais diretamente sobre os estados internos. Em vez disso, sempre agrega sobre [CLS] do Transformer, cuja dinâmica não é contrativa e não converge para vetores idênticos. Em outro resultado, eles mostram que Odin contém estritamente o poder de expressão de Transformers puros e de GNNs de message passing. Se você configura sem TG, vira Transformer; se você mata o encoder de texto e usa TG em todas as camadas, emula GNN. Mas, no modo completo, consegue distinguir nós com texto igual e estrutura diferente, e nós com estrutura igual e texto diferente, coisa que nem um nem outro consegue sozinho.

---

Resultados em modo boss fight: Odin vs o resto do multiverso

O capítulo experimental de Hong et al é praticamente um torneio de arco final de anime, com Odin enfrentando PLMs puros, GNNs clássicos e modelos de fusão LM-GNN em quatro tarefas. Eles usam cinco datasets text-rich, incluindo Cora, CiteSeer, subgrafos de OGBN-ArXiv (3k, 6k, 10k nós), ArXiv2023 e OGBN-Products. Em todas as tasks, treinam com poucos exemplos por classe, o que transforma o problema em uma espécie de ranqueada em elo baixo com meta altamente punitivo.

Node classification: XP distribuído ao longo da árvore de talentos

Na tarefa de classificação com 8-shot por classe, Odin atinge acurácia na faixa de 0.72 em Cora e algo em torno de 0.70 em OGBN-Products, o que é nível “raid clear” comparado às bases. Patton, que já era forte, fica alguns pontos atrás em vários cenários, e SciBERT puro fica preso na casa dos 0.45–0.46 em vários datasets. Isso é como comparar um personagem com build híbrida bem pensada contra um mago full INT tentando tankar dano físico.

O Light Odin, mesmo com só 6 camadas, consegue subir bem acima de seu checkpoint original DistilBERT, que em alguns cenários fica com acurácia em torno de 0.08–0.20, praticamente jogando de suporte AFK. O ganho mostra que a injeção de estrutura mesmo em encoder raso muda o jogo. A mensagem aqui é estatisticamente clara: quando você mede diferença de 5–10 pontos percentuais em ACC, isso não é ruído, é mudança de regime, como sair de Ferro para Ouro no matchmaking.

Link prediction: acertando pares como se fosse shipper profissional

Na task de link prediction com 32-shot, a métrica é precisão de ranking (PRC). Em Cora, Odin chega a valores na casa de 0.78, enquanto baselines como PLM+GraphSAGE ficam perto de 0.72 e GNNs puros como GraphSAGE ou GraphSAGE++ caem até regiões de 0.16–0.21 em alguns cenários. Isso é quantidade de diferença que, em termos geek, parece a distância entre farmar item lendário e dropar só gear comum.

Em OGBN-Products, Odin passa de 0.94 de precisão, enquanto alguns modelos puros de texto ficam próximos de 0.55 e GNNs giram em torno de 0.15–0.20. Ou seja, quando a rede é grande e o texto é rico, só confiar na topologia é como tentar entender o MCU vendo apenas cenas pós-crédito. A combinação de [CLS] com multi-hop controlado permite que o modelo entenda que certos nós “devem” se conectar mesmo se o padrão estiver escondido em múltiplas hops com semântica complicada.

Retrieval: jogando DPR no modo hard

No cenário de retrieval, Hong et al usam pipeline tipo DPR, onde o [CLS] do nó e o [CLS] do rótulo são embeddings densos, e o modelo precisa acertar o label correto entre muitos. Em vários datasets, Odin bate Recall@10 acima de 0.90, chegando próximo de 0.93 em ArXiv2023. PLM+GraphSAGE mantém resultados fortes, mas normalmente 5–10 pontos abaixo. PLMs puros, como ModernBERT ou SciBERT, oscilam muito, às vezes ficando em torno de 0.35–0.75, dependendo do dataset.

Light Odin aqui sofre mais, com números por volta de 0.21–0.48 em alguns cenários, o que lembra time de heróis mid-tier enfrentando boss end-game sem build otimizada. Mas mesmo assim, ele geralmente supera DistilBERT, que ronda valores parecidos ou piores. O sinal estatístico é bem importante: tarefas de retrieval são hiper-sensíveis a representação de rótulo, e Odin está basicamente dizendo que estruturar o grafo como contexto para o rótulo também importa, não só para o nó.

Reranking: afinando o top-k como se fosse draft de time competitivo

No reranking, a ideia é pegar uma lista de candidatos gerada por BM25 e pedir para o modelo reordenar as classes. Aqui, Odin atinge PRC perto de 0.75 em vários subgrafos de OGBN-ArXiv, e algo por volta de 0.65 em ArXiv2023. Patton se mantém competitivo, mas geralmente abaixo em 1–3 pontos. PLM+GraphSAGE fica mais distante, na região de 0.55, o que mostra que concatenar embeddings sem alinhamento de camadas é tipo montar time de RPG só pela estética dos personagens.

Curiosamente, Light Odin às vezes brilha em cenários com lista de candidatos mais restrita, chegando a ultrapassar 0.76 em alguns settings. Isso sugere que, quando o espaço de decisão é mais concentrado, mesmo um encoder raso com estrutura bem injetada consegue fazer distinções finas, como jogador experiente que, mesmo com personagem fraco, compensa na leitura de jogo. Estatisticamente, ganhos consistentes de 0.05–0.10 em PRC nessa tarefa significam menos confusão entre classes semânticas próximas, algo essencial em domínios com taxonomias grandes.

Comparando paradigmas: Enhancer, Predictor e Aligner em arena

Os resultados deixam claro que as três famílias de métodos se comportam como classes diferentes em um MOBA. Os modelos LLM-as-Enhancer, tipo PLM+GraphSAGE, têm desempenho sólido mas dependem pesadamente da qualidade da inicialização textual; se o texto não for bem modelado, a parte de grafo não salva. Os LLM-as-Predictor estilo LLaGA têm potencial em classificação, mas são mais frágeis quando a tarefa exige controle fino de estrutura, já que tudo é reduzido a geração condicionada.

Odin se posiciona no LLM-as-Aligner, mas com uma arquitetura que resolve dois problemas que Jin et al já tinham apontado: mismatch de profundidade e injeção rígida de estrutura. Usando TG em camadas 1, 6 e 11 e estratégia PG nas TS, Hong et al mostram que distribuir estrutura em estágios importa mais do que bombardear o modelo com GNN em todas as camadas ou ampliar demais o hop. Isso fica evidente quando variantes com todos TG layers e 3-hop sampling estouram memória ou têm performance pior por over-injeção. É literalmente a diferença entre buff bem colocado e spammar skill até ficar sem mana.

Eficiência: GPUs salvas do sacrifício

No quesito tempo de pré-treino, o Odin full leva algo em torno de 1h12–1h15 em ArXiv2023, enquanto Patton e PLM+GraphSAGE passam de 1h38–1h41. Já o Light Odin derruba isso para 25–40 minutos, dependendo de quantos TG layers são usados. O monstro Odin-ALL com 3-hop nem termina o treino por causa de OOM, o que serve de lembrete prático de que “mais GNN em toda camada” não é caminho sustentável. Esses números funcionam como benchmarks de custo: se você troca 60% de parâmetros e boa parte do tempo de inferência por uma queda moderada de performance, isso é exatamente o tipo de trade-off que importa para aplicações reais.

---

Hype de IA, grafos e Transformers: saiu patch, mas o meta continua tóxico

Odin joga luz em um ponto incômodo: boa parte da hype de “Graph + LLM” até agora era meio cosmética. Era pegar um Transformer, grudar um GNN na frente ou atrás e dizer que agora temos “razão estruturada guiada por linguagem”, como se colar dois quadrinhos da Marvel criasse automaticamente um universo compartilhado. Hong et al mostram que, sem alinhar a profundidade semântica com a profundidade estrutural, você só está empilhando módulos, não criando uma arquitetura coerente.

Também fica claro que benchmarks em TAGs são facilmente enganados por modelos que só acertam o grosso das distribuições. Quando você vê melhorias pequenas mas consistentes em tasks difíceis como reranking e retrieval, percebe que o jogo real não é bater um novo SOTA em um dataset estático, e sim mostrar que a arquitetura resolve limitações estruturais de design. Pensar que só escalar o tamanho do LLM vai magicamente resolver multi-hop em grafos é como achar que aumentar o nível do personagem compensa uma árvore de talentos construída errado.

---

Próximas quests: para além de Odin, sem cair no culto ao martelo mágico

Odin não é o martelo definitivo, mas é um belíssimo tapa na cara da comunidade para parar de tratar grafo e texto como dois reinos separados que só cruzam em crossover de evento. Ainda falta explorar, por exemplo, como esse alinhamento de camadas se comporta em grafos dinâmicos, com nós e arestas surgindo como em partidas rankeadas em tempo real. Também falta investigar versões que troquem GraphSAGE por outros operadores mais expressivos, sem sacrificar o anti-over-smoothing que Hong et al conquistam.

Outra frente óbvia é trazer essa lógica para LLMs maiores, mas com disciplina. Não faz sentido treinar um monstro de bilhões de parâmetros em TAG se você não tiver garantias de que a estrutura está realmente condicionando a semântica em múltiplas profundidades, em vez de só virar ruído. Pensar em regularização explícita entre níveis de abstração estrutural e semântica seria como desenhar uma árvore de talentos com sinergias obrigatórias entre ramos, evitando builds “meme” que só brilham em benchmark de Twitter.

Se você é jovem pesquisador, a move certa agora não é só copiar Odin e trocar o nome, mas entender onde ele acerta: alinhamento camada-a-camada, agregação sobre [CLS] para evitar over-smoothing, uso de variantes leves como Light Odin para testar ideias sem queimar GPU como se fosse pergaminho descartável.

Leia o paper completo com calma, anote como eles montam os experimentos, como definem as variantes de agregação e como conectam teoria de expressividade com resultados práticos. É ali que estão as runas que você pode reutilizar para criar a sua própria arma lendária no próximo projeto.