InfoForge: Wikipedia offline como fonte RAG para meus agentes de IA locais
- Categoria
- IA e LLM Local
- Publicado em
- 28 agosto 2026
- Por
- Jacob Lloyd — escrito com ajuda de IA, depois do projeto
- Tempo de leitura
- 11 min de leitura
Em termos simples: O InfoForge é uma cópia de toda a Wikipédia em inglês armazenada num computador na minha casa, mais um pequeno programa que permite aos assistentes de IA que uso consultá-la. Ao fazer uma pergunta, o assistente não responde com base apenas na memória; ele busca nos artigos, lê os relevantes e escreve uma resposta mencionando quais foram as fontes. Se nada for encontrado, ele avisa claramente que "não conseguiu encontrar" em vez de inventar algo. Nada é enviado para empresas, ninguém registra as perguntas, e o sistema continua funcionando mesmo sem internet.
Perguntei a um modelo local de 8B quem escreveu Kokoro e quando foi publicado. Ele respondeu “Natsume Sōseki, 1914”, e depois fez o que realmente me interessava: citou o artigo da Wikipedia no qual encontrou essa informação. O modelo, por si só, não conhecia esse fato; ele consultou uma cópia de 52,69 GB da Wikipedia armazenada num computador em minha casa — sem qualquer necessidade da internet para isso.
Resumindo:
- O que é: a versão completa da Wikipedia em inglês num único arquivo ZIM: 19,19 milhões de entradas, atualização de junho de 2026, sem imagens. O conteúdo é servido localmente; há também cerca de 700 linhas de código Python que o transformam numa fonte de consulta para modelos locais.
- Quanto custa: nada. Um único download, aproximadamente 53 GB de espaço em disco; não é preciso conta, chave API ou assinatura alguma.
- Qual a velocidade: busca full-text leva de 3 a 30 ms; recuperação do artigo, 0,5 ms. Uma resposta completa leva cerca de 8 segundos — sendo que quase todo esse tempo é gasto pelo modelo de IA processando a informação.
- A regra que o torna útil: o sistema retorna um código de erro diferente de zero quando não consegue encontrar uma resposta confiável. Os agentes que o utilizam são instruídos a reportar essa falha em vez de inventar uma resposta.
- O que ele nunca faz: sair da casa onde está instalado. Não há provedor, nem chamadas à API, nem registro de consultas; as perguntas feitas por minha família não viram dados coletados em lugar nenhum.
Por que se dar ao trabalho, se o modelo já “sabe” as coisas?
Porque ele não sabe, e o modo como falha é problemático. Um modelo pequeno, ao ser questionado sobre datas, propriedades químicas ou nomes de lugares, costuma responder de forma fluente, confiante e plausível — sem dar nenhum sinal se a informação é verdadeira ou não. Ele não está mentindo; simplesmente não tem mecanismo para distinguir entre o que lembra e o que gera. Isso é aceitável para textos criativos, mas desastroso quando se trata de fatos.
A recuperação de informações corrige esse problema, porém os sistemas comuns exigem uma API de busca na nuvem: sua pergunta vai para uma empresa, que a registra; a utilidade do seu assistente passa a depender da disponibilidade e dos termos de serviço dessa empresa. Em minha casa, onde um conjunto de IA responde às perguntas das crianças, ambos os aspectos me incomodam.
A Wikipedia resolve ambos os problemas ao mesmo tempo: é o maior repositório de conhecimento geral que existe, pode ser baixada integralmente sem problemas legais ou práticos, e cabe num disco cujo custo é menor do que uma noite num restaurante. O projeto Kiwix já faz esse trabalho há anos: empacota wikis inteiras no formato ZIM, comprimido e indexado, para uso offline em escolas, navios e lugares sem conexão à internet. Eu apenas direciono um modelo de IA para esse conteúdo, em vez de um navegador.
O que se obtém ao final
Uma pergunta feita, uma resposta fornecida e um bloco de citações indicando exatamente quais artigos da Wikipedia serviram de base para a resposta. Algo como:
$ infoforge "Quem escreveu Kokoro e quando foi publicado?"
Kokoro foi escrito por Natsume Sōseki e publicado em 1914.
Fontes:
- Kokoro"
Parece simples, mas o importante é o que não acontece: nenhuma requisição de rede sai do ambiente local; nada é registrado por nenhum provedor; o modelo sequer poderia responder baseando-se apenas na memória. Caso a busca não retornasse resultados, o comando exibiria uma falha e encerraria com código de erro, em vez de preencher o vazio com algo inventado.
Como funciona
Cinco etapas, todas bem simples — o que é justamente recomendado.
Extração de palavras-chave. A pergunta original não é o melhor termo para busca; “Kokoro” é. Algumas dezenas de linhas de código, removendo palavras irrelevantes e mantendo as frases importantes, funcionam bem o suficiente — nunca precisei trocar esse módulo.
Busca. O sistema de busca full-text do Kiwix é um verdadeiro índice, não um simples grep; ele torna tudo isso possível. Entre 19,19 milhões de entradas, os resultados são devolvidos em 3 a 30 milissegundos. Não há embeddings, bancos de dados vetoriais ou qualquer outra estrutura complexa que precise ser reconstruída após atualizações da Wikipedia; os editores do site já fizeram o “dividir em pedaços” — eles chamam esses pedaços de artigos.
Recuperação e truncamento. Os melhores resultados são obtidos como textos completos, levando cerca de meio milissegundo cada. O truncamento é a única parte que exige julgamento: as primeiras seções dos artigos contêm a maioria das informações úteis; por isso o limite de tokens é aplicado a partir do topo, garantindo que cada texto seja autossuficiente sem ocupar espaço demais e sobrepor-se às instruções posteriores.
O prompt orientado. Os artigos são inseridos no prompt com instrução para responder apenas com base neles e citar os títulos usados. Essa é a chave do sistema; trata-se de um simples prompt, não uma garantia absoluta — daí a necessidade da etapa seguinte.
O modelo. Um modelo de raciocínio local (DeepSeek-R1 8B, rodando na GPU da casa) gera a resposta final. Em estado “quente”, o ciclo completo leva cerca de 8 segundos, sendo que 7,9 desses segundos são gastos pelo modelo processando a informação. A recuperação é gratuita; o raciocínio, não.
O “contrato de recusa” da ancoragem
Essa é a decisão de design que mais defenderei — e não é técnica.
Um prompt do tipo “use apenas essas fontes” é um pedido. Os modelos geralmente o respeitam, mas às vezes o ignoram, especialmente quando as fontes são escassas ou o modelo possui informações na memória que parecem caber no contexto. Se a única proteção do sistema for essa frase, então “ancoragem” acaba sendo apenas uma impressão subjetiva.
Por isso, a ancoragem é imposta fora do modelo. Quando a busca não retorna nada útil, o programa não repassa a pergunta ao modelo como se fosse um “plano B”; ele falha e encerra com código de erro diferente de zero — sinal que qualquer sistema que o chame já está preparado para detectar. Os agentes de IA que o utilizam são obrigados a relatar a falha em vez de inventar uma resposta baseada na memória. Assim, a recusa é propagada; ela não é suavizada por camadas superiores.
O resultado é um assistente que lhe dirá claramente que não encontrou o que procurava. Isso parece uma falha numa lista de recursos, mas é exatamente o oposto: um modelo que admite “não achei” vale mais do que um modelo maior que inventa respostas. O primeiro pode ser usado como base para construções posteriores; o segundo exige checagem constante de fatos — e se você precisa verificar cada resposta, na verdade não ganhou nada em termos de eficiência.
Privacidade é arquitetura, não política
Todos os grandes assistentes têm páginas de privacidade; este tem uma topologia: a pergunta parte do terminal, vai para um índice de busca na mesma rede local, depois para o modelo também na mesma rede, e volta. Não há provedor no caminho capaz de registrar nada, não há chave que identifique quem sou, nem termos de serviço sujeitos a mudanças futuras. Meu filho pode perguntar algo embaraçoso; o processo é tão privado quanto procurar num livro na estante — porque, funcionalmente, é exatamente isso que acontece.
Ninguém precisa confiar em mim para isso; basta desconectar a internet e ver que tudo continua funcionando. É comprovável.
Os 90% pouco glamourosos
Montar o pipeline foi um fim de semana agradável. O verdadeiro desafio foram três flags de configuração dos containers.
O servidor da Wikipedia roda num container sem privilégios num desktop Linux imutável com SELinux ativado; cada um desses requisitos me custou uma noite inteira de trabalho:
- Mapeamento de usuário sem root. O container precisa rodar como root dentro do seu próprio namespace, mas esse acesso deve ser mapeado para meu usuário comum fora dele. Errou isso e o servidor inicia, diz que está “saudável”, mas não serve nada — o processo simplesmente não consegue ler o arquivo ao qual aponta.
- Relabeling do SELinux. Num sistema com SELinux, um volume montado num container exige uma opção de montagem específica para reclassificar os arquivos; sem ela, o kernel bloqueia a leitura por conta de uma política que desconhece o container. O erro aparece como “arquivo ausente”, levando à busca no lugar errado.
- Caminhos de arquivo explícitos. A detecção automática do diretório com os arquivos ZIM não funcionou conforme a documentação previa na visão do container; especificar o caminho manualmente levou trinta segundos, depois que parei de presumir que o problema estava em outro lugar.
Três flags. Cerca de 90% do tempo gasto. Essa é a realidade da maioria dos trabalhos de auto-hospedagem: pouco glamouroso, mas essencial; é exatamente esse aspecto que quase nunca aparece nos textos explicativos — e por isso muita gente acha que “não tem jeito” de fazer isso, quando na verdade estão apenas enfrentando as mesmas três flags pela primeira vez, sozinhos.
Depois, parou de funcionar… e ninguém percebeu
Funcionava perfeitamente. Era rápido. Testei-o, anotei os resultados e segui em frente.
Uma semana depois, tentei usá-lo novamente, mas ele havia desaparecido. A máquina havia reiniciado em algum momento; o container não voltou a rodar, e nada me avisou disso — pois não havia nenhuma unidade de serviço, nem monitoramento, nem verificação de integridade. Pior ainda: o arquivo de configuração que informaria aos meus agentes de IA sobre a existência dessa ferramenta estava apenas como “rascunho”, sem nunca ter sido instalado. Assim, durante toda aquela semana, todos os agentes responderam com base na memória, quando poderiam ter consultado a ferramenta; eles nem sabiam que lhes faltava essa opção.
A lição é simples:
Uma funcionalidade que nada inicia automaticamente e da qual ninguém tem conhecimento é indistinguível de uma funcionalidade que você nunca criou.
A solução exigiu apenas 12 linhas numa unidade de serviço e um arquivo Markdown. A unidade garante que o servidor sobreviva a reinicializações; o arquivo Markdown atua como um “manual” compartilhado entre os agentes, informando-os da existência da ferramenta, como utilizá-la (via comando shell ou HTTP) e que as respostas devem conter as devidas referências.
O processo completo exigia 700 linhas de código… mas apenas 13 linhas foram suficientes para tornar tudo funcional. Continuo aprendendo isso, repetidamente.
Integrado ao ecossistema de agentes
Eu gerencio um pequeno conjunto de agentes de IA locais para tarefas domésticas e empresariais; agora, o InfoForge é uma capacidade compartilhada, em vez de ser apenas um script que eu precisava lembrar de executar. Quando um agente precisa de alguma informação, ele executa o comando ou acessa o endpoint correspondente, recebendo uma resposta acompanhada de referências; essas referências são cruciais: ao citar um artigo, o agente permite que eu verifique a informação com um único clique. Essa verificação é o que transforma um assistente “plausível” num assistente realmente útil.
O InfoForge também interage com tudo o mais no sistema: o mesmo servidor com GPU responde às consultas, redige e-mails e participa de conversas; a camada de conhecimento tornou-se mais um componente do sistema, sem exigir cadastro algum.
Pontos de atenção
- Espaço em disco antes do download. São cerca de 53 GB para a versão sem imagens; o dobro, se quiser incluir imagens também. Verifique o espaço disponível antes de começar; tentar baixar metade do arquivo é uma maneira lenta de descobrir isso.
- A data do dump importado. O meu é de junho de 2026. A Wikipedia não para de crescer; portanto, qualquer informação mais recente que essa data simplesmente não existe para este sistema — o que é bom se você souber disso, mas pode ser uma armadilha se esquecer.
- A qualidade da busca depende da extração de palavras-chave. Quase todas as respostas ruins que vi têm origem em consultas mal formuladas, não em modelos inadequados. Corrija a extração das palavras-chave antes de pensar em usar um modelo maior.
- O tamanho do contexto é uma escolha crítica. Pouco contexto gera respostas incompletas; muito contexto faz o modelo se desviar das instruções. Ajuste esse parâmetro com base em perguntas reais, não sintéticas.
- Teste também os cenários de falha. Faça uma pergunta para a qual a Wikipedia realmente não tenha artigo algum; confirme que o sistema recusa a resposta e retorna um código de erro diferente de zero — não um parágrafo bem redigido. Se só testar perguntas que funcionam, você testou apenas metade do cenário possível.
- Crie a unidade de serviço já no primeiro dia. Como dito acima. Pergunte-me como sei disso.
Onde isso me deixa agora
Minha casa conta agora com uma enciclopédia offline, com um índice de busca e uma IA que só pode responder com base nela. Tudo isso exigiu apenas um download e um fim de semana de trabalho. É mais rápido que a internet, funciona mesmo durante quedas de conexão, nunca será descontinuado… e não exige nenhum modelo de negócios envolvendo-me.
Próximos passos: adicionar mais arquivos ZIM ao sistema — coleções médicas e técnicas fornecidas pelo Kiwix, além de um ou dois wikis meus. A camada de recuperação de informações não se importa com o tipo de conteúdo; portanto, é fácil expandir o sistema. E também vou implementar uma verificação de integridade… afinal, já aprendi essa lição da maneira mais cara possível.
Downloads
Gratuito para uso pessoal. Se isso te economizar uma tarde, o botão do café está logo ali.