A abordagem de "LLM Wiki" popularizada por Karpathy pode reduzir o uso de tokens em até 95% para bases de conhecimento pequenas. Veja como ela se compara ao RAG tradicional e quando usar cada uma.

---

O Problema de Usar RAG Para Tudo

Retrieval-Augmented Generation (RAG) se tornou a resposta padrão para qualquer pergunta do tipo "como eu dou acesso a conhecimento para minha IA?". Precisa que seu chatbot conheça seu produto? RAG. Precisa que seu agente consulte documentos internos? RAG. Mas RAG traz custos reais — complexidade de infraestrutura, falhas de recuperação, dores de cabeça com chunking e manutenção contínua — e, para muitos casos de uso, existe uma abordagem mais simples que funciona tão bem ou melhor.

Essa abordagem é a LLM Wiki: uma base de conhecimento estruturada em markdown, projetada para viver diretamente na janela de contexto do LLM.

---

O Que É uma LLM Wiki?

Uma LLM Wiki é um conjunto de documentos markdown escritos especificamente para serem lidos por um modelo de linguagem, não por humanos navegando em um site. A ideia central: ao invés de construir um pipeline de recuperação para buscar informações relevantes em tempo de consulta, você escreve um documento compacto e bem organizado que cobre tudo que o LLM precisa saber. Esse documento é carregado diretamente no contexto como parte do system prompt.

Propriedades de uma Boa LLM Wiki

• Concisa e completa — Sem enrolação, sem repetição. Cada frase justifica seu lugar.

• Bem estruturada — Títulos claros, formatação consistente, hierarquia lógica.

• Factual e específica — Definições, exemplos, relações entre conceitos.

• Curada — Inclui deliberadamente o que importa e exclui o que não importa.

• Atualizável — Mantida como um documento vivo.

Um arquivo markdown de ~2.000 palavras cobrindo o modelo de preços do seu produto, casos especiais e perguntas frequentes pode ser tudo que você precisa. Sem embeddings, sem banco vetorial, sem lógica de recuperação.

Por Que Funciona?

Modelos modernos têm janelas de contexto enormes. O Claude suporta 200K tokens, GPT-4o suporta 128K, Gemini 1.5 Pro vai ainda além. Para a maioria das bases de conhecimento pequenas a médias, tudo cabe no contexto. E quando cabe, você não precisa buscar nada — o LLM lê tudo e raciocina diretamente sobre o conteúdo. Isso é mais confiável do que depender de similaridade de embeddings para encontrar os trechos certos.

---

Como o RAG Tradicional Funciona

RAG adiciona uma fonte de conhecimento externa ao LLM, recuperando informações relevantes no momento da consulta.

flowchart LR
    A["📄 Documentos"] --> B["✂️ Chunking"]
    B --> C["🧮 Embedding"]
    C --> D["🗄️ Banco Vetorial"]
    E["❓ Pergunta do Usuário"] --> F["🧮 Embedding da Query"]
    F --> G["🔍 Busca por Similaridade"]
    D --> G
    G --> H["📋 Chunks Recuperados"]
    H --> I["🤖 LLM + Contexto"]
    E --> I
    I --> J["💬 Resposta"]

O pipeline típico:

1. Ingestão — Documentos são divididos em chunks (geralmente 256–1.024 tokens cada).

2. Embedding — Cada chunk é convertido em um vetor usando um modelo de embedding.

3. Armazenamento — Vetores são armazenados em um banco vetorial (Pinecone, Weaviate, Chroma, pgvector, etc.).

4. Consulta — Em runtime, a query do usuário é vetorizada e o banco retorna os chunks mais similares.

5. Injeção — Chunks recuperados são injetados no contexto do LLM junto com a pergunta.

6. Geração — O LLM gera uma resposta baseada no contexto recuperado.

---

Onde o RAG Acerta

• Escala — Quando sua base tem milhões de documentos, não cabe no contexto. RAG permite consultar apenas o relevante.

• Atualizações em tempo real — Você pode atualizar o banco vetorial sem mudar seus prompts.

• Atribuição de fonte — RAG suporta citações naturalmente, já que você sabe exatamente quais chunks foram recuperados.

• Cobertura de cauda longa — Para bases amplas com tópicos diversos, a recuperação pode trazer conteúdo de nicho imprevisível.

Onde o RAG Erra

• Problemas de chunking — Dividir documentos nos pontos errados quebra o contexto. Um chunk que diz "a taxa é R$25" sem explicar qual taxa é praticamente inútil.

• Falhas de recuperação silenciosas — Similaridade de embedding ≠ relevância semântica. Uma query sobre "política de cancelamento" pode não recuperar o chunk que fala sobre "encerrar sua assinatura".

• Overhead de recuperação — Cada query exige uma chamada de embedding + busca vetorial. Em alto volume, isso adiciona latência e custo.

• Complexidade de infraestrutura — Você agora mantém um pipeline de embedding, um banco vetorial, lógica de chunking e tuning de recuperação.

• Índices desatualizados — Se os documentos mudam mas o índice não, sua IA dá respostas erradas com confiança.

---

Comparação Direta

---

Quando Usar LLM Wiki

Sua base cabe no contexto

Se toda a sua base de conhecimento tem menos de 50.000–100.000 tokens, não há razão técnica para usar RAG. Uma wiki de 50K tokens equivale a ~150–200 páginas de texto denso. A maioria do conhecimento de domínio real cabe nesse limite quando é devidamente curado.

Você precisa de alta confiabilidade

Se seu caso de uso não tolera falhas de recuperação — bots de suporte ao cliente, ferramentas jurídicas, assistentes de informação médica — a LLM Wiki é mais confiável. Tudo está no contexto; o modelo raciocina sobre o quadro completo.

Seu conhecimento é estável

Se a base não muda frequentemente, um arquivo markdown é fácil de manter. Você edita o documento e a próxima consulta automaticamente usa a versão atualizada. Sem re-indexação.

Você quer entregar rápido

RAG exige infraestrutura. Uma LLM Wiki é um arquivo markdown. Você pode construir e testar em uma tarde.

---

Quando Usar RAG

Sua base é grande

Milhares de documentos, bases legais extensas, catálogos grandes de produtos, ou qualquer base que chegue a milhões de tokens — você precisa de recuperação.

Conteúdo muda frequentemente

Informações de estoque, feeds de notícias, preços em tempo real — um sistema de recuperação com atualização incremental é a arquitetura certa.

Você precisa de atribuição de fonte

RAG torna citações diretas. Quando você recupera um chunk, sabe o documento de origem, página e URL.

Sistemas multi-domínio

Um único índice RAG pode cobrir muitos domínios diferentes. Uma LLM Wiki funciona melhor quando o conhecimento é coerente e focado.

---

A Matemática dos Tokens

A alegação de que uma LLM Wiki pode cortar o uso de tokens em 95% merece contexto:

Comparando com carregamento ingênuo de documentos

Muitos times começam carregando documentos inteiros — PDFs completos, manuais — diretamente no contexto. Um único documento de política pode ter 20.000 tokens. Carregue três e você está em 60.000 tokens por query. Uma wiki curada cobrindo o mesmo conteúdo factual pode ter 2.000–3.000 tokens. Daí vem a redução de 95%.

Comparando com RAG otimizado

Contra um RAG bem ajustado, a comparação é mais sutil:

xychart-beta
    title "Custo de Tokens por Query (comparativo)"
    x-axis ["Docs Brutos", "LLM Wiki (pequena)", "RAG Otimizado", "LLM Wiki (grande)"]
    y-axis "Tokens por Query" 0 --> 65000
    bar [60000, 3000, 4000, 30000]

O ponto de equilíbrio depende do tamanho da sua wiki e das configurações do seu RAG. Para bases pequenas, a LLM Wiki é competitiva ou mais barata. Para bases grandes, RAG vence em economia de tokens.

---

Abordagem Híbrida: O Melhor dos Dois Mundos

Na prática, muitos sistemas em produção usam ambos:

flowchart TB
    subgraph SystemPrompt["System Prompt (sempre disponível)"]
        W["📝 LLM Wiki<br>Conhecimento estável e curado:<br>• Visão geral do produto<br>• Políticas centrais<br>• Instruções de persona"]
    end

    subgraph RAGLayer["Camada RAG (sob demanda)"]
        R["🔍 Recuperação Dinâmica:<br>• Histórico de transações<br>• Registros específicos do usuário<br>• Grandes bases de referência"]
    end

    Q["❓ Query do Usuário"] --> LLM["🤖 LLM"]
    SystemPrompt --> LLM
    Q --> RAGLayer
    RAGLayer --> LLM
    LLM --> A["💬 Resposta"]

A wiki lida com o conhecimento fundamental que deve estar sempre disponível. O RAG lida com conteúdo de cauda longa, alto volume ou que muda frequentemente.

---

Minhas Considerações Pessoais

Depois de ler o artigo original e refletir sobre a prática, quero adicionar alguns pontos que considero importantes:

1. LLM Wiki é subestimada por causa do hype de RAG

O ecossistema de IA criou uma cultura onde "RAG" virou sinônimo de "sério" e "produção". Muitos times pulam direto para arquiteturas complexas sem antes perguntar: "meu caso de uso realmente precisa disso?". Na minha experiência, uma quantidade surpreendente de projetos poderia funcionar perfeitamente com um markdown bem escrito no system prompt.

2. A qualidade da curadoria é tudo

Uma LLM Wiki mal escrita é tão ruim quanto um RAG mal configurado. O diferencial não é a técnica, é a qualidade da informação. Se você joga um documento de 50 páginas sem curadoria no contexto, não está usando uma "LLM Wiki", está fazendo context stuffing.

3. O futuro provavelmente torna a LLM Wiki ainda mais viável

Com janelas de contexto crescendo (Gemini já suporta 1M+ tokens) e os custos de tokens caindo, a faixa de casos onde a LLM Wiki é viável só tende a crescer. O RAG continuará essencial para escala, mas o limiar onde ele se torna necessário está se movendo.

4. GraphRAG e bases de conhecimento estruturadas

Uma evolução interessante que o artigo não menciona é o GraphRAG, onde ao invés de chunks soltos em um banco vetorial, você constrói um grafo de conhecimento com relações explícitas entre entidades. Isso resolve vários problemas de chunking e contexto que afetam o RAG tradicional.

Referências e Links

• Artigo original — MindStudio: LLM Wiki vs RAG

• Andrej Karpathy — LLM Wiki concept (X/Twitter)

• O que é RAG? — MindStudio

• Pinecone — What is RAG?

• LangChain — RAG Tutorial

• Microsoft — GraphRAG

• Anthropic — Claude Context Window

• Chunking Strategies for RAG — Pinecone