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

Le pregunté a un modelo local de 8 mil millones de parámetros quién escribió Kokoro y cuándo se publicó. Respondió “Natsume Sōseki, 1914”, y luego hizo lo que realmente me interesaba: mencionó el artículo de Wikipedia en el que leyó esa información. El modelo no conocía ese dato; lo buscó en una copia de Wikipedia de 52,69 GB almacenada en mi casa; la conexión a internet no tuvo ninguna influencia en el proceso.

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

Porque en realidad no sabe nada, y su modo de fallar es problemático. Un modelo pequeño, al recibir una consulta sobre fechas, propiedades químicas o nombres de lugares, produce una respuesta fluida, segura y plausible, sin indicar en absoluto si esa información es cierta. No miente; simplemente no tiene mecanismos para distinguir entre lo que recuerda y lo que genera. Eso está bien para textos narrativos, pero resulta catastrófico para datos factuales.

La recuperación de información soluciona el problema, pero los sistemas habituales asumen una API de búsqueda en la nube: la consulta llega a una empresa, ésta la registra, y la utilidad del asistente depende ahora del tiempo de actividad y las condiciones de servicio de terceros. En mi casa, donde el stack de IA responde a mis hijos, ambas situaciones 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 que cuesta menos que 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 oriento un modelo de IA hacia ese contenido, en lugar de usar un navegador.

¿Qué se obtiene al final?

Una pregunta como entrada, una respuesta como salida, 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 trivial. 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 estructuralmente responder basándose únicamente en su memoria. Si la búsqueda no hubiera devuelto resultados, el programa habría mostrado un error y finalizado con código distinto de cero, en lugar de llenar el vacío con una respuesta.

¿Cómo funciona?

Cinco etapas, ninguna particularmente ingeniosa; esa es precisamente la recomendación.

Extracción de palabras clave. La pregunta no es la consulta en sí. “¿Quién escribió Kokoro y cuándo se publicó?” no es un buen término de búsqueda; Kokoro sí lo es. Unas pocas docenas de líneas de código para eliminar palabras vacías y conservar 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 un simple grep; 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 almacenes de fragmentos que haya que reconstruir cada vez que se actualiza la Wikipedia; sus editores ya hicieron el trabajo de dividirla en artículos.

Recuperación y truncamiento. Los resultados principales llegan como artículos completos; cada uno tarda medio milisegundo aproximadamente en ser obtenido. El truncamiento es la única parte que requiere juicio: las secciones iniciales contienen la mayoría de los datos relevantes, así que el presupuesto de tokens se gasta empezando por arriba; se toma lo suficiente para que cada artículo sea autocontenido, pero no tanto como para que el modelo ignore las instrucciones posteriores.

El prompt anclado. Los artículos se incluyen en el prompt con la indicación de que la respuesta debe basarse únicamente en ellos y de citar sus títulos. Ese es el truco principal; no se trata de una garantía, sino de un simple prompt —de ahí la siguiente sección.

El modelo. Un modelo de razonamiento local (DeepSeek-R1 8B, ejecutándose en el servidor con GPU de mi casa) genera la respuesta. En estado “caliente”, todo el proceso tarda unos 8 segundos, de los cuales casi 7,9 corresponden al propio modelo pensando. La recuperación es gratuita; el razonamiento no lo es.

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 únicamente estas fuentes” es, en realidad, una petición. Los modelos suelen cumplirla, pero a veces la ignoran, sobre todo cuando las fuentes son escasas y el modelo tiene en su memoria información similar. 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 aplica fuera del modelo: cuando la búsqueda no devuelve nada útil, el programa no envía la pregunta al modelo como último recurso; en su lugar falla y devuelve un código de error distinto de cero, señal que todo programa que lo invoca ya sabe interpretar. Los agentes de IA que lo usan están obligados a reportar el fallo en lugar de inventar una respuesta basada en su 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 confiable; el segundo exige verificación constante, y si hay que comprobar cada respuesta, no se ha ahorrado nada en absoluto.

La privacidad es arquitectura, no política

Todos los grandes asistentes tienen una página de privacidad. Este tiene una topología: la pregunta parte del terminal, llega a un índice de búsqueda en la misma red local, pasa al modelo que también está en esa red, y vuelve al usuario. No hay proveedores intermedios capaces de registrar nada; no hay claves que me identifiquen; no hay términos de servicio que puedan cambiar el próximo trimestre. Mi hijo puede preguntarle algo vergonzoso, y la transacción es tan privada como si buscara 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. Se puede verificar desconectando internet y comprobando que el sistema sigue funcionando.

El 90% poco glamuroso

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

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

• Mapeo de usuarios sin privilegios. El contenedor debe ejecutarse como root dentro de su propio espacio de nombres, pero ese usuario debe mapearse a mi cuenta normal fuera del contenedor. Si esto falla, el servidor arranca, informa que está operativo, pero no sirve nada: el proceso simplemente no puede leer el archivo al que apunta.
• Relabeling de SELinux. Un volumen montado en un contenedor bajo SELinux necesita una opción específica para que se le cambie la etiqueta; de lo contrario el kernel bloquea el acceso por razones de seguridad, ignorando por completo al contenedor. El error se manifiesta como “archivo no encontrado”, lo que lleva a buscar en lugares totalmente equivocados.
• Rutas de archivos explícitas. La detección automática del directorio ZIM no funcionaba según lo descrito en la documentación, dentro de la perspectiva del contenedor. Especificar el nombre del archivo directamente solucionó el problema en treinta segundos, una vez que dejé de suponer que el fallo estaba en otro sitio.

Tres parámetros. Aproximadamente el 90% del tiempo invertido. Esta es la realidad de casi todo trabajo de autoalojamiento; es precisamente esa parte la que se omite en las descripciones, y por eso la gente concluye que no sirven para esto cuando simplemente lo están haciendo por primera vez, solos, enfrentándose a esos mismos tres parámetros.

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 quise 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 redactado pero nunca instalado. 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 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 es indistinguible 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 un reinicio; el archivo Markdown es una “habilidad” compartida en el sistema de agentes —el mecanismo mediante el cual estos descubren qué pueden hacer—, y les indica que la herramienta existe, cómo invocarla (un comando de shell o una solicitud HTTP, según prefieran) y que toda respuesta debe incluir sus citas correspondientes.

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

Integrado en el sistema de agentes

Manejo un pequeño grupo de agentes de IA locales para tareas domésticas y empresariales; ahora InfoForge es una capacidad compartida, no simplemente un script que yo recuerdo. Cuando un agente necesita algún dato, ejecuta el comando o llama al endpoint correspondiente, recibe una respuesta acompañada de citas y la transmite luego. Estas citas son más importantes de lo que parecen: cuando un agente me informa algo y menciona el artículo fuente, 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 opera en mi entorno local. El mismo servidor con GPU atiende consultas de InfoForge, redacta correos y participa en conversaciones; la capa de conocimiento se ha convertido así en un componente más que no requiere ninguna cuenta de registro.

Cosas a tener en cuenta

• Espacio en disco antes de descargar. Aproximadamente 53 GB para la versión sin imágenes; el doble si deseas incluir imágenes. Comprueba primero el espacio disponible; intentar descargar un archivo ZIM incompleto es una forma lenta de darse cuenta de este requisito.
• La fecha del dump importa. El mío data de junio de 2026; Wikipedia sigue actualizándose. Cualquier información posterior a esa fecha no existe para este sistema, lo cual está bien si lo sabes… pero puede ser una trampa si lo olvidas.
• La calidad de la búsqueda depende de tu extracción de palabras clave. Casi todas las respuestas incorrectas que he visto se deben a consultas mal formuladas, no a un modelo deficiente. Corrige primero la extracción de términos antes de optar por un modelo más potente.
• El truncamiento es una decisión deliberada. Con muy poco contexto, la respuesta no aparece; con demasiado, el modelo se desvía de las instrucciones. Ajusta este parámetro según preguntas reales que te interesen, no basándote en ejemplos sintéticos.
• Prueba intencionadamente los casos de fallo. Pregunta algo sobre lo cual Wikipedia realmente no tiene artículo y verifica que el sistema responda con un rechazo y un código de salida distinto de cero, en lugar de ofrecer un párrafo fluido. Si solo pruebas preguntas para las que sí hay respuesta, solo habrás probado la mitad fácil del proceso.
• Crea la unidad de servicio desde el primer día. Ya lo he mencionado; pregúntame cómo lo sé.

¿En qué me deja todo esto?

Ahora mi entorno local cuenta con una enciclopedia offline provista de un índice de búsqueda, y con una IA autorizada únicamente a hablar basándose en ella. Todo ello requirió 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, no corre riesgo de desaparecer, y no implica ningún modelo de negocio del cual yo deba preocuparme.

Lo siguiente en mi lista: añadir más archivos ZIM al mismo servidor —las colecciones médicas y técnicas que ofrece Kiwix, además de uno o dos wikis propios—; la capa de recuperación de información no se preocupa por el tipo de contenido almacenado. También implementaré una comprobación de estado, porque ya he aprendido esa lección… pagando el precio completo.

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.