A análise detalhada de um desenvolvedor sobre a construção de um "motor de contexto" destaca o que equipes RAG de produção têm resolvido silenciosamente: recuperação funciona, mas gerenciar o que realmente entra na janela de contexto do LLM não. O sistema, implementado em Python puro com benchmarks mensuráveis, controla explicitamente memória, compressão, re-ranking e orçamentos de tokens — abordando a lacuna entre recuperação bruta e construção de prompts onde a maioria das implementações RAG falha.
Isso mapeia diretamente com o que cobri quando Karpathy abandonou RAG por gerenciamento de conhecimento nativo do LLM em abril. O problema fundamental não é precisão de recuperação — é arquitetônico. Tutoriais de RAG terminam em "recuperar documentos, enfiar no prompt", mas sistemas de produção precisam de decisões deliberadas sobre fluxo de informação. Quando contexto recuperado são 6.000 caracteres mas seu orçamento é 1.800 tokens, quando documentos quase duplicados expulsam os úteis, quando histórico de conversa do primeiro turno ainda ocupa espaço vinte turnos depois — é aí que RAG básico quebra.
A comunidade mais ampla está convergindo neste mesmo problema de diferentes ângulos. O repositório RAG Techniques de 27.000 estrelas enfatiza arquiteturas de cinco camadas que lidam com modos de falha sequencialmente. Outros desenvolvedores estão implementando busca híbrida BM25 + vetorial com re-ranking de cross-encoder, ou abandonando RAG completamente por bases de conhecimento markdown mantidas por LLM. O que conecta essas abordagens é controle explícito sobre composição de contexto ao invés de esperar que recuperação + prompting de alguma forma funcione em escala.
Para equipes rodando chatbots multi-turno ou sistemas RAG com grandes bases de conhecimento, isso não é teórico. Gerenciamento de contexto vira o gargalo nos primeiros turnos de conversa. A escolha é construir essa camada deliberadamente ou assistir seu sistema degradar conforme contexto se acumula — o que explica por que equipes de produção estão investindo tempo de engenharia no que teoricamente deveria ser resolvido por melhor prompting.
