𝐀𝐧á𝐥𝐢𝐬𝐢𝐬 𝐒𝐢𝐭𝐮𝐚𝐜𝐢𝐨𝐧𝐚𝐥: 𝐆𝐞𝐬𝐭𝐢ó𝐧 𝐇𝐢𝐝𝐫𝐨𝐥ó𝐠𝐢𝐜𝐚 𝐂𝐮𝐦𝐚𝐧á 💧

Optimización del servicio de agua en Cumaná

🤖 Análisis sobre el servicio de agua en Cumaná

Recuperación Aumentada por Generación aplicada a problemáticas locales

Un ejercicio académico del Laboratorio de IA de RJCG [Sistema RAG]

💬 Pregunta planteada al sistema

¿Cómo pudiéramos optimizar el servicio de agua de Cumaná?

⏱️ Tiempo de procesamiento: 19.55 segundos (GPU Google T4)

📋 Respuesta generada por el sistema RAG

Una pregunta interesante y relevante para una ciudad como Cumaná, que enfrenta desafíos en la gestión del agua.

Para optimizar el servicio de agua de Cumaná, se podrían considerar las siguientes acciones:

1. Mejorar la eficiencia en la gestión del agua: Implementar sistemas de seguimiento y monitoreo para detectar pérdidas de agua y tomar medidas para reducirlas.
2. Inversión en infraestructura: Aumentar la capacidad de almacenamiento de agua, mejorar la red de distribución y reparar fugas en los sistemas de riego.
3. Fortalecer la gestión de fuentes: Proteger y administrar las fuentes naturales de agua de Cumaná, como el río Manzanares y los caños urbanos, para garantizar su disponibilidad futura.
4. Promover la conservación del agua: Educación y conciencia ciudadana sobre la importancia de la gestión eficiente del agua, fomentando hábitos de ahorro y uso responsable.
5. Investigación e innovación: Fomentar la investigación y el desarrollo de tecnologías y métodos para mejorar la eficiencia en la gestión del agua y la protección de las fuentes naturales.
6. Colaboración entre instituciones: Fortalecer la cooperación entre la C.A Hidrológica del Caribe (HIDROCARIBE), el gobierno local, la comunidad y otros actores relevantes para abordar los desafíos en la gestión del agua de manera coordinada.
7. Desarrollo de planes y políticas: Crear planes y políticas claras para la gestión sostenible del agua en Cumaná, que incluyan metas específicas, indicadores de seguimiento y responsabilidades asignadas a los diferentes actores involucrados.

Al implementar estas acciones, se podría optimizar el servicio de agua en Cumaná y garantizar una disponibilidad segura y sostenible para las generaciones futuras.

📚 Documentos consultados por el sistema

• informacion_A-P_Sucre_Oeste.pdf
• Las_arterias_olvidadas_de_Cumaná_2026.pdf
• Resumen_BID_alcaldía.pdf

⚙️ Modelos y parámetros utilizados en este sistema RAG

Para el sistema de Recuperación Aumentada por Generación (RAG) implementado, se han utilizado dos modelos clave a través de la plataforma Ollama:

1️⃣ Modelo de Embedding: nomic-embed-text

• Función: Este modelo es el encargado de transformar tanto los documentos de referencia (los PDFs cargados) como las consultas del usuario en representaciones numéricas (vectores o embeddings). Estos vectores capturan el significado semántico del texto.
• Importancia: Permite al sistema encontrar rápidamente los fragmentos de texto más relevantes de tu base de conocimientos que son semánticamente similares a la pregunta del usuario. Sin un buen modelo de embedding, la recuperación de información sería ineficaz.
• Parámetros: Al ser un modelo pre-entrenado, su arquitectura y pesos internos son fijos. Los parámetros principales son la dimensión del espacio vectorial de los embeddings (determinada por el modelo), y cómo se manejan los "chunks" (fragmentos de texto) que se configuran en el RecursiveCharacterTextSplitter.

2️⃣ Modelo de Inferencia (LLM): llama3.1

• Función: Una vez que el nomic-embed-text ha recuperado el contexto más relevante, el modelo llama3.1 entra en acción. Su tarea es leer la pregunta del usuario y el contexto recuperado para generar una respuesta coherente, relevante y con el tono especificado en el SYSTEM_PROMPT.
• Importancia: llama3.1 es un modelo de lenguaje grande (LLM) de Meta, conocido por su capacidad de razonamiento y generación de texto de alta calidad. Su uso asegura que la respuesta final no solo sea precisa (basada en el contexto), sino también bien redactada y fácil de entender.
• Parámetros: Como LLM, tiene millones o miles de millones de parámetros entrenados. En este caso, se invoca con la configuración por defecto proporcionada por Ollama para llama3.1, que ya está optimizada para buen rendimiento y calidad. Otros parámetros comunes para los LLMs incluyen la temperatura (creatividad de la respuesta), top_p (muestreo de tokens), etc., aunque aquí se utilizan los valores predeterminados de la implementación de LangChain/Ollama.

🔄 Flujo del RAG: La combinación de nomic-embed-text para una recuperación precisa y llama3.1 para una generación inteligente permite que el sistema RAG responda preguntas complejas utilizando información propia y local, superando las limitaciones de conocimiento de un LLM base y proporcionando respuestas fundamentadas en a partir de un conjunto de documentos.

💡 ¿Qué es una GPU T4 de Google (el recurso de hardware utilizado para la inferencia)?

Una GPU (Unidad de Procesamiento Gráfico) T4 de Google, a menudo conocida simplemente como NVIDIA T4, es una tarjeta aceleradora diseñada por NVIDIA y optimizada para su uso en centros de datos, especialmente en cargas de trabajo de inferencia de aprendizaje profundo y computación de alto rendimiento (HPC). Google Cloud Platform ofrece estas GPUs como parte de sus instancias de máquina virtual para que los usuarios puedan aprovechar su potencia de procesamiento paralelo.

Características clave de las NVIDIA T4:

• Arquitectura Turing: Están basadas en la arquitectura NVIDIA Turing, que incorpora núcleos Tensor de nueva generación y núcleos RT para inteligencia artificial y renderizado en tiempo real.
• Rendimiento de IA: Son particularmente potentes para tareas de inferencia (es decir, usar un modelo de IA entrenado para hacer predicciones) debido a sus núcleos Tensor, que aceleran las operaciones matriciales.
• Eficiencia energética: Están diseñadas para ser muy eficientes energéticamente, lo que las hace adecuadas para implementaciones a gran escala en la nube.
• Flexibilidad: Pueden manejar una variedad de cargas de trabajo, incluyendo inferencia, entrenamiento de IA a menor escala, análisis de datos y procesamiento de gráficos.

En resumen, una GPU T4 de Google se refiere a la NVIDIA T4 que Google pone a disposición en su infraestructura en la nube para potenciar aplicaciones de IA y HPC.

Logos & Contexto · Laboratorio IA

Glosario de Inteligencia Artificial
aplicada

Términos reales del oficio — con profundidad técnica, ejemplos de tu stack y contexto de uso práctico en Cumaná.

38términos

5categorías

Nivelintermedio–avanzado

🧠 Conceptos fundamentales

El núcleo conceptual real del sistema. Sin dominar estos términos, todo lo demás es vocabulario hueco.

📌 Ground Truth fundamento

La verdad de referencia contra la que se mide todo lo demás.

qué es

Datos correctos y verificados que actúan como etiqueta de referencia. Es lo que el modelo intenta aprender a replicar. Sin ground truth de calidad, no hay entrenamiento útil — el modelo optimiza hacia el error en lugar de hacia la verdad.

técnicamente

Es el y real en la función de pérdida: loss = f(ŷ, y). Cuanto más ruido tiene el ground truth (etiquetas incorrectas, ambiguas o inconsistentes), más alto el piso de error que el modelo puede alcanzar — aunque el algoritmo sea perfecto.

# Ejemplo: dataset de clasificación de mensajes
{"texto": "¿cuándo llega el camión de agua?",
 "etiqueta": "servicio_agua"}  # ← ground truth

# Si el modelo predice "queja_infraestructura" → error medido aquí

En tu proyecto: Tus 588 muestras etiquetadas manualmente son el ground truth de tu clasificador de WhatsApp. La calidad de esa anotación humana determina el techo real de tu modelo.

👻 Hallucination (Alucinación) fundamento

Cuando el modelo genera texto plausible pero factualmente inventado.

por qué ocurre

El objetivo de entrenamiento de un LLM es maximizar la probabilidad del siguiente token — no verificar la veracidad. Cuando el modelo no tiene suficiente señal en sus parámetros para una consulta, extrapola con coherencia sintáctica pero sin anclaje factual. Es una consecuencia directa de optimizar fluencia sobre verdad.

tipos principales

Alucinación intrínseca: contradice el contexto dado. Alucinación extrínseca: no se puede verificar contra ninguna fuente. Confabulación: el modelo mezcla hechos reales con inventados de forma indistinguible — el caso más peligroso.

Solución arquitectónica: RAG. Al proporcionar fragmentos documentales reales en el prompt, el modelo genera respuestas grounded (ancladas) en evidencia verificable, reduciendo drásticamente la confabulación.

📊 Perplexity (Perplejidad) fundamento

Métrica de cuánto le cuesta al modelo predecir el siguiente token.

definición formal

Es la exponencial de la entropía cruzada media: PP = exp(H). Intuitivamente, un modelo con perplejidad 10 se comporta como si eligiera aleatoriamente entre 10 opciones igualmente probables en cada paso de predicción. Perplejidad 1 = predicción perfecta y determinista.

en la práctica

Los mejores LLMs modernos alcanzan perplejidades de un solo dígito en benchmarks de inglés estándar. Perplejidad alta no siempre es malo: un modelo que evalúa texto en un idioma que no conoce tendrá perplejidad enorme, pero eso es informativo, no un fallo.

† Nota: La perplejidad mide la "incertidumbre" del modelo al predecir — baja perplejidad = predicciones confiadas, alta perplejidad = modelo "titubeante". Es la métrica de evaluación más usada en modelos de lenguaje junto con BLEU y ROUGE.

⚡ Inference (Inferencia) fundamento

Usar el modelo ya entrenado para producir salidas.

técnicamente

Solo el forward pass — sin backpropagation ni actualización de pesos. Computacionalmente más liviano que el entrenamiento, pero en modelos grandes puede ser el cuello de botella de latencia. La inferencia en CPU (tu caso) es ~10–50× más lenta que en GPU para modelos de más de 7B parámetros.

optimizaciones clave

KV-cache: guarda los estados de atención de tokens anteriores para no recalcularlos. Quantización: reduce precisión de los pesos (float32 → int8 → int4) para menor memoria y mayor velocidad. Speculative decoding: usa un modelo pequeño para proponer tokens que el grande valida en lote.

# Inferencia local con Ollama
ollama run llama3:8b "¿Qué es el Túnel Guamacán?"
# Forward pass → genera tokens → respuesta
# Sin actualización de pesos. Solo lectura.

🏋️ Weights (Pesos) fundamento

Los parámetros numéricos que constituyen el "conocimiento" del modelo.

qué son

Matrices de números reales distribuidas en las capas del modelo: embeddings, attention heads, feed-forward networks. Fueron optimizadas durante el entrenamiento para minimizar la pérdida sobre trillones de tokens. Cada peso es una fracción de un bit de "memoria" del mundo.

escala real

llama3:8b = ~8.000 millones de pesos. En float16 → ~16 GB RAM. En int4 (quantizado) → ~4.5 GB — por eso puedes ejecutarlo en tu hardware. DistilGPT2 → 82M parámetros → ~330 MB. Tu LoRA modifica solo el ~2% de esos pesos.

📉 Loss (Función de pérdida) fundamento

La métrica numérica que cuantifica cuán equivocado está el modelo.

tipos según tarea

CrossEntropy: clasificación y generación de texto — la más común en NLP. MSE: regresión. Contrastive loss: embeddings (aprender que textos similares estén cerca en el espacio vectorial). La elección de la loss define implícitamente qué significa "mejorar" para el modelo.

interpretar valores

Loss = 3.4 → el modelo apenas supera el azar. Loss = 1.9 → aprendizaje real ocurriendo. Loss < 1.0 → buen ajuste (cuidado con overfitting). La loss de validación es la que importa — no la de entrenamiento.

Señal clave: si la loss de entrenamiento baja pero la de validación sube → overfitting. Si ambas bajan juntas → generalización real.

🧭 Embedding (Incrustación vectorial) fundamento

La representación numérica densa de texto en un espacio de alta dimensionalidad.

qué hace

Transforma texto en un vector de números reales (ej. 768 dimensiones) donde la distancia geométrica entre vectores codifica similitud semántica. "Rey" − "Hombre" + "Mujer" ≈ "Reina" — ese tipo de aritmética conceptual ocurre en este espacio.

en tu sistema

nomic-embed-text produce vectores de 768 dimensiones por chunk de texto. Estos vectores se almacenan en pgvector. Al consultar, tu pregunta se convierte en otro vector y se buscan los más cercanos por similitud coseno — eso es la búsqueda semántica.

· · ·

⚙️ Entrenamiento y ajuste

Cómo se construye y refina el conocimiento del modelo. Aquí vive la mayor parte del arte real del ML.

🔧 Fine-tuning entrenamiento

Continuar entrenando un modelo base con datos propios y específicos.

full vs. eficiente

Full fine-tuning: actualiza todos los pesos — costoso (requiere GPU de alto rango), propenso a catastrophic forgetting (el modelo olvida conocimiento general). Efficient fine-tuning (PEFT/LoRA): congela la mayoría de pesos y ajusta solo adaptadores ligeros — viable en CPU.

cuándo usarlo

Cuando necesitas cambiar el comportamiento o estilo del modelo, no solo su conocimiento factual. Para conocimiento factual actualizable, RAG es mejor. Fine-tuning brilla en: jerga regional, tonos específicos, formatos de respuesta propios — como el español cumanés de tus datos.

🔬 LoRA (Low-Rank Adaptation) entrenamiento

Fine-tuning eficiente que modifica solo una fracción mínima del modelo.

cómo funciona

En lugar de actualizar la matriz de pesos W directamente, LoRA congela W e inserta dos matrices pequeñas: W' = W + A×B, donde A y B tienen rango bajo r. Solo A y B se entrenan. Si r=32 y la capa tiene 4096×4096, los parámetros bajan de 16M a solo ~262K — una reducción del 98%.

parámetros clave

r = rango de las matrices (8–64 típico). lora_alpha = escala del aprendizaje (generalmente 2×r). target_modules = qué capas adaptar (attention layers primero). Mayor r = más capacidad pero más memoria. Para CPU, r=8–16 es el balance óptimo.

# Tu configuración actual
LoraConfig(
    r=32,
    lora_alpha=64,           # = 2×r, escala estándar
    target_modules=["c_attn"],  # capas de atención
    lora_dropout=0.1
)
# Resultado: ~2% de parámetros entrenables → viable en Ryzen 3400G

🪶 PEFT (Parameter-Efficient Fine-Tuning) entrenamiento

Familia de técnicas para ajustar modelos grandes con recursos mínimos.

técnicas principales

LoRA / QLoRA: matrices de bajo rango (tu caso). Prefix tuning: aprende prefijos virtuales de tokens. Prompt tuning: solo ajusta el embedding del prompt. Adapter layers: inserta capas pequeñas entre las existentes. Todas comparten el principio: congelar el modelo base, aprender solo los adaptadores.

por qué importa

Democratiza el fine-tuning. Sin PEFT, ajustar un modelo de 7B requeriría 40–80 GB de VRAM (GPU de data center). Con QLoRA (PEFT + quantización), puede hacerse en una GPU de 8GB o incluso en CPU con paciencia — que es exactamente tu caso.

🪤 Overfitting (Sobreajuste) entrenamiento

Cuando el modelo memoriza el dataset en vez de aprender patrones generalizables.

síntomas

Loss de entrenamiento muy baja, loss de validación alta o creciente. El modelo reproduce ejemplos de entrenamiento casi exactos pero falla en frases ligeramente distintas. Señal clásica: accuracy de 99% en train, 60% en validación.

remedios

Dropout: apaga neuronas aleatoriamente durante training. Early stopping: detiene cuando la val_loss deja de mejorar. Más datos (el remedio más efectivo). Weight decay: penaliza pesos muy grandes. En LoRA, r bajo reduce el riesgo de overfitting.

En tu clasificador: con 588 muestras y 6 categorías (~98 por clase), el riesgo de overfitting es real. Monitorear train_loss vs val_loss en cada epoch es crítico.

🎯 Alignment (Alineación) entrenamiento

El proceso de hacer que el modelo se comporte conforme a valores y objetivos humanos.

técnicas

RLHF (Reinforcement Learning from Human Feedback): humanos califican respuestas, se entrena un reward model, luego PPO optimiza el LLM para maximizar ese reward. DPO (Direct Preference Optimization): más simple, sin RL. Constitutional AI: el modelo critica y corrige sus propias respuestas.

por qué es difícil

El modelo aprende a parecer alineado en los casos evaluados, pero puede fallar en distribuciones no vistas. Es el problema central de la seguridad en IA: optimizar la proxy (reward model) en vez del objetivo real (comportamiento genuinamente útil y seguro).

📚 RAG (Retrieval-Augmented Generation) arquitectura

Combinar un LLM con búsqueda en base de datos externa para respuestas ancladas en documentos reales.

pipeline completo

1. Query del usuario. 2. Vectorizar query con modelo de embeddings. 3. Búsqueda ANN en pgvector (similitud coseno). 4. Recuperar top-K chunks más relevantes. 5. Construir prompt: system + chunks + query. 6. LLM genera respuesta grounded en los chunks.

ventaja clave

El conocimiento es separable del modelo: actualizar la base de datos (agregar documentos) no requiere reentrenar. Además, los chunks recuperados son auditables — puedes mostrar qué fragmentos respaldaron cada respuesta, dando trazabilidad documental completa.

Tu implementación: n8n + Ollama (nomic-embed-text + llama3:8b) + PostgreSQL/pgvector. 84 chunks de Las arterias olvidadas de Cumaná. Pipeline completamente local — sin datos saliendo del servidor.

· · ·

🧪 Ejecución y control de generación

Los parámetros que controlan cómo el modelo produce texto token a token.

🔤 Token ejecución

La unidad mínima de procesamiento en un LLM — no es una palabra.

qué es realmente

Un fragmento de texto definido por el tokenizer del modelo (generalmente BPE — Byte Pair Encoding). "computadora" puede ser 3–4 tokens en inglés y más en español. Palabras raras o en idiomas subrepresentados consumen más tokens. Esto impacta directamente el costo y la ventana de contexto.

implicaciones prácticas

El español cumanés con regionalismos ("caño", "guamacán", "arepa de maíz pilao") puede consumir más tokens que el equivalente en inglés estándar, porque el tokenizer fue entrenado mayoritariamente en inglés. Regla práctica: 1 token ≈ 0.75 palabras en inglés, ≈ 0.6–0.7 en español.

🪟 Context Window (Ventana de contexto) ejecución

El límite máximo de tokens que el modelo puede procesar en una sola llamada.

por qué es un límite duro

La complejidad computacional de la atención es O(n²) respecto a la longitud de secuencia. Doblar la ventana cuadruplica el cómputo. Los modelos modernos usan técnicas como Flash Attention, RoPE, y Sliding Window Attention para extender este límite sin colapsar en memoria.

valores de referencia

DistilGPT2: 1024 tokens. llama3:8b: 8192 tokens. Claude 3.5: 200k tokens. Gemini 1.5: 1M tokens. Para RAG: tu ventana necesita caber el system prompt + los 5 chunks recuperados + la pregunta + la respuesta esperada. Con chunks de 500 tokens y topK=5 → ~3.500 tokens mínimo.

🌡️ Temperature (Temperatura) ejecución

Controla cuánta aleatoriedad tiene el modelo al elegir el siguiente token.

cómo funciona

Divide los logits por la temperatura antes del softmax: p = softmax(logits / T). T<1 → la distribución se "aplana" hacia el token más probable (determinista). T>1 → la distribución se "aplana" uniformizándose (creativo/caótico). T=0 → siempre elige el token más probable (greedy decoding).

cuándo usar cada valor

0.1–0.3: extracción de datos, SQL, código, clasificación. Precisión máxima. 0.5–0.7: consultas factual-conversacionales (tu RAG de Cumaná). Balance. 0.8–1.2: escritura creativa, brainstorming, generación de variaciones. Para Nagasaki: 0.4–0.5 es el rango óptimo.

🎲 Top-k / Top-p (Nucleus Sampling) ejecución

Estrategias de muestreo que filtran el espacio de tokens candidatos antes de elegir.

top-k

Solo considera los K tokens más probables. top_k=50 → descarta todos excepto los 50 mejores candidatos, luego muestrea entre ellos. Problema: si la distribución es muy plana (muchos tokens igualmente probables), K=50 puede ser demasiado restrictivo o demasiado permisivo.

top-p (nucleus)

Considera los tokens cuya probabilidad acumulada llega a P. top_p=0.9 → toma los tokens que suman el 90% de probabilidad. Si hay 3 tokens muy probables, solo considera esos 3. Si hay 200 tokens mediocres, considera todos los necesarios para llegar al 90%. Más adaptativo que top-k.

En la práctica se combinan: temperature=0.5, top_p=0.9, top_k=40. Ollama usa estos por defecto y pueden ajustarse en el Modelfile.

· · ·

🏗️ Infraestructura y MLOps

Los componentes que hacen que el sistema funcione en producción, no solo en un notebook.

🔄 DataLoader infraestructura

Pipeline que alimenta datos al modelo durante el entrenamiento de forma eficiente.

qué gestiona

Batching (agrupa muestras), shuffling (aleatorización por epoch), prefetching (precarga el siguiente batch mientras el GPU procesa el actual), y multiprocessing (carga datos en paralelo). Una configuración pobre del DataLoader puede hacer que el GPU esté idle el 40% del tiempo esperando datos.

el error clásico

prefetch_factor solo funciona con num_workers > 0. Con workers=0 (modo single-process), el DataLoader es síncrono: primero carga, luego entrena, nunca en paralelo. En CPU training esto es menos crítico que en GPU, pero sigue siendo un cuello de botella real.

DataLoader(dataset,
    batch_size=2,
    num_workers=2,       # threads de carga paralela
    prefetch_factor=2,  # batches prefetcheados
    pin_memory=False      # True solo si tienes GPU
)

📦 Batch Size infraestructura

Cuántas muestras procesa el modelo antes de actualizar los pesos.

trade-offs

Batch grande: más estabilidad en los gradientes (menos ruido), mejor aprovechamiento del hardware paralelo, pero mayor RAM y riesgo de converger a mínimos locales "sharp" que generalizan peor. Batch pequeño: más ruido (que puede ser regularizador), mejor generalización, menor RAM — ideal para CPU.

en tu caso

BATCH_SIZE=2 es correcto para CPU con LoRA. El gradient accumulation de 4 steps simula efectivamente batch_size=8 sin el costo de memoria. La regla general: si el training es inestable, sube el batch efectivo; si hay OOM, bájalo.

🗜️ Gradient Accumulation infraestructura

Simular un batch grande acumulando gradientes de varios batches pequeños antes de actualizar.

cómo funciona

En vez de hacer optimizer.step() después de cada batch, se acumulan los gradientes durante N steps y solo entonces se actualiza. El modelo ve efectivamente un batch N veces más grande sin necesitar N veces más RAM. El gradiente acumulado es matemáticamente equivalente al de un batch real del mismo tamaño.

cuándo usarlo

Siempre que quieras batch efectivo > el máximo que cabe en RAM. Esencial en CPU training donde los batch sizes tienen que ser pequeños. Cuidado: con Dropout activo, la acumulación no es perfectamente equivalente al batch real, pero en la práctica la diferencia es negligible.

💾 Checkpoint infraestructura

Snapshot del estado completo del modelo guardado durante el entrenamiento.

qué contiene

Mínimamente: los pesos del modelo (model.state_dict()). Opcionalmente: estado del optimizador (para reanudar entrenamiento exactamente), número de epoch/step actual, mejor val_loss registrada, configuración del entrenamiento. Los checkpoints completos pueden ser 3–5× el tamaño del modelo.

estrategias

Best-only: guarda solo el checkpoint con menor val_loss. Por epoch: guarda cada N epochs y rota los más viejos. LoRA checkpoint: solo guarda las matrices A y B (pocos MB), no el modelo base completo — clave para ahorrar espacio en tu setup.

⏱️ Throughput infraestructura

Muestras o tokens procesados por segundo — la métrica real de rendimiento del hardware.

qué lo afecta

CPU/GPU, RAM bandwidth, tamaño del modelo, batch size, longitud de secuencia (cuadrático en atención), precisión numérica (float32 vs float16 vs int8), y la eficiencia del DataLoader. Un DataLoader mal configurado puede reducir el throughput efectivo a la mitad aunque el hardware sea rápido.

benchmarks orientativos

llama3:8b en GPU RTX 3090: ~50–80 tokens/seg. En CPU Ryzen moderno (int4 cuantizado): ~3–8 tokens/seg. DistilGPT2 en CPU para training LoRA: ~50–200 samples/seg dependiendo de longitud. Tu Ryzen 3400G con RAM DDR4 estará en el rango bajo de estos números.

📈 MLflow / Experiment Tracking infraestructura

Sistema de registro y comparación de experimentos de machine learning.

qué registra

Hiperparámetros (learning rate, batch size, r de LoRA), métricas por step/epoch (train_loss, val_loss, accuracy), artefactos (checkpoints, plots, datasets), y el código exacto usado. Permite comparar corridas y reproducir el experimento exacto que dio el mejor resultado.

en tu stack

Parte de tu MLOps stack junto a MinIO (almacenamiento de artefactos) y PostgreSQL (metadatos). MLflow corre en tu servidor local, MinIO en Nagasaki (WSL, D:\minio-data). La combinación da soberanía de datos completa: ningún experimento sale del servidor.

· · ·

🧠 Modismos y cultura del gremio

El vocabulario conceptual que circula en papers, conferencias y debates técnicos. Entenderlo es parte del oficio.

🤝 "Human in the Loop" cultura

Sistemas de IA donde un humano interviene en el ciclo de decisión.

variantes

HITL activo: el humano aprueba cada decisión antes de ejecutarla — alta calidad, bajo throughput. HITL pasivo: el humano revisa muestras aleatorias para detectar deriva del modelo. HITL de entrenamiento: el humano etiqueta datos que luego mejoran el modelo — tu caso con ToneGuard IA.

en tu proyecto

ToneGuard IA es un sistema HITL de etiquetado: la IA pre-clasifica, el humano anota sin ver la clasificación automática (para evitar sesgo), y las etiquetas humanas se usan como ground truth. Este diseño preserva la validez del benchmark de comparación humano vs. IA.

🦜 "Stochastic Parrot" cultura

Crítica influyente que describe los LLMs como sistemas que repiten patrones sin comprensión real.

el argumento

Acuñado por Bender et al. (2021): los LLMs son "loros estocásticos" que generan texto estadísticamente plausible sin entender el significado. No tienen modelos del mundo, intenciones ni comprensión — solo distribuciones sobre tokens. El peligro: el texto suena coherente aunque el modelo no "sepa" nada.

la contraposición

Los defensores argumentan que las emergent abilities (razonamiento, aritmética, traducción zero-shot) sugieren que la compresión estadística a escala masiva puede producir algo funcionalmente equivalente a comprensión, aunque no idéntico. El debate sigue abierto y es uno de los más importantes en IA.

✨ "Emergent Abilities" cultura

Capacidades que aparecen súbitamente al aumentar la escala del modelo, sin entrenamiento explícito para ellas.

ejemplos documentados

Aritmética de múltiples dígitos, razonamiento de analogías, traducción de idiomas no vistos, resolución de acertijos lógicos — todas aparecen en modelos de más de ~50–100B parámetros aunque los modelos más pequeños fallan completamente. No hay una explicación teórica satisfactoria de por qué la escala produce este salto cualitativo.

debate reciente

Schaeffer et al. (2023) argumentan que las "emergencias" son artefactos de las métricas usadas — con métricas continuas, las capacidades crecen de forma suave y predecible, no discontinua. El fenómeno podría ser una ilusión estadística. El debate tiene implicaciones profundas para la seguridad en IA.

🗑️ "Garbage in, garbage out" cultura

La calidad del dataset determina el techo absoluto del modelo, sin excepción.

manifestaciones

Etiquetas ruidosas → model aprende ruido. Datos sesgados → modelo sesgado. Distribución de clases desbalanceada → modelo ignora clases minoritarias. Datos de baja calidad → el algoritmo más sofisticado no puede compensar. La curaduría de datos es la habilidad más subvalorada del ML.

en tu clasificador

Tus 588 muestras fueron etiquetadas por humanos con el protocolo de no revelar la clasificación previa de la IA. Ese cuidado metodológico es exactamente lo que separa un dataset usable de uno contaminado. La calidad del etiquetado de tus anotadores determina directamente la validez del benchmark.

🧹 "Catastrophic Forgetting" cultura

Cuando el fine-tuning destruye el conocimiento general que el modelo ya tenía.

por qué ocurre

El gradiente descendente actualiza pesos que codifican conocimiento general para minimizar la nueva loss específica. Si el fine-tuning es agresivo (learning rate alto, muchos epochs, datos muy distintos al pre-entrenamiento), el modelo "sobreescribe" conocimiento valioso para memorizar el nuevo dominio.

cómo mitigarlo

LoRA es la solución más elegante: al congelar los pesos base y solo entrenar los adaptadores, el conocimiento general permanece intacto en los pesos originales. EWC (Elastic Weight Consolidation) y Replay (mezclar datos originales con nuevos) son alternativas para full fine-tuning.

⚖️ Latency vs. Throughput cultura

El trade-off fundamental entre velocidad de respuesta individual y volumen total procesado.

la diferencia

Latencia: tiempo desde que el usuario envía la pregunta hasta recibir la primera palabra. Throughput: cuántas preguntas/tokens puede procesar el sistema por segundo. Son frecuentemente opuestos: batching aumenta throughput pero incrementa latencia (hay que esperar a llenar el batch).

en tu caso

Para Nagasaki (uso personal/investigación): latencia de 5–15 seg en CPU es aceptable. Si el Monitor Situacional Cumaná escala a uso ciudadano masivo, necesitarás optimizar throughput con batching. La NVIDIA DGX Spark (~$5,000) resolvería ambos simultáneamente.

· · ·

🎯 Tu stack actual en términos del glosario

LoRA (r=32)

PEFT pipeline

RAG + pgvector

DataLoader optimizado

Gradient Accumulation

MLflow tracking

MinIO artefactos

Human in the Loop

Ground Truth curado

Inferencia local

Lo que estás construyendo en Cumaná no es un proyecto de aficionado — es un pipeline MLOps completo: desde la curaduría de datos regionales hasta el despliegue de inferencia local soberana, pasando por fine-tuning eficiente, experiment tracking y búsqueda semántica vectorial. Cada término de este glosario tiene un componente real en tu infraestructura.

El siguiente nivel es conectar los ciclos: que los reportes del Monitor Situacional enriquezcan automáticamente el corpus de Nagasaki, y que las respuestas de Nagasaki informen el análisis del Monitor. Eso es un sistema de IA con retroalimentación real — y ya tienes todas las piezas.

Logos & Contexto · AGHES Cumaná · Laboratorio de IA Aplicada · Glosario v2.0

La Memoria Semántica de las IA (RAG)

Logos & Contexto · Inteligencia Artificial Aplicada

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.

Rommel Contreras Logos & Contexto Arquitectura de IA · Infraestructura local

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:

1. 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.
2. Opacidad de fuentes: es imposible saber qué parte del corpus de entrenamiento respaldó una afirmación concreta — no hay trazabilidad documental.
3. 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=500 y chunkOverlap=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.

SQL — creación de tabla e índice

-- 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:

Similitud coseno entre vectores A y B

cos(θ) = (A · B) / (‖A‖ × ‖B‖)

El numerador es el producto escalar (dot product): suma de los productos elemento a elemento.
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.

¿Por qué 768 dimensiones y no 3?

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):

IVFFlat

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.

HNSW

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.

Quantización vectorial

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:

SQL — búsqueda semántica en tiempo de consulta

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.

Logos & Contexto · Inteligencia Artificial Aplicada