GraphRAG versus vector search é a briga errada. A ApolloSpace AI roda os dois, em sequência.

Um operations agent recebe uma pergunta two-hop numa terça-feira: qual fornecedor causou o atraso na renovação do Q2, e se aquela decisão chegou a ser revertida. O vector index devolve três chunks que mencionam o fornecedor, a renovação, e uma reversão, cada um com um score de similaridade saudável, nenhum conectado ao outro. O agent costura seu melhor palpite e inverte a reversão.

Essa é a cara da briga que todo mundo está tendo agora: GraphRAG vs vector RAG, discutida como se um lado tivesse que vencer. Não vai vencer, porque os dois são bons exatamente naquilo em que o outro é ruim.

A resposta de produção para memória de agent é um substrato híbrido onde vetores encontram candidatos rápido e o graph faz o raciocínio multi-hop e mantém a proveniência, não um ou outro sozinho.

Este post defende esse híbrido como o único substrato que sobrevive ao contato com um agent ao vivo: por que retrieval vector-only bagunça a reversão na cena de abertura, por que um graph construído uma vez e percorrido por inteiro é lento e desatualizado demais para confiar a cada turno, e como a própria memória de agents da ApolloSpace AI roda o pipeline que devolve uma resposta correta e citada em poucas centenas de milissegundos sem esperar por um rebuild.

A briga ingênua: GraphRAG vs vector RAG

O enquadramento ingênuo tem dois lados, e os dois têm um ponto real. O lado do vector diz que embeddings escalam: barato para computar, barato para fazer query, já rodando por baixo de todo sistema retrieval-augmented em produção. O lado do graph diz que relações importam, que uma pilha de chunks parecidos entre si não é a mesma coisa que saber qual fato causou qual, e que os demos do lado do vector silenciosamente pulam toda pergunta que precisa de mais de um hop.

Aqui está por que escolher um lado falha. Retrieval vector-only não tem noção de relação, só de distância, então não consegue encadear “o fornecedor atrasou a renovação” com “a decisão do atraso foi revertida” a menos que os dois fatos fiquem perto da mesma query no embedding space. GraphRAG estático, o termo e a arquitetura da pesquisa de 2024 da Microsoft sobre retrieval com community summaries, resolve o problema do raciocínio construindo um graph inteiro antecipadamente e percorrendo community summaries para responder perguntas globais. Isso funciona, mas é construído uma vez, percorrido por inteiro toda vez, e fica desatualizado no momento em que chega um fato novo que o graph ainda não reconciliou.

Nenhuma das duas falhas é um bug que se conserta com patch. São dois trabalhos diferentes, e a resposta para a qual 2026 está convergindo é parar de pedir para um sistema só fazer os dois.

Por que retrieval vector-only bagunça uma pergunta multi-hop

O pitch ingênuo aqui é simples: embeda tudo, chat logs, tickets, documentos, decisões, e deixe a similaridade de cosseno fazer o resto. Se o fato está no store, uma query perto o suficiente traz ele à tona.

Vale a pena ser preciso sobre o mecanismo que quebra isso. Um vetor codifica o quão semanticamente perto dois pedaços de texto estão, nada mais. “O fornecedor perdeu o prazo de março” e “a decisão da renovação foi revertida em abril” podem ambos pontuar alto contra uma query sobre a renovação sem o store nunca representar que um causou o outro, ou que o segundo evento supersedes o primeiro. Similaridade não tem opinião sobre causação, sequência, ou qual fato vale atualmente. Isso é um primo próximo da falha que RAG não é memória já descreveu, retrieval encontrando um documento em vez de memória guardando uma conclusão, mas uma camada mais abaixo: mesmo um memory store que reconcilia fatos corretamente ainda não consegue encadear dois fatos relacionados na hora da query se tudo que você roda contra ele é busca por similaridade pura.

A lacuna não é teórica. Um benchmark independente comparando uma context layer estruturada em graph contra retrieval vector-only no mesmo conjunto de perguntas encontrou 80.0% de acurácia em multi-hop join queries para a abordagem baseada em graph contra 20.0% para vector search, uma lacuna de quatro para um exatamente no tipo de pergunta que a cena de abertura descreve (towardsdatascience.com, “Vector RAG Isn’t Enough”). Vale a pena citar precisamente porque isola a única coisa que similaridade vetorial estruturalmente não consegue fazer: raciocinar através de uma relação explícita em vez de adivinhar por proximidade.

Um vector store responde “o que é similar a isto”. Uma pergunta multi-hop pergunta “o que decorre daquilo”, e similaridade nunca foi construída para responder isso.

Por que um graph estático sozinho não consegue acompanhar um agent ao vivo

Se vector search não consegue encadear fatos, o conserto ingênuo parece óbvio: construir o knowledge graph inteiro antecipadamente, indexar cada relação a fundo, e percorrer ele na hora da query. Agora o raciocínio funciona.

E funciona, até você olhar para o que “construir antecipadamente” custa na próxima atualização. GraphRAG estático responde perguntas globais, em nível de corpus, percorrendo community summaries computados na hora do index, precisamente por isso o raciocínio está certo e precisamente por isso é pesado. Reconciliar um graph contra fatos novos é uma operação diferente e mais difícil do que dar append numa linha de um vector index, então a maioria dos deployments estáticos faz rebuild em lote em vez de atualizar ao vivo, autoritativo no dia do build e cada vez mais atrasado a cada dia depois. Um graph correto no dia do build e errado uma semana depois é a mesma forma de falha que memória com um relógio descreve no nível de um único fato: correção que decai é um bug diferente de correção nunca recuperada, e igualmente danoso para um agent ao vivo.

O custo de velocidade de pular retrieval estruturado por completo é concreto, não é conversa fiada. O próprio benchmark da Zep mediu uma baseline ingênua, enfiando o histórico de conversa inteiro na context window a cada turno em vez de reduzir primeiro, em 28.9 segundos de latência mediana por query contra o gpt-4o, comparado a 2.58 segundos para o caminho híbrido de retrieval estruturado deles, um corte de aproximadamente 91% (arXiv 2501.13956, Table 2). Um sistema que não consegue reduzir antes de raciocinar paga por isso em dezenas de segundos. GraphRAG estático paga uma versão mais estreita e mais dura do mesmo custo uma vez na hora do build em vez de por query, e depois roda desatualizado entre rebuilds, uma falha pior porque ninguém vê até a resposta já estar errada.

Um graph que está certo no dia em que é construído e errado em todo dia depois não é um reasoning engine. É um snapshot fingindo ser memória.

Construir o graph inteiro e percorrer ele por completo resolve o problema do raciocínio e reintroduz os problemas de latência e desatualização do outro lado.

O que um substrato híbrido faz, query por query

Então o movimento ingênuo dos dois lados falha do mesmo jeito: cada um tenta fazer um único mecanismo realizar um trabalho para o qual ele não foi construído. A própria memória de agents da ApolloSpace AI é construída para rodar o conserto diretamente, não descrevê-lo de fora, e ela mapeia para as três camadas nomeadas para sistemas de IA em geral: um sistema de registro, um sistema de inteligência, e um sistema de ação. A pergunta fornecedor-renovação-reversão da cena de abertura é o caso concreto.

O sistema de registro da ApolloSpace AI para memória de agent é o vector index e o graph temporal juntos, um substrato só, não dois produtos separados colados na API. O sistema de inteligência é o loop do agent raciocinando sobre esse registro query por query, construído para rodar na mesma ordem que o Graphiti, o engine de knowledge graph temporal por baixo da memória de agent de produção da Zep, validou: vector recall primeiro, similaridade de cosseno puxa um pequeno conjunto de candidate nodes de um store muito maior em milissegundos. Esses candidatos são pontos de entrada no graph, não a resposta. A travessia do graph expande em seguida, seguindo as edges tipadas que conectam um fato a outro, o fornecedor à renovação à reversão, em vez de adivinhar por proximidade. Um reranker híbrido então mescla três sinais de uma vez, similaridade semântica de cosseno, keyword search, e o resultado da travessia do graph, numa resposta final com o caminho de suporte intacto.

Esse é o mesmo padrão de três passos que o Graphiti reporta rodar em produção com uma latência P95 de retrieval de 300 milissegundos e zero chamadas de LLM na hora da query, pontuando 94.8% no benchmark Deep Memory Retrieval com gpt-4-turbo e 98.2% com gpt-4o-mini (arXiv 2501.13956; Neo4j engineering blog on Graphiti). O pipeline da ApolloSpace AI é construído sobre essa arquitetura publicada de propósito, não inventado do zero: os próprios resultados da Zep são a validação contra a qual a ApolloSpace AI projeta o padrão, do jeito que um time de engenharia faz benchmark de um build contra uma spec pública em vez de adivinhar uma. A gente aprofunda como as três camadas de memória de agent dividem esse trabalho em os três tipos de memória que seu agent precisa.

O próprio loop da ApolloSpace AI é construído para fazer uma terceira coisa que nem o lado vector-only nem o lado do graph estático precisavam fazer: o sistema de ação. Assim que a resposta com rerank resolve a reversão, ele é projetado para escrever essa resolução de volta no mesmo registro como uma edge nova, tipada e com timestamp, que supersedes o fato desatualizado em vez de ficar do lado dele, então o próximo agent perguntando sobre o mesmo fornecedor lê o fato resolvido em vez de rederivá-lo a partir de três chunks desconectados. Esse write-back é o que mantém o registro, o raciocínio, e a ação dentro de um loop auditável só, em vez de uma camada que responde certo uma vez e esquece que já respondeu.

Vector recall reduz o search space em milissegundos, a travessia do graph raciocina só sobre esse conjunto reduzido, e um rerank híbrido mescla os dois sinais sem chamar o modelo para isso, e então a action layer escreve o fato resolvido de volta no registro de onde ele começou.

O que isso custa, honestamente

Nada disso é de graça, e fingir o contrário enfraqueceria o argumento inteiro. Um substrato híbrido significa rodar e manter dois sistemas em vez de um, um vector index e um graph store, mantidos em sync. Cada fato novo custa mais para escrever do que um simples append num index: ele tem que ser reconciliado contra nodes existentes, tipado contra as edges certas, e, num graph temporal, marcado com timestamp para que uma contradição posterior supersedes ele em vez de ficar do lado dele. Essa amplificação de escrita é real, o preço de um graph que consegue responder “por quê” e “a partir de quando”, não só “o quê”.

Ser dono das duas camadas também significa abrir mão da opção fácil de trocar por qualquer vector database ou graph engine que pareça melhor neste trimestre. Os dois stores têm que concordar sobre identidade e scope, o que conta como a mesma entidade nos dois, e esse acoplamento é um compromisso real, não uma nota de rodapé. Um time esperando um plugin de graph pronto para encaixar em cima de um vector store existente vai achar que o trabalho de integração está mais perto de um rebuild da camada de retrieval do que de um encaixe simples.

O tradeoff vale a pena por uma razão: a alternativa não é mais barata, só é mais barata de construir e cara de estar errada. Um sistema vector-only que inverte a reversão na frente de um cliente custa mais do que o overhead de manutenção jamais vai custar, e um graph estático certo uma vez por semana e desatualizado nos outros seis dias troca um tipo de inconfiabilidade por outro. Pagar por reconciliação e sync é o custo de um agent em quem se confia com uma pergunta two-hop na primeira vez que ela é feita.

A virada

Dá um passo atrás do diagrama do pipeline por um segundo, porque a pessoa que fez a pergunta original não liga para qual store respondeu ela.

O que essa pessoa liga é se o agent pode ser confiado com uma pergunta two-hop do jeito que um colega que estava de fato na sala responderia, corretamente, na primeira tentativa, não na terceira reformulação depois que a resposta errada já saiu. Essa confiança é exatamente o que nenhum mecanismo puro entrega sozinho: vector search sozinho consegue uma resposta rápida, confiante, ocasionalmente invertida; um graph estático sozinho consegue uma resposta correta que chega depois que o momento que precisava dela já passou. A resposta de produção para memória de agent é um substrato híbrido onde vetores encontram candidatos rápido e o graph faz o raciocínio multi-hop e mantém a proveniência, não um ou outro sozinho, precisamente porque é a única versão do sistema que chega lá correta e na hora.

A resposta de produção para memória de agent é um substrato híbrido onde vetores encontram candidatos rápido e o graph faz o raciocínio multi-hop e mantém a proveniência, não um ou outro sozinho. Fala isso vezes suficientes e para de soar como um meio-termo entre dois lados e passa a soar como o que realmente é: rotear cada pergunta para o mecanismo construído para respondê-la.

---

Esse é o loop que a própria memória de agents da ApolloSpace AI é construída para rodar, não só o substrato ao redor do qual ela é projetada: vector recall para reduzir rápido, um graph para raciocinar sobre o que está conectado e guardar os recibos do porquê, e o write-back que resolve a resposta dentro do registro para que o próximo agent não reabra o caso, montado para que um operations agent perguntado sobre um fornecedor, uma renovação, e uma reversão receba a resposta certa antes da conversa seguir adiante, não dezenas de segundos depois.