InfoForge: Wikipedia sin conexión como fuente RAG para mis agentes de IA locales

Le pregunté a un modelo local de 8B quién escribió Kokoro y cuándo se publicó. Respondió “Natsume Sōseki, 1914”, y luego hizo la parte que realmente me importaba: nombró el artículo en el que leyó eso. El modelo no sabe ese dato. Lo buscó, en una copia de Wikipedia de 52,69 GB en una máquina en mi casa, con internet irrelevante para la transacción.

¿Para qué molestarse, si el modelo ya “sabe cosas”?

Porque en realidad no sabe nada, y su modo de fallo es especialmente problemático. Un modelo pequeño al que se le pide una fecha, una propiedad química o el nombre de un lugar suele responder de forma fluida, segura y creíble, sin dar ninguna indicación de si esa información es verdadera. No está mintiendo; simplemente no cuenta con mecanismos para distinguir entre lo que recuerda y lo que genera. Eso está bien para textos narrativos, pero resulta catastrófico cuando se trata de hechos.

La recuperación de información soluciona el problema, pero los sistemas habituales asumen la existencia de una API de búsqueda en la nube: la consulta llega a una empresa, esa empresa la registra, y la utilidad del asistente pasa a depender del tiempo de actividad y de las condiciones de servicio de terceros. En mi casa, donde el sistema de IA responde a las preguntas de mis hijos, ambos aspectos me preocupan.

Wikipedia resuelve ambos problemas a la vez: es el corpus de conocimiento general más denso que existe, se puede descargar íntegramente de forma legal y práctica, y cabe en un disco cuyo coste es menor que el de salir a cenar. El proyecto Kiwix lleva años haciendo el trabajo duro: empaquetar wikis completas en el formato ZIM comprimido e indexado para uso offline en escuelas, barcos y lugares sin conexión. Yo simplemente dirijo un modelo de IA hacia ese contenido en lugar de un navegador.

¿Qué se obtiene al final?

Una pregunta, una respuesta y un bloque de citas que indica exactamente qué artículos de Wikipedia se usaron para generarla. Algo así:

$ infoforge "¿Quién escribió Kokoro y cuándo se publicó?"

Kokoro fue escrito por Natsume Sōseki y publicado en 1914.

Fuentes:
  - Kokoro

Parece algo sencillo. Lo importante es lo que no ocurre: no se realiza ninguna solicitud de red, no se registra nada en ningún proveedor, y al modelo se le impide responder basándose únicamente en su memoria. Si la búsqueda no hubiera arrojado resultados, el programa habría indicado un fallo y finalizado con código de error, en lugar de dejar el silencio sin respuesta.

¿Cómo funciona?

Cinco etapas, ninguna especialmente compleja; eso es precisamente lo recomendable.

Extracción de palabras clave. La pregunta no es el término de búsqueda ideal. “¿Quién escribió Kokoro y cuándo se publicó?” no sirve; Kokoro sí. Unas pocas docenas de líneas de código que eliminan palabras irrelevantes y conservan frases clave hacen el trabajo bastante bien; nunca he sentido la necesidad de cambiarlo.

Búsqueda. El motor de búsqueda de Kiwix es un índice real, no una simple búsqueda de texto plano; eso es lo que permite que todo funcione. Con 19,19 millones de entradas, devuelve los títulos más relevantes en 3 a 30 milisegundos. En este sistema no hay embeddings, ni bases de datos vectoriales, ni almacenamiento de fragmentos que haya que reconstruir cada vez que se actualiza la Wikipedia; sus editores ya se encargaron del “fragmentado”, y esos fragmentos son los artículos.

Recuperación y truncamiento. Los resultados principales llegan como artículos completos, cada uno en medio milisegundo aproximadamente. El truncamiento es la única parte que requiere criterio: las secciones iniciales contienen la mayoría de los datos útiles; por eso el límite de tokens se aplica desde el principio del texto, de modo que cada fragmento sea autocontenido pero sin excederse en volumen para no “ahogar” la instrucción posterior.

El prompt anclado. Los textos recuperados se incluyen en el prompt junto con la orden de responder únicamente a partir de ellos y de citar sus títulos. Eso es todo el truco; no se trata de una garantía, sino de un simple prompt —de ahí la importancia de la siguiente etapa.

El modelo. Un modelo local de razonamiento (DeepSeek-R1 8B, ejecutándose en el servidor con GPU de mi casa) genera la respuesta. Cuando ya está “caliente”, todo el proceso dura unos 8 segundos, de los cuales casi 7,9 corresponden al propio modelo. La recuperación de información no cuesta nada; el pensamiento sí.

El anclaje como contrato de rechazo

Esta es la decisión de diseño que más defendería, y no es una decisión técnica.

Un prompt que dice “usa solo estas fuentes” es, en realidad, una petición. Los modelos suelen cumplirla la mayor parte del tiempo, pero a veces la ignoran, especialmente cuando las fuentes son escasas y el modelo cuenta con información similar en su memoria. Si la única defensa del sistema es esa frase, entonces “anclado” no es más que una impresión subjetiva.

Por eso el anclaje se impone fuera del modelo. Cuando la búsqueda no devuelve resultados útiles, el programa no envía la pregunta tal cual al modelo como solución de emergencia; en su lugar, falla y emite un código de error distinto de cero, señal que todo programa que lo invoque ya sabe interpretar. Además, los agentes de IA que lo usan están obligados a reportar el fallo en lugar de inventar una respuesta basada en su propia memoria. El rechazo se propaga; no se suaviza en capas superiores.

El resultado es un asistente que te dirá abiertamente que no encontró la información. Eso parece una debilidad en una lista de funcionalidades, pero es todo lo contrario. Un modelo que admite “no lo sé” vale más que uno más grande que inventa datos, porque el primero se puede utilizar como base para futuros desarrollos; el segundo requiere una verificación exhaustiva de cada respuesta, lo cual no ahorra ningún esfuerzo en realidad.

La privacidad es arquitectura, no política

Todos los grandes asistentes tienen páginas dedicadas a la privacidad. Este, en cambio, cuenta con una topología muy clara: la pregunta parte del terminal, llega a un índice de búsqueda en la misma red local, después al modelo que también está en esa red, y finalmente regresa. No hay ningún proveedor intermedio capaz de registrarla, ni claves que me identifiquen, ni términos de servicio susceptibles de cambiar en el futuro. Mi hijo puede preguntarle algo vergonzoso; la transacción es tan privada como si buscara la respuesta en un libro de una estantería, porque, funcionalmente, eso es exactamente lo que ocurre.

Nadie tiene que confiar en mi palabra al respecto; esa es la parte positiva. Todo esto se puede comprobar desconectando internet y observando cómo el sistema sigue funcionando sin problemas.

El 90% poco glamuroso

El desarrollo del flujo principal fue un trabajo agradable, de fin de semana. Lo realmente difícil fueron tres simples parámetros de configuración de contenedores.

El servidor de Wikipedia se ejecuta como un contenedor sin privilegios en un escritorio Linux inmutable donde SELinux está activado; cada uno de esos requisitos me costó una tarde entera:

• Mapeo de usuarios sin privilegios. El contenedor debe correr como root dentro de su propio espacio de nombres, pero ese usuario debe mapearse a mi cuenta normal fuera del contenedor. Si esto no se hace bien, el servidor inicia, reporta que está listo, pero no sirve nada: el proceso simplemente no puede leer el archivo al que apunta.
• Relabeling de SELinux. Un volumen montado en un contenedor dentro de un sistema con SELinux necesita una opción específica para que el kernel relablee sus permisos; de lo contrario, se deniega el acceso a la lectura por una política que desconoce la existencia del contenedor. El error se manifiesta como “archivo no encontrado”, lo que lleva a buscar en lugares completamente equivocados.
• Rutas de archivos explícitas. La detección automática del directorio con el archivo ZIM no funcionó como indicaban los documentos dentro de la perspectiva del contenedor; especificar la ruta manualmente solucionó el problema en treinta segundos, una vez que dejé de pensar que el fallo estaba en otro sitio.

Tres parámetros. Aproximadamente el 90% del tiempo invertido. Esta es la realidad cotidiana del autoalojamiento; es precisamente esa parte la que suele omitirse en las guías, lo que lleva a la gente a creer que no se les da bien esto cuando, en realidad, solo lo están haciendo por primera vez, solos y con esos mismos tres parámetros delante.

Luego dejó de funcionar, y nadie se dio cuenta

Funcionaba. Era rápido. Lo probé, anoté los resultados y seguí adelante.

Una semana después intenté usarlo, pero ya no estaba. En algún momento la máquina se había reiniciado; el contenedor no volvió a iniciarse, y nada me avisó de ello: no había ninguna unidad de servicio, ni monitoreo, ni comprobaciones de estado. Peor aún: el archivo de habilidades que habría informado a mis agentes de IA sobre la existencia de esta herramienta estaba en borrador y nunca se instaló. Así que durante toda esa semana, cada agente respondió basándose en su memoria, cuando podría haber consultado la información; además, no tenían ni idea de que les faltaba esa opción.

La lección es muy sencilla:

Una capacidad que nada inicia automáticamente y de la que nadie sabe no se diferencia en nada de una capacidad que nunca llegaste a crear.

La solución consistió en una unidad de servicio de 12 líneas y un archivo Markdown. La unidad garantiza que el servidor sobreviva a los reinicios; el archivo Markdown es una “habilidad” compartida entre los agentes: les indica que la herramienta existe, cómo invocarla (mediante un comando de shell o HTTP, según prefieran) y que toda respuesta debe incluir sus citas correspondientes.

El sistema completo constaba de 700 líneas; sin embargo, tan solo 13 líneas de código fueron las que lo hicieron realidad. Sigo aprendiendo esto una y otra vez.

Integrado en el ecosistema de agentes

Tengo un pequeño grupo de agentes de IA locales para tareas domésticas y laborales; ahora InfoForge es una capacidad compartida, no simplemente un script que yo recuerdo. Cuando un agente necesita algún dato, ejecuta el comando o accede al endpoint correspondiente, recibe una respuesta con sus citas incluidas y las transmite a su vez. Estas citas son cruciales: cuando un agente me da información y menciona el artículo de origen, puedo verificarlo con un solo clic; esa verificación es lo que convierte a un asistente potencialmente útil en uno verdaderamente confiable.

InfoForge también se integra con todo lo demás que tengo en casa. El mismo servidor con GPU responde a consultas de InfoForge, redacta correos y gestiona conversaciones; la capa de conocimiento ahora es simplemente otro componente más que no requiere ninguna cuenta para funcionar.

Posibles problemas

• Espacio en disco antes de descargar. Unos 53 GB para la versión sin imágenes; casi el doble si se desean imágenes. Compruebe primero el espacio disponible; intentar descargar medio archivo ZIM es una forma lenta de darse cuenta de este requisito.
• La fecha del dump importa. El mío data de junio de 2026. Wikipedia no se detiene nunca; por lo tanto, cualquier información posterior a esa fecha no existe para este sistema. Esto está bien si se sabe, pero puede resultar en un error si se olvida.
• La calidad de búsqueda depende de la extracción de palabras clave. Casi todas las respuestas incorrectas que he visto se deben a consultas mal formuladas, no a modelos deficientes. Corrija primero la extracción de términos antes de recurrir a modelos más potentes.
• El truncamiento es una elección deliberada. Si el contexto es insuficiente, la respuesta no aparece; si es excesivo, el modelo se desvía de las instrucciones. Ajuste este parámetro en función de preguntas reales que le interesen, no de ejemplos sintéticos.
• Pruebe también el caso de fallo. Pregúntele algo sobre lo cual Wikipedia no tenga artículo alguno; verifique que obtenga un rechazo y un código de error distinto de cero, en lugar de un párrafo fluido. Si solo prueba preguntas para las que sí hay respuesta, solo habrá probado la mitad fácil del sistema.
• Cree la unidad de servicio desde el primer día. Ya lo he mencionado antes; pregúnteme cómo lo sé.

¿En qué me deja todo esto?

Ahora mi hogar cuenta con una enciclopedia offline provista de índice de búsqueda, además de una IA autorizada a responder únicamente a partir de ella. Todo ello costó tan solo una descarga y un fin de semana de trabajo. El sistema es más rápido que Internet, funciona incluso durante cortes de red, nunca se interrumpirá y, además, no requiere ningún modelo de negocio que me involucre a mí.

Lo siguiente en la lista: añadir más colecciones ZIM al mismo servidor —las colecciones médicas y técnicas empaquetadas por Kiwix, además de uno o dos wikis propios—; la capa de recuperación de información no depende del tipo de contenido disponible. También implementaré comprobaciones de estado, ya que ahora he aprendido esa lección… al precio más alto posible.

Descargas

• Download InfoForge project source (zip) 80 KB

Gratis para uso personal. Si te ahorra una tarde, el botón del café está aquí cerca.