Os codificadores de vibração de IA têm mais um motivo para agradecer Andrej Karpatiao cunhador do termo.
O ex-diretor de IA da Tesla e cofundador da OpenAI, agora executando seu próprio projeto independente de IA, recentemente postado no X descrevendo uma “Base de Conhecimento LLM” abordagem que ele está usando para gerenciar vários tópicos de interesse de pesquisa.
Ao construir um registro persistente de seus projetos, mantido pelo LLM, Karpathy está resolvendo a principal frustração do desenvolvimento de IA “sem estado”: a temida redefinição do limite de contexto.
Como qualquer pessoa que tenha vibe coded pode atestar, atingir um limite de uso ou encerrar uma sessão muitas vezes parece uma lobotomia para o seu projeto. Você é forçado a gastar tokens valiosos (e tempo) reconstruindo o contexto para a IA, esperando que ela “se lembre” das nuances arquitetônicas que você acabou de estabelecer.
Karpathy propõe algo mais simples, mais flexível e desordenadamente elegante do que a solução empresarial típica de um banco de dados vetorial e pipeline RAG.
Em vez disso, ele descreve um sistema onde o próprio LLM atua como um “bibliotecário de pesquisa” em tempo integral – compilando, lintando e interligando ativamente arquivos Markdown (.md), o formato de dados compacto e mais amigável ao LLM.
Ao desviar uma parte significativa de seu “produto de token” para a manipulação de conhecimento estruturado, em vez de código padronizado, Karpathy apresentou um projeto para a próxima fase do “Segundo Cérebro” – que é autocurável, auditável e inteiramente legível por humanos.
Além do RAG
Nos últimos três anos, o paradigma dominante para dar aos LLMs acesso a dados proprietários tem sido Geração Aumentada de Recuperação (RAG).
Em uma configuração RAG padrão, os documentos são cortados em “pedaços” arbitrários, convertidos em vetores matemáticos (incorporação) e armazenados em um banco de dados especializado.
Quando um usuário faz uma pergunta, o sistema realiza uma “pesquisa de similaridade” para encontrar os pedaços mais relevantes e os alimenta na abordagem do LLM.Karpathy, que ele chama Bases de conhecimento LLMrejeita a complexidade dos bancos de dados vetoriais para conjuntos de dados de médio porte.
Em vez disso, depende da capacidade crescente do LLM de raciocinar sobre textos estruturados.
A arquitetura do sistema, conforme visualizada pelo usuário X @himanshu em parte das reações mais amplas à postagem de Karpathy, funciona em três estágios distintos:
-
Ingestão de dados: Matérias-primas – artigos de pesquisa, repositórios GitHub, conjuntos de dados e artigos da web – são despejados em um
raw/diretório. Karpathy utiliza o Obsidiana Web Clipper para converter conteúdo da web em Markdown (.md), garantindo que até mesmo as imagens sejam armazenadas localmente para que o LLM possa referenciá-las por meio de recursos de visão. -
A etapa de compilação: Esta é a inovação central. Em vez de apenas indexar os arquivos, o LLM os “compila”. Ele lê os dados brutos e escreve um wiki estruturado. Isso inclui a geração de resumos, a identificação de conceitos-chave, a autoria de artigos em estilo enciclopédico e, o que é crucial, a criação de backlinks entre ideias relacionadas.
-
Manutenção Ativa (Linting): O sistema não é estático. Karpathy descreve a execução de “verificações de integridade” ou passagens de “linting”, onde o LLM verifica o wiki em busca de inconsistências, dados ausentes ou novas conexões. Como membro da comunidade Charly Wargnier observou: “Ele atua como uma base viva de conhecimento de IA que realmente se cura.”
Ao tratar os arquivos Markdown como a “fonte da verdade”, Karpathy evita o problema da “caixa preta” da incorporação de vetores. Cada afirmação feita pela IA pode ser rastreada até um ponto específico .md arquivo que um ser humano pode ler, editar ou excluir.
Implicações para a empresa
Embora a configuração do Karpathy seja atualmente descrita como uma “coleção hackeada de scripts”, as implicações para a empresa são imediatas.
Como empresário Vamshi Reddy (@tammireddy) anotado em resposta ao anúncio: “Toda empresa tem um diretório raw/. Ninguém nunca o compilou. Esse é o produto.”
Karpathy concordou, sugerindo que esta metodologia representa uma categoria de “novo produto incrível”.
A maioria das empresas atualmente se “afoga” em dados não estruturados – registros do Slack, wikis internos e relatórios em PDF que ninguém tem tempo de sintetizar.
Uma camada empresarial do “estilo Karpathy” não pesquisaria apenas esses documentos; criaria ativamente uma “Bíblia da Empresa” que seria atualizada em tempo real.
Como educador de IA e autor de boletins informativos Ole Lehmann colocou no X: “Acho que quem empacota isso para pessoas normais está sentado em algo enorme. Um aplicativo que sincroniza com as ferramentas que você já usa, seus favoritos, seu aplicativo de leitura posterior, seu aplicativo de podcast, seus tópicos salvos.”
Eugen Alpeza, cofundador e CEO da construtora de agentes empresariais de IA e startup de orquestração Edra, observou em uma postagem X que: “O salto do wiki de pesquisa pessoal para as operações empresariais é onde tudo se torna brutal. Milhares de funcionários, milhões de registros, conhecimento tribal que se contradiz entre as equipes. Na verdade, há espaço para um novo produto e estamos construindo-o na empresa.”
À medida que a comunidade explora o “Padrão Karpathy”, o foco já está mudando da pesquisa pessoal para a orquestração multiagente.
Uma análise arquitetônica recente por @jumperzfundador da plataforma de criação de agentes de IA Segundo companheiroilustra essa evolução por meio de uma “Base de conhecimento Swarm” que dimensiona o fluxo de trabalho do wiki para um sistema de 10 agentes gerenciado via OpenClaw.
O principal desafio de um enxame multiagente – onde uma alucinação pode agravar e “infectar” a memória coletiva – é abordado aqui por um “Portão de Qualidade” dedicado.
Usando o modelo Hermes (treinado pela Nous Research para avaliação estruturada) como supervisor independente, cada rascunho do artigo é pontuado e validado antes de ser promovido para o wiki “ao vivo”.
Este sistema cria um “Loop Composto”: os agentes despejam as saídas brutas, o compilador as organiza, o Hermes valida a verdade e os briefings verificados são retornados aos agentes no início de cada sessão. Isso garante que o enxame nunca “acorde em branco”, mas em vez disso comece cada tarefa com um briefing filtrado e de alta integridade de tudo o que o coletivo aprendeu.
Dimensionamento e desempenho
Uma crítica comum às abordagens não vetoriais é a escalabilidade. No entanto, Karpathy observa que em uma escala de aproximadamente 100 artigos e aproximadamente 400.000 palavras, a capacidade do LLM de navegar por resumos e arquivos de índice é mais que suficiente.
Para um wiki departamental ou um projeto de pesquisa pessoal, a infraestrutura “RAG sofisticada” geralmente introduz mais latência e “ruído de recuperação” do que resolve.
Podcaster de tecnologia Lex Fridman (@lexfridman) confirmou que ele usa uma configuração semelhante, adicionando uma camada de visualização dinâmica:
“Muitas vezes faço com que ele gere HTML dinâmico (com js) que me permite classificar/filtrar dados e mexer nas visualizações de forma interativa. Outra coisa útil é fazer com que o sistema gere uma minibase de conhecimento focada temporariamente… que eu então carrego em um LLM para interação em modo de voz em uma longa corrida de 7 a 10 milhas.”
Este conceito de “wiki efêmero” sugere um futuro onde os usuários não apenas “conversam” com uma IA; eles geram uma equipe de agentes para construir um ambiente de pesquisa personalizado para uma tarefa específica, que então se dissolve assim que o relatório é escrito.
Licenciamento e a filosofia ‘file-over-app’
Tecnicamente, a metodologia de Karpathy é construída em um padrão aberto (Markdown), mas vista através de lentes proprietárias, mas extensíveis (aplicativo de anotações e organização de arquivos Obsidiana).
-
Remarcação (.md): Ao escolher o Markdown, Karpathy garante que sua base de conhecimento não fique restrita a um fornecedor específico. É à prova de futuro; se o Obsidian desaparecer, os arquivos permanecerão legíveis por qualquer editor de texto.
-
Obsidiana: Embora o Obsidian seja um aplicativo proprietário, sua filosofia “local-first” e seu EULA (que permite o uso pessoal gratuito e requer uma licença para uso comercial) se alinham com o desejo do desenvolvedor de soberania de dados.
-
As ferramentas “codificadas pelo Vibe”: Os mecanismos de pesquisa e ferramentas CLI mencionados por Karpathy são scripts personalizados – provavelmente baseados em Python – que preenchem a lacuna entre o LLM e o sistema de arquivos local.
Essa filosofia de “arquivo sobre aplicativo” é um desafio direto para modelos pesados de SaaS, como Notion ou Google Docs. No modelo Karpathy, o usuário é dono dos dados, e a IA é apenas um editor altamente sofisticado que “visita” os arquivos para realizar o trabalho.
Bibliotecário vs. mecanismo de pesquisa
A comunidade de IA reagiu com uma mistura de validação técnica e entusiasmo de “codificação de vibração”. O debate centra-se em saber se a indústria indexou excessivamente os bancos de dados vetoriais para problemas que são fundamentalmente relacionados à estrutura, e não apenas à similaridade.
Jason Paul Michaels (@SpaceWelder314), um soldador que usa Claude, expressou o sentimento de que ferramentas mais simples são muitas vezes mais robustas:
“Sem banco de dados de vetores. Sem incorporações… Apenas markdown, FTS5 e grep… Cada correção de bug… é indexada. O conhecimento é composto.”
No entanto, os elogios mais significativos vieram de Steph Ango (@Kepano), cocriador da Obsidian, que destacou um conceito chamado “Mitigação de Contaminação”.
Ele sugeriu que os usuários deveriam manter seu “cofre” pessoal limpo e deixar os agentes brincarem em um “cofre bagunçado”, trazendo apenas os artefatos úteis depois que o fluxo de trabalho voltado para o agente os tiver destilado.
Qual solução é a certa para seus projetos empresariais de codificação vibe?
|
Recurso |
Vetor DB / RAG |
Wiki Markdown de Karpathy |
|
Formato de dados |
Vetores opacos (matemática) |
Markdown legível por humanos |
|
Lógica |
Similaridade semântica (vizinho mais próximo) |
Conexões explícitas (backlinks/índices) |
|
Auditabilidade |
Baixo (caixa preta) |
Alto (rastreabilidade direta) |
|
Composição |
Estático (requer reindexação) |
Ativo (autocura por meio de fiapos) |
|
Escala Ideal |
Milhões de documentos |
100 – 10.000 documentos de alto sinal |
A abordagem “Vector DB” é como um armazém enorme e desorganizado com um motorista de empilhadeira muito rápido. Você pode encontrar qualquer coisa, mas não sabe por que está ali ou como se relaciona com o palete próximo a ele. O “Markdown Wiki” de Karpathy é como uma biblioteca com curadoria com um bibliotecário-chefe que está constantemente escrevendo novos livros para explicar os antigos.
A próxima fase
A exploração final de Karpathy aponta para o destino final desses dados: Geração de Dados Sintéticos e Ajuste Fino.
À medida que o wiki cresce e os dados se tornam mais “puros” através do linting contínuo do LLM, ele se torna o conjunto de treinamento perfeito.
Em vez de o LLM apenas ler o wiki em sua “janela de contexto”, o usuário pode eventualmente ajustar um modelo menor e mais eficiente no próprio wiki. Isto permitiria ao LLM “conhecer” a base de conhecimento pessoal do pesquisador em seus próprios pesos, essencialmente transformando um projeto de pesquisa pessoal em uma inteligência privada e personalizada.
Resumindo: Karpathy não apenas compartilhou um roteiro; ele compartilhou uma filosofia. Ao tratar o LLM como um agente ativo que mantém sua própria memória, ele contornou as limitações das interações de IA “únicas”.
Para o pesquisador individual, significa o fim do “marcador esquecido”.
Para a empresa, significa a transição de um “lago de dados brutos” para um “ativo de conhecimento compilado”. Como o próprio Karpathy resumiu: “Raramente você escreve ou edita o wiki manualmente; é o domínio do LLM.” Estamos entrando na era do arquivo autônomo.












