Do LLM Wiki do Karpathy a um Segundo Cérebro de verdade: minha implementação com o Amazon Quick Desktop

Dima Kramskoy — Senior Cloud Architect na DoiT International Mais de 20 anos em engenharia de software · 10 certificações AWS · AWS Community Builder 2026 · Alumni do Architect Master Class do Juval Löwy (2022)

O problema: toda conversa começa do zero

Esse é o antipadrão que me tira do sério: você tem uma conversa profunda de 45 minutos com um assistente de IA sobre suas decisões de arquitetura, trade-offs e restrições. Fecha a aba. No dia seguinte, abre um novo chat. Ele não sabe de nada. Você está de volta no onboarding.

Agora multiplique isso por toda a sua superfície de conhecimento: threads do Slack com contexto que nunca mais vai ser pesquisável, correntes de e-mail em que decisões ficaram enterradas na resposta nº 14, documentos que existem em três versões espalhadas por dois drives, e o conhecimento tribal que mora exclusivamente na cabeça das pessoas.

Ninguém faria o onboarding do próprio substituto só com o histórico do Slack. Mas é basicamente isso que estamos fazendo com nossas ferramentas de IA — entregando fragmentos e esperando coerência.

O problema central não é inteligência. GPT-4, Claude, Gemini — são todos brilhantes. O problema é amnésia. Toda sessão é um cold start. Seu contexto está espalhado por uma dúzia de ferramentas, e nenhuma delas conversa entre si por meio de um modelo unificado de você e do seu trabalho.

Faz meses que venho pensando nisso. Aí o Karpathy postou um tweet que cristalizou a solução.

A inspiração do Karpathy: RAG recupera, um wiki acumula

Em abril de 2026, Andrej Karpathy postou sobre "o LLM Wiki" no X — 17 milhões de visualizações e contando. O insight central caiu como um design pattern se encaixando na cabeça:

"RAG recupera. Um wiki acumula."

O framework dele é elegante. Três camadas:

1. Fontes brutas — artigos, papers, tweets, conversas, notas
2. Wiki — páginas de conhecimento destiladas, estruturadas e interconectadas
3. Schema — a ontologia que governa como o conhecimento é organizado

A analogia que ele usa é perfeita: "O Obsidian é a IDE. O LLM é o programador. O wiki é o codebase."

O Matt Paige escreveu uma análise excelente do conceito. A virada-chave: em vez de jogar documentos brutos num vector database e torcer para a recuperação achar o chunk certo, você constrói uma base de conhecimento viva e estruturada que o LLM mantém e enriquece com o tempo.

RAG é uma consulta. Um wiki é um sistema. Um é O(1) por query. O outro acumula.

Mas tem uma coisa que me incomodou na versão do Karpathy: ela é manual. Você é o operador. Você prompta, revisa, cola, organiza. O LLM ajuda, mas quem conduz é você. Eu queria algo diferente — um assistente que fizesse isso por mim, não um sistema que eu tivesse que manter.

Por que o Amazon Quick Desktop

Quando avaliei ferramentas para essa implementação, eu tinha um checklist tirado direto da arquitetura do Karpathy:

• ✅ Memória de longo prazo que persiste entre conversas
• ✅ Grafo de conhecimento (extrai automaticamente entidades e relações do Slack, e-mail, calendário)
• ✅ Busca semântica em arquivos locais
• ✅ Acesso de leitura/escrita ao meu filesystem
• ✅ Tarefas em background (pesquisa enquanto trabalho em outras coisas)
• ✅ Ferramentas conectadas (Gmail, Slack, Google Calendar, servidores MCP)
• ✅ Camada de ação (consegue rascunhar e-mails, criar docs, marcar reuniões)

O Amazon Quick Desktop já tinha o que o Karpathy descreve — só que embutido e conectado a ferramentas reais de trabalho. Não é uma janela de chat. É um runtime.

Comparação rápida:

A decisão-chave: eu queria um assistente que acumulasse conhecimento POR mim, não um sistema que eu mesmo tivesse que manter. O custo de manutenção de um wiki manual mata a adoção. Já vi isso umas doze vezes.

O que eu construí (em 1 semana)

Estrutura de pastas

~/SecondBrain/
├── raw/                          # Entradas não processadas
│   ├── articles/
│   ├── transcripts/
│   └── captures/
├── wiki/                         # Conhecimento destilado
│   ├── concepts/                 # Modelos mentais, frameworks
│   │   ├── second-brain-architecture.md
│   │   ├── rag-vs-wiki-pattern.md
│   │   └── approval-workflow-pattern.md
│   ├── entities/                 # Pessoas, organizações, ferramentas
│   │   ├── doit-international.md
│   │   └── amazon-quick.md
│   ├── projects/                 # Trabalho em andamento
│   │   ├── genai-skill-share-talk.md
│   │   └── voice-capture-pipeline.md
│   ├── sources/                  # Referências indexadas
│   │   └── karpathy-llm-wiki.md
│   └── log/                      # Acompanhamento diário
│       ├── 2026-05-19.md
│       ├── 2026-05-20.md
│       └── ...
├── SCHEMA.md                     # A ontologia
└── mkdocs.yml                    # Documentação servida automaticamente

SCHEMA.md (trecho)

# SecondBrain Schema v1.0

## Tipos de página
- **concept**: um modelo mental, padrão ou framework. Deve incluir: definição, quando usar, antipadrões, conceitos relacionados.
- **entity**: uma pessoa, organização ou ferramenta. Deve incluir: papel/propósito, relação com meu trabalho, data da última interação.
- **project**: trabalho em andamento ou concluído. Deve incluir: status, stakeholders, registro de decisões, próximas ações.
- **source**: um artigo/palestra/paper ingerido. Deve incluir: URL, principais insights (no máximo 5), conexão com conceitos existentes.
- **log**: entrada diária. Gerada automaticamente. Acompanha: páginas criadas, páginas atualizadas, perguntas respondidas, ações executadas.

## Convenção de nomes
kebab-case. Sem datas nos nomes dos arquivos (use frontmatter).

## Regras de cross-reference
Toda página nova DEVE linkar para pelo menos 1 página existente. Páginas órfãs são sinal de problema.

A stack

• MkDocs + tema Material — serve o wiki localmente em localhost:8000
• launchd plist — inicia o MkDocs no login (macOS). Atrito zero para navegar.
• Amazon Quick — lê/escreve no wiki, propõe atualizações, responde perguntas com base nele
• Indexação semântica — o Quick indexa ~/SecondBrain/ e busca contextualmente

O fluxo de aprovação

Isso é crítico. Nada é escrito sem meu OK. O fluxo:

1. Eu digo "ingere esse artigo" ou compartilho um link
2. O Quick lê, propõe uma nova página de wiki (ou atualizações em páginas existentes)
3. Eu vejo o diff — conteúdo novo destacado, cross-references à mostra
4. Aprovo, edito ou rejeito
5. O conteúdo aprovado é gravado em disco, e o MkDocs atualiza automaticamente

Mais de 15 páginas de wiki na primeira semana. Não foi na marra — foi a partir de conversas que eu já estava tendo.

Um dia na vida

De manhã:

"Bom dia"

O Quick responde com: e-mails prioritários (sinalizados ou de pessoas-chave), threads do Slack que precisam da minha resposta, agenda do dia com anotações de preparo para as reuniões. Não é uma enxurrada — é um briefing.

Durante o dia:

"Ingere isso: [link para um post sobre arquitetura]"

O Quick lê, identifica 3 conceitos-chave, propõe uma nova página em sources/ e atualizações em duas páginas existentes em concepts/. Passo o olho no diff, aprovo, pronto. 90 segundos.

"Rascunha um post de blog sobre a implementação do Segundo Cérebro"

Ele puxa das minhas páginas de wiki, conhece minha voz (pela memória de textos anteriores) e estrutura no formato que eu prefiro. Eu edito, não escrevo do zero.

"Bloqueia 2 horas para deep work no voice capture pipeline amanhã"

Ele olha minha agenda, acha um slot, agenda e adiciona anotações de preparo a partir da página projects/voice-capture-pipeline.md.

Em background:

Enquanto estou em reuniões, tarefas em background pesquisam tópicos que enfileirei antes. Quando volto: "Achei 3 papers relevantes sobre manutenção de grafo de conhecimento. Quer que eu ingira?"

O efeito composto é real. No quinto dia, ele já respondia perguntas sintetizando informações de várias páginas de wiki que eu nem lembrava ter aprovado.

A extensão de captura por voz (PoC)

As melhores ideias vêm quando estou caminhando, não na mesa. Então construí um pipeline:

Arquitetura

iPhone Shortcuts (ou o wearable Plaud NotePin)
    → API Gateway (REST)
        → Lambda (handler de upload)
            → S3 (bucket de áudio)
                → Evento S3 → Lambda (gatilho de transcrição)
                    → AWS Transcribe
                        → Lambda (pós-processamento)
                            → Amazon Quick Knowledge Base
                                → Página de wiki proposta

Como funciona

1. Eu toco num Shortcut no iPhone (ou o NotePin grava o ambiente)
2. O áudio sobe pro S3 via API Gateway + Lambda
3. O evento do S3 dispara a transcrição via AWS Transcribe
4. A transcrição é limpa, dividida em chunks e enviada para a knowledge base do Quick
5. Na próxima vez que eu abrir o Quick: "Você fez uma captura de voz sobre [tópico]. Quer que eu crie uma página de wiki?"

Custo total na AWS: frações de centavo por captura. As funções Lambda são triviais — 50 linhas cada. O valor está em fechar o loop: pensamento → captura → conhecimento estruturado → ação.

Avaliação honesta: 7/10

O que está funcionando

• Estrutura — o schema impõe consistência. As páginas são fáceis de achar e úteis.
• Acúmulo — as respostas da semana 2 são visivelmente melhores que as da semana 1. Ele sabe das coisas.
• Ferramentas conectadas — o contexto do Slack enriquece as páginas do wiki. A consciência do calendário viabiliza agendamentos de verdade.
• Camada de ação — ele não só sabe das coisas; ele faz as coisas. Rascunhos, slides, agendamentos.
• Busca semântica — "O que eu decidi sobre X?" realmente funciona no wiki inteiro.

O que ainda precisa de trabalho

• Cross-referencing — ainda não é totalmente automático. Algumas páginas seguem com poucos links.
• Health checks — não implementei auditorias agendadas para páginas obsoletas/órfãs.
• Ingestão agendada — sem cron para "checar esses 5 RSS feeds diariamente." Ainda é gatilho manual.
• Detecção de contradição — não testada. O que acontece quando uma informação nova conflita com páginas existentes do wiki?

O que fizemos MELHOR do que a visão original do Karpathy

A visão dele é o blueprint. Mas é read-only — arquivos que você consulta. A minha produz: rascunha e-mails, cria slides, marca reuniões, escreve posts de blog. O wiki não é só uma referência; é uma fonte de ação.

Como você pode começar (5 passos)

Você não precisa do meu setup completo para tirar valor disso. Veja a gradação:

Os 5 passos

1. Conecte suas ferramentas — Slack, Gmail, Calendar, uma pasta local. São 10 minutos em Configurações.
2. Comece a conversar — a memória acumula desde o Dia 1. Toda conversa ensina algo sobre você.
3. Diga "lembre disso" depois de conversas importantes — âncoras explícitas de memória.
4. Crie ~/SecondBrain/ + SCHEMA.md — se quiser ir mais fundo, dê estrutura a isso.
5. Faça uma pergunta que atravesse tudo — "Quais foram minhas decisões-chave da semana passada?" Pronto, você fica viciado.

Três níveis de comprometimento

Comece no 🟢. Sério. O acúmulo acontece quer você construa infraestrutura, quer não. A estrutura do wiki só torna isso visível e auditável.

Conclusão

Sua IA não deveria começar do zero a cada conversa.

As ferramentas existem. O padrão está provado. O Karpathy mostrou a arquitetura; o Amazon Quick oferece o runtime. O abismo entre "assistente de IA" e "segundo cérebro" é só estrutura + persistência + ferramentas conectadas.

Acumular > Recuperar. Toda conversa, todo artigo ingerido, toda página de wiki aprovada deixa a próxima interação mais inteligente. Isso não é recuperação — é crescimento.

Comece pequeno. Vai acumular. É esse o ponto.

Uma última reflexão — e essa vem do Jocko Willink, não da pesquisa em IA: Extreme Ownership aplicado ao conhecimento. Se uma informação está no seu mundo — uma thread do Slack, uma palestra meio esquecida, uma ideia numa caminhada matinal — e você não captura, ela não é sua. Ela é dona de você, ficando indisponível justo na hora em que você mais precisa.

Capture. Estruture. Deixe acumular.

Esse post foi rascunhado com a ajuda do meu Segundo Cérebro — puxando das páginas de wiki que construí na semana anterior. A ironia não me escapa. É justamente esse o ponto.

Apresentado no GenAI Community Skill Share da DoiT em 22/05/2026. Obrigado aos ~27 colegas que fizeram perguntas afiadas e empurraram o raciocínio adiante.