EXTRACTED ou INFERRED no graphify: como saber em quais ligações do grafo confiar?

diagrama mostrando EXTRACTED e INFERRED no graphify e a aresta AMBIGUOUS entre elas
Resposta rápida

No graphify toda aresta do grafo carrega uma marca de proveniência, e são três: EXTRACTED, INFERRED ou AMBIGUOUS. EXTRACTED significa que veio direto da AST, o parser encontrou a ligação. INFERRED significa que um modelo ligou os pontos, algo que a documentação descreve como ‘geralmente certo’ e rotula como julgamento, não como fato lido no código. AMBIGUOUS é evidência que o graphify não conseguiu resolver por completo. Entender EXTRACTED e INFERRED no graphify é o que evita tratar dedução como fato: EXTRACTED sustenta decisão, INFERRED sustenta hipótese, AMBIGUOUS pede conferir o arquivo:linha

Fala aí, beleza? Tem uma diferença que muda tudo na hora de ler um grafo de código: uma coisa é o parser ter LIDO aquela ligação no arquivo, outra bem diferente é um modelo ter deduzido que ela existe

As duas aparecem no mesmo desenho, com a mesma setinha bonita

E aí você olha, acredita, apaga uma função e descobre da pior forma que aquilo era um palpite e não um fato 😅

O graphify resolve isso de um jeito simples: toda aresta do grafo carrega uma marca de proveniência, e são três possíveis, EXTRACTED, INFERRED e AMBIGUOUS

Cada ligação te conta de onde ela veio antes de você decidir qualquer coisa

Formação Claude Code
Formação Recomendada

Formação Claude Code

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

  • 116 aulas
  • 4 projetos
  • 9h 23min

EXTRACTED, INFERRED e AMBIGUOUS lado a lado

Antes de sair rodando comando, vale fixar o que cada rótulo quer dizer na definição oficial:

Rótulo O que significa De onde vem a evidência Peso na leitura
EXTRACTED Veio direto da AST: o parser encontrou a ligação Parsing determinístico do código É fato parseado, o rótulo mais forte dos três
INFERRED Um modelo ligou os pontos, descrito na documentação como "geralmente certo" Passagem semântica rodada por modelo É julgamento, não fato lido no código
AMBIGUOUS O graphify viu evidência que não conseguiu resolver por completo Dispatch dinâmico, reflexão, imports montados por string É aviso de incerteza, pede olho humano

Repara no detalhe mais honesto da tabela: o AMBIGUOUS existe justamente pra ferramenta marcar incerteza em vez de chutar em silêncio

Isso é raro, viu

A maioria das ferramentas prefere entregar uma resposta lisa e deixar você descobrir sozinho onde ela inventou 🙂

Por que o graphify marca cada aresta em vez de entregar um grafo só

O propósito declarado da proveniência é permitir distinguir fato parseado de julgamento quando o assistente responde percorrendo o grafo

E aqui tá a sacada: toda resposta é um CAMINHO

O assistente sai de um nó, pula pra outro, pula de novo, e monta a explicação em cima desses hops

Se um hop no meio do caminho for um palpite, a resposta inteira herda o palpite sem avisar

Com o rótulo, cada hop da resposta mostra se é fato parseado ou inferência

E de onde vem cada camada?

O grafo estrutural é trabalho puro de AST, roda local e não exige chave de API

Já as passagens semânticas mais ricas (nomear comunidades, modo deep) rodam pela sessão do assistente ou por um backend de modelo configurado

E são exatamente essas que geram as arestas inferidas

Ou seja: o rótulo não é enfeite, ele espelha qual camada produziu aquela ligação

Se você conhece a diferença entre um lint que lê o código e um review que interpreta intenção, é bem esse o espírito

O mapeamento, aliás, cobre 36 linguagens de código, mais docs, SQL e outros formatos

Como ver o rótulo de cada ligação na prática

Bora ver na prática? O caminho é curto

  1. Instale a CLI a partir do PyPI
uv tool install graphifyy
# ou
pipx install graphifyy
# ou
pip install graphifyy

O erro comum deste passo: o pacote no PyPI chama graphifyy, com dois "y", mas o comando instalado chama graphify

Quem digita pip install graphify já começa quebrando 😛

  1. Registre a skill no assistente
graphify install

Sem argumento, o alvo padrão do graphify install é o Claude Code

  1. Construa o grafo DENTRO do assistente
/graphify .

O erro comum deste passo: tentar construir o grafo pelo terminal

A build acontece dentro do assistente, e o projeto é mapeado para a pasta graphify-out/

De lá saem três arquivos: graphify-out/graph.html (o grafo interativo), graphify-out/GRAPH_REPORT.md (relatório de arquitetura) e graphify-out/graph.json (o grafo legível por máquina, que é o que os comandos da CLI leem)

  1. Pergunte e leia os rótulos
graphify query "<pergunta>" [--dfs] [--context <c>] [--budget <n>] [--graph <path>]

O graphify query percorre o grafo a partir dos nós que mais casam com a pergunta e imprime o subgrafo como texto

Com caminhos explícitos, citações no formato arquivo:linha e cada aresta marcada como EXTRACTED, INFERRED ou AMBIGUOUS

É aqui que a leitura crítica acontece de verdade

  1. Ajuste a saída com os flags que importam

O --budget limita a saída em n tokens, com padrão de 2000 tokens

O --mode deep ativa uma análise multi-passo mais profunda, mais lenta e com MAIS conexões inferidas (então sim, tende a aumentar a proporção de coisa rotulada como julgamento)

E o --update re-escaneia apenas o que mudou desde a última execução, em vez de reconstruir do zero

Quando confiar na aresta e quando ir conferir o arquivo:linha

O rótulo só vale se você mudar de comportamento conforme ele muda

Se liga nos três cenários mais comuns:

Refatorar e apagar código:

Aqui o peso mora no EXTRACTED

É a ligação que o parser encontrou na AST, é fato parseado

Se o caminho até aquela função só passa por arestas inferidas, tu não tem prova de uso, tu tem uma boa suspeita

E apagar código com base em suspeita é receita pros rm -rf da vida 😅

Entender intenção e agrupamento de módulos:

Aqui o INFERRED brilha, mesmo sendo julgamento

Nomear comunidades, entender que um punhado de arquivos forma um subsistema, sacar a divisão de responsabilidade: nada disso tá escrito na AST

A documentação descreve o INFERRED como "geralmente certo", e pra ganhar mapa mental rápido isso é MUITO útil

Só não vira decisão de deleção

Código com dispatch dinâmico, reflexão ou import montado por string:

Esse é o território do AMBIGUOUS

Quando ele aparece, o recado é claro: a ferramenta viu evidência e não conseguiu resolver por completo

Abre a citação arquivo:linha e confere com o olho humano, sem preguiça

E se eu quiser isso dentro do assistente?

Tem servidor MCP também

O servidor MCP do graphify expõe 10 ferramentas sobre o grafo, com profundidade de travessia de 1 a 6, e devolve o MESMO formato de saída do graphify query

Ou seja: citações arquivo:linha e cada aresta marcada

O rótulo te acompanha, não some no caminho

Em quais ligações do grafo confiar, afinal

Veredito honesto: o rótulo não é nota de confiança absoluta, é ORIGEM da evidência

EXTRACTED não quer dizer "100% certo pra sempre", quer dizer "isso o parser leu no código"

INFERRED não quer dizer "errado", quer dizer "um modelo ligou os pontos"

A régua de leitura que dá pra usar sem inventar número nenhum é essa:

  • EXTRACTED: sustenta decisão sozinho
  • INFERRED: sustenta hipótese, e hipótese boa vira pergunta, não vira commit
  • AMBIGUOUS: pede verificação humana no arquivo apontado

Não tem porcentagem publicada de quanto do grafo costuma cair em cada rótulo, então qualquer número que te venderem por aí é achismo

O valor tá em ler hop a hop, não em confiar num placar

E se você tá no começo da carreira e fica na dúvida sobre a hora de dar o próximo passo profissional, tem esse vídeo aqui do canal:

Conclusão

Resumo em uma frase: no graphify, EXTRACTED é o que o parser leu na AST, INFERRED é o que um modelo deduziu e AMBIGUOUS é o que a ferramenta assumiu que não conseguiu resolver, e confundir os três é o jeito mais rápido de tratar dedução como fato

O próximo passo é bem concreto: roda /graphify . no teu projeto, abre uma pergunta com graphify query e lê os rótulos hop a hop ANTES de mexer em qualquer coisa

O projeto vive no repositório Graphify-Labs/graphify e chega como skill /graphify pro Claude Code, Cursor, Codex e Gemini CLI, com parsing AST local determinístico e sem banco vetorial

Testa e me conta o que apareceu de AMBIGUOUS no teu código, aposto que tem surpresa ali 😀

até o próximo post!

Perguntas frequentes

O graphify precisa de chave de API pra marcar uma aresta como EXTRACTED?

Não. O grafo estrutural é trabalho puro de AST, roda local e não exige chave de API. As arestas EXTRACTED vêm exatamente dessa camada, é o parser encontrando a ligação direto no código.

Qual a diferença prática entre AMBIGUOUS e INFERRED no graphify?

INFERRED é um modelo ligando os pontos, algo que a documentação chama de ‘geralmente certo’, mas ainda é julgamento. AMBIGUOUS é diferente: é quando o graphify viu evidência (dispatch dinâmico, reflexão, import montado por string) e não conseguiu resolver por completo, então marcou como incerto em vez de chutar em silêncio.

Usar –mode deep no graphify query aumenta a proporção de arestas INFERRED?

Sim. O –mode deep ativa uma análise multi-passo mais profunda, mais lenta e com mais conexões inferidas. Então uma consulta com esse flag tende a trazer mais rótulos de julgamento no caminho.

Onde ficam os arquivos depois de rodar /graphify . no assistente?

Tudo vai pra pasta graphify-out/: o graph.html é o grafo interativo, o GRAPH_REPORT.md é o relatório de arquitetura e o graph.json é o grafo legível por máquina, que é o arquivo que os comandos da CLI leem.

O graphify funciona só no Claude Code ou dá pra usar em outro assistente?

O graphify se apresenta como skill /graphify pra Claude Code, Cursor, Codex e Gemini CLI, com parsing AST local determinístico e sem vector store. Vale lembrar que o graphify install, sem argumento, tem o Claude Code como alvo padrão.

Dá pra ler os rótulos EXTRACTED e INFERRED sem usar a CLI, direto no assistente?

Dá, pelo servidor MCP do graphify. Ele expõe 10 ferramentas sobre o grafo, com profundidade de travessia de 1 a 6, e devolve o mesmo formato de saída do graphify query, com citações arquivo:linha e cada aresta marcada.




Escrito por | Matheus Battisti

Matheus Battisti
Fundador da Hora de Codar

Programador apaixonado pelo mundo das tecnologias, sempre buscando em aprender e se aprofundar em linguagens, frameworks e o que mais for necessário para executar um bom trabalho. Agora tem uma nova missão que é de passar seu conhecimento adiante para formar novos programadores e especializar mais os que já são.

Subscribe
Notify of
guest

0 Comentários
Oldest
Newest Most Voted

Formações

Formação Vibe Coding

Formação Vibe Coding

Do Prompt ao Produto: Crie Software Real com IA

  • 474 aulas
  • 20 projetos
  • 39h 27min

Blog | Mais populares