Memória Estrutural Persistente para IA: A Arquitetura por Trás do Infigraph

No meu artigo anterior, escrevi sobre o que chamei de Cegueira de Código – o custo operacional oculto de forçar assistentes de IA a redescobrir repetidamente a estrutura e as relações arquitetônicas que já existem dentro de nossas bases de código.

Os assistentes de codificação de hoje podem inspecionar arquivos locais, rastrear importações explícitas e juntar cuidadosamente as relações para responder a perguntas de engenharia familiares:

– Quem chama esta função?

– O que quebra se eu alterar esta rota de API?

– Quais serviços dependem deste componente?

– Qual é o verdadeiro raio de impacto desta mudança?

Essas não são perguntas difíceis porque o código é difícil de ler. Elas são difíceis porque as relações que as respondem não estão explicitamente disponíveis. Cada nova sessão de IA as reconstrói a partir do código-fonte, apenas para descartar esse entendimento quando a conversa termina.

Essa observação eventualmente nos levou a construir Infigraph – uma tentativa de transformar a estrutura de software em uma infraestrutura local reutilizável.

Quando recentemente abrimos o projeto como código aberto, uma pergunta surgiu repetidamente:

“O que torna o Infigraph diferente dos outros projetos de inteligência de código e gráficos de código que já existem por aí?”

É uma pergunta justa.

O ecossistema já possui ferramentas para busca de código, análise estática, visualização de arquitetura e desenvolvimento assistido por IA. Algumas se concentram em ajudar engenheiros a navegar pelo código. Outras geram gráficos de conhecimento para LLMs, visualizam arquitetura ou constroem pipelines de recuperação mais ricos.

Não estávamos tentando construir mais uma ferramenta de inteligência de código.

Estávamos tentando construir uma camada de memória estrutural persistente e local que assistentes de IA pudessem consultar diretamente em vez de reconstruir repetidamente as relações de software a partir do código-fonte.

Esse objetivo influenciou quase todas as decisões arquitetônicas que tomamos – desde como o código é analisado, até como as relações são extraídas e armazenadas, até como os agentes de IA recuperam informações.

Olhando para trás, essas decisões não foram otimizações independentes. Elas foram consequências de um único princípio de design:

Se a estrutura do software muda muito mais lentamente do que as conversas de IA, então o conhecimento estrutural deve ser tratado como infraestrutura e não como algo reconstruído do zero para cada prompt.

Este artigo percorre as decisões de engenharia que seguiram desse princípio, os trade-offs que aceitamos e as lições que aprendemos ao construir o Infigraph.

O Blueprint do Sistema

Antes de discutir as decisões arquitetônicas individuais, vale a pena entender como as peças se encaixam. Em um nível alto, o Infigraph transforma continuamente uma base de código em uma representação estrutural persistente que assistentes de IA podem consultar diretamente. Em vez de redescobrir relações para cada conversa, essas relações se tornam infraestrutura compartilhada.

O gráfico não substitui o modelo de linguagem. Ele muda a pergunta que o modelo de linguagem precisa responder. Em vez de tratar cada prompt como um exercício de raciocínio isolado, o Infigraph trata a compreensão estrutural como infraestrutura persistente.

A observação importante não são as tecnologias individuais. É onde o esforço computacional se desloca.

Fluxos de trabalho de IA tradicionais gastam a maior parte de seu esforço reconstruindo a arquitetura a partir do código-fonte toda vez que uma pergunta é feita. O Infigraph move esse trabalho para o tempo de indexação. Analisar o código-fonte, resolver símbolos, entender importações e descobrir relações acontece uma vez – quando o repositório é indexado. Cada pergunta subsequente se torna um problema de recuperação em vez de um problema de reconstrução.

Essa mudança arquitetônica imediatamente impôs um novo conjunto de requisitos de engenharia. Precisávamos:

• Um motor de armazenamento otimizado para travessia de relações em vez de recuperação de documentos
• Uma camada de recuperação que pudesse combinar consultas de gráfico com busca tradicional
• Uma arquitetura de análise capaz de entender bases de código poliglotas modernas sem se tornar específica de linguagem

As próximas três seções explicam como esses requisitos moldaram a arquitetura do Infigraph.

Decisão #1: Representar Código como um Gráfico Persistente

A primeira decisão arquitetônica foi decidir como o software em si deveria ser representado.

Um sistema de software não é apenas uma coleção de arquivos fonte. É uma rede de relações explícitas. Uma chamada de função é uma relação explícita. Uma declaração de importação expressa uma dependência. Uma hierarquia de classes define herança. Limites de módulo já existem, quer um modelo de IA os descubra ou não. Precisávamos de uma representação descobrível estaticamente onde as relações fossem cidadãos de primeira classe.

Isso nos levou naturalmente a um gráfico.

Em vez de armazenar arquivos fonte como texto isolado, o Infigraph persiste uma topologia conectada de entidades de software e as relações entre elas.

Uma vez que as relações se tornam explícitas, perguntas arquitetônicas deixam de ser problemas de busca de texto. Perguntas de engenharia familiares se tornam uma travessia de gráfico. O sistema não está lendo código-fonte bruto dentro de um loop de raciocínio de LLM para encontrar chamadores. Ele está atravessando um índice que já sabe que eles existem.

Uma vez que nos comprometemos a representar o software como um gráfico, a próxima pergunta se tornou muito mais prática:

Que tipo de motor de gráfico poderia suportar fluxos de trabalho interativos de IA sem se tornar outra dependência do lado do servidor?

Essa pergunta moldou nossa próxima decisão arquitetônica.

Decisão #2: Persistir Memória Estrutural Localmente

Poderíamos ter armazenado o gráfico em um banco de dados tradicional cliente-servidor. Poderíamos ter confiado em um serviço de gráfico gerenciado. Ou poderíamos ter gerado contexto estrutural sob demanda através de pipelines de recuperação hospedados na nuvem.

Todas essas abordagens funcionam.

Mas elas entraram em conflito com uma de nossas restrições arquitetônicas desde o início:

O conhecimento estrutural deve viver ao lado