RAG: la memoria semántica
de las máquinas
Cómo la Generación Aumentada por Recuperación transforma un modelo de lenguaje en un investigador capaz de consultar su propia biblioteca de documentos — y por qué la distancia coseno es la brújula que lo guía.
Un modelo de lenguaje, por potente que sea, es fundamentalmente un sistema con amnesia selectiva: sabe mucho del mundo hasta la fecha de su entrenamiento, pero no sabe nada de tus documentos. RAG es la solución arquitectónica a ese problema — y su elegancia está en que no modifica el modelo, sino que le entrega el contexto exacto que necesita, justo antes de que responda.
En las últimas semanas he estado construyendo un sistema de consulta sobre mis investigaciones de geohistoria de Cumaná — específicamente sobre el colapso del Túnel de Transferencia Guamacán y la crisis hídrica que genera. El sistema usa n8n como orquestador, Ollama con modelos locales (llama3.1:8b y nomic-embed-text), y PostgreSQL + pgvector como motor de búsqueda vectorial. En este artículo explico la arquitectura desde sus fundamentos matemáticos hasta su implementación práctica.
El problema que RAG resuelve
Los Large Language Models (LLMs) son, en esencia, compresores estadísticos del lenguaje humano. Durante el entrenamiento, el modelo ajusta billones de parámetros para minimizar la perplejidad† sobre un corpus masivo de texto. El resultado es una red neuronal que ha interiorizado patrones sintácticos, semánticos y factuales — pero ese conocimiento está congelado en los pesos del modelo desde el momento del entrenamiento.
Esto genera tres patologías bien documentadas:
- Alucinaciones factuales: el modelo genera texto plausible pero incorrecto cuando no tiene información suficiente, porque su objetivo de entrenamiento es producir tokens probables, no verdaderos.
- Opacidad de fuentes: es imposible saber qué parte del corpus de entrenamiento respaldó una afirmación concreta — no hay trazabilidad documental.
- Conocimiento estático: el modelo no puede acceder a documentos privados, bases de datos propias, ni información posterior a su fecha de corte.
† Perplejidad (perplexity): métrica que cuantifica cuánta incertidumbre tiene el modelo al predecir el siguiente token en una secuencia. Formalmente, es la exponencial de la entropía cruzada media: un modelo con perplejidad 10 se comporta, estadísticamente, como si eligiera entre 10 opciones igualmente probables en cada paso. Perplejidad baja = predicciones confiadas y precisas; perplejidad alta = el modelo "titubea" con frecuencia. Los mejores LLMs modernos alcanzan perplejidades de un solo dígito en benchmarks estándar de inglés.
RAG ataca los tres problemas de raíz: en lugar de pedirle al modelo que recuerde, le proporcionamos los fragmentos relevantes de nuestra base documental en el propio prompt. El modelo pasa de ser un oráculo a ser un lector experto que sintetiza evidencia concreta.
La búsqueda semántica en el espacio vectorial no busca palabras exactas — busca proximidad de significado. Dos frases que nunca comparten una sola palabra pueden estar a milímetros de distancia en ese espacio si expresan la misma idea.
Fase I — Ingesta: construir la biblioteca vectorial
Antes de poder consultar nada, debemos transformar nuestros documentos en una representación que permita búsqueda semántica. Este proceso tiene tres etapas bien definidas.
-
Fragmentación recursiva (chunking)
Un PDF de 40 páginas no se puede insertar como un solo vector. Los modelos de embeddings tienen una ventana de contexto limitada (típicamente 512 tokens para nomic-embed-text), y además, un fragmento demasiado largo diluye la señal semántica. El RecursiveCharacterTextSplitter divide el texto respetando jerarquías de separadores: primero párrafos, luego oraciones, luego palabras — garantizando que cada chunk sea coherente en sí mismo. Con
chunkSize=500ychunkOverlap=50, los chunks adyacentes comparten 50 tokens, preservando el contexto en las fronteras. -
Proyección al espacio latente (embedding)
Cada chunk de texto se pasa por un modelo de embeddings — en nuestro caso nomic-embed-text, que produce vectores de 768 dimensiones. Este modelo fue entrenado específicamente para representar la similitud semántica: textos con significado similar se proyectan a regiones cercanas del espacio vectorial, independientemente de las palabras exactas usadas. El resultado es un tensor
float32[768]por cada chunk. -
Persistencia en PostgreSQL + pgvector
Los vectores se almacenan en una tabla de Postgres con la extensión pgvector, que añade un tipo de dato nativo
vector(n)y operadores de distancia vectorial. Cada fila contiene el texto original del chunk, sus metadatos (página, documento de origen), y su vector embedding. Sobre la columna de embeddings se construye un índice especializado para búsqueda eficiente.
-- Habilitar la extensión vectorial CREATE EXTENSION IF NOT EXISTS vector; -- Tabla de documentos con embeddings de 768 dimensiones CREATE TABLE documentos_investigacion ( id BIGSERIAL PRIMARY KEY, text TEXT, metadata JSONB, embedding vector(768) ); -- Índice IVFFlat para búsqueda aproximada de vecinos cercanos -- lists=100: particiona el espacio en 100 listas de Voronoi CREATE INDEX ON documentos_investigacion USING ivfflat (embedding vector_cosine_ops) WITH (lists = 100);
La matemática de la búsqueda semántica
Aquí está el núcleo conceptual de todo el sistema. Cuando el usuario hace una pregunta, esa pregunta también se convierte en un vector de 768 dimensiones mediante el mismo modelo de embeddings. Luego el sistema busca los vectores almacenados que están más cerca de ese vector-consulta en el espacio multidimensional.
La métrica de distancia que usamos es la similitud coseno:
El denominador normaliza por las magnitudes, haciendo la métrica invariante a la escala.
Resultado: 1 = idénticos semánticamente · 0 = ortogonales · −1 = opuestos.
La intuición geométrica es poderosa: los vectores son flechas en un espacio de 768 dimensiones. Dos flechas que apuntan en la misma dirección tienen similitud coseno cercana a 1, sin importar qué tan largas sean. Un párrafo sobre "colapso de infraestructura hídrica" y una pregunta sobre "falla en el sistema de agua" apuntarán casi en la misma dirección en ese espacio — aunque no compartan ninguna palabra.
En 3 dimensiones, el espacio disponible para separar conceptos distintos es extremadamente limitado. A 768 dimensiones, el espacio crece exponencialmente: hay suficiente "lugar" para que conceptos sutilmente distintos ocupen regiones claramente diferenciadas, mientras los conceptos similares permanecen agrupados. Este fenómeno es la base del éxito de los embeddings modernos.
El problema de escala: búsqueda exacta vs. aproximada
Con 84 vectores almacenados, una búsqueda exhaustiva (comparar la consulta contra cada vector) es trivial. Pero en producción, con millones de documentos, una búsqueda exacta requeriría O(n) comparaciones — completamente inviable. Por eso pgvector implementa dos algoritmos de búsqueda aproximada de vecinos cercanos (ANN):
Inverted File with Flat quantization. Divide el espacio vectorial en listas de Voronoi mediante k-means. Al buscar, solo examina las listas más cercanas al vector de consulta. Requiere un paso previo de entrenamiento con VACUUM ANALYZE. Ideal para datasets medianos con latencia predecible.
Hierarchical Navigable Small World. Construye un grafo de proximidad multicapa: las capas superiores permiten saltos largos; las inferiores refinan la búsqueda. Búsqueda en O(log n). Mayor uso de memoria que IVFFlat, pero sin fase de entrenamiento.
Los embeddings float32 ocupan 768 × 4 = 3.072 bytes por vector. Con quantización a 8-bit (int8), se reduce a 768 bytes — 4× menos memoria. La quantización a 1-bit (binary) lleva esto a 96 bytes por vector, con aceleración masiva mediante instrucciones SIMD.
Fase II — Consulta: el ciclo RAG en acción
Una vez construida la biblioteca vectorial, el flujo de consulta es elegante en su simplicidad. Esto es lo que sucede "bajo el capó" cada vez que el usuario hace una pregunta:
┌─────────────────────────────────────────────────────────┐ │ CICLO RAG — FASE DE CONSULTA │ └─────────────────────────────────────────────────────────┘ Usuario │ │ "¿Qué papel juegan las arterias olvidadas en │ la estructura urbana histórica de Cumaná?" ▼ ┌─────────────────────────┐ │ Modelo de Embeddings │ ← nomic-embed-text │ (vectoriza la query) │ └─────────────────────────┘ │ │ vector float32[768] = [0.021, -0.143, 0.887, ...] ▼ ┌─────────────────────────┐ │ PostgreSQL + pgvector │ ← búsqueda ANN por similitud coseno │ SELECT top-5 chunks │ ← ORDER BY embedding <=> query_vector └─────────────────────────┘ │ │ 5 fragmentos de texto con mayor similitud semántica ▼ ┌─────────────────────────┐ │ AI Agent (n8n) │ │ construye el prompt │ ← system prompt + chunks + pregunta └─────────────────────────┘ │ ▼ ┌─────────────────────────┐ │ LLM — llama3:8b │ ← genera respuesta fundamentada │ (Ollama, local) │ ← en los chunks recuperados └─────────────────────────┘ │ ▼ Respuesta con trazabilidad documental
El operador <=> en pgvector calcula la distancia coseno entre vectores. La consulta SQL que ejecuta el retriever es:
SELECT text, metadata, 1 - (embedding <=> '[0.021, -0.143, 0.887, ...]'::vector) AS similitud FROM documentos_investigacion ORDER BY embedding <=> '[0.021, -0.143, 0.887, ...]'::vector LIMIT 5;
La expresión 1 - distancia_coseno convierte la distancia en similitud: 1.0 sería idéntico, 0.0 sería ortogonal. En la práctica, fragmentos relevantes suelen tener similitud entre 0.75 y 0.95.
La arquitectura completa en n8n
El sistema tiene dos workflows separados con responsabilidades bien delimitadas. La ingesta corre una vez por documento; la consulta corre en cada interacción del usuario.
Workflow 1 — Ingesta
Manual Trigger │ main ▼ Read/Write Files from Disk ← PDF binario desde /home/node/.n8n-files/ │ main ──────────────────────────────────────────┐ ▼ │ main Postgres PGVector Store (mode: insert) Default Data Loader ▲ │ ai_document │ ai_embedding Text Splitter ──────┘ │ (chunk 500, overlap 50) Embeddings Ollama (nomic-embed-text:latest)
Workflow 2 — Consulta (Chat RAG)
Chat Trigger (interfaz web pública) │ main ▼ AI Agent ← "Eres un agente en Nagasaki, asistente experto de Logos & Contexto..." ▲ ├── Ollama Chat Model (llama3:8b) ai_languageModel ├── Window Buffer Memory (últimas 10 turns) ai_memory └── Postgres PGVector Store (retrieve-as-tool) ai_tool ▲ └── Ollama Embeddings (nomic-embed-text) ai_embedding
El Window Buffer Memory con windowSize=10 mantiene las últimas 10 rondas de conversación en el contexto del agente, permitiendo que las preguntas de seguimiento referencien respuestas anteriores — algo imposible sin memoria explícita, dado que los LLMs son stateless por defecto.
RAG vs. Fine-tuning: cuándo usar cada uno
Una pregunta frecuente es si RAG no puede ser reemplazado simplemente por hacer fine-tuning del modelo con nuestros documentos. La respuesta corta: son soluciones a problemas distintos.
| Dimensión | RAG | Fine-tuning |
|---|---|---|
| Actualización de conocimiento | Inmediata — agrega documentos a la BD | Requiere reentrenamiento completo |
| Trazabilidad | Alta — chunks recuperados son auditables | Opaca — el conocimiento está en los pesos |
| Costo computacional | Bajo — solo inferencia + búsqueda vectorial | Alto — GPU hours para reentrenamiento |
| Estilo y tono | Limitado al modelo base | Superior — adapta personalidad y estilo |
| Conocimiento procedimental | Depende del contenido de los documentos | Superior — aprende patrones de razonamiento |
| Privacidad de datos | Alta — documentos nunca salen del servidor | Requiere enviar datos al proveedor de cómputo |
Para el caso de Logos & Contexto — un corpus de investigación en crecimiento continuo, con necesidad de trazabilidad documental y ejecutado completamente en infraestructura local — RAG es la elección correcta. El fine-tuning tiene sentido cuando el objetivo es cambiar el comportamiento del modelo, no su conocimiento factual.
El espacio vectorial como metáfora epistemológica
Hay algo filosóficamente interesante en la búsqueda vectorial que vale la pena explicitar. Cuando la computadora Nagasaki recibe la pregunta "¿qué papel juegan las arterias olvidadas en la estructura urbana de Cumaná?", el sistema no busca esas palabras exactas. Busca la región del espacio semántico donde vive ese concepto.
Si en mis documentos aparece un párrafo que dice "los ductos de distribución hídrica actúan como columna vertebral del tejido urbano histórico", ese fragmento estará geométricamente próximo a la consulta aunque no comparta ningún término. El modelo de embeddings ha aprendido que ductos de distribución y arterias son análogos funcionales, que tejido urbano y estructura urbana son sinónimos contextuales.
Esto es recuperación de información por similitud conceptual, no por coincidencia léxica. Y es exactamente lo que hace posible que un sistema responda preguntas sobre documentos usando formulaciones que los documentos mismos nunca usaron.
El vector no es el texto — es la huella semántica del texto en un espacio matemático donde la distancia es significado. Buscar en ese espacio es buscar ideas, no palabras.
Estado actual y próximos pasos
El sistema procesó exitosamente el documento Las arterias olvidadas de Cumaná (2026), generando 84 chunks vectorizados almacenados en documentos_investigacion con embeddings de 768 dimensiones. El workflow de consulta opera completamente en infraestructura local, sin dependencias externas de API.
- Ampliar el corpus con los demás documentos del archivo personal sobre geohistoria de la región.
- Implementar un índice HNSW a medida que el corpus crezca, para mantener la latencia de consulta por debajo de 100ms.
- Integrar el sistema con el Monitor Situacional Cumaná, permitiendo que los reportes ciudadanos enriquezcan automáticamente la base de conocimiento.
- Explorar modelos de embeddings multilingües para manejar la mezcla español/términos técnicos del corpus regional.
Este artículo documenta la implementación técnica de un sistema RAG local desarrollado en el marco de las actividades de investigación que adelanto, Cumaná, Venezuela. Todos los modelos de lenguaje e inferencia operan en hardware local sin transmisión de datos a servicios externos.
