A equipa fundadora da OpenAI e antiga diretora-geral de IA da Tesla, Andrej Karpathy, publicou no X o trabalho “LLM Knowledge Bases”, detalhando um fluxo de trabalho que explica como, recentemente, aumentou o uso massivo de tokens ao passar de “manipular código” para “manipular conhecimento”: usar LLM para transformar papers, artigos, pastas, imagens dispersas num wiki pessoal auto-assegurado. Todo o processo foi acumulado nos seus próprios projetos de investigação, com ~100 artigos, ~400 mil palavras, e todo o conteúdo foi escrito e atualizado ao longo do tempo por LLM. Este artigo reúne o setup completo de Karpathy, deixando uma lista de verificação executável para os programadores que queiram replicar.
Ideia central: dados brutos → compilação em LLM → wiki → Q&A
A filosofia de design de Karpathy pode resumir-se a uma frase: “raw data entra, LLM compila em wiki, wiki é usada para pesquisa pelo LLM, e os resultados da pesquisa voltam a ser escritos no wiki”. A chave de todo o sistema é retirar o papel humano de “fazer anotações” e passar a “vigiar as anotações que o LLM está a escrever”. A knowledge base deixa de ser algo mantido manualmente, como Notion ou Roam Research, passando a ser um conjunto de ficheiros markdown escritos e mantidos automaticamente por LLM.
Ele descreve que edita o wiki muito raramente — a escrita, o acrescentar de ligações, a extração de estrutura, a verificação de consistência, tudo é feito por LLM. Este modelo “LLM a liderar o conteúdo, humano a vigiar”, contrasta totalmente com o hábito da maioria de escrever manualmente no Obsidian/Notion e é a mudança central deste fluxo de trabalho.
Passo 1: Data Ingest — deitar todos os dados brutos numa pasta raw/
A entrada de Karpathy é simples: criar uma pasta raw/ e despejar lá dentro todos os dados de origem — PDFs de papers, artigos de notícias, repositórios de código, conjuntos de dados, imagens, transcrições de palestras. O LLM usa esta pasta como entrada e vai “compilando” um wiki.
Ele menciona especialmente duas ferramentas:
A extensão Obsidian Web Clipper — converter artigos de páginas web diretamente para ficheiros .md e guardá-los em raw/
Hotkey personalizado — descarregar imagens relevantes das páginas para o computador, para o LLM conseguir lê-las diretamente quando fizer referência mais tarde
Design-chave: todo o conteúdo externo fica guardado em formato “offline, local”, garantindo que, quando o LLM fizer pesquisa mais tarde, não fique bloqueado com o problema de “não encontrar as ligações originais”.
Passo 2: Compilar wiki com LLM — gerar automaticamente categorias, artigos e ligações de retorno
Com raw/ pronto, Karpathy “compila” incrementamente um wiki com LLM — uma estrutura de diretórios feita de uma série de ficheiros .md. O LLM faz quatro coisas:
Escrever resumos de todos os materiais dentro de raw/
Classificar os dados em conceitos
Escrever um artigo para cada conceito
Criar ligações de retorno (backlinks) entre os artigos
Este processo é “incremental” — os novos dados em raw/ fazem o LLM atualizar apenas as secções do wiki afetadas, sem ser necessário recompilar tudo de uma vez. Para temas de investigação acumulados a longo prazo (o wiki de investigação de Karpathy já tem ~100 artigos, ~400 mil palavras), esta atualização incremental é muito mais útil do que uma recompilação grande feita uma única vez.
Passo 3: Usar Obsidian como “front-end” IDE e expandir com Marp, entre outros plugins
Karpathy usa Obsidian como front-end visual do sistema — permitindo ver simultaneamente raw/, o wiki compilado e visualizações derivadas (slides, gráficos). A vantagem do Obsidian é que ele próprio é um editor de markdown, é naturalmente compatível com os ficheiros .md que o LLM escreve e também suporta extensões via plugins.
Ele menciona especialmente o plugin Marp — que permite renderizar markdown diretamente em formato de apresentações, para que o LLM não consiga apenas produzir texto, mas também produzir apresentações.
Passo 4: Q&A — transformar o wiki inteiro no objeto de pesquisa do LLM
Quando o wiki de Karpathy atinge uma escala de “~100 artigos, ~400 mil palavras”, surgem as capacidades mais interessantes: é possível fazer ao agente de LLM qualquer pergunta complexa, e ele vai sozinho investigar a resposta, citando os parágrafos relevantes no wiki.
Inicialmente, ele esperava precisar de “RAG sofisticado” (busca vetorial, modelos de embeddings, re-ranking, etc.) para funcionar a esta escala, mas na prática verificou o seguinte: o LLM mantém um ficheiro de index e pequenos resumos de cada artigo; na pesquisa, basta usar estes index e resumos para encontrar os parágrafos relevantes. Neste patamar de “~400 mil palavras”, nem um RAG complexo é necessário — funciona bastante bem.
Esta observação está alinhada com o consenso da indústria desde 2024 de que “a moda das vector DB arrefeceu; em muitos cenários nem precisa”. Quando a knowledge base está abaixo de milhões de palavras e o markdown estruturado + index sob controlo do LLM já chegam, é suficiente.
Passo 5: Saída — não é apenas texto puro, mas markdown/slides/gráficos
A outra decisão de design de Karpathy: ele não quer que o LLM responda apenas com texto no terminal; quer que o LLM produza saídas estruturadas — ficheiros markdown, apresentações Marp, gráficos matplotlib e dados para visualização. Estas saídas podem ser consultadas dentro do Obsidian.
Mais importante ainda é o ciclo: muitas vezes os resultados produzidos são “arquivados” por Karpathy de volta no wiki, reforçando assim as pesquisas futuras. Ele descreve que “a exploração e a pesquisa se vão sempre somando (add up) à knowledge base” — ou seja, um sistema com estado, que cresce, e que contrasta com o modo do ChatGPT, onde cada conversa “recomeça do zero”.
Passo 6: Linting — o LLM faz auto-check de saúde, encontra problemas de consistência e candidatos a novos artigos
Para o wiki, Karpathy faz o LLM correr uma “saúde” — lidando com três tipos de problemas:
Identificar inconsistências de dados (descrições em conflito do mesmo conceito em artigos diferentes)
Usar pesquisa na web para preencher dados em falta
Encontrar ligações interessantes entre conceitos e recomendar candidatos a novos artigos
Este passo de linting é a chave para o wiki ir ficando “cada vez mais limpo” com o tempo — sem isso, o wiki compilado automaticamente vai acumulando contradições e ruído. O LLM mostra bom desempenho nesta tarefa, sendo uma das razões pelas quais Karpathy acredita que este fluxo de trabalho pode ser mantido a longo prazo.
Passo 7: Ferramentas extra feitas à medida — por exemplo, construir um motor de pesquisa para o wiki
Karpathy referiu que “codificou por vibe” um motor de pesquisa pequeno, a correr no próprio wiki. Esta ferramenta tem dois usos: (1) ele usa o web UI diretamente; (2) mais comum, é ligar o motor de pesquisa via interface CLI, entregá-lo ao LLM como ferramenta e permitir que o LLM, em pesquisas grandes, acerte com precisão os parágrafos relevantes.
Este padrão (o humano montar um CLI, o LLM usá-lo como ferramenta) é o desenho central em frameworks de agentes como o Claude Code e o OpenAI Codex: o LLM não lê diretamente todo o conteúdo, antes obtém o subconjunto necessário através de ferramentas (CLI, motor de pesquisa, sistema de ficheiros).
Passo 8: Direções futuras — geração de dados sintéticos e afinação (fine-tuning) do modelo
Quando o wiki tiver uma dimensão suficiente, Karpathy propõe duas direções avançadas:
Usar o wiki para gerar dados sintéticos — fazer com que o LLM produza automaticamente pares Q&A, artigos de ensino e exemplos para certos temas
Fazer fine-tuning de um LLM especializado com dados sintéticos — para o seu LLM pessoal “saber” estes dados dentro dos pesos, em vez de só os ler no context window
Esta direção leva a knowledge base de “memória externa” para “memória interna”, sendo o próximo passo da IA personalizada. Mas Karpathy também reconhece que isto exige mais infraestrutura e, por agora, continua a ser uma fase de exploração.
A ideia de “Idea File” de Karpathy: partilhar a ideia, não partilhar o código
Depois do post ter ficado viral, Karpathy avançou com um novo conceito nos posts seguintes: “idea file”. Na era dos agentes de LLM, em vez de partilhar código concreto, mais vale partilhar “ideias”, para que o agente personalize e construa algo por si.
Ele colocou o “idea file” deste sistema de LLM Knowledge Bases num GitHub gist, mantendo-o propositadamente abstrato e deixando espaço para os agentes de cada pessoa se manifestarem livremente. Isto pode vir a ser um novo modelo de partilha para a comunidade dev: não um repositório no GitHub, nem um pacote npm, mas sim “documentos de instruções”, especificações abertas pensadas para LLM.
Sugestão de implementação: como começar para leitores de Taiwan
Para programadores de Taiwan que queiram replicar este sistema, um caminho de entrada prático:
O Obsidian é gratuito, funciona em macOS/Windows/Linux e pode ser descarregado do site oficial
A extensão Web Clipper pode ser instalada na Chrome/Firefox/Edge
No lado do LLM, pode escolher Claude Code (CLI), ChatGPT (API) ou Ollama local (se tiver um GPU com boa performance)
Recomenda-se colocar as duas pastas raw/ e wiki/ ao lado do Obsidian vault, e adicionar controlo de versão além de .gitignore (para, caso o LLM escreva algo mal, ainda conseguir recuperar)
Começar com um tema de investigação que conheça bem — por exemplo, “dinâmica de conformidade de bolsas cripto em 2026”, “arquitetura de inferência de LLM”. Depois de acumular 30–50 artigos, a capacidade de Q&A melhora de forma clara
No fim do post, Karpathy diz: “Há espaço para construir um produto novo e excelente, e não este formato de scripts grosseiros e colagem.” Para quem constrói (builder), esta thread é tanto uma explicação do fluxo de trabalho como matéria para uma ideia de negócio — LLM wiki automática, um mercado que ainda não tem um vencedor de produto claramente definido.
Este artigo, em que Karpathy revela pessoalmente o método completo para construir uma base de conhecimento pessoal com LLM, apareceu pela primeira vez em 鏈新聞 ABMedia.
