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á.
El núcleo conceptual real del sistema. Sin dominar estos términos, todo lo demás es vocabulario hueco.
La verdad de referencia contra la que se mide todo lo demás.
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.
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í
Cuando el modelo genera texto plausible pero factualmente inventado.
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.
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.
Métrica de cuánto le cuesta al modelo predecir el siguiente token.
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.
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.
Usar el modelo ya entrenado para producir salidas.
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.
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.
Los parámetros numéricos que constituyen el "conocimiento" del modelo.
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.
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.
La métrica numérica que cuantifica cuán equivocado está el modelo.
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.
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.
La representación numérica densa de texto en un espacio de alta dimensionalidad.
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.
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.
Cómo se construye y refina el conocimiento del modelo. Aquí vive la mayor parte del arte real del ML.
Continuar entrenando un modelo base con datos propios y específicos.
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.
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.
Fine-tuning eficiente que modifica solo una fracción mínima del modelo.
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%.
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
Familia de técnicas para ajustar modelos grandes con recursos mínimos.
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.
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.
Cuando el modelo memoriza el dataset en vez de aprender patrones generalizables.
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.
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.
El proceso de hacer que el modelo se comporte conforme a valores y objetivos humanos.
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.
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).
Combinar un LLM con búsqueda en base de datos externa para respuestas ancladas en documentos reales.
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.
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.
Los parámetros que controlan cómo el modelo produce texto token a token.
La unidad mínima de procesamiento en un LLM — no es una palabra.
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.
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.
El límite máximo de tokens que el modelo puede procesar en una sola llamada.
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.
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.
Controla cuánta aleatoriedad tiene el modelo al elegir el siguiente token.
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).
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.
Estrategias de muestreo que filtran el espacio de tokens candidatos antes de elegir.
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.
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.
temperature=0.5, top_p=0.9, top_k=40. Ollama usa estos por defecto y pueden ajustarse en el Modelfile.Los componentes que hacen que el sistema funcione en producción, no solo en un notebook.
Pipeline que alimenta datos al modelo durante el entrenamiento de forma eficiente.
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.
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 )
Cuántas muestras procesa el modelo antes de actualizar los pesos.
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.
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.
Simular un batch grande acumulando gradientes de varios batches pequeños antes de actualizar.
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.
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.
Snapshot del estado completo del modelo guardado durante el entrenamiento.
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.
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.
Muestras o tokens procesados por segundo — la métrica real de rendimiento del hardware.
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.
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.
Sistema de registro y comparación de experimentos de machine learning.
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.
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.
El vocabulario conceptual que circula en papers, conferencias y debates técnicos. Entenderlo es parte del oficio.
Sistemas de IA donde un humano interviene en el ciclo de decisión.
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.
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.
Crítica influyente que describe los LLMs como sistemas que repiten patrones sin comprensión real.
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.
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.
Capacidades que aparecen súbitamente al aumentar la escala del modelo, sin entrenamiento explícito para ellas.
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.
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.
La calidad del dataset determina el techo absoluto del modelo, sin excepción.
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.
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.
Cuando el fine-tuning destruye el conocimiento general que el modelo ya tenía.
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.
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.
El trade-off fundamental entre velocidad de respuesta individual y volumen total procesado.
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).
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.
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.
