RAGAL: A Frugal, Fully Local Retrieval-Augmented Assistant for Technical Support at a Government Agency

Imagina que tienes un bibliotecario robot súper inteligente que puede leer millones de libros y responder cualquier pregunta que le hagas. Normalmente, para que este robot funcione, tienes que enviar tus preguntas y los libros a un cerebro gigante basado en la nube en un centro de datos distante. Pero, ¿qué pasaría si tu biblioteca contiene archivos gubernamentales de alto secreto que es ilegal que salgan del edificio? ¿Qué pasa si no puedes usar la nube en absoluto? Este es el rompecabezas que está en el corazón de la Generación Aumentada por Recuperación (RAG). Piensa en el RAG como una danza de dos pasos: primero, el robot escanea rápidamente una pila específica de documentos para encontrar las páginas más relevantes (recuperación); segundo, utiliza esas páginas para escribir una respuesta inteligente y precisa (generación). La gran pregunta para muchas organizaciones es: ¿Podemos construir este robot enteramente dentro de nuestros propios muros, usando solo una laptop modesta, sin enviar jamás un solo byte de datos al mundo exterior?

Este documento cuenta la historia de RAGAL, un proyecto de una agencia gubernamental rumana que construyó exactamente tal robot. Se enfrentaron a tres reglas que parecían imposibles: ningún dato podía salir jamás de su edificio, el robot solo podía redactar respuestas (los humanos tenían que pulsar el botón de "enviar") y tenían que hacerlo todo en una laptop de consumo con solo 8 GB de memoria. En lugar de rendirse, convirtieron esta configuración "frugal" en un laboratorio de ingeniería ingeniosa. Descubrieron que el secreto del éxito no era comprar un cerebro más grande y caro, sino enseñar al robot cómo buscar mejor la información. Al ajustar su motor de búsqueda con tickets de soporte reales y utilizar un truco ingenioso llamado "destilación de anclaje" para evitar que el robot inventara comandos de base de datos falsos, crearon un sistema que funciona de forma segura y eficaz. Incluso construyeron un "juez en cámara lenta": un modelo de IA masivo que se ejecuta tan lentamente en su CPU que no puede chatear en tiempo real, pero es perfecto para calificar la tarea del robot durante la noche. El resultado es un plano de cómo cualquier organización con estrictas reglas de privacidad puede construir un asistente de IA útil sin necesidad de la nube.

La historia de RAGAL: Un robot que nunca sale de casa

Conoce a RAGAL, el nuevo asistente de una agencia gubernamental rumana que gestiona fondos de inversión rurales. Esta agencia maneja miles de documentos sensibles y tickets de soporte cada día. Debido a que estos archivos contienen datos privados de ciudadanos, tienen estrictamente prohibido salir del edificio de la agencia. Esto significa que no podían usar las herramientas de IA habituales y potentes que viven en la nube. Tenían que construir su propio robot "totalmente local", y tenían que hacerlo en una sola laptop con una tarjeta gráfica que solo tenía 8 GB de memoria —una cantidad minúscula para los estándares de la IA.

El equipo tuvo que seguir tres reglas estrictas, que llaman restricciones:

1. Cero Egresos: Ni una sola pieza de datos podía salir jamás del edificio. Nada de enviar preguntas a la nube, nada de descargar datos de entrenamiento de Internet. Todo tenía que ocurrir en su propio hardware.
2. Solo Lectura: El robot era un escritor, no un actor. Podía redactar código SQL (instrucciones para corregir errores de base de datos) o escribir explicaciones, pero nunca podía ejecutar esos comandos. Un humano tenía que revisarlos y ejecutarlos.
3. Frugalidad: Todo el sistema fue desarrollado, entrenado y probado en una sola laptop de consumo.

El gran descubrimiento: Una mejor búsqueda vence a cerebros más grandes

El equipo comenzó con una suposición común: para obtener mejores respuestas, necesitas un modelo de IA más grande y más inteligente. Pero rápidamente descubrieron que eso era erróneo. Su primera gran victoria no vino de actualizar el "cerebro" (el generador), sino de actualizar el "motor de búsqueda" (el recuperador).

Se dieron cuenta de que simplemente pedirle al robot que encontrara documentos no era suficiente. Necesitaban enseñarle cómo buscar. Construyeron un sistema de búsqueda híbrida que combinaba dos métodos: una búsqueda "densa" que entiende el significado de las palabras, y una búsqueda "dispersa" que busca coincidencias exactas de palabras clave. También añadieron un "policía de tráfico" (enrutamiento de intención) que decide qué tipo de documento buscar basándose en la pregunta. Si preguntas por un procedimiento, busca en manuales; si preguntas por una corrección de base de datos, busca en tickets de soporte antiguos.

Este simple cambio fue una mejora masiva. Antes de cualquier entrenamiento sofisticado, esta búsqueda híbrida aumentó su tasa de éxito del 62% al 81%. Fue la mejora más barata y efectiva que realizaron.

El milagro de los 8 GB: Entrenando en una laptop

El siguiente desafío fue entrenar el motor de búsqueda con sus propios datos. Tenían unos 15.000 tickets de soporte resueltos y documentos internos. Querían enseñar al motor de búsqueda a entender el lenguaje específico de su agencia.

Normalmente, entrenar un modelo como este requiere una supercomputadora masiva. Pero el equipo solo tenía 8 GB de memoria. Descubrieron una trampa oculta: en su laptop con Windows, el controlador de la tarjeta gráfica "derramaba" silenciosamente los datos en la memoria regular de la computadora cuando se quedaba sin espacio, lo que hacía que el entrenamiento fuera increíblemente lento sin llegar a colapsar. Era como intentar correr un maratón con una mochila llena de agua que no sabías que estabías cargando.

Para solucionar esto, utilizaron una receta especial:

• Optimizador de 8 bits: Una forma de reducir las matemáticas que la computadora tiene que hacer.
• Checkpointing de Gradiente: Una técnica que ahorra memoria recalculando algunos pasos en lugar de almacenarlos.

Con estos trucos, lograron entrenar completamente su motor de búsqueda en solo 72 minutos en esa única laptop. Los resultados fueron asombrosos: la capacidad de encontrar el documento correcto entre los 10 primeros resultados (Recall@10) saltó de 0.663 a 0.850.

La trampa silenciosa: Un dominio, dos mundos

Aquí es donde la historia se vuelve complicada. Cuando entrenaron el motor de búsqueda solo con los tickets de soporte, se volvió muy bueno encontrando tickets. Pero, de una manera silenciosa e invisible, empeoró en la búsqueda de los documentos oficiales. El entrenamiento había "deformado" la comprensión del motor de búsqueda, haciendo que olvidara cómo manejar los documentos formales.

Solo lo descubrieron porque construyeron un conjunto de pruebas separado solo para los documentos. Si no lo hubieran hecho, habrían pensado que su sistema era perfecto, cuando en realidad estaba fallando en la mitad de sus datos. Para solucionar esto sin enviar datos a la nube, utilizaron un truco ingenioso llamado GenQ. Utilizaron una IA local para generar preguntas falsas para sus documentos, creando un nuevo conjunto de entrenamiento que equilibraba ambos mundos. Esto reparó el daño, y el motor de búsqueda volvió a ser excelente encontrando tanto tickets como documentos.

La seguridad es lo primero: Evitando que el robot mienta

Dado que el robot redactaba comandos de base de datos, el equipo tenía que asegurarse de que nunca inventara cosas (alucinaciones). Utilizaron una técnica llamada Destilación de Anclaje. En lugar de dejar que la IA escribiera el código SQL desde cero, tomaron código real y funcional de tickets pasados, lo copiaron exactamente, y solo permitieron que la IA escribiera el texto alredíloc (explicando qué hace y cuándo usarlo). Esto hizo imposible que el robot inventara comandos de base de datos falsos porque el código en sí mismo era un "ancla" real y verificada.

También descubrieron un beneficio sorprendente al enmascarar PII (ocultar nombres y números de identificación). Cuando reemplazaron los nombres reales con marcadores de posición como <usuario> o <id_proyecto> antes del entrenamiento, el robot en realidad escribió respuestas mejores. Dejó de copiar nombres de personas específicas de tickets antiguos y empezó a escribir plantillas flexibles que podrían usarse para cualquier persona.

El Juez Lento

Finalmente, ¿cómo calificas a un robot si no puedes usar una IA basada en la nube para revisar su trabajo? El equipo construyó un "juez lento". Utilizaron un modelo de IA masivo (744 mil millones de parámetros) que era demasiado grande para ejecutarse rápido. Se ejecutaba en el procesador principal (CPU) de su computadora en lugar de la tarjeta gráfica, moviendo datos desde el disco duro a medida que avanzaba. Era increíblemente lento, tardando unos 10 a 13 minutos en calificar una sola respuesta. Pero, como era tan inteligente, era perfecto para calificar la tarea del robot durante la noche.

Descubrieron que este juez lento era un buen "segundo opinión", pero no perfecto. A veces discrepaba con los expertos humanos, especialmente en las mejores o peores respuestas. La lección fue usar al juez para encontrar tendencias y patrones, pero siempre tener a un humano que verifique los veredictos específicos.

La Conclusión

El proyecto RAGAL demuestra que no necesitas una supercomputadora o la nube para construir un asistente de IA potente y seguro. Al centrarse en una ingeniería inteligente —mejores estrategias de búsqueda, manejo cuidadoso de datos y reglas de seguridad estrictas— un pequeño equipo con una sola laptop puede crear un sistema que respete la privacidad y aporte un valor real. Demostraron que, a veces, la mejor manera de avanzar es ir más despacio, mantener todo local y prestar mucha atención a los detalles.