O RAG em Obsidian de Karpathy Matou Meu Banco de Dados Vetorial

O RAG em Obsidian de Karpathy Matou Meu Banco de Dados Vetorial

Eu estava no meio de um pipeline RAG tradicional quando Andrej Karpathy postou algo no X que me fez questionar cada decisão arquitetônica dos últimos seis meses.

Sem banco de dados vetorial. Sem embeddings. Sem estratégia de chunking. Sem limiares de similaridade para ajustar. Apenas arquivos markdown, uma estrutura de pastas e um LLM que atua como bibliotecário e autor ao mesmo tempo.

Minha primeira reação foi ceticismo. Eu construí sistemas RAG. Debuguei falhas de retrieval, lutei com configurações de chunk overlap, e vi documentos perfeitamente relevantes serem enterrados por pontuações de similaridade cosseno que não faziam sentido. A ideia de que você poderia pular toda essa infraestrutura e obter resultados melhores para uma base de conhecimento pessoal parecia como alguém dizendo que você poderia ultrapassar um carro andando — na direção certa.

Então eu construí. E a metáfora de andar na direção certa acabou sendo desconfortavelmente precisa.

O sistema de Karpathy — que ele chama de "LLM Knowledge Bases" — funciona porque explora algo que a maioria dos arquitetos RAG ignora: para datasets abaixo de cerca de 400.000 palavras (aproximadamente 100 artigos substanciais), uma estrutura markdown bem organizada com resumos e arquivos de índice dá ao LLM mais contexto útil do que a busca vetorial jamais poderia. O modelo não recupera fragmentos. Ele navega por um grafo de conhecimento que ele mesmo construiu, seguindo links que ele mesmo criou, lendo resumos que ele mesmo escreveu.

Essa distinção — o LLM como autor da estrutura de conhecimento, não apenas um consumidor de chunks recuperados — muda tudo sobre como o sistema performa. E é a parte que a maioria da cobertura da abordagem de Karpathy enterra sob o título.

Por Que o RAG Tradicional Falha na Escala em que a Maioria das Pessoas Realmente Trabalha

Aqui está algo que ninguém no ecossistema RAG quer admitir: para 90% dos desenvolvedores individuais e equipes pequenas, o RAG tradicional é exagero que piora ativamente os resultados.

Não estou falando de busca empresarial em milhões de documentos. Esse é um problema diferente com restrições diferentes. Estou falando do desenvolvedor que tem 50-200 artigos marcados, um punhado de papers de pesquisa, alguma documentação de repos, e uma pilha crescente de notas sobre as quais quer que um LLM raciocine.

Para esse caso de uso — que descreve a maioria de nós — o pipeline RAG tradicional introduz três problemas que sistemas markdown-first simplesmente não têm.

O problema do chunking. Todo sistema RAG divide documentos em chunks. O tamanho do chunk é um compromisso: muito pequeno e você perde contexto, muito grande e desperdiça tokens em texto irrelevante. Não existe um tamanho de chunk universalmente correto, e a escolha errada degrada silenciosamente cada consulta. Passei tardes inteiras ajustando porcentagens de overlap de chunks, e a verdade honesta é que sempre parecia que eu estava negociando com o sistema em vez de configurá-lo.

O problema do ruído de retrieval. A busca por similaridade vetorial retorna os chunks matematicamente mais similares, não os mais úteis. Tive consultas onde os top-5 chunks recuperados eram todos da mesma seção do mesmo documento — cinco parágrafos ligeiramente diferentes dizendo quase a mesma coisa — enquanto o insight realmente relevante de outro documento estava na posição 47 dos resultados. Relevância e similaridade não são a mesma coisa, e a busca vetorial otimiza para a coisa errada.

O problema da caixa preta. Com um banco de dados vetorial, você não consegue ver facilmente o que está dentro. Não pode navegar sua base de conhecimento como navega uma pasta. Não pode verificar manualmente se um documento foi indexado corretamente. Não pode identificar lacunas na cobertura escaneando uma lista. Os dados desaparecem em embeddings, e você interage com eles apenas através de consultas que podem ou não revelar o que você precisa.

O sistema de Karpathy contorna os três. Sem chunking — o LLM lê resumos estruturados e segue links para documentos completos quando necessário. Sem similaridade vetorial — o LLM navega um índice que construiu e entende. Sem caixa preta — cada pedaço de conhecimento vive em um arquivo markdown legível que você pode abrir em qualquer editor de texto.

O trade-off? Não escala para milhões de documentos. Mas se sua base de conhecimento é medida em centenas de artigos em vez de milhões, esse trade-off é um dos melhores negócios em IA agora.

Como a Base de Conhecimento LLM de Karpathy Realmente Funciona

Em 3 de abril de 2026, Karpathy publicou um GitHub gist chamado llm-wiki que expõe a arquitetura completa. O sistema tem três camadas, e entender como elas interagem é a chave para fazê-lo funcionar.

Camada 1: O Cofre Raw

Tudo começa em uma pasta raw/ dentro de um vault do Obsidian. Esta é a área de staging — um depósito para qualquer coisa que você queira que o LLM eventualmente conheça. Artigos recortados da web. Papers de pesquisa em PDF. Documentação de repositórios. Capturas de tela. Fragmentos de código. Transcrições de podcasts.

A pasta raw tem uma regra: nada nela precisa estar organizado. Você joga coisas dentro, e o LLM organiza depois. Isso importa mais do que parece. A maioria dos sistemas de gestão do conhecimento falha porque a fricção de ingestão é muito alta — você precisa taguear coisas, categorizar coisas, arquivar coisas no lugar certo. Com a abordagem de Karpathy, a ingestão é tão simples quanto arrastar um arquivo para uma pasta.

Para artigos web, Karpathy usa o Obsidian Web Clipper — uma extensão Chrome que converte qualquer página web em um arquivo markdown e o coloca diretamente na sua pasta raw. Um clique. O artigo está no seu sistema, imagens incluídas.

Falando em imagens: Obsidian não lida automaticamente com imagens inline de páginas web recortadas. Você precisa do plugin comunitário "Local Images Plus", que baixa imagens remotas e as armazena localmente dentro do vault. Sem este plugin, seus artigos recortados terão links de imagens quebrados quando você estiver offline — e o LLM não poderá referenciar conteúdo visual através de suas capacidades de visão.

Camada 2: O Wiki Compilado

Aqui é onde o sistema de Karpathy diverge de qualquer outra abordagem de gestão do conhecimento que eu já vi.

Em vez de indexar os documentos raw para retrieval, o LLM os lê e escreve novos documentos. Ele compila o material bruto em um wiki estruturado — artigos estilo enciclopédia sobre conceitos fundamentais, resumos de documentos fonte, e backlinks explícitos entre ideias relacionadas.

O wiki vive em uma pasta wiki/, paralela a raw/. Dentro, você encontrará:

• Um índice mestre (index.md) — um único arquivo markdown listando cada wiki criado, com descrições breves e links. Este é o ponto de partida do LLM para qualquer consulta. Ele lê o índice mestre, identifica qual wiki é relevante, e então navega para o próprio índice e artigos daquele wiki.

• Pastas de sub-wiki — cada tópico ganha sua própria pasta com seu próprio index.md e um conjunto de artigos compilados. Um wiki sobre "arquiteturas transformer" pode conter artigos sobre mecanismos de atenção, codificação posicional e leis de escalamento, todos interligados.

• Backlinks e referências cruzadas — o LLM cria [[links estilo wiki]] entre conceitos relacionados através de diferentes wikis. Estes não são decorativos. São a estrutura de navegação que o LLM usa ao responder consultas que abrangem múltiplos tópicos.

O passo de compilação é onde o LLM prova seu valor. Não está copiando texto de documentos raw para artigos wiki. Está sintetizando — identificando os conceitos fundamentais, escrevendo explicações claras, notando contradições entre fontes, e construindo uma rede de conexões que nenhum banco de dados vetorial poderia replicar.

Veja como um prompt de compilação se parece na prática. Você aponta seu agente LLM (Karpathy usa Claude Code) para a pasta raw e diz algo como:

Leia os arquivos em raw/ que se relacionam com [tópico].
Crie um novo wiki em wiki/[nome-do-topico]/ com:
1. Um index.md listando todos os artigos neste wiki
2. Artigos individuais para cada conceito principal
3. Backlinks para wikis relacionados onde relevante
4. Atualize o master wiki/index.md para incluir este novo wiki

O LLM faz a pesquisa, escreve os artigos, constrói os links e atualiza os índices. Você revisa o output na UI do Obsidian — limpo, navegável, legível por humanos.

Camada 3: A Interface de Consulta

Quando você faz uma pergunta ao LLM sobre sua base de conhecimento, ele não busca em documentos raw. Segue um caminho estruturado:

1. Lê o master wiki/index.md para identificar wikis relevantes
2. Abre o index.md do wiki relevante para encontrar artigos específicos
3. Lê esses artigos (que contêm conhecimento sintetizado mais referências a fontes)
4. Segue backlinks para conceitos relacionados se a pergunta abrange tópicos
5. Retorna uma resposta fundamentada no wiki compilado, citando artigos específicos

Isso se parece mais com como um pesquisador humano trabalha do que qualquer coisa que a busca vetorial oferece. Um pesquisador não escaneia cada documento em uma biblioteca buscando correspondências de palavras-chave. Verifica o índice, encontra a seção certa, lê os artigos relevantes e segue referências para material relacionado.

A diferença de desempenho é real. Para o dataset de Karpathy de aproximadamente 100 artigos e 400.000 palavras, a abordagem de navegação por wiki deu respostas mais coerentes e melhor documentadas do que um pipeline RAG tradicional — porque o LLM estava raciocinando sobre conhecimento estruturado que já havia sintetizado, não tentando dar sentido a chunks recuperados em tempo real.

Configurando Isso do Zero: O Guia Completo

Reconstruí o sistema de Karpathy na minha própria máquina em menos de uma hora. Aqui está cada passo, incluindo os que a maioria dos guias pula.

Passo 1: Instalar Obsidian e criar a estrutura do vault.

Baixe Obsidian de obsidian.md. É gratuito para uso pessoal. Crie um novo vault — Obsidian pedirá que escolha uma pasta. Nomeei o meu vault e coloquei no meu diretório home, mas a localização não importa.

Dentro do vault, crie duas pastas:

vault/
  raw/
  wiki/

Essa é toda a estrutura de arquivos para começar. A pasta wiki será preenchida conforme você compila.

Passo 2: Instalar o Web Clipper.

Vá para obsidian.md/clipper e instale a extensão Chrome. Nas configurações do clipper, defina o local de salvamento padrão para sua pasta raw/. Agora qualquer artigo web está a um clique de estar na sua base de conhecimento.

Teste imediatamente. Recorte um artigo que estava querendo ler. Abra Obsidian e confirme que o arquivo markdown apareceu em raw/. Se as imagens não estão aparecendo, você precisa do passo 3.

Passo 3: Instalar Local Images Plus.

No Obsidian, vá para Configurações > Plugins Comunitários > Explorar. Procure "Local Images Plus" e instale. Ative o plugin, depois configure para baixar imagens em uma subpasta dentro do seu vault (uso vault/assets/images/).

Após ativar este plugin, recorte novamente um artigo web. As imagens agora devem baixar localmente e exibir corretamente no modo de preview do Obsidian. Isso é especialmente crítico se você está recortando artigos técnicos com diagramas, gráficos de arquitetura ou capturas de código — o contexto visual importa, e LLMs modernos com capacidades de visão podem realmente ler essas imagens.

Passo 4: Preencher sua pasta raw.

Essa é a parte divertida. Comece a despejar conteúdo em raw/. Algumas fontes que funcionam bem:

• Posts técnicos de blog que você marcou (use o Web Clipper)
• Papers de pesquisa (salvar como PDF ou converter para markdown)
• READMEs de repos do GitHub (copiar o markdown diretamente)
• Suas próprias notas, esboços e documentação de projetos
• Transcrições de palestras de conferências
• Edições de newsletters que você salvou

Não organize. Não renomeie. Não taguee. Apenas coloque na pasta. O LLM cuida da organização no próximo passo.

Comecei com 63 artigos sobre arquiteturas de agentes IA — uma mistura de posts de blog, papers e minhas próprias notas de projeto. O total chegou a cerca de 180.000 palavras de material bruto.

Passo 5: Criar sua primeira compilação wiki.

Aqui é onde você traz seu agente LLM. Se estiver usando Claude Code (que recomendo para este fluxo de trabalho porque lida com operações de arquivo nativamente), navegue até o diretório do vault e execute um prompt de compilação.

Aqui está o prompt que usei para meu primeiro wiki:

Examine os arquivos em raw/ que discutem arquiteturas de agentes IA,
sistemas multi-agente ou padrões de orquestração de agentes.

Crie um wiki em wiki/ai-agent-architectures/ com:
- Um index.md listando cada artigo no wiki com uma descrição de uma linha
- Artigos individuais para conceitos principais (pelo menos: padrões de
  orquestração, padrões de uso de ferramentas, arquiteturas de memória,
  comunicação multi-agente)
- Cada artigo deve sintetizar informações de múltiplas fontes raw
- Incluir [[backlinks]] para conceitos relacionados dentro do wiki
- No final de cada artigo, listar os arquivos fonte raw de onde veio
- Criar wiki/index.md (o índice mestre) se não existir,
  e adicionar este wiki

Claude Code leu os arquivos raw relevantes, identificou os conceitos-chave e gerou um wiki com 11 artigos, um índice abrangente e referências cruzadas entre eles. Todo o processo levou cerca de quatro minutos.

A qualidade do output me surpreendeu. Não era simples resumo — era síntese genuína. Um artigo sobre "Arquiteturas de Memória para Agentes IA" extraiu insights de sete fontes raw diferentes, organizou-os em um framework coerente, e notou onde duas das fontes se contradiziam na questão de persistência de memória de longo prazo.

Passo 6: Configurar o índice mestre.

Após sua primeira compilação, wiki/index.md deve existir. Abra no Obsidian e verifique se parece correto. À medida que cria mais wikis, este arquivo se torna o ponto de entrada do LLM — o índice de toda sua base de conhecimento.

Um índice mestre saudável se parece com algo assim:

# Índice da Base de Conhecimento

## Wikis

### Arquiteturas de Agentes IA
Padrões de orquestração, uso de ferramentas, sistemas de memória e
frameworks de comunicação multi-agente.
→ [[ai-agent-architectures/index]]

### Leis de Escalamento de Transformers
Compute de treinamento, contagem de parâmetros, requisitos de dados e
capacidades emergentes através de tamanhos de modelo.
→ [[transformer-scaling/index]]

Passo 7: Consultar sua base de conhecimento.

Agora vem a recompensa. Quando quiser fazer uma pergunta à sua base de conhecimento, diga ao Claude Code para começar pelo índice mestre:

Leia wiki/index.md para se orientar sobre o que está disponível na minha
base de conhecimento. Depois responda esta pergunta usando os artigos
wiki relevantes: [sua pergunta aqui]

O LLM lê o índice, identifica o wiki relevante, navega até os artigos específicos e dá uma resposta fundamentada no seu conhecimento compilado — com referências a artigos específicos que você pode verificar.

Dica: adicione um changelog.md à raiz do vault. Cada vez que compilar um novo wiki ou atualizar um existente, registre a data e o que mudou. Karpathy recomenda um formato de prefixo consistente como ## [2026-04-05] ingest | Título do Artigo para que o log seja parseável com ferramentas unix padrão. Isso dá a você (e ao LLM) uma linha do tempo de como a base de conhecimento evoluiu.

O Que Isso Acerta Que o RAG Tradicional Erra

Após executar ambos sistemas em paralelo por uma semana — meu antigo pipeline RAG baseado em vetores no mesmo dataset ao lado do wiki estilo Karpathy — notei três vantagens específicas que não são óbvias até você ter usado ambos.

A vantagem da síntese. Quando perguntei ao meu sistema vector RAG "Quais são os trade-offs entre orquestração de agentes centralizada e descentralizada?", ele retornou cinco chunks de três documentos diferentes. Os chunks eram relevantes, mas eu tive que sintetizá-los mentalmente. O sistema wiki já havia feito essa síntese durante a compilação. O artigo sobre padrões de orquestração apresentou os trade-offs em uma comparação estruturada, extraindo dos mesmos documentos fonte mas apresentando-os como um argumento coerente em vez de fragmentos.

A vantagem da descoberta. A estrutura de backlinks do wiki revela conexões que você não perguntou. Quando consultei o sistema wiki sobre arquiteturas de memória, a resposta referenciou um backlink para um conceito no wiki de "padrões de uso de ferramentas" que eu não havia conectado mentalmente. O backlink existia porque o LLM, durante a compilação, notou que o problema de persistência de memória em agentes é estruturalmente similar ao problema de gestão de estado em cadeias de ferramentas. A busca vetorial não encontra essas conexões porque não são lexicamente similares — estão conceitualmente relacionadas em um nível que requer compreensão, não correspondência.

A vantagem da transparência. Quando o sistema wiki me dá uma resposta, posso abrir os artigos fonte no Obsidian e lê-los eu mesmo. Posso ver o que o LLM sintetizou, posso verificar se a síntese é precisa, posso corrigi-la se estiver errada. Com vector RAG, recebo chunks e pontuações de similaridade. Debugar por que o sistema deu uma resposta ruim significa escavar embeddings e logs de retrieval. Com o sistema wiki, abro um arquivo markdown e leio. A superfície de debug é texto legível por humanos.

Se prefere que alguém construa um sistema completo de base de conhecimento LLM personalizado para seu fluxo de trabalho de pesquisa específico, aceito exatamente esse tipo de projetos de infraestrutura IA. Você pode ver o que construí em fiverr.com/s/EgxYmWD.

As Limitações Honestas — Onde Esta Abordagem Quebra

Eu estaria fazendo um desserviço se não expusesse os limites claramente. O sistema de Karpathy é brilhante para seu caso de uso pretendido, mas tem restrições reais que importam.

Teto de escala. Esta abordagem funciona para aproximadamente 100-400 artigos (até cerca de 400.000 palavras de material bruto). Além disso, o LLM começa a ter dificuldades para manter índices coerentes e o tempo de compilação cresce substancialmente. Se estiver lidando com milhares de documentos, precisa de RAG tradicional ou uma abordagem híbrida. O ponto de equilíbrio depende da janela de contexto do seu LLM — com o contexto de 1M tokens do Opus 4.6, pode ir além das estimativas originais de Karpathy, mas ainda há um teto prático.

Custo de compilação. Cada vez que adiciona material novo significativo, precisa recompilar o wiki afetado. Isso significa chamadas ao LLM, o que significa tokens, o que significa dinheiro. Para um projeto hobby, isso é insignificante. Para uma base de conhecimento continuamente atualizada com ingestão diária, os custos de compilação se acumulam. Descobri que batching — acumular material bruto por uma semana e depois compilar uma vez — mantém os custos razoáveis.

Sem retrieval em tempo real. O wiki é um snapshot. Se recortou um artigo dez minutos atrás mas não recompilou o wiki relevante, o LLM não saberá dele durante uma consulta. Pode apontá-lo para a pasta raw diretamente para adições recentes, mas isso é um passo manual. Sistemas RAG tradicionais indexam novos documentos em segundos após a ingestão.

Design de usuário único. Isso é fundamentalmente um sistema de gestão do conhecimento pessoal. Não há controle de acesso multiusuário, sem salvaguardas de edição concorrente, sem histórico de versões além do que o git fornece. Para equipes, seria necessário construir infraestrutura de colaboração por cima — ponto em que talvez esteja melhor servido com um sistema RAG construído para esse propósito.

Dependência do LLM. A qualidade do seu wiki está diretamente ligada à qualidade do LLM fazendo a compilação. Testei isso com modelos menores e os resultados são notavelmente mais fracos — a síntese é mais superficial, as referências cruzadas são menos perspicazes, e a organização do índice é menos intuitiva. Você quer um modelo fronteira para o passo de compilação. Para consultas, um modelo menor pode funcionar bem porque está apenas navegando um wiki bem estruturado.

Esses não são dealbreakers. São limites de design. Karpathy construiu este sistema para um perfil específico — um pesquisador ou desenvolvedor individual gerenciando uma base de conhecimento pessoal de tamanho moderado — e dentro desses limites, funciona melhor do que qualquer outra coisa que experimentei.

O Que Faria Diferente Após Uma Semana Usando Isso

Minha primeira compilação wiki foi descuidada. Não porque o LLM fez um trabalho ruim, mas porque dei material bruto demais de uma vez sem um limite temático claro. Apontei Claude Code para 63 artigos e disse "faça um wiki sobre agentes IA." O resultado foi extenso — 11 artigos cobrindo tudo desde prompt engineering até coordenação multi-agente até tool calling, com backlinks conectando conceitos que estavam relacionados apenas no sentido mais amplo.

Na segunda vez, fui mais cirúrgico. Agrupei meus arquivos raw em clusters temáticos aproximados antes da compilação: 18 artigos sobre padrões de orquestração em um lote, 12 sobre arquiteturas de memória em outro, 15 sobre uso de ferramentas em um terceiro. Cada um se tornou seu próprio wiki com seu próprio índice focado. As referências cruzadas entre wikis foram mais significativas porque cada wiki tinha um escopo claro.

Essa é minha maior lição prática: compile estreito, linke amplo. Cada wiki deve cobrir um tópico restrito. As conexões entre wikis emergem naturalmente através de backlinks, e essas conexões são mais valiosas quando fazem ponte entre domínios genuinamente distintos em vez de linkar parágrafos adjacentes no mesmo tópico extenso.

Segunda lição: revise a primeira compilação de cada wiki manualmente. O LLM ocasionalmente toma decisões estruturais que você não tomaria — agrupando conceitos diferentemente do esperado, ou criando artigos com uma granularidade que não corresponde a como você pensa sobre o tópico. Uma revisão e reestruturação de 10 minutos após a primeira compilação salva de agravar problemas estruturais à medida que o wiki cresce.

Terceira lição: sua pasta raw vai ficar bagunçada, e está tudo bem. Comecei tentando organizar arquivos raw em subpastas por tipo de fonte. Foi esforço desperdiçado. O LLM não se importa se seus arquivos raw estão organizados. Lê todos, extrai o relevante e ignora o resto. Deixe o wiki ser sua camada organizada. Deixe raw ser sua gaveta de bagunça.

Venho construindo sistemas de gestão do conhecimento pessoal com Obsidian há algum tempo — se você leu meu guia sobre transformar Obsidian e Claude Code em um segundo cérebro, reconhecerá alguns desses padrões. Mas a abordagem de compilação de Karpathy vai além. Minha configuração original usava Obsidian principalmente como fonte de contexto — apontar o LLM para arquivos markdown e deixá-lo ler. O insight de Karpathy é que o LLM também deve escrever a estrutura de conhecimento, não apenas consumir.

Onde Isso Se Encaixa na Paisagem RAG de 2026

O timing do post de Karpathy não foi acidental. Estamos em um ponto de inflexão onde as ferramentas para construir sistemas de conhecimento se bifurcaram em dois campos.

Campo um: plataformas RAG pesadas com bancos de dados vetoriais, pipelines de embedding, modelos de reranking e estratégias de retrieval complexas. São construídas especificamente para escala empresarial — milhões de documentos, milhares de consultas concorrentes, requisitos rigorosos de latência. Funcionam. Mas são caras para construir, caras para manter, e exagero para qualquer um cuja coleção de documentos cabe em uma pasta.

Campo dois: o que Karpathy chama de "LLM Knowledge Bases." Arquivos markdown, índices estruturados, wikis compilados por LLM. Zero infraestrutura além de um editor de texto e uma API de LLM. São construídas especificamente para pesquisadores individuais, desenvolvedores e equipes pequenas cuja base de conhecimento é medida em centenas de artigos, não milhões.

O erro que a maioria comete é usar ferramentas do campo um para problemas do campo dois. Já vi desenvolvedores solo levantarem instâncias Pinecone para gerenciar 40 documentos. Isso não é engenharia, é arquitetura guiada pelo currículo. A ferramenta certa para uma base de conhecimento de 40 documentos é uma pasta de arquivos markdown e um LLM inteligente.

Se suas necessidades crescerem além do que a abordagem markdown-first suporta, sempre pode migrar. Os arquivos raw são texto plano. Os wikis são texto plano. Não há formato proprietário, sem vendor lock-in, sem pesadelo de migração. Você pega seus arquivos markdown e os alimenta no sistema para o qual evoluir.

Esse é talvez o aspecto mais subestimado do design de Karpathy: otimiza para o caminho de saída, não apenas o caminho de entrada. Cada pedaço de conhecimento no sistema é armazenado no formato mais portável possível. Se Obsidian desaparecer amanhã, seus arquivos ainda funcionam no VS Code, Notion, Bear ou qualquer outro editor markdown. Se superar o sistema, seu conteúdo muda com você.

Se já está usando Obsidian com Claude Code para memória persistente — algo que cobri em profundidade no meu post sobre por que Obsidian corrigiu a maior fraqueza do Claude Code — a abordagem de compilação wiki de Karpathy é o passo natural seguinte. Já está armazenando contexto em markdown. Agora deixe o LLM organizar esse contexto em algo pelo qual possa navegar inteligentemente.

A Mudança Que Importa Mais do Que os Detalhes Técnicos

Continuo voltando a uma única distinção que faz a abordagem de Karpathy parecer fundamentalmente diferente do RAG tradicional.

Em um sistema RAG tradicional, o LLM é um consumidor. Recebe chunks, lê e gera uma resposta. A estrutura de conhecimento — os embeddings, o índice, a lógica de retrieval — é construída por infraestrutura de engenharia, não pelo modelo em si.

No sistema de Karpathy, o LLM é tanto arquiteto quanto residente. Constrói a estrutura de conhecimento durante a compilação. Escreve os resumos, cria os links, organiza o índice. Depois, durante consultas, navega uma casa que ele mesmo projetou. Sabe onde as coisas estão porque as colocou lá.

Isso não é uma distinção técnica menor. É um paradigma diferente para como pensamos sobre LLMs e conhecimento.

A maior parte da comunidade IA em 2026 está focada em tornar o retrieval mais inteligente — melhores embeddings, melhor reranking, melhor seleção de chunks. Karpathy está fazendo uma pergunta fundamentalmente diferente: e se pararmos de tratar o LLM como um motor de busca e começarmos a tratá-lo como um bibliotecário pesquisador? Não um que encontra livros sob demanda, mas um que já leu cada livro na coleção, escreveu resumos de cada um, criou um catálogo de referências cruzadas, e pode levá-lo diretamente à prateleira que precisa.

Essa pergunta vai importar mais à medida que as janelas de contexto continuam crescendo. Com Opus 4.6 lidando com 1 milhão de tokens, a quantidade de conhecimento que um LLM pode navegar através de índices estruturados — sem qualquer busca vetorial — já é prática para a maioria dos casos de uso pessoais e de equipes pequenas. E as janelas de contexto só estão ficando maiores.

Meu banco de dados vetorial não vai a lugar nenhum. Ainda preciso dele para o sistema RAG de produção que construí para o arquivo de 2 milhões de documentos de um cliente. Mas para minha base de conhecimento pessoal? Para a pesquisa que estou fazendo sobre agentes IA, os artigos que estou lendo, as ideias que estou colecionando? O banco de dados vetorial está desligado. O vault do Obsidian está aberto. E pela primeira vez, minha base de conhecimento parece algo que realmente posso navegar, não apenas consultar.

Comece com 20 artigos sobre um tópico que está pesquisando ativamente. Recorte-os em raw. Execute uma compilação. Faça uma pergunta ao wiki. Veja o que ele conecta. A configuração leva uma hora. O momento em que ele revela uma conexão entre duas ideias que você não havia ligado — é quando entenderá por que Karpathy construiu isso em vez de recorrer a outro banco de dados vetorial.

Perguntas Frequentes

O sistema RAG Obsidian de Karpathy requer habilidades de programação?

Programação mínima é necessária. O sistema usa Obsidian (gratuito, gráfico) para a interface e um agente LLM como Claude Code para compilação wiki. Você escreve prompts em linguagem natural, não código. Conforto básico com linha de comando ajuda mas não é estritamente necessário.

Quantos documentos o sistema wiki Obsidian pode lidar?

A abordagem de Karpathy funciona bem para aproximadamente 100-400 artigos totalizando até 400.000 palavras. Além disso, os tempos de compilação crescem e a coerência do índice se degrada. Para coleções maiores, uma abordagem híbrida ou pipeline RAG tradicional é mais apropriada.

Posso usar GPT ou outros LLMs em vez de Claude Code para compilação wiki?

Sim. O gist do GitHub de Karpathy menciona explicitamente compatibilidade com OpenAI Codex, Claude Code e outros agentes LLM. A qualidade da compilação depende da capacidade de raciocínio do modelo — modelos fronteira produzem síntese e referências cruzadas notavelmente melhores que modelos menores.

O que acontece se Obsidian deixar de ser mantido?

Nada quebra. Cada arquivo no sistema é markdown plano armazenado localmente na sua máquina. Pode abrir toda a base de conhecimento no VS Code, Notion, Bear ou qualquer editor de texto. Há zero vendor lock-in por design.

Como isso difere de simplesmente colocar arquivos em uma pasta e usar ChatGPT?

A diferença crítica é o passo de compilação. Arquivos raw despejados em um chat dão ao LLM contexto não estruturado. O sistema de Karpathy faz o LLM compilar esses arquivos em artigos wiki estruturados com índices, resumos e referências cruzadas — criando uma estrutura de conhecimento navegável em vez de um monte de documentos.

Vamos Trabalhar Juntos

Procurando construir sistemas IA, automatizar fluxos de trabalho ou escalar sua infraestrutura tech? Adoraria ajudar.

• Fiverr (builds personalizados e integrações): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (soluções enterprise): ramlit.com
• ColorPark (design e branding): colorpark.io
• xCyberSecurity (serviços de segurança): xcybersecurity.io