Graphify multimodal: como docs, PDFs, imagens e vídeo entram no mesmo grafo do código

Fala aí, beleza? O teu assistente lê o repositório inteiro e mesmo assim não sabe POR QUE aquele módulo existe do jeito que existe

E o motivo é simples: o racional do projeto quase nunca mora no código

Ele mora num PDF que alguém do time leu, num diagrama exportado em PNG, numa gravação de call que ficou parada numa pasta, num ADR em Markdown que ninguém abre desde o ano passado

O Graphify é uma skill que ataca justamente esse buraco: ele pega uma pasta com código, docs, schemas SQL, configs e PDFs e transforma tudo num grafo de conhecimento consultável, sem vector store, com cada aresta explicada

A skill /graphify funciona no Claude Code, Cursor, Codex e Gemini CLI, e o parsing de código roda em AST local e determinístico

Bora entender como esse material que normalmente fica fora do alcance do assistente entra no MESMO grafo do teu código 🙂

De onde veio o Graphify e quem mantém

A história começa num post do Andrej Karpathy em 01/04/2026, falando sobre usar LLMs como "compiladores de conhecimento" pra montar bases estruturadas

Cerca de 48 horas depois o Graphify apareceu no GitHub

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Só que atenção nesse ponto, porque muita gente confunde: o Karpathy NÃO é autor nem mantenedor do projeto

Quem escreveu foi Safi Shamsi, fundador da Graphify Labs, empresa do batch S26 da Y Combinator

O projeto é escrito em Python e distribuído sob licença MIT, open source

O repositório canônico do Graphify hoje fica na organização Graphify-Labs, e não mais na conta pessoal do autor (a URL antiga safishamsi/graphify redireciona pra lá)

A branch de desenvolvimento mais recente é a v8

E tem um detalhe massa pra quem lê em português: o repositório mantém traduções do README, incluindo docs/translations/README.pt-BR.md

Os três passes: o que cada tipo de arquivo recebe

Aqui mora a sacada do projeto

Ele não joga tudo no mesmo moedor: cada tipo de material passa por um caminho diferente, e só depois os resultados se encontram

O passe 1 é o mais previsível de todos: tree-sitter monta a árvore sintática, sem LLM no meio, então o mesmo código gera a mesma extração

O passe 2 transcreve vídeo e áudio localmente com faster-whisper, usando um prompt de domínio derivado dos god nodes do corpus

Que god nodes? São os nós mais conectados do teu material, os conceitos que aparecem em todo canto

A transcrição usa esse vocabulário pra não errar os termos técnicos do teu projeto, e ainda guarda cache das transcrições

E aqui vai um aviso de honestidade: a numeração dos passes é um jeito de organizar o que cada material recebe, não uma promessa de fila indiana. A documentação diz que o passe 2 usa esses god nodes, mas não detalha em que momento eles são calculados, então não vou chutar a ordem pra você

O passe 3 é onde entram subagentes em paralelo lendo docs, papers, imagens e as transcrições, extraindo conceitos, relações e racional de design

Os resultados dos três passes são unificados num grafo NetworkX, agrupados por detecção de comunidades Leiden, e exportados em três formatos: graph.html (interativo), graph.json (consultável) e GRAPH_REPORT.md (relatório em linguagem simples)

E a lista de formatos ingeridos é bem mais larga que só código e PDF: schemas SQL com introspecção PostgreSQL, configs de workspace Cargo, HCL do Terraform, Markdown e MDX, reStructuredText, HTML, YAML, .docx, .xlsx, PNG, JPEG, MP4, MP3, além de scripts R e shell

O que sai da sua máquina (e o que não sai)

Essa é a pergunta que aparece na hora que você pensa em jogar PDF interno e gravação de reunião num grafo

E a resposta muda por passe, então vale separar direitinho

Código fica local: tree-sitter roda offline, sem LLM, e nada sai da máquina

Inclusive, um corpus só de código roda sem API key nenhuma

O arquivo de vídeo e o de áudio também não saem: a transcrição com faster-whisper acontece localmente

Só que se liga nesse detalhe, porque é fácil ler errado: o ARQUIVO fica, mas o TEXTO da transcrição vira material do passe 3, junto com docs e imagens

Ou seja, a transcrição pode sim seguir pra um LLM depois de gerada, seja o modelo da sessão do assistente, seja um backend configurado por API key

Agora o outro lado da moeda: docs, PDFs e imagens vão pro modelo da sessão do assistente (via skill /graphify) ou pra uma API key configurada, porque o passe semântico precisa de um LLM lendo aquilo

A parte boa é que esse passe aceita vários backends, cada um com sua variável de ambiente:

• ANTHROPIC_API_KEY (Claude)
• OPENAI_API_KEY (OpenAI)
• GEMINI_API_KEY ou GOOGLE_API_KEY (Gemini)
• DEEPSEEK_API_KEY (DeepSeek)
• MOONSHOT_API_KEY (Kimi)
• AWS Bedrock
• Ollama rodando na sua máquina

Repara na última linha: com uma instância Ollama rodando, o passe semântico fica totalmente local, e isso vale também pro texto das transcrições que entra nesse passe

Pra quem trabalha com material interno que não pode circular, esse é o caminho

Quando documentação e mídia carregam contexto que o código não tem

Beleza, mas em que situação isso muda a resposta do assistente de verdade?

São os casos em que o "porquê" nunca esteve no arquivo .py

• Paper em PDF que explica a arquitetura. A decisão está implementada em duas funções discretas, e o motivo está numa seção do artigo. Com os dois no mesmo grafo, a aresta liga o conceito à implementação em vez de você explicar tudo de novo no prompt
• ADR e RFC em Markdown. O commit guarda o "o quê", o documento guarda o "por que não fizemos do outro jeito". Esse tipo de leitura de documentação é o mesmo terreno que o NotebookLM cobre pra programadores, com a diferença de que aqui o doc entra colado no grafo do código
• Planilha .xlsx e schema SQL. A introspecção do PostgreSQL traz a estrutura real das tabelas, e a planilha costuma ser onde alguém mapeou coluna com regra de negócio
• Diagrama em PNG ou JPEG. A extração por visão lê a imagem e ela vira nó ligado ao módulo correspondente, em vez de ficar morta numa pasta assets
• Gravação de call ou aula em MP4 e MP3. Vira transcrição local e a transcrição vira contexto ligado ao trecho de código que foi discutido ali
• Terraform em HCL e configs. É o que conecta infraestrutura ao serviço, aquele pedaço que o assistente costuma ignorar porque não é "código de aplicação"

O padrão é sempre o mesmo: o assistente para de responder só pelo que está escrito nas funções e passa a responder pelo que o time realmente decidiu

A onda multimodal, pra quem quer contexto

Pra começar do zero no assunto de multimodalidade, este vídeo do canal mostra o movimento das big techs em imagens, vídeos e 3D:

E se o teu lado da multimodalidade é PRODUZIR mídia em vez de indexar, tem por aqui um passo a passo de como criar vídeos a partir de imagens

Como montar um grafo multimodal na prática

Sequência enxuta, só com o que está documentado no projeto:

1. Instale o pacote. Dá pra usar uv, pipx ou pip:

uv tool install graphifyy
# ou
pipx install graphifyy
# ou
pip install graphifyy

O erro comum aqui é o nome: o pacote no PyPI é graphifyy, com dois "y"

Se você digitar graphify na instalação, não é o pacote certo

2. Registre a skill no assistente. Depois de instalar o pacote, o comando disponível é graphify (com um "y" só):

graphify install

Sem argumento, o alvo padrão é o Claude Code

O erro comum deste passo é justamente a troca entre graphifyy (pacote) e graphify (comando). Instala com dois, roda com um 🙂

3. Aponte a skill pra pasta. Dentro do assistente:

/graphify .

Isso constrói o grafo da pasta atual

O erro comum: esperar que TUDO rode offline. Só código roda sem API key. No momento que você inclui docs, PDFs e imagens, o passe semântico entra e precisa de um modelo (o da sessão ou um backend configurado)

4. Atualize de forma incremental. Não precisa reconstruir tudo a cada mudança:

/graphify ./docs --update

Com --update, apenas os arquivos que mudaram são re-extraídos

O erro comum: rodar do zero por hábito e pagar de novo o passe semântico de um material que continua igual

5. Abra as saídas. No fim você tem graph.html pra navegar visualmente, graph.json pra consultar de forma programática e GRAPH_REPORT.md pra ler em linguagem simples

O GRAPH_REPORT.md costuma ser o melhor lugar pra checar se as arestas fazem sentido antes de confiar no grafo

O ganho de tokens é real, mas o número de manchete tem contexto

Aqui é onde eu peço calma com o hype

O número que circula é 71,5x menos tokens por consulta

Só que esse resultado vem de um corpus específico e MISTO: 52 arquivos, sendo os repositórios nanoGPT, minGPT e micrograd + 5 PDFs do arXiv + 4 imagens

Já um benchmark independente sobre uma base Python real registrou 7,3x menos tokens

Os dois números podem ser verdade ao mesmo tempo, e a leitura honesta é essa: o salto grande aparece justamente quando o corpus é multimodal

Faz sentido, né? É exatamente o material que o assistente teria que ler inteiro, em texto bruto, toda vez

Em código puro, a economia continua existindo, mas em outra escala

Então: se o teu contexto é um repositório e mais nada, o ganho é bem menor que a manchete promete

Se o teu contexto tem paper, doc de arquitetura, diagrama e gravação espalhados, é aí que o graphify multimodal compensa de verdade

Conclusão

A ideia central é uma só: material que normalmente fica fora do alcance do assistente (PDF, planilha, diagrama, gravação) entrando no mesmo grafo do código, com cada aresta explicada e sem vector store no meio

O próximo passo concreto é pequeno e barato de testar

Monte um corpus mínimo misturando o teu repositório com a pasta de docs e um PDF de referência

Rode a skill, abra o GRAPH_REPORT.md e confira se as arestas explicam o racional que faltava

Se explicarem, você acabou de dar ao assistente o contexto que o código sozinho nunca teve

Quem quiser ir mais fundo, o repositório na organização Graphify-Labs tem a documentação do funcionamento na branch v8, e o README em português está em docs/translations/README.pt-BR.md

até o próximo post! 😀