RAG local explicado sin jerga

Un modelo de IA como Gemini o Claude fue entrenado con una foto fija de internet hasta cierta fecha. No sabe nada de tu proyecto "Rediseño Q3" ni de la tarea que creaste ayer — porque esa información no existía cuando se entrenó, y probablemente nunca debería haber sido pública.

La solución obvia sería escribir todo el contexto en cada pregunta ("aquí están mis 40 proyectos, ahora responde"), pero eso no escala: hay un límite de cuánto texto le puedes dar a un modelo de una sola vez, y la mayor parte sería irrelevante para la pregunta puntual. RAG resuelve exactamente ese problema: en lugar de mandar todo, busca solo lo relevante y se lo pasa al modelo justo antes de que responda.

Sin jerga, esto es lo que pasa cada vez que le preguntas algo a un asistente con RAG:

1. Tus datos se convierten en números. Cada pieza de información (una tarea, una nota, un proyecto) se transforma en una lista de números que representa su significado — esto se llama embedding. Dos textos con significados parecidos generan listas de números parecidas, aunque usen palabras distintas.
2. Esos números se guardan en un índice buscable. Este índice es lo que se consulta más adelante, en lugar de releer todo el texto original cada vez.
3. Cuando haces una pregunta, tu pregunta también se convierte en números, usando el mismo proceso.
4. Se comparan los números de tu pregunta con los del índice para encontrar las piezas de información más parecidas en significado — no necesariamente las que comparten las mismas palabras.
5. Los resultados más relevantes se agregan a tu pregunta antes de mandársela al modelo, que ahora sí tiene el contexto necesario para responder con precisión sobre tus datos.

Todo esto pasa en segundos, sin que lo veas — el asistente simplemente "sabe" de qué le estás hablando.

La diferencia entre un RAG genérico y un RAG local está en el paso 2: dónde vive ese índice de números.

En la mayoría de las implementaciones empresariales de RAG, el índice vive en una base de datos vectorial especializada en la nube (Pinecone, Weaviate, y similares), gestionada por un proveedor externo. Es rápida y escala bien, pero implica que tu índice de búsqueda —una representación de todo tu contenido— vive en el servidor de otra empresa.

En un RAG local, ese índice vive en tu propio dispositivo. No hay una base de datos vectorial externa que mantener ni a la que confiarle una copia de tu información indexada.

Para que esto no quede en teoría, así es como funciona el RAG de Hito, verificado directamente contra el código:

Qué se indexa

Cuando activas la búsqueda semántica, Hito recorre tu workspace y convierte en texto descriptivo cada: producto, proyecto, tarea, área, ítem de checklist, persona, plantilla de checklist, plantilla de proceso, tipo de proyecto y automatización. Por ejemplo, una tarea se convierte en algo como "Tarea: Revisar contrato — Descripción: pendiente de firma legal" antes de generar su embedding.

Cómo se generan los embeddings

Cada uno de esos textos se envía al modelo gemini-embedding-001 de Google, que devuelve la lista de números correspondiente. La indexación es incremental: si una tarea no cambió desde la última vez que se indexó, Hito no vuelve a pedir su embedding — ahorra llamadas a la API y hace que reindexar sea rápido después de la primera vez.

Dónde vive el índice

Los embeddings resultantes se guardan en IndexedDB, la base de datos incorporada en tu navegador — no en un servidor de Hito (que no existe) ni en una base de datos vectorial de terceros.

Cómo se busca

Cuando preguntas algo, tu pregunta se convierte en su propio embedding y se compara contra todos los guardados usando similitud coseno, calculada a mano en JavaScript puro, sin ninguna librería externa de búsqueda vectorial. Es una búsqueda lineal (recorre todos los embeddings uno por uno), no una estructura optimizada tipo ANN — funciona bien para el volumen de datos de un workspace personal o de equipo chico, pero no es la arquitectura de un buscador a escala de miles de millones de documentos.

Cómo se activa

Todo esto se controla desde Ajustes: hay un interruptor para activar RAG, un estado visible (sin datos, indexando, actualizado, parcial, error), una barra de progreso y botones para cancelar o borrar el índice completo. No pasa nada en segundo plano sin que lo actives explícitamente.

"RAG local" describe dónde vive el índice ya calculado — no que absolutamente nada toque un servidor externo en todo el proceso. Para generar cada embedding, el texto de tu tarea o proyecto se envía a la API de Google (embedContent) con tu propia API key. Es el mismo viaje de datos que ya existe cuando usas el chat del asistente, explicado en detalle en nuestro post sobre MCP.

Lo que sí es enteramente local: el índice resultante (las listas de números y a qué entidad corresponden) vive únicamente en tu navegador, y la búsqueda posterior —comparar tu pregunta contra ese índice— ocurre completamente en tu máquina, sin ninguna llamada de red adicional. Si nunca activas el asistente ni el RAG, ninguno de tus datos sale de tu equipo.

RAG no es magia: es buscar lo relevante antes de responder, en lugar de intentar que el modelo lo sepa todo de memoria. Que sea "local" cambia una cosa importante — dónde vive el índice resultante y quién lo administra — sin cambiar el hecho de que generar embeddings requiere, hoy, una llamada a una API externa.

Si quieres ver esto funcionando sobre tus propios datos, activa la búsqueda semántica en Ajustes y prueba a pedirle al asistente que busque algo que escribiste hace semanas sin usar las palabras exactas — vas a notar la diferencia entre buscar por palabra clave y buscar por significado.

👉 Prueba Hito gratis — gestor de proyectos, procesos y checklists 100% local-first, con un asistente de IA y RAG opcionales que tú controlas con tu propia API key.