O gargalo da IA corporativa não é o modelo. É a camada de contexto por baixo.

Todo time construindo IA dentro de uma empresa eventualmente chega na mesma conversa. O modelo é impressionante. As demos são ótimas. O piloto interno parecia promissor. Mas quando tentamos torná-lo útil para o nosso trabalho de verdade, com os nossos dados de verdade, tudo desmorona. O modelo não sabe quem são os nossos clientes. Não sabe o que foi discutido na call da semana passada. Não sabe qual versão do contrato é a atual. Construímos um cérebro lindo que não tem memória de quem somos.

Isso não é um problema de modelo. Os modelos estão notavelmente capazes hoje, e ficando cada vez mais. Isso é um problema de contexto, e é o gargalo que segura a maior parte da IA corporativa em algo tecnicamente impressionante em vez de genuinamente útil.

Eu venho pensando nessa camada com calma nos últimos meses, em parte porque já entreguei uma pequena peça dela, principalmente porque acho que a próxima década de como a IA vai ser usada dentro de empresas será definida por quem resolver essa camada bem. Este post é o que aprendi. Não é pitch de vendedor. Eu não trabalho em nenhuma das empresas que vou mencionar. É a visão de um engenheiro sobre como o problema realmente se parece, por que a solução dominante hoje é estruturalmente limitada, e para onde o campo está convergindo.

O problema da amnésia e por que precisamos de uma camada de contexto

A coisa fundamental para entender sobre grandes modelos de linguagem é que eles não têm memória entre chamadas. Toda vez que você manda uma mensagem para o Claude, GPT, Gemini ou qualquer modelo de fronteira, o modelo processa toda a entrada completamente do zero. Nada persiste de chamadas anteriores. O modelo não sabe nada sobre você, sua empresa, sua conversa anterior, seus dados, suas intenções, a menos que essa informação esteja incluída na requisição atual.

O nome técnico para tudo que você manda para o modelo em uma única requisição é context window. Tem um limite duro, medido em tokens. Dois anos atrás esse limite era de 4K tokens, mais ou menos quatro páginas de texto. Hoje a fronteira está empurrando para além de dois milhões de tokens, centenas de páginas. O limite continua subindo, e o custo por token continua caindo. Mas dois fatos permanecem teimosamente verdadeiros. Primeiro, o modelo continua amnésico fora dessa janela. Segundo, a informação que de fato existe na sua empresa (no seu CRM, na sua caixa de entrada, nos seus docs, no seu código, nas suas reuniões) é vastamente maior do que qualquer context window vai ser um dia.

Todo o desafio de engenharia de construir IA útil em cima desses modelos se reduz a uma única pergunta. O que você coloca na context window para qualquer query dada?

Essa pergunta é o portão para tudo o resto. Não importa se você está construindo um agente de suporte ao cliente, um assistente de coding, uma ferramenta de busca corporativa ou um sistema multi-agente, você está respondendo essa pergunta, explicitamente ou implicitamente. O campo do que as pessoas hoje chamam de “context engineering” existe porque a resposta ingênua não funciona.

A abordagem ingênua, e por que ela falha

A resposta ingênua é usar tudo. Tem documentação? Cola. Tem dados de cliente? Injeta. Tem código? Inclui todos os arquivos. Context windows modernas são enormes; é só usar.

Isso quebra em escala por três motivos que qualquer um que já tentou viveu na pele.

Primeiro, o custo é mais ou menos linear no comprimento da entrada. Um contexto de 100K custa cerca de trinta e três vezes o que um contexto de 3K custa. Multiplique isso por cada query de usuário e você construiu um produto que sangra dinheiro a cada interação.

Segundo, a latência escala com o comprimento da entrada. Uma query que deveria parecer instantânea leva quatro segundos. Usuários percebem. A conversão cai.

Terceiro, e o mais sutil, atenção se degrada com o tamanho do contexto. O paper que nomeou esse fenômeno, “Lost in the Middle” do Liu et al, demonstrou que modelos prestam menos atenção a informação enterrada fundo em contextos longos. Mesmo quando você consegue tecnicamente caber 200K tokens, o modelo efetivamente ignora os 100K do meio. Você está pagando por tokens que não ajudam.

Então você não pode despejar tudo. Você tem que recuperar apenas a fatia mais relevante para cada query. O padrão dominante para fazer isso, o que quase toda aplicação de LLM usa hoje, é Retrieval-Augmented Generation. RAG.

RAG: o padrão que construiu as aplicações modernas de LLM

O pipeline de RAG, na sua forma mais simples:

1. Pegue o seu conteúdo de origem. Divida em chunks (tipicamente 200-1000 tokens cada).
2. Para cada chunk, gere um embedding usando um modelo de embedding. Um embedding é um vetor denso, tipicamente de 1536 dimensões, que captura o conteúdo semântico daquele chunk de um jeito em que significados parecidos produzem vetores parecidos.
3. Armazene os embeddings em um banco vetorial (Pinecone, Weaviate, Qdrant, ChromaDB, pgvector, dezenas de outros).
4. Quando o usuário faz uma pergunta, embede a pergunta com o mesmo modelo.
5. Pesquise no banco vetorial os K chunks mais similares à pergunta. Similaridade de cosseno é a métrica padrão.
6. Injete esses K chunks no contexto do modelo junto com a pergunta.
7. O modelo agora tem informação relevante para responder.

Esse padrão é a fundação da maioria das aplicações modernas de LLM. Toda startup de IA corporativa, toda ferramenta de “chat com seu PDF”, todo bot de suporte ao cliente, todo assistente de coding usa alguma variante. Eu mesmo já usei. Lancei um app de recomendação de filmes chamado Reellette ano passado que rodava exatamente essa stack: chunks de metadados, embeddings da OpenAI, ChromaDB para armazenamento, retrieval top-K na hora da query. Para “me ache algo parecido com Inception” o padrão funcionava lindamente. Para uma classe de problemas, o vector RAG é genuinamente a ferramenta certa.

E aí tem a classe muito maior de problemas em que ele não é. Esses são os problemas que mais importam em software corporativo, e são os que estão matando silenciosamente as iniciativas de IA dentro da maioria das empresas.

Onde o vector RAG quebra para dados do mundo real

Três limitações estruturais aparecem consistentemente assim que você empurra o vector RAG para além do estágio de demo.

Similaridade não é a mesma coisa que relação

O primeiro tipo de query que o vector RAG resolve bem é o caso de manual. “Me ache documentos sobre preço”. Embede a pergunta, ache chunks que falam de preço, devolve. Fácil.

O tipo que quebra é relacional. “O que a Acme Corp disse sobre preço na nossa última call?” “Me fala das mudanças recentes de posicionamento da Acme Corp.” “Quais dos nossos clientes deram churn depois de levantar preocupações parecidas com as da Acme?” Essas se parecem superficialmente com queries de busca, mas são estruturalmente diferentes. Elas exigem entender como entidades se relacionam, como fatos se conectam, como eventos se sequenciam. A similaridade vetorial achata todas essas dimensões em um escalar único de proximidade textual.

Eu percebi uma pequena versão disso quando estava construindo o Reellette. O sistema era ótimo em “filmes parecidos com Inception” mas quebrava em “filmes como Inception mas mais sombrios” ou “filmes que usam o mesmo estilo narrativo do roteirista”. A similaridade vetorial não conseguia capturar as dimensões com que os usuários de fato se importavam. Em escala de consumidor, a consequência era uma recomendação um pouco decepcionante. Em escala corporativa, a falha equivalente significa que a IA acha documentos que mencionam a Acme mas não consegue responder quem na sua empresa trabalhou com eles, quando a relação começou, ou como ela evoluiu.

A mesma entidade usa nomes diferentes em todo lugar

Em dados corporativos reais, a mesma pessoa, cliente, produto ou contrato aparece em sistemas diferentes com identificadores diferentes. “John Smith” no Salesforce, “[email protected]” no Gmail, “Smith” no Slack, “JS” em uma transcrição de reunião. Um sistema de contexto ingênuo trata isso como quatro entidades diferentes. Um sistema de contexto correto reconhece como uma só.

O problema tem nome: entity resolution. É o problema mais difícil ainda não resolvido na camada de contexto. A razão de ser difícil é que você quase nunca tem uma chave determinística compartilhada entre sistemas. Se cada ferramenta marcasse o John com o mesmo UUID global, o problema seria trivial. No mundo real, quase nunca é trivial. Então você tem que inferir identidade a partir de evidência circunstancial: nomes parecidos, domínios sobrepostos, contexto compartilhado, o fato de que “Smith” foi mencionado em uma thread que também referenciou a Acme. Toda pista é probabilística. O sistema tem que pesá-las e decidir se a confiança é alta o bastante para fazer merge.

Isso é um tradeoff de precisão versus recall sem almoço grátis. Faça merge agressivo demais e você vai combinar dois John Smiths genuinamente diferentes em um único registro corrompido. Faça merge cauteloso demais e você fragmenta uma pessoa em várias entradas, perdendo toda conexão.

Eu enfrentei uma pequena versão disso no Reellette também. O mesmo filme frequentemente aparecia com títulos ou IDs ligeiramente diferentes entre fontes de metadados, e dedupe era uma dor de cabeça constante de baixa intensidade. Na minha escala era uma cutucada de UX. Em escala corporativa, o mesmo problema estrutural vira um vazamento de access control quando duas pessoas reais são combinadas, ou uma figura de conta corrompida quando uma pessoa é fragmentada. A dificuldade é idêntica. Os riscos diferem em ordens de magnitude.

Busca vetorial estruturalmente não consegue responder perguntas relacionais

Essa é a limitação mais profunda, e é a que motiva o movimento para além de RAG inteiramente. Suponha que você pergunte: “Me ache a pessoa na nossa empresa que está conectada à Acme por meio de um board member compartilhado.” Não existe documento nos seus dados que seja textualmente similar a essa pergunta. A resposta não está nas palavras. A resposta está na estrutura das conexões em si. Você acharia a resposta caminhando da Acme para o board dela, do board para as pessoas que estão nele, dessas pessoas para as empresas com as quais elas são afiliadas, e dessas empresas de volta para o seu time.

A busca vetorial não consegue fazer essa caminhada. Ela consegue achar texto parecido com “board member” ou “Acme” mas não consegue seguir a corrente. A informação existe nos seus dados, mas mora nas relações entre entidades, não em qualquer chunk individual de texto. Pedir para um vector store responder essa query é pedir a coisa errada à ferramenta errada.

A virada para grafo

A resposta a essas limitações, cada vez mais visível em pesquisa e em produto pelo campo todo, é mover de representações vetoriais planas para representações de grafo estruturadas.

Um knowledge graph representa informação como uma rede de nós (entidades) conectados por arestas (relações). Os dois podem carregar propriedades: um nó de pessoa pode ter nome, email e função; uma aresta de “contrato assinado” pode ter data, valor e status de renovação. O grafo não é só um formato de armazenamento diferente. É uma forma diferente de pensar sobre o que os seus dados de fato são.

A intuição é simples. Um vector store trata cada peça de informação como um ponto isolado em espaço semântico. Você acha pontos próximos de outros pontos por similaridade. Mas o valor real na maior parte dos dados corporativos não está nos pontos; está nas relações entre eles. A Acme é cliente. O John é o contato na Acme. Eles assinaram em março. A renovação é em setembro. Eles têm estado cada vez mais ativos em suporte. Eles mencionaram um competidor na call da semana passada. Cada um desses fatos é uma relação entre entidades. Nenhum deles é capturado por similaridade vetorial. Todos eles são capturados por um grafo.

O GraphRAG, em suas várias formas, combina essa estrutura de grafo com a lógica de retrieval do RAG tradicional. Em vez de só achar os K chunks mais similares a uma query, o sistema faz os dois. Usa similaridade vetorial para achar entidades semanticamente relevantes, depois caminha pelo grafo a partir dessas entidades para reunir contexto conectado. O resultado é uma fatia estruturada do estado da empresa que é coerente e conectada, não uma pilha de blocos de texto que por acaso são textualmente próximos.

Um cenário de produtos agora está apostando em versões diferentes disso. A Microsoft publicou um framework de pesquisa chamado GraphRAG que fincou a estaca acadêmica no chão. Empresas como Zep com o Graphiti, Cognee no espaço open-source, e Mem0 especificamente em agent memory estão construindo variantes públicas. Algumas são graph-first. Algumas são híbridas vector-plus-graph. Algumas miram agent memory; outras miram contexto corporativo de forma ampla. A aposta compartilhada é a mesma: o grafo é onde mora o valor.

Traversal de grafo, a operação que a busca vetorial estruturalmente não consegue fazer

O que faz grafos poderosos é a operação chamada traversal. Uma vez que seus dados estão estruturados como grafo, você pode responder perguntas caminhando pelas relações em vez de procurar por matches textuais.

De volta para a pergunta que coloquei antes. “Me ache a pessoa na nossa empresa conectada à Acme por meio de um board member compartilhado.” Coloque o dedo no nó da Acme. Caminhe para fora por arestas marcadas “board member” ou “investidor” para achar conexões compartilhadas. A partir delas, caminhe de volta por arestas “trabalha em” para achar seus colegas. As pessoas no fim dessa caminhada são a sua resposta. Você as achou não por casar palavras mas por seguir a estrutura das relações.

Essa é a coisa central que grafos desbloqueiam, e é por isso que estou cada vez mais convencido de que o futuro do contexto de IA não são context windows maiores. É contexto estruturado. Uma context window de dois milhões de tokens não te ajuda a responder a pergunta da Acme. Um grafo com as entidades e arestas certas, sim.

A profundidade da caminhada importa e é em si um pedaço de julgamento de engenharia. Um hop acha conexões diretas. Dois hops acham amigos de amigos. Três ou quatro hops acham conexões cada vez mais distantes, mas quanto mais longe você caminha, mais resultados você ganha e mais ruidosos eles ficam. Sistemas reais têm que escolher profundidades de traversal sensatas e funções de peso, ambas áreas ativas de pesquisa.

A camada de protocolo: MCP

Mesmo com um grafo limpo e entity resolution rigorosa, ainda existe a pergunta de como as ferramentas de IA de fato consomem o contexto que você construiu. Integrações sob medida foram o padrão até recentemente: todo assistente de IA ganhava o seu próprio conector custom para cada fonte de dados, e a matriz de integração explodia.

O Model Context Protocol, MCP, que a Anthropic lançou no final de 2024, é a tentativa mais credível de resolver isso. O MCP é mais ou menos USB para LLMs: uma forma padronizada para qualquer cliente de IA (Claude, Cursor, n8n, agentes custom) conversar com qualquer fonte de dados (bancos, APIs SaaS, stores custom) sem integração sob medida. Você constrói o contexto uma vez, expõe via MCP, e qualquer ferramenta de IA que fala o protocolo consegue consumir. Isso é uma mudança grande comparada ao mundo anterior, em que toda integração de IA-para-dado era um floco de neve único.

O protocolo em si é aberto, a especificação é pública, e a adoção rápida tanto por grandes provedores de modelos quanto por grandes fontes de dados fez do MCP a camada de interoperabilidade dominante. Se você está construindo qualquer coisa nesse espaço, MCP vale ser entendido a fundo.

A ressalva da qual ninguém fala

Se eu fosse um vendor fazendo pitch dessa coisa toda, eu pararia aqui na nota otimista. Mas eu não estou fazendo pitch de nada, então uma ressalva merece ser dita com clareza porque ela é silenciosamente pulada na maior parte do material sobre essa camada.

Mais contexto não conserta raciocínio ruim.

Se o modelo não consegue pensar atravessando um problema, um contexto mais rico só deixa ele alucinar com mais confiança. Um grafo perfeitamente resolvido com precisão bitemporal e enforcement de ACL limpo é necessário, não suficiente. O grafo ajuda uma IA que já sabe pensar. Não faz de um raciocinador fraco um raciocinador forte.

Isso importa porque os limites do que os modelos atuais conseguem raciocinar através são reais, e eles não se mexem só porque você dá ao modelo mais dados. Algumas perguntas os modelos ainda respondem mal mesmo com contexto perfeito: planejamento multi-step de fim aberto, problemas que exigem raciocínio numérico genuíno, qualquer coisa em que a resposta depende de entender intenção em vez de recuperar informação. Para essas, a camada de contexto não é o gargalo. O modelo é.

Saber quando você tem um problema de contexto versus um problema de raciocínio é em si uma habilidade. Problemas de contexto se resolvem com retrieval e estrutura melhores. Problemas de raciocínio se resolvem esperando modelos melhores, decompondo a tarefa de uma forma diferente, ou aceitando que a IA não é a ferramenta certa para esse trabalho específico. Confundir os dois leva a uma quantidade enorme de esforço de engenharia desperdiçado.

O enquadramento honesto é que contexto é um substrato necessário. Sem ele, mesmo o melhor modelo de raciocínio é inútil nos seus dados. Com ele, um modelo de raciocínio capaz fica substancialmente mais útil. Mas o substrato sozinho não é a resposta. O que você constrói em cima, e o que o modelo subjacente de fato consegue raciocinar, é o resto da resposta.

Para onde eu estou levando isso

A razão de eu vir pensando com calma sobre tudo isso é que estou construindo um sistema de agente de IA pessoal sob o a7t.ai. A visão por trás desse projeto sempre foi um pequeno conjunto de sub-agentes especializados trabalhando a partir de contexto compartilhado: meu calendário, meu email, minhas finanças, meu código. Os primeiros rascunhos assumiam retrieval plano, e quanto mais eu construía, mais óbvio ficava que retrieval plano não me levaria aonde eu queria chegar. A próxima arquitetura vai tratar contexto como um grafo estruturado, com entity resolution explícita entre minhas fontes e traversal como a operação primária de retrieval.

A peça entregue que eu tenho até agora, Reellette, foi a menor versão possível do padrão maior. Ela me ensinou onde a similaridade vetorial bate no teto e tornou o argumento pela estrutura de grafo concreto nas minhas próprias mãos. O sistema que estou construindo a seguir está alguns passos mais à frente no mesmo arco, e eu vou escrever sobre a arquitetura em um post separado quando ela estiver rodando de forma limpa.

O quadro maior é que eu acho que estamos nos primeiros innings da infraestrutura de contexto. O vector RAG é a linguagem de máquina das aplicações de LLM: útil, ubíqua, estruturalmente limitada. A próxima camada (grafos, entity resolution, protocolos MCP, lógica de traversal, permissões multi-tenant) está sendo construída agora, em público, por algumas dezenas de empresas e algumas centenas de engenheiros pelo mundo. Algumas dessas apostas vão funcionar e algumas não. As que funcionarem vão definir como a IA é usada dentro de empresas pela próxima década.

Esse é um problema que vale entender a fundo, mesmo se você não está construindo a camada de infraestrutura por si. Especialmente se você está usando IA para construir qualquer coisa que importa.

Recursos que achei úteis

• “Lost in the Middle: How Language Models Use Long Contexts” por Liu et al, 2023. O paper que nomeou o problema da degradação de atenção.
• “Unlocking Data with Generative AI and RAG” por Keith Bourne, Packt 2024. O livro mais prático e hands-on que achei sobre padrões de RAG em produção.
• Microsoft GraphRAG. Framework de pesquisa e paper que o acompanha da Microsoft Research, a base acadêmica para a abordagem baseada em grafo.
• Anthropic Model Context Protocol. O padrão aberto para conexões de IA-para-dado.
• Ensaios sobre “Context Engineering”. Procure por esse termo para achar a fronteira em movimento. Substack e blogs de engenharia ao longo de 2025 e 2026 trouxeram à tona o pensamento mais atual.