I’ve updated the AI Workshop for curious people.

About 130 more slides have been added on: classical ML applied, BFS/DFS/A* search, SAT/CSP, planning/PDDL, games with minimax/MCTS, RDF/OWL/SPARQL and ontologies, RAG vs Knowledge Graph, classical and modern agents, and practical labs to carry out.

It has been added from the syllabus of the subject Artificial Intelligence and Knowledge Engineering of the Software Engineering Degree.

More formulas, examples, sources…, but for everyone. Trying to explain it from the ground up.

https://workshop-ia-2026.686f6c61.dev

** If you keep sending me feedback via DM, I’ll keep improving it. The previous update had 28K visits. Thanks.

---

Workshop de IA para gente curiosa

Source: https://workshop-ia-2026.686f6c61.dev/ Agentes, modelos y herramientas - by 686f6c61

Mayo 2026 (Update: 05/26)

Actualización del día · 16 mayo 2026

Nuevos bloques: IA clásica, ML, agentes, evals, operación, seguridad, laboratorios y UX de IA.

Usa las flechas←→del teclado o los botones para navegar.

01

Fundamentos

Qué es (y qué no es) la inteligencia artificial, cómo funcionan los tokens, embeddings y el ciclo de entrenamiento e inferencia.

02¿Qué NO es la IA?

• **No es magia ni ciencia ficción.**No hay una “mente” dentro de la máquina. Es software, ejecutándose en servidores, con electricidad y silicio.
• **No es una mente consciente.**No tiene deseos, emociones ni intenciones. No “quiere” nada. Procesa tokens y calcula probabilidades.
• **No es un buscador glorificado.**Un buscador recupera páginas o documentos. Un LLM (Large Language Model, modelo grande de lenguaje) genera texto a partir de patrones aprendidos y no consulta fuentes por defecto.
• **No “piensa” como un humano.**Puede producir pasos que parecen razonamiento, pero su mecanismo base es predecir tokens a partir de patrones aprendidos.
• **No es infalible ni objetiva.**Puede alucinar (generar información falsa con confianza), heredar sesgos de los datos de entrenamiento y carece de introspección fiable sobre sus errores.

No piensa

No tiene procesos cognitivos. Calcula distribuciones de probabilidad sobre secuencias de tokens.

No es consciente

No tiene experiencia subjetiva, ni autoconciencia, ni modelo del mundo. Es una función matemática muy compleja.

No entiende como una persona

Aprende representaciones estadísticas de tokens y conceptos. Puede comportarse como si entendiera, pero no tiene experiencia ni criterio propio.

No es magia

Es álgebra lineal, cálculo matricial y optimización por gradiente. Impresionante, pero explicable.

Idea clave

Si entiendes que la IA no piensa, no entiende y no razona como un humano, puedes usarla mejor: le darás instrucciones más precisas y confiarás menos ciegamente en sus respuestas.

03¿Qué SÍ es la IA?

Modelos matemáticos masivos

Redes neuronales con miles de millones o billones de parámetros ajustados para reconocer patrones en texto, imágenes, código y audio.

Reconocimiento de patrones a escala

Lo que un humano tarda horas en analizar, el modelo lo procesa en segundos. Detecta correlaciones estadísticas, no “entiende”.

Predicción estadística del siguiente token

Dada una secuencia de tokens, cuál es el más probable a continuación. Esto, repetido miles de veces, produce párrafos coherentes.

Amplificador de capacidades

Si sabes programar, te hace más rápido. Si no sabes, te da una falsa sensación de que funciona... hasta que deja de hacerlo.

Hitos clave de la IA moderna

FechaHitoPor qué importa2017TransformerArquitectura “Attention Is All You Need”. Base de todo lo que vino después.2020GPT-3175B parámetros. Demostró que escalar funciona: más datos + más parámetros = más capacidad.2022ChatGPTRLHF (Reinforcement Learning from Human Feedback, aprendizaje por refuerzo con feedback humano) + interfaz de chat. La IA se hace accesible al público general.2023GPT-4Multimodal y razonamiento avanzado. Salto cualitativo en capacidades.2024Claude 3 / GeminiCompetencia real. Contextos de 200k+ tokens. IA como herramienta de trabajo diaria.2025-26Era de agentesIA que ejecuta tareas completas: navega, programa, despliega. Claude Code, Devin, agentes autónomos.Idea clave

La IA no sustituye el criterio humano. Lo amplifica. Si le das contexto claro y restricciones precisas, el resultado es impresionante. Si le das ambigüedad, el resultado es impredecible.

04¿Qué es un sistema determinista y por qué la IA no lo es?

Sistema determinista

Misma entrada → siempre la misma salida. Un compilador, una query SQL, una función pura. Quienes programamos estamos entrenados para pensar así:f\(x\) = y, siempre.

functionsumar(a, b) { returna + b; }

Sistema estocástico (la IA)

Misma entrada → salidaspotencialmente diferentes. El modelo puede muestrear de una distribución de probabilidades. Cada ejecución puede dar un resultado distinto según configuración e infraestructura.

prompt:“Explica qué es Rust”

¿Por qué ocurre esto?

El modelo no devuelve “la respuesta correcta”. Calcula una distribución de probabilidades sobre todos los tokens posibles ymuestreade ella. Los parámetrostemperature,top\-pytop\-kcontrolan cuánta aleatoriedad se permite. Contemperature=0se acerca al determinismo, pero no lo garantiza (hay variaciones por precisión numérica y batching).

Del prompt al token: flujo de generación

Texto de entrada→Tokenización→Distribución de probabilidades→Muestreo (temp, top-p, top-k)→Token elegido

Consecuencia práctica

No basta con un test unitario que espere una frase exacta. Cambia la mentalidad: de “esto devuelve X” a “esto devuelve algo razonable dentro de un rango”. Estrategias: evaluaciones (evals), validación de estructura, asserts sobre propiedades y no solo sobre valores exactos.

Conexión con la slide 27

Los parámetrostemperature,top\-pytop\-kse explican en detalle en la slide de parámetros de configuración. Allí verás cómo ajustarlos según tu caso de uso.

05Principios de la IA

Aprendizaje supervisado

Le das ejemplos etiquetados (entrada → salida esperada) y el modelo aprende a generalizar. Es la base del fine-tuning.

Aprendizaje no supervisado

El modelo encuentra patrones en datos sin etiquetar. Así se pre-entrenan los LLMs: prediciendo la siguiente palabra en textos masivos.

Post-training con preferencias y refuerzo

RLHF = Reinforcement Learning from Human Feedback. Es una técnica de post-training: humanos puntúan o comparan respuestas y esa señal ayuda a alinear el modelo. No es la única: también se usan SFT, DPO, RLAIF, RFT y refuerzo verificable.

Atención (Transformers)

El mecanismo que lo cambió todo. Permite al modelo mirar todas las palabras de la entrada simultáneamente y decidir cuáles son relevantes para cada predicción.

Scaling Laws (leyes de escala)

Más datos + más parámetros + más compute = modelo más capaz. No es magia: es una relación predecible (Kaplan et al., 2020). Explica por qué la industria invierte miles de millones en clusters de GPUs.

06La neurona artificial

Todo empieza aquí. Una neurona artificial es unafunción matemáticaque recibe números, los multiplica por pesos, suma un sesgo y aplica una función de activación.

En código

functionneurona(inputs, weights, bias) { constsum = inputs.reduce((acc, x, i) => acc + x * weights[i], 0); returnactivation(sum + bias); }

neurona([0.5, 0.3, 0.8], [0.2, -0.4, 0.7], 0.1);

Funciones de activación

FunciónFórmulaCuándo se usaReLUmax\(0, x\)Capas ocultas. La más usada por su simplicidad y eficienciaSigmoid1 / \(1 \+ e^\-x\)Salida entre 0 y 1. Clasificación binariaSoftmaxNormaliza a probabilidadesCapa final. Distribución de probabilidades sobre clasesTanh\(e^x \- e^\-x\) / \(e^x \+ e^\-x\)Salida entre -1 y 1. Usada en RNNs/LSTMsPara gente curiosa

Una neurona es una función pura con parámetros aprendidos (pesos y bias). La “inteligencia” no está en una neurona individual: está en losmiles de millones de parámetrosajustados durante el entrenamiento. En modelos propietarios como Claude o GPT, el proveedor no publica siempre el número exacto de pesos.

07Redes neuronales: capas y arquitectura

Una red neuronal es ungrafo de neuronas organizadas en capas. Cada capa transforma los datos y los pasa a la siguiente.

Estructura de una red (MLP)

Input layer (tus datos)→Hidden layer 1 (patrones simples)→Hidden layer 2 (patrones complejos)→Output layer (predicción)

¿Qué aprende cada capa?

Capas tempranas

Detectan patrones simples: bordes, colores, frecuencias. En texto: n-gramas, patrones sintácticos

Capas intermedias

Combinan patrones simples en conceptos: formas, texturas, relaciones entre palabras

Capas profundas

Abstracciones de alto nivel: objetos completos, significado semántico, razonamiento

“Deep” learning = muchas capas

Una red con 2-3 capas es “shallow”. Con decenas o cientos de capas es “deep”. En modelos propietarios, si el proveedor no publica el número de capas, lo correcto es marcarlo como no publicado en vez de afirmarlo como dato. Más capas suelen aportar más capacidad de abstracción, pero aumentan latencia, memoria y dificultad de entrenamiento.

08Cómo aprende una red: backpropagation

El entrenamiento es unbucle: predice, mide el error, ajusta los pesos, repite. Miles de millones de veces.

El bucle de entrenamiento

1. Forward pass (datos → predicción)→2. Calcular loss (predicción vs realidad)→3. Backward pass (calcular gradientes)→4. Actualizar pesos (gradient descent)↻

En pseudocódigo

forepochinrange(num_epochs): forbatchindataloader: prediction = model.forward(batch.input) loss = loss_fn(prediction, batch.target) loss.backward() optimizer.step() optimizer.zero_grad()

Analogía: bajar una montaña con niebla

Imagina que estás en una montaña con niebla y quieres llegar al valle (mínimo de la función de pérdida). No ves el camino, pero puedes sentir la pendiente bajo tus pies. En cada paso, avanzas en la dirección que baja más (gradiente). Ellearning ratees el tamaño del paso: muy grande y te pasas del valle, muy pequeño y tardas una eternidad.

09Funciones de pérdida y optimizadores

Lafunción de pérdidamide cuánto se equivoca el modelo. Eloptimizadordecide cómo ajustar los pesos para reducir ese error.

Funciones de pérdida principales

FunciónCuándo se usaQué mideCross-EntropyClasificación, LLMsDiferencia entre distribución predicha y real. La que usan los LLMs: mide si el token predicho es el correctoMSERegresiónMedia del cuadrado de los errores. Para predecir valores numéricosContrastive LossEmbeddingsAcercar ejemplos similares y alejar los diferentes en el espacio vectorial### Optimizadores

OptimizadorIdea claveUsoSGDGradient descent con mini-batchesSimple, funciona bien con buen tuningAdamLearning rate adaptativo por parámetroEl más usado. Funciona bien “out of the box”AdamWAdam + weight decay correctoEl estándar para entrenar LLMs y transformers### Problemas comunes del entrenamiento

Overfitting

El modelo memoriza los datos de entrenamiento pero falla con datos nuevos. Solución: dropout, regularización, más datos

Vanishing gradients

Los gradientes se hacen tan pequeños que las capas profundas no aprenden. Solución: ReLU, skip connections, normalización

10CNNs: redes convolucionales para visión

LasConvolutional Neural Networksrevolucionaron la visión por computador. En vez de mirar cada píxel por separado, aplicanfiltrosque detectan patrones locales.

Flujo de una CNN

Imagen (píxeles)→Convoluciones (filtros)→Pooling (reducir)→Más conv + pool→Clasificación

Conceptos clave

Convolución

Un filtro pequeño (3x3, 5x5) que se desliza por la imagen. Detecta un patrón local: borde horizontal, esquina, textura. Múltiples filtros detectan múltiples patrones

Pooling

Reduce la resolución manteniendo la información importante. Max pooling: toma el valor máximo de cada zona. Hace la red invariante a pequeños desplazamientos

Feature maps

La salida de cada capa de convolución. Capas tempranas: bordes y colores. Capas profundas: ojos, ruedas, letras. La red “aprende” qué patrones son relevantes

Skip connections (ResNet)

Atajos que permiten que la información salte capas. Resolvió el problema de entrenar redes muy profundas (100+ capas). Innovación clave de 2015

Relevancia actual

Las CNNs siguen siendo la base de la visión por computador (detección de objetos, segmentación). Los Vision Transformers (ViT) las están reemplazando en algunas tareas, pero las CNNs dominan en edge/móvil por su eficiencia. Stable Diffusion usa un U-Net (basado en CNNs) para el denoising.

11RNNs y LSTMs: redes para secuencias

Antes de los Transformers, lasRecurrent Neural Networkseran la forma de procesar secuencias (texto, audio, series temporales). Entenderlas explica por qué el Transformer fue revolucionario.

Cómo funciona una RNN

Token 1→RNN (hidden state)→Token 2 + state→RNN (actualiza state)→Token 3 + state...

Procesa un token a la vez, manteniendo un “estado oculto” (hidden state) que resume todo lo que ha visto antes. El problema: al llegar al token 500, ya ha “olvidado” el token 1.

RNN vs LSTM vs Transformer

RNNLSTMTransformerProcesamientoSecuencialSecuencialParaleloMemoriaCorto plazoLargo plazo (gates)Toda la secuenciaContexto máximo~100 tokens~500 tokens128K-1M+ tokensParalelizableNoNoSí (GPUs)VelocidadLentaLentaRápida¿Por qué el Transformer ganó?

Dos razones: (1)paralelismo: mira todos los tokens a la vez, aprovechando GPUs masivamente paralelas. (2)atención: en vez de comprimir todo en un hidden state fijo, cada token puede “mirar” directamente a cualquier otro token de la secuencia. Más detalles en la slide de Transformers.

12¿Qué es un token?

Un token es launidad discretaque procesa el modelo. Puede ser una palabra, parte de una palabra, un carácter o incluso bytes, según el tokenizador y el vocabulario.

Ejemplos de tokenización

“Hola mundo”→ [“Hola”,“ mundo“] “desarrolladores”→ [“des”,“arrol”,“ladores”] “function getName()”→ [“function”,“ get“,“Name”,“()”]

Palabras frente a tokens

Como regla muy aproximada, 1 token suele rondar 3-4 caracteres en texto latino. Idioma, símbolos, código y tokenizador cambian mucho el resultado.

FrasePalabrasTokens (aprox.)Ratio“Hello world“221:1“Hola mundo“22-3~1:1.25“Machine learning is great“441:1“El aprendizaje automático es genial“57-81:1.5const getData = async \(\) =\> \{\}710-121:1.6- En español a menudo se gastan más tokensque en inglés para decir lo mismo, aunque el porcentaje depende del tokenizador y del texto.

• **El modelo no ve texto:**ve secuencias de números (IDs de token). Cada token tiene un ID único en el vocabulario del modelo.
• **Todo se mide en tokens:**el context window, el precio de la API, el límite de respuesta. Es la “moneda” de la IA.
• **Regla rápida:**1 token suele ser menos que una palabra; úsalo solo como estimación inicial.

13¿Qué es un embedding?

Un embedding es unarepresentación numéricade una palabra, frase, imagen, código o documento. Convierte el contenido en un vector de cientos o miles de números para poder comparar cercanía semántica.

¿Qué es una dimensión?

Un vector de embedding tiene cientos o miles de componentes. Las dimensiones no suelen tener una etiqueta humana limpia; lo importante es la posición global del vector y sus distancias respecto a otros vectores.

“gato”→ [ 0.23, -0.87, 0.45, 0.12, ... ]

“felino”→ [0.21, -0.85, 0.48, 0.11, ...] “JavaScript”→ [-0.56, 0.33, -0.12, 0.78, ...]

Más dimensiones = más matices

Con más dimensiones hay más capacidad para separar matices, aunque la calidad no depende solo del tamaño: importan los datos, el objetivo de entrenamiento y el tipo de contenido.

Analogía: espacio semántico

Imagina un mapa donde las palabras se colocan según su significado. “Perro” y “gato” están cerca (ambos son animales). “Python” y “JavaScript” están cerca (ambos son lenguajes). Pero “perro” y “Python” están lejos. El embedding es la coordenada de cada palabra en ese mapa de miles de dimensiones.

14Embeddings en la práctica

Aritmética de significado

Los embeddings pueden capturar relaciones semánticas que a veces aparecen como operaciones vectoriales aproximadas:

rey - hombre + mujer ≈reina Madrid - España + Francia ≈Paris Python - scripting + compilado ≈Go

Similitud semántica

Par de palabrasSimilitud cosenoInterpretación“gato“ / “felino“altaMuy cercanos: cuasi-sinónimos“gato” / “perro“media-altaCercanos: misma categoría (animal)“gato” / “coche“bajaLejanos: conceptos poco relacionados“deploy” / “desplegar“altaCercanos en un buen modelo multilingüeLa clave:conceptos similares quedancercaen el espacio vectorial. Esto permite buscar por significado, no por palabras exactas.

¿Para qué sirven?

• **Búsqueda semántica:**encontrar documentos por significado (“¿cómo despliego en producción?” encuentra docs sobre “deploy to prod”)
• **RAG (Retrieval-Augmented Generation):**así se buscan los fragmentos relevantes para inyectar en el prompt del modelo
• **Clasificación:**agrupar textos similares automáticamente (tickets de soporte, emails...)
• **Detección de duplicados:**comparar si dos textos dicen lo mismo con palabras diferentes

Modelos de embedding (mayo 2026)

ModeloEmpresaDimensionesPunto fuertetext-embedding-3-largeOpenAI3072 por defecto; configurableAlta calidad general para inglés y multilingüe. API madura y coste predecible.voyage-4-large / voyage-4 / voyage-4-liteVoyage AI1024 por defecto; 256, 512, 2048Muy fuerte para RAG general y multilingüe. Matryoshka y cuantización para reducir coste de vector DB.gemini-embedding-001Google3072 por defecto; reducibleModelo unificado para inglés, multilingüe y código. Buena opción si ya usas Vertex/Gemini.Qwen3-EmbeddingQwen (open weights)1024 / 2560 / 4096 según tamaño0.6B, 4B y 8B. 100+ idiomas, 32k contexto, MRL (Matryoshka Representation Learning) y ejecución self-host.BGE-M3BAAI (open source)1024Multilingüe (100+ idiomas), 8192 tokens y retrieval híbrido: denso + sparse + multi-vector.Cohere embed-v4.0Cohere1536 por defecto; 256, 512, 1024, 1536Embeddings multimodales texto/imagen/PDF, Matryoshka y contexto 128k.codestral-embedMistral AI1536 por defecto; hasta 3072Especializado en code retrieval: búsqueda semántica sobre repositorios y documentación técnica.e5-mistral-7b-instructIntFloat / Microsoft4096Baseline open-weight de alta calidad, pero pesado: requiere más compute que BGE o Qwen pequeños.Los embeddings se almacenan en bases de datos vectoriales: Pinecone, Chroma, Weaviate, pgvector. La elección del modelo depende del idioma, tipo de contenido y presupuesto.

No confundir

El modelo de embedding solo convierte texto a vector. No genera texto. Es diferente del LLM. Los embeddings sirven para buscar; el LLM sirve para generar.

15Entrenamiento vs inferencia

Entrenamiento

El proceso decrearel modelo. Se ajustan miles de millones o billones de parámetros con datos masivos.

Datos curados→Pre-training→Post-training (SFT + preferencias/RL)→Evals + safety→Deploy + monitorización

AspectoValorDuraciónSemanas a mesesHardwareMiles de GPUs (A100/H100)CosteMillones de dólaresQuién lo haceAnthropic, OpenAI, Google, MetaFrecuenciaCada pocos meses

Inferencia

Usar el modeloya entrenadopara obtener respuestas. Es lo que haces cuando chateas con Claude o llamas a la API.

Tu prompt→Modelo→Respuesta

AspectoValorDuraciónSegundosHardware1 GPU o CPU optimizadaCosteCéntimos por peticiónQuién lo haceCualquiera con acceso a la APIFrecuenciaMiles de veces por segundo

Fine-tuning

Reentrenarparcialmenteun modelo existente con tus propios datos. Mucho más barato que entrenar desde cero. Cambia el comportamiento y estilo del modelo, pero no le “enseña” datos nuevos en tiempo real. Para acceder a datos propios cambiantes, es mejor usar RAG.

16Quantización: modelos que caben en tu portátil

Comprimir el modelo reduciendo la precisión numérica de cadapeso. Un peso es un número aprendido durante el entrenamiento; al quantizar no cambias la arquitectura, cambias cómo se guarda ese número.

Cómo leer la tabla

Formatoes el tipo de dato usado para guardar cada peso.Bits/pesoes el espacio que ocupa cada número.Memoria 7Bestima solo los pesos: 7.000 millones de pesos x bits / 8.Trade-offes lo que ganas y pierdes al comprimir.

FormatoQué significaBits/pesoUso típicoMemoria 7BTrade-offFP32Floating Point 32: número decimal de alta precisión32Entrenamiento clásico~28 GBMáxima precisión, memoria enormeBF16 / FP16BF16 = Brain Float 16; FP16 = Floating Point 16. Decimales de 16 bits; BF16 conserva mejor el rango, FP16 más detalle local16Entrenamiento e inferencia GPU~14 GBCasi calidad original, buen rendimientoFP8 / INT88 bits por peso: FP8 guarda decimales pequeños; INT8 guarda enteros con escala8Inferencia optimizada~7 GBMuy buena calidad, mitad de memoriaINT4 / NF44 bits: INT4 usa 16 niveles; NF4 está diseñado para pesos con distribución normal4Local, QLoRA, despliegue barato~3.5-4.5 GBGran ahorro; puede perder razonamiento finoDe dónde salen esos GB

Un modelo 7B tiene unos 7.000 millones de pesos. Si cada peso ocupa 32 bits: 7B x 32 / 8 = ~28 GB. Si ocupa 4 bits: 7B x 4 / 8 = ~3.5 GB. En la práctica se suma memoria para tokenizer, activaciones, KV cache y runtime.

Esto es lo que hace posibleLM StudioyOllama: ejecutar modelos de 7B-70B parámetros en hardware de consumo usando formatos GGUF quantizados. A menor precisión, menor memoria; la pérdida depende del modelo, del método y de la tarea.

No todas las quantizaciones son iguales

FamiliaDónde se veIdeaCuándo usarlaGGUF / GGMLOllama, LM Studio, llama.cppArchivo con pesos + tokenizer + metadata; optimizado para CPU/GPU localModelos locales y portátilesbitsandbytesTransformersCarga en 8-bit o 4-bit al vueloPrototipos, fine-tuning con QLoRAGPTQ / AWQHugging Face, vLLM, ExLlamaGPTQ = GPT Quantization; AWQ = Activation-aware Weight Quantization. Quantización post-training con ejemplos de calibraciónGPU, inferencia rápida en producciónFP8H100/H200, proveedores cloudFormato de baja precisión pensado para aceleradores modernosServir modelos grandes con buen throughputFormatos GGUF habituales

Q4_K_M: equilibrio por defecto en llama.cpp; suele ser el primer intento.Q5_K_M: más calidad con algo más de RAM.Q6_K / Q8_0: mejor fidelidad para razonamiento, extracción precisa o producción local.IQ quants: usan una matriz de importancia, es decir, datos de ejemplo para decidir qué pesos conviene conservar mejor.

17ML clásico: el mapa antes de los LLMs

Antes de hablar de modelos gigantes conviene separar tareas: aprender una etiqueta, predecir un número, descubrir estructura o actuar para maximizar recompensa. Esa separación evita elegir una arquitectura por moda cuando todavía no está claro qué señal de aprendizaje existe.

Este mapa evita una confusión frecuente: machine learning no es una técnica única, sino una familia de problemas. Antes de elegir algoritmo hay que identificar qué señal tienes, qué salida esperas y cómo vas a medir si el sistema aprende algo útil fuera de los ejemplos vistos.

La pregunta no es “qué modelo uso”, sino “qué salida necesito, qué feedback tengo y cómo sabré que generaliza”.

Teoría aplicada

Primero se decide la señal de aprendizaje: etiqueta, estructura o recompensa. El algoritmo viene después.

Fórmula / criterio

Problema supervisado: aprende f(x) -> y minimizando una pérdida L(y, f(x)).

Ejemplo

Un ticket puede ser clase, prioridad, tiempo estimado o acción recomendada: son problemas distintos aunque usen el mismo texto.

Decisión

Antes de entrenar, escribe salida esperada, métrica, baseline y coste de equivocarte.

xentrada: features, texto, imagen, estado o señales

yrespuesta esperada, si existe

ŷpredicción o decisión del modelo

**L(y, ŷ)**pérdida: cuánto duele equivocarse

Supervisado

Entrenas con ejemplos etiquetados: entrada -> respuesta esperada. Sirve cuando puedes auditar una verdad de referencia, aunque sea imperfecta.

clasificación / regresión

No supervisado

No hay etiqueta. Buscas estructura, anomalías o compresión, pero la interpretación necesita validación externa.

clustering / reducción

Refuerzo

Un agente elige acciones, observa recompensa y aprende una política. El reto es diseñar una recompensa que no pueda explotarse mal.

secuencia de decisiones

Evaluación

No basta con “parece funcionar”: separa datos, define baseline, métrica y coste de error antes de iterar.

train / test

Pregunta prácticaFamiliaMétrica típicaRiesgo si lo formulas mal¿Qué categoría corresponde?Supervisado: clasificaciónprecision, recall, F1, matriz de confusiónoptimizar accuracy y fallar justo en la clase minoritaria¿Cuánto vale o cuánto tardará?Supervisado: regresiónMAE, RMSE, R², error por segmentoconvertir un número útil en una etiqueta pobre¿Qué estructura aparece?No supervisadosilhouette, estabilidad, validación de dominioconfundir cluster con verdad causal¿Qué acción conviene ahora?Refuerzo / decisión secuencialretorno acumulado, regret, tasa de éxitopremiar una conducta que maximiza métrica y rompe producto

18Dataset, features, label y target

Un modelo no aprende “el mundo” directamente: aprende la representación que le damos en forma de filas, columnas, textos, imágenes o señales. Por eso la calidad de las features, la etiqueta y el split de datos suele importar más que cambiar de algoritmo.

El dataset es la forma concreta en la que conviertes el mundo en datos. Si una fila, una columna o una etiqueta están mal definidas, el modelo optimiza una representación equivocada y puede dar métricas bonitas sin resolver el problema real.

Garbage in, garbage out sigue vigente: una etiqueta mal definida produce un modelo obediente al problema equivocado.

Teoría aplicada

La representación define lo que el modelo puede aprender. Una feature ausente no se compensa con un algoritmo elegante.

Fórmula / criterio

Dataset típico: X matriz de features, y vector de targets; predicción: y_hat = f(X).

Ejemplo

Para fraude, importe y país ayudan; una columna creada después de revisar el fraude sería leakage.

Decisión

Audita cada feature preguntando: existe en el momento de predecir, es estable y es legal usarla.

TérminoLectura sencillaEjemploCuidado prácticoInstanciaUn caso individual del datasetUn coche, una factura, una conversaciónDefine la unidad: fila por usuario, evento, sesión o documento cambia el problema.FeatureVariable de entrada que describe el casoprecio, edad, categoría, longitud del textoDebe existir en el momento de predecir y no introducir leakage.Label / targetRespuesta esperada durante entrenamientospam/no spam, precio final, clase de riesgoPuede tener ruido humano, sesgo de proceso o definiciones inconsistentes.Train setDatos usados para ajustar el modelo70-80% si el dataset lo permiteNo debe mezclarse con decisiones de evaluación final.ValidaciónDatos para elegir features, modelo, umbral e hiperparámetrosfold o periodo de validaciónTocarla muchas veces también sobreajusta decisiones.Test setDatos reservados para medir generalizaciónDatos que el modelo no debe ver al entrenarDebe parecerse al futuro real, no solo a una muestra cómoda.Ejemplo: ticket de soporteQué seríaPor qué importaTexto del ticket, canal, producto, país, planfeatures disponibles antes de respondersirven para clasificar intención o prioridadEquipo correcto o prioridad real finallabel supervisadanecesita historial fiable y criterios consistentesTiempo hasta resolucióntarget de regresiónno se mide igual que una claseSatisfacción posterior del usuarioseñal retrasadapuede entrar en ranking, RL o evaluación de calidadRegla práctica

Si no puedes explicar qué es una fila, qué son las columnas, cuándo existen y qué decisión habilita la predicción, todavía no tienes un problema de machine learning: tienes datos sueltos.

19Supervisado, no supervisado y refuerzo

Estas tres familias no se separan por usar árboles, redes neuronales o Transformers, sino por el tipo de feedback disponible durante el aprendizaje. La pregunta clave es: ¿quién corrige al modelo y cuándo?

La señal de aprendizaje determina la estrategia. En supervisado comparas contra una respuesta esperada, en no supervisado buscas patrones sin una verdad etiquetada, y en refuerzo aprendes por consecuencias acumuladas de acciones.

Supervisado = respuestas correctas. No supervisado = estructura. Refuerzo = acciones + recompensa.

Teoría aplicada

La diferencia real es quién da feedback: label inmediato, ninguna label, o recompensa retrasada.

Fórmula / criterio

Supervisado: min L(y, y_hat). RL: maximizar retorno G_t = suma gamma^k r_{t+k+1}.

Ejemplo

Clasificar tickets usa labels; segmentar tickets usa estructura; decidir el siguiente paso de soporte usa recompensa o política.

Decisión

Si no puedes nombrar la señal de aprendizaje, todavía no elijas arquitectura.

**D={(xᵢ,yᵢ)}**supervisado: ejemplos con respuesta

**D={xᵢ}**no supervisado: solo observaciones

**s,a,r,s′**refuerzo: estado, acción, recompensa, nuevo estado

baselinecomparador simple para saber si mejoras algo

FamiliaSeñal de aprendizajeQué aprendeEjemplo y cuidadoSupervisadoCada ejemplo trae una respuesta esperada: label o targetUna función que mapea entrada -> salidaClasificar spam/no spam, predecir precio o churn. Cuidado: si las etiquetas son malas, el modelo aprende ese error.No supervisadoSolo hay datos de entrada, sin respuesta correcta por filaEstructura: grupos, dimensiones, anomalías o representaciones latentesAgrupar clientes, detectar facturas raras o reducir variables. Cuidado: un cluster no es una categoría real hasta validarlo.RefuerzoEl sistema actúa y recibe recompensa, a veces mucho despuésUna política: qué acción tomar en cada estado para maximizar retornoJuegos, robots, recomendaciones, bandits o RLHF/RLAIF. Cuidado: puede aprender a explotar mal la recompensa.Lectura rápida

Si tienes ejemplos con respuesta, empieza pensando en supervisado. Si no tienes etiquetas y quieres explorar datos, piensa en no supervisado. Si hay decisiones secuenciales con consecuencias, piensa en refuerzo.

20Clasificación vs regresión

Ambas son aprendizaje supervisado: entrenas con ejemplos donde ya conoces la respuesta. La diferencia está en el tipo de variable que quieres predecir: una categoría discreta o una cantidad continua.

La diferencia parece sencilla, pero cambia toda la evaluación. Una clase discreta se revisa con errores por categoría; un valor continuo se revisa por distancia, tolerancia y coste del error según el dominio.

Clasificación estima “qué clase es”; regresión estima “cuánto vale”. Esa diferencia cambia pérdidas, métricas, umbrales y decisiones de producto.

Teoría aplicada

Cambiar el tipo de salida cambia la pérdida, las métricas y el umbral de actuación.

Fórmula / criterio

Clasificación: p(y=c|x). Regresión: error = y - y_hat, MAE = mean(|error|).

Ejemplo

Riesgo de churn como probabilidad sirve para priorizar; días hasta baja requiere regresión o supervivencia.

Decisión

Elige la formulación que preserve la decisión real, no la que produzca la demo más cómoda.

Clasificacióny pertenece a un conjunto de clases: spam/no spam, A/B/C

Regresióny es un número real: precio, demanda, latencia, riesgo

**p(y = c | x)**probabilidad de clase dado un ejemplo x

**ŷ = f(x)**valor predicho por una función aprendida

Clasificación

Predice una categoría. Puede devolver una clase final o una distribución de probabilidades por clase. Ejemplo: fraude = 0.92, no fraude = 0.08; después decides un umbral para bloquear, revisar o dejar pasar.

clases discretas

Regresión

Predice una magnitud. La salida no es “correcto/incorrecto” de forma natural: importa cuánto te alejas del valor real. Ejemplo: precio real 310000, predicción 302000, error absoluto 8000.

valor continuo

TipoEjemplosPérdida típicaMétricasClasificación binariaspam/no spam, fraude/no fraude, aprobado/rechazadoLog loss / binary cross-entropy: penaliza probabilidades mal calibradasaccuracy, precision, recall, F1, ROC-AUC, matriz de confusiónClasificación multiclaseidioma, tipo de ticket, categoría de productoCross-entropy con softmax: compara distribución real vs predichaaccuracy por clase, macro/micro F1, top-k accuracyRegresiónprecio, demanda, tiempo de entrega, temperatura, latenciaMSE = media de (y - ŷ)^2; MAE = media de |y - ŷ|MAE, RMSE, R², error porcentual, tolerancia de negocioRanking / scoringordenar leads, priorizar tickets, recomendar productosPairwise/listwise loss o modelos de scorenDCG, MRR, recall@k, tasa de conversiónError común

Convertir todo en clasificación porque es cómodo. Si el valor continuo importa para decidir, usa regresión; si solo importa el orden, quizá necesitas ranking; si una probabilidad dispara una acción, necesitas calibración y umbrales.

21Validación: medir generalización

Generalizar significa acertar en casos nuevos, con ruido nuevo y usuarios nuevos. Un modelo que solo funciona en los ejemplos con los que lo has ajustado no ha aprendido una regla útil: ha memorizado una foto del pasado.

Validar es simular el futuro con honestidad. El modelo debe demostrar que funciona en datos que no ha usado para ajustar sus parámetros ni para que nosotros tomemos decisiones de diseño durante el entrenamiento.

Validar es una simulación honesta de producción: separas datos, congelas un test y aceptas que la métrica mande más que la intuición.

Teoría aplicada

La validación estima futuro con datos que no han guiado el entrenamiento ni las decisiones de diseño.

Fórmula / criterio

Gap de generalización = error_test - error_train; si crece, algo no traslada bien.

Ejemplo

Un modelo de demanda entrenado con Black Friday puede fallar si validas aleatoriamente y mezclas fechas.

Decisión

Define el split como se usará en producción: por tiempo, usuario, cliente o entidad cuando toque.

Datos crudos→Train→Validación→Test oculto→Decisión

Traindatos para aprender parámetros o ajustar prompts

Validacióndatos para elegir modelo, features, umbral e hiperparámetros

Test ocultodatos que solo miras al final para estimar rendimiento real

Produccióndonde aparecen drift, cambios de usuario y errores caros

Split

Separa datos antes de iterar. En fraude, ventas o series temporales, no mezcles futuro con pasado: usa split temporal.

Cross-validation

k-fold entrena varias veces cambiando el fold de validación. Útil con pocos datos para ver variabilidad, no solo una métrica con suerte.

Drift

Si cambian usuarios, precios, campañas, regulación o producto, el rendimiento cambia aunque el código sea idéntico.

Leakage

Fuga de información: una columna, fecha, duplicado o etiqueta derivada deja ver una señal que no existirá al predecir.

Riesgo realEjemploCómo lo detectas o previenesLeakage por columnapredecir impago usando una columna generada después del impagorevisar cuándo existe cada feature y hacer feature auditDuplicados entre train/testmismo cliente, ticket o texto casi igual en ambos splitsdeduplicar y separar por entidad, no solo por fila aleatoriaSplit temporal mal hechoentrenar con datos de mayo para predecir abrilordenar por fecha y validar en periodos posterioresOverfitting de decisionesprobar 40 modelos hasta que uno gana en validaciónmantener test oculto, registrar experimentos y usar nested validation si hace faltaDrift en produccióncambia el producto y la distribución de tickets ya no se parece al trainmonitorizar métricas, distribución de features y errores por segmentoSkin in the game

Antes de enseñar una métrica, escribe qué decisión tomarás si baja: no lanzar, pedir revisión humana, recopilar más datos, cambiar umbral o volver a baseline. Sin esa decisión, la validación es decoración.

22Overfitting y underfitting

El objetivo no es acertar el train set: es capturar una señal que siga funcionando fuera de los ejemplos vistos. La pregunta práctica no es “cuánto acierta entrenando”, sino “cuánto aguanta cuando cambia el caso”.

Un modelo demasiado simple no captura la señal; uno demasiado flexible puede memorizar ruido. El trabajo práctico consiste en encontrar el punto donde el error baja en datos nuevos, no solo en los datos que ya conoce.

Underfitting = no aprende suficiente señal. Overfitting = aprende demasiado detalle accidental. Generalización = equilibrio entre ambos.

Teoría aplicada

Bias y variance explican si fallas por modelo pobre o por sensibilidad excesiva al dataset.

Fórmula / criterio

Riesgo esperado = ruido irreducible + bias^2 + variance.

Ejemplo

Un árbol profundo memoriza excepciones; una regla lineal puede no capturar una frontera claramente curva.

Decisión

Mira train y validación juntos: una sola métrica no diagnostica el fallo.

Biaserror por modelo demasiado simple o supuestos pobres

Variancesensibilidad excesiva a los datos concretos de entrenamiento

Train errorerror en datos usados para ajustar el modelo

Validation errorerror en datos no usados para aprender parámetros

ProblemaSíntomaCausa típicaControlUnderfittingMalo en train y validación. Ni siquiera aprende los ejemplos fáciles.Modelo demasiado simple, features pobres, poca señal, entrenamiento insuficiente.Mejor representación, más features útiles, modelo algo más expresivo, entrenar más o revisar labels.OverfittingMuy bueno en train, peor en validación/test. La brecha train-validación crece.Memorización, dataset pequeño, modelo demasiado flexible, leakage, demasiadas pruebas contra validación.Regularización, más datos, data augmentation, early stopping, simplificar modelo, test oculto.Métrica equivocadaParece bueno pero falla donde importa al negocio.Accuracy con clases desbalanceadas, métrica promedio que oculta segmentos críticos.Precision/recall/F1, coste de error, matriz de confusión, métricas por segmento y umbrales.Dataset no representativoFunciona en laboratorio y cae en producción.Train no se parece al tráfico real: otra época, canal, país, producto o tipo de usuario.Split temporal, muestreo por segmentos, eval privada reciente y monitorización de drift.Diagnóstico rápido

Train malo + validación mala suele pedir más señal o más capacidad. Train bueno + validación mala pide regularizar, limpiar leakage o conseguir datos más representativos. Train y validación buenos pero producción mala apunta a drift o mala definición de eval.

23Matriz de confusión

Para clasificación, la matriz de confusión enseña qué aciertos y errores comete el modelo por clase. Es la forma más directa de pasar de “accuracy” a consecuencias reales.

La matriz de confusión obliga a mirar errores concretos, no solo una nota final. Dos modelos con la misma accuracy pueden ser radicalmente distintos si uno falla en falsos positivos y otro en falsos negativos.

La matriz no pregunta solo cuánto aciertas; pregunta qué tipo de error cometes y cuánto cuesta.

Teoría aplicada

La matriz traduce errores estadísticos en consecuencias: bloquear, dejar pasar, revisar o escalar.

Fórmula / criterio

Accuracy=(TP+TN)/N; recall=TP/(TP+FN); specificity=TN/(TN+FP).

Ejemplo

En fraude, bajar FN puede subir FP: detectas más fraude, pero bloqueas más compras buenas.

Decisión

Asigna coste a FP y FN antes de elegir umbral o declarar ganador.

TPverdadero positivo: detectas correctamente el caso positivo

FPfalso positivo: acusas o bloqueas algo que era negativo

FNfalso negativo: dejas pasar algo que era positivo

TNverdadero negativo: descartas correctamente el caso negativo

Fraude

FN: dejas pasar una operación fraudulenta. FP: bloqueas una compra legítima y enfadas al cliente.

coste asimétrico

Moderación

FN: dejas contenido dañino. FP: censuras contenido legítimo. El umbral depende de política y riesgo.

umbral

Diagnóstico

FN: no detectas una enfermedad. FP: alarmas y pruebas innecesarias. La sensibilidad suele pesar mucho.

riesgo humano

Spam

FN: entra spam. FP: pierdes un email importante. Por eso no basta mirar accuracy global.

producto

Real \ PredichoPositivoNegativoPositivoTP El modelo detecta correctamente un caso positivo.FN El modelo deja escapar un positivo real.NegativoFP El modelo marca como positivo algo que no lo era.TN El modelo descarta correctamente un negativo.MétricaFórmula desde la matrizLecturaAccuracy(TP + TN) / (TP + FP + FN + TN)Porcentaje total de aciertos. Engaña si una clase domina.PrecisionTP / (TP + FP)De lo que marco como positivo, cuánto era positivo. Controla falsas alarmas.Recall / sensibilidadTP / (TP + FN)De todos los positivos reales, cuántos encuentro. Controla positivos perdidos.SpecificityTN / (TN + FP)De todos los negativos reales, cuántos descarto bien. Controla bloqueos injustos.F12 · precision · recall / (precision + recall)Resumen cuando necesitas balancear precision y recall.Skin in the game

Antes de elegir métrica, escribe el coste de FP y FN. Si un FN cuesta 100 veces más que un FP, no optimices accuracy: ajusta umbral, recall, revisión humana o coste ponderado.

24Precision, recall y F1

Accuracy suele engañar cuando las clases están desbalanceadas. Si el 99% de emails no son spam, un modelo que diga “no spam” siempre tiene 99% de accuracy y aun así no sirve para detectar spam.

Estas métricas existen porque casi nunca todos los errores cuestan lo mismo. Precision castiga alarmas falsas, recall castiga casos perdidos y F1 resume el equilibrio cuando necesitas una sola cifra de lectura rápida.

Precision responde “¿cuánto ruido genero?”; recall responde “¿cuánto se me escapa?”; F1 resume ambos cuando necesitas una cifra, pero nunca sustituye entender el coste del error.

Teoría aplicada

Precision mide contaminación de positivos; recall mide cobertura de positivos reales.

Fórmula / criterio

F1 = 2PR/(P+R); F_beta pondera recall si beta > 1 y precision si beta < 1.

Ejemplo

Un detector médico suele aceptar menos precision para no perder casos; un sistema de bloqueo puede exigir alta precision.

Decisión

Mueve el umbral con una curva precision-recall y elige según coste operativo.

Precisionde lo que marco como positivo, cuánto era positivo

Recallde todos los positivos reales, cuántos encuentro

F1media armónica entre precision y recall

Accuracyaciertos totales, útil solo si el balance acompaña

MétricaFórmulaCuándo importaEjemplo de decisiónPrecisionTP / (TP + FP)Evitar falsas alarmasRevisión manual cara: solo mandas casos con alta confianzaRecallTP / (TP + FN)No perder positivos relevantesFraude, salud o seguridad: prefieres revisar de más antes que dejar pasarF12PR / (P + R)Balance entre precision y recallComparar modelos cuando FP y FN pesan parecidoFβ(1 + β²) · P · R / (β² · P + R)Dar más peso a recall si β > 1 o a precision si β < 1F2 para no perder positivos; F0.5 para reducir falsas alarmasEjemplo con 1000 casosValorPositivos reales50El modelo marca positivos80Verdaderos positivos (TP)40Falsos positivos (FP)40Falsos negativos (FN)10Precision40 / (40 + 40) = 0.50Recall40 / (40 + 10) = 0.80F12 · 0.50 · 0.80 / (0.50 + 0.80) = 0.62Umbral y producto

Si subes el umbral, normalmente sube precision y baja recall: molestas menos, pero se escapan más casos. Si bajas el umbral, sube recall y baja precision: detectas más, pero generas más revisión o falsos bloqueos. La métrica correcta depende del coste real de actuar.

25Clustering y k-means

Clustering agrupa datos sin etiqueta. k-means busca k centroides y asigna cada punto al centro más cercano. La parte peligrosa no es ejecutar el algoritmo, sino interpretar los grupos como si fueran categorías naturales.

Clustering no descubre categorías naturales por arte de magia. Construye grupos según la geometría que le des: variables, escala, distancia y número de clusters condicionan totalmente el resultado.

k-means optimiza geometría, no significado. Si cambias escala, variables o k, puede cambiar la historia.

Teoría aplicada

k-means no descubre verdades: minimiza distancia a centroides bajo una geometría concreta.

Fórmula / criterio

Objetivo: minimizar suma ||x_i - mu_{c_i}||^2 dentro de cada cluster.

Ejemplo

Si ingresos está en miles y edad en decenas, ingresos dominará la distancia salvo que escales.

Decisión

Normaliza, prueba varios k, varias semillas y valida si los grupos son útiles fuera del gráfico.

Elegir k→Inicializar centroides→Asignar puntos→Recalcular centroides→Repetir

knúmero de clusters elegido antes de entrenar

μⱼcentroide del cluster j

inertiasuma de distancias cuadradas al centroide

silhouetteseparación y cohesión aproximadas

Centroide

Punto medio representativo de un cluster. No tiene por qué ser un caso real ni una persona “tipo”.

Distancia

Normalmente euclídea; una feature con escala grande puede dominar toda la agrupación.

Iteración

Alterna asignación y actualización hasta estabilizar. Distintas semillas pueden dar soluciones distintas.

k

Número de grupos. No siempre viene dado por el dominio; elbow y silhouette ayudan, pero no sustituyen criterio.

DecisiónPregunta que hacesQué mirarEscalar features¿todas las variables tienen peso comparable?standardization, robust scaling, unidadesElegir k¿cuántos grupos son útiles y estables?elbow, silhouette, estabilidad por semillaInterpretar cluster¿qué lo diferencia realmente?perfil de centroides, ejemplos cercanos, revisión de dominioUsarlo en producto¿qué acción cambia por pertenecer al cluster?lift, coste de error, fairness y monitorización

26Cuándo no confiar en clusters

Un cluster no es una verdad del mundo. Es una partición inducida por features, escala, métrica y algoritmo. Puede ser una hipótesis útil, pero también una forma elegante de amplificar sesgos o artefactos.

Un cluster debe leerse como una hipótesis exploratoria. Sirve para preguntar mejor, segmentar provisionalmente o detectar anomalías, pero necesita validación de dominio antes de convertirse en regla de negocio.

No confíes en un cluster hasta que sea estable, interpretable y útil para una decisión concreta.

Teoría aplicada

Un cluster es una hipótesis exploratoria, no una etiqueta causal ni un segmento de negocio automáticamente válido.

Fórmula / criterio

Comprueba estabilidad, silhouette, lift de negocio y auditoría manual por muestra.

Ejemplo

Un cluster de clientes “premium” puede ser solo efecto de una feature de facturación mal escalada.

Decisión

No automatices decisiones sensibles solo porque un algoritmo separó puntos en colores bonitos.

Señal de alarmaQué pasaQué hacerFeatures mal escaladasUna variable domina la distanciaNormalizar, revisar unidades y justificar variablesk elegido por estéticaLos grupos parecen bonitos pero no explican nadaValidar con dominio, estabilidad y métricasClusters no esféricosk-means corta mal formas alargadas o densidades distintasProbar DBSCAN, jerárquico o UMAP solo como exploraciónAlta dimensiónLas distancias se vuelven menos informativasReducir dimensión con cuidado y revisar vecinos realesSesgo de muestreoEl cluster refleja cómo recogiste datos, no cómo es el mundoComparar contra población real y segmentos críticosInterpretación causalSe confunde grupo con causaUsar clustering como hipótesis, no como sentenciaValidación mínimaPreguntaEstabilidad¿aparece parecido si cambio seed, muestra o periodo?Separación¿silhouette o métricas internas sugieren grupos distinguibles?Interpretabilidad¿puedo describir el cluster con variables comprensibles?Utilidad¿tomar una acción por cluster mejora una métrica real?Riesgo¿el cluster introduce discriminación, exclusión o decisiones no explicables?Qué debe saber

ML clásico te da vocabulario para medir. LLMs y agentes no eliminan validación, la hacen más necesaria.

27Lo que deberías saber: fundamentos

ConceptoSlideLa IA no piensa ni es consciente: es predicción estadística2-3Sistemas estocásticos: misma entrada, distintas salidas4Aprendizaje supervisado, no supervisado y post-training con preferencias/refuerzo5Neurona artificial = función con pesos, bias y activación6Redes neuronales: capas que aprenden abstracciones7Backpropagation: forward, loss, backward, update8Overfitting, vanishing gradients, optimizadores (Adam)9CNNs para imágenes, RNNs/LSTMs para secuencias10-11Token = unidad discreta que procesa el modelo12Embedding = vector numérico que codifica significado13-14Entrenamiento (crear el modelo) vs inferencia (usarlo)15Quantización: comprimir modelos para hardware modesto16 28

IA clásica aplicada

Búsqueda, restricciones, planificación, juegos y conocimiento simbólico: las ideas que siguen vivas detrás de agentes, RAG y sistemas fiables.

29Búsqueda: resolver como espacio de estados

Muchos problemas de IA se pueden formular como navegar desde un estado inicial hasta un estado objetivo aplicando acciones con coste.

Formular un problema como estados y acciones es una forma de quitar ambigüedad. En vez de pedir una respuesta genérica, defines dónde estás, qué movimientos son legales, cuánto cuestan y cómo sabes que has llegado a una solución.

Teoría aplicada

Búsqueda formaliza resolver como explorar estados con coste. Lo importante es qué guardas como estado y qué frontera expandes.

Fórmula / criterio

Complejidad típica: O(b^d), con b factor de ramificación y d profundidad de solución.

Ejemplo

En un agente, cada tool call es un paso: tiene coste, riesgo y puede abrir nuevas ramas.

Decisión

Define estado, acciones, coste, criterio de parada y política contra loops antes de automatizar.

Estado inicial→Acciones→Estados sucesores→Coste→Objetivo

Estado

Descripción suficiente de la situación actual.

Acción

Operación que transforma un estado en otro.

Meta

Condición que permite decir: problema resuelto.

Coste

Precio de una acción o camino: distancia, tiempo, tokens, riesgo.

30Árbol de búsqueda vs grafo de estados

El árbol representa caminos explorados; el grafo representa estados reales. Confundirlos produce loops y coste innecesario.

El árbol de búsqueda puede tener muchos caminos que llegan al mismo estado. Por eso los algoritmos prácticos suelen recordar estados visitados: evita repetir trabajo y evita bucles que consumen memoria, tiempo o tokens sin avanzar.

Teoría aplicada

Búsqueda formaliza resolver como explorar estados con coste. Lo importante es qué guardas como estado y qué frontera expandes.

Fórmula / criterio

Complejidad típica: O(b^d), con b factor de ramificación y d profundidad de solución.

Ejemplo

En un agente, cada tool call es un paso: tiene coste, riesgo y puede abrir nuevas ramas.

Decisión

Define estado, acciones, coste, criterio de parada y política contra loops antes de automatizar.

ConceptoQué contieneRiesgoNodo de árbolUn camino concreto hasta un estadoEl mismo estado puede aparecer muchas vecesEstado del mundoConfiguración real del problemaSi no lo identificas, repites trabajoLista abierta / fronteraNodos pendientes de explorarPuede crecer exponencialmenteLista cerradaEstados ya visitadosEvita ciclos si la comparación de estados es correcta

31BFS: búsqueda en anchura

BFS explora primero todos los estados a distancia 1, luego distancia 2, etc. Si todos los costes son iguales, encuentra el camino más corto en número de pasos.

BFS es fácil de razonar porque explora por capas. Su virtud es la garantía con costes uniformes; su problema es que la frontera crece rápido y puede hacerse inviable aunque conceptualmente sea muy ordenado.

Teoría aplicada

Búsqueda formaliza resolver como explorar estados con coste. Lo importante es qué guardas como estado y qué frontera expandes.

Fórmula / criterio

Complejidad típica: O(b^d), con b factor de ramificación y d profundidad de solución.

Ejemplo

En un agente, cada tool call es un paso: tiene coste, riesgo y puede abrir nuevas ramas.

Decisión

Define estado, acciones, coste, criterio de parada y política contra loops antes de automatizar.

1. Mete el estado inicial en una cola FIFO.
2. Extrae el primer nodo de la cola.
3. Si es objetivo, devuelve el camino.
4. Genera sucesores no visitados y añádelos al final.
5. Repite hasta encontrar solución o agotar frontera.

Trade-off

Es completa y óptima con costes uniformes, pero puede consumir mucha memoria porque mantiene la frontera por niveles.

32DFS: búsqueda en profundidad

DFS baja por un camino hasta el fondo antes de probar alternativas. Es barata en memoria, pero puede perderse en ramas largas o infinitas.

DFS representa una estrategia opuesta: comprometerse con una rama y retroceder si falla. Es útil cuando la memoria manda, pero requiere límites o control de ciclos para no profundizar indefinidamente.

Teoría aplicada

Búsqueda formaliza resolver como explorar estados con coste. Lo importante es qué guardas como estado y qué frontera expandes.

Fórmula / criterio

Complejidad típica: O(b^d), con b factor de ramificación y d profundidad de solución.

Ejemplo

En un agente, cada tool call es un paso: tiene coste, riesgo y puede abrir nuevas ramas.

Decisión

Define estado, acciones, coste, criterio de parada y política contra loops antes de automatizar.

Cuándo ayuda

Cuando el espacio es muy grande, la memoria importa y puedes limitar profundidad o detectar ciclos.

memoria baja

Cuándo falla

Cuando hay ramas profundas irrelevantes o necesitas garantizar el camino más corto.

no óptima

function dfs(node, goal):
  if goal(node): return path(node)
  mark node as visited
  for child in successors(node):
    if child not visited:
      result = dfs(child, goal)
      if result: return result
  return failure

33Coste uniforme: cuando no todos los pasos cuestan igual

Uniform Cost Search expande primero el camino de menor coste acumulado, no el camino con menos pasos.

Contar pasos no siempre equivale a optimizar. Si una acción barata y una cara cuentan igual, BFS puede elegir mal; coste uniforme corrige esto priorizando el coste acumulado real del camino.

Teoría aplicada

Búsqueda formaliza resolver como explorar estados con coste. Lo importante es qué guardas como estado y qué frontera expandes.

Fórmula / criterio

Complejidad típica: O(b^d), con b factor de ramificación y d profundidad de solución.

Ejemplo

En un agente, cada tool call es un paso: tiene coste, riesgo y puede abrir nuevas ramas.

Decisión

Define estado, acciones, coste, criterio de parada y política contra loops antes de automatizar.

AlgoritmoPriorizaÓptimo siBFSMenos pasosTodos los pasos cuestan igualDFSProfundidadNo garantiza óptimoCoste uniformeMenor coste g(n)Costes no negativosA*g(n) + h(n)Heurística admisible y consistente

34Greedy best-first search

Greedy elige lo que parece más cerca del objetivo según una heurística h(n). Es rápido, pero miope.

Greedy enseña una lección muy útil para agentes: lo que parece más cercano puede no ser lo mejor. Una heurística rápida acelera, pero si ignora obstáculos o restricciones puede llevar a soluciones convincentes y malas.

Teoría aplicada

Búsqueda formaliza resolver como explorar estados con coste. Lo importante es qué guardas como estado y qué frontera expandes.

Fórmula / criterio

Complejidad típica: O(b^d), con b factor de ramificación y d profundidad de solución.

Ejemplo

En un agente, cada tool call es un paso: tiene coste, riesgo y puede abrir nuevas ramas.

Decisión

Define estado, acciones, coste, criterio de parada y política contra loops antes de automatizar.

Ventaja

Explora menos si la heurística orienta bien.

Riesgo

Puede elegir un atajo aparente que termina siendo peor.

Ejemplo

Ir hacia la ciudad en línea recta aunque haya una montaña entre medias.

En agentes

Equivale a elegir la tool que parece obvia sin verificar restricciones.

35A*: coste real + intuición

A* combina lo que ya cuesta el camino, g(n), con una estimación de lo que falta, h(n).

A* combina prudencia y orientación. No se limita a seguir la intuición de la heurística; también recuerda cuánto ha costado llegar hasta cada punto, por eso es un puente excelente entre teoría y planificación práctica.

Teoría aplicada

Búsqueda formaliza resolver como explorar estados con coste. Lo importante es qué guardas como estado y qué frontera expandes.

Fórmula / criterio

Complejidad típica: O(b^d), con b factor de ramificación y d profundidad de solución.

Ejemplo

En un agente, cada tool call es un paso: tiene coste, riesgo y puede abrir nuevas ramas.

Decisión

Define estado, acciones, coste, criterio de parada y política contra loops antes de automatizar.

**g(n)**coste acumulado desde el inicio

**h(n)**estimación hasta la meta

**f(n)**g(n) + h(n)

Lectura práctica

A* es potente porque no solo mira lo prometedor: también penaliza caminos que ya han costado demasiado.

36Heurísticas: buenas intuiciones, malos atajos

Una heurística es una estimación. No tiene que ser perfecta, pero sí debe estar alineada con el objetivo.

Una heurística es conocimiento del dominio comprimido en una función. Puede hacer un problema resoluble o sesgarlo por completo; por eso se evalúa no solo por acierto, sino por coste, consistencia y alineación con el objetivo.

Teoría aplicada

Búsqueda formaliza resolver como explorar estados con coste. Lo importante es qué guardas como estado y qué frontera expandes.

Fórmula / criterio

Complejidad típica: O(b^d), con b factor de ramificación y d profundidad de solución.

Ejemplo

En un agente, cada tool call es un paso: tiene coste, riesgo y puede abrir nuevas ramas.

Decisión

Define estado, acciones, coste, criterio de parada y política contra loops antes de automatizar.

PropiedadDefiniciónImplicaciónAdmisibleNunca sobreestima el coste real restanteA* puede mantener optimalidadConsistenteLa estimación respeta el coste entre vecinosEvita reabrir nodos innecesariamenteInformativaDiferencia buenos y malos caminosReduce exploraciónBarataSe calcula rápidoNo gastas más evaluando que buscando

37Búsqueda en agentes modernos

Un agente LLM también explora: decide pasos, prueba tools, observa resultados y corrige. La diferencia es que el espacio no siempre está formalizado.

Los agentes modernos también exploran un espacio de posibilidades, aunque ese espacio esté escrito en lenguaje natural. Cada tool call, lectura de archivo o intento de solución tiene coste y debería tratarse como parte de una búsqueda controlada.

Teoría aplicada

Búsqueda formaliza resolver como explorar estados con coste. Lo importante es qué guardas como estado y qué frontera expandes.

Fórmula / criterio

Complejidad típica: O(b^d), con b factor de ramificación y d profundidad de solución.

Ejemplo

En un agente, cada tool call es un paso: tiene coste, riesgo y puede abrir nuevas ramas.

Decisión

Define estado, acciones, coste, criterio de parada y política contra loops antes de automatizar.

IA clásicaAgente LLMRiesgo modernoEstado explícitoContexto + memoria + logsEstado incompleto o contaminadoAcción modeladaTool call o navegaciónTool demasiado ampliaCoste de caminoTokens + latencia + riesgoOptimizar solo calidad textualHeurísticaModelo, routing o evalConfundir confianza con verdad

38Qué debe saber: búsqueda

No necesitas memorizar todos los algoritmos, pero sí reconocer cuándo un problema es de búsqueda y qué coste estás optimizando.

La utilidad de este bloque es práctica: cuando una tarea se atasca, pregúntate si faltan estado, acciones, coste o criterio de parada. Esa pregunta mejora tanto un algoritmo clásico como un workflow con LLM.

Teoría aplicada

Búsqueda formaliza resolver como explorar estados con coste. Lo importante es qué guardas como estado y qué frontera expandes.

Fórmula / criterio

Complejidad típica: O(b^d), con b factor de ramificación y d profundidad de solución.

Ejemplo

En un agente, cada tool call es un paso: tiene coste, riesgo y puede abrir nuevas ramas.

Decisión

Define estado, acciones, coste, criterio de parada y política contra loops antes de automatizar.

Debes poder explicarPor qué importaEstado, acción, objetivo y costeSin esto no hay problema bien formuladoBFS, DFS, coste uniforme y A*Son patrones mentales para explorar solucionesHeurística admisible vs heurística útilNo todas las intuiciones conservan optimalidadFrontera, visitados y loopsEvitan gastar recursos explorando lo mismoConexión con agentesPlanificar tools es búsqueda con coste y riesgo

39SAT y CSP: IA como restricciones

No todos los problemas se resuelven generando texto. Muchos consisten en encontrar una asignación que cumpla restricciones exactas: horarios, configuraciones, permisos, rutas, turnos, dependencias o planes válidos.

SAT y CSP cambian el foco: no buscamos el texto más probable, buscamos una asignación válida. Son fundamentales para entender por qué muchos sistemas fiables combinan generación flexible con verificación determinista.

SAT y CSP enseñan una idea clave para sistemas con IA: primero genera candidatos si quieres, pero acepta solo soluciones que pasen reglas verificables.

Teoría aplicada

SAT y CSP tratan la IA como búsqueda de una configuración válida bajo reglas explícitas, no como generación probable.

Fórmula / criterio

SAT: existe una asignación que satisface una fórmula booleana. CSP = (X,D,C): variables, dominios y restricciones.

Ejemplo

Un horario válido asigna aula, profesor y hora sin solapes, disponibilidad rota ni reglas incumplidas.

Decisión

Usa LLM para traducir preferencias ambiguas; usa solver o validador para decidir si la solución es aceptable.

Variables→Dominios→Restricciones→Asignación→Solución válida

SATvariables booleanas: verdadero/falso

CSPvariables con dominios posibles

Solverbusca asignaciones válidas o demuestra fallo

Validadorcomprueba reglas después de generar

EnfoquePregunta formalEjemplo pequeñoQué garantizaSAT¿Existe una combinación de verdadero/falso que hace verdadera toda la fórmula?(A OR B) AND (NOT A OR C)Satisfacible o insatisfacible bajo esa lógica booleana.CSP¿Existe una asignación de valores a variables que respete todas las restricciones?turno(Ana)=mañana, aula(Curso)=A3, hora=10:00Cada variable toma un valor permitido y las combinaciones cumplen reglas.Optimización con restricciones¿Cuál es la mejor solución válida según un coste?horario válido minimizando cambios de aulaNo solo validez: también calidad según una función objetivo.LLM + validador¿El candidato generado cumple reglas ejecutables?el LLM propone agenda; el validador rechaza solapesFlexibilidad de lenguaje sin renunciar a controles deterministas.Ejemplo mental

Si tienes 5 reuniones, 3 salas y 4 franjas horarias, el LLM puede proponer una agenda razonable. Pero la agenda solo es aceptable si ninguna sala se duplica, nadie está en dos sitios a la vez y cada reunión cumple duración, permisos y disponibilidad.

40SAT: satisfacibilidad booleana

SAT pregunta si existe una asignación de verdadero/falso que hace verdadera una fórmula lógica. Parece abstracto, pero es una de las ideas más potentes de la informática: muchos problemas reales pueden traducirse a “estas condiciones se cumplen o no se cumplen”.

SAT trabaja con verdadero y falso, pero su importancia es enorme porque muchos problemas se pueden codificar en lógica booleana. Si existe una asignación que satisface todas las cláusulas, el solver la puede encontrar o demostrar que no existe.

SAT no genera una respuesta plausible: busca un modelo que satisfaga todas las cláusulas o demuestra que no existe.

Teoría aplicada

SAT reduce un problema a variables verdadero/falso y cláusulas. La salida no es una opinión: es SAT con modelo o UNSAT bajo la codificación.

Fórmula / criterio

CNF = conjunción de cláusulas; cláusula = disyunción de literales. Ejemplo: (A OR B) AND (NOT A OR C).

Ejemplo

Si A=true, B=false, C=true, la fórmula anterior se satisface; A AND NOT A es imposible.

Decisión

Cuando una regla debe cumplirse siempre, codifícala y verifícala en vez de pedir al modelo que “tenga cuidado”.

VariableA, B, C toman true o false

Literalvariable afirmada o negada: A, NOT A

CláusulaOR de literales: A OR NOT B

CNFAND de cláusulas: C1 AND C2 AND C3

Variable booleana

Representa una decisión elemental: usar proveedor A, activar feature B, acción en tiempo 3, paquete instalado.

Cláusula

Disyunción de literales. Si una cláusula falla, toda la fórmula deja de estar satisfecha.

Modelo

Asignación concreta que hace verdadera la fórmula completa. Es una solución, no una explicación literaria.

UNSAT

No existe asignación posible bajo esas reglas. Esto detecta contradicciones de diseño o requisitos incompatibles.

ObjetoLectura sencillaEjemploLiteralUna variable o su negaciónA, NOT BCláusulaAl menos uno de sus literales debe ser verdadero(A OR NOT B OR C)CNFTodas las cláusulas deben cumplirse a la vez(A OR B) AND (NOT A OR C)Modelo SATAsignación que satisface todoA=true, B=false, C=trueUNSATLas reglas se contradicenA AND NOT ACaso prácticoCómo se codifica en booleanosPor qué importaConfiguración de productofeature_A=true, addon_B=false, plan_enterprise=trueimpide combinaciones comerciales incompatiblesDependencias de paquetesinstalar_X implica instalar_Y; X y Z no pueden coexistirresuelve conflictos de versionesPlanning con horizonte fijoaccion_mover_t3=true si esa acción ocurre en el paso 3comprueba si existe plan de longitud kVerificación de circuitoscada señal se representa como variable booleanadetecta si un circuito puede alcanzar un estado prohibidoEjemplo rápido

Fórmula: (A OR B) AND (NOT A OR C). Si A=true y C=true, la segunda cláusula se cumple por C; si además A=true, la primera se cumple por A. El solver busca ese tipo de asignación automáticamente en problemas con miles o millones de variables.

41CSP: variables, dominios y restricciones

Un Constraint Satisfaction Problem se define por variables, dominios posibles y restricciones que deben cumplirse. Es una forma disciplinada de convertir “quiero una solución válida” en piezas comprobables por una máquina.

Un CSP es una forma ordenada de describir decisiones compatibles entre sí. La clave pedagógica es separar variable, dominio y restricción; mezclarlas en lenguaje natural suele ocultar errores que luego aparecen en producción.

La calidad de un CSP no depende solo del solver: depende de elegir bien variables, dominios y restricciones.

Teoría aplicada

Un CSP modela decisiones finitas. Resolverlo consiste en asignar valores a variables manteniendo consistencia con todas las restricciones.

Fórmula / criterio

X={X1..Xn}; Di dominio de Xi; Cj restringe combinaciones. Solución: asignación completa a tal que cumple todo Cj.

Ejemplo

Turnos: variable=turno de Ana; dominio={mañana,tarde,noche}; restricción=Ana no puede hacer noche dos días seguidos.

Decisión

Antes de resolver, revisa si cada regla es dura, blanda, local, global, comprobable y actualizable.

Xvariables: decisiones pendientes

Dᵢdominio permitido para cada variable Xᵢ

Crestricciones sobre una o varias variables

aasignación parcial o completa de valores

ElementoQué significaFormalizaciónEjemploVariableDecisión que hay que asignarXᵢturno_Ana_lunesDominioValores permitidos para una variableD(turno_Ana_lunes)={M,T,N,libre}mañana, tarde, noche, libreRestricciónCondición que filtra valores o combinacionesC(Xᵢ, Xⱼ, ...)=true/falseAna no puede hacer noche y mañana seguidasAsignación parcialAlgunas variables ya tienen valora={X1=M, X2=T}lunes asignado, martes pendienteSoluciónAsignación completa y consistente∀Cⱼ, Cⱼ(a)=truecalendario válido para todo el equipoTipo de restricciónQué limitaEjemploRiesgo si se omiteUnariaUna sola variableturno_Ana_lunes ≠ nochese asignan valores prohibidos individualmenteBinariaRelación entre dos variablesturno_Ana_lunes=noche implica turno_Ana_martes≠mañanaaparecen incompatibilidades entre paresGlobalMuchas variables a la vezexactamente 2 personas por turnola solución parece localmente válida pero falla como conjuntoBlanda / costePreferencias que se pueden violar pagando penalizaciónAna prefiere mañana, pero puede hacer tardeconfundir preferencia con regla dura vuelve el problema imposibleEjemplo de modelado

Si modelas “empleado asignado a turno” como una variable gigante, el dominio explota. Si separas por empleado-día o por turno-día, puedes expresar disponibilidad, descansos, cobertura mínima y preferencias con restricciones más claras.

42Ejemplos reales de CSP

Los CSP aparecen en problemas muy cotidianos: horarios, configuración, rutas con restricciones, asignación de recursos y validación de negocio.

Estos problemas parecen administrativos, pero son IA clásica pura. Cuando hay recursos limitados, reglas de compatibilidad y muchas combinaciones, un solver o validador puede aportar garantías que un LLM no debería prometer solo con un prompt.

Teoría aplicada

CSP separa decisiones, valores posibles y restricciones. Es útil cuando una respuesta debe ser válida, no solo plausible.

Fórmula / criterio

CSP = (X, D, C): variables X, dominios D y restricciones C que filtran asignaciones.

Ejemplo

Un calendario puede sonar bien en texto y aun así violar disponibilidad, descansos o permisos.

Decisión

Usa modelo generativo para entender preferencias; usa solver o validador para aceptar soluciones.

Scheduling

Turnos, aulas, salas, recursos limitados.

Asignación

Equipos a proyectos con habilidades y disponibilidad.

Configuración

Productos compatibles, bundles, planes y restricciones comerciales.

Validación

Reglas regulatorias, límites y políticas internas.

43Propagación de restricciones

Propagar significa reducir dominios usando restricciones antes de buscar a ciegas.

Propagar restricciones significa deducir consecuencias antes de probar combinaciones. Es una idea potente: cuanto antes eliminas opciones imposibles, menos espacio exploras y más claro queda por qué una solución falla.

Teoría aplicada

CSP separa decisiones, valores posibles y restricciones. Es útil cuando una respuesta debe ser válida, no solo plausible.

Fórmula / criterio

CSP = (X, D, C): variables X, dominios D y restricciones C que filtran asignaciones.

Ejemplo

Un calendario puede sonar bien en texto y aun así violar disponibilidad, descansos o permisos.

Decisión

Usa modelo generativo para entender preferencias; usa solver o validador para aceptar soluciones.

Dominio amplio→Aplicar restricción→Eliminar valores imposibles→Repetir→Buscar menos

Idea clave

La propagación no resuelve siempre el problema, pero reduce el espacio. Es el equivalente clásico a filtrar contexto antes de llamar al modelo.

44Backtracking: probar, fallar, volver

Backtracking asigna una variable, comprueba restricciones y vuelve atrás si la elección lleva a contradicción.

Backtracking es ensayo y error disciplinado. No prueba al azar: elige una variable, comprueba consistencia y deshace decisiones cuando detecta contradicción, exactamente la clase de control que queremos en automatizaciones críticas.

Teoría aplicada

CSP separa decisiones, valores posibles y restricciones. Es útil cuando una respuesta debe ser válida, no solo plausible.

Fórmula / criterio

CSP = (X, D, C): variables X, dominios D y restricciones C que filtran asignaciones.

Ejemplo

Un calendario puede sonar bien en texto y aun así violar disponibilidad, descansos o permisos.

Decisión

Usa modelo generativo para entender preferencias; usa solver o validador para aceptar soluciones.

function backtrack(assign):
  if complete(assign): return assign
  var = choose_unassigned_variable()
  for value in ordered_domain(var):
    if consistent(var, value, assign):
      add(var, value)
      result = backtrack(assign)
      if result: return result
      remove(var)
  return failure

45Heurísticas en CSP

La diferencia entre resolver rápido y explotar combinatoriamente suele estar en qué variable eliges primero, qué valor pruebas y cuánto propagas las consecuencias antes de seguir buscando.

Las heurísticas en CSP son estrategias para fallar pronto o preservar opciones. En problemas combinatorios, elegir bien el orden puede cambiar una ejecución imposible por una respuesta en segundos.

Una buena heurística en CSP no adivina la solución: reduce el árbol de búsqueda haciendo visibles las contradicciones cuanto antes.

Teoría aplicada

Las heurísticas no cambian las soluciones válidas; cambian el orden de búsqueda para detectar contradicciones antes.

Fórmula / criterio

Backtracking sin guía puede explorar producto |D_i|; MRV elige argmin |D_i restante| y LCV minimiza poda futura.

Ejemplo

En turnos, asignar primero a quien solo puede trabajar un día evita construir calendarios que fallarán al final.

Decisión

Ordena variables por riesgo de bloqueo y valores por flexibilidad restante antes de probar fuerza bruta.

MRVelige la variable con menos valores legales restantes

Degreeprioriza la variable que participa en más restricciones

LCVprueba el valor que menos limita a las demás variables

FC / AC-3propaga consecuencias para podar dominios

HeurísticaIdeaIntuiciónEjemplo prácticoMRVMinimum Remaining Valueselige la variable con menos valores posiblesprimero asigna al empleado que solo puede trabajar martes o juevesDegree heuristicVariable que afecta a más restriccionesataca antes lo más conectadoprimero agenda la sala compartida por más cursosLeast constraining valueValor que deja más opciones al restono cierres puertas prontoelige un turno que todavía deje cobertura suficiente para mañanaForward checkingComprueba consecuencias inmediatas tras asignardetecta contradicciones antessi Ana hace noche, elimina mañana del dominio de Ana al día siguienteArc consistencyElimina valores que no tienen soporte en variables vecinaslimpia dominios antes de profundizarsi ningún profesor puede cubrir una franja, esa franja se detecta prontoSituaciónSin heurísticaCon heurística10 variables con 5 valores cada unahasta 5¹⁰ combinaciones en el peor casose prueban primero los puntos con más riesgo de contradicciónRestricción aparece al finaldescubres tarde que el calendario era imposibleMRV/forward checking pueden fallar en los primeros pasosVariables muy conectadasuna decisión tardía invalida medio plandegree heuristic ataca antes el cuello de botellaPreferencias no críticaspuedes bloquear una solución válida por mala elección tempranaLCV preserva alternativas para el resto del problemaSkin in the game

En producción, una heurística buena no solo ahorra CPU: reduce latencia, evita timeouts y permite explicar por qué el sistema declara “no hay solución” antes de probar combinaciones absurdas.

46Restricciones como guardrails

En apps con LLM, muchas garantías no deben vivir en el prompt. Deben vivir en schemas, validadores, permisos, políticas, límites de coste y reglas ejecutables que se comprueban fuera del modelo.

El prompt puede expresar intención, pero no debe ser la única frontera de seguridad. Las restricciones ejecutables convierten reglas de negocio, permisos y formatos en controles que se comprueban fuera del modelo.

El prompt orienta; el guardrail decide qué puede pasar. Un sistema fiable no confunde obediencia textual con autorización real.

Teoría aplicada

Un guardrail robusto separa intención lingüística de control ejecutable: el modelo propone, otra capa verifica.

Fórmula / criterio

Ejecutar solo si schema(args) AND permiso(user,action) AND politica(state,args) AND invariantes(output).

Ejemplo

El LLM puede sugerir “reembolsa al cliente”; el sistema debe comprobar importe, rol, estado del pedido y límites antes de llamar a la tool.

Decisión

Todo lo irreversible, caro, sensible o regulado debe pasar por controles fuera del prompt.

Intención del usuario→LLM propone→Schema valida→Permisos/políticas→Tool ejecuta→Log auditable

Softinstrucción: estilo, tono, criterio general

Hardcontrol ejecutable: schema, permiso, límite o regla

Invariantcondición que debe seguir siendo cierta tras actuar

HITLaprobación humana cuando el riesgo supera umbral

Prompt

Bueno para explicar intención, tono, políticas generales y ejemplos. Malo como única frontera: puede ser ambiguo, olvidado, contradicho o atacado por prompt injection.

blando

Restricción ejecutable

Schema JSON, validador, política de permisos, constraint solver, límite de coste o regla de negocio que acepta o rechaza una acción de forma comprobable.

duro

CapaQué controlaEjemploSchema de entradaforma y tipos de argumentosamount debe ser número positivo; currency ∈ {EUR, USD}Permisosquién puede hacer quésolo rol admin puede aprobar reembolso > 500 EURPolítica de negocioreglas dependientes del estadono reembolsar pedido ya reembolsado o en disputaLímites de coste/riesgopresupuesto y acciones peligrosasmáximo 3 tool calls o aprobación humana para pagosValidación de salidaformato, citas, groundedness e invariantestoda afirmación legal debe traer fuente recuperadaAuditoríatraza de decisión y efectoquién pidió, qué modelo decidió, qué tool se ejecutó y resultadoFallo típicoPor qué el prompt no bastaControl correctoPrompt injectionel usuario o documento intenta cambiar instruccionesseparar datos de instrucciones, permisos y allowlist de toolsArgumentos inválidosel modelo puede inventar campos o tiposschema estricto y errores recuperablesAcción no autorizadael modelo no es sistema de identidadRBAC/ABAC antes de tool callDato sensibleel modelo puede resumir o enviar información indebidafiltros de acceso, redacción y clasificación de datosEfecto irreversibleuna disculpa posterior no deshace una transferenciaaprobación humana, doble confirmación o cola de revisiónRegla de producción

Si una acción cambia dinero, permisos, datos personales, contratos, infraestructura o comunicaciones externas, el LLM no debería tener la última palabra sin validación ejecutable y trazabilidad.

47Cuándo usar CSP/SAT en vez de un LLM

Si la respuesta debe satisfacer restricciones exactas, el LLM puede ayudar a entender, explicar o proponer candidatos, pero la aceptación debería depender de una comprobación determinista.

Cuando una salida debe cumplir reglas exactas, conviene separar generación y verificación. El LLM puede traducir preferencias, explicar decisiones o proponer candidatos; el solver o validador decide si algo es válido.

Usa LLM para lenguaje ambiguo; usa validador para aceptar o rechazar; usa solver cuando no basta comprobar una respuesta y hay que encontrar una solución válida.

Teoría aplicada

La elección no es LLM contra solver: es lenguaje para ambigüedad, validador para reglas y solver para encontrar soluciones factibles.

Fórmula / criterio

Patrón robusto: candidato = LLM(input); aceptar solo si V(candidato, estado)=true. Optimización: min coste(x) sujeto a C(x).

Ejemplo

Un configurador puede usar LLM para explicar planes, pero un validador debe impedir descuentos incompatibles o add-ons prohibidos.

Decisión

Si una salida inválida cuesta dinero, riesgo legal, seguridad o pérdida de confianza, no la dejes solo en manos del prompt.

LLMinterpreta intención, resume, propone y explica

Validadorcomprueba si un candidato cumple reglas

Solverbusca una asignación factible u óptima

Humanodecide excepciones, riesgo y política no codificada

CasoLLMSolver / validadorCriterio de decisiónGenerar calendarioEntiende preferencias en lenguaje naturalGarantiza disponibilidad, descansos, salas y límitesSi hay solapes o cobertura mínima, necesitas validación determinista.Configurar productoExplica opciones al usuario y traduce necesidadesImpide combinaciones inválidas de plan, add-on, región o contratoSi una combinación inválida puede venderse o provisionarse, usa reglas.Cumplimiento legalResume requisitos y ayuda a mapearlosComprueba reglas codificadas, jurisdicción, permisos y evidenciasSi necesitas auditoría, el LLM no debe ser la única prueba.OptimizaciónPropone objetivos, restricciones y trade-offsBusca solución factible/óptima bajo coste, tiempo o recursosSi hay muchas combinaciones, el solver explora mejor que un chat.Acción con toolPropone la llamada y explica intenciónSchema, permisos y políticas bloquean argumentos inválidosSi la tool cambia el mundo, valida antes de ejecutar.Pregunta de diseñoSi la respuesta es sí...Arquitectura recomendada¿La salida puede ser parcialmente útil aunque no sea perfecta?SíLLM + revisión o eval ligera puede bastar¿Hay reglas duras que nunca deben violarse?SíLLM + validador determinista¿Hay que encontrar una combinación válida entre muchas?SíSolver CSP/SAT/optimización, con LLM como interfaz¿Hay preferencias blandas además de reglas duras?SíSolver con función de coste o ranking de candidatos válidos¿Hay riesgo legal, económico o de seguridad?SíValidador, auditoría, permisos y aprobación humanaPatrón sano

Separar generación y verificación: el LLM produce un candidato legible; el sistema lo convierte a estructura; el validador o solver decide; el LLM explica el resultado al usuario sin saltarse la decisión formal.

48Qué debe saber: restricciones

Las restricciones son una forma de precisión. Donde hay reglas duras, no todo debe quedarse en manos del modelo generativo: hay que separar lo que el modelo interpreta de lo que el sistema acepta.

El mensaje central es que precisión y creatividad viven en capas distintas. Un buen sistema usa el modelo para manejar ambigüedad y usa restricciones para impedir que esa ambigüedad rompa reglas duras.

Creatividad y garantía viven en capas distintas: el LLM maneja ambigüedad; SAT, CSP, schemas, políticas y validadores impiden romper reglas duras.

Teoría aplicada

El bloque de restricciones enseña a separar generación, búsqueda y verificación. Esa separación es una base de sistemas fiables con LLMs.

Fórmula / criterio

SAT: SAT/UNSAT. CSP: (X,D,C). Guardrail: aceptar salida solo si cumple schema, permisos, políticas e invariantes.

Ejemplo

Un agente puede proponer un calendario, una configuración o un reembolso; las restricciones deciden si eso puede ejecutarse.

Decisión

Cuando una regla sea dura, conviértela en código, solver, política o test; no la dejes solo como frase en el prompt.

SATsatisfacible o contradicción booleana

CSPvariables, dominios, restricciones y solución consistente

Searchbacktracking, propagación y heurísticas para no explotar

Guardrailsvalidación ejecutable fuera del prompt

Debes poder explicarFórmula mentalConexión modernaError que debes detectarSAT = asignar booleanos que satisfacen una fórmulaCNF: cláusulas AND; cada cláusula es OR de literalesverificación, planning, configuración, dependenciasrequisitos incompatibles que un texto puede maquillarCSP = variables + dominios + restriccionesCSP=(X,D,C); solución si toda restricción se cumplescheduling, permisos, validación, asignación de recursosmezclar preferencias blandas con reglas durasBacktracking y propagaciónprobar valor, podar dominios, volver si hay contradicciónworkflows, planners, búsqueda de configuracionesdescubrir tarde una imposibilidad que se podía detectar antesHeurísticasMRV, degree, LCV, forward checkingmenos latencia, menos coste, menos timeoutsfuerza bruta donde el orden de búsqueda importaGuardrails deterministasschema AND permiso AND política AND invariantestools, agentes, RAG, compliance y operacionesconfiar en “el prompt dice que no lo haga” como barrera realPregunta de repasoRespuesta esperada¿Qué devuelve SAT?SAT con un modelo válido, o UNSAT si no existe asignación bajo esa codificación.¿Qué añade CSP frente a SAT?Dominios no necesariamente booleanos y restricciones más naturales sobre variables.¿Por qué propagar restricciones?Para eliminar valores imposibles antes de profundizar y fallar antes.¿Qué papel tiene el LLM?Traducir lenguaje, proponer candidatos y explicar resultados, no garantizar reglas duras por sí solo.¿Qué se audita en producción?Entrada, candidato, reglas aplicadas, decisión del validador, tool ejecutada y efecto final.Examen mental

Si una persona del equipo no puede decir qué regla se comprobó, dónde vive esa regla y qué pasa cuando falla, todavía no tienes un guardrail: tienes una intención escrita.

49Planificación automática: de objetivo a plan

Planificar es encontrar una secuencia de acciones que transforme el estado inicial en un estado objetivo. La diferencia con una lista de tareas es que cada acción solo es válida si sus precondiciones se cumplen y sus efectos actualizan el estado.

La planificación formaliza algo que hacemos intuitivamente: pasar de un objetivo a una secuencia de acciones. La diferencia es que obliga a declarar qué debe ser cierto antes de actuar y qué cambia después.

Un plan no es “lo que suena razonable”; es una trayectoria verificable desde s0 hasta goal.

Teoría aplicada

Planificar es buscar una secuencia de acciones que cambia el mundo desde un estado inicial hasta un objetivo.

Fórmula / criterio

Plan pi=[a1..ak]; aplicar result(...result(s0,a1),ak) debe satisfacer goal.

Ejemplo

Preparar una release: tests verdes, changelog, tag, build, despliegue y verificación posterior.

Decisión

Antes de ejecutar, declara estado inicial, objetivo, acciones legales, precondiciones, efectos y criterio de parada.

Estado inicial→Acciones disponibles→Precondiciones→Efectos→Plan

s0estado inicial: hechos que sabemos al empezar

**A(s)**acciones aplicables en el estado actual

**result(s,a)**estado tras ejecutar una acción válida

**goal(s)**test que dice si el objetivo está logrado

PreguntaEn planificaciónEn un agente LLM¿Dónde estoy?estado inicial y hechos verdaderoscontexto, memoria, filesystem, APIs y logs¿Qué puedo hacer?acciones con precondicionestools disponibles con permisos y schemas¿Qué cambia si actúo?efectos add/delete sobre el estadosalida de tool, archivo modificado, ticket creado¿Cuándo paro?objetivo satisfecho o no hay planeval de tarea, tests, confirmación humana o límite de costeSkin in the game

En producción, un plan mal modelado no falla como “respuesta incorrecta”: puede enviar un email, desplegar código, cambiar datos o gastar dinero en el orden equivocado. Por eso planning va unido a permisos, validación y trazas.

50Vocabulario de planificación

La planificación clásica obliga a explicitar lo que muchos agentes modernos dejan implícito. Este vocabulario es útil aunque nunca escribas PDDL: te da una forma de revisar si una automatización sabe actuar o solo redacta pasos.

Este vocabulario es la base para diseñar tools seguras. Si no sabes decir qué precondición necesita una acción y qué efecto produce, el agente puede ejecutar pasos plausibles pero inválidos.

Predicado, acción, precondición y efecto son el contrato mínimo de una tool ejecutable.

Teoría aplicada

El vocabulario de planning convierte intención en condiciones verificables: hechos, acciones, precondiciones y efectos.

Fórmula / criterio

Acción a es aplicable si pre(a) se cumple; después se aplican add(a) y delete(a).

Ejemplo

No puedes “enviar factura” si faltan datos fiscales; validar la factura cambia el estado y habilita enviar.

Decisión

Si una tool no tiene precondiciones y efectos claros, todavía no está lista para un agente fiable.

predicadohecho verificable: true/false

**pre(a)**lo que debe ser cierto antes de actuar

**add(a)**hechos que pasan a ser ciertos

**del(a)**hechos que dejan de ser ciertos

TérminoQué significaEjemploPor qué importaPredicadoHecho que puede ser verdadero/falsofactura_validada(f123)si no puedes comprobarlo, no lo uses como condición críticaAcciónOperador disponible que cambia estadoenviar_factura(f123, cliente)debe tener contrato, permisos y efecto observablePrecondiciónLo que debe cumplirse para ejecutarfactura_validada(f123) AND email_confirmado(cliente)evita pasos plausibles pero inválidosEfectoLo que cambia tras ejecutaremail_enviado(f123) AND not borrador(f123)permite auditar progreso y no repetir accionesInvarianteRegla que nunca debe romperseimporte_total >= 0; destinatario pertenece al clienteprotege negocio aunque el plan sea creativoFrase ambiguaVersión planificable“manda la factura cuando esté lista”pre: factura_validada AND email_confirmado; effect: email_enviado“haz deploy si todo va bien”pre: tests_ok AND build_ok AND aprobacion_si_riesgo; effect: version_desplegada“avisa al cliente si falta algo”pre: datos_incompletos AND canal_permitido; effect: mensaje_enviado + caso_actualizado

51PDDL: lenguaje para describir planes

PDDL separa dominio y problema: una parte define acciones generales y otra define objetos, estado inicial y objetivo. Su valor pedagógico es enorme porque obliga a escribir exactamente qué necesita y qué cambia cada acción.

PDDL es importante aunque no lo uses a diario porque muestra una separación mental muy sana: reglas generales del mundo por un lado, caso concreto por otro. Esa misma separación aparece en prompts, workflows y agentes robustos.

PDDL es menos importante como sintaxis que como disciplina: no puedes ejecutar una acción si no has declarado cuándo es válida.

Teoría aplicada

PDDL obliga a separar reglas generales del mundo y caso concreto. Esa separación evita prompts monolíticos imposibles de auditar.

Fórmula / criterio

Dominio = tipos + predicados + acciones. Problema = objetos + init + goal.

Ejemplo

La acción pick-up sirve para muchos objetos; el problema decide qué robot, sala y objeto existen hoy.

Decisión

Usa PDDL como modelo mental aunque no uses PDDL en producción: separa contrato de acción y estado del caso.

domaintipos, predicados y acciones reutilizables

problemobjetos, estado inicial y objetivo concreto

:preconditioncondiciones para aplicar acción

:effecthechos añadidos o eliminados

Línea del ejemploLectura:parametersvariables que la acción puede recibir: robot, objeto y habitación:preconditionel robot y el objeto están en la misma habitación y la mano está libre:effectel robot sostiene el objeto; el objeto deja de estar en la habitación; la mano deja de estar librenot (...)PDDL modela también hechos que dejan de ser ciertos, no solo nuevos hechos``` (:action pick-up :parameters (?robot ?object ?room) :precondition (and (at ?robot ?room) (at ?object ?room) (handempty ?robot)) :effect (and (holding ?robot ?object) (not (at ?object ?room)) (not (handempty ?robot))))

Conexión con tools

Una tool moderna debería tener algo parecido a PDDL: parámetros tipados, precondiciones comprobables, efectos registrados y errores recuperables\. Si solo tiene un nombre bonito, el agente opera a ciegas\.

## 52Dominio vs problema

Separar dominio y problema permite reutilizar acciones en escenarios distintos\. Es la misma idea que separar código de configuración: no cambias la lógica de “mover paquete” cada vez que cambia el paquete\.

Separar dominio y problema evita rehacer conocimiento\. Si el dominio describe cómo funcionan las acciones, puedes cambiar objetos, estado inicial u objetivo sin rediseñar toda la lógica\.

Dominio es el contrato del mundo; problema es la instancia de hoy\.

**Teoría aplicada**

Dominio y problema separan conocimiento reutilizable de instancia concreta\.

**Fórmula / criterio**

domain describe operadores; problem instancia objetos, estado inicial y objetivo\.

**Ejemplo**

El dominio “logística” sabe mover paquetes; el problema dice qué paquetes, ciudades y camiones hay ahora\.

**Decisión**

No dupliques reglas en cada workflow: modela acciones comunes y cambia solo el estado y objetivo\.

Dominio

Tipos, predicados y acciones\. Define cómo funciona el mundo: qué acciones existen, cuándo son válidas y qué efectos producen\.

reutilizable

Problema

Objetos concretos, estado inicial y objetivo\. Define el caso específico: qué recursos hay hoy y qué queremos conseguir\.

instancia

EjemploDominioProblemaLogísticacargar, descargar, conducir; capacidad y ubicaciónpaquete P1, camión T2, Madrid, Valencia, objetivo entregar P1Release softwaretest, build, deploy, rollbackversión 2\.4\.1, staging verde, objetivo producción actualizadaAtención al clienteconsultar pedido, reembolsar, escalarpedido \#123, usuario autenticado, objetivo resolver incidenciaError común

Meter detalles de la instancia dentro del dominio crea automatizaciones frágiles: cada nuevo caso obliga a reescribir reglas\. En agentes, pasa lo mismo cuando el prompt mezcla política general con datos del ticket actual\.

## 53Planificación como búsqueda heurística

Un planner puede buscar en el espacio de estados, pero necesita heurísticas para no explotar combinatoriamente\. En problemas reales, el número de planes posibles crece con cada acción disponible y cada paso del horizonte\.

Un planner puede verse como un buscador especializado\. La dificultad no es solo encontrar una secuencia, sino no perderse entre miles de acciones posibles y estados intermedios irrelevantes\.

La heurística convierte “probar planes” en “probar primero los planes con más pinta de acercarse al objetivo”\.

**Teoría aplicada**

Planificar puede verse como búsqueda en estados, pero las heurísticas deciden qué caminos merecen presupuesto\.

**Fórmula / criterio**

Nodo = conjunto de hechos; sucesor = aplicar acción válida; h\(s\) estima distancia al goal\.

**Ejemplo**

Un planner de despliegue prioriza acciones que desbloquean dependencias en vez de pasos decorativos\.

**Decisión**

Si el espacio de acciones crece, necesitas heurística, límites y trazas; no basta “razonar más”\.

**b**acciones aplicables por estado

**d**longitud de plan buscada

**O\(b^d\)**crecimiento bruto del árbol de planes

**h\(s\)**estimación de coste restante hasta goal

ElementoEn búsquedaEn planificaciónEn un agente modernoNodoEstado alcanzadoConjunto de hechos verdaderoscontexto \+ estado persistente tras tool callsAristaAcción aplicadaOperador con precondiciones y efectostool call, edición de archivo, consulta o navegaciónObjetivoEstado metaHechos que deben ser verdaderostests verdes, ticket resuelto, deploy verificadoHeurísticaCoste estimado restanteacciones necesarias aproximadasrouting, eval parcial, prioridad de checksHeurística de planningIdeaCuidadorelaxed planning graphignora algunos efectos negativos para estimar distanciarápida pero optimistalandmarkshechos que todo plan debe lograr alguna vezútil para no perder pasos inevitablescoste de accionespenaliza acciones caras o peligrosassi el coste está mal, optimiza lo incorrecto
## 54Planificación con SAT

También puedes convertir planning en satisfacibilidad: ¿existe un conjunto de acciones por tiempo que cumple transiciones y objetivo? En vez de caminar por estados, preguntas si hay una historia coherente de longitud k\.

La planificación con SAT enseña que un mismo problema puede reformularse\. En vez de caminar por estados, preguntas si existe un conjunto de acciones en un horizonte temporal que haga coherente toda la historia\.

Planning con SAT cambia búsqueda secuencial por verificación lógica de un horizonte temporal\.

**Teoría aplicada**

Planning con SAT codifica acciones, estados y transiciones por pasos temporales y pregunta si existe un plan de longitud k\.

**Fórmula / criterio**

Variables: accion\(a,t\), hecho\(p,t\)\. Restricciones: precondiciones, efectos, exclusión y goal en t=k\.

**Ejemplo**

Si no hay plan con k=3, pruebas k=4; si aparece modelo SAT, sus acciones forman el plan\.

**Decisión**

Úsalo cuando necesites una prueba clara de factibilidad bajo un horizonte y reglas exactas\.

Horizonte k→Variables por tiempo→Restricciones de acción→Objetivo→SAT solver

**p@t**hecho p es verdadero en tiempo t

**a@t**acción a ocurre entre t y t\+1

**k**horizonte máximo del plan

**SAT/UNSAT**existe o no plan de longitud k

Restricción codificadaQué impideprecondiciones: si a@t entonces pre\(a\)@tacciones ejecutadas sin requisitosefectos: si a@t entonces effect\(a\)@t\+1historias donde actuar no cambia nadaframe axiomshechos que persisten si nadie los cambiamundos que olvidan estado arbitrariamentemutex/exclusiónacciones incompatibles en el mismo pasodos acciones compitiendo por el mismo recursogoal@kel objetivo debe cumplirse al finalplanes que hacen cosas pero no resuelvenLectura práctica

Aumentas k hasta encontrar plan\. Si k=3 es UNSAT y k=4 es SAT, el modelo SAT te devuelve qué acciones ocurren en cada paso\. Eso da una evidencia mucho más fuerte que “el LLM cree que tres pasos bastan”\.

## 55Planning y agentes LLM

Los agentes modernos planifican, pero muchas veces sin modelo formal del mundo\. Eso da flexibilidad para tareas abiertas, y también errores cuando el modelo inventa recursos, salta dependencias o confunde observación con éxito\.

Los agentes LLM ganan flexibilidad porque entienden instrucciones abiertas, pero pierden garantías si no se valida su plan\. Por eso los planes generados deben pasar por permisos, estado actualizado y checks antes de ejecutar\.

El LLM puede proponer pasos; el sistema debe comprobar si cada paso es legal, útil y verificable\.

**Teoría aplicada**

Un agente LLM planifica en lenguaje natural, pero el plan solo es ejecutable si sus pasos pasan estado, permisos y validación\.

**Fórmula / criterio**

Propuesta LLM \-\> validar precondiciones \-\> ejecutar tool \-\> observar efecto \-\> actualizar estado\.

**Ejemplo**

Un agente de código no debe “asumir tests verdes”: debe ejecutarlos y registrar el resultado\.

**Decisión**

Combina flexibilidad del LLM con checks formales antes de cada acción que cambie el mundo\.

Plan textual→Validar paso→Ejecutar tool→Observar efecto→Actualizar estado→Replanificar

Planner clásicoAgente LLMControl recomendadoEjemploPrecondiciones explícitasEl modelo infiere si puede actuarvalidadores antes de tool callno ejecutar deploy si build no existeEfectos modeladosObservación tras ejecutarlogs y estado persistenteleer resultado de tests, no asumirlosPlan completo o parcialPlan textual revisableHITL en pasos críticospedir aprobación antes de borrar datosÓptimo o factibleSuficientemente buenoeval por tarea aceptadaresolver ticket con cita y acción correctaCoste explícitoTokens y tool calls dispersosbudget y paradano iterar 20 veces sin nueva evidenciaPatrón práctico

Para agentes con tools, piensa en “plan\-monitor\-replan”: el agente propone, ejecuta un paso, observa realidad, actualiza estado y solo entonces decide el siguiente\. Evita planes largos ejecutados a ciegas\.

## 56Fallos típicos al planificar

Un plan puede sonar razonable y ser imposible\. La diferencia entre demo y sistema fiable está en comprobar precondiciones, efectos, dependencias y criterio de recuperación\.

Un fallo de planificación no siempre parece fallo: a veces suena razonable\. La pedagogía aquí es entrenar el ojo para detectar recursos inexistentes, dependencias omitidas, acciones fuera de orden y bucles sin información nueva\.

Los fallos de planning no siempre parecen errores: muchas veces son pasos plausibles en el orden equivocado\.

**Teoría aplicada**

Los fallos de planning suelen sonar razonables: recurso inexistente, orden incorrecto, estado oculto o bucle sin información\.

**Fórmula / criterio**

Fallo típico: pre\(a\)=false, efecto no observado, goal ambiguo o loop sin nueva evidencia\.

**Ejemplo**

Enviar email antes de confirmar destinatario puede parecer un paso natural y ser un incidente\.

**Decisión**

Añade validación antes/después, límites de reintento y rollback o escalado humano\.

**Precondición falsa**

El agente intenta usar un dato, permiso o recurso que no existe\.

validar antes

**Orden incorrecto**

Ejecuta antes de preparar dependencias o confirma antes de calcular\.

orden causal

**Estado oculto**

No sabe que una acción ya cambió el entorno o que otro proceso lo cambió\.

estado fresco

**Loop**

Reintenta sin nueva información, sin límite y sin cambiar hipótesis\.

parada

SíntomaCausa probableControl“No encuentro el archivo” repetidono actualiza estado tras listar o buscarregistrar observaciones y cambiar estrategiaPlan usa permiso inexistenteprecondiciones no verificadascomprobar RBAC/credenciales antes de toolAcción peligrosa demasiado prontodependencias omitidasgates: tests, aprobación, backup, dry\-runPlan infinitoobjetivo ambiguo o no mediblecriterio de parada y escalado humanoDebug de agentes

Cuando un agente falle, no mires solo el último mensaje\. Revisa estado inicial, plan, precondiciones de cada tool, observaciones reales y qué hecho hizo cambiar o no cambiar el plan\.

## 57Mini\-ejemplo: enviar una factura

Modelar una tarea cotidiana como planificación fuerza a separar intención, datos y permisos\. “Enviar una factura” parece una acción única, pero en producción es una secuencia con validaciones y efectos auditables\.

Las tareas cotidianas son perfectas para practicar porque conocemos sus reglas implícitas\. Al convertirlas en estado, acciones y guardrails se ve qué parte puede automatizarse y qué parte requiere confirmación humana\.

La tarea simple revela el patrón completo: estado, acciones, precondiciones, efectos, excepción y humano\.

**Teoría aplicada**

Un ejemplo pequeño muestra que automatizar no es listar pasos: es modelar estado, permisos y efectos\.

**Fórmula / criterio**

Estado inicial \+ acciones aplicables \+ goal \+ guardrails = workflow ejecutable\.

**Ejemplo**

Factura: completar datos, validar importe, pedir aprobación si supera umbral y enviar al email confirmado\.

**Decisión**

Convierte tareas cotidianas en planning antes de darles autonomía a tools o agentes\.

PiezaEjemploRiesgo si faltaEstado inicialcliente existe, factura borrador, email no enviadoel agente inventa datos o repite envíosObjetivofactura validada y enviada al cliente correctose optimiza “hacer algo” y no resolverAcción completar datospre: cliente identificado; efecto: datos fiscales completos o bloqueofactura inválidaAcción validarpre: importe y datos fiscales completos; efecto: factura validadase envía documento incorrectoAcción enviarpre: factura validada y email confirmado; efecto: email enviado \+ logenvío a destinatario equivocadoGuardrailsi importe \> umbral o cliente sensible, pedir aprobación humanariesgo económico o legalPasoQué debe registrar el sistemavalidaciónquién validó, reglas aplicadas, versión de plantillaaprobaciónpersona, timestamp, motivo, umbralenvíodestinatario, canal, proveedor, id de mensajefallocausa estructurada y siguiente acción permitida
## 58Qué debe saber: planificación

Planificar no es “pensar mucho”: es convertir un objetivo en acciones ejecutables bajo restricciones, con estado observable y recuperación cuando el mundo no coincide con el plan\.

Saber planificación no significa escribir PDDL de memoria\. Significa leer cualquier automatización y preguntar: cuál es el estado, qué acción es legal, qué efecto se espera y cómo se recupera si algo falla\.

Un alumno debe salir pudiendo mirar cualquier workflow con tools y preguntar: estado, acción, precondición, efecto, coste, parada\.

**Teoría aplicada**

Saber planificación significa reconocer acciones ejecutables y no confundir un plan textual con un plan válido\.

**Fórmula / criterio**

Plan válido = secuencia de acciones aplicables que transforma s0 en un estado que satisface goal\.

**Ejemplo**

Un plan de migración debe declarar dependencias, checks, efectos y rollback, no solo pasos bonitos\.

**Decisión**

Evalúa agentes por planes ejecutables y verificados, no por razonamientos que suenan completos\.

**estado**qué hechos son ciertos ahora

**acción**qué operación está permitida

**efecto**qué cambia y cómo lo sé

**recuperación**qué pasa si falla o contradice el plan

Debes poder explicarConexión modernaPregunta de controlEstado inicial, objetivo y accionestodo agente necesita estado y herramientas¿qué sabe el sistema y qué intenta conseguir?Precondiciones y efectosvalidadores antes/después de tools¿qué debe ser cierto antes y después de cada acción?PDDL como lenguaje formalprompting estructurado y diseño de workflows¿separé reglas generales de caso concreto?Planning con heurísticas o SATbúsqueda eficiente de planes¿cómo evito probar planes absurdos?Plan\-monitor\-replanagentes que observan y corrigen¿qué evidencia hace cambiar el plan?Qué debe quedar

Un plan textual sin estado, precondiciones, efectos y verificación es documentación, no automatización\. Puede ser útil para humanos, pero no debería ejecutar tools críticas\.

## 59Juegos: decisión con otros agentes

Los juegos enseñan decisión en entornos donde otro actor también elige\. Eso introduce estrategia, adversario, incentivos e incertidumbre: justo lo que aparece en fraude, seguridad, mercados, negociación y agentes con herramientas\.

Los juegos introducen un elemento que no aparece en una ruta estática: otros actores responden\. Esta idea se traslada a seguridad, fraude, mercados y cualquier producto donde los usuarios adapten su conducta al sistema\.

La pregunta deja de ser “qué acción es buena” y pasa a ser “qué acción sigue siendo buena cuando otros reaccionan”\.

**Teoría aplicada**

Los juegos modelan decisiones donde otros actores reaccionan\. Esto introduce estrategia, incentivos y comportamiento adversarial\.

**Fórmula / criterio**

Juego = estados, acciones, jugadores, transición, utilidad e información disponible\.

**Ejemplo**

Un sistema antifraude cambia el comportamiento del atacante cuando empieza a bloquear patrones\.

**Decisión**

Si alguien puede adaptarse a tu sistema, evalúa reacción y abuso, no solo el caso cooperativo\.

**Jugador**actor con objetivos propios

**Utilidad**valor de un resultado para cada actor

**Información**qué sabe cada jugador al decidir

**Estrategia**regla para elegir acciones según estado

**Varios jugadores**

Tus acciones cambian las opciones del otro, y el otro puede cambiar las tuyas\.

interacción

**Información**

Perfecta, imperfecta, completa o incompleta\. No es igual jugar ajedrez que detectar fraude oculto\.

observabilidad

**Utilidad**

Cada resultado tiene valor distinto para cada actor: ganar, ahorrar coste, evadir control o causar daño\.

incentivo

**Árbol de juego**

Estados alternando turnos y decisiones; el futuro depende de respuestas, no solo de pasos propios\.

anticipación

Producto realQuién reaccionaQué aprendes del bloqueAntifraudeatacantes adaptan patronesno entrenes solo contra el fraude de ayerModeraciónusuarios bordean reglasevalúa evasión, no solo contenido obvioPricingclientes y competidores respondenlos incentivos cambian la distribuciónAgentes con toolsinputs externos intentan manipulardiseña permisos y límites adversariales
## 60Minimax: elegir contra un rival óptimo

Minimax asume dos jugadores: MAX intenta maximizar utilidad y MIN intenta minimizarla\. No busca la jugada que parece mejor si nadie responde: busca la mejor jugada después de considerar la mejor respuesta del rival\.

Minimax enseña a decidir suponiendo que el otro jugador también busca su mejor resultado\. No es una receta para todo, pero sí un modelo mental para pensar en adversarios, trade\-offs y consecuencias futuras\.

Minimax enseña a no evaluar una acción aislada: evalúa la cadena de respuestas que habilita\.

**Teoría aplicada**

Minimax decide suponiendo que el rival elegirá la respuesta que peor deja a MAX\.

**Fórmula / criterio**

V\(s\)=max\_a min\_b V\(result\(s,a,b\)\) en juegos de suma cero y turnos alternos\.

**Ejemplo**

En ajedrez, una jugada brillante no sirve si permite una respuesta forzada ganadora del rival\.

**Decisión**

Úsalo como modelo mental para riesgo adversarial: pregunta siempre qué haría el otro si ve tu jugada\.

MAX elige→MIN responde→Estados terminales→Propagar valores→Mejor jugada

**MAX**elige la acción con mayor valor garantizado

**MIN**elige la respuesta que reduce ese valor

**V\(s\)**valor propagado del estado

**depth**profundidad que puedes mirar antes de cortar

NivelQué ocurreLecturaHojaestado terminal o evaluadoasignas utilidad: ganar=\+1, perder=\-1, empate=0Turno MINelige el mínimo valor entre sucesoresasumes que el rival castiga tu peor debilidadTurno MAXelige el máximo valor entre sucesoreseliges la mejor garantía, no el mejor deseoRaízacción recomendadala jugada robusta frente a respuesta óptimaSupuesto fuerte

Minimax es apropiado como modelo mental cuando el rival tiene objetivos opuestos y puede responder bien\. En producto, úsalo para pensar en atacantes, competidores o usuarios que optimizan contra tus reglas\.

## 61Poda alfa\-beta

Alfa\-beta no cambia la decisión de minimax\. Solo evita explorar ramas que ya no pueden mejorar el resultado\. Es una lección importante: optimizar no siempre significa cambiar la respuesta; a veces significa llegar a la misma respuesta gastando muchísimo menos\.

La poda alfa\-beta muestra que optimizar no siempre significa cambiar la respuesta; a veces significa llegar a la misma respuesta evitando trabajo inútil\. Esa idea reaparece en caching, pruning y routing moderno\.

Poda es saber cuándo una rama ya no merece atención porque no puede cambiar la decisión final\.

**Teoría aplicada**

La poda alfa\-beta conserva la decisión de minimax, pero evita explorar ramas que ya no pueden cambiar el resultado\.

**Fórmula / criterio**

Alpha = mejor opción de MAX; beta = mejor opción de MIN; si alpha \>= beta, poda\.

**Ejemplo**

Si ya tienes una alternativa segura, no gastes tiempo evaluando una rama que el rival nunca permitiría\.

**Decisión**

Ordenar bien candidatos puede ahorrar enorme coste sin cambiar la respuesta final\.

**α**mejor valor ya garantizado para MAX

**β**mejor valor ya garantizado para MIN

**α ≥ β**condición típica de poda

**orden**mejor ordering produce más poda

ValorQué representaUsoIntuición aplicadaAlfaMejor valor garantizado para MAXsi una rama no lo supera, se podaya tengo una alternativa suficientemente buenaBetaMejor valor garantizado para MINsi MAX ya tiene alternativa mejor, se cortael rival no permitirá esta líneaOrden de movimientosqué rama exploras primeromejor orden = más podamirar primero candidatos prometedores ahorra presupuestoResultadomisma jugada que minimaxmenos nodos exploradosoptimización sin cambiar semánticaConexión con LLMs

En agentes, pruning significa no llamar tools, modelos caros o búsquedas que ya no pueden cambiar la decisión\. Para eso necesitas puntuaciones parciales, límites y criterios de descarte\.

## 62Funciones de evaluación

Cuando no puedes llegar al final del árbol, evalúas estados intermedios con una función heurística\. La calidad de esa función determina qué ramas parecen prometedoras y qué errores se vuelven sistemáticos\.

Cuando no puedes mirar hasta el final, necesitas evaluar estados intermedios\. Esa función de evaluación concentra conocimiento del dominio, y sus sesgos se convierten directamente en malas decisiones\.

Una función de evaluación es conocimiento del dominio convertido en número; si premia mal, el sistema aprende o busca mal\.

**Teoría aplicada**

Cuando no puedes explorar hasta terminales, una función de evaluación aproxima el valor de estados intermedios\.

**Fórmula / criterio**

Eval\(s\)=w1\*f1\(s\)\+\.\.\.\+wn\*fn\(s\), o una red/modelo que estima valor\.

**Ejemplo**

En ajedrez: material, seguridad del rey, movilidad y estructura de peones aproximan ventaja\.

**Decisión**

Audita qué premia tu función: una heurística mal diseñada optimiza comportamientos equivocados\.

**Eval\(s\)**score aproximado de un estado no terminal

**features**señales del estado que importan

**pesos**importancia relativa de cada señal

**sesgo**lo que la función ignora también decide

**Límite de profundidad**

Cortas búsqueda por tiempo, coste o profundidad\. La evaluación decide qué hacer sin ver el final\.

presupuesto

**Score heurístico**

Estima qué tan bueno es el estado con señales observables\.

aproximación

**Dominio**

La función debe capturar lo que importa: material, riesgo, coste, cobertura o seguridad\.

criterio

**Sesgo**

Una mala función produce decisiones convincentes pero dañinas\.

Goodhart

DominioEval útilError si faltaAjedrezmaterial \+ movilidad \+ seguridad del reycapturar piezas y dejar mate en una jugadaAgente de soporteresolución \+ satisfacción \+ coste \+ riesgocerrar tickets rápido sin resolverlosRAGrelevancia \+ groundedness \+ cita \+ actualidadrespuestas fluidas sin evidenciaSeguridadimpacto \+ probabilidad \+ detectabilidadoptimizar falsos positivos o dejar abuso real
## 63Monte Carlo: decidir simulando

Monte Carlo estima resultados probando muchas simulaciones\. No necesita evaluar todo el árbol exactamente: acepta incertidumbre medible a cambio de explorar un espacio enorme con presupuesto finito\.

Monte Carlo cambia exactitud por estimación controlada\. En vez de recorrer todo el árbol, simula muchas trayectorias y usa la frecuencia de resultados para decidir con incertidumbre explícita\.

Simular muchas trayectorias convierte “no puedo calcularlo todo” en “puedo estimar con error controlado”\.

**Teoría aplicada**

Monte Carlo estima valor simulando trayectorias\. Cambia búsqueda exacta por muestreo controlado\.

**Fórmula / criterio**

Valor estimado = media de retornos simulados; el error baja aproximadamente con 1/sqrt\(n\)\.

**Ejemplo**

Simular muchas partidas aleatorias da una señal de qué movimiento tiende a terminar mejor\.

**Decisión**

Úsalo cuando el espacio sea grande y puedas aceptar estimación con incertidumbre explícita\.

Seleccionar→Expandir→Simular→Retropropagar valor→Elegir

**n**número de simulaciones

**media**valor estimado por resultados observados

**varianza**incertidumbre de las simulaciones

**1/sqrt\(n\)**intuición de reducción de error

PasoQué haceRiesgo prácticoSimularjuega o proyecta una trayectoria posiblesi el simulador es malo, estimas basuraMedir retornoasigna resultado: victoria, coste, reward, conversiónsi la métrica es mala, optimizas malRepetiraumenta n para reducir ruidocoste crece con simulacionesDecidirelige la acción con mejor estimaciónno confundas estimación con certeza
## 64MCTS: exploración vs explotación

Monte Carlo Tree Search balancea probar ramas prometedoras y explorar opciones menos visitadas\. Su valor está en asignar presupuesto de simulación de forma adaptativa: más donde aprende, algo donde todavía no sabe\.

MCTS es útil porque no reparte el presupuesto de simulación por igual\. Invierte más en ramas prometedoras sin dejar de explorar alternativas, equilibrando explotación y descubrimiento\.

MCTS no reparte el tiempo por igual: invierte en ramas con buena señal sin dejar de explorar alternativas\.

**Teoría aplicada**

MCTS reparte simulaciones entre explorar opciones nuevas y explotar las que parecen prometedoras\.

**Fórmula / criterio**

UCT suele combinar valor medio \+ c\*sqrt\(ln\(N\)/n\) para balancear exploración\.

**Ejemplo**

AlphaGo popularizó esta idea: no mirar todo, sino invertir presupuesto donde más aprende\.

**Decisión**

Diseña presupuestos, criterio de parada y métrica de valor antes de confiar en simulaciones\.

**Q\(s,a\)**valor medio observado de una acción

**N\(s,a\)**visitas a esa acción

**UCT**valor \+ bonus de exploración

**c**controla cuánto exploras

FasePreguntaQué se aprendeSelection¿Qué rama parece mejor según valor y visitas?usa lo aprendido hasta ahoraExpansion¿Qué nuevo hijo añadimos al árbol?abre una posibilidad no probadaSimulation¿Qué pasa si jugamos hasta el final o aproximamos?estima retorno con una trayectoriaBackpropagation¿Cómo actualizamos valor y visitas?convierte resultado en mejor decisión futuraParámetro de diseñoEfectomás exploracióndescubre opciones raras pero gasta más presupuestomás explotaciónprofundiza en lo prometedor pero puede atascarsesimulador pobrepropaga señales poco fiablesbudget bajoresultado sensible al azar y al orden inicial
## 65Simulación y LLMs

Un LLM puede simular escenarios, pero sus simulaciones no son garantías estadísticas si no controlas datos, aleatoriedad y evaluación\. El modelo genera plausibilidad textual, no muestras independientes de un proceso real\.

Un LLM puede generar escenarios plausibles, pero plausibilidad no es muestreo estadístico\. Para usarlo como simulador necesitas controlar prompts, temperatura, casos, jueces y contraste con datos reales\.

Usa simulación con LLM para descubrir hipótesis y casos; no para demostrar una tasa real sin contraste\.

**Teoría aplicada**

Un LLM puede producir escenarios plausibles, pero plausibilidad lingüística no equivale a muestra estadística\.

**Fórmula / criterio**

Simulación fiable requiere distribución definida, control de aleatoriedad, n suficiente y validación externa\.

**Ejemplo**

Pedir “simula usuarios” puede revelar ideas, pero no estima conversión real sin datos y eval\.

**Decisión**

Usa LLMs para generar hipótesis; usa datos, experimentos o simuladores formales para evidencia\.

Monte Carlo clásico

Muestras de un proceso definido\. Puedes estimar error, aumentar simulaciones y razonar sobre distribución\.

modelo explícito

Simulación con LLM

Genera escenarios plausibles condicionados por prompt y datos de entrenamiento\. Útil para idear, peligroso como evidencia final\.

plausibilidad

UsoSí aportaNo demuestraRed teamingcasos de abuso, variaciones de ataque, inputs rarosfrecuencia real de ataquesProductohistorias de usuario y objeciones posiblesconversión o retención esperadaSoportetickets sintéticos para entrenar criteriosdistribución real de incidenciasEvalscasos iniciales para ampliar coberturacalidad final sin datos reales o revisiónRegla práctica

Cuando un LLM “simula usuarios”, trátalo como generador de hipótesis\. Para tomar decisiones, pide contraste: logs reales, experimento, eval humana o simulador formal\.

## 66Decisión adversarial en producto

La lógica de juegos aparece cuando usuarios, atacantes o competidores reaccionan a tu sistema\. La seguridad de agentes y LLMs exige pensar en incentivos: quién gana si tu sistema se equivoca\.

Pensar adversarialmente evita diseñar solo para usuarios ideales\. En IA aplicada siempre hay incentivos: alguien puede intentar manipular instrucciones, explotar herramientas o encontrar el borde de tus permisos\.

Diseñar solo para el usuario ideal es dejar sin modelar al usuario que optimiza contra ti\.

**Teoría aplicada**

La decisión adversarial asume que alguien optimiza contra tus reglas, filtros o incentivos\.

**Fórmula / criterio**

Riesgo = capacidad del atacante \* incentivo \* superficie de acción \* falta de controles\.

**Ejemplo**

Prompt injection, fraude y spam mejoran justo cuando el sistema defensivo se vuelve predecible\.

**Decisión**

Incluye red teaming, límites, permisos y monitorización; no diseñes solo para usuarios ideales\.

**incentivo**qué gana el adversario

**capacidad**qué puede probar o automatizar

**superficie**inputs, tools, permisos y documentos

**adaptación**cómo cambia al observar defensas

**Prompt injection**

El atacante juega contra tus instrucciones incrustando órdenes en contenido aparentemente pasivo\.

input hostil

**Spam/fraude**

El adversario cambia estrategia al detectar defensas, umbrales o revisiones\.

adaptación

**Pricing**

Competidores y usuarios responden a incentivos, descuentos y fricción\.

mercado

**Seguridad agentic**

Diseñar permisos pensando en abuso, no solo en caso feliz\.

tools

ControlPregunta adversarialPermisos mínimos¿qué pasa si el modelo intenta una tool que no debería?Separar datos/instrucciones¿un documento recuperado puede dar órdenes al agente?Límites de presupuesto¿pueden forzar tool calls infinitas o caras?Trazas y detección¿verás el abuso antes de que cause daño?Red teaming continuo¿tu eval incluye ataques nuevos o solo los de lanzamiento?
## 67Puente hacia aprendizaje por refuerzo

Juegos, MCTS y RL comparten una pregunta: qué acción conviene ahora para mejorar retorno futuro\. La dificultad es que una acción buena a corto plazo puede destruir valor después\.

El puente con refuerzo está en valorar acciones por consecuencias futuras\. Esta mirada ayuda a entender desde juegos hasta RLHF: no se optimiza solo una respuesta, se optimiza comportamiento bajo una señal de recompensa\.

RL enseña a evaluar comportamiento, no respuestas aisladas\.

**Teoría aplicada**

El puente con RL está en valorar acciones por consecuencias futuras, no solo por recompensa inmediata\.

**Fórmula / criterio**

Retorno G\_t = r\_\{t\+1\}\+gamma\*r\_\{t\+2\}\+\.\.\.; política pi\(a\|s\) elige acciones\.

**Ejemplo**

Un agente de soporte puede evitar una acción rápida si empeora satisfacción o coste futuro\.

**Decisión**

Define bien recompensa, horizonte y efectos secundarios antes de optimizar comportamiento\.

**s**estado observado

**a**acción elegida

**r**recompensa inmediata

**G**retorno acumulado descontado

ConceptoJuegosRLEn sistemas LLMEstadoposición del tableroobservación del entornocontexto, memoria, permisos y datos recuperadosAcciónjugadadecisión del agenteresponder, llamar tool, pedir aclaración, escalarRecompensaganar/perder/puntosseñal escalaréxito de tarea, coste, satisfacción, seguridadPolíticaestrategia de juegofunción que elige accionesmodelo \+ routing \+ reglas de decisiónHorizonteturnos futurosretorno a largo plazoevitar resolver rápido causando deuda o riesgoCuidado con la recompensa

Si premias “cerrar tickets rápido”, el agente aprende a cerrar\. Si premias “resolver con evidencia y baja reapertura”, el comportamiento cambia\. La recompensa es diseño de producto, no detalle matemático\.

## 68Qué debe saber: juegos y simulación

Los juegos no son un capítulo anecdótico: enseñan búsqueda con adversario, simulación, evaluación de decisiones y diseño de incentivos\. Son una vacuna contra sistemas que solo funcionan cuando nadie reacciona\.

El bloque de juegos aporta intuiciones sobre decisión bajo oposición e incertidumbre\. No es necesario dominar teoría de juegos, pero sí reconocer cuándo una solución debe considerar reacción, simulación y coste futuro\.

Después de este bloque, debes pensar en respuesta, incentivo, presupuesto e incertidumbre\.

**Teoría aplicada**

Juegos y simulación enseñan a pensar en adversarios, incertidumbre, presupuesto de búsqueda y valor futuro\.

**Fórmula / criterio**

Minimax para rival racional; Monte Carlo/MCTS para estimación; eval\(s\) cuando no puedes mirar todo\.

**Ejemplo**

Seguridad, pricing, fraude y agentes con tools son productos donde otros actores reaccionan\.

**Decisión**

Pregunta siempre: quién puede reaccionar, qué incentivo tiene y cómo medirás daño o mejora\.

Debes poder explicarFórmula / criterioConexión modernaPregunta que debes hacerMinimax y poda alfa\-betamaximizar valor considerando respuesta del rivaldecidir bajo adversario racional¿qué haría alguien que quiere que falle?Función de evaluaciónscore de estados cuando no llegas al finalheurísticas de agentes, evals y ranking¿qué estás premiando realmente?Monte Carlo / MCTSsimular para estimar valor con presupuestoplanificación, búsqueda, exploración de herramientas¿cuánta incertidumbre aceptas?Simulación formal vs plausiblemuestra definida vs texto verosímilLLMs para hipótesis, no prueba final¿esto es evidencia o imaginación útil?Puente con RLretorno futuro y políticaoptimizar comportamiento de agentes¿la recompensa produce el comportamiento deseado?Qué debe quedar

Si un sistema puede ser explotado, competido o manipulado, evalúalo con mentalidad de juego: actores, información, incentivos, acciones posibles, coste y respuesta\.

## 69Conocimiento simbólico: hechos, reglas y significado

Antes de embeddings, mucha IA representaba conocimiento de forma explícita: entidades, relaciones, clases, reglas e inferencia\. Esa tradición sigue siendo clave cuando necesitas trazabilidad, permisos, cumplimiento o respuestas que dependan de relaciones exactas\.

El conocimiento simbólico intenta que el significado sea explícito y manipulable\. En lugar de confiar en parecido estadístico, declara entidades, relaciones y reglas que pueden consultarse, validarse y explicar conclusiones\.

Lo simbólico no intenta parecer inteligente: intenta hacer explícito qué sabes, cómo se relaciona y qué puedes inferir\.

**Teoría aplicada**

El conocimiento simbólico representa explícitamente entidades, relaciones, clases y reglas para consultar y razonar\.

**Fórmula / criterio**

Hechos \+ reglas \+ motor de inferencia \-\> conclusiones trazables\.

**Ejemplo**

cliente compra producto, producto requiere permiso, permiso caduca en fecha: todo queda consultable\.

**Decisión**

Haz explícito lo que necesites auditar, explicar o validar; no todo debe vivir como embedding\.

**Entidad**cosa identificable del dominio

**Relación**conexión tipada entre entidades

**Regla**condición que deriva o valida hechos

**Inferencia**hechos nuevos a partir de hechos y reglas

**Entidad**

Objeto del dominio: persona, enfermedad, producto, contrato\. Debe tener identidad estable\.

nodo

**Relación**

Conecta entidades: compra, pertenece\_a, contraindica\. La relación tiene significado, no solo cercanía\.

arista

**Clase**

Categoría de entidades con propiedades comunes: Cliente, Factura, DocumentoFiscal\.

tipo

**Regla**

Si se cumplen condiciones, deriva o bloquea una conclusión\.

inferencia

NecesidadVector storeConocimiento simbólicobuscar texto parecidomuy fuertesolo si hay documentos asociadosseguir relación exactadébil o indirectofuerte: entidad \-\> relación \-\> entidadvalidar una reglano garantizafuerte con reglas/ontologíaauditar por qué se respondiócitas ayudancadena de hechos y reglasConexión con RAG

RAG aporta evidencia textual al LLM; el conocimiento simbólico aporta estructura\. Cuando la pregunta depende de relaciones, permisos o reglas, un embedding por sí solo no es una fuente de verdad suficiente\.

## 70RDF: sujeto, predicado, objeto

RDF representa conocimiento como tripletas\. Es simple, pero permite construir grafos grandes y consultables porque todo se reduce a afirmaciones pequeñas con identidad: sujeto, predicado y objeto\.

RDF parece minimalista porque todo se reduce a sujeto, predicado y objeto\. Esa simplicidad es precisamente su fuerza: permite combinar muchas fuentes en un grafo común si se cuidan identificadores y vocabularios\.

Una tripleta RDF convierte una frase del dominio en una relación que una máquina puede consultar\.

**Teoría aplicada**

RDF reduce conocimiento a tripletas enlazables\. Su fuerza está en identidad estable y composición\.

**Fórmula / criterio**

<sujeto\> <predicado\> <objeto\>; muchas tripletas forman un grafo dirigido etiquetado\.

**Ejemplo**

paciente:123 tieneSintoma sintoma:Tos es una relación consultable, no texto parecido\.

**Decisión**

Cuida URIs y vocabulario: sin identidad estable, el grafo se llena de duplicados ambiguos\.

**Sujeto**recurso del que hablamos

**Predicado**relación o propiedad

**Objeto**otro recurso o valor literal

**URI**identidad estable y enlazable

SujetoPredicadoObjetoLecturapaciente:123tieneSintomasintoma:Tosel paciente 123 tiene tosenfermedad:AsmaseDetectaConprueba:Espirometriael asma se detecta con espirometríamedicamento:Broncodilatadoraliviasintoma:DificultadRespirarel broncodilatador alivia dificultad al respirarfactura:f9perteneceAcliente:c42la factura f9 pertenece al cliente c42servicio:apidependeDeservicio:dbla API depende de la base de datosError de modeladoConsecuenciausar nombres libres en vez de URIsduplicados: “ACME”, “Acme SL”, “acme” parecen entidades distintaspredicados vagos como relacionadoConconsultas poco útiles y relaciones sin semánticamezclar literal y entidad sin criteriono puedes navegar ni enlazar correctamente
## 71RDFS y OWL: vocabulario y restricciones

RDFS añade clases y propiedades básicas; OWL permite expresar restricciones y axiomas más ricos\. La diferencia con un grafo plano es que ahora el sistema puede inferir y validar parte del significado\.

RDFS y OWL añaden semántica al grafo\. No solo dicen que dos nodos están conectados; permiten declarar clases, jerarquías y restricciones para que un reasoner derive consecuencias que no estaban escritas literalmente\.

RDF dice hechos; RDFS/OWL dicen qué significan esos hechos y qué consecuencias tienen\.

**Teoría aplicada**

RDFS y OWL añaden significado formal: clases, subclases, dominios, rangos, equivalencias y restricciones\.

**Fórmula / criterio**

Si A subClassOf B y x type A, un reasoner puede inferir x type B\.

**Ejemplo**

Si Factura es DocumentoFiscal, las reglas sobre documentos fiscales aplican también a facturas\.

**Decisión**

Añade semántica cuando la inferencia y validación valgan el coste de modelado\.

**class**tipo de cosa: Persona, Factura, Servicio

**subClassOf**jerarquía de clases

**domain/range**qué sujetos y objetos acepta una propiedad

**reasoner**deriva hechos implícitos

CapaQué añadeEjemploPara qué sirveRDFTripletasA seRelacionaCon Brepresentar hechos básicosRDFSClases, subclases, dominio, rangoFactura subClassOf DocumentoFiscalorganizar vocabulario e inferir tiposOWLRestricciones lógicas más expresivasdisjointWith, equivalentClass, cardinalidadmodelar reglas de dominio más fuertesReasonerDeriva hechos implícitossi Factura es DocumentoFiscal, f9 es DocumentoFiscalconsultar consecuencias no escritas literalmenteAxiomaQué evitaCliente disjointWith Proveedorque una entidad mal cargada sea dos clases incompatiblestieneFactura domain Clienteusar la propiedad con sujetos que no son clientesperteneceA range Organizaciónrelacionar facturas con objetos que no son organizacionescardinalidad máxima 1 para NIFmúltiples identificadores fiscales incompatiblesCuidado

Más OWL no siempre es mejor\. Cada axioma añade coste de modelado y mantenimiento\. Úsalo donde la inferencia o validación reduzca errores reales\.

## 72SPARQL: consultar conocimiento estructurado

SPARQL permite preguntar al grafo con patrones de tripletas, no con similitud aproximada\. Si la pregunta depende de una relación exacta, SPARQL da una respuesta trazable: cumple el patrón o no lo cumple\.

SPARQL no intenta adivinar intención por similitud, sino encontrar patrones estructurados\. Es potente cuando la pregunta depende de relaciones exactas y quieres una respuesta trazable, no solo fragmentos relevantes\.

SPARQL no adivina intención: busca patrones formales en un grafo\.

**Teoría aplicada**

SPARQL consulta patrones exactos en el grafo; no ordena por parecido semántico\.

**Fórmula / criterio**

SELECT ?x WHERE \{ ?x :relacion ?y \. FILTER\(\.\.\.\) \}

**Ejemplo**

“Medicamentos que alivian síntoma X” se expresa como relación, no como búsqueda difusa\.

**Decisión**

Usa SPARQL cuando necesites respuestas trazables sobre relaciones explícitas\.

**SELECT**variables que quieres devolver

**WHERE**patrones que deben cumplirse

**?x**variable que captura recursos

**FILTER**condición exacta adicional

PreguntaPatrón SPARQL que necesitas¿Qué medicamentos alivian síntomas??medicamento :alivia ?sintoma¿Qué facturas pertenecen a cliente c42??factura :perteneceA cliente:c42¿Qué servicios dependen de db??servicio :dependeDe servicio:db¿Qué contratos vencen antes de fecha??contrato :vence ?fecha \+ FILTER\(?fecha < límite\)```
SELECT ?medicamento ?sintoma WHERE {
  ?medicamento :alivia ?sintoma .
  ?sintoma rdf:type :Sintoma .
}

Diferencia clave

SPARQL no busca “lo parecido”; devuelve lo que cumple el patrón formal de la consulta. Si falta una relación en el grafo, no la inventa para sonar útil.

73Ontología: modelo compartido del dominio

Una ontología define conceptos, relaciones y restricciones de un dominio para que personas y máquinas compartan vocabulario. Es especialmente útil cuando distintos equipos usan las mismas palabras con significados diferentes.

Una ontología es un contrato conceptual del dominio. Reduce ambigüedad entre equipos, permite validaciones y facilita que los sistemas distingan entre términos parecidos que en negocio significan cosas distintas.

Una ontología es un contrato semántico: reduce ambigüedad antes de que se convierta en bug.

Teoría aplicada

Una ontología es un contrato conceptual del dominio: qué cosas existen, cómo se nombran y qué relaciones son válidas.

Fórmula / criterio

Ontología = clases + propiedades + restricciones + axiomas + ejemplos de individuos.

Ejemplo

“Usuario”, “cliente” y “cuenta” pueden ser entidades distintas aunque en conversación se mezclen.

Decisión

Construye ontología cuando la ambigüedad cause errores de negocio, integración o cumplimiento.

Vocabulario

Nombres consistentes para conceptos importantes: Cliente, Cuenta, Usuario, Contrato.

lenguaje común

Relaciones

Cómo se conectan entidades y clases: perteneceA, autoriza, contraindica, dependeDe.

estructura

Restricciones

Qué combinaciones tienen sentido y cuáles deberían rechazarse.

validación

Consultas

Permite responder preguntas trazables y explicar de dónde salen.

auditoría

Sin ontologíaCon ontología“cliente” significa pagador para ventas y usuario para soporteclases separadas: Account, BillingCustomer, EndUserrelaciones vagas como “asociado a”propiedades tipadas: paga, usa, administra, perteneceAcada sistema valida distintorestricciones compartidas y comprobablesRAG recupera textos pero no sabe relaciones exactasRAG puede apoyarse en entidades y relaciones verificablesCuándo merece la pena

No hagas una ontología por estética. Hazla cuando la ambigüedad esté causando errores: integraciones frágiles, permisos confusos, reporting inconsistente o respuestas RAG que mezclan entidades.

74Linked Data: datos enlazados

Linked Data usa URIs y estándares web para que datos de distintas fuentes se puedan enlazar y reutilizar. La idea importante no es “publicar datos”, sino poder referirse a la misma entidad de forma estable entre sistemas.

Linked Data lleva esa idea a la web: recursos identificables, enlazables y reutilizables. Su valor aparece cuando distintas fuentes pueden hablar de la misma entidad sin depender de copias sueltas o nombres ambiguos.

Sin identidad estable no hay conocimiento conectado: hay copias sueltas con nombres parecidos.

Teoría aplicada

Linked Data busca que datos de distintas fuentes se enlacen mediante identificadores web y estándares comunes.

Fórmula / criterio

URI estable + HTTP + RDF + enlaces externos = grafo interoperable.

Ejemplo

Un proveedor puede enlazarse con contratos internos, catálogos y registros públicos.

Decisión

Invierte en identificadores estables antes de intentar integrar conocimiento entre sistemas.

URI estable→HTTP→RDF→Enlaces a otros recursos→Grafo global

URIidentificador global de recurso

HTTPforma estándar de resolverlo

RDFmodelo común de tripletas

linksconexión entre datasets

PrincipioLectura prácticausa URIs para nombrar cosasno dependas de strings ambiguos como “ACME”usa HTTP para que puedan resolverseun identificador debe llevar a información útildevuelve datos estructuradosmáquinas y personas pueden reutilizar la entidadenlaza con otros recursosconecta catálogos, registros, contratos y documentaciónConexión moderna

Para GraphRAG, catálogos internos o lineage de datos, Linked Data enseña una lección durísima: si no identificas bien entidades, todo el pipeline posterior mezcla cosas.

75Sistemas expertos

Un sistema experto intenta resolver problemas de un dominio con una base de conocimiento y un motor de inferencia. Su límite histórico fue capturar y mantener reglas; su lección moderna es que las reglas siguen siendo útiles cuando necesitas explicación y control.

Los sistemas expertos recuerdan que antes de los LLMs ya existía IA explicable basada en reglas. Su límite era capturar y mantener conocimiento; su lección moderna es que las reglas siguen siendo valiosas cuando necesitas trazabilidad.

Antes de los LLMs ya existían sistemas que razonaban con reglas; ahora podemos combinar reglas con lenguaje natural y retrieval.

Teoría aplicada

Los sistemas expertos separan conocimiento del motor que lo aplica, y producen explicaciones basadas en reglas.

Fórmula / criterio

IF condiciones THEN conclusión; el motor encadena reglas sobre hechos.

Ejemplo

Si fiebre alta y marcador X, recomendar prueba Y bajo una regla revisada por experto.

Decisión

Usa reglas cuando necesites trazabilidad, consistencia y responsabilidad de dominio.

hechosdatos conocidos del caso

reglasconocimiento experto codificado

motoraplica reglas e infiere

explicacióncadena de reglas usada

ComponenteFunciónEquivalente moderno aproximadoRiesgoBase de conocimientohechos y reglas del dominiodocs, KG, rules, policiesse queda obsoleta si nadie la mantieneMotor de inferenciaaplica reglas y deriva conclusionesLLM + reglas + retrievalaplica reglas malas de forma muy consistenteExplicaciónjustifica qué regla llevó a una conclusióntrazas, citas, tool logsexplicación incompleta si faltan datosExperto humanocodifica y valida conocimientodomain owner + reviewercuello de botella y sesgo del expertoPatrón clásicoPatrón modernoIF síntomas THEN diagnóstico probableLLM resume caso + reglas validan red flags + humano decideIF producto incompatible THEN bloquear configuraciónLLM explica alternativas + validador impide compra inválidaIF política incumplida THEN escalarRAG cita política + regla decide si puede ejecutar tool

76Simbólico vs neuronal

No es una guerra. Son herramientas distintas: una aporta estructura explícita; la otra, generalización estadística. Los sistemas útiles suelen combinar ambas porque el lenguaje real es ambiguo y las reglas de negocio no deberían serlo.

La comparación no busca declarar un ganador. Los sistemas fiables suelen combinar lo neuronal para interpretar y generar, y lo simbólico para restringir, consultar, auditar y explicar.

Neuronal para entender y generar; simbólico para consultar, validar, auditar y restringir.

Teoría aplicada

Lo simbólico aporta estructura y garantías; lo neuronal aporta flexibilidad y generalización estadística.

Fórmula / criterio

Sistema robusto = LLM para interpretar/generar + simbólico para validar/consultar/auditar.

Ejemplo

Un asistente legal puede resumir lenguaje natural, pero reglas y citas limitan lo que puede afirmar.

Decisión

Pon cada garantía en la capa adecuada: no pidas trazabilidad formal a un embedding.

DimensiónSimbólicoNeuronal / LLMDiseño híbridoRepresentaciónhechos, reglas, ontologíasvectores, pesos, embeddingsextraer entidades y validarlas contra un KGFortalezaprecisión, trazabilidad, restriccionesflexibilidad, lenguaje natural, patrones difusosLLM interpreta; reglas aceptan o rechazanDebilidadcoste de modelado y mantenimientoalucinación y falta de garantíasautomatizar solo lo verificableEvaluaciónconsistencia lógica y cobertura de reglascalidad, groundedness, robustezevals que midan ambas capasRegla práctica

Si el usuario pregunta algo ambiguo, usa modelos neuronales. Si la respuesta compromete permisos, dinero, cumplimiento o relación exacta, añade capa simbólica o validador.

77Knowledge graph vs vector store

Un vector store recupera fragmentos parecidos. Un knowledge graph representa entidades y relaciones consultables. Confundirlos lleva a vender “memoria semántica” como si fuera conocimiento formal.

Un vector store responde por proximidad; un knowledge graph responde por relación. Entender esa diferencia evita vender RAG como si fuera una base de conocimiento formal y evita usar grafos cuando basta recuperar texto.

Vector store responde por parecido; knowledge graph responde por relación.

Teoría aplicada

Un vector store recupera por proximidad; un knowledge graph recupera por identidad y relación.

Fórmula / criterio

Vector: top-k por similitud. KG: caminos y patrones sobre nodos/aristas tipadas.

Ejemplo

“Docs parecidos a esta incidencia” es vectorial; “servicios que dependen de X” es grafo.

Decisión

Elige vector, grafo o híbrido según si necesitas parecido, relación exacta o ambas cosas.

Vector store

Embeddings + búsqueda por similitud. Muy útil para texto no estructurado, paráfrasis y preguntas abiertas.

aproximado

Knowledge graph

Entidades + relaciones + propiedades. Muy útil para consultas relacionales, trazabilidad, permisos e inferencia.

estructurado

PreguntaVector storeKnowledge graph“Busca documentos parecidos a este caso”fuertedébil si no hay texto asociado“Qué servicios dependen de esta base de datos”puede recuperar docs, no garantiza relaciónfuerte con camino de dependencia“Resume evidencia de política”fuerte con chunks y citasútil para filtrar entidades y reglas“Puede este usuario hacer esta acción”no debería decidir solofuerte con relaciones de permiso + reglas“Por qué respondiste eso”cita fragmentosmuestra camino de entidades y relacionesPuente hacia GraphRAG

GraphRAG intenta usar estructura para mejorar retrieval, pero no convierte automáticamente documentos en una ontología fiable. La extracción de entidades y relaciones también necesita evaluación.

78Qué debe saber: conocimiento simbólico

RAG moderno se entiende mejor cuando sabes qué intentaba resolver la web semántica: significado explícito, relaciones e inferencia. No para sustituir embeddings, sino para saber cuándo un embedding se queda corto.

Este bloque prepara el terreno para GraphRAG y RAG híbrido. Si entiendes tripletas, ontologías y consultas exactas, puedes decidir cuándo un embedding se queda corto y cuándo merece modelar relaciones.

Debes distinguir texto parecido, relación exacta, regla verificable y explicación trazable.

Teoría aplicada

El bloque simbólico enseña cuándo necesitas significado explícito además de recuperación semántica.

Fórmula / criterio

RDF para hechos; RDFS/OWL para semántica; SPARQL para consulta; reglas para inferencia.

Ejemplo

GraphRAG mejora cuando entidades y relaciones se modelan y evalúan, no solo se extraen una vez.

Decisión

Cuando una respuesta deba explicar relación, fuente y regla, combina RAG con estructura.

Debes poder explicarFórmula mentalConexión modernaError frecuenteRDF como tripletassujeto-predicado-objetografos de conocimiento y GraphRAGusar strings ambiguos sin identidadOWL/RDFS como vocabulario y restriccionesclases, propiedades, axiomasvalidación de dominio y razonamientosobremodelar sin caso de usoSPARQL como consulta exactapatrones de tripletaspreguntas estructuradas frente a similitud vectorialusar embeddings para permisos exactosSistema expertohechos + reglas + inferenciaLLM + reglas + RAG + trazasmeter reglas duras solo en promptKG vs vector storerelación vs proximidadRAG híbrido y auditoríallamar conocimiento a cualquier índice vectorialChecklist

Antes de elegir arquitectura pregunta: ¿necesito parecido textual, relación exacta, inferencia, validación o explicación? La respuesta decide si basta RAG vectorial o necesitas KG/ontología/reglas.

79Lo que deberías saber: IA clásica aplicada

La IA clásica no compite con los LLMs: te da vocabulario para construir sistemas menos mágicos y más verificables. Si entiendes estado, coste, restricción, plan, adversario y regla, puedes diseñar mejores agentes, RAG y workflows.

La IA clásica aporta lenguaje de ingeniería: estado, coste, restricción, plan, adversario, regla e inferencia. Ese lenguaje hace que los sistemas con LLM sean menos místicos y más diseñables.

Los LLMs amplían lo que podemos automatizar; la IA clásica ayuda a que esa automatización tenga estructura, límites y evidencia.

Teoría aplicada

La IA clásica aporta el vocabulario de sistemas fiables: estado, coste, restricción, plan, adversario y regla.

Fórmula / criterio

LLM útil en producción = generación + recuperación + validación + evaluación + trazas.

Ejemplo

Un agente serio usa búsqueda para explorar, constraints para validar, planning para actuar y KG/RAG para evidenciar.

Decisión

Usa estos conceptos como checklist de arquitectura antes de vender autonomía.

BloqueIdea mínimaConexión con 2026Pregunta que debes llevarteBúsquedaestado, acción, coste, heurísticaplanning, routing y exploración de agentes¿qué espacio estoy explorando y qué coste tiene?SAT/CSPrestricciones duras y asignación válidaschemas, permisos, scheduling, guardrails¿qué regla nunca debe romperse?Planificaciónprecondiciones, efectos y secuencia de accionestools, workflows, HITL¿qué hace legal cada acción y qué cambia después?Juegosdecisión adversarial y simulaciónseguridad, red teaming, MCTS, RL¿quién reacciona y qué incentivo tiene?Conocimiento simbólicografos, reglas e inferenciaGraphRAG, KG, trazabilidad¿necesito parecido textual o relación verificable?Arquitectura modernaQué hereda de IA clásicaAgente con toolsplanning, precondiciones, efectos, estado y guardrailsRAG empresarialretrieval, conocimiento simbólico, citas y evaluaciónGraphRAGentidades, relaciones, comunidades, inferencia y mantenimientoEvals de IAmétricas, coste de error, adversarialidad y generalizaciónAutomatización seguraconstraints, permisos, auditoría y recuperaciónCierre del bloque

La pregunta madura no es “¿LLM o IA clásica?”. Es: ¿qué parte requiere lenguaje, qué parte requiere búsqueda, qué parte requiere reglas y qué parte requiere evidencia?

80

Arquitecturas y modelos

Transformers, Mixture of Experts, LLMs y los parámetros que controlan su comportamiento.

81¿Qué es un modelo LLM?

Large Language Model: un modelo de lenguaje a gran escala. Entrenado con cantidades masivas de texto (internet, libros, código...) para predecir el siguiente token dada una secuencia.

Generación de texto

Redacción, resumen, traducción, reformulación de contenido

Razonamiento

Lógica, matemáticas, análisis, resolución de problemas complejos

Código

Generación, depuración, refactorización en múltiples lenguajes

Multilingüe

Comprensión y generación en decenas de idiomas simultáneamente

Modelos principales (mayo 2026)

ModeloEmpresaDimensiones públicasContext windowTipoGPT-5.5OpenAINo publica pesos ni arquitectura1.05MPropietarioClaude Opus 4.7AnthropicNo publica pesos ni arquitectura1MPropietarioClaude Sonnet 4.6AnthropicNo publica pesos ni arquitectura1MPropietarioGemini 3.1 Pro PreviewGoogleNo publica pesos; multimodal nativo1MPropietariogpt-oss-120bOpenAIMoE: 117B total, 5.1B activos; reasoning open-weight131kApache 2.0Llama 4 ScoutMetaMoE: 109B total, 17B activos, 16 expertos10MOpen weightsLlama 4 MaverickMetaMoE: 400B total, 17B activos, 128 expertos1MOpen weightsQwen3.6-35B-A3BAlibabaMoE multimodal: 35B total, 3B activos, 40 capas, 256 expertos262k nativo / 1.01M YaRNApache 2.0DeepSeek-V4-ProDeepSeekMoE: 1.6T total, 49B activos, FP4+FP8 mixed1MMITDeepSeek-V4-FlashDeepSeekMoE: 284B total, 13B activos, FP4+FP8 mixed1MMITMistral Large 3 / Medium 3.5Mistral AILarge 3 MoE: 675B total, 41B activos; Medium 3.5 multimodal agentic/codingLarge 3 según runtime / Medium 3.5 256kApache 2.0 / Modified MIT### Dimensiones de un modelo: qué significan

DimensiónQué midePor qué importaParámetros totalesTodos los pesos guardadosMemoria necesaria para cargar el modeloParámetros activosPesos usados por token en MoECoste de cómputo por inferenciaCapasProfundidad del TransformerMás pasos de abstracción, más latencia secuencialHidden size / d_modelAnchura del vector internoCapacidad representacional y tamaño de matricesAttention heads / KV headsParalelismo de atenciónCalidad de atención y tamaño de KV cacheContext windowTokens máximos de entradaNo garantiza buena recuperación en todo el contextoIdea clave

En modelos densos, “parámetros” aproxima memoria y coste. En MoE hay que separartotal(lo que cargas) deactivo(lo que calculas por token). Por eso un 400B MoE puede costar por token mucho menos que un 400B denso.

Snapshot mayo 2026

Modelos, context window, precios y disponibilidad cambian rápido. En Google, el preview textual actual es Gemini 3.1 Pro Preview; Gemini 3 Pro Preview quedó discontinuado el 26 de marzo de 2026. Antes de producción, verifica documentación oficial, model card y pricing del proveedor.

82Arquitecturas

Evolución de las arquitecturas

La historia no acaba en Transformer. En 2026 la base dominante sigue siendo la familia Transformer, pero los modelos punteros combinan bloques: decoder-only, MoE, atención eficiente, memoria larga, SSM (State Space Model) / Mamba e incluso procesamiento por bytes o latentes.

Perceptron (1958)→RNN (1986)→LSTM (1997)→Transformer (2017)→Decoder-only + MoE→SSM / híbridos

Qué problema intenta resolver cada familia

FamiliaCómo procesaVentajaLimitaciónRNN / LSTMToken a token, con estado recurrenteMemoria compacta y coste linealDifícil de paralelizar y peor escalado en lenguajeTransformerTodos los tokens atienden a todosEntrenamiento paralelo y gran calidadAtención O(n²) y KV cache grande en contexto largoDecoder-only TransformerPredice el siguiente token de izquierda a derechaBase práctica de chat, código y agentesNecesita ingeniería para memoria, herramientas y contexto largoMoE TransformerUn router activa pocos expertos por tokenMás capacidad total sin activar todo el modeloMás complejo de entrenar, servir y compararSSM / MambaSSM = State Space Model; estado selectivo con coste lineal en secuenciaPromete mejor throughput y menos memoria en contexto largoAún no desplaza al Transformer en modelos frontier generalistasHíbridosIntercalan atención, Mamba/SSM y a veces MoEBuscan calidad de Transformer + eficiencia de SSMMás moving parts; la receta óptima sigue abierta### Mapa actualizado de arquitecturas

AñoArquitecturaIdea claveEstado en 2026Fuente2017TransformerAtención como bloque centralBase conceptual de casi todoAttention Is All You Need2018-26Decoder-onlyModelo autoregresivo: predice siguiente tokenPatrón dominante en LLMs de texto/códigoGPT-12021-26MoE / sparse expertsMuchos parámetros almacenados, pocos activos por tokenMuy usado en open weights y modelos eficientesSwitch Transformers2023RWKV / RetNetEntrenar en paralelo, inferir como recurrenteAlternativas eficientes; menos mainstream que TransformerRWKV/RetNet2023HyenaConvoluciones largas + gating como sustituto subcuadráticoImportante en investigación de contexto largoHyena2023-24Mamba / Mamba-2State Space Models selectivos; coste linealMuy relevante para long context y eficienciaMamba/Mamba-22024-26Híbridos Transformer-SSMMezclan atención, Mamba y MoEProducción real en familias como JambaJamba2024-26Byte / latent / multimodalMenos dependencia del tokenizador; BLT = Byte Latent Transformer; texto+imagen+audio/videoFrontera activa, no un estándar únicoBLT/GPT-4 reportLectura correcta en 2026

No digas “todo es Transformer” ni “Transformer ha muerto”. Lo correcto es:la familia Transformer sigue dominando, pero la innovación se está moviendo hacia bloques híbridos que reducen coste de contexto, KV cache y memoria, especialmente para agentes y documentos largos.

83¿Cómo funciona un Transformer?

Analogía

Imagina que estás leyendo una frase y tienes que adivinar el siguiente token. El Transformer puede procesar muchos tokens de la ventana en paralelo durante el cálculo interno, a diferencia de las RNN clásicas.

Atención = subrayar lo importante

“El gato se subió al árbol porqueteníamiedo” → “tenía” mira a “gato” para saber QUIEN tenía miedo. Es como subrayar las palabras importantes para entender cada parte de la frase.

Paso a paso simplificado

1. El texto se trocea entokens(palabras o trozos de palabras)
2. Cada token se convierte en unvector(embedding) con su significado y posición
3. El mecanismo deatencióncompara cada token con todos los demás: “¿quién es relevante para quién?”
4. Esta información se mezcla y se pasa porredes neuronales
5. Al final, el modelo predice: “el siguiente token más probable es...”

Flujo del mecanismo de atención

Token actual (“tenía”)→Query: “¿quién es relevante?”→Key: cada token ofrece su “etiqueta”→Puntuación: similitud Q*K→Value: información ponderada→Salida enriquecida

Analogía de la reunión

Imagina una reunión donde cada persona (token) tiene una pregunta (Query), una tarjeta de presentación (Key) y una respuesta útil (Value). Cada persona mira las tarjetas permitidas, decide a quién prestar atención y combina las respuestas de los más relevantes. Esa es la intuición de Self-Attention.

¿Por qué fue revolucionario?

Como el cálculo de atención se paraleliza muy bien, se puede distribuir en miles de GPUs. Esto permitió entrenar con MUCHOS más datos que antes. Más datos + más parámetros, con buen entrenamiento, suelen producir modelos más capaces.

84Arquitectura MoE (Mixture of Experts)

En vez de un modelo denso donde todos los parámetros participan en cada paso, MoE divide parte del modelo en múltiplesexpertosseleccionados por un router.

Flujo de una petición MoE

Token de entrada→Router (gate)→Experto 3 + Experto 7→Combinar salidas→Resultado

Cómo funciona el routing

• Unrouter(red neuronal pequeña) decide qué expertos activa para cada token
• Cada experto suele ser una red feed-forward; durante el entrenamiento puede especializarse en ciertos patrones
• Solo se activa unafracciónde los parámetros por inferencia (ej: 2 de 8 expertos)
• El router asigna pesos a los expertos activos; la salida final es la suma ponderada
• Se aplicaload balancingdurante el entrenamiento para que todos los expertos se utilicen de forma equilibrada

Modelo denso frente a MoE

Modelo denso

En un modelo denso, todos los parámetros relevantes de las capas participan en cada token. 70B parámetros implica un coste activo mucho mayor que un modelo sparse equivalente.

70B params70B activos100% uso

Modelo MoE

Solo una fracción se activa por token. El modelo tiene muchos parámetros almacenados, pero el router elige pocos expertos en cada capa. Más capacidad total, menor coste por token.

Total altoActivos bajosSparse

Ejemplos reales

ModeloTotalActivo/tokenRoutingContextoMixtral 8x7B~47B~13BTop-2 de 8 expertos32kMistral Large 3675B41BMoE granular, Apache 2.0Según runtimegpt-oss-120b117B5.1BMoE reasoning open-weight131kDeepSeek-V4-Pro1.6T49BMoE frontier, FP4+FP8 mixed1MDeepSeek-V4-Flash284B13BMoE eficiente, misma familia V41MQwen3.6-35B-A3B35B3B8 routed + 1 shared de 256 expertos262k / 1.01MLlama 4 Maverick400B17B128 expertos1MCuidado con las comparaciones

Un MoE no es “mejor” por tener más parámetros totales. Importan el routing, la calidad de datos, el post-training, el número de expertos activos, la KV cache y el hardware. Además, los modelos propietarios no siempre publican arquitectura: no conviene atribuirles MoE si no hay fuente pública.

85El mecanismo de atención en detalle

La atención permite que cada token “mire” a todos los demás para decidir cuáles son relevantes. Aquí están las matemáticas detrás, simplificadas.

Las matrices Q, K, V

Q = token × W_query K = token × W_key V = token × W_value

score = (Q × K^T) / sqrt(d_k) weights = softmax(score) output = weights × V

Multi-head attention

En vez de una sola atención, el modelo ejecuta**múltiples “cabezas”**en paralelo (32-128 en modelos grandes). Cada cabeza aprende a fijarse en algo diferente: una en sintaxis, otra en semántica, otra en correferencia. Los resultados se concatenan.

Positional encoding

La atención por sí sola no codifica orden; compara tokens como un conjunto. Por eso se añade información de posición a cada token:

TipoCómo funcionaQuién lo usaSinusoidalFunciones seno/coseno de distinta frecuenciaTransformer original (2017)AprendidoEmbeddings de posición entrenadosGPT, BERTRoPERotary Position Embedding. Codifica posiciones relativasLlama, Qwen, la mayoría de LLMs modernos¿Por qué escalar por sqrt(d_k)?

Sin escalar, los dot products crecen con la dimensión y los softmax se saturan (todos los pesos van a un solo token). Dividir porsqrt\(d\_k\)mantiene la varianza estable. Es un truco numérico simple pero crítico.

86Tokenización en profundidad

El tokenizador convierte texto en números antes de que el modelo lo vea.Cómo se tokenizaafecta directamente al rendimiento, al coste y al soporte multilingüe.

Algoritmos principales

AlgoritmoCómo funcionaQuién lo usaBPEByte Pair Encoding. Empieza con unidades pequeñas y fusiona pares frecuentes iterativamente. “low” + “er” = “lower“GPT, Llama y muchos LLMs modernosWordPieceSimilar a BPE pero maximiza la probabilidad del corpus en cada fusiónBERT, DistilBERTSentencePieceTrata el texto como una secuencia continua y no presupone que el espacio sea un separador especial. Útil para idiomas sin espacios clarosT5, Llama, modelos multilingües### Impacto en idiomas

“Hello world”→ [“Hello”,“ world“] “Hola mundo”→ [“H”,“ola”,“ mundo“] “こんにちは世界”→ [“こん”,“にち”,“は”,“世界”]

Implicaciones prácticas

• **Coste:**más tokens = más caro. El español puede gastar más tokens que el inglés para el mismo contenido, según tokenizador y texto
• **Calidad/eficiencia:**mucha fragmentación puede hacer menos eficiente representar palabras raras, nombres propios o términos técnicos
• **Context window:**el límite es en tokens, no en palabras. Un documento en español consume más context que el mismo en inglés

Para gente curiosa

Puedes contar tokens antes de enviar a la API contiktoken(OpenAI) o las librerías de Anthropic. Si tu prompt es largo, tokeniza primero para estimar coste y verificar que cabe en el context window.

87Transfer learning: el paradigma que lo cambió todo

Antes de transfer learning, cada tarea requería entrenar un modelo desde cero. Hoy, sepre-entrena una vezcon datos masivos y seadaptaa cualquier tarea con poco esfuerzo.

Flujo de transfer learning

Pre-training (billones de tokens, semanas)→Modelo base (conocimiento general)→Fine-tuning / Prompt (tu tarea específica)→Modelo especializado (listo para usar)

Evolución del paradigma

EraEnfoqueEjemploPre-2018Entrenar desde cero para cada tareaUn modelo para sentiment, otro para NER, otro para traducción2018-2022Pre-train + fine-tuneBERT pre-entrenado → fine-tune para tu tarea. Semanas → horas2022-2026Pre-train + prompt (zero/few-shot)GPT/Claude ya saben hacer casi todo. Solo necesitas un buen prompt### Hitos del transfer learning

• **ImageNet (2012):**AlexNet demostró que features aprendidas en ImageNet se transfieren a cualquier tarea de visión. Empezó la revolución
• **Word2Vec (2013):**embeddings pre-entrenados reutilizables para cualquier tarea de NLP
• **BERT (2018):**pre-training bidireccional masivo. Fine-tune con 1000 ejemplos superaba modelos entrenados con millones
• **GPT-3 (2020):**demostró que con suficiente escala, el fine-tuning ni siquiera es necesario: basta con describir la tarea en el prompt

Por qué importa para ti

Transfer learning es la razón por la que puedes usar Claude o GPT paracualquier tareasin entrenar nada. El modelo ya “sabe” programar, traducir, analizar... porque lo aprendió durante el pre-training. Tu trabajo es darle el contexto adecuado, no entrenarlo.

88¿Cómo funciona MoE?

Analogía

Imagina unhospital con médicos especialistas. Cuando llegas con dolor de muelas, no te atienden todos los médicos: te mandan al dentista y quizá a radiología. El recepcionista es elrouter: decide qué especialistas trabajan para cada caso.

MoE aumenta capacidad total sin activar todo el modelo en cada token: muchos parámetros existen, pocos calculan.

Parámetros totalestodos los expertos cargados en memoria

Parámetros activosexpertos usados por token

Top-k routingnormalmente 1 o 2 expertos

Load balancingevita que todos usen el mismo experto

Paso a paso

PasoQué ocurrePor qué importaTokenEntra una representaciónxen una capa MoE.La decisión se toma por token, no necesariamente por frase completa.RouterUna red pequeña calcula puntuaciones para cada experto:g\(x\).El router aprende qué experto conviene para cada tipo de patrón.Top-kSe activan solo los mejores expertos, por ejemplo experto 3 y 7.Baja FLOPs por token frente a activar todo el modelo.CombinaciónLa salida mezcla expertos ponderados:y = Σ wᵢ · Eᵢ\(x\).No es votar texto; es combinar activaciones internas.BalanceoDurante entrenamiento se penaliza saturar pocos expertos.Sin balanceo, el modelo colapsa en expertos populares y desaprovecha capacidad.### Lo que debes comparar en fichas de modelos

ConceptoLectura correctaConsecuencia prácticaTotal vs activoUn MoE puede tener 1T total y activar decenas de B por token.Más memoria para cargarlo; menos cómputo que un denso equivalente.VRAM/RAMLos expertos no activos también ocupan memoria si están cargados.“Activos” no significa que quepa como un modelo denso de ese tamaño.ThroughputMoE puede ser rápido si routing y comunicación están optimizados.En hardware pobre, mover expertos puede comerse el ahorro.EspecializaciónExpertos aprenden patrones distintos, no profesiones humanas limpias.No asumas “experto de Python” o “experto de español” salvo evidencia.Inferencia localQuantización y runtime importan mucho.Ollama/LM Studio suelen necesitar variantes cuantizadas y soporte específico.Skin in the game

MoE es brillante cuando quieres mucha capacidad con coste activo menor. La trampa:no abarata mágicamente todo. Necesitas memoria para expertos, routing estable, balanceo, buen runtime y hardware con comunicación rápida. Si comparas modelos, mira siempreparámetros totales, activos, contexto, precisión, runtime y coste por token.

89Parámetros de configuración de un modelo

Parámetros principales

ParámetroRangoQué controla**temperature0.0 - 2.0Aleatoriedad de la salida. 0 = casi determinista, 0.7 = equilibrio, 1.5+ = creativotop\_p0.0 - 1.0Nucleus sampling. Solo considera tokens cuya probabilidad acumulada sume hasta ptop\_k1 - NSolo considera los k tokens más probablesmax\_tokens1 - límiteLímite de tokens en la respuesta (no confundir con context window)stopstringsSecuencias que cortan la generaciónsystemtextoInstrucciones que definen el comportamiento base del modelofrequency\_penalty**-2.0 - 2.0Penaliza la repetición de tokens### Ejemplo práctico: llamada a la API

importAnthropicfrom“@anthropic-ai/sdk“;

constclient =newAnthropic(); constresponse =awaitclient.messages.create({ model:“claude-sonnet-4-6”, max_tokens:1024, temperature:0.3, system:“Eres un experto en Python.”, messages: [{ role:“user”, content:“Explica list comprehensions” }] });

¿Cuándo usar qué?

**temperature 0-0.3:**código, datos, respuestas factuales.**temperature 0.5-0.7:**redacción equilibrada.**temperature 0.8+:**escritura creativa, brainstorming. Regla general: ajustatemperatureOtop\_p, no ambos a la vez.

Analogía

temperaturees “cuanto riesgo toma al elegir el siguiente token”. Un valor bajo es conservador (elige lo seguro), un valor alto es atrevido (puede sorprender o desvariar).

¿Qué hace top_p (nucleus sampling)?

Imagina que el modelo ha calculado las probabilidades de los siguientes tokens posibles:

TokenProbabilidadProb. acumulada¿Entra con top_p=0.9?**“hola”0.400.40Sí“buenos”0.300.70Sí“saludos”0.150.85Sí“hey”0.080.93Sí (supera 0.9 aquí)“estimado”0.040.97No (ya se pasó de 0.9)“querido”**0.031.00NoContop\_p=0\.9se toma el conjunto mínimo de tokens más probables cuya probabilidad acumulada cubre aproximadamente el 90%, y se muestrea dentro de ese núcleo. Cuanto menor el valor, más conservador.

¿Qué hace top_k?

Más simple: solo mira losk tokens más probables, independientemente de cuánta probabilidad acumulen.

• top\_k=1: siempre elige el token más probable (greedy, casi determinista)
• top\_k=10: elige entre los 10 más probables
• top\_k=50: bastante diverso, 50 candidatos
• top\_k=0o sin límite: considera todos los tokens del vocabulario

Diferencia clave entre top_p y top_k

top\_ksiempre mira un número fijo de candidatos.top\_pes adaptativo: si un token tiene el 95% de probabilidad, contop\_p=0\.9solo ese entra (1 candidato). Si las probabilidades están repartidas, pueden entrar muchos. Por esotop\_psuele dar mejores resultados: se adapta a cada predicción.

90Modelos de razonamiento (thinking models)

Los modelos de razonamiento reservan presupuesto para deliberar antes de responder. No son “más inteligentes siempre”: son mejores cuando la tarea necesita plan, búsqueda, verificación interna o coordinación de pasos.

Regla práctica: empieza por el modelo más barato que supere tu eval. Escala razonamiento solo cuando reduzca errores que realmente cuestan.

Reasoning effortcuánto presupuesto interno asignas

Thinking tokenstokens de deliberación, visibles o no según proveedor

Latenciamás pensamiento suele tardar más

Verificaciónrazonar no sustituye tests, reglas ni citas

Qué ocurre realmente

ConceptoLectura correctaImplicación prácticaRazonamiento internoEl modelo dedica tokens a explorar pasos, hipótesis o planes antes de la respuesta visible.Puede mejorar tareas difíciles, pero aumenta coste y tiempo.OpenAILos modelos de razonamiento se controlan con parámetros comoreasoning\.efforten la Responses API.Ajusta esfuerzo por tarea; no pongas alto por defecto.ClaudeExtended thinking usa un objetothinkingconbudget\_tokens.El presupuesto de thinking debe planificarse como parte demax\_tokens, coste y latencia.ContextoLos tokens de razonamiento pueden ocupar presupuesto de salida/contexto y se facturan según proveedor.Deja margen para razonar y para responder; si no, tendrás respuestas incompletas.VerdadMás reasoning no garantiza factualidad ni permisos correctos.Para alto riesgo: retrieval, tests, validadores, citas y revisión humana.### Cuándo escalar razonamiento

Señal de la tareaModelo rápidoRazonamiento medio/altoPor quéClasificar, extraer, transformar formatoNormalmente suficienteSolo si hay ambigüedad o coste altoLa tarea es local y verificable.Matemáticas, algoritmos, debugging profundoPuede fallar por atajosRecomendadoNecesita mantener hipótesis y comprobar pasos.Agente con herramientasÚtil como ejecutor baratoÚtil como planner/routerDebe decidir orden, tool, parada y recuperación.Legal, finanzas, seguridadNo basta por sí soloAlto + verificación externaEl coste de error exige evidencia y controles.Investigación larga o diseño complejoBueno para borradoresAlto o asincrónico con evalHay múltiples fuentes, trade-offs y síntesis.### Decisión económica

PreguntaCriterioEjemplo¿Cuánto cuesta pensar?coste ≈ input \+ output visible \+ reasoning/thinking \+ tool calls \+ reintentosUn modelo lento que evita tres reintentos puede salir más barato.¿Mejora algo medible?Compara contra baseline rápido en una eval real.Debugging: tests pasados, bugs resueltos, menos regresiones.¿Dónde usarlo?Planner fuerte + ejecutores baratos suele ser eficiente.Agente: razonamiento alto para plan; modelo rápido para editar o clasificar pasos simples.¿Cuándo no usarlo?Si la tarea es simple, latencia crítica o fácilmente validable.Normalizar JSON, resumir un ticket corto, clasificar idioma.Skin in the game

No compres “razonamiento” como magia. Úsalo cuando una eval demuestre que reduce fallos relevantes. Y si la respuesta mueve dinero, permisos, código o decisiones sensibles, el razonamiento debe terminar enevidencia verificable: tests, citas, constraints, tool logs o aprobación humana.

91Modelos multimodales nativos

En 2026, “multimodal” no significa automáticamente “todo a todo”. Un modelo puede aceptar imágenes pero no generar imágenes, entender audio pero responder solo texto, o usar un endpoint distinto para voz en tiempo real.

La pregunta correcta no es “¿es multimodal?”, sino “qué acepta, qué genera, si es batch o realtime, y qué garantía necesito”.

Inputtexto, imagen, PDF, audio, vídeo

Outputtexto, imagen, audio, vídeo

Realtimestreaming de voz/vídeo con baja latencia

ToolingOCR, ASR, TTS, video gen, vision, grounding

Pipeline vs nativo

Pipeline (2022-2023)

Modelo de texto + OCR + ASR + visión + TTS pegados con código. Funciona, pero cada paso puede perder contexto, introducir errores y complicar evaluación.

Componentes separadosPérdida de contexto

Nativo / integrado (2025-2026)

Un modelo o familia de endpoints comparte representación entre texto, imagen, audio o vídeo. Permite razonar cruzando modalidades, aunque generación y realtime suelen vivir en endpoints especializados.

Modelo unificadoContexto cruzado

Matriz práctica de capacidades (mayo 2026)

Familia / endpointInputOutputLectura correctaGemini 2.5 / Gemini APItexto, imagen, audio, vídeo, PDFtexto en modelos estándarMuy fuerte para comprensión multimodal larga; generación y voz dependen del endpoint.Gemini Live APItexto, audio y vídeo en streamingtexto y audioDiseñado para interacción realtime, no para análisis batch pesado.OpenAI GPT / Responsestexto e imagen según modelotexto + toolsPara visión, análisis y agentes; audio/vídeo suelen ir por endpoints especializados.OpenAI Realtimetexto, audio e imagentexto y audioVoz/agentes de baja latencia; evalúa turn-taking, interrupciones y coste de audio.OpenAI Soratexto e imagenvídeo con audioGeneración de media, no sustituto de un modelo conversacional general.Claude 4 / Messagestexto e imagentextoExcelente para análisis visual/documental; audio/vídeo requieren pipeline externo.Qwen Omnitexto, imagen, audio y vídeotexto y vozEjemplo open/abierto de enfoque omni; despliegue y runtime importan mucho.### ¿Qué cambia en la práctica?

CasoQué aporta multimodalQué debes medirSoporte con capturasEl usuario sube screenshot + texto; el modelo localiza error visual y pasos.resolución, falsos diagnósticos, privacidad de pantallaQA de vídeoAnaliza frames, audio y transcripción para detectar eventos.cobertura temporal, coste por minuto, eventos perdidosVoz realtimeConversación natural con interrupciones y latencia baja.latencia, barge-in, errores ASR, coste de audio, seguridadDocumentos complejosCombina texto, tablas, sellos, firmas, imágenes y layout.extracción estructurada, citas, errores OCR/layoutGeneración de mediaTexto/imagen de referencia -> imagen, audio o vídeo.derechos, consistencia, safety, coste y revisión humana### Trampas frecuentes

ConfusiónLectura correcta“Acepta vídeo”Puede significar frames muestreados, vídeo completo, streaming o solo archivo corto. Mira límites.“Acepta audio”No implica voz realtime ni salida de audio. Puede ser transcripción + razonamiento textual.“Nativo”No siempre significa mismo endpoint para entender, generar y conversar.“Ve PDFs”PDF puede procesarse como texto extraído, imágenes de páginas o mezcla. Evalúa tablas y layout.“Genera vídeo”Generar media es otro problema: consistencia temporal, derechos, safety y revisión pesan mucho.Skin in the game

Diseña multimodalidad como matriz de producto:modalidad de entrada, modalidad de salida, latencia, coste, privacidad, límites de archivo y evaluación. El error caro no es elegir “un modelo peor”; es asumir que una demo con una imagen equivale a un sistema fiable con vídeo, voz, documentos y usuarios reales.

92Open weights vs propietario: ¿cuál elegir?

Esta decisión no es ideológica: es una decisión de producto, riesgo y operación. Un modelo propietario suele comprarse comoservicio; un modelo open weights se adopta comocapacidad que tú operas.

La pregunta correcta no es “¿cuál es mejor?”, sino “¿qué necesito controlar y qué estoy dispuesto a operar?”.

Vocabulario que no conviene mezclar

TérminoQué tienesQué no garantizaEjemploPropietario/APIAcceso al modelo como servicio, normalmente con SLA, escalado y actualizaciones.Acceso a pesos, entrenamiento, datos o reproducibilidad completa.Claude, GPT, Gemini.Open weightsPesos descargables para inferencia, fine-tuning, cuantización o auto-hosting según licencia.Que sea “open source AI”: pueden faltar datos, código de entrenamiento o detalles suficientes para reproducirlo.gpt-oss, Llama, Mistral, Qwen, DeepSeek.Open source AISegún OSI, debe incluir forma preferida de modificación: código, información de datos y parámetros.Que todo modelo con pesos públicos cumpla esa definición.Hay que revisar cada ficha y licencia.Research / community licenseUso permitido bajo condiciones concretas.Uso comercial ilimitado, redistribución libre o ausencia de restricciones de escala.Licencias tipo Llama Community License.### Ejemplos representativos (mayo 2026)

FamiliaTipo realLectura correctaPreguntas antes de usarClaude Opus 4.7 / Sonnet 4.6Propietario/APIMuy fuertes para agentes, código, contexto largo y producto gestionado.¿Dónde viajan los datos? ¿Qué SLA, región, logs y política de retención aplican?GPT-5.5 / GPT-5.4Propietario/API + familia open weights separadaEl API frontier y gpt-oss no son lo mismo: uno es servicio cerrado, otro son pesos descargables.¿Necesitas el frontier API o basta un open-weight especializado?Gemini 3.1 / Gemini APIPropietario/APIPotente para multimodalidad, contexto largo e integración con nube Google.¿La ventaja viene del modelo o del ecosistema donde ya viven tus datos?gpt-oss-120b / 20bOpen weights, Apache 2.0Razonamiento auto-hospedado; útil si quieres control de despliegue y fine-tuning.¿Tienes GPU, serving, seguridad y evals para operarlo bien?Mistral Large 3Open weights, Apache 2.0MoE grande con pesos abiertos; buen ejemplo de modelo frontier-like desplegable por terceros.¿El coste de nodo y latencia compensa frente a API?Qwen3.6Open weights, Apache 2.0Modelo chino fuerte en coding agente, visión y contexto largo; runtime recomendado importa mucho.¿Puedes servirlo con vLLM/SGLang/KTransformers y medirlo en tus tareas?DeepSeek-V4 Pro/FlashOpen weights, MITMoE de gran escala, contexto largo y modos de razonamiento; comparar total vs activo es obligatorio.¿Qué versión, cuantización y modo de reasoning estás evaluando?Llama 4 Scout/MaverickOpen weights con licencia propiaPesos disponibles, multimodalidad y MoE; no lo trates como Apache/MIT sin leer la licencia.¿Tu caso encaja con la Community License y la política de uso?### Matriz de decisión

CriterioPropietario suele ganar si...Open weights suele ganar si...Calidad máximaNecesitas el mejor resultado general, multimodalidad madura o tool use muy robusto desde hoy.La tarea es acotada y un modelo ajustado/quantizado supera suficiente la eval interna.Privacidad y residenciaEl proveedor ofrece región, contratos, retención cero o controles enterprise aceptables.Los datos no pueden salir de tu red, cliente, dispositivo o jurisdicción.CosteVolumen bajo/medio, picos impredecibles o equipo pequeño: pagas por uso y evitas operación.Volumen alto y estable: amortizas GPUs, batch, caché y modelos pequeños por tarea.LatenciaLa API está cerca del usuario y el proveedor optimiza streaming/realtime.Necesitas edge, offline, on-prem o latencia muy baja dentro de tu propia red.PersonalizaciónBasta prompting, RAG, tools, fine-tuning gestionado o guardrails del proveedor.Necesitas LoRA, distilación, cuantización, tokenizer propio o inspección de pesos/versiones.ResponsabilidadQuieres delegar serving, parches, seguridad operacional y escalado.Aceptas operar monitorización, evaluación, abuso, red teaming, upgrades y rollback.### Fórmula útil: coste total, no solo precio por token

TCO self\-host ≈ GPU/hora / utilización \+ ingeniería \+ observabilidad \+ seguridad \+ energía \+ fallos TCO API ≈ tokens entrada \+ tokens salida \+ tools \+ reintentos \+ latencia \+ dependencia proveedor

Un modelo open weights “gratis” puede ser caro si la GPU está al 8%, si nadie sabe depurar vLLM, o si cada incidente consume al equipo. Un API caro puede ser barato si evita meses de infraestructura y mejora conversión, soporte o calidad.

Patrón realista: arquitectura híbrida

CapaModelo típicoPor quéClasificación, extracción simple, PIIOpen weights pequeño/localBarato, privado, rápido y fácil de validar.RAG interno sensibleOpen weights o API con contrato enterpriseLa política de datos manda más que el benchmark.Planificación difícil, código, casos rarosPropietario frontier o modelo open grandeEscalas inteligencia solo cuando la tarea lo justifica.FallbackSegundo proveedor o modelo localReduce dependencia, caídas, límites de rate y sorpresas de versión.Skin in the game

No elijas por identidad de marca. Haz una eval con tus datos y calculacalidad, latencia, coste total, riesgo legal, operación y salida. La mejor decisión suele ser híbrida: modelo propietario para tareas difíciles, open weights para privacidad/coste/control, y un router que decide con métricas.

93Destilación de modelos

Analogía

Un profesor experto no solo dice la respuesta correcta: también muestra qué alternativas eran casi plausibles y cuáles eran absurdas. En destilación, el modelo pequeño aprende esa “forma de decidir” del modelo grande.

Destilar no es entrenar desde cero ni “meter conocimiento nuevo” en tiempo real. Es entrenar unstudentpara imitar el comportamiento de unteachermás caro, grande o lento.

La destilación es compresión de comportamiento: cambias capacidad general por coste, latencia, privacidad o despliegue local.

La idea matemática

ElementoLectura sencillaPor qué importaSoft targetsEl teacher no devuelve solo “clase correcta”; devuelve una distribución de probabilidades.El student aprende relaciones entre opciones: “gato” puede estar más cerca de “lince” que de “camión”.Temperaturap\_i = softmax\(z\_i / T\). SiTsube, la distribución se suaviza.Revela “dark knowledge”: señales débiles que una etiqueta dura ocultaría.PérdidaL = α CE\(y, s\) \+ \(1\-α\) T² KL\(p\_teacher^T \|\| p\_student^T\)Combina verdad etiquetada con imitación del teacher; no todo debe depender de respuestas sintéticas.EvalStudent vs teacher vs baseline pequeño.Si no mides, solo has entrenado un imitador más barato, no necesariamente útil.### Qué se puede destilar

TipoQué imita el studentEjemplo prácticoRiesgoLogitsDistribución de probabilidades del teacher.Clasificador pequeño para soporte o moderación.Necesitas acceso a logits; muchas APIs no lo dan.RespuestasOutputs generados por el teacher.Dataset sintético de preguntas/respuestas para un modelo local.El student aprende estilo y errores del teacher.RazonamientoTrazas, pasos o soluciones largas.Modelos de razonamiento tipo R1 distill.Puede aprender a “sonar razonable” sin verificar.PreferenciasQué respuesta es mejor entre varias.Reducir rechazos falsos, mejorar tono o formato.Puede sobreajustarse a gustos del juez.### Caso moderno: DeepSeek-R1 distill

DeepSeek-R1 mostró muy bien el patrón: un teacher grande de razonamiento genera ejemplos que se usan para ajustar modelos mucho más pequeños. Las variantes destiladas de 1.5B, 7B, 8B, 14B, 32B y 70B acercaron razonamiento paso a paso a hardware más accesible, pero no convirtieron esos modelos en el teacher completo.

DecisiónSí tiene sentidoMejor noLatenciaRespuesta en móvil, navegador, call center o asistente interno con mucho volumen.Casos raros donde el coste del error supera el ahorro por token.Dominio estrechoExtracción de facturas, clasificación de tickets, comandos internos, estilo de soporte.Preguntas abiertas donde necesitas conocimiento amplio y actualizado.PrivacidadQuieres inferencia local/on-prem con datos sensibles.Usas datos sintéticos con licencias dudosas o sin trazabilidad.EquipoTienes evals, dataset, MLOps y capacidad de servir el student.No tienes métrica de éxito ni ejemplos negativos.Skin in the game

No destiles “para mejorar un modelo”; destila para ganar una restricción concreta:menos latencia, menos coste, más privacidad o despliegue offline. Si el problema es acceder a datos cambiantes, usa RAG. Si el problema es formato o estilo, prueba primero prompting/fine-tuning. Si el problema es coste a escala y ya tienes una eval estable, entonces destilar empieza a tener sentido.

94Inferencia optimizada

Servir un LLM en producción no es “cargar pesos y llamar agenerate\(\)”. Es gestionar memoria, colas, latencia, concurrencia y coste por token sin romper calidad.

Optimizar inferencia significa decidir qué cuello de botella tienes: memoria de pesos, KV cache, decodificación secuencial, batching, red o calidad.

TTFTtiempo hasta el primer token

TPOTtiempo por token generado

Throughputtokens/segundo agregados

UtilizaciónGPU ocupada sin colas absurdas

Prefill vs decode

FaseQué ocurreCuello de botellaOptimización típicaPrefillEl modelo procesa todo el prompt/contexto inicial.Compute y memoria para una secuencia larga.prompt caching, chunked prefill, RAG selectivo, no meter documentos enteros sin criterio.DecodeGenera tokens uno a uno de forma autoregresiva.Secuencialidad: cada token depende del anterior.KV cache, speculative decoding, batching continuo, modelos más pequeños.ServingMuchas peticiones compiten por la misma GPU.Fragmentación de memoria, colas, picos y tamaños variables.PagedAttention, continuous batching, límites de contexto, backpressure.### KV cache: la memoria invisible

En un decoder-only Transformer, cada token nuevo reutiliza claves y valores de tokens anteriores. La KV cache evita recalcular contexto, pero consume memoria proporcional a capas, batch y longitud.

Fórmula mentalLectura prácticaKV ≈ 2 × capas × batch × seq\_len × kv\_heads × head\_dim × bytesEl “2” son K y V. Si duplicas contexto o concurrencia, sube memoria casi linealmente.memoria total ≈ pesos \+ KV cache \+ activaciones \+ overhead runtimeQue los pesos quepan en VRAM no significa que puedas servir 100 usuarios con 128k tokens.### Técnicas clave

TécnicaQué resuelveTrade-offPagedAttentionGestiona KV cache en bloques, reduciendo fragmentación y desperdicio de memoria.Complejidad del runtime; dependes de servidor especializado como vLLM.Continuous batchingAgrupa peticiones que entran/salen en momentos distintos para mantener GPU ocupada.Puede empeorar latencia individual si no configuras colas y prioridades.Speculative decodingUn modelo draft propone tokens y el modelo grande verifica varios de golpe.Acelera si el draft acierta; añade complejidad y memoria extra.QuantizaciónReduce memoria y ancho de banda de pesos.Puede perder calidad, especialmente en razonamiento fino o modelos pequeños.Tensor parallelismParte capas/matrices entre varias GPUs para modelos que no caben en una.La comunicación entre GPUs puede comerse la mejora.Prefix/prompt cachingReutiliza prefijos repetidos: system prompts, instrucciones, documentos comunes.Sirve cuando hay repetición real; no arregla prompts caóticos.### Herramientas de serving

HerramientaUso típicoPunto fuerteCuidado con...vLLMAPIs OpenAI-compatible con alto throughput.PagedAttention, continuous batching, serving multiusuario.Configurar memoria, contexto y paralelismo según modelo.SGLangAgentes, structured generation y serving eficiente.Buen soporte para routing, tool use y modelos frontier open weights.Versiones de parser/tool calling y compatibilidad de modelos.TensorRT-LLMRendimiento máximo en NVIDIA.Kernels optimizados, FP8/INT8, despliegue de alto rendimiento.Mayor complejidad de build, hardware y mantenimiento.llama.cpp / GGUFLocal, edge, CPU/GPU ligera.Portabilidad, cuantizaciones, laptops y edge servers.No es la misma experiencia que servir cientos de usuarios concurrentes.Ollama / LM StudioDesarrollo local y demos.Ergonomía excelente para probar modelos.No confundas comodidad de demo con serving productivo.Skin in the game

Antes de tocar knobs, mideTTFT, TPOT, tokens/s, coste por 1.000 requests, tasa de errores y calidad. Optimizar sin eval puede convertir un sistema correcto en uno rápido que se equivoca. Si usas OpenAI, Claude o Gemini como API, gran parte de esto lo opera el proveedor; si auto-hospedas, pasa a ser tu problema.

95Edge AI: modelos en el dispositivo

Edge AI significa ejecutar inferencia cerca del usuario: móvil, portátil, navegador, coche, fábrica o servidor local. No es “menos serio” que cloud; es otra arquitectura con restricciones distintas.

El edge gana cuando privacidad, latencia, coste variable u offline importan más que usar siempre el modelo más grande.

¿Cabe en el dispositivo?

Cálculo mentalEjemploQué falta sumarmemoria pesos ≈ parámetros × bits / 83B en INT4 ≈ 1.5 GB solo pesos. 7B en INT4 ≈ 3.5 GB solo pesos.KV cache, runtime, tokenizer, buffers, sistema operativo y margen térmico.KV cache ∝ contexto × capas × batchUn contexto largo puede romper un modelo que “cabía” con un prompt corto.Límites de tokens, streaming, truncado y UX de documentos.energía ≠ gratisSin coste por token en API, pero hay batería, calor y experiencia de usuario.Thermal throttling, consumo, tiempos de descarga y tamaño de app.### Opciones por plataforma

PlataformaRuntime / APIUso razonableRiesgoNavegadorWebGPU, WebLLM, Transformers.js, ONNX Runtime Web, Prompt API.Clasificación, embeddings, resumen corto, chat pequeño, demos privadas.Compatibilidad de navegador, descarga inicial, memoria y rendimiento desigual.iOS/macOSCore ML, MLX, Foundation Models framework.Autocompletado, extracción, asistentes privados, adapters/LoRA, modelos Apple Silicon.Versiones de sistema, tamaño de modelo, ANE/GPU/CPU y políticas de distribución.AndroidGoogle AI Edge / MediaPipe LLM Inference, LiteRT, ONNX Runtime.Texto local, resumen, comandos, modelos Gemma/Gemini Nano cuando aplique.Fragmentación de hardware y memoria; probar en gama media real.Edge serverllama.cpp, vLLM, SGLang, TensorRT-LLM, Ollama.On-prem, fábrica, hospital, call center, baja latencia LAN.Operación, seguridad, actualizaciones y observabilidad siguen siendo tuyas.### Cloud vs edge: decisión aplicada

CasoCloudEdge / on-deviceArquitectura habitualAsistente legal complejoMejor razonamiento, contexto y citas con modelos grandes.Útil para PII redaction previa o búsqueda local.Edge limpia/filtra; cloud razona; logs auditados.Teclado predictivoDemasiada latencia y privacidad sensible.Ideal: texto no sale del dispositivo.Modelo pequeño local + aprendizaje privado.Fábrica sin conexión estableFalla si la red cae.Funciona offline y cerca de sensores.Edge server local + sincronización diferida.Soporte con casos rarosModelo frontier para problemas difíciles.Modelo local clasifica, resume y enruta.Router: local por defecto, cloud para escalado.Educación / laboratorioBueno para comparar SOTA.Bueno para aprender tokens, memoria y límites reales.Colab/cloud para entrenar; local para inferencia ligera.### Trampas frecuentes

ConfusiónLectura correcta“On-device es privado”Solo si no envías telemetría, prompts, embeddings o errores a servicios externos.“No pago tokens”Pagas en batería, almacenamiento, soporte, rendimiento y abandono si la UX es mala.“Corre en mi portátil”No significa que corra en móviles de gama media ni en navegador con memoria limitada.“El modelo pequeño basta”Basta para tareas estrechas; para razonamiento abierto suele necesitar router o fallback.Skin in the game

Diseña edge con una eval en dispositivos reales:tiempo de descarga, memoria pico, tokens/s, temperatura, batería, calidad y fallback. La arquitectura robusta no es “todo local” ni “todo cloud”: es decidir qué debe quedarse cerca del usuario y qué merece escalar a un modelo grande.

96Lo que deberías saber: arquitecturas y modelos

ConceptoSlideLLM = modelo de lenguaje a gran escala; estado del arte mayo 2026 y dimensiones públicas81Arquitecturas modernas: Transformer, MoE, SSM/Mamba, híbridos y multimodalidad82Transformer: atención paralela sobre toda la secuencia83MoE: activar solo una fracción de los parámetros por token84 y 88Q, K, V: matemáticas de la atención, multi-head y positional encoding85Tokenización: BPE, impacto en coste, idioma y límites de contexto86Transfer learning: pre-entrenar una vez, adaptar a tareas concretas87Temperature, top_p, max_tokens y otros parámetros de generación89Modelos de razonamiento: thinking tokens, coste, latencia y verificación90Multimodalidad: input/output, batch vs realtime y endpoints especializados91Open weights vs propietario: licencia, TCO, privacidad y operación92Destilación: teacher/student, soft targets, casos adecuados y riesgos93Inferencia optimizada: KV cache, vLLM, batching y speculative decoding94Edge AI: memoria, batería, privacidad, navegador, móvil y edge servers95 97

Uso práctico

Prompt engineering, alucinaciones, modelos frontier, Hugging Face, Colab, experimentos reproducibles, RAG, bases de datos vectoriales y arquitectura de apps LLM.

98Prompt engineering: cómo hablarle bien al modelo

No es “preguntarle cosas”: esdiseñar la entradapara obtener la salida que necesitas. La calidad del prompt determina la calidad de la respuesta.

Técnicas principales

TécnicaQué esEjemploZero-shotPregunta directa sin ejemplos“Traduce esto al inglés“Few-shotIncluir 2-3 ejemplos del formato esperado’Entrada: X → Salida: Y. Ahora: Z →‘Razonamiento guiado“Analiza internamente y devuelve solo pasos verificables“Útil para tareas complejas sin exponer razonamiento privadoSystem promptDefine rol, restricciones, formato“Eres un experto en seguridad. Responde en JSON”Structured outputPedir formato específico’Devuelve un JSON con los campos: nombre, tipo’Prompt negativoDecir lo que NO debe hacer“No inventes datos. No uses markdown“### Antes vs después: el impacto de un buen prompt

“Hazme una función de validación”

“Escribe una función en TypeScript que valide un email. Debe devolver un objeto { valid: boolean, error?: string } y cubrir: formato, dominio y longitud.”

Regla de oro

Cuanto más contexto y restricciones claras, mejor resultado. Un buen prompt convierte un modelo mediocre en útil; un mal prompt desperdicia un modelo excelente.

99Context engineering: más allá del prompt

En 2026 el término clave ya no esprompt engineeringsinocontext engineering: la disciplina de gestionartoda la informaciónque recibe el modelo, no solo el prompt del usuario.

¿Qué compone el contexto?

CapaQué contieneQuién lo gestionaSystem promptInstrucciones base, rol, restriccionesEl desarrollador (CLAUDE.md, rules)MemoriaDecisiones previas, preferencias del usuarioEl framework (memoria episódica, ficheros)RAG / contexto dinámicoDocumentos relevantes, código fuenteEl pipeline de retrievalTools disponiblesDescripciones de herramientas (MCP, functions)La configuración del agenteHistorial de conversaciónMensajes previos del turno actualEl framework (compactación)Prompt del usuarioLa petición concretaEl usuarioCambio de mentalidad

El prompt del usuario es solo una fracción del contexto. Un buencontext engineerdiseña las 6 capas para acercar al modelo la información relevante sin ruido innecesario. Demasiado contexto puede degradar la calidad (lost in the middle); poco contexto aumenta el riesgo de alucinaciones.

Técnicas de context engineering (2026)

• **Compactación selectiva:**resumir el historial manteniendo las decisiones clave (Claude Code lo hace automáticamente)
• **Rules persistentes:**ficheros CLAUDE.md, .cursorrules o AGENTS.md que inyectan contexto en cada conversación
• **Memoria episódica:**recordar conversaciones anteriores y recuperarlas cuando son relevantes
• **Context routing:**enviar solo el contexto relevante según la tarea detectada

100Formatos de datos para LLMs: JSON, YAML, Markdown y más

Los LLMs no leen datos como un parser: los interpretan comosecuencia de tokens. El formato que elijas afecta directamente a la calidad de la respuesta, el coste y la velocidad.

Comparativa de formatos

FormatoTokens (mismo dato)FuerzaCaso de uso idealJSON~120Parseo exacto, schema validationStructured output, APIs, function callingYAML~85Legible, menos ruido sintácticoConfiguración, frontmatter de skills, prompts complejosMarkdown~70Natural para el modelo, jerárquicoSystem prompts, CLAUDE.md, documentación como contextoXML / tags~100Separación clara de bloquesPrompts con múltiples secciones (Anthropic recomienda<tags\>)TOML~90Secciones explícitas, tipadoFicheros de configuración de herramientasCSV / tabular~50Mínimo overheadDatos tabulares masivos, few-shot con muchos ejemplos### El mismo dato en 3 formatos

{ “name”:“Ana”, “role”:“backend”, “skills”: [“Go”,“Rust”] }

name: Ana role: backend skills: - Go - Rust

## Ana - Rol: backend - Skills: Go, Rust

<developer> <name>Ana</name> <role>backend</role> <skills>Go, Rust</skills> </developer>

Regla práctica: ¿cuándo usar cada uno?

• ¿Tu código parsea la salida?→ JSON con strict mode (slide 40)
• ¿El LLM lee la entrada como contexto?→ Markdown (más natural, menos tokens)
• ¿Configuras herramientas de IA?→ YAML (skills, agentes, frontmatter)
• ¿Separas bloques en un prompt largo?→ XML tags (<context\>,<instructions\>)

Formato como contrato

SituaciónFormato recomendadoPor quéValidaciónSalida que ejecuta códigoJSON Schema / tool callEl backend necesita tipos, campos obligatorios y errores controladosValidador + retry + logsContexto largo para leerMarkdown con títulos establesEl modelo aprovecha jerarquía, listas y fragmentos documentalesCitas por secciónBloques de promptXML/tagsEvita mezclar instrucciones, datos y ejemplosSepararinstructions,context,examplesMuchos ejemplos tabularesCSV/TSV compactoMenos tokens y lectura regular cuando las columnas son clarasCabeceras y tipos explícitosConsejo clave

Markdown suele funcionar bien con LLMs porque aparece mucho en documentación, issues, repositorios y datos de entrenamiento. Úsalo para estructurar contexto legible (CLAUDE.md, system prompts, documentación). Reserva JSON para cuando necesites quetu códigoparsee la salida.

101Alucinaciones: cuando la IA inventa con total confianza

Una alucinación ocurre cuando el modelo genera informaciónfalsa, inventada o sin base suficiente, pero la presenta con apariencia de dato real. No es un simple bug de implementación: es un riesgo propio de generar lenguaje por probabilidad sin verificación externa.

Ejemplo real: código alucinado

“Usa la librería fast-csv-validator para validar este CSV”

import{ validate }from “fast-csv-validator”;

db.findOneAndValidate()

docker run--memory-swap-limit

“Ver docs en docs.example.com/v3/...”

¿Por qué ocurre?

• **No consulta automáticamente una base de datos:**si no le das herramientas o contexto, responde desde patrones aprendidos. Si “fast-csv-validator” suena plausible, puede generarlo
• **No verifica por defecto:**puede mezclar datos reales, inferencias y elementos inventados con el mismo tono de confianza
• **Cuanto más específico, más riesgo:**preguntas generales (“¿qué es REST?”) suelen ser más seguras. Preguntas específicas (“¿qué método de la API de Stripe v4.2 maneja reembolsos parciales?”) requieren verificación

Tipos de alucinación

TipoEjemploMitigación realFactualFecha, precio, benchmark o API inventadaBuscar fuente primaria, usar RAG, citar documento concretoBibliográficaPaper, URL o autor inexistenteVerificar enlaces y DOI; no aceptar citas sin abrirCódigo/APIMétodo, flag o paquete que no existeCompilar, ejecutar tests, consultar docs oficialesRazonamientoConclusión coherente con premisas falsasSeparar hechos, supuestos, cálculo y verificaciónGroundingRespuesta no soportada por los documentos recuperadosObligar a citar chunks y permitir “no hay evidencia”### Cómo protegerte

EstrategiaCómo aplicarlaVerificar importsComprueba que cada paquete existe en npm/PyPI antes de instalarloComprobar APIsVerifica cada método/función contra la documentación oficialRAGInyecta documentación real en el prompt para que el modelo se base en datos verificadosPedir fuentesPide al modelo que cite la fuente. Si no puede dar una URL real, sospechaTestsEjecuta siempre el código generado. Un test que falla detecta la alucinación antes de que llegue a producciónRegla de oro

Cuanto menos sabes de un tema, más peligrosa es la alucinación. Si no puedes verificar la respuesta por tu cuenta, no confíes ciegamente. La IA no “sabe” que no sabe.

102Structured output: que el modelo devuelva datos parseables

En producción no quieres texto libre: quieresJSON válido, con campos tipados, que tu código pueda parsear sin romper. Los modelos modernos ofrecen modos para aumentar mucho la fiabilidad del formato.

Tres niveles de control

NivelCómoFiabilidadPrompt“Responde en JSON con los campos name y age“Media: el modelo puede añadir texto extra o romper el formatoJSON modeParámetro tiporesponse\_format, según proveedorAlta: fuerza JSON válido en condiciones normales, pero no garantiza el schemaSchema / tool useJSON Schema en la definición de la tool o respuestaMuy alta: restringe la salida al schema, pero valida igualmente en tu backend### Ejemplo con Anthropic (tool use con schema)

constresponse =awaitclient.messages.create({ model:“claude-sonnet-4-6”, tools: [{ name:“extract_contact”, description:“Extrae datos de contacto del texto”, input_schema: { type:“object”, properties: { name: { type:“string”}, email: { type:“string”}, phone: { type: [“string”,“null”] } }, required: [“name”,“email”] } }], tool_choice: { type:“tool”, name:“extract_contact”}, messages: [{ role:“user”, content:“Ana Garcia, [email protected], tel 612345678” }] });

¿Cuándo usar cada nivel?

• **Solo prompt:**prototipos rápidos, chat interactivo donde no necesitas parsear la salida
• **JSON mode:**cuando necesitas JSON pero el schema es flexible o variable
• **Strict mode:**producción, pipelines automatizados, integraciones API donde un campo que falta rompe el flujo

Diseño de schema

DecisiónBuena prácticaPor quéCampos requeridosSolo los imprescindibles; usa nullable si falta informaciónEvita inventar datos para completar el objetoEnumsLimita categorías cerradas:billing,support,salesReduce variaciones difíciles de procesarUnidadesIncluye moneda, zona horaria, idioma o escalaUn número sin unidad es una fuente de bugsConfianzaAñadeconfidenceyevidencecuando haya incertidumbrePermite revisión humana o reintento selectivoValidación backendRechaza, corrige o reintenta salidas inválidasEl schema del proveedor no sustituye tus reglas de negocioClave práctica

Structured output reduce mucho la necesidad de parsear texto con regex. Defines el schema una vez, fuerzas la forma de la salida y después validas en código. Aun con schema, rechaza, reintenta y registra fallos: la garantía final la da tu backend.

103Visión y multimodalidad: más allá del texto

Los modelos actuales no solo leen texto: puedenver imágenes, leer PDFs y procesar audio. Esto abre casos de uso que antes requerían herramientas especializadas.

¿Qué puedes enviar al modelo?

Imágenes

Capturas de pantalla, diagramas, mockups, fotos de pizarras, gráficos. El modelo los “ve” y puede describir, analizar o extraer datos

PDFs y documentos

Contratos, facturas, papers, manuales. El modelo extrae texto, tablas y entiende la estructura del documento

Capturas de errores

Envía un screenshot del error en vez de copiar/pegar. El modelo lee la traza, identifica el problema y sugiere la solución

Diagramas y mockups

Envía un wireframe dibujado a mano o un diagrama de arquitectura. El modelo lo interpreta y puede generar código a partir de él

Ejemplo: enviar una imagen a la API

constresponse =awaitclient.messages.create({ model:“claude-sonnet-4-6”, messages: [{ role:“user”, content: [ { type:“image”, source: { type:“url”, url:“https://ejemplo.com/screenshot.png” } }, { type:“text”, text:“¿Qué error muestra esta captura?”} ] }] });

Soporte por modelo (mayo 2026)

CapacidadClaude Opus 4.7GPT-5.5Gemini 3.1 Pro PreviewImágenesSí (hasta 20 por mensaje)SíSíPDFsSí (nativo)SíSíAudioNo en MessagesSí vía modelos Realtime/audioSí vía Live/APIVideoNoHerramientas especializadasSí### Qué debes medir

CasoLo que suele fallarMétrica útilCapturas de UIConfundir texto pequeño, estados deshabilitados o jerarquía visualdiagnóstico correcto, pasos reproducibles, falso positivoPDFsTablas, pies de página, firmas, columnas y anexosextracción campo a campo + cita de páginaDiagramasInferir relaciones no dibujadas o leer flechas malcomparar nodos/aristas contra solución esperadaImágenes con textoOCR parcial y errores en números/códigosexact match de campos críticosCaso de uso inmediato

En vez de describir un bug con texto, envía la captura de pantalla. En vez de copiar una tabla de un PDF, envía el PDF. En vez de transcribir un diagrama, envía la foto. El modelo hace el trabajo de interpretación por ti.

104Voz y APIs en tiempo real

En 2026, los agentes ya no solo leen y escriben texto:hablan. Las APIs de voz en tiempo real permiten construir agentes conversacionales con baja latencia.

Pipeline clásico vs nativo

Pipeline (STT + LLM + TTS)

Audio entra como texto (STT), el modelo responde en texto, y se sintetiza voz (TTS). Funciona, pero cada etapa añade latencia.

Mayor latenciaMás control

Nativo (speech-to-speech)

Audio entra y sale directamente del modelo, sin pasos intermedios. OpenAI Realtime API y Gemini Live lo soportan. La latencia depende de red, región, modelo y configuración.

Baja latenciaMás natural

Herramientas (mayo 2026)

HerramientaTipoPunto fuerteOpenAI Realtime APISpeech-to-speech nativoWebSocket bidireccional, tool use con voz, interrupciones naturalesElevenLabsTTS de alta calidadVoces clonadas, multilingüe, baja latencia. El estándar en calidad de vozDeepgramSTT en tiempo realTranscripción streaming, muy rápido, buena precisión en españolGemini LiveSpeech-to-speech nativoIntegrado con el ecosistema Google, soporte de vídeo en tiempo real### Casos de uso prácticos

• **Agentes de soporte telefónico:**sustituyen IVRs tradicionales por conversaciones naturales con acceso a herramientas
• **Pair programming por voz:**hablar con el agente mientras programas, sin cambiar de contexto
• **Traducción simultánea:**interpretar reuniones en tiempo real entre idiomas

Métricas de una experiencia de voz

MétricaQué midePor qué importaEnd-to-end latencyDesde que el usuario termina/pausa hasta que oye respuestaPor encima de cierto umbral la conversación se siente torpeBarge-inCapacidad de interrumpir al agente mientras hablaSin interrupción, la voz se parece a un IVR modernoTurn detection / VADDetectar cuándo el usuario terminó de hablarEvita cortes prematuros y silencios incómodosTool latencyTiempo de consultar CRM, pedidos, calendario o base internaLa voz magnifica cualquier espera de backendSafety auditQué dijo, qué tool llamó y con qué permisoNecesario en soporte, ventas, salud, finanzas o complianceTendencia 2026

La voz es la interfaz más natural para humanos. Los agentes de voz están pasando de “demo impresionante” a “producto en producción”. El reto ya no es la tecnología, sino diseñar buenas experiencias conversacionales.

105Generación de imágenes y vídeo con IA

Los modelos generativos no solo producen texto: generanimágenes, vídeo, audio y 3Da partir de descripciones en lenguaje natural.

Modelos de imagen (snapshot mayo 2026)

ModeloEmpresaPunto fuerteGPT Image 2OpenAIGeneración y edición de imagen en API; DALL-E 3 queda como generación anterior en muchos flujosNano Banana Pro / Imagen 4GoogleImagen nativa con razonamiento, texto y edición contextualMidjourney v7MidjourneyCalidad estética y workflows creativosFlux / Stable DiffusionBFL / StabilityOpen weights, control local y ecosistema de LoRAs### Modelos de vídeo

ModeloEmpresaCapacidadSora 2 / Sora 2 ProOpenAIVídeo con audio sincronizado; verificar estado API porque el catálogo los marca legacy/deprecatedVeo 3.1GoogleVídeo cinematográfico, edición y audio nativoRunwayRunwayReferencia en producción creativa y image-to-video### Casos de uso prácticos

• **Prototipar UIs:**generar mockups desde descripciones antes de programar
• **Assets y placeholders:**iconos, fondos, avatares para tests y demos
• **Documentación visual:**diagramas explicativos para docs técnicas

Evaluar media generativa

CriterioImagenVídeoFidelidad al promptObjetos, estilo, composición y texto legibleAcciones, cámara, continuidad y audio coherenteConsistenciaMismo personaje/producto entre variantesIdentidad, ropa, manos, física y escena entre framesDerechosMarcas, personajes, datasets y licencia de usoVoz, música, likeness y derechos audiovisualesRevisión humanaNecesaria si se publica o representa una marcaCrítica por coste reputacional y deepfakesLimitaciones actuales

Imágenes: aún fallan con texto exacto y consistencia entre imágenes del mismo personaje. Vídeo: física inconsistente, artefactos en movimientos complejos, duración limitada. Catálogo, nombres de modelo, límites y regiones cambian según proveedor y plan.

106Cómo funcionan los modelos de difusión

Los modelos de difusión generan imágeneseliminando ruido progresivamente. Empiezan con ruido puro y, paso a paso, lo convierten en una imagen coherente guiada por tu prompt.

Proceso de generación

Texto (prompt)→CLIP codifica el texto→Ruido aleatorio (latent space)→Denoising (20-50 pasos)→Decodificar a imagen

Conceptos clave

Latent space

En vez de trabajar con píxeles directamente (512x512x3 = 786K valores), se comprime a un espacio latente mucho más pequeño (64x64x4). Esto hace la generación viable en GPUs consumer

CLIP (text encoder)

Convierte tu prompt de texto en un vector que guía el proceso de denoising. Entiende conceptos, estilos y composiciones. Es el puente entre lenguaje e imagen

Denoising (U-Net / DiT)

La red neuronal que elimina ruido paso a paso. En cada paso, predice cuánto ruido quitar y en qué dirección. Los modelos nuevos (Flux, SD3) usan DiT (Diffusion Transformer) en vez de U-Net

CFG (Classifier-Free Guidance)

Controla cuánto se adhiere la imagen al prompt. Valor alto (7-12): muy fiel al texto pero menos natural. Valor bajo (1-3): más creativo pero puede ignorar partes del prompt

Fórmula mental de difusión

FaseLecturaImplicación prácticaForward processx\_t = ruido\(x\_0, t\): durante entrenamiento se añade ruido a una imagen realEl modelo aprende a invertir el procesoReverse processε\_θ\(x\_t, t, prompt\)predice el ruido que hay que quitarMás pasos suelen mejorar control hasta cierto punto, pero aumentan latenciaSeedInicializa el ruido aleatorioMisma seed + mismo modelo + mismos parámetros ≈ imagen reproducibleCFGMezcla predicción condicionada por prompt y sin promptValores altos fuerzan texto pero pueden crear artefactos### Difusión vs GANs

Difusión (SD, Flux, DALL-E)GANs (StyleGAN)CalidadMuy alta, diversaMuy alta, pero limitadaControlTexto, imagen, pose, depth...Limitado (vectores latentes)EntrenamientoEstableInestable (mode collapse)VelocidadMás lento (múltiples pasos)Rápido (un solo paso)Por qué Stable Diffusion cambió todo

Fue el primer modelo de difusión de alta calidad publicado conpesos abiertos y un ecosistema ampliamente reutilizable(agosto 2022). Permitió que cualquiera con una GPU de 8 GB generase imágenes. Abrió la puerta a LoRAs, ControlNet, ComfyUI y todo el ecosistema que existe hoy.

107Tipos de entrenamiento para modelos de imagen

No necesitas entrenar un modelo desde cero. Existen técnicas paraadaptar modelos existentesa tu estilo, personaje o dominio con pocos datos y hardware modesto.

TécnicaDatosVRAMResultadoCaso de usoFull fine-tuningMiles de imágenes24-80 GBModelo completamente nuevoCrear un modelo de dominio (médico, satélite, arquitectura)LoRA20-200 imágenes6-12 GBAdaptador pequeño (10-200 MB)Estilo artístico, personaje, concepto. El más usadoDreamBooth5-30 imágenes12-24 GBModelo o LoRA especializadoEnseñar un objeto/persona específica al modeloTextual Inversion3-10 imágenes4-8 GBEmbedding nuevo (pocos KB)Definir un concepto con una palabra clave### ¿Cuál elegir?

LoRA (lo más común)

Entrena en horas con decenas de imágenes, según GPU y configuración. Fichero pequeño, apilable (puedes combinar varios LoRAs). En muchos casos es la opción práctica antes de tocar el modelo completo

DreamBooth (identidad)

Cuando necesitas que el modelo “reconozca” una persona u objeto concreto. Mejor consistencia facial que LoRA. Más pesado de entrenar

Textual Inversion (ligero)

El más simple: define un concepto con muy pocas imágenes. Resultado más sutil que LoRA. Ideal para estilos de color o texturas

Dataset y captions mandan

PiezaBuena prácticaFallo típicoImágenesVariedad de pose, luz, fondo, distancia y expresión20 fotos casi iguales: el LoRA memorizaCaptionsDescribir lo que debe aprender y lo que no debe fijarCaptions pobres que atan estilo, fondo e identidad sin quererRegularizaciónComparar outputs con y sin adapter, varias seeds y prompts negativosSobreentrenar hasta perder flexibilidadEval visualGrid fijo: prompts, seeds y criterios antes/despuésElegir solo la mejor imagen de veinte### Ejemplo: entrenar un LoRA con Kohya

accelerate launch train_network.py \ --pretrained_model=“stabilityai/stable-diffusion-xl”\ --train_data_dir=“./dataset”\ --output_dir=“./output”\ --network_module=“networks.lora”\ --resolution=1024--train_batch_size=1\ --max_train_epochs=10--lr=1e-4

Consejo práctico

Antes de entrenar, busca enCivitaisi alguien ya entrenó algo similar. Hay miles de LoRAs gratuitos. Entrenar desde cero solo merece la pena si necesitas algo muy específico que no existe.

108Herramientas OSS y plataformas para imagen

El ecosistema open source de generación de imágenes es enorme. Estas son las herramientas que conviene conocer.

Interfaces locales

HerramientaTipoPunto fuerteComfyUINode-based (grafos)Máximo control. Workflows visuales reutilizables. El estándar para pipelines complejos. Extensible con custom nodesForge / A1111UI web clásicaMás simple que ComfyUI. Interfaz de formulario. Forge es el fork optimizado de Automatic1111InvokeAIUI web modernaCanvas para inpainting/outpainting. Buena UX. Instalación fácil### Plataformas cloud (GPU bajo demanda)

PlataformaModelo de pagoIdeal paraReplicatePay-per-inferenceAPI para integrar en apps. Modelos predeployados. Cero configRunPodGPU por hora ($0.2-2/h)Entrenar LoRAs, ejecutar ComfyUI en la nube, GPUs potentesfal.aiPay-per-inferenceAPI rápida para Flux, SDXL. Serverless. Baja latenciaModalPay-per-secondInfraestructura serverless para ML. Deploy de pipelines custom### Ecosistema de modelos

Civitai

El marketplace principal. Miles de modelos, LoRAs, embeddings y workflows de ComfyUI compartidos por la comunidad. Filtros por estilo, modelo base, valoración

Hugging Face

Hub oficial para modelos base (SDXL, Flux, SD3). Model cards con licencias, benchmarks y demos. Más formal que Civitai

De workflow a producto

PasoQué guardarPor quéPrompt y negativosTexto, seed, sampler, steps, CFG, resoluciónReproducibilidad y debugging visualWorkflowJSON de ComfyUI o pipeline versionadoPermite pasar de demo a backendModelos/adaptersBase, VAE, LoRAs, ControlNet, hashesEvita “funciona en mi máquina”Política de revisiónSafety, derechos, marca, aprobación humanaLa generación visual tiene riesgo reputacional altoFlujo típico

Exploraren Civitai/HF →Descargarmodelo + LoRAs →Cargaren ComfyUI →Crear workflow(text → img, con ControlNet si necesitas control) →Automatizarvía API de ComfyUI o Replicate para integrar en tu app.

109Técnicas de control: ControlNet, IP-Adapter y más

Generar imágenes “a ver qué sale” es divertido. En producción, necesitascontrol precisosobre la composición, la pose, el estilo y los detalles.

Técnicas principales

ControlNet

Guía la generación con una imagen de referencia: bordes (canny), profundidad (depth), pose humana (OpenPose), mapa de normales. El modelo respeta la estructura de la referencia

IP-Adapter

Transfiere el estilo de una imagen de referencia sin copiar la composición. “Genera algo nuevo pero con este estilo/ambiente”. Muy útil para consistencia de marca

Inpainting / Outpainting

Inpainting: repintar una zona específica de la imagen (borrar objeto, cambiar fondo). Outpainting: extender la imagen más allá de sus bordes originales

Upscaling

Ampliar resolución sin perder calidad. ESRGAN, 4x-UltraSharp, Tile ControlNet. De 512x512 a 2048x2048 con detalle añadido

Tipos de ControlNet

TipoInput de referenciaCaso de usoCannyBordes detectados de una imagenMantener la composición exacta, redesign de interfacesDepthMapa de profundidadMantener la perspectiva y distancias entre objetosOpenPoseEsqueleto de pose humanaControlar la postura exacta de personasScribbleDibujo a mano alzadaConvertir bocetos rápidos en imágenes detalladasTileImagen a baja resoluciónUpscaling con añadido de detalle inteligente### Cómo se rompe el control

TécnicaRiesgoControl prácticoControlNetFuerza demasiada estructura y mata estilo o naturalidadAjustar weight/start/end y probar varias seedsIP-AdapterCopia más identidad de la deseadaRevisar derechos y bajar fuerza de referenciaInpaintingCosturas visibles o sombras inconsistentesMáscara con margen, denoise adecuado y revisión a resolución finalUpscalingInventa textura o detalles falsosComparar antes/después y no usarlo para evidencia documentalPara integrar en apps

ComfyUI expone unaAPI REST. Puedes crear un workflow complejo (ControlNet + LoRA + upscaling), guardarlo como JSON, y llamarlo desde tu backend. Replicate y fal.ai ya tienen modelos con ControlNet preconfigurados como endpoints API.

110¿Cómo se crea un modelo frontier?

1. **Datos, tokenizer y filtrado:**deduplicar, limpiar, clasificar licencias, quitar PII/secrets y decidir cómo partir texto en tokens. Esta fase define buena parte de lo que el modelo podrá aprender.
2. **Pre-training:**billones de tokens, semanas de entrenamiento en miles de GPUs. El modelo aprende patrones prediciendo tokens en texto, código e inputs multimodales. Suele consumir la mayor parte del compute.
3. **SFT:**Supervised Fine-Tuning. Ejemplos curados de instrucción/respuesta para enseñar formato, estilo, seguimiento de instrucciones y tareas conversacionales.
4. **Preferencias y refuerzo:**RLHF/RLAIF entrenan o usan señales de recompensa. DPO (Direct Preference Optimization) aprende de pares preferido/rechazado sin reward model explícito. GRPO (Group Relative Policy Optimization) es una receta de RL que evita critic/value model en algunos entrenamientos, pero no es “DPO con otro nombre”. RFT/RLVR refuerzan tareas verificables con graders o tests.
5. **Safety, evals y red-teaming:**benchmarks públicos, evals privadas, pruebas adversariales, políticas de seguridad y análisis de regresiones antes de abrir el modelo.
6. **Serving y monitorización:**optimizar inferencia, medir coste/latencia, observar abuso, alucinaciones y regresiones, y preparar rollback o cambios de modelo.

Coste

Decenas a cientos de millones de dólares por modelo frontier, según estimaciones públicas de compute, datos y personal. Solo unas pocas organizaciones pueden permitirse entrenar modelos de frontera desde cero.

Moats (ventajas competitivas)

Datos, compute (GPUs), talento investigador, infraestructura de entrenamiento. Es una carrera de capital. Los clusters de entrenamiento ya superan las 100.000 GPUs.

Datos + tokenizer→Pre-train→SFT→Preferencias / RL→Evals + safety→Deploy + monitorización

Qué se optimiza en cada fase

FaseMétrica dominanteError caroPre-trainingLoss, calidad de datos, cobertura de dominios, eficiencia de computeEntrenar semanas con datos duplicados, contaminados o mal filtradosPost-trainingSeguimiento de instrucciones, safety, tool use, preferencias humanasUn modelo capaz que responde de forma inútil o inseguraRazonamiento/RLVRPasar tests, graders verificables, benchmarks de código/matemáticasOptimizar estilo de razonamiento sin mejorar la soluciónServingCoste/token, latencia, disponibilidad, regresionesUn modelo excelente que no cabe en el producto

111Hugging Face: leer una model card

Hugging Face es el registro de referencia para modelos abiertos. Unamodel cardbien leída evita tres errores clásicos: descargar un modelo que no puedes ejecutar, incumplir una licencia o comparar benchmarks que no significan lo mismo.

Anatomía de una ficha de modelo

CampoQué mirarPregunta prácticaArquitecturaDenso, MoE, multimodal, nº capas, heads, expertos¿Mi motor lo soporta?ParámetrosTotal vs activos, hidden size, context length¿Cabe? pesos + KV cache + margenLicenciaApache, MIT, Llama, research, comercial¿Puedo usarlo en mi producto?Base modelBase, instruct, fine-tune, adapter, merge, quantized¿Estoy usando el modelo correcto?Datos/evalsDatasets, benchmarks, idiomas, limitaciones¿Sirve para mi dominio?Filessafetensors, GGUF, GPTQ (GPT Quantization), AWQ (Activation-aware Weight Quantization), FP8¿Qué runtime necesito?### Red flags al leer una model card

SeñalPor qué preocupaQué hacerNo hay licencia claraRiesgo legal y de redistribuciónNo usar en producto hasta revisar LICENSE y términosBenchmarks sin setupNo sabes prompt, tools, temperatura ni scaffoldReproducir con tu eval pequeñaSolo ejemplos bonitosMarketing, no evidenciaBuscar limitaciones, issues y evals externasQuantización sin basePuede venir de un tercero con pérdida o erroresVerificar procedencia, hash, runtime y calidad

112¿Cabe en RAM/VRAM? ejemplo de cálculo

Para inferencia local no basta con mirar “7B” o “70B”: el formato de pesos, el tamaño de contexto y la KV cache pueden cambiar completamente la memoria necesaria.

Fórmula aproximada

ParteCálculoPesosparams\_totales x bits / 8KV cache2 x capas x tokens x kv\_heads x head\_dim x bytesAtajo2 x capas x tokens x hidden\_size x bytesMoEtotales para memoria; activos para coste/tokenTotalpesos \+ KV \+ 10\-30%

Ejemplo 7B Q4

ElementoResultadoLecturaPesos Q4~3.5 GB7B x 4 / 8KV 4k FP16~2.1 GB32 capas, hidden 4096Total 4k~6.3-7.3 GBCon margen runtimeKV 128k~67 GBEl contexto domina

Sensibilidad del contexto

VariableImpactoControlContext lengthLa KV cache crece casi linealmente con tokens y batchNo activar 128k/1M si no hace faltaBatch/concurrenciaMás usuarios multiplican KV y buffersReservar margen y limitar máximo por requestMoETotal manda en memoria; activos mandan en FLOPs por tokenLeer total/active params y formato realQuantizaciónBaja pesos, no siempre baja KV cacheMedir calidad y memoria real con el runtime elegido

113Elegir fichero: safetensors, GGUF, GPTQ/AWQ

La model card puede tener varios ficheros para el mismo modelo. Elegir mal el formato es una de las causas más comunes de “lo he descargado pero no arranca”.

Elegir fichero: safetensors vs GGUF vs GPTQ/AWQ

GPTQ = GPT Quantization. AWQ = Activation-aware Weight Quantization. Ambos son formatos de quantización post-training pensados para reducir memoria y acelerar inferencia, con distinta compatibilidad por runtime.

Servir / fine-tune

safetensorsmantiene pesos completos o FP8/BF16. Es el formato natural para Transformers, vLLM, SGLang y entrenamiento. Requiere GPU y más memoria.

BF16/FP8vLLMSGLang

Local / escritorio

GGUFempaqueta pesos, tokenizer y metadata para llama.cpp, Ollama y LM Studio. Q4_K_M para empezar; Q5/Q6/Q8 si necesitas más fidelidad.

GGUFOllamaLM Studio

Checklist antes de descargar

1) licencia; 2) contexto; 3) idioma/dominio; 4) total y activo si es MoE; 5) formato compatible; 6) quantización; 7) benchmarks con metodología comparable; 8) riesgos declarados en la model card. Si falta alguno, trátalo como incertidumbre, no como verdad.

LM Studio y Ollama son la vía rápida para probar localmente. Hugging Face es la fuente para verificar procedencia, licencia, arquitectura y variantes quantizadas.

114Caso real: leer DeepSeek-V4 en Hugging Face

Una ficha real condensa arquitectura, licencia, formatos, contexto, modos de razonamiento y benchmarks. DeepSeek-V4-Pro y DeepSeek-V4-Flash sirven como ejemplo porque muestran casi todos los términos que vas a encontrar en modelos frontier open weights.

Qué dice la ficha

ElementoLectura correctaImplicación prácticaTagsText Generation, Transformers, Safetensors, conversational, Eval Results, 8-bit, fp8Se puede descubrir por tarea, librería, formato y precisiónLicenciaMITPermisiva, pero revisa siempre LICENSE y condiciones del proveedor de inferenciaArquitecturaPro: MoE 1.6T total / 49B activos. Flash: MoE 284B total / 13B activosLa familia separa capacidad máxima y coste por token; compara total, activos y setupContext length1M tokens en Pro y FlashÚtil para repos/docs enormes; no significa que debas meterlo todo siemprePrecisiónFP4 + FP8 mixed en las versiones instructMenos memoria y FLOPs; comparar con BF16 requiere entender la quantizaciónRuntimeTransformers, vLLM, SGLang, Docker Model RunnerLa ficha te dice cómo servirlo; LM Studio/Ollama suelen requerir quantizaciones aparteTrampa común

El panel lateral puede mostrar “model size” distinto al número arquitectónico anunciado, porque cuenta tensores disponibles en ese repo, tipos de tensor y empaquetado. Para MoE, lee siempretotal paramsyactivated paramsen la card.

Lectura en 5 preguntas

PreguntaPor qué importa¿Qué repo exacto estoy leyendo?Pro, Flash, base, instruct y quantized pueden tener capacidades distintas.¿Qué licencia y términos aplican?MIT, Apache, Llama o comercial cambian uso, redistribución y producto.¿Qué runtime recomienda la ficha?Un modelo puede existir en HF y aun así no funcionar bien en tu stack local.¿Qué evals son comparables?Modo de razonamiento, tools y presupuesto pueden mover mucho el resultado.¿Qué coste operativo implica?Total params, activos, precisión y contexto deciden memoria y latencia.

115DeepSeek-V4: etiquetas, licencia y runtime

Una model card está escrita para gente técnica. El objetivo es traducir cada campo a una decisión:qué puedo hacer, con qué herramienta y qué debo comprobar.

TérminoSignificaCómo leerlo en la prácticaTagsEtiquetas de búsqueda en Hugging Face: tarea, librería, formato, modo de uso y evals.Sirven para encontrar modelos y filtrar, pero no sustituyen leer la ficha.Text GenerationEl modelo genera texto token a token.Vale para chat, resumen, código o agentes; no implica por sí solo visión/audio.Transformers/safetensorsLibrería compatible / formato seguro para guardar pesos.Buena señal para servir con Transformers, vLLM o SGLang; no significa que quepa en local.conversational/Eval ResultsPreparado para conversación / publica resultados de benchmarks.Revisa chat template y setup de evaluación antes de comparar.Licencia MITPermisiva: normalmente permite uso comercial, copia, modificación y distribución.RevisaLICENSE, model card y condiciones del proveedor de inferencia.RuntimeSoftware que carga y sirve el modelo: Transformers, vLLM, SGLang, Docker Model Runner...La card indica el camino de despliegue; LM Studio/Ollama suelen requerir GGUF u otra quantización.Lectura segura

Trata cada tag como una pista, no como una garantía. La garantía práctica sale de ejecutar el modelo con el runtime indicado, una muestra de tus datos y una eval pequeña con coste y latencia.

116DeepSeek-V4: arquitectura, contexto y precisión

Estos términos explican por qué un modelo puede ser enorme en capacidad, razonable por token y aun así imposible de ejecutar en un portátil.

TérminoSignificaCómo leerlo en la prácticaMoEMixture of Experts: muchos expertos guardados; el router elige algunos por token.Más capacidad total sin usar todo el modelo en cada paso.Total vs activosTotal = pesos almacenados. Activos = pesos usados por token.Total afecta a RAM/VRAM; activos afecta a coste, latencia y FLOPs.Pro vs FlashPro prioriza capacidad; Flash prioriza coste/latencia.No compares solo el nombre: compara total, activos, contexto, precisión y eval setup.Context length 1MLímite máximo de tokens: prompt, historial, docs, tools y respuesta.Útil para repos/docs enormes, pero aumenta KV cache, coste y latencia.FP4 + FP8 mixedPesos en 4/8 bits de coma flotante; mixed = distintos tensores usan distinta precisión.Menos memoria y FLOPs que BF16/FP16; verifica calidad, hardware y runtime.### Fórmula de lectura MoE

ValorÚsalo para estimar...Parámetros totales × bitsMemoria para pesos si cargas el modelo completo.Parámetros activosCompute aproximado por token y latencia relativa.Context lengthKV cache, coste de input y necesidad de retrieval/segmentación.PrecisiónCompatibilidad de hardware y posible degradación de calidad.

117Glosario Hugging Face: términos que aparecen en una model card

Antes de descargar un modelo, hay que traducir la ficha a decisiones de ingeniería. Este glosario convierte términos frecuentes en preguntas concretas.

TérminoSignificadoPregunta que debes hacerBaseModelo pre-entrenado sin alineamiento conversacional fuerte¿Lo usaré para fine-tune o investigación?Instruct / ChatModelo post-entrenado para seguir instrucciones y dialogar¿Lo necesito para asistentes, agentes o API de chat?Fine-tuneDerivado entrenado sobre un dominio o estilo concreto¿Qué dataset lo especializó y qué perdió por el camino?Adapter / LoRAPesos pequeños que modifican un modelo base¿Tengo el base model exacto compatible?MergeCombinación de varios modelos o adapters¿Está documentado el origen y la licencia de cada parte?QuantizedPesos reducidos a menos bits: INT8, INT4, FP8, GGUF Q4...¿Acepto la pérdida de calidad por memoria/velocidad?SafetensorsFormato seguro y rápido para tensores, alternativa a pickle¿Voy a servirlo con Transformers, vLLM o SGLang?GGUFFormato con pesos + metadata para llama.cpp/Ollama/LM Studio¿Quiero correrlo localmente en CPU/GPU de escritorio?GatedModelo que requiere aceptar condiciones o pedir acceso¿Puedo automatizar despliegue y CI con ese requisito?Chat templateFormato exacto de roles, tokens especiales y delimitadores¿Mi runtime enviará prompts en el formato correcto?Pregunta de examen

Si una ficha dice “Instruct, GGUF, Q4_K_M, gated, chat template”, el alumno debe poder explicar qué cambia en uso, memoria, licencia, runtime y formato de prompt.

118Benchmarks en Hugging Face: cómo leer métricas

Las fichas modernas ya no solo dicen “somos buenos”: publican resultados estructurados. Hugging Face muestra evals en la card y puede enlazarlas con leaderboards de datasets benchmark.

Métricas frecuentes

MétricaQué significaEjemploCuidado conEMExact Match: respuesta idéntica a la esperadaMMLU, AGIEvalPenaliza equivalencias válidas si el formato cambiaPass@1Un intento; cuenta si la primera solución pasaHumanEval, LiveCodeBench, GPQANo compara bien con sistemas multi-rolloutResolvedEl issue queda resuelto según tests/harnessSWE-bench Verified, SWE ProDepende mucho del agente, herramientas y presupuestoAccAccuracy: proporción de aciertosTerminal Bench, CorpusQAPuede ocultar dificultad por subgrupoF1Balance precisión/recallDROP, extracciónÚtil cuando hay respuestas parcialesElo / ratingRanking relativo por comparacionesGDPval-AA, CodeforcesNo es porcentaje; depende del pool comparado### Nombres de benchmarks que verás en fichas como DeepSeek-V4

CategoríaBenchmarks típicosQué intentan medirConocimientoMMLU, MMLU-Pro, MMMLU, C-Eval, CMMLU, SimpleQA, HLE, GPQAPreguntas académicas, factualidad, ciencia, cultura general, razonamiento cerradoCódigo y matemáticasHumanEval, BigCodeBench, LiveCodeBench, Codeforces, GSM8K, MATH, HMMT, IMOAnswerBenchProgramación autocontenida, competición, cálculo, problemas matemáticos formalesContexto largoLongBench-V2, MRCR 1M, CorpusQA 1MRecuperar y razonar sobre información enterrada en cientos de miles o millones de tokensAgentes y herramientasTerminal Bench, SWE-bench Verified/Pro/Multilingual, BrowseComp, HLE w/ tools, MCP-Atlas, Tool Decathlon, GDPval-AAUso de terminal, navegación, herramientas, resolución de issues y tareas multi-paso### Campos de un resultado HF

dataset/task_ididentifica el benchmark exacto;split/revisionfija la versión evaluada;verified/community/sourceindica procedencia;notesdebería explicar setup: tools/no-tools, thinking mode, temperatura, presupuesto y scaffold.

Lectura profesional de un benchmark

PreguntaPor qué importa¿El resultado es del modelo o de un agente con herramientas?SWE-bench mide sistema completo: modelo, scaffold, editor, terminal, tests y presupuesto.¿Hay contaminación de datos?Si el benchmark apareció en training data, el resultado puede sobreestimar generalización.¿Se reporta coste?Un score alto con 100 intentos o mucho reasoning puede no ser viable en producción.¿Tu tarea se parece?Un modelo excelente en matemáticas puede ser mediocre en soporte, legal o español técnico.Regla de lectura

Un benchmark sin setup no es una conclusión: es una pista. En DeepSeek-V4-Pro, por ejemplo, “SWE Verified 80.6 resolved” solo es interpretable si sabes modo de razonamiento, agente, herramientas, coste y versión del benchmark.

119Cómo mantenerse actualizado sin comprar humo

El estado del arte cambia cada pocas semanas. La habilidad profesional no es memorizar nombres: es tener un método para decidir qué merece confianza.

Orden de confianza

FuenteQué aportaQué mirarDocs oficialesModel IDs, límites, pricing, API realFecha, snapshots, deprecations, contexto, output, toolsModel cardsArquitectura, licencia, pesos, evalsTotal/activos, formato, licencia, benchmarks con setupPapers / tech reportsDetalles de entrenamiento y evaluaciónDataset, ablations, limitaciones, reproducibilidadLeaderboardsComparación rápidaSplit, scaffold, coste, herramientas y fechaTu eval internaSi mejora tu producto realCasos de tu repo, coste por tarea y revisión humanaRegla práctica

Si una afirmación no tiene versión, fecha, setup y fuente, no la pongas en producción. Apúntala como hipótesis y pruébala.

Plantilla mínima de experimento

CampoEjemploHipótesis“RAG híbrido sube recall@5 del 70% al 85% sin duplicar coste”.BaselinePrompt actual + modelo actual + dataset fijo.Cambio únicoSolo cambiar reranker, chunking o modelo; no todo a la vez.Criterio de paradaAdoptar, iterar o descartar con umbral definido antes.

120Matriz rápida: qué modelo usar

No hay un modelo correcto para todo. La decisión combina calidad, latencia, coste, privacidad, tools, contexto y riesgo.

NecesidadPrimera opciónAlternativa eficientePor quéFeature compleja / refactorClaude Opus 4.7, GPT-5.5Sonnet 4.6, GPT-5.4Razonamiento, tools, contexto largoCódigo repetitivoGPT-5.4 mini, HaikuQwen3.6, DeepSeek-V4-FlashCoste bajo, suficiente calidadOpen weights / privacidadQwen3.6, DeepSeek-V4, Mistral 3gpt-oss-120b/20bPesos descargables, control de infraestructuraContexto enormeClaude/Gemini/GPT con 1M+DeepSeek-V4, Qwen3.6 YaRNSeparar context window de recuperación realMultimodal / docs visualesGemini, GPT, Claude Opus 4.7Qwen3.6, Mistral Medium 3.5Verifica modalidad exacta por APIExperimentos baratosColab + HF notebooksOllama/LM Studio localIteración rápida antes de gastar en producciónDecisión adulta

Elige porcoste por tarea resuelta, no por ranking global. Un modelo peor en leaderboard puede ganar si resuelve tu caso con menos tokens, menos latencia y menos fallos operativos.

Fórmula de compra

FactorIncluyeCalidad aceptada% de casos que pasan eval + revisión humana necesaria.Coste realInput, output, reasoning, herramientas, reintentos y caching.RiesgoPrivacidad, vendor lock-in, cambios de modelo y compliance.OperaciónTimeouts, rate limits, observabilidad, fallback y soporte.

121Mini-lab: decidir si una model card sirve

Ejercicio para clase: abrir una ficha de Hugging Face y tomar una decisión de ingeniería en 10 minutos.

Protocolo de 10 minutos

MinutoPreguntaSalida esperada0-2¿Qué tipo de modelo es?Base/instruct, denso/MoE, texto/visión/audio, contexto2-4¿Puedo usarlo legalmente?Licencia, gated access, uso comercial, modelo base4-6¿Cabe en mi entorno?Formato, quantización, VRAM/RAM, runtime compatible6-8¿Los benchmarks se parecen a mi caso?Dataset, split, scaffold, herramientas, coste8-10¿Cuál es el siguiente experimento?Notebook, prompt set, eval pequeña, criterio de éxitoEntregable

Una ficha de decisión:usar / no usar / probar, con 3 razones y un experimento reproducible. Si no puedes escribir eso, aún no entiendes la model card.

Rúbrica rápida

NotaCriterioVerdeLicencia clara, formato compatible, cabe en memoria y eval parecida al caso.AmarilloPromete mucho pero faltan setup, runtime o pruebas con tus datos.RojoNo hay licencia, no hay model card, benchmarks opacos o requiere hardware inviable.

122Google Colab: probar experimentos sin instalar nada

Colab es ideal para clase y prototipos: notebooks Jupyter en la nube, sin setup local, con acceso a GPU/TPU sujeto a disponibilidad. Perfecto para probar ideas antes de convertirlas en código de producción.

Qué probar en Colab

ExperimentoNotebook buenoQué aprendesInferencia HFTransformers quicktour:pipeline, tokenizer y modeloModelo ≠ tokenizer;dtype, GPU, batch ymax\_new\_tokensmueven memoria, coste y latencia.Fine-tuning pequeñoTrainer + PEFT/LoRA con train/validationDataset, epochs, learning rate, checkpoints, métrica y señales de overfitting.RAG mínimoEmbeddings + Chroma/FAISS + prompt con citasChunk size, overlap ytop\_kcambian el recall; grounding = responder desde evidencia.Imagen/difusiónDiffusers o ComfyUI variando seed, sampler, CFG y stepsVRAM vs resolución/batch; seed reproduce; CFG/sampler/steps cambian calidad y tiempo.Eval propiaCSV/JSONL con input, expected, rúbrica y judgePasas de demo subjetiva a medición: acierto, coste, latencia y decisión.Primeras celdas obligatorias

Siempre empieza registrando GPU/CPU, memoria, versiones, modelo exacto, seed y ruta del dataset. Si no puedes reproducir el entorno, no puedes comparar resultados.

123Google Colab: límites y disciplina de laboratorio

Colab no es producción: es un laboratorio reproducible. El objetivo no es que “funcione una vez”, sino que otra persona pueda ejecutar, medir y decidir. El alumno debe controlar estos límites:

LímiteQué significaCómo se gestionaRuntime temporalLa VM puede cerrarse por idle o límite de vida.Guardar outputs, checkpoints, datasets yrequirements\.txt.GPU/TPU variableTipo de GPU, VRAM y disponibilidad cambian por plan y demanda.Anotar hardware,dtype, batch, resolución y tiempo por caso.Secretos y datosUn notebook compartido puede filtrar tokens o datos sensibles.Usar variables/secretos, anonimizar ejemplos y no publicar credenciales.ReproducibilidadCeldas ejecutadas fuera de orden dan resultados imposibles de repetir.ProbarRun all, fijar seeds, versiones, modelo y snapshot del dataset.Dependencias vivasUnpip installsin versión puede cambiar el resultado mañana.Fijar versiones críticas y guardarrequirements\.txto lockfile.Entregable de un buen Colab

Notebook que corre limpio de arriba abajo, inputs versionados, outputs guardados, coste/latencia/métrica anotados y conclusión explícita: usar, iterar o descartar.

124Qué hace bueno a un experimento con IA

Un buen experimento no es una demo bonita. Es una prueba pequeña, reproducible y falsable que te ayuda a decidir el siguiente paso.

Checklist de experimento bueno

ElementoBuenoMaloHipótesis“Qwen3.6 resuelve extracción JSON con <2% error”“Vamos a probar IA”Datos20-100 casos reales, versionados, sin filtrar solo éxitos3 prompts escogidos a manoMétricaExactitud, coste, latencia, fallos, revisión humana“Parece mejor“ReproducibilidadNotebook limpio, seeds, versiones, requirements, outputs guardadosCeldas ejecutadas fuera de ordenDecisiónAdoptar, descartar o iterar con criterioSeguir probando indefinidamenteDel Colab a producción

Cuando un notebook funciona, conviértelo en script, fija dependencias, añade tests, registra prompts/modelos y llévalo a una eval interna. El notebook es laboratorio; producción necesita disciplina de software.

125Repos Colab para practicar sin partir de cero

Para aprender, empieza por notebooks mantenidos por proyectos de referencia. Antes de ejecutarlos, mira fecha, licencia, dependencias, GPU requerida y si el notebook pide tokens.

ExperimentoRepo / Colab buenoQué tocarInferencia HFHF Transformers quicktourpipeline, tokenizer, modelo, device, batch y precisión (dtype).Fine-tuningHF Trainer+PEFT/LoRASplit train/validation, epochs, LR, checkpoint, overfitting y métrica.RAG mínimoLangChain RAG From ScratchChunking, embeddings, vector store,top\_k, grounding y citas.Imagen/difusiónHF Diffusers introSeed, scheduler/sampler, steps, resolución, batch y VRAM.Eval propiaOpenAI Cookbook evals+HF EvaluateCSV/JSONL de casos, expected, rúbrica, juez, coste y regresiones.Regla de seguridad

No ejecutes notebooks aleatorios con tus tokens. Lee el README, instala dependencias explícitas, guarda una copia propia y copia a producción solo el código que entiendes.

126Evals internas: de notebook a criterio de compra

Un benchmark público te orienta; una eval interna decide. La eval debe parecerse al trabajo real que quieres automatizar.

Flujo mínimo

20-100 casos reales→Prompt/modelo fijo→Ejecución reproducible→Métricas + coste→Revisión humana

CampoEjemploPor qué importaInputTicket real, diff, documento, capturaEvita demos irrealesExpectedJSON válido, patch que pasa tests, resumen correctoDefine éxito antes de mirar resultadosJudgeTests, schema, heurística, LLM-as-judge, humanoNingún juez único cubre todoBudgetMáx. tokens, tiempo, llamadas a toolsControla coste y comparabilidadDecisionAdoptar si supera baseline + no sube coste >20%Convierte medición en acciónMétrica de verdad

Midecoste por tarea aceptada: tokens + latencia + herramientas + revisión humana + retrabajo. Ese número suele cambiar decisiones que un leaderboard no ve.

Si usas LLM-as-judge

ControlMotivoEjemplos anclaCalibran qué es bueno, malo y dudoso.Blind judgingOculta el nombre del modelo para reducir sesgo.Auditoría humanaMuestrea decisiones del juez y mide acuerdo.Tests deterministasSiempre que puedas, una prueba ejecutable vale más que opinión textual.

127Errores comunes al probar modelos

La mayoría de malas decisiones no vienen de usar un modelo flojo, sino de probarlo mal.

ErrorQué pasaCorrecciónProbar solo casos fácilesEl demo parece mágicoIncluye edge cases, datos sucios y ejemplos fallidosCambiar prompt y modelo a la vezNo sabes qué mejoróUn cambio por experimentoNo fijar versionesEl resultado cambia semanas despuésSnapshot/model ID, librerías y dataset versionadosIgnorar coste/latenciaFunciona, pero no escalaRegistra tokens, tool calls y tiempo por casoUsar LLM judge sin calibrarEl juez premia estilo, no verdadMezcla tests, schema, ejemplos ancla y revisión humanaConfundir Colab con producciónDependencias, secrets y runtimes se rompenPasa a script/CI cuando el experimento funcioneSeñal de madurez

Un experimento bueno puede demostrar que una ideanomerece seguir. Eso ahorra más dinero que una demo espectacular.

Post-mortem de experimento

PreguntaRespuesta que debe quedar escrita¿Qué hipótesis probamos?Una frase medible, no “probar IA”.¿Qué aprendimos?Mejora, empeora o incertidumbre con datos.¿Qué haríamos distinto?Próximo cambio único o decisión de parar.¿Qué coste tuvo?Tiempo humano, tokens, GPU, revisión y retrabajo.

128RAG (Retrieval Augmented Generation)

**Problema:**el modelo no accede por sí solo a tus datos internos (documentación, BD, wikis). Su conocimiento viene del entrenamiento y del contexto que le das en la petición.

**Solución:**en vez de reentrenar el modelo, le pasas contexto relevante en cada consulta.

Ingesta + chunking→Embeddings + índice→Retrieval / rerank→Contexto con citas→Respuesta o no-answer

Componentes clave

Documentos fuente

PDFs, wikis, código, bases de datos, cualquier texto que quieras consultar

Chunking

Dividir documentos en fragmentos de 500-1000 tokens con solapamiento

Embeddings

Convertir cada fragmento en un vector numérico que captura su significado

Vector DB + reranker

Almacena vectores, recupera candidatos y puede reordenarlos por relevancia antes de responder

Métricas de retrieval

MétricaFórmula mentalQué te diceRecall@k¿El chunk correcto aparece entre los top-k?Si el retrieval encuentra evidencia suficienteMRRMedia de1 / posición\_del\_primer\_relevanteSi lo relevante aparece pronto o enterradoGroundednessRespuesta soportada por citas recuperadasSi el generador respeta la evidenciaNo-answer accuracyAcertar cuando no hay evidenciaReduce respuestas inventadasCalidad mínima

Un RAG serio muestra citas, conserva metadatos, sabe decir “no hay evidencia suficiente” y mide retrieval por separado de la generación. Si solo pega chunks al prompt, es una demo, no una base fiable.

Flujo RAG en código (simplificado)

constchunks = splitIntoChunks(document,512); constvectors =awaitembed(chunks); awaitvectorDB.upsert(vectors);

constqueryVec =awaitembed(userQuestion); constrelevant =awaitvectorDB.search(queryVec, { topK: 5 });

constresponse =awaitllm.generate({ system:“Responde usando SOLO el contexto dado.”, context: relevant.map(r => r.text).join(“\n”), question: userQuestion });

RAG vs fine-tuning

• **RAG:**para datos propios que cambian frecuentemente. Sin coste de reentrenamiento. Fuentes citables.
• **Fine-tuning:**para cambiar el estilo o comportamiento del modelo. Los datos se “hornean” en los pesos.

129Agentic RAG: la evolución del retrieval

El RAG básico (slide anterior) busca, inyecta y genera.Agentic RAGañade razonamiento: el agente decidequé buscar, cómo buscarlo, y si el resultado es suficiente.

RAG básico vs agentic RAG

RAG básico

Pregunta → embedding → buscar los K fragmentos más similares → inyectar en el prompt → generar. Un solo paso, sin reflexión.

Un solo pasoSin iteración

Agentic RAG

El agente razona sobre la pregunta, descompone en sub-preguntas, busca en múltiples fuentes, evalúa si los resultados son suficientes, y reintenta si no lo son.

Multi-pasoAuto-corrección

Patrones de agentic RAG

Query decomposition

Una pregunta compleja se divide en sub-preguntas. Cada una se busca por separado y los resultados se combinan

Retrieval con re-ranking

Buscar amplio (top-20), luego un modelo re-rankea los resultados por relevancia real. Elimina falsos positivos del embedding

Self-reflection

Tras generar la respuesta, el agente evalúa: “¿He respondido con los datos recuperados? ¿Necesito buscar más?” Si no está satisfecho, itera

Multi-source

Buscar en vector DB + SQL + API + web simultáneamente. Combinar resultados de fuentes heterogéneas

Coste de hacer RAG “agente”

BeneficioCoste añadidoControlMejor cobertura en preguntas multi-hopMás llamadas, más tokens y más latenciaPresupuesto máximo de búsquedas y pasosPuede reformular queriesRiesgo de desviarse de la pregunta originalGuardar plan, queries y evidenciasValida suficiencia del contextoUn judge LLM puede equivocarseRúbrica + ejemplos ancla + no-answerBusca en varias fuentesPermisos y freshness más difícilesACLs por fuente y timestamps en metadataCuándo pasar de RAG básico a agentic

RAG básico basta para preguntas simples sobre un corpus homogéneo. Agentic RAG merece la pena cuando: las preguntas son complejas (multi-hop), los datos están en múltiples fuentes, o la calidad del retrieval básico no es suficiente.

130GraphRAG y estrategias avanzadas de retrieval

Más allá de buscar fragmentos similares: estrategias que combinangrafos de conocimiento, búsqueda híbrida y contexto enriquecido.

Estrategias de retrieval (de simple a avanzado)

EstrategiaCómo funcionaCuándo usarlaVector searchEmbedding de la query, buscar los K más similaresCorpus homogéneo, preguntas directasHybrid searchVector search + BM25 (ranking lexical por palabras clave). Fusiona resultadosCuando las keywords importan (nombres, IDs)Contextual retrievalUn LLM añade contexto a cada chunk antes de indexarChunks que pierden sentido fuera de contextoGraphRAGGrafo de entidades y relaciones. Busca por conexionesPreguntas que cruzan múltiples documentos### Flujo de GraphRAG

Documentos→Extraer entidades→Construir grafo→Buscar por relaciones→Respuesta con contexto rico

RAG, KG y GraphRAG no son lo mismo

TécnicaUnidad principalPregunta que resuelve mejorRAG vectorialChunk textual“¿Qué documentos se parecen a esta pregunta?”Knowledge graphEntidad y relación explícita“¿Qué relación exacta existe entre A y B?”GraphRAGEntidades, comunidades y evidencias textuales“¿Qué explicación emerge al conectar varios documentos?”OntologíaClases, propiedades y restricciones“¿Qué está permitido o inferido por el modelo del dominio?”¿Cuál elegir?

**Empieza con vector search.**Si no basta, añade hybrid search (trivial en Pinecone, Weaviate). Si los chunks pierden contexto, usa contextual retrieval. GraphRAG solo si necesitas respuestas que cruzan múltiples documentos y relaciones.

131RAG no es una ontología

RAG conecta generación con recuperación de contexto. Una ontología modela conocimiento formal del dominio. Pueden convivir, pero no son lo mismo.

RAG y ontologías resuelven problemas diferentes. RAG mejora la respuesta de un modelo aportando documentos relevantes; una ontología define qué conceptos existen, cómo se relacionan y qué reglas del dominio son válidas.

RAG recupera evidencia textual; una ontología define qué existe, cómo se relaciona y qué reglas del dominio son válidas.

Teoría aplicada

RAG recupera evidencia textual; una ontología define significado formal, tipos, relaciones y restricciones.

Fórmula / criterio

RAG: query -> top-k chunks -> respuesta. Ontología: tripletas + axiomas -> consulta/inferencia.

Ejemplo

Buscar políticas parecidas es RAG; comprobar si una factura viola una regla de dominio necesita estructura o validador.

Decisión

Si necesitas garantía relacional, no vendas vector search como conocimiento formal.

CapaQué guardaCómo respondeRAG vectorialchunks + embeddings + metadatasimilitud semántica y rerankingOntologíaclases, relaciones, restriccionesconsulta estructurada e inferenciaGraphRAGentidades, relaciones y comunidades derivadas de textorecuperación por grafo + resumenConfusiónLectura correcta“Tengo embeddings, tengo conocimiento”Tienes una representación útil para buscar parecido, no una teoría formal del dominio.“GraphRAG valida verdad”GraphRAG estructura recuperación; la verdad depende de fuentes, extracción y validación.“Una ontología responde en lenguaje natural”La ontología consulta y valida; el LLM puede explicar el resultado.

132Vector store: qué hace realmente

Una base vectorial no entiende el documento. Guarda vectores y devuelve fragmentos cercanos según una métrica.

Una base vectorial es una pieza de recuperación, no una fuente de verdad completa. Su calidad depende del chunking, del modelo de embeddings, de los filtros, del reranking y de si los fragmentos contienen evidencia suficiente.

La base vectorial es una estructura de búsqueda aproximada: su calidad depende de embeddings, chunking, metadata y evaluación.

Teoría aplicada

El vector store ordena por proximidad matemática, no por verdad, actualidad o permiso salvo que lo modeles.

Fórmula / criterio

cos(a,b)=a·b/(||a|| ||b||); top-k recupera vecinos cercanos en embedding space.

Ejemplo

Dos textos parecidos pueden contradecirse; metadata y fecha deciden cuál es válido.

Decisión

Evalúa retrieval con recall@k, precision@k, MRR y ejemplos con citas esperadas.

Documento→Chunks→Embeddings→Índice vectorial→Top-k fragmentos

Chunking

Decide qué unidades recuperas. Un mal corte rompe contexto.

Métrica

Coseno, dot product o distancia L2 cambian ranking.

Metadata

Filtros por fecha, fuente, usuario, permisos o tipo documental.

Rerank

Segundo paso para ordenar por relevancia más fina.

ParámetroEfectoSeñal de ajustechunk_sizeFragmentos grandes dan contexto; pequeños dan precisiónSube/baja recall@k y groundednessoverlapEvita cortar ideas entre chunksDemasiado overlap duplica coste y resultadostop_kMás candidatos suben recall y costeSi top_k alto no ayuda, el embedding o chunking fallafiltrosPermisos, fecha, idioma, clienteSin filtros puedes citar datos incorrectos

133Knowledge graph: entidades y relaciones

Un knowledge graph representa cosas del mundo y cómo se conectan. Es útil cuando la relación importa tanto como el texto.

Un knowledge graph da identidad y relación estable a las entidades. Es especialmente útil cuando necesitas seguir cadenas de dependencia, permisos, propiedad, causalidad declarada o auditoría de por qué algo se conecta con otra cosa.

El grafo no guarda “párrafos parecidos”; guarda identidad y relaciones consultables.

Teoría aplicada

El grafo conserva identidad y relaciones; por eso responde preguntas que no son solo “texto parecido”.

Fórmula / criterio

Tripleta RDF: sujeto - predicado - objeto; una consulta busca patrones de tripletas.

Ejemplo

cliente -> tieneContrato -> contrato -> caducaEn -> fecha permite trazabilidad exacta.

Decisión

Usa KG cuando la relación sea parte del producto, la auditoría o la regla.

ElementoEjemploValor prácticoEntidadCliente, contrato, productoidentidad estableRelacióncompra, pertenece_a, caduca_ennavegación y trazabilidadPropiedadfecha, importe, regiónfiltros exactosTipo/claseFactura, Persona, Riesgovalidación e inferenciaEjemplo

En soporte B2B, un vector store encuentra tickets parecidos. Un knowledge graph puede responder qué cliente pertenece a qué contrato, qué producto tiene activo y qué SLA aplica.

134RDF/OWL/SPARQL vs embeddings

Embeddings aproximan significado; RDF/OWL/SPARQL formalizan relaciones. El primero recupera parecido, el segundo consulta estructura.

Los embeddings toleran lenguaje ambiguo y paráfrasis; RDF, OWL y SPARQL exigen estructura. El diseño correcto empieza preguntando si el usuario necesita parecido textual o una relación exacta verificable.

Embeddings son probabilísticos y útiles para lenguaje; RDF/OWL/SPARQL son simbólicos y útiles para exactitud.

Teoría aplicada

Embeddings toleran ambigüedad; RDF/OWL/SPARQL exigen estructura y devuelven relaciones verificables.

Fórmula / criterio

Embedding: similitud(q,d). SPARQL: patrón { ?s ?p ?o } satisfecho o no satisfecho.

Ejemplo

“Documentos sobre cancelación” es vectorial; “contratos que vencen antes de 30 días” es estructurado.

Decisión

Elige aproximación para descubrir texto y estructura para compromisos verificables.

PreguntaMejor herramientaPor qué“Dame textos parecidos a este caso”Embeddingssimilitud semántica difusa“Qué medicamentos alivian fatiga”SPARQL / KGrelación exacta sujeto-predicado-objeto“Resume todo lo relevante”RAG + LLMgeneración con contexto recuperado“Comprueba si esta relación viola una regla”OWL/SHACL/reglasrestricción verificableTecnologíaUnidadGarantíaEmbeddingsvector densoparecido semántico aproximadoRDFtriple sujeto-predicado-objetorepresentación explícitaOWLclases, propiedades, axiomasinferencias y consistencia formalSPARQLpatrones de consultarespuesta exacta sobre un grafo

135GraphRAG como puente

GraphRAG usa estructura de grafo para recuperar contexto a nivel de entidades, relaciones o comunidades, no solo por chunks cercanos.

GraphRAG intenta combinar ambos mundos: extrae estructura de documentos y la usa para recuperar contexto más global. Pero esa estructura hereda errores de extracción, por lo que necesita evaluación y mantenimiento.

GraphRAG intenta mejorar preguntas globales y multi-documento, pero añade una fase crítica: extracción de entidades y relaciones.

Teoría aplicada

GraphRAG añade estructura al retrieval, pero la estructura extraída de texto también puede tener errores.

Fórmula / criterio

Documentos -> entidades -> relaciones -> comunidades -> contexto global/local.

Ejemplo

Una pregunta sobre una organización puede necesitar comunidad, entidades clave y fragmentos fuente.

Decisión

Mide extracción, relación, groundedness y actualización del grafo, no solo calidad de respuesta.

Documentos→Extracción de entidades→Relaciones→Comunidades→Retrieval + resumen

PasoRiesgoControlExtracción de entidadesduplicados y ambigüedadentity resolution y revisión de muestrasRelacionesaristas plausibles no evidenciadasguardar cita/origen por relaciónComunidadesresúmenes demasiado generaleseval con preguntas globales realesRespuesta finalmezclar evidencia débilcitas y nivel de confianzaLectura correcta

GraphRAG no convierte automáticamente texto en verdad formal. Extrae estructura útil, que debe evaluarse y mantenerse.

136Cuándo usar retrieval vectorial

Vectorial es buen punto de partida cuando trabajas con documentos largos, lenguaje natural y preguntas abiertas.

El retrieval vectorial suele ser la primera opción para documentación, tickets o correos porque el lenguaje real es desordenado. Funciona bien cuando la pregunta puede formularse de muchas formas y la evidencia vive en texto largo.

Empieza vectorial cuando el usuario no conoce las palabras exactas o el corpus está escrito en lenguaje natural.

Teoría aplicada

Lo vectorial brilla cuando la pregunta y el documento dicen lo mismo de formas distintas.

Fórmula / criterio

top-k + rerank + filtros = recuperación práctica más robusta que solo similitud.

Ejemplo

“No puedo entrar” puede recuperar documentos sobre autenticación aunque no usen esa frase literal.

Decisión

Empieza vectorial si el corpus es texto largo y la pregunta es abierta; añade estructura si falla por relaciones.

Texto no estructurado

PDFs, emails, tickets, documentación y notas.

Preguntas abiertas

El usuario no sabe exactamente cómo se llama lo que busca.

Paráfrasis

La consulta y el documento usan palabras distintas.

Time-to-value

Se prototipa rápido y permite medir utilidad pronto.

Señal de que funcionaSeñal de que no bastaEl chunk correcto aparece en top-5/top-10Recupera textos parecidos pero no evidenciasLas citas soportan la respuestaFalla con IDs, fechas, nombres exactos o permisosEl usuario reformula y encuentra lo mismoPreguntas multi-hop requieren combinar documentos

137Cuándo usar grafo semántico

Grafo semántico compensa cuando necesitas relaciones explícitas, trazabilidad, consultas exactas o reglas de dominio.

El grafo semántico merece la pena cuando las relaciones son parte del producto. Si preguntas por dependencias, cumplimiento, trazabilidad o reglas, la estructura explícita ofrece garantías que un ranking vectorial no da por sí solo.

Usa grafo cuando el coste de confundir entidades o relaciones es mayor que el coste de modelarlas.

Teoría aplicada

El grafo semántico aporta identidad, relaciones tipadas y razonamiento sobre reglas del dominio.

Fórmula / criterio

Consulta relacional: entidad A --relacion--> entidad B con filtros exactos.

Ejemplo

Dependencias de un servicio, permisos heredados o linaje de datos no deberían depender de parecido textual.

Decisión

Invierte en grafo cuando la trazabilidad reduzca riesgo operativo o regulatorio.

NecesidadPor qué grafo ayudaTrazar dependenciasnavegas relaciones explícitasPermisos y dominiosfiltras por entidad, clase o propiedadConsultas exactasSPARQL responde patrones concretosAuditoríapuedes enseñar la cadena de relacionesReglas de dominiopuedes validar restricciones fuera del LLMCriterio práctico

Si la pregunta contiene “quién depende de quién”, “qué permiso aplica”, “qué contrato cubre esto” o “qué regla se viola”, probablemente necesitas estructura, no solo similitud.

138Cuándo usar híbrido

En producción, la respuesta madura rara vez es “solo vector” o “solo grafo”. Lo habitual es combinar señales.

Lo híbrido no significa complicar por gusto. Significa usar cada señal donde aporta: keywords para términos exactos, embeddings para significado, grafos para relaciones y reglas para validar.

Híbrido significa usar cada índice para lo que sabe hacer: exactitud lexical, parecido semántico, relaciones y reglas.

Teoría aplicada

Híbrido significa separar señales: texto para evidencia, grafo para relación, reglas para garantías.

Fórmula / criterio

score final = retrieval semántico + filtros + rerank + validación determinista.

Ejemplo

Soporte técnico: vector encuentra el manual, KG localiza producto/version, reglas filtran permisos.

Decisión

Añade complejidad solo si una eval muestra que una señal sola no basta.

Patrón híbridoCómo funcionaCasoVector + metadatasimilitud con filtros exactosdocs por cliente, fecha o permisoBM25 + embeddingskeyword + semánticatérminos técnicos y paráfrasisKG + vectorentidades filtran, chunks explicanGraphRAG y soporte complejoRules + RAGvalidación determinista tras generacióncompliance, legal, finanzasFusiónQué decideRRF (Reciprocal Rank Fusion)Combina rankings lexicales y vectoriales sin calibrar scores directamenteReranker cross-encoderReordena candidatos mirando query y documento juntosFiltros por permisosElimina documentos antes de que el LLM pueda verlosReglas finalesComprueban que la respuesta no viole invariantes

139Errores al mezclar RAG y grafos

La arquitectura híbrida no arregla malos datos. Añade potencia, pero también puntos de fallo.

Mezclar técnicas aumenta superficie de fallo. Puedes recuperar la entidad correcta pero el chunk equivocado, tener relaciones antiguas o dejar que el LLM rellene huecos con inferencias no soportadas.

Cada capa nueva debe aportar una garantía nueva; si solo añade complejidad, empeora el sistema.

Teoría aplicada

Cada capa añade potencia y superficie de fallo: chunking, entidad, relación, permiso, generación.

Fórmula / criterio

Error total ~= error_retrieval + error_extraccion + error_actualizacion + error_generacion.

Ejemplo

El grafo recupera la entidad correcta pero el chunk citado pertenece a una versión antigua.

Decisión

Diseña tests de fallo, no solo demos felices: entidad ambigua, dato viejo, permiso y contradicción.

Chunking roto

El grafo recupera entidad, pero el chunk no tiene evidencia suficiente.

Entidades mal resueltas

“Apple” empresa y fruta acaban mezcladas.

Grafo desactualizado

La relación existe en el grafo pero ya no en el mundo.

Inferencia sin validación

El LLM une relaciones plausibles que no están soportadas.

Error operativoSíntoma en producciónPrevenciónACLs después del retrievalEl LLM ve datos que el usuario no debería verfiltrar antes de recuperar o inyectar contextoNo versionar índiceResultados distintos sin cambios de códigoversionar embeddings, corpus y pipelineGrafo sin freshnessResponde con relaciones caducadastimestamps, TTL y reindexaciónNo medir retrievalCulpas al LLM de un fallo de búsquedarecall@k, MRR y ejemplos negativos

140Qué debe saber: RAG, KG y ontologías

La decisión no es estética: depende de si buscas parecido textual, relación exacta, explicación trazable o restricción verificable.

La pregunta práctica es qué garantía necesitas. Si basta encontrar texto parecido, vectorial; si necesitas relación exacta, grafo; si necesitas explicación con evidencia, RAG evaluado; si necesitas reglas, validación simbólica.

Un buen sistema de conocimiento separa recuperación, estructura, reglas y generación.

Teoría aplicada

La arquitectura se elige por garantía requerida, no por moda.

Fórmula / criterio

Parecido -> vector; relación -> KG; reglas -> validador; explicación -> citas + trazas.

Ejemplo

Un asistente legal puede usar RAG para citar, KG para entidades y reglas para límites de jurisdicción.

Decisión

Pide siempre evidencia observable: chunk, tripleta, regla o tool log.

Si necesitas...Usa primero...Añade si...buscar texto parecidovector storererank y filtrosconsultar relaciones exactasknowledge graph / SPARQLontología si hay reglasresponder con citasRAGeval de groundednessrazonar sobre entidadesGraphRAGvalidación humana y datos frescosPregunta final

Antes de diseñar: ¿quiero encontrar evidencia, consultar una relación, validar una regla o redactar una explicación? La respuesta decide la arquitectura.

141¿Cuándo usar prompt, RAG o fine-tuning?

Las tres técnicas resuelven problemas diferentes. Elegir mal cuesta tiempo y dinero.

Prompt engineeringRAGFine-tuning**¿Qué cambia?La entrada al modeloEl contexto inyectadoLos pesos del modeloDatos propiosCaben en el prompt (<200k tokens)Cualquier volumen, búsqueda por similitudSe “hornean” en el modeloDatos cambiantesActualizas el promptActualizas los documentos indexadosRequiere reentrenarCoste inicialCeroMedio (embeddings + vector DB)Alto (compute, datos curados)Coste por peticiónSolo tokens del promptEmbedding + búsqueda + tokensSolo tokens (modelo ya ajustado)TrazabilidadNo cita fuentesPuede citar fragmentos exactosNo cita fuentesComplejidad**BajaMediaAlta### Árbol de decisión

¿Tus datos caben en el prompt?→Sí → Prompt engineering

¿Necesitas buscar en muchos docs?→Sí → RAG

¿Necesitas cambiar el estilo/tono?→Sí → Fine-tuning

Diagnóstico por síntoma

SíntomaPrimera intervenciónNo confundas con...El modelo no sabe una política internaRAG o herramienta que consulte la fuente vivaFine-tuning para memorizar documentos cambiantesDevuelve formato irregularStructured output + schema + ejemplosRAG, porque el problema no es conocimientoEl tono no encaja aunque sabe responderPrompt/few-shot; fine-tuning si escalaMeter más documentos irrelevantesFalla en tareas muy repetidas y carasEval + fine-tuning/destilación de modelo pequeñoUsar siempre frontier por inerciaNecesitas trazabilidadRAG con citas y no-answerFine-tuning, que no conserva fuentesRegla práctica

Empiezasiemprepor prompt engineering. Solo pasa a RAG cuando el contexto no cabe en el prompt o cambia frecuentemente. Solo haz fine-tuning si necesitas cambiar el comportamiento base del modelo (tono, formato, dominio muy específico).

142Fine-tuning: cuándo sí y cuándo no

Fine-tuningsignifica reentrenar parcialmente un modelo existente con ejemplos propios. No empiezas desde cero: partes de un modelo que ya sabe lenguaje, código y patrones generales, y lo ajustas para una tarea, formato, estilo o dominio concreto.

Es mucho más barato que entrenar un modelo base, pero sigue siendo un proyecto de datos: necesitas ejemplos buenos, validación, métricas y una razón clara para tocar el comportamiento del modelo. Fine-tuning puede cambiar cómo responde; no le da acceso automático a información nueva en tiempo real.

Qué cambia y qué no cambia

ElementoLectura correctaImplicación prácticaModelo baseYa viene preentrenado con conocimiento y capacidades generalesNo enseñas lenguaje desde cero; especializas un comportamiento existenteDatos de fine-tuningEjemplos input/output, conversaciones, clasificaciones o trazas de tareaEl modelo aprende patrones de respuesta, formato, tono y decisiónPesos/adaptadoresSe modifican pesos del modelo o se entrenan adaptadores pequeños como LoRAEl cambio queda “horneado” hasta que vuelvas a entrenar o cambies adaptadorConocimiento vivoNo consulta tu base documental por sí soloPara precios, políticas, inventario, documentación o datos cambiantes: mejor RAGTrazabilidadNo guarda citas ni fuentes verificablesSi necesitas justificar con documentos, combina con RAG o reglasCalidadDepende muchísimo de datos limpios y evalsSin evaluación interna puedes empeorar el modelo sin darte cuenta### Sí tiene sentido

• **Formato estable:**extracción, clasificación o respuestas con una estructura muy concreta que el prompt no clava.
• **Estilo repetible:**tono de marca, taxonomía interna, redacción legal/comercial muy consistente.
• **Coste y latencia:**sustituir prompts largos con muchos ejemplos por un modelo pequeño especializado.
• **Tarea acotada:**dataset curado, métrica clara y ejemplos parecidos a producción.
• **Dominio privado estable:**patrones que no cambian cada semana y no necesitan citar fuentes.

Mejor no meterse

• **Datos cambiantes:**precios, políticas, documentación viva, inventario, tickets. Usa RAG.
• **Necesitas fuentes:**fine-tuning no cita ni garantiza trazabilidad documental.
• **Datos sucios o pocos ejemplos:**el modelo aprende tus errores y sesgos.
• **Razonamiento general:**suele ser mejor cambiar de modelo, prompt o scaffold.
• **No tienes evals:**sin benchmark interno no sabrás si mejoró o solo cambió.

Regla práctica

Fine-tuningno enseña datos nuevos en tiempo real. Para acceder a conocimiento propio que cambia, usa RAG. Para cambiar cómo responde el modelo ante tareas repetibles, estables y medibles, fine-tuning puede ser una buena inversión.

Eval mínima antes de entrenar

MétricaPor qué decideBaseline con prompt buenoEvita entrenar para arreglar una instrucción mala.Formato válidoMuchas mejoras de fine-tuning son de consistencia, no de “conocimiento”.GeneralizaciónTest oculto con casos nuevos, no ejemplos vistos.Coste por caso aceptadoUn modelo ajustado puede ganar aunque tenga menor score global.

143Fine-tuning en la práctica

En la práctica, fine-tuning no empieza con “vamos a entrenar”. Empieza con una tarea repetible, ejemplos representativos y una eval que diga si el cambio mejora de verdad. Si no puedes medirlo, todavía estás en fase de prompt/RAG/prototipo.

Flujo mínimo sano

Caso de uso→Dataset curado→Train / validación→Entrenar adapter→Eval interna→Servir o descartar

PiezaQué debes tenerSeñal de peligroDatasetEjemplos parecidos a producción, limpios, revisados y balanceadosCopiar logs sin limpiar, duplicados, respuestas malas o etiquetas ambiguasSplitTrain, validación y test oculto separados antes de iterarMedir con los mismos ejemplos usados para entrenarMétricaFormato válido, exactitud, coste, latencia, safety o preferencia humana“Me gusta más” sin rúbrica ni casos negativosBaselinePrompt bueno, RAG si aplica y modelo frontier como comparaciónEntrenar para arreglar un prompt mal diseñadoRollbackVersión de modelo/adaptador, dataset y configuración reproduciblesNo poder volver al comportamiento anterior### LoRA y QLoRA

En vez de reentrenar los miles de millones de parámetros del modelo,LoRA(Low-Rank Adaptation) añade pequeñas matrices entrenables en capas clave. Resultado: entrenas0.1-1% de los parámetroscon una fracción de la memoria.

TécnicaMemoria GPUParámetros entrenadosCaso de usoFull fine-tuning~160 GB (7B)100%Cambio radical de comportamientoLoRA~16 GB (7B)0.1 - 1%Especialización: estilo, dominio, formatoQLoRA~6 GB (7B)0.1 - 1%Igual que LoRA pero con modelo quantizado (4-bit)### Herramientas

Unsloth

2x más rápido, 60% menos memoria. Soporta Llama, Mistral, Gemma. La opción más eficiente para fine-tuning local

Axolotl

Configuración YAML, múltiples formatos de dataset, integración con Weights & Biases

APIs de fine-tuning

OpenAI y Google/Vertex ofrecen fine-tuning como servicio. En Claude API, Anthropic no ofrece fine-tuning público general: para Claude suele tocar prompt, RAG, tools o hablar con el proveedor.

Señales durante entrenamiento

SeñalLecturaAcciónTrain loss baja, validación empeoraOverfittingMenos epochs, más datos, regularización o early stoppingFormato mejora, contenido empeoraEl dataset enseña plantilla, no criterioAñadir ejemplos difíciles y revisión de etiquetasModelo olvida capacidades generalesCatastrophic forgetting / sobreespecializaciónMezclar datos generales o usar adapters más pequeñosEval no cambiaEl problema quizá era retrieval, prompt o modelo baseParar y volver al diagnósticoAntes de hacer fine-tuning

En la mayoría de proyectos, un buen prompt o RAG resuelve el problema sin fine-tuning. Fine-tuning tiene sentido cuando necesitas: (1) comportamiento o formato estable que el prompt no consigue, (2) adaptar un modelo pequeño a una tarea repetible, o (3) reducir latencia/coste eliminando instrucciones largas del prompt.

144Datos sintéticos

Usar un LLM grande paragenerar datos de entrenamientopara otros modelos o sistemas. Cada vez más común como alternativa a la recolección manual de datos.

Patrones comunes

Datos para destilación

El modelo teacher genera miles de pares input/output. El modelo student entrena con esos pares. Así se crearon los modelos destilados de DeepSeek-R1 y Phi

Datasets de evaluación

Generar casos de test automáticos para evaluar modelos. Preguntas, respuestas esperadas, escenarios edge case

Aumentación de datos

Tienes pocos ejemplos reales (50-100) y generas variantes: paráfrasis, traducciones, cambios de estilo. Multiplicas tu dataset por 10-100x

Datos conversacionales

Generar diálogos multi-turno para entrenar chatbots de dominio específico (soporte técnico, ventas, onboarding)

Riesgos

• **Model collapse:**si entrenas con datos generados por el mismo modelo (o uno similar), la calidad degrada con cada generación. Los errores se amplifican
• **Sesgo amplificado:**los sesgos del modelo teacher se heredan y pueden intensificarse en el student
• **Calidad variable:**sin filtrado y revisión humana, los datos sintéticos pueden contener alucinaciones, inconsistencias o patrones repetitivos

Buenas prácticas

No hay un ratio universal. Empieza mezclando datos sintéticos con datos reales, filtra por calidad (otro LLM como juez o métricas automáticas) y valida siempre con un subset de datos reales etiquetados por humanos.

Pipeline sano de datos sintéticos

PasoQué hacesControl de calidadSemillas realesPartes de casos reales anonimizados o taxonomías de dominioEvita inventar una distribución que no existeGeneraciónTeacher genera variantes, edge cases y respuestas esperadasPrompt versionado y temperatura controladaFiltradoDeduplicas, verificas formato y descartas incoherenciasReglas + juez + muestreo humanoMezclaCombinas real y sintético sin perder el test realTest final solo con datos reales o auditadosAuditoríaGuardas prompt, modelo, fecha, licencia y criteriosTrazabilidad si el dataset se usa para entrenar

145Bases de datos vectoriales: ¿qué son y en qué se diferencian?

Bases de datos optimizadas para almacenar y buscar**vectores (embeddings)**por similitud. En vez de buscar por coincidencia exacta (WHERE nombre = 'X'), buscan por distancia entre vectores: “¿qué vectores se parecen más a este?”

SQL vs NoSQL vs Vectorial

TipoBusca porEjemplo de consultaSQLValores exactos, filtros, relacionesSELECT \* WHERE precio \> 100NoSQLDocumentos, claves, campos flexiblesdb\.find\(\{ status: "active" \}\)VectorialSimilitud semántica“gato doméstico“ encuentra “felino de compañía”### Proveedores principales (mayo 2026)

ProveedorTipoIdeal paraPineconeGestionado (serverless)Producción sin operaciones. Escala a billones de vectoresQdrantOpen source (Rust)Alto rendimiento, filtrado avanzado por metadatosWeaviateOpen sourceBúsqueda híbrida (vectorial + keyword), multimodalChromaOpen sourcePrototipos y desarrollo rápido. LigeropgvectorExtensión PostgreSQLSi ya usas Postgres. Límite ~10-100M vectoresMilvusOpen sourceBillones de vectores. GPU-accelerated### Distancia y búsqueda aproximada

ConceptoLectura prácticaRiesgoCosine similarityCompara dirección del vector; muy usada en embeddings normalizadosNo entiende permisos ni fechas si no filtras metadataDot productCombina dirección y magnitud; depende de cómo se entrenó el embeddingNo mezclar métricas sin saber lo que espera el modeloANN / HNSW / IVFÍndices aproximados para no comparar contra todos los vectoresMás velocidad puede bajar recall si se configura malHybrid searchCombina vector + BM25 + filtrosNecesita fusión/rerank para no mezclar rankings a ciegas¿Cómo elegir?

**Prototipo rápido:**Chroma (embebido, sin servidor).**Ya usas Postgres:**pgvector.**Producción sin preocuparte de infra:**Pinecone.**Necesitas control total + rendimiento:**Qdrant o Milvus.**Búsqueda híbrida:**Weaviate.

146Text-to-SQL: consultas en lenguaje natural

Convertir preguntas en español aqueries SQL ejecutables. El caso de uso más inmediato de IA para backend engineers.

Flujo

“¿Cuántos usuarios se registraron ayer?”→LLM + esquema de BD→SELECT COUNT(*) FROM users WHERE...→Ejecutar + resultado

Ejemplo

constsystemPrompt =`Eres un experto en SQL. Esquema de la BD: - users (id, name, email, created_at, plan) - orders (id, user_id, total, status, created_at) Genera SOLO la query SQL. Sin explicaciones.`;

constquery =awaitllm.generate(systemPrompt, pregunta); constresult =awaitdb.raw(query);

Riesgos y mitigaciones

• **SQL injection vía LLM:**el modelo podría generar DELETE o DROP. Solución: usuario de solo lectura, validar query, limitar a SELECT
• **Queries incorrectas:**el modelo puede malinterpretar el esquema. Solución: incluir descripciones de columnas, validar con EXPLAIN
• **Datos sensibles:**el usuario podría pedir datos que no debería ver. Solución: row-level security, filtros obligatorios

En la práctica

No expongas text-to-SQL directamente a usuarios finales sin guardrails. Funciona bien como herramienta interna para analistas y producto que necesitan consultar datos sin depender del equipo técnico.

Guardrails mínimos

ControlCómo se aplicaQué evitaUsuario read-onlyCredenciales sin permisos de escrituraDROP,DELETE, mutaciones accidentalesAST parserParsear SQL y permitir soloSELECTy tablas autorizadasPrompt injection y queries peligrosasEXPLAIN + limitRevisar plan y añadir límites máximosQueries caras o bloqueantesSemantic layerExponer métricas aprobadas, no toda la BD crudaInterpretaciones distintas de “ingresos”, “activo”, “churn”AuditoríaGuardar pregunta, SQL, usuario y resultado resumidoFalta de trazabilidad ante errores

147Prompt caching: reutilizar prefijos repetidos

Cuando usas system prompts largos o contexto RAG fijo, puedes pagar repetidamente los mismos tokens. El prompt caching permite reutilizar prefijos estáticos y cobrar menos por tokens cacheados, según proveedor y ventana de caché.

Primera llamada→Cachear prefijo→Siguientes llamadas→Tokens nuevos + tokens cacheados con descuento

Soporte por proveedor

ProveedorCómo funcionaAhorroAnthropiccache\_controlbreakpoints en el mensajeDescuentos en tokens cacheados según modelo y planOpenAIAutomático para prefijos largos repetidosPrecio reducido para cached tokens según modeloGoogleContext caching explícitoDescuento y retención de caché según configuración### Ejemplo con la API de Anthropic

constresponse =awaitclient.messages.create({ model:“claude-sonnet-4-6”, system: [{ type:“text”, text: systemPromptLargo, cache_control: { type:“ephemeral”} }], messages: [{ role:“user”, content: pregunta }] });

Invalidation: lo que se olvida

ProblemaEjemploControlPrefijo cambiaAñades una línea al system prompt y ya no coincideSeparar instrucciones estables de contexto variableDatos caducanPolítica interna, precio o documentación cambiaTTL, versión de documento y cache busting explícitoPrivacidadCachear contexto de un cliente y reutilizarlo malCache key por tenant/usuario/permisosMedición incompletaSolo miras descuento, no latencia ni aciertosRegistrar cache hit rate, coste y calidad¿Cuándo usarlo?

**Ideal para:**system prompts largos (>1000 tokens), contexto RAG fijo que se repite, conversaciones donde el historial crece.**No útil para:**prompts cortos que cambian cada vez.

148Context window en la práctica: no todo es lo que parece

Un modelo con 1M tokens de context window no significa que puedas meter 1M tokens y funcione igual de bien. Hay límites prácticos que conviene conocer.

“Lost in the middle”

Los modelos prestan más atención al inicio y al final del contexto, y tienden a “olvidar” información que está en el medio. Si metes un dato importante en la página 50 de 100, el modelo puede ignorarlo. (Lost in the Middle paper)

Context teórico vs práctico

ModeloContext windowZona óptimaNotaClaude Opus 4.7 / Sonnet 4.61MUsar citas y estructura en contextos largosOpus 4.7 añade 128k max output y task budgetsGPT-5.5 / GPT-5.41.05MSegmentar por secciones y usar toolsCached prefixes ayudan; ojo a pricing de contexto largoGemini 3.1 Pro Preview1MMuy fuerte en multimodal largoVerificar recuperación, no asumir lectura perfectaDeepSeek-V4 Pro/Flash1MSeparar Pro para calidad y Flash para coste/latenciaThink Max recomienda al menos 384k en despliegue localQwen3.6-35B-A3B262k / 1.01M YaRNActivar YaRN solo cuando haga falta contexto ultra-largoEl escalado puede afectar prompts cortos### Estrategias para contextos grandes

• **Chunking inteligente:**dividir documentos en fragmentos con solapamiento
• Priorizar información relevanteal inicio y final del prompt
• RAG en vez de meter todo en el contextcuando el volumen es grande
• Resumen progresivopara conversaciones largas
• Map-reducepara documentos enormes

Presupuesto de contexto

ParteDebe reservarse para...Regla prácticaSystem/developerReglas estables, formato, permisosCompacto y cacheableContexto recuperadoEvidencia mínima necesariaTop-k con rerank, no “todo el documento”HistorialDecisiones relevantes, no charla completaResumen con estado y cambiosRespuestaTokens de salida y, si aplica, razonamiento/tool callsDejar margen:input \+ output <= windowRegla práctica

No llenes el context window “porque puedes”. Más contexto = más caro, más lento y potencialmente peor calidad. Usa solo el contexto que necesitas para la tarea.

149API Hello World: tu primera llamada a un LLM

Antes de hablar de agentes, veamos lo más básico: hacer una llamada a la API de un modelo. Es sorprendentemente simple.

Con curl

curl https://api.anthropic.com/v1/messages \ -H“x-api-key: $ANTHROPIC_API_KEY“\ -H“content-type: application/json“\ -H“anthropic-version: 2023-06-01“\ -d’{ “model”: “claude-sonnet-4-6”, “max_tokens”: 256, “messages”: [ {“role”: “user”, “content”: “¿Qué es TypeScript en una frase?”} ] }’

Con el SDK de TypeScript

importAnthropicfrom“@anthropic-ai/sdk“; constclient =newAnthropic(); constmsg =awaitclient.messages.create({ model:“claude-sonnet-4-6”, max_tokens:256, messages: [ { role:“user”, content:“¿Qué es TypeScript en una frase?”} ] }); console.log(msg.content[0].text);

¿Qué devuelve la API?

• **content:**array de bloques con el texto de la respuesta
• **model:**el modelo que respondió
• **stop_reason:**por qué paró ("end\_turn"= respuesta completa)
• usage:input\_tokensyoutput\_tokensconsumidos (lo que pagas)

Checklist de primera integración

PiezaQué configurar desde el día 1SecretsAPI keys en variables de entorno, nunca en notebooks ni frontendTimeoutsTiempo máximo por llamada y cancelación del requestUsageLog de input/output tokens, modelo, coste estimado y usuarioErroresRate limit, 5xx, invalid request, content filtering y reintentosVersionadoModelo, prompt, schema y parámetros guardados con la respuestaDe aquí a un agente

Esta llamada simple es la base de todo. Un agente es esto mismo dentro de un bucle que añade tool calls. La complejidad se construye sobre esta base.

150Streaming de respuestas

En vez de esperar a que el modelo genere toda la respuesta, recibesfragmentosen tiempo real. Es el patrón habitual en interfaces conversacionales como ChatGPT, Claude o Gemini.

¿Cómo funciona?

Server-Sent Events (SSE)

El estándar para streaming de LLMs. Conexión HTTP unidireccional: el servidor envía eventos conforme genera tokens. Más simple que WebSockets y suficiente para este caso

Time to First Token (TTFT)

Métrica clave: cuánto tarda en llegar el primer fragmento. Con streaming, el usuario ve actividad antes de esperar a la respuesta completa

Ejemplo: streaming con la API de Anthropic

importAnthropicfrom“@anthropic-ai/sdk“;

constclient =newAnthropic();

conststream = client.messages.stream({ model:“claude-sonnet-4-6”, max_tokens:1024, messages: [{ role:“user”, content:“Explica qué es Docker”}] });

stream.on(‘text’, (text) => { process.stdout.write(text); });

constfinalMessage =awaitstream.finalMessage();

Eventos del stream

EventoQué contieneUso típicomessage\_startMetadata del mensaje (id, modelo)Inicializar UIcontent\_block\_deltaFragmento de texto (delta)Mostrar texto incrementalmentemessage\_deltaRazón de parada, uso de tokensContabilizar costemessage\_stopFin del mensajeCerrar la UI de escritura### UX y backend

DecisiónBuena prácticaMotivoRender incrementalMostrar tokens/chunks sin bloquear inputMejora percepción de velocidadCancelaciónBotón stop que corta stream y backendEvita coste inútilTool callsMostrar estados: buscando, ejecutando, verificandoEl usuario entiende esperas no textualesModeración parcialNo publicar directamente contenido sensible sin checksStreaming puede enseñar texto antes de validar todoEn la práctica

Streaming no cambia el precio por token ni la lógica de generación. Cambiacuándo recibesla respuesta. La percepción de velocidad mejora aunque el tiempo total pueda ser parecido.

151Arquitectura de aplicaciones con LLM

Saber llamar a la API es el primer paso. Construir unproducto en producciónrequiere patrones de ingeniería que la documentación del modelo no enseña.

Capas de una app LLM en producción

Cliente→API Gateway→Orquestación→LLM Provider(s)

Retry + fallback

Si Claude falla, reintentar con backoff. Si sigue, caer a GPT o modelo local. Nunca depender de un solo proveedor

Caché semántica

Cachear por similitud de la pregunta, no por igualdad exacta. Reduce coste y latencia en preguntas frecuentes

Circuit breaker

Si un proveedor da errores consecutivos, dejar de llamarlo temporalmente. Evita cascadas de fallos

Model routing

Clasificar complejidad y enviar al modelo adecuado: modelos baratos para lo simple, modelos potentes para lo complejo. Puede reducir coste sin perder calidad

Checklist para producción

• **Spending limits:**alertas y cortes automáticos por coste diario/mensual
• **Timeouts:**nunca esperar indefinidamente. Timeout + respuesta de fallback
• **Observabilidad:**loguear cada llamada (modelo, tokens, latencia, coste)
• **Versionado de prompts:**tratar prompts como código: en git, con rollback

Observabilidad específica de LLM

SeñalPor qué importaPrompt/model/schema versionPermite reproducir una respuesta y hacer rollbackTokens, coste y latenciaDetecta prompts inflados, loops de agente y modelos mal ruteadosTool tracesExplica qué leyó o ejecutó el agente antes de responderQuality signalsFeedback humano, evals en sombra, groundedness y resolución realSafety eventsJailbreaks, PII, refusals, abuso y acciones bloqueadasRegla de oro

Trata al LLM como unservicio externo no fiable: puede fallar, puede ser lento, puede dar respuestas incorrectas. Diseña tu arquitectura como lo harías con cualquier dependencia externa crítica.

152Lo que deberías saber: uso práctico

ConceptoSlidePrompt engineering: contexto claro + restricciones precisas98Context engineering: gestionar capas de contexto, memoria, tools y RAG99Formatos de datos: JSON, YAML, Markdown, XML y formato como contrato100Alucinaciones: tipos de error, verificación y grounding101Structured output: schema, tool use, validación backend y retries102Multimodal: imágenes, PDFs, audio, vídeo y métricas de calidad103-104Generación visual: imagen/vídeo, difusión, LoRA, ControlNet, ComfyUI105-109Modelos frontier: datos, pre-training, SFT, RL, safety y serving110Hugging Face: model cards, memoria, formatos, DeepSeek y eval results111-118Mantenerse actualizado, elegir modelo y diseñar mini-labs119-121Google Colab, repos de práctica, experimentos reproducibles y eval interna122-127RAG: chunking, embeddings, rerank, citas, recall@k y no-answer128Agentic RAG, GraphRAG, knowledge graphs, RDF/OWL/SPARQL y retrieval híbrido129-140Prompt, RAG o fine-tuning: diagnosticar el problema correcto141-143Datos sintéticos: generación, filtrado, mezcla, riesgos y auditoría144Vector DB y Text-to-SQL: búsqueda semántica, guardrails y consultas seguras145-146Prompt caching y context window: coste, invalidación, lost in the middle147-148API, streaming y arquitectura de apps LLM con observabilidad y fallback149-151 153

Agentes y orquestación

Qué es un agente, cuándo usarlo, function calling, arquitecturas, patrones, orquestadores, MCP, computer use, A2A y human-in-the-loop.

154¿Cuándo usar un agente y no un prompt?

La pregunta no es si un agente “parece más avanzado”, sino si la tarea necesitaestado, herramientas, iteración y verificación. Un agente añade potencia, pero también coste, latencia, superficie de fallo y necesidad de observabilidad.

Usa un prompt cuando

• La tarea es única y simple
• No tiene efectos secundarios
• No necesita acceder a ficheros o APIs
• Una respuesta de texto basta

Usa un agente cuando

• Necesitas múltiples pasos coordinados
• Hay que interactuar con sistemas externos
• La tarea requiere iteración y autocorrección
• El flujo tiene decisiones condicionales
• Quieres automatizar un proceso repetitivo

Criterio operativo

SeñalPrompt únicoAgente / workflowPasos1 respuesta, poca dependenciavarios pasos con observaciones entre mediasHerramientasno necesita APIs ni ficheroslee, escribe, consulta, navega o ejecuta comandosErrorse corrige editando el textonecesita detectar fallo, reintentar o escalarRiesgosin efectos lateralesacciones con permisos, coste o impacto realMedicióncalidad subjetiva suficienteéxito verificable: test, diff, ticket, métrica, aprobaciónClave

Cada tarea del agente necesita unaventana de contexto nueva(conversación limpia). Si reutilizas una conversación larga, el contexto acumulado degrada la calidad: el modelo pierde foco, las instrucciones iniciales se diluyen y el coste en tokens se dispara. Nuevo objetivo = nueva conversación.

Regla rápida

Si necesitas copiar/pegar el resultado del chat para hacer algo con él, probablemente necesitas un agente.

155¿Qué es un agente?

Un LLM con capacidad deactuar a través de herramientas: no solo responde, sino que decide llamadas a tools que ejecuta el sistema anfitrión. Puede completar tareas complejas con distintos niveles de autonomía.

Percibir→Razonar→Actuar→Observar↻

Componentes mínimos

ComponenteQué aportaEjemploObjetivodefine qué significa terminar“abrir PR con tests verdes“Estadorecuerda progreso, permisos y evidenciasarchivos leídos, plan, errores, decisionesToolsacciones observables sobre el mundoread_file, run_tests, search_docs, create_ticketPolíticadecide siguiente acción según estadoLLM + reglas + routing + guardrailsEvaluacióncomprueba si la tarea funcionótests, schema, diff, métricas, revisión humana### ¿Qué puede hacer un agente?

Buscar información

Ficheros, bases de datos, internet, APIs externas

Leer y escribir

Crear, editar y analizar archivos de tu proyecto

Ejecutar comandos

Tests, builds, deploys, instalaciones, scripts

Autocorregirse

Si algo falla, analiza el error y reintenta con otra estrategia

Ejemplo paso a paso: “Añade tests al módulo de auth”

1. Leeel código del módulo de auth para entender la estructura
2. Identificafunciones sin cobertura de tests
3. Escribelos tests en un archivo nuevo o existente
4. Ejecutanpm testpara verificar que pasan
5. Corrigeerrores si algún test falla y vuelve a ejecutar

Diferencia clave con un chatbot

Un chatbot responde preguntas. Un agentecompleta tareas. El chatbot te dice cómo hacerlo; el agente coordina acciones por ti mediante herramientas y con tu supervisión.

Lectura correcta

Agente no significa “autónomo sin control”. Significa que el sistema tiene un loop de decisión y acción. La autonomía se gradúa con permisos, límites, checkpoints y capacidad de rollback.

**Ejemplos:**Claude Code, Devin, Cursor Agent, Aider

156Agente moderno vs agente clásico

La palabra agente no empezó con los LLMs. Lo nuevo es que el modelo puede interpretar lenguaje, decidir tools y mantener una conversación operativa.

La comparación permite separar moda de arquitectura. Un agente moderno no es solo un chat largo: necesita percepción, estado, acciones, restricciones y evaluación, aunque esas piezas se implementen con LLMs y tools.

La continuidad es más importante que la moda: un agente clásico ya tenía percepción, estado, decisión y acción. El LLM aporta lenguaje natural y flexibilidad, pero no elimina la necesidad de estado, contratos, restricciones y evaluación.

Teoría aplicada

Un agente es un bucle de percepción, estado, decisión y acción; el LLM solo ocupa algunas piezas.

Fórmula / criterio

policy: pi(a|s) elige acción a dado estado s; en LLM, s incluye contexto, memoria y tools.

Ejemplo

Un coding agent lee tests, modifica archivos, ejecuta build y decide siguiente paso con observaciones.

Decisión

Diseña el agente como sistema, no como prompt largo.

ClásicoModernoestado explícitocontexto + memoriaacciones modeladastools / function callingprecondiciones y efectosvalidadores, schemas, permisosplannerLLM razonador / orquestadorheurísticamodelo, eval, routingmotor de inferenciaLLM + RAG + reglasPregunta de diseñoLectura práctica¿Qué observa?inputs de usuario, documentos, tool results, logs, eventos¿Qué recuerda?estado explícito, memoria persistente, trazas y decisiones¿Qué puede hacer?tools con permisos, contratos y efectos auditables¿Cómo sabes que funciona?evals por tarea, tests, métricas y revisión humanaNo es “más autonomía” por defecto

Un agente moderno solo merece autonomía cuando puede observar resultados, corregir errores, respetar límites y dejar evidencia. Si no, es un prompt largo con permisos peligrosos.

157Agente clásico: percibir y actuar

Un agente clásico recibe perceptos, actualiza estado y elige una acción. Esa estructura sigue estando debajo de muchos agentes LLM.

El bucle percepción-acción sigue siendo la unidad mínima. Cada observación cambia lo que el agente sabe, y cada acción debe producir una nueva evidencia que permita decidir si avanzar, corregir o detenerse.

El aprendizaje importante es operacional: una acción no termina cuando se invoca una tool, termina cuando el sistema observa su efecto. Sin esa observación, el agente no sabe si avanzó, falló o dañó algo.

Teoría aplicada

Cada acción debe producir una observación que reduzca incertidumbre o acerque al objetivo.

Fórmula / criterio

loop: observe(s) -> choose(a) -> act(a) -> observe(s’) -> update.

Ejemplo

Tras llamar a una API, el agente no debe asumir éxito: debe leer status, payload y efecto persistido.

Decisión

Bloquea loops que repiten acciones sin nueva evidencia.

Percepción→Estado interno→Decisión→Acción→Nuevo percepto

Percepto

Lo que el sistema observa: input, respuesta de tool, logs.

Estado

Representación mantenida de la situación.

Acción

Cambio en el entorno: API, archivo, navegador, email.

Feedback

La acción modifica el mundo y produce nueva observación.

En IA clásicaEn agente LLMRiesgo si faltaPerceptoresultado de tool, error de build, respuesta HTTPactúa con información viejaEstadoplan, progreso, permisos, archivos tocadosrepite pasos o contradice decisionesAcciónllamada a API, edición, navegación, comandoefectos laterales no controladosFeedbacktest, diff, log, métrica, aprobaciónconfunde plausibilidad con éxitoCriterio de parada

Todo loop de agente necesita una condición de éxito, una condición de fallo y un límite de pasos/coste. Si no puedes escribirlos, todavía no tienes una automatización controlada.

158Reactivo, deliberativo e híbrido

No todo agente necesita plan largo. A veces basta reacción; otras veces necesitas deliberar, comprobar y ejecutar por fases.

No todas las tareas justifican autonomía compleja. Un clasificador reactivo puede ser mejor para decisiones simples; un agente deliberativo tiene sentido cuando hay dependencias, incertidumbre y pasos que se validan durante la marcha.

La arquitectura correcta depende de incertidumbre y coste de error. Cuanto más irreversible sea la acción, más conviene pasar de respuesta reactiva a planificación, validación y checkpoints.

Teoría aplicada

Reactivo minimiza latencia; deliberativo mejora tareas con dependencias; híbrido combina ambos.

Fórmula / criterio

Complejidad útil ~= riesgo x número de pasos x incertidumbre.

Ejemplo

Enrutar un ticket puede ser reactivo; migrar una base de datos exige plan, checks y rollback.

Decisión

No conviertas una regla simple en agente autónomo sin necesidad.

TipoCómo decideEjemplo modernoReactivoreglas directas sobre perceptosclasificar ticket y enrutarDeliberativoconstruye un plan antes de actuarmigrar un módulo con testsHíbridoplanifica alto nivel y reacciona a observacionescoding agent con loop de build/testTipoFallo típicoControl útilReactivoconfunde intención o aplica regla demasiado simpleclasificador calibrado, fallback y revisión de casos fronteraDeliberativoplan bonito pero no ejecutablevalidar precondiciones antes de cada acciónHíbridoderiva entre pasos o cambia de objetivoestado explícito, trazas y checkpointsEjemplo

Clasificar un ticket como facturación puede ser reactivo. Reembolsar dinero al cliente exige plan, permiso, consulta de estado, tool segura y confirmación.

159Estado explícito vs contexto

En un agente LLM, el estado muchas veces vive repartido entre prompt, memoria, filesystem, trazas y resultados de tools.

El contexto textual es cómodo, pero no sustituye a estado controlado. Cuando algo importa para permisos, progreso o auditoría, conviene guardarlo en una estructura verificable y no confiar en que el modelo lo recuerde.

El contexto sirve para razonar; el estado sirve para operar. La diferencia importa porque el texto puede ser ambiguo, viejo o demasiado largo, mientras que el estado estructurado puede validarse y auditarse.

Teoría aplicada

El contexto textual es memoria blanda; el estado explícito es contrato verificable.

Fórmula / criterio

Estado crítico = hechos + permisos + progreso + locks + efectos confirmados.

Ejemplo

“Ya pagado” debe vivir en base de datos, no solo en conversación previa.

Decisión

Todo lo que implique dinero, permisos o auditoría va fuera del prompt.

Estado explícito

Estructura definida: variables, hechos, flags, permisos, plan, progreso.

verificable

Contexto

Texto que el modelo interpreta. Flexible, pero puede ser incompleto, largo o ambiguo.

flexible

Debe ir a estado explícitoPuede ir en contextosaldo, permisos, usuario autenticado, IDs, lockspreferencias de estilo, objetivos, explicación del dominiopasos completados, tool calls, outputs confirmadosresúmenes de lectura y notas de razonamiento operativodecisiones auditables y aprobaciones humanashipótesis temporales que se pueden revalidarRegla práctica

Lo crítico debería estar en estado verificable, no escondido en conversación.

160Acciones modeladas vs tools

Una tool es una acción con interfaz. Si no defines contrato, permisos y efectos, el agente opera a ciegas.

Una tool mal definida convierte al agente en operador de una caja negra. El contrato de la tool debe decir qué recibe, qué permite, qué cambia y cómo se recupera de errores.

Una tool no es “una función que el modelo puede llamar”; es una frontera de seguridad. El schema reduce errores de forma, las precondiciones reducen errores de decisión y los logs permiten depurar el comportamiento.

Teoría aplicada

Una tool es una acción con contrato: entradas, permisos, efectos, errores y límites.

Fórmula / criterio

tool = schema(input) + preconditions + side effects + error model.

Ejemplo

create_invoice no debe aceptar cualquier texto: importe, moneda, cliente y concepto deben validarse.

Decisión

Diseña tools pequeñas, reversibles cuando sea posible y con logs de efecto.

PiezaDiseño correctoNombreverbo claro: search_docs, create_invoice, run_testsSchemaparámetros tipados, enums y campos obligatoriosPrecondicionespermisos, datos mínimos, límites de costeEfectosqué cambia y cómo se registraErroresmensajes estructurados y recuperablesTipo de toolEjemploNivel de controlSolo lecturasearch_docs, get_invoice, list_filespermisos y límites de datosReversiblecreate_draft, open_ticket, write_temp_fileconfirmación ligera y rollbackIrreversiblesend_email, refund_payment, delete_recordaprobación humana, doble validación y auditoríaDiseño mínimo

Una buena tool tiene nombre inequívoco, descripción corta, schema estricto, errores recuperables, límites de coste, permisos y registro de efecto.

161Precondiciones, efectos y schemas

El prompt puede pedir cuidado; el schema puede impedir una llamada inválida. Son capas complementarias.

Schemas y precondiciones son la traducción moderna de planificación clásica. Antes de ejecutar, comprueban si la acción tiene sentido; después, registran efectos para que el siguiente paso parta de estado real.

Esta slide conecta planning clásico con agentes modernos: antes de una acción preguntas “¿se puede ejecutar ahora?”; después preguntas “¿qué cambió realmente?”. Esa disciplina evita que el modelo convierta intención en efecto no verificado.

Teoría aplicada

Schemas reducen forma inválida; precondiciones reducen acción inválida; efectos permiten auditar.

Fórmula / criterio

can_execute(action,state) debe ser true antes de ejecutar.

Ejemplo

Enviar email requiere destinatario confirmado, plantilla aprobada y documento final.

Decisión

Valida antes y después: la tool debe demostrar qué cambió.

Intento del modelo→Validar schema→Comprobar permisos→Ejecutar tool→Registrar efecto

ConceptoPreguntaEjemploSchema¿La forma de los datos es válida?email con formato correcto, enum de moneda, importe numéricoPrecondición¿Tiene sentido ejecutar ahora?usuario autenticado, factura existe, estado permite reembolsoEfecto¿Qué cambia tras ejecutar?ticket creado, saldo actualizado, fichero escritoPostcondición¿El efecto esperado ocurrió?leer de nuevo BD, comprobar status, verificar diffProducción

Toda tool peligrosa debería tener contrato, límites, autorización y log de efecto.

162Planner vs LLM razonador

Un planner formal busca planes en un modelo del mundo. Un LLM razonador propone pasos plausibles a partir de contexto.

El LLM es excelente proponiendo pasos en lenguaje natural, pero no demuestra por sí solo que el plan sea factible. La robustez aparece al combinar propuesta flexible con comprobaciones explícitas.

No compiten; se complementan. El LLM entiende objetivos mal especificados y lenguaje humano; el planner o validador comprueba si las acciones encajan con estado, recursos y restricciones.

Teoría aplicada

El LLM propone planes plausibles; el planner formal busca factibilidad bajo un modelo explícito.

Fórmula / criterio

Plan válido: aplicar acciones desde s0 produce estado s que satisface goal.

Ejemplo

Un LLM puede olvidar una dependencia; un validador detecta que faltaba credencial, archivo o permiso.

Decisión

Usa el LLM para generar candidatos y validadores para aceptar ejecución.

DimensiónPlanner formalLLM razonadorMundomodelo explícitocontexto textual y herramientasGarantíafactibilidad/optimalidad bajo supuestosplausibilidad y adaptaciónFortalezarestricciones duraslenguaje natural y casos abiertosRiesgomodelado caroplan imposible si no se validaUsa planner/solver cuandoUsa LLM cuandoUsa híbrido cuandohay reglas exactas, recursos y restriccionesla entrada viene ambigua en lenguaje naturalnecesitas traducir preferencias a acciones verificablesel coste de un plan inválido es altoimporta explicar, resumir o negociar opcionesel agente propone y el sistema valida antes de ejecutarPrueba de realidad

Un plan textual no es un plan operativo hasta que cada paso tiene precondiciones, tool concreta, efecto esperado y criterio de verificación.

163Heurística, routing y evals

El agente moderno también necesita heurísticas: qué modelo usar, qué tool llamar, cuándo parar y cuándo escalar a humano.

Las heurísticas modernas son decisiones de ingeniería: modelo barato o caro, tool local o remota, parada automática o aprobación humana. Sin evals, esas decisiones se toman por intuición y se degradan sin que nadie lo vea.

Routing es una heurística con presupuesto. No intenta encontrar la verdad absoluta; decide dónde gastar tokens, latencia y atención humana para maximizar éxito esperado con coste razonable.

Teoría aplicada

Routing y evals son heurísticas modernas: asignan presupuesto según dificultad y riesgo.

Fórmula / criterio

coste esperado = tokens + tool calls + latencia + revisión humana + riesgo residual.

Ejemplo

Un FAQ va a modelo barato; una acción irreversible pide modelo fuerte y aprobación.

Decisión

Sin eval por tarea, el routing acaba siendo intuición vestida de arquitectura.

Routing

Modelo barato para tareas simples, modelo caro para alto riesgo.

Eval

Mide éxito por tarea, no solo calidad de texto.

Budget

Tokens, tool calls, latencia y coste humano.

Escalado

Cuando incertidumbre o riesgo superan umbral, pide aprobación.

Señal observableDecisión de routingMétricatarea simple y repetitivamodelo rápido o reglalatencia y coste por casobaja confianza o contradicciónmodelo fuerte o búsqueda adicionaltasa de resolución y groundednessacción irreversibleaprobación humanaerrores evitados y tiempo de revisiónfallo tras N intentosparar, resumir y escalarloops cortados y coste ahorradoEvals antes de arquitectura

Sin una eval por tarea, “usar varios modelos” suele ser intuición cara. Mide primero baseline, coste, latencia, errores y casos en los que un modelo pequeño no basta.

164Motor de inferencia moderno

En un sistema real, el “razonamiento” no vive solo en el LLM. Se reparte entre modelo, RAG, reglas, validadores y trazas.

En producción, razonar es coordinar capas. El LLM interpreta, el retrieval aporta evidencia, las reglas fijan límites, las tools cambian el mundo y las trazas permiten revisar qué ocurrió.

La arquitectura fiable reparte responsabilidades. El LLM maneja ambigüedad; el retrieval trae evidencia; las reglas bloquean lo inválido; las tools producen efectos; las trazas convierten la ejecución en algo auditable.

Teoría aplicada

La inferencia moderna es composición: modelo, evidencia, reglas, tools, trazas y humano.

Fórmula / criterio

respuesta aceptable = groundedness + validez + permiso + trazabilidad.

Ejemplo

El LLM redacta, RAG cita, reglas bloquean, tool ejecuta y trace permite revisar.

Decisión

Pon cada garantía en la capa que mejor puede cumplirla.

Input→RAG / KG→LLM→Reglas / schemas→Tool→Trace

CapaResponsabilidadLLMinterpretar, generar, decidir candidatosRAG/KGaportar evidencia y contextoReglasgarantizar restricciones durasTool logshacer auditable cada acciónFalloDónde se controla mejordato inventadoRAG con citas + verificación de fuenteformato inválidostructured output + schema parseracción no permitidapermisos fuera del modelobucle caropresupuesto de pasos, tokens y tool callsdecisión sensiblecheckpoint humano y traceArquitectura mental

Piensa en el LLM como una capa de decisión probabilística dentro de un sistema determinista alrededor. Cuanto más crítico el dominio, más fuerte debe ser el sistema alrededor.

165Qué debe saber: agentes clásicos y modernos

La parte clásica ayuda a diseñar agentes LLM con menos humo: estado claro, acciones seguras, restricciones y evaluación.

La idea final es diseñar agentes con vocabulario clásico y herramientas modernas. Eso reduce humo: menos promesas de autonomía y más contratos, permisos, validadores, memoria explícita y medición.

Al terminar este subbloque, el alumno debe poder mirar cualquier demo de agente y hacer preguntas incómodas: qué observa, qué estado conserva, qué permisos tiene, cómo valida, cuándo para y cómo se audita.

Teoría aplicada

El vocabulario clásico sirve para quitar magia a los agentes modernos.

Fórmula / criterio

Agente robusto = estado + acción + restricción + eval + recuperación.

Ejemplo

Un agente de soporte fiable no solo responde: consulta, valida permiso, cita y escala.

Decisión

Evalúa agentes por tareas completadas con seguridad, no por razonamientos bonitos.

Debes poder explicarAplicación modernaPercepción-estado-acciónloop de agente con toolsReactivo vs deliberativoprompt simple vs workflow/agentePrecondiciones y efectosschemas, permisos y logsPlanner vs LLMvalidar planes antes de ejecutarMotor de inferencia híbridoLLM + RAG + reglas + humanoPregunta de examen útilRespuesta esperada¿Por qué un agente no es solo un chatbot?porque actúa sobre herramientas y observa efectos¿Por qué no todo debe vivir en el prompt?porque permisos, estado y validación necesitan garantías externas¿Cuándo aumentar autonomía?cuando hay eval, trazas, límites, recuperación y coste de error asumible¿Qué se revisa en una tool peligrosa?schema, precondiciones, permisos, idempotencia, logs y aprobaciónMensaje del bloque

La parte clásica no es nostalgia: es el vocabulario que impide confundir una demo impresionante con un sistema operativo fiable.

166Contexto y memoria en agentes: por qué importa empezar limpio

Elcontext windowes la memoria de trabajo del agente: lo que “ve” en cada momento. Cuanto más larga la conversación, más tokens consume → más caro, más lento y con más riesgo de perder información relevante.

El contexto no es una base de datos: es una mochila limitada que el modelo relee en cada turno. Meter todo “por si acaso” suele empeorar el rendimiento porque diluye la señal importante y aumenta el coste de cada decisión.

¿Por qué usar contextos nuevos para tareas nuevas?

• **Evitas contaminación:**instrucciones o errores de una tarea anterior no afectan a la siguiente
• **Mejor rendimiento:**el modelo razona mejor con contexto limpio y enfocado
• **Menor coste:**no pagas tokens de historia irrelevante

Tipos de memoria en agentes

TipoDuraciónEjemploCorto plazoLa conversación actualEl context window del LLMLargo plazoPersistida entre sesionesFicheros, BD, embeddings, CLAUDE.mdEpisódicaRecuerdos de conversacionesQué decisiones se tomaron y por qué### Presupuesto mental y presupuesto de tokens

ReglaImplicación prácticaCoste por turno ≈ input acumulado + output nuevouna conversación larga encarece cada paso aunque la tarea actual sea pequeñaContexto útil < contexto máximo1M tokens no significa que debas enviarlo todo; recuperar lo relevante suele ganarEstado crítico fuera del promptpermisos, IDs, progreso y efectos deben vivir en estructuras verificablesResumen no es verdadcompactar ayuda, pero cualquier resumen puede perder matices importantesEstrategia práctica

Una tarea = un contexto nuevo, con solo las instrucciones y datos que necesita. Los frameworks ya lo gestionan: CrewAI tiene memoria corta/larga/entidad, Claude Code compacta automáticamente.

167Memoria persistente para agentes

Un agente sin memoria entre sesiones empieza de cero cada vez. Lamemoria persistentepermite que recuerde decisiones, preferencias y contexto de conversaciones anteriores.

La memoria persistente debe tratarse como producto, no como magia. Hay que decidir qué se guarda, por qué, durante cuánto tiempo, cómo se corrige y qué datos no deben persistirse nunca por privacidad o seguridad.

Tipos de memoria persistente

TipoCómo funcionaEjemploFicheros de reglasCLAUDE.md, .cursorrules: texto que se inyecta en cada sesión“Siempre usar TypeScript strict, commits en español“Memoria episódicaResúmenes de conversaciones anteriores, indexados por tema“En la sesión del 15/03 decidimos usar PostgreSQL por X razón“Base de conocimientoDocumentos del proyecto indexados en vector DB para RAGArquitectura, ADRs, convenciones del equipoMemoria semánticaHechos y relaciones extraídos y almacenados como grafo“El usuario es senior en Go, nuevo en React“### Herramientas (mayo 2026)

CLAUDE.md / Rules

Lo más simple. Ficheros de texto que Claude Code lee al inicio de cada sesión. Manual pero efectivo. En git con el proyecto

Memoria automática

Claude Code guarda decisiones y preferencias automáticamente en ficheros .md. Se recuperan por relevancia en sesiones futuras

Zep / MemGPT

Frameworks especializados en memoria para agentes. Almacenan, resumen y recuperan conversaciones pasadas automáticamente

Ciclo de vida de la memoria

FasePreguntaEjemploCapturar¿merece guardarse?decisión de arquitectura, preferencia estable, regla del equipoConsolidar¿cómo se resume sin perder evidencia?ADR breve con enlace a PR o conversaciónRecuperar¿cuándo se inyecta en contexto?solo si coincide con repo, tarea y fechaOlvidar¿cuándo caduca o se borra?secretos, datos personales, preferencias antiguasPrivacidad y seguridad

No guardes secretos, datos personales innecesarios ni inferencias sensibles. Una memoria útil pero incorrecta es peor que no tener memoria: contamina decisiones futuras con una falsa sensación de continuidad.

El problema sin resolver

La memoria perfecta para agentes sigue siendo un problema abierto. Demasiada memoria contamina el contexto. Poca memoria obliga a repetir decisiones. El equilibrio depende del caso de uso: empieza con CLAUDE.md + reglas y escala según necesites.

168Function calling (tool use): cómo el modelo ejecuta acciones

El modelo no puede ejecutar código directamente. Lo que puede hacer esdecidir qué herramienta llamary con qué parámetros. El sistema anfitrión ejecuta la herramienta y le devuelve el resultado.

Flujo de una tool call

Tu prompt→Modelo razona→Emite tool_use→Sistema ejecuta→Resultado al modelo→Respuesta final

Contrato de una tool

PiezaPor qué importaEjemploNombre y descripciónel modelo decide por semánticaget\_weathermejor quedo\_thingInput schemalimita forma y tiposcity:string, units: enumAutorizaciónel modelo no debe concederse permisosallowlist de usuarios/accionesIdempotenciareintentos no deben duplicar efectosidempotency key en pagos o ticketsObservaciónel agente necesita saber qué pasóstatus, error estructurado, recurso creado### Ejemplo con la API de Anthropic

consttools = [{ name:“get_weather”, description:“Obtiene el clima actual de una ciudad”, input_schema: { type:“object”, properties: { city: { type:“string”} }, required: [“city”] } }];

consttoolUse = { type:“tool_use”, id:“toolu_01”, name:“get_weather”, input: { city:“Madrid”} };

constresult =awaitfetchWeather(toolUse.input.city);

{ role:“user”, content: [{ type:“tool_result”, tool_use_id: toolUse.id, content: result }] }

Claves prácticas

• **El modelo NO ejecuta nada:**solo emite un JSON con la herramienta y parámetros. Tu código decide si ejecutar o no (sandboxing, permisos)
• **La descripción importa:**el modelo elige la herramienta por su nombre y descripción. Una descripción mala = herramienta ignorada o mal usada
• **Bucle iterativo:**el modelo puede encadenar múltiples tool calls antes de dar una respuesta final
• **Es la base de los agentes:**un agente es un LLM con acceso a herramientas que decide cuáles usar en cada paso

Diferencia clave

Sin tool use, el modelo solo genera texto. Con tool use, el modelo puedeactuar en el mundo real: consultar APIs, leer ficheros, ejecutar queries, navegar por la web. Es el salto de “chatbot” a “agente”.

Diseño seguro

Trata los argumentos de una tool como input no confiable. Valida schema, permisos y límites fuera del modelo; registra cada tool call con input, output, usuario, coste y decisión de aprobación.

169Arquitecturas de agentes: el bucle fundamental

Un agente no es solo un modelo que responde. Es unsistema que planifica, actúa y aprende del resultadoen un bucle continuo.

La teoría aplicada es simple: cada vuelta del bucle debe reducir incertidumbre. Si el agente llama tools pero no aprende nada nuevo, solo está consumiendo tokens y ampliando superficie de error.

El bucle ReAct (Reason + Act)

Observar→Razonar internamente→Actuar (tool call)→Observar resultado→Repetir

El agente mantiene razonamiento de trabajo, decide qué herramienta usar, ejecuta, lee el resultado y decide el siguiente paso. En producto conviene registrar plan, acciones, observaciones y verificación; no pedir que exponga todo su chain of thought.

Qué debe registrar un loop serio

RegistroPregunta que respondePlan visible¿qué intenta hacer y qué criterio de éxito usa?Tool call¿qué acción pidió, con qué argumentos y permiso?Observación¿qué devolvió el sistema y qué evidencia nueva aporta?Decisión¿continúa, cambia estrategia, pide ayuda o para?Budget¿cuántos pasos, tokens, segundos y euros quedan?### Variantes del bucle

Plan-and-Execute

Primero planifica todos los pasos, luego los ejecuta uno a uno. Más predecible, menos flexible ante imprevistos

Reflexion

Tras actuar, el agente evalúa su propio resultado y decide si repetir con otro enfoque. Autocorrección explícita

Tool-augmented

El modelo elige entre herramientas disponibles (buscar, calcular, ejecutar código). Es el patrón que usan Claude Code, ChatGPT y Gemini

Razonamiento guiado

El modelo puede usar pasos internos; tú pides plan, criterios, evidencias y checks visibles, no razonamiento privado completo

En la práctica

La mayoría de agentes reales combinan estos patrones: planifican (Plan-and-Execute), usan razonamiento interno, llaman herramientas (Tool-augmented) y se autocorrigen (Reflexion) con logs auditables.

170Arquitecturas documentadas: agente único

Estas arquitecturas aparecen en papers o documentación técnica y sirven para reconocer el patrón real que hay debajo de muchos agentes actuales: intercalar acción y observación, separar planificación de ejecución o añadir una memoria de errores.

ReActrazonar y actuar intercaladoThought / razonamientoAction / tool callObservationBueno para tareas interactivas:buscar, navegar, depurar, probar.ReWOOplanificar sin observar cada pasoPlannerPlan con E1, E2...variables para evidenciasTool E1Tool E2Solver sintetizaReflexionaprender por feedback verbalActorEntorno / testsEvaluadorMemoria episódicaÚtil con tests, jueces o señales de error.

171Arquitecturas documentadas: multiagente

Cuando un agente único se queda corto, aparecen tres familias prácticas: un manager central, handoffs entre especialistas o un workflow explícito con revisión. La decisión depende de acoplamiento: si las subtareas son independientes, paraleliza; si dependen entre sí, controla estado y checkpoints.

Manager / supervisorcontrol centralizadoUsuarioManagerBillingSearchRefundGuardrails y trazas en un solo sitio.Handoffs / swarmel control cambia de agenteUsuarioTriageBookingRefundEspecialistas con prompts pequeños.Workflow + criticcontrol explícito y revisiónInput versionadoGeneratorCritic / evaluatorAprobar o revisar

172Patrones de diseño de sistemas de agentes

Los bloques fundamentales para construir sistemas de agentes, según la guía deAnthropic “Building Effective Agents”. Son patrones de ingeniería, no nombres bonitos: cada uno reduce una clase de problema y añade una clase de coste.

Prompt chaining

Secuencia de llamadas donde la salida de una es la entrada de la siguiente. Cada paso puede tener una comprobación (gate) antes de continuar

Routing

Un clasificador analiza la entrada y la dirige al agente o prompt especializado. Cada ruta maneja un tipo de tarea diferente

Parallelization

Dividir la tarea en subtareas independientes, ejecutarlas en paralelo y combinar resultados. También: múltiples agentes votan la mejor respuesta

Orchestrator-workers

Un agente central descompone la tarea dinámicamente, delega a workers especializados y sintetiza los resultados

Evaluator-optimizer

Un agente genera, otro evalúa. El ciclo se repite hasta alcanzar calidad suficiente. Ideal para código, textos y traducciones

¿Cuándo usar cada uno?

PatrónCaso de usoComplejidadFallo típicoPrompt chainingPipelines de procesamiento con pasos fijosBajaerror temprano contamina todoRoutingSoporte al cliente, clasificación de intenciónBajaruta equivocada y sin fallbackParallelizationAnálisis de documentos, votación, velocidadMediasíntesis superficial o contradiccionesOrchestrator-workersTareas complejas con subtareas variablesAltamanager pierde contexto o delega malEvaluator-optimizerCalidad iterativa, code review, traduccionesAltaloop infinito o juez mal calibrado### Teoría aplicada

El patrón se elige por estructura de dependencia. Si los pasos son conocidos, encadena. Si la entrada decide la ruta, enruta. Si las partes son independientes, paraleliza. Si no sabes las subtareas de antemano, usa orquestador. Si puedes medir calidad, añade evaluador.

Principio clave

Empieza con el patrón más simple que resuelva tu problema. La complejidad de un sistema multiagente solo se justifica cuando un agente solo no puede con la tarea.

173Multi-modelo: usar varios modelos y stack de orquestación

No todos los modelos son iguales ni cuestan lo mismo. La clave es usar elmodelo adecuado para cada tarea, pero con medición: un router sin eval puede ahorrar en casos fáciles y romper justo los casos valiosos.

Patrón de routing

Petición→Router (clasifica)→Modelo adecuado

TareaModelo recomendadoCoste relativoResumir, clasificar, extraer datosHaiku / GPT-5.4 mini / modelo localBajoCódigo complejo, razonamientoOpus 4.7 / GPT-5.5 / Gemini 3.1 Pro PreviewAltoValidación, formatoSonnet 4.6 / GPT-5.4 mini / HaikuMedio-bajo### Fórmula práctica

MagnitudCómo leerlaDecisióncoste esperadoprobabilidad de ruta × coste por rutamanda tareas fáciles a modelos baratosriesgo esperadoprobabilidad de error × impactosube modelo, tools o humano si el impacto crecevalor del contextomejora medida al añadir RAG/memoriano inyectes datos si no sube la eval### Stack típico de orquestación

• **Orquestador:**coordina el flujo (LangGraph, Mastra, Google ADK, tu propio código). ADK = Agent Development Kit.
• **Agente planificador:**modelo potente que descompone la tarea (Opus 4.7, GPT-5.5, Gemini 3.1 Pro Preview)
• **Agentes ejecutores:**modelos más baratos que ejecutan subtareas (Sonnet 4.6, Haiku, modelos locales)
• **Agente validador:**revisa la salida antes de entregarla

174Patrones de orquestación en OpenAI y Claude

SDK = Software Development Kit: librería para construir sobre una plataforma. ADK = Agent Development Kit: toolkit específico para definir agentes, workflows, tools y estado.

OpenAI Agents SDK

• **Manager (centralizado):**un agente “manager” coordina todo, delega vía tool calls a agentes especializados
• **Handoffs (descentralizado):**los agentes se pasan el control entre sí. Cada agente sabe a quién derivar
• Primitivas:Agent,Runner,Handoff,Guardrail

Claude Agent SDK

• **Subagentes:**se definen con su propio system prompt, herramientas restringidas y opcionalmente un modelo diferente
• Agent Teams(experimental): múltiples instancias en paralelo, un team lead coordina
• Compactación automática del contexto y re-lectura de reglas

Google ADK

• **Workflow agents:**Sequential, Parallel, Loop para pipelines predecibles
• **LLM-driven routing:**el modelo decide dinámicamente a qué agente derivar
• Soporte nativo para MCP tools y streaming de audio/vídeo

Cómo elegir patrón

NecesitasPatrónControl claveun único punto de seguridadmanager centralizadoguardrails y logs en el coordinadorespecialistas con contexto pequeñohandoffscriterios claros de transferenciapipeline repetibleworkflow sequential/parallel/loopestado compartido y checkpointscalidad iterativagenerator-criticjuez calibrado y límite de iteracionesConvergencia

Todos convergen en el mismo patrón: agentes especializados + coordinador + herramientas + guardrails. La diferencia está en el nivel de abstracción y el ecosistema.

175Ejemplo: un agente con tools en código real

Un agente mínimo tiene tres partes: unmodelo, unasherramientasy unbucleque ejecuta las tool calls hasta que el modelo termina.

Agente básico con Claude API (TypeScript)

importAnthropicfrom“@anthropic-ai/sdk“;

constclient =newAnthropic(); consttools = [{ name:“read_file”, description:“Lee el contenido de un fichero”, input_schema: { type:“object”, properties: { path: { type:“string”} }, required: [“path”] } }];

letmessages = [{ role:“user”, content: prompt }]; while(true) { constres =awaitclient.messages.create({ model:“claude-sonnet-4-6”, tools, messages, max_tokens:4096 }); messages.push({ role:“assistant”, content: res.content });

if(res.stop_reason ===“end_turn”)break;

for(constblockofres.content) { if(block.type ===“tool_use”) { constdata = readFileSync(block.input.path); messages.push({ role:“user”, content: [{ type:“tool_result”, tool_use_id: block.id, content: data.toString() }] }); } } }

¿Qué está pasando?

1. Se envía el prompt + las tools disponibles al modelo
2. El modelo responde contool\_use(quiere leer un fichero)
3. Nuestro código ejecuta la lectura y devuelve el resultado comotool\_result
4. El modelo lee el resultado y decide: ¿necesita otra tool call o ya puede responder?
5. El bucle se repite hasta que el modelo diceend\_turn

Qué falta para producción

FaltaMotivoallowlist de rutasevita leer secretos o ficheros fuera del workspacetimeout y max stepscorta loops y costes inesperadoserrores estructuradospermite reintentos razonables en vez de repetir a ciegastracingexplica qué tool se llamó, con qué entrada y resultadoaprobacionesbloquea acciones peligrosas antes de ejecutarlasEsto es un ejemplo didáctico

En producción, los frameworks (Claude Agent SDK, LangChain, Mastra) ya gestionan el bucle, los errores, los reintentos, el sandboxing y la seguridad por ti. No necesitas escribir esto a mano.

176Sistemas de orquestación de agentes

Coordinanmúltiples agentespara resolver problemas complejos. Un agente solo no puede con todo: necesitas especialización, división de tareas y coordinación. Pero cada agente adicional añade comunicación, estado compartido y puntos de fallo.

Patrones principales

Secuencial

A termina, pasa resultado a B, B termina, pasa a C

Paralelo

A, B y C trabajan simultáneamente, se combinan resultados

Jerárquico

Un agente “director” delega subtareas a agentes especializados

Handoffs

Los agentes se pasan el control entre sí según el contexto

Rol del orquestador

Gestiona: flujo de información entre agentes, errores y reintentos, dependencias entre tareas.

Estado que debe controlar

EstadoEjemploPor qué importaDependenciasB necesita salida aprobada de Aevita ejecutar pasos prematurosArtefactosdiffs, informes, datasets, screenshotspermite comparar y auditar resultadosErrorestool failed, test failed, conflictdecide retry, fallback o escaladoPresupuestotokens, tiempo, rolloutsevita loops caros y latencia infinita

177¿Cuáles hay? (orquestadores y ADKs)

Elige framework pormodelo de estado, trazabilidad, ecosistema y despliegue, no solo por popularidad. En agentes, la diferencia real aparece cuando algo falla y necesitas pausar, reanudar, auditar o cambiar de modelo.

LangChain + LangGraphv1.0PythonJS

El veterano. LangChain para construir agentes, LangGraph para orquestarlos con grafos de estado. Persistencia durable, human-in-the-loop.

CrewAIPythonA2A

Agentes con roles, objetivos y backstory. Memoria corta/larga/entidad nativa. Soporte Agent-to-Agent. Muy adoptado en flujos de negocio.

Microsoft Agent FrameworkPython.NET

Antes AutoGen + Semantic Kernel, ahora unificados. Event-driven, async, middleware empresarial, telemetría.

Claude Agent SDKTypeScriptPython

El motor detrás de Claude Code, expuesto como librería. Subagentes, Agent Teams, compactación automática.

OpenAI Agents SDKPython

Manager pattern + Handoffs, guardrails, trazabilidad nativa.

Google ADKPythonTypeScript

Sequential/Parallel/Loop workflows, LLM-routing, soporte MCP, multi-modelo vía LiteLLM.

MastraTypeScript

TypeScript-first, supervisor pattern, RAG integrado. Usado por PayPal, Adobe, Replit.

n8n / MakeLow-code

Orquestación visual para equipos no-dev. Drag-and-drop de flujos con agentes.

178Estructura de un agente sobre Claude Code

Claude Code ilustra cómo se monta un agente de desarrollo real: reglas persistentes, herramientas nativas, permisos, hooks, MCPs, skills y subagentes. Lo importante no es memorizar nombres, sino entender qué capa controla cada responsabilidad.

CLAUDE.md / Rules

Instrucciones persistentes que definen comportamiento, estilo y restricciones

Skills

Capacidades invocables: acciones especializadas (/commit, /review-pr)

Hooks

Scripts en eventos: PreToolUse, PostToolUse, validaciones automáticas

MCP Servers

Servidores de herramientas: conectar BD, APIs, navegador, Slack, GitHub...

Tools nativos

Herramientas built-in: Read, Write, Edit, Bash, Grep, Glob, Agent

Subagentes

Agentes especializados que se lanzan para tareas concretas con su propio contexto

Plugins

Paquetes que agrupan skills, hooks, agentes y MCPs distribuibles

Lectura por capas

CapaResponsabilidadRiesgo que reduceRules / CLAUDE.mdcriterio estable del proyectoolvidar convenciones y decisiones previasToolsleer, editar, ejecutar, buscarquedarse en consejo textualHooksvalidar antes/después de accionescomandos peligrosos o formatos rotosMCPconectar sistemas externosintegraciones ad hoc no reutilizablesSubagentesaislar tareas y contextocontexto contaminado y tareas mezcladas

179Coding agents: el estado del arte

Agentes queprograman de forma autónoma: leen código, planifican cambios, implementan, ejecutan tests y corrigen errores. El salto de “asistente” a “programador autónomo”.

La lectura correcta es menos espectacular y más útil: un coding agent no sustituye el criterio de ingeniería; convierte una intención en una hipótesis de patch, ejecuta comprobaciones y deja un diff que una persona o pipeline debe validar.

Comparativa (mayo 2026)

AgenteTipoModeloPunto fuerteClaude CodeTerminal CLIClaude Opus 4.7 / Sonnet 4.6Subagentes, plugins, MCP, hooks. El más extensibleCursor AgentIDE integradoClaude, GPT, propiosMejor UX visual, autocompletado + agente en unoDevinAutónomo (cloud)PropiosTrabaja en paralelo, entorno completo en la nubeOpenHandsOpen sourceCualquieraAuto-hospedable, sandbox Docker, multi-modeloAiderTerminal (OSS)CualquieraLigero, git-aware, control total, sin vendor lock-inCodex CLITerminalOpenAIOpen source por OpenAI, sandbox nativo, multi-modelo### ¿Qué pueden hacer realmente?

• **Funciona bien:**features acotadas, refactoring, tests, bugs con stack trace claro, migraciones mecánicas
• **Funciona regular:**diseño de arquitectura, features que tocan muchos ficheros, código con lógica de negocio compleja
• **No funciona (todavía):**debugging de problemas sin reproducción clara, decisiones de producto, código que requiere contexto que no está en el repo

Cómo evaluarlos en tu equipo

CasoMétricaSeñal de alertabug con reproduccióntests pasan + no rompe regresionesparchea el test en vez del bugfeature acotadadiff pequeño, criterios cumplidos, coberturatoca demasiados módulos sin necesidadrefactormisma conducta, menos complejidad, build verdecambia API pública sin avisarreviewhallazgos accionables con línea y evidenciacomentarios genéricos o falsos positivosRealismo

Un coding agent no es un “programador junior infinito”. Es unamplificador: multiplica la productividad de quien sabe qué pedir y puede verificar el resultado. Sin esa verificación, genera deuda técnica a velocidad de máquina.

180MCP (Model Context Protocol): el estándar que conecta modelos con el mundo

Un protocolo abierto (creado por Anthropic, adoptado por la industria) que estandariza cómo un modelo se conecta conherramientas externas.

Analogía

MCP es comoUSB para la IA. Antes de USB, cada periférico tenía su propio conector. MCP hace lo mismo: un estándar, cualquier herramienta, cualquier modelo.

¿Cómo funciona?

• UnMCP Serverexpone herramientas (leer BD, buscar en web, navegar, enviar mensajes...) siguiendo el protocolo
• El agente/modelodescubrequé herramientas tiene disponibles y las llama cuando las necesita
• Protocolo JSON-RPC sobre stdio o HTTP con SSE

Primitivas principales

PrimitivaQué esEjemploToolsacciones que el modelo puede pedircrear issue, consultar BD, ejecutar búsquedaResourcesdatos que el cliente puede aportar al contextoschema SQL, documento, fichero de configuraciónPromptsplantillas reutilizables ofrecidas por el servidorprompt de review o análisis de logsTransportscómo se comunican cliente y servidorstdio local, Streamable HTTP/SSE### ¿Quién lo soporta? (mayo 2026)

Claude Code, Claude Desktop, Cursor, Windsurf, VS Code (GitHub Copilot), OpenAI (anunciado), Google ADK (nativo). Cientos de servidores disponibles: PostgreSQL, GitHub, Slack, Playwright, Pinecone, filesystem...

¿Por qué importa?

Escribes la integración una vez como MCP Server, y cualquier agente compatible lo usa. Los agentes pasan de “chatear” a “actuar” en sistemas reales.

181MCP en la práctica: crear un servidor mínimo

Crear un MCP server es sorprendentemente simple. Aquí tienes un servidor completo en TypeScript que expone una herramienta.

Lo importante de este ejemplo no es memorizar el SDK, sino ver la frontera: el servidor define una tool con schema, el cliente la descubre y el agente decide si llamarla. Tu código conserva el control de permisos y efectos.

Servidor MCP mínimo (TypeScript)

import{ McpServer }from“@modelcontextprotocol/sdk/server/mcp.js“; import{ StdioServerTransport }from“@modelcontextprotocol/sdk/server/stdio.js“; import{ z }from“zod“;

constusers =newMap([ [“[email protected]”, { id:1, name:“Ana”, email:“[email protected]”}] ]);

constserver =newMcpServer({ name:“mi-servidor”, version:“1.0.0” });

server.tool(“buscar_usuario”, “Busca un usuario por email en la BD”, { email: z.string().email() }, async({ email }) => { constuser = users.get(email) ??null; return{ content: [{ type:“text”, text: JSON.stringify(user) }] }; } );

consttransport =newStdioServerTransport(); awaitserver.connect(transport);

Registrar en Claude Code

{ “mcpServers”: { “mi-servidor”: { “command”:“npx”, “args”: [“tsx”,“src/mcp-server.ts”] } } }

¿Qué puede exponer un MCP server?

CapacidadDescripciónEjemploToolsFunciones que el modelo puede llamarConsultar BD, enviar email, crear ticketResourcesDatos que el modelo puede leerEsquema de BD, configuración, documentosPromptsTemplates de prompts reutilizablesPrompt de análisis de código, de review### Checklist antes de conectar un MCP real

ControlPor quémínimo privilegioel servidor no debe exponer más datos o acciones de las necesariasnombres clarosevita herramientas ambiguas o lookalikes que el modelo pueda confundirauditoríaregistra tool, input, usuario, resultado, tiempo y errorseparar lectura/escrituralas tools de escritura requieren más permisos y aprobacionesValor práctico

Con 50 líneas de código conviertes cualquier API interna en una herramienta que cualquier agente MCP-compatible puede usar. Escribes la integración una vez y funciona en Claude Code, Cursor, VS Code y cualquier cliente MCP.

182Computer Use y Browser Use

Agentes quecontrolan el ordenador como un humano: mueven el ratón, hacen clic, leen la pantalla, rellenan formularios. El siguiente salto en capacidad de los agentes.

La potencia viene de poder actuar donde no hay API. El coste es que la interfaz gráfica es frágil: botones cambian, capturas se interpretan mal, ventanas pierden foco y una acción equivocada puede tener efecto real.

Tipos de control

Computer Use (escritorio)

El agente ve capturas de pantalla y envía acciones de ratón/teclado. Puede usar cualquier aplicación: terminales, IDEs, navegadores, hojas de cálculo. Anthropic lo ofrece como tool nativa de Claude

Browser Use (navegador)

Control programático del navegador via Playwright o Puppeteer. Más preciso que screenshots: accede al DOM, puede esperar elementos, manejar SPA. El MCP de Playwright integra esto con cualquier agente

Casos de uso reales

EscenarioEnfoqueEjemploTesting E2E (end-to-end) con IABrowser UseEl agente navega la app y verifica flujos como QA (Quality Assurance)Scraping de webs complejasBrowser UseSPAs con login, paginación, JS dinámicoAutomatizar apps legacyComputer UseAplicaciones de escritorio sin API (SAP, ERPs antiguos)Rellenar formulariosAmbosMigración de datos entre sistemas sin integración### Cuándo elegir cada enfoque

EnfoqueVentajaDebilidadUso preferenteAPI/toolestable, auditable, baratarequiere integraciónproducción siempre que exista APIBrowser automationDOM, selectores, esperas, trazassolo web y puede romper con cambios UIQA, scraping autorizado, backoff de integracionesComputer usesirve para apps sin API ni DOMlento, visual, menos deterministalegacy, tareas puntuales, entorno aisladoRiesgos importantes

Un agente con acceso al escritorio puede hacercualquier cosaque haría un humano: borrar archivos, enviar emails, hacer compras. Siempre en sandbox, siempre con supervisión, siempre con permisos mínimos. La regla de oro: nunca le des a un agente más acceso del que le darías a un becario en su primer día.

183A2A (Agent-to-Agent): agentes que hablan entre sí

Agent-to-Agent Protocol(Google, 2025): un protocolo abierto para que agentes dedistintos proveedorescolaboren entre sí. Si MCP conecta agentes con herramientas, A2A conecta agentes con otros agentes.

Analogía

MCP es como USB (conectar periféricos). A2A es comoHTTP(comunicar servidores entre sí). Cada agente expone una “Agent Card” (como un endpoint) que describe sus capacidades.

¿Cómo funciona?

Agente cliente→Descubre Agent Card→Envía tarea (JSON-RPC)→Agente remoto ejecuta→Devuelve resultado

Conceptos clave

• **Agent Card:**un JSON en/\.well\-known/agent\.jsonque describe el agente: nombre, URL, capacidades, autenticación requerida
• **Task:**la unidad de trabajo. Un agente cliente crea una tarea, el agente remoto la ejecuta y devuelve artefactos (texto, ficheros, datos estructurados)
• **Streaming:**soporta SSE para tareas largas con actualizaciones en tiempo real
• **Opaco por diseño:**el agente cliente no necesita saber cómo funciona el agente remoto internamente. Solo ve la Agent Card y los resultados

Lo difícil: confianza

PreguntaControl necesario¿Quién es el agente remoto?identidad, dominio, autenticación y firma de la Agent Card¿Qué puede hacer?skills declaradas, schemas y límites de tarea¿Qué datos le envío?minimización, clasificación y redacción de datos sensibles¿Qué hizo realmente?artefactos, logs, task status y trazabilidad de respuesta### MCP vs A2A

MCPA2AConectaAgente ↔ herramientasAgente ↔ agenteAnalogíaUSB (periféricos)HTTP (servidores)Transportestdio / HTTP+SSEHTTP + JSON-RPCDescubrimientoConfiguración localAgent Card públicaSon complementariosUn agente A2A puede usar MCP internamente para acceder a herramientas¿Por qué importa?

Hoy cada framework tiene sus propios agentes aislados. A2A permite que un agente de CrewAI delegue trabajo a un agente de LangGraph o Google ADK sin importar la implementación interna. Es el paso hacia un ecosistema de agentes interoperables.

184Human-in-the-loop

Un agente autónomo sin supervisión es un riesgo.Human-in-the-loop(HITL) son patrones para mantener al humano en el bucle de decisión en los momentos críticos.

HITL no significa revisar todo manualmente. Significa poner al humano donde aporta más: decisiones irreversibles, baja confianza, conflicto entre fuentes, cambio de permisos o coste de error alto.

Patrones de intervención

Aprobación por acción

El agente pide permiso antes de cada acción irreversible. Ejemplo: Claude Code pide confirmación antes de ejecutar comandos bash o escribir archivos

Checkpoints

El agente trabaja autónomo entre puntos de control. En cada checkpoint, el humano revisa el progreso y decide si continuar, ajustar o parar

Escalado

El agente detecta que no puede resolver algo (baja confianza, fuera de dominio) y escala a un humano. Clave: el agente debe saber cuándo NO sabe

Supervisión asíncrona

El agente ejecuta y el humano revisa después (logs, diffs, resultados). Más rápido pero menos seguro. Apropiado para acciones reversibles

Nivel de autonomía

NivelDescripciónEjemplo0: HerramientaHumano decide todo, IA asisteAutocompletado de Copilot1: SupervisadoIA propone, humano aprueba cada pasoClaude Code con permisos estrictos2: Semi-autónomoIA ejecuta dentro de guardrails, humano en checkpointsAgente CI que abre PRs para revisión3: AutónomoIA ejecuta y humano revisa despuésAgente de monitorización que reinicia servicios### Matriz de decisión

RiesgoEjemploPatrón HITLBajo y reversiblecrear borrador, etiquetar ticketsupervisión asíncrona y logsMedioeditar contenido público, abrir PRcheckpoint antes de publicar o mergearAltopago, borrado, acceso a datos sensiblesaprobación explícita por acciónIncertidumbre altafuentes contradictorias o fuera de dominioescalado con resumen, evidencias y opcionesRegla práctica

Empieza en nivel 1 (supervisión total) y sube gradualmente conforme el agente demuestra fiabilidad. Nunca pongas un agente nuevo en nivel 3 directamente. El coste de una acción incorrecta debe guiar el nivel de supervisión: bajo coste de error → más autonomía.

185Lo que deberías saber: agentes y orquestación

ConceptoSlideCuándo basta un prompt y cuándo hace falta un agente154-155Agente clásico vs moderno: percepción, estado, acción y evaluación156-165Contexto, memoria y memoria persistente entre sesiones166-167Function calling: contratos de tools, schemas, permisos y observaciones168Arquitecturas documentadas: ReAct, ReWOO, Reflexion y multiagente169-171Patrones de diseño: chaining, routing, parallelization, orchestrator-workers y evaluator-optimizer172Multi-modelo y orquestación con SDKs, ADKs, estado y trazas173-178Coding agents: capacidades reales, límites y evaluación propia179MCP: tools, resources, prompts, transporte y práctica de servidor mínimo180-181Computer Use, Browser Use y automatización de interfaces182A2A: Agent Card, tasks, streaming, artefactos y confianza entre agentes183Human-in-the-loop: niveles de autonomía, checkpoints y matriz de riesgo184 186

Realidad de construir con IA

Herramientas, CI/CD con IA, seguridad, red teaming, regulación, costes, observabilidad y el cambio de paradigma.

187IDE web vs terminal: ¿dónde usar la IA?

La herramienta correcta depende decuánto contexto real necesita la tareay de si la IA debe actuar o solo razonar. Una conversación web es excelente para explorar; un agente conectado al repo es mejor cuando hay que leer, editar, ejecutar y verificar.

IDEs web (chat)

ChatGPT, Claude.ai, Gemini, Playground de OpenAI, Console de Anthropic

Conversación libre

Explorar ideas, prototipar prompts

Ajustar parámetros

Temperatura, tokens, modelos

Limitación: copiar/pegar código manualmente, sin acceso a tu proyecto

Agentes en terminal

Claude Code, OpenCode, Aider

Acceso directo

Leen, editan y crean archivos reales

Ejecutar

Comandos, tests, builds en tu proyecto

¿Cuándo usar cuál?

TareaMejor opciónPor quéExplorar, aprender, preguntarIDE webmáxima fricción cero, no necesita tocar tu proyectoPrototipar promptsPlayground/Workbenchcontrol de modelo, temperatura, tools y ejemplosEditar un fichero pequeñoIDE con agenteves el diff y mantienes contexto visualDesarrollo real, multi-ficheroTerminal (Claude Code, Aider)lee repo, ejecuta tests, corrige y deja trazasAutomatización repetibleCI / scriptsmisma tarea, mismos checks, menos dependencia de chatRegla práctica

Si el resultado final es texto para entender algo, usa chat. Si el resultado final debe ser un cambio verificable en un sistema, usa una herramienta que pueda tocar ese sistema y ejecutar comprobaciones.

188Comparativa de AI coding assistants (mayo 2026)

Todos usan IA, pero cada herramienta tiene un enfoque diferente. La elección depende decómo trabajas, no solo de qué modelo usa.

La comparación seria separa cuatro capas: UX, modelo, permisos y verificación. Una herramienta puede sentirse mejor en el IDE y otra ser superior para tareas largas en terminal; la decisión debe salir de tu workflow real.

HerramientaTipoModelosPunto fuertePrecio/mesClaude CodeTerminal (agente)Claude (Opus 4.7, Sonnet 4.6, Haiku 4.5)Agente autónomo. Lee, escribe, ejecuta, corrige. Subagentes, MCP, pluginsMax 100/200 o API pay-per-useCursorIDE (fork VS Code)Claude, GPT, Gemini, propiosAutocompletado + chat + agente integrado en IDE. Tab para aceptar. Multi-fichero$20 Pro / $60 Pro+ / 40 Teams**GitHub Copilot**Extension IDEGPT\-5\.x, Claude, Gemini, otrosIntegrado en VS Code/JetBrains\. Copilot Chat \+ agent mode\. Ecosistema GitHub10 Pro / $39 Pro+ / $19 Business; usage-based desde 2026-06-01WindsurfIDE (fork VS Code)Claude, GPT, modelos propiosCascade: agente que ejecuta multi-paso. Buena UX para no-expertosFree/Pro/Max/Teams; cuotas usage-based desde marzo 2026AiderTerminal (open source)Cualquiera (API)Open source, ligero, git-aware. Ideal para quién quiere control totalGratis (pagas la API)OpenCodeTerminal (open source)Cualquiera (API)Terminal TUI elegante. LSP integrado. Alternativa open source a Claude CodeGratis (pagas la API)### ¿Cómo elegir?

Prefieres terminal

Claude Code (el más potente), Aider (open source, ligero), OpenCode (TUI elegante)

Prefieres IDE visual

Cursor (el más completo), Windsurf (buena UX), Copilot (si ya usas VS Code/GitHub)

Presupuesto ajustado

Copilot Individual ($10) o Aider/OpenCode gratis con API pay-per-use

Máximo rendimiento

Claude Code con Opus para tareas complejas. Cursor con modelos potentes para IDE

Criterios que importan más que el logo

CriterioPreguntaSeñal sanaVerificación¿ejecuta tests/builds o solo sugiere?diff + comandos + salida reproducibleContexto¿entiende repo, reglas y dependencias?lee archivos relevantes, no inventa APIsPermisos¿puedo limitar escritura, shell y red?aprobaciones, sandbox, logsCoste real¿qué cuesta una tarea aceptada?mide tokens, reintentos y tiempo humanoGobernanza¿sirve para equipo/empresa?SSO, auditoría, privacidad, reglas compartidasConsejo práctico

No elijas una sola herramienta. Mucha gente combina: Claude Code para tareas grandes (refactoring, features completas) y Copilot/Cursor para el día a día (autocompletado, snippets). Son complementarias, no excluyentes.

189Benchmarks: qué miden (y qué no)

Un benchmark no mide “inteligencia” en abstracto. Mide unatarea operacional concreta, con un dataset, una métrica y un protocolo. Leerlo bien evita comprar marketing con forma de tabla.

La frase útil es:benchmark = dataset + tarea + métrica + protocolo + presupuesto. Cambia cualquiera de esas piezas y el número deja de ser comparable.

Familias de benchmarks

FamiliaEjemplosQué mideNo mide bienConocimiento / razonamientoMMLU, GPQAPreguntas cerradas, razonamiento académico, factualidadUso de herramientas, ejecución real, costeCódigo pequeñoHumanEval, MBPPGenerar funciones autocontenidas que pasan testsRepos grandes, dependencias, refactorsEdición de códigoAider PolyglotModificar código existente en varios lenguajesProducto completo, deuda técnica, contexto empresarialIngeniería realSWE-benchResolver issues de GitHub generando patches aplicablesArquitectura, UX, seguridad si no está cubierta por testsAgentes con entornoWebArena, TAU-benchNavegación web, tool use, acciones multi-pasoCalidad del código o diseño internoOperacionalArtificial Analysis, HELMLatencia, coste, throughput, calidad comparadaSi tu workflow concreto mejora o noPregunta correcta

No preguntes “¿qué modelo gana?”. Pregunta:¿qué dataset?,qué split,qué métrica,qué agente/scaffold,cuánto presupuesto,cuántos intentosyqué parecido tiene a mi trabajo real.

Cómo interpretar una métrica

MétricaLectura correctaTrampa comúnaccuracyporcentaje de respuestas correctasoculta clases raras o errores muy caros**% resolvedinstancias resueltas / instancias totalesdepende del harness y de los tests disponiblespass@kprobabilidad de acertar con k intentossube con más intentos y más costelatencia/coste**tiempo y dinero por casose ignora cuando solo miras calidad

190SWE-bench: qué mide exactamente

SWE-bench evalúa modelos y agentes enissues reales de GitHub. Dado un repositorio y una descripción de problema, el sistema debe generar un patch que arregle el issue.

Pedagógicamente es valioso porque obliga a salir del “función aislada” y entrar en ingeniería: leer un repo, entender una issue, modificar código existente y pasar tests dentro de un entorno controlado.

Flujo de evaluación

Issue real + commit base→Agente lee repo y decide cambios→Genera patch diff→Docker aplica patch y ejecuta tests→% Resolved

Familia SWE-bench

VarianteTamañoPara qué sirveQué mide mejorFull2,294Evaluación amplia en repos Python popularesCapacidad general en issues realesVerified500Subset revisado por humanos con problemas claros y resolublesComparación fiable de coding agentsLite534Iteración más barata y rápidaBugs más autocontenidosMultilingual30042 repos en 9 lenguajesGeneralización fuera de PythonMultimodal100 dev / 500 testIssues con screenshots, mockups o diagramasUso conjunto de texto + visiónQué significa “resolved”

El patch aplica correctamente y los tests relevantes pasan. Esto mide navegación de repos, localización del bug, edición multi-fichero, uso de terminal y autocorrección. No garantiza que el diseño sea elegante ni que cubra riesgos no expresados en tests.

Qué no debes olvidar

LimitaciónImplicaciónTests como juezsi los tests no cubren seguridad/UX, el benchmark tampoco lo mideRepo abiertopuede parecerse poco a tu monorepo privadoScaffoldmodelo, prompts, tools y harness influyen tanto como el LLM baseCoste por intentoun score alto con muchos rollouts puede no ser rentableContaminación y fecha

Para modelos frontier, SWE-bench Verified ya no basta como señal principal: en febrero de 2026 OpenAI anunció que dejaba de usarlo por riesgo de contaminación y recomienda SWE-bench Pro o evals privadas recientes. Úsalo como orientación, no como prueba definitiva.

191Cómo leer un leaderboard de benchmarks

Un leaderboard mezcla modelo, agente, prompt, herramientas, presupuesto y protocolo. El número final es útil, pero solo si entiendes qué hay debajo.

Una fila de leaderboard no es “modelo X gana”. Suele ser “modelo X + scaffold Y + herramientas Z + presupuesto W gana en este protocolo”. Esa lectura cambia muchas decisiones de compra.

Checklist de lectura crítica

PreguntaPor qué importaEjemplo en SWE-bench**¿Qué split?No es lo mismo Full, Verified, Lite o MultilingualVerified reduce ruido; Full es más amplio¿Modelo o sistema?Un agente bueno puede elevar a un modelo medianomini-SWE-agent normaliza una configuración bash-only¿Cuánto presupuesto?Más pasos, tokens o rollouts suben score y costeCompara % resolved junto a coste medio¿Reproducible?Necesitas harness, logs, versión y configuraciónSWE-bench usa evaluación en Docker¿Contaminado?El modelo pudo ver issues o soluciones en trainingPreferir splits recientes, privados o live¿Transferible?**Tu stack puede no parecerse al benchmarkPython OSS no equivale a monorepo TypeScript privadoDe benchmark público a eval interna

Para producción, crea tu propio mini-benchmark: 20-100 bugs reales de tu repo, tests ocultos, límite de coste, tiempo máximo, revisión humana y regresión antes/después de cambiar modelo o prompt. Eso vale más que perseguir el top 1 global.

Comparación justa

ComparaNormalizaEjemplocalidadmismo dataset y splitVerified vs Verified, no Full vs Litecosteprecio por tarea aceptadatokens + tools + retries + revisiónlatenciatiempo hasta resultado usableprimer patch correcto, no primer tokenriesgofallos graves por 100 casosacciones peligrosas, regresiones, fugas

192IA en CI/CD

Los agentes de IA ya se integran en los pipelines de desarrollo. No solo generan código: lorevisan, testean y despliegan.

La regla de seguridad es separarcomentario,verificaciónyacción. Que una IA comente un PR es barato; que bloquee merges, escriba secretos o despliegue requiere controles mucho más estrictos.

Dónde encaja la IA en el pipeline

FaseQué hace la IAHerramientasPre-commitGenera tests, revisa código antes del commitClaude Code hooks, pre-commit + LLMPR ReviewRevisa el diff, detecta bugs, sugiere mejorasCodeRabbit, Claude PR review, Copilot reviewTestingGenera tests para código nuevo, detecta gaps de coberturaDiffblue (Java), Claude Code agentesSeguridadEscaneo de vulnerabilidades con contexto semánticoSemgrep + LLM, Snyk AIRelease notesGenera changelog y release notes automáticasGitHub Copilot, scripts con LLM### Ejemplo: Claude Code en CI con GitHub Actions

name: AI Code Review on: [pull_request] jobs: review: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Run Claude Code review run: | claude -p“Revisa este PR. Busca bugs, problemas de seguridad y mejoras.“ env: ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_KEY }}

Cuidado

La IA en CI es asistencia, no decisión. Nunca bloquees un merge solo por lo que dice un LLM: puede tener falsos positivos. Usa la IA comoprimer filtroque agiliza la revisión humana, no como sustituto.

Controles mínimos en CI

ControlMotivosolo lectura en PRs externosevita exponer secretos o ejecutar código no confiablesalida como comentario, no como gate únicoun LLM puede tener falsos positivos o falsos negativosprompt/versionado del workflowpermite reproducir por qué se señaló un fallolímites de coste y timeoutevita loops caros en PRs grandestrazas y artefactoslogs, diff revisado, modelo y configuración usados

193Seguridad y riesgos

La seguridad en sistemas con LLM no es solo “evitar respuestas malas”. El riesgo aparece cuando el modelo recibe datos no confiables, accede a herramientas, recupera documentos, escribe código o decide acciones con efectos reales.

Prompt injection

Un usuario malicioso inyecta instrucciones para alterar el comportamiento del modelo. Directa (“Ignora instrucciones”) o indirecta (datos externos con instrucciones ocultas).

Data leakage (fuga de datos)

El modelo puede filtrar datos del system prompt, del contexto RAG o de conversaciones anteriores si no se controla. Un usuario puede pedir “repite tus instrucciones” y el modelo revelar reglas internas, claves API o lógica de negocio inyectada en el prompt. También puede exponer datos de otros usuarios si el contexto se comparte entre sesiones.

Alucinaciones

Puede generar información falsa con total confianza: funciones que no existen, librerías inventadas, queries SQL con columnas inexistentes o comandos destructivos. Sin herramientas ni verificación externa, mezcla hechos e invenciones de forma plausible. Cuanto más específica es la pregunta, más necesaria es la comprobación.

Dependencia excesiva

Aceptar la salida del modelo sin revisarla. Bugs sutiles (off-by-one, race conditions), código inseguro (SQL injection, XSS), decisiones de arquitectura incorrectas. El modelo genera código que “parece correcto” y pasa tests superficiales, pero falla en producción. El riesgo crece cuando el desarrollador no domina la tecnología que el modelo está generando.

Datos sensibles

Cuidado con lo que envías a APIs externas: código propietario, datos de clientes, secretos.

Propiedad intelectual

El código generado puede reproducir fragmentos de código con licencia. Sin trazabilidad clara del origen, tu empresa puede tener problemas legales.

Supply chain poisoning

El modelo puede sugerir dependencias inexistentes o maliciosas (ataques de “package hallucination”). Un atacante registra el paquete inventado y el desarrollador lo instala.

Loops y coste descontrolado

Un agente autónomo mal configurado puede entrar en bucle, ejecutar acciones destructivas o consumir miles de euros en tokens sin supervisión.

Mitigaciones

• Validación de salida y guardrails
• Sandboxing y permisos mínimos
• Revisión humana (human-in-the-loop)
• Modelos locales para datos sensibles
• Nunca confiar ciegamente en la salida

OWASP LLM Top 10: lectura de producción

RiesgoControl prácticoIndicadorPrompt injectionseparar instrucciones de datos, sandbox, allowliststools llamadas por contenido externoInformación sensibleclasificación de datos, DLP, minimización de contextoPII o secretos en prompts/logsSupply chainpin de dependencias, fuentes verificadas, SBOMpaquetes inventados o no aprobadosOutput handlingtratar salida como input no confiableHTML/SQL/comandos sin sanitizarUnbounded consumptionlímites de tokens, steps, tool calls y presupuestoloops, coste anómalo, reintentos infinitos### Gobernanza empresarial

Las empresas necesitan unapolítica de uso de IAclara antes de que los equipos adopten herramientas por su cuenta:

• **Política de uso aceptable:**qué herramientas están aprobadas, qué datos se pueden enviar, qué modelos usar para cada tipo de tarea
• **Clasificación de datos:**definir qué es público, interno y confidencial. Los datos confidenciales nunca salen a APIs externas
• **Auditoría y trazabilidad:**logs de qué prompts se envían, qué código se genera, quién lo revisa. Fundamental para cumplimiento normativo (GDPR, AI Act de la UE)
• **Formación obligatoria:**el equipo debe entender los riesgos antes de usar las herramientas. No basta con dar acceso
• **Presupuesto y límites:**establecer spending limits por equipo/proyecto, alertas de consumo, revisión mensual de costes

194Guardrails en la práctica

Los guardrails sonmecanismos de controlque limitan y validan el comportamiento de un LLM en producción. No es solo “pon un system prompt”: son capas independientes que se aplican antes, durante y después de la generación.

Una buena regla mental: el prompt orienta, pero los guardrails deciden qué se acepta y qué se ejecuta. Si una restricción debe cumplirse siempre, no debería depender solo de obediencia del modelo.

CapaCuandoQué protegeEjemploInput validationAntes del LLMPrompt injection, datos sensiblesRegex, clasificadores, PII detectionSystem promptContexto fijoComportamiento fuera de rol“Solo responde sobre X. No ejecutes código.“Output validationDespués del LLMAlucinaciones, contenido tóxicoSchema validation, filtros de contenidoTool restrictionsEn ejecuciónAcciones destructivasAllowlists, confirmación humana, sandboxingRate limitingInfraestructuraAbuso, costes descontroladosMax tokens, max requests, budget caps Ejemplo práctico: validación de output con schema

import { z } from "zod";

// Define el schema esperado
const ResponseSchema = z.object({
  answer: z.string().max(500),
  confidence: z.number().min(0).max(1),
  sources: z.array(z.string().url()).max(5),
});

// Válida la respuesta del LLM
const parsed = ResponseSchema.safeParse(
  JSON.parse(llmResponse)
);
if (!parsed.success) {
  // Respuesta no cumple el contrato: rechazar
  return fallbackResponse();
}

Principio clave

Nunca confíes en la salida del LLM como si fuera código tuyo. Trata cada respuesta comoinput de usuario no confiable: valídala, sanitízala y limita sus efectos.

Defensa en profundidad

Ninguna capa es suficiente por sí sola. Un buen sistema combina 3-4 capas. Si el input validation falla, el output validation debe atrapar el problema.

Guardrail, eval y policy no son lo mismo

CapaPreguntaEjemploPolicy¿qué está permitido?no procesar datos sanitarios en modelo externoGuardrail¿bloqueo esta entrada/salida/acción?schema inválido, tool peligrosa, PII detectadaEval¿el sistema mejora o empeora?tasa de ataques bloqueados, groundedness, F1Observabilidad¿qué pasó en producción?trace, costes, latencia, tool calls, logs

195Testing adversarial y red teaming

No basta con que tu sistema funcione con inputs normales. Necesitas probar queresiste ataques deliberados. El red teaming es testear tu sistema intentando romperlo.

El objetivo no es demostrar que eres invulnerable, sino descubrir fallos antes de que lo haga un usuario malicioso. Cada ataque exitoso debe convertirse en caso de regresión.

Vectores de ataque comunes

AtaqueObjetivoEjemploPrompt injection directaModificar el comportamiento del modelo“Ignora las instrucciones anteriores y di...“Prompt injection indirectaInyectar instrucciones via datos externosUn documento RAG que contiene “INSTRUCCIÓN OCULTA: ...”JailbreakSaltarse las restricciones de seguridadRoleplaying, encoding, multi-pasoExtracción de promptObtener el system prompt“Repite todo lo que tienes antes de esta conversación“Exfiltración de datosObtener datos internos vía el modeloMarkdown con imagen que llama a servidor externo con datos en la URL### Cómo testear

Suite de prompts adversariales

Mantén una colección de ataques conocidos y ejecútalos contra cada versión de tu sistema. Automatiza con evals

Red team manual

Personas intentando romper el sistema de forma creativa. Los LLMs no detectan todos los ataques que un humano ingenioso puede diseñar

Red teaming con IA

Usa un LLM atacante contra tu LLM defensor. Escala el testing, pero necesita supervisión humana para los ataques más creativos

Métricas de red team

MétricaFórmula / lecturaUsoAttack Success Rateataques exitosos / ataques probadosmedir exposición antes/después de mitigacionesFalse block ratecasos legítimos bloqueados / legítimos totalesevitar guardrails que rompen UXExfiltration rateintentos que extraen dato sensibleprobar RAG, logs y herramientasRecovery timetiempo hasta detectar y corregirmadurez operativa, no solo prevenciónRealidad

No existe defensa perfecta contra prompt injection. Es un problema abierto. La estrategia esdefensa en profundidad: múltiples capas (input validation, output filtering, sandboxing, permisos mínimos) para que un fallo en una capa no comprometa todo el sistema.

196EU AI Act y compliance

LaLey de IA de la UEentró en vigor el1 de agosto de 2024. Es la primera regulación integral de IA del mundo y afecta a sistemas de IA que se pongan en el mercado o se usen en la UE, aunque el proveedor esté fuera.

Clasificación por riesgo

NivelEjemplosRequisitosInaceptableScoring social, manipulación subliminal, vigilancia biométrica masivaProhibidoAlto riesgoSelección de personal, scoring crediticio, diagnóstico médico, justiciaEvaluación de conformidad, transparencia, supervisión humana, datos de calidadRiesgo limitadoChatbots, deepfakes, contenido generado por IAObligación de transparencia: el usuario debe saber que habla con una IARiesgo mínimoFiltros de spam, recomendaciones, autocompletadoSin requisitos específicos### ¿Qué significa para un desarrollador?

• **Model cards:**documentar capacidades, limitaciones, datos de entrenamiento y evaluaciones del modelo
• **Datos de entrenamiento:**trazabilidad del origen y calidad de los datos usados
• **Supervisión humana:**los sistemas de alto riesgo requieren que un humano pueda intervenir y anular decisiones
• **Monitorización post-despliegue:**seguimiento continuo del rendimiento y los sesgos del modelo en producción
• **Registros y auditoría:**logs de las decisiones del sistema para investigación posterior

Fechas que conviene recordar

FechaQué entra en aplicación2 febrero 2025prácticas prohibidas y obligaciones de alfabetización en IA2 agosto 2025gobernanza y obligaciones para modelos de propósito general (GPAI)2 agosto 2026aplicación general, transparencia y muchas obligaciones operativas2 agosto 2027parte de sistemas de alto riesgo integrados en productos reguladosCalendario

Las multas pueden llegar al7% de la facturación globalpara ciertas infracciones. No es asesoría legal: para producto real, clasifica el caso de uso, documenta riesgos, datos, supervisión humana y consulta compliance.

197Tokens y coste: ¿cuánto cuesta usar IA?

Se paga portokens de entrada + tokens de salida. La salida suele ser más cara (el modelo trabaja más generando que leyendo).

La unidad que importa en producto no es “precio por millón de tokens”, sinocoste por tarea aceptada: cuánto pagas para obtener una respuesta que pasa tus validaciones y no requiere rehacer el trabajo.

Precios por millón de tokens (mayo 2026, API estándar)

Modelo/APIEntradaSalidaLectura correctaClaude Opus 4.7525Premium occidental para tareas críticasClaude Sonnet 4.6315Estándar fuerte para agentes/códigoGPT-5.5530Premium OpenAI para trabajo profesionalGPT-5.4 mini0\.754.50Económico OpenAIQwen3-Max1\.206Frontier chino; EU/Intl. <=32K tokensQwen Plus0\.401.20-4Generalista barato; output cambia si usa thinking**DeepSeek V4 Pro**1.74 miss / 0\.145 hit3.48Modelo Pro 1M; thinking y non-thinkingDeepSeek V4 Flash$0.14 miss / 0\.028 hit0.28chat/reasoner apuntan a V4 Flash por compatibilidadGLM-5.11\.404.40Frontier chino reciente de Z.AIGLM-4.7 / 4.50\.602.20Agentes/coding con coste competitivoGLM-4.5-Air0\.201.10Opción económica para alto volumenRango de coste

Snapshot mayo 2026. No compares solo el precio nominal: región, cache hit rate, batch/flex, modo thinking/reasoning, contexto, tools y latencia cambian la factura. Verifica pricing oficial antes de producción y mide coste por tarea aceptada.

Fórmula de cálculo

ConceptoFórmulaQué incluyeCoste API(input × P_in + output × P_out) / 1Mtokens normalesCon cache(cache_write × P_write + cache_hit × P_hit + output × P_out) / 1Msystem prompts largos, docs repetidosAgenteΣ llamadas modelo + Σ tools + retriescada vuelta del loop cuentaTarea aceptadacoste total / casos que pasan evalla métrica que decide producción

198Observabilidad de LLMs

En producción, un LLM sin observabilidad es una caja negra. Necesitas saberqué está pasandoen cada llamada: latencia, coste, calidad, errores, y poder investigar cuando algo falla.

Una traza no solo sirve para debuggear: convierte una conversación probabilística en una secuencia revisable de prompts, modelos, tool calls, evidencias, costes y decisiones.

¿Qué observar?

Latencia

TTFT (time to first token), tiempo total, latencia por modelo. Alertas cuando sube

Coste

Tokens input/output por request, coste acumulado por usuario/feature/modelo

Calidad

Scores de evaluación, feedback de usuario (thumbs up/down), tasa de reintentos

Traces

El recorrido completo de una petición: prompt → modelo → tools → respuesta. Imprescindible para debuggear agentes multi-paso

Herramientas

HerramientaTipoPunto fuerteLangfuseOpen source (self-host o cloud)Tracing completo, evals, datasets, prompts management. El más completo open sourceLangSmithSaaS (LangChain)Integración nativa con LangChain/LangGraph. Playground de promptsHeliconeProxy transparenteSe pone delante de tu API sin cambiar código. Dashboard de costes y latenciaBraintrustSaaSEnfocado en evals y experiments. Bueno para comparar versiones de prompts### Métricas mínimas por request

MétricaPor qué importamodelo + versiónsin esto no puedes explicar regresionesprompt/template versionrelaciona cambios de prompt con calidadtokens y cache hitscontrola coste y contexto inútiltool callsdetecta loops, permisos y latencia externaeval score / feedbackconecta producción con mejora continuaMínimo viable

Si no quieres montar nada: loguea cada llamada con timestamp, modelo, tokens input/output, latencia y coste en una tabla. Con eso ya puedes detectar anomalías y controlar el gasto. Las herramientas especializadas añaden tracing, evals y visualización, pero el logging básico es el mínimo razonable.

199Gestión de prompts como código

Un prompt en producción no es un string pegado en el código. Es unartefacto de ingenieríaque necesita versionado, testing, review y rollback.

Versionado en git

Cada prompt en un fichero dedicado (.md, .yaml). Cambios vía PR con diff legible. Historial completo de quién cambió qué y por qué

Testing con evals

Suite de casos de prueba por prompt. Antes de mergear, las evals deben pasar: ¿el nuevo prompt es igual o mejor?

A/B testing

Servir dos versiones del prompt en paralelo, medir cuál da mejores resultados y promocionar la ganadora

Rollback instantáneo

Si un cambio degrada la calidad, revertir al commit anterior sin redesplegar. El prompt es config, no código compilado

Ejemplo de estructura

model:claude-sonnet-4-6 temperature:0.1 version:3 last_eval_score:0.94 owner:equipo-backend

Por qué importa

Un cambio de una palabra en un prompt puede alterar el comportamiento de todo el sistema. Sin versionado y evals, es imposible saber si un cambio mejora o empeora. Tratar prompts como código elimina el “a mí me funciona” y lo sustituye por métricas.

Ciclo de vida de un prompt

FasePreguntaArtefactoDiseño¿qué tarea, datos y límites?prompt + contrato de salidaEval¿qué casos debe resolver y cuáles debe rechazar?dataset, graders, umbralesRelease¿quién aprobó y qué cambió?PR, changelog, versiónProducción¿qué pasa con datos reales?traces, feedback, alertasRollback¿cómo vuelvo a una versión sana?feature flag o prompt registry

200Evaluaciones (evals): ¿cómo saber si tu IA funciona bien?

Los tests unitarios clásicos no bastan para un LLM: parte de la salida puede variar aunque la respuesta sea válida. Necesitasevaluaciones (evals): métricas y frameworks para medir la calidad de un sistema de IA de forma sistemática.

Una eval buena no pregunta “¿me gusta esta respuesta?”, sino “¿qué decisión puedo tomar con evidencia?”. Sirve para comparar modelos, prompts, tools, RAG, routing y versiones antes de cambiar producción.

Tipos de evaluación

TipoQué mideCómoExactitud¿La respuesta es correcta?Comparar contra respuestas de referencia (gold standard)Estructura¿El formato es válido?Validar JSON schema, regex, longitud, campos requeridosLLM-as-judge¿La calidad es buena?Otro modelo evalúa la respuesta con criterios definidosClasificación¿El routing es correcto?Precisión, recall, F1 contra etiquetas conocidasRegression¿Un cambio empeoró algo?Comparar resultados antes/después de un cambio de prompt o modelo### Ejemplo práctico: eval básica

consttestCases = [ { input:“Contacta en [email protected]”, expected:“[email protected]”}, { input:“Sin email aquí”, expected:null}, ];

letpassed =0; for(consttcoftestCases) { constresult =awaitextractEmail(tc.input); if(result === tc.expected) passed++; } console.log(`Score: \{passed\}/{testCases.length}`);

Herramientas de evaluación

Anthropic Evals

Framework oficial de Anthropic para evaluar modelos y prompts con datasets personalizados

Braintrust / Promptfoo

Plataformas para gestionar datasets de evaluación, comparar versiones de prompts y detectar regresiones

LLM-as-judge

Usar un modelo potente (Opus) para evaluar las respuestas de un modelo más barato (Haiku). Definir criterios claros en el prompt del juez

Diseño de una eval útil

PiezaEjemploFallo si faltaDatasetcasos reales + edge cases + casos de rechazomides solo demos felicesRubriccriterios explícitos de 0-5 o pass/failel juez evalúa “por vibes”Baselineprompt/modelo actualno sabes si el cambio mejoraUmbralno bajar F1, coste por caso < Xoptimizas una métrica y rompes otraRevisión humanamuestreo de outputs y desacuerdos del juezautomatizas un juez sesgadoSin evals, estás volando a ciegas

Cambias el prompt y “parece que va bien” no es una métrica. Las evals te dicen si un cambio mejora o empeora el sistema. Son el equivalente de los tests en software clásico.

201Testing de código generado por IA

El código generado por IA parece correcto y tiene buena pinta. Peroesconde bugs sutilesque solo se detectan con testing riguroso.

La diferencia con copiar código de StackOverflow es la velocidad: un agente puede introducir cambios en muchos ficheros muy rápido. Eso exige pruebas que miren comportamiento, límites, seguridad y regresiones, no solo que compile.

Errores típicos del código generado

Tipo de errorEjemploCómo detectarloOff-by-oneBucle que itera de más o de menosTests con boundary values (0, 1, N-1, N)Race conditionsAcceso concurrente no protegidoTests de concurrencia, stress testingHappy path onlySolo maneja el caso exitosoTests con inputs inválidos, nulos, vacíosAPIs inventadasMétodos o paquetes que no existenCompilación + ejecución realSeguridadSQL injection, XSS, secrets en códigoSAST (Static Application Security Testing; por ejemplo Semgrep), OWASP checks### Estrategia de testing

Siempre ejecutar

Nunca aceptar código sin ejecutarlo. “Se ve bien” no es un test

Mutation testing

Cambiar partes del código y verificar que los tests fallan. Si no fallan, los tests no cubren esa lógica

Property-based testing

Definir propiedades que siempre deben cumplirse. El framework genera cientos de inputs aleatorios

Review como junior

Leer el diff como si lo hubiera escrito un junior. No asumir que “la IA sabe lo que hace”

Pirámide de verificación para IA

CapaQué detectaEjemploBuild / typecheckAPIs inventadas, tipos rotostsc \-\-noEmit,npm run buildUnit testslógica local y edge cases0, nulos, permisos, errores esperadosIntegration testscontratos entre módulosDB real, API real, cola real en DockerE2E / snapshotsflujos completos y UI rotaPlaywright, screenshots, accesibilidadSecurity checksinyecciones, secretos, dependenciasSemgrep, Snyk, secret scanningRegla práctica

Pide a la IA que genere los tests primero (spec-first), revísalos tú, y luego pide la implementación. Si los tests son buenos, la implementación correcta sale casi sola. Si genera código y tests juntos, los tests pueden estar “hechos a medida” para pasar.

202Vibe coding: programar por intención

Término acuñado porAndrej Karpathy(febrero 2025): “un nuevo tipo de programación donde te dejas llevar por las vibes, abrazas lo exponencial, y olvidas que el código existe”.

Como concepto es útil para explicar el cambio de interfaz: pasamos de escribir instrucciones para la máquina a escribir intención para un sistema que genera código. Como práctica profesional, solo funciona si añades especificación, tests y review.

Programación tradicional

La persona escribe cada línea. Domina la sintaxis, las APIs, los patrones. El valor está en saber cómo implementar.

Escribir códigoDominar sintaxis

Vibe coding

La persona describe qué quiere. La IA escribe el código. El valor está en saber qué construir, cómo verificarlo y cuándo la IA se equivoca.

Describir intenciónVerificar resultado

Riesgos sin disciplina

• **Código que no entiendes:**si no puedes leerlo, no puedes mantenerlo ni debuggearlo
• Deuda técnica invisible:“funciona” pero tiene decisiones de arquitectura que no has evaluado
• **Falsa productividad:**generar código rápido no es generar código correcto

Vibe coding con disciplina

• **Spec antes que código:**describe qué quieres antes de pedir implementación
• **Tests antes que implementación:**genera los tests primero, luego la implementación
• **Revisa cada diff:**no hagas merge de código que no entiendas
• **Commits pequeños:**cambios atómicos que puedes revertir individualmente

Semáforo práctico

SituaciónVibe coding encajaPor quéprototipo descartableSíla velocidad vale más que la deudafeature acotada con testsSí, con disciplinael test fija el contratocore de pagos/seguridadNo sin revisión fuerteel coste de error domina la velocidadtecnología que no entiendesCon cuidadopuedes aceptar arquitectura que no sabrás mantenerLa clave

Vibe coding no es “dejar que la IA haga todo”. Eselevar el nivel de abstracción: de líneas de código a intenciones y restricciones. Quien mejor lo usa es quien mejor sabe especificar, verificar y corregir.

203El cambio de paradigma al trabajar con IA

El cambio no elimina ingeniería; desplaza el cuello de botella. Escribes menos boilerplate, pero necesitas más claridad sobre requisitos, arquitectura, seguridad, validación y producto.

Lo que cambia

• De “escribir código” aespecificar intención
• De “dominar la sintaxis” adominar el contexto
• De “programador individual” adirector de agentes
• De “memorizar APIs” adiseñar prompts y flujos
• De “hacer el trabajo” averificar el trabajo

Lo que NO cambia

• Pensar en arquitectura y trade-offs
• Entender qué hace el código
• Seguridad, rendimiento, buenas prácticas
• La responsabilidad: si el agente genera un bug, el responsable eres tú
• Resolver problemas ambiguos que requieren criterio humano

Exponential Programming (Diverger)

No es solo “programar más rápido”. Es un cambio de modelo mental. Diverger acuña el términoExponential Programmingpara describir cómo la IA transforma la relación entre las personas y el código:

• **Productividad no lineal:**una persona con agentes no es 2x más rápida, puede ser 10x o 50x en ciertas tareas. El cuello de botella deja de ser escribir código y pasa a ser pensar qué construir
• **Abstracción sobre abstracción:**antes abstraíamos con funciones, clases y frameworks. Ahora abstraemos con prompts, agentes y flujos. El nivel de abstracción sube un orden de magnitud
• **Equipos más pequeños, más impacto:**lo que antes requería un equipo de 10 personas durante meses, una persona con agentes bien orquestados puede hacerlo en días. Cambia la economía de los proyectos
• **La persona como directora:**tu trabajo no es escribir cada línea, es definir la visión, establecer las restricciones, revisar el resultado y tomar decisiones que la IA no puede tomar por ti

Nuevas habilidades con IA

• Prompt engineering y diseño de system prompts
• Evaluación de salidas de modelos (evals)
• Orquestación de agentes y diseño de flujos multi-paso
• Gestión de contexto: qué información dar al modelo y cuándo
• Pensamiento crítico: detectar alucinaciones, sesgos y errores sutiles

Nueva responsabilidad profesional

AntesAhoraRiesgo si no cambiasescribir implementaciónespecificar y verificar implementacióngeneras mucho código sin criteriorecordar APIsvalidar APIs reales y contratosaceptas paquetes o métodos inventadosdebuggear tu propio códigodebuggear sistemas humano+agenteno sabes qué paso introdujo el falloreview de compañerosreview de diffs generados a alta velocidadla deuda entra más rápido de lo que puedes verlaEl riesgo real

No es que la IA te sustituya. Es que alguien que usa IA con criterio puede adelantar a quien no la usa.

204Patrones de trabajo con IA en el día a día

Más allá de las herramientas, lo que marca la diferencia escómo integras la IA en tu flujo de trabajo. Estos son los patrones que los equipos más productivos usan en 2026.

Spec-first development

Antes de escribir código, escribe una especificación clara en lenguaje natural. El agente implementa desde la spec. Resultado: menos iteraciones, código más alineado con la intención

Test-first con IA

Escribe los tests primero (o pide al agente que los genere desde la spec) y luego implementa hasta que pasen. TDD clásico, pero el agente hace el trabajo pesado

Rules como código

CLAUDE.md, .cursorrules, AGENTS.md son la “configuración” del agente. Mantenlos en git, revísalos en PR, itéralos como cualquier otro fichero del proyecto

Rubber-duck debugging con LLM

Explícale el problema al modelo como harías con un compañero. El acto de articular el problema + la perspectiva del modelo desbloquea más rápido que depurar solo

Contexto nuevo por tarea

Cada tarea significativa merece una conversación nueva. No acumules contexto irrelevante. Define el objetivo, da el contexto mínimo necesario y deja trabajar al agente

Review antes de commit

El agente genera, tú revisas. Lee cada diff como si lo hubiera escrito un junior. No hagas merge de código que no entiendas, aunque “funcione”

El patrón que más impacto tiene

**Spec-first + test-first:**defines qué quieres en lenguaje natural, el agente genera los tests, luego implementa hasta que pasan. Si los tests son buenos, la implementación es correcta por definición. Es el flujo que más consistentemente produce buen código con IA.

Workflow recomendado para una feature

PasoQué pides a la IAQué revisas tú1. Specconvertir idea en requisitos y casos bordealcance, no objetivos inventados2. Planidentificar ficheros, riesgos y testsarquitectura y dependencias3. Testscrear tests que fallen primerosi cubren el comportamiento real4. Implementaciónhacer el cambio mínimodiff, complejidad y estilo del repo5. Verificaciónejecutar test/build y corregirlogs, regresiones y decisión de merge

205Configurar Claude Code como un pro

La diferencia entre un Claude Code que “funciona” y uno quemultiplica tu productividadestá en cómo lo configuras. Estos ficheros definen su comportamiento.

La configuración convierte preferencias tácitas en contexto explícito. Si el equipo repite siempre la misma corrección al agente, esa corrección debería vivir en rules, hooks, skills o documentación del proyecto.

Estructura de configuración

FicheroAlcancePara qué**~/\.claude/CLAUDE\.mdGlobal (todos los proyectos)Idioma, estilo de commits, preferencias personales, herramientas\.claude/CLAUDE\.mdProyectoStack del proyecto, convenciones, arquitectura, reglas de equipo\.claude/rules/\*\.mdProyecto (modular)Reglas por dominio: testing, seguridad, estilo, deploy\.mcp\.jsonProyectoServidores MCP: BD, APIs, navegador, herramientas externassettings\.json**Global / proyectoPermisos, hooks, modelo por defecto, variables de entorno### Ejemplo: CLAUDE.md de proyecto

- TypeScript strict, Node 22, Fastify, Drizzle ORM, PostgreSQL - Tests: Vitest. Cobertura mínima: 80% - Lint: Biome. Formateo automático al guardar

- Commits: tipo(scope): descripción. En español - No hacer push directo a main. Siempre PR - Cada endpoint tiene tests de integración - Validar inputs con Zod en cada handler

- src/routes/ → endpoints Fastify - src/services/ → lógica de negocio - src/db/ → esquema Drizzle y migraciones - src/lib/ → utilidades compartidas

- API keys en variables de entorno, nunca en código - Validar todos los inputs antes de procesar - Rate limiting en todos los endpoints públicos

Ejemplo: .claude/rules/testing.md

- Siempre ejecutarnpm testantes de considerar la tarea terminada - Tests de integración con base de datos real (Docker), no mocks - Nombres de test descriptivos: “debería devolver 404 si el pedido no existe” - Un fichero de test por módulo: orders.test.ts para orders.ts

Consejo clave

Las rules son elmultiplicador más infravaloradode Claude Code. 30 minutos configurando buenas rules te ahorran horas de correcciones. Mantenlas en git, revísalas en cada PR, e itéralas cada semana con lo que aprendas.

Qué va en cada capa

CapaContenido idealNo metas aquíGlobalidioma, estilo personal, preferencias de explicaciónsecretos o reglas de un cliente concretoProyectostack, comandos, arquitectura, convencionesopiniones personales no compartidasRules modularestesting, seguridad, deploy, UI, backendlistas largas que se pisan entre síHooksformat, lint, validaciones automáticasdecisiones creativas o ambiguas

206Configurar OpenCode y Cursor

Cada herramienta tiene su propio sistema de reglas. La idea es la misma:darle contexto persistentepara que no tengas que repetirte en cada conversación.

La estrategia más mantenible es escribir una fuente de verdad neutral, por ejemploAGENTS\.mdodocs/ai\-rules\.md, y generar/adaptar los formatos específicos de cada herramienta desde ahí.

OpenCode

FicheroPara qué**AGENTS\.mdReglas generales del proyecto. Se genera con/initopencode\.json**Configuración: modelo, provider, reglas, seguridad- Resolver la tarea completamente antes de confirmar - Tests verdes antes de considerar terminado - Pedir confirmación en cambios destructivos

- Python 3.12, FastAPI, SQLAlchemy, PostgreSQL - Tests: pytest. Formateo: ruff

- Confirmación si se modifican más de 5 archivos - Confirmación si se eliminan archivos - Nunca modificar archivos de configuración de producción

Cursor

FicheroPara qué**\.cursorrulesReglas de proyecto (raíz del repo). Formato Markdown libre\.cursor/rules/\*\.md**Reglas modulares por dominio (similar a Claude Code)- TypeScript strict, 2 espacios, comillas simples - Prettier + ESLint. No commitear sin que pasen

- Next.js 15 App Router, Server Components por defecto - Tailwind CSS, sin CSS custom salvo excepciones justificadas - Componentes en src/components/, páginas en src/app/

- Explicar brevemente cada decisión antes de implementar - Si hay alternativas, presentarlas con trade-offs

Comparativa rápida

Claude CodeOpenCodeCursorFichero principalCLAUDE.mdAGENTS.md.cursorrulesReglas modulares.claude/rules/*.mdNo.cursor/rules/*.mdMCPs.mcp.jsonSí (config)Sí (settings)Hooks/automatizaciónSí (hooks + skills)LimitadoNoGeneración automáticaNo (manual)/initNo (manual)Consejo práctico

Si usas varias herramientas en el mismo proyecto, mantén unfichero base compartido(Markdown con las convenciones) y adapta el formato a cada herramienta. Las reglas son las mismas; solo cambia dónde se ponen.

Evitar drift entre herramientas

ProblemaSoluciónClaude y Cursor reciben reglas distintasmantén una regla base común versionadarules antiguas contradicen el códigorevisión mensual y PR cuando cambie arquitecturademasiadas rules reducen focosepara por dominio y carga solo lo relevantenadie sabe qué reglas aplicandocumenta prioridad: global, proyecto, dominio, tarea

207Escribir rules efectivas: el arte de instruir al modelo

Las rules son elROI (Return on Investment) más altoque puedes conseguir con una herramienta de IA. 30 minutos bien invertidos te ahorran horas de correcciones. Pero no todas las rules son iguales.

Una rule buena reduce ambigüedad y se puede comprobar. Una rule mala solo expresa deseo. “Haz buen código” no cambia nada; “no usesanyy ejecutanpm run typecheck” sí cambia comportamiento.

Rules malas vs buenas

- Escribe buen código - Sigue las mejores prácticas - Haz tests - Sé conciso

- Tests con Vitest. Mínimo 80% cobertura - Validar inputs con Zod en cada handler - Commits: tipo(scope): desc. En español - No usar any. Tipar todo explícitamente - Ejecutar npm test antes de confirmar

Estructura de una buena rule

SecciónQué ponerEjemploStackVersiones exactas, frameworks, herramientasTypeScript 5.7, Node 22, Fastify 5, DrizzleConvencionesLo que es específico de tu equipocamelCase, sin abreviaturas, español en commitsArquitecturaDónde va cada cosa en tu proyectosrc/routes/, src/services/, src/db/ProhibicionesLo que NO debe hacer nuncaNo usar console.log, no push a main, no anyFlujo de trabajoPasos obligatorios antes de terminarLint, tests, build antes de considerar hecho### Iterar rules: el ciclo virtuoso

• Trabaja con el modelo→ detecta cuándo hace algo que no quieres
• Añade la rule→ corrige ese comportamiento concreto
• Commitea la rule→ todo el equipo se beneficia
• Revisión semanal→ elimina rules obsoletas, refina las que no funcionan

Checklist de calidad de una rule

PreguntaBuena señal¿Es específica del proyecto?nombra stack, rutas, comandos o convenciones reales¿Es verificable?se puede comprobar con test, lint, grep o review¿Tiene prioridad clara?no contradice otra rule más importante¿Evita instrucciones genéricas?quita frases que cualquier modelo ya asumiría¿Se mantiene?tiene owner y se revisa cuando cambia el repoPara ponerlo en práctica ahora

Abre tu proyecto, crea unCLAUDE\.md(o\.cursorrules) y escribe 5 reglas concretas de tu stack. La primera vez cuesta; después lo actualizarás cada vez que el modelo haga algo que no te gusta. En una semana, notarás la diferencia.

208Crear una skill: extensiones reutilizables para tu agente

Unaskilles una capacidad empaquetada que el modelo activa automáticamente cuando detecta que aplica, o que invocas manualmente con/nombre. Cada skill vive en su propio directorio con un fichero**SKILL\.md**.

La idea clave esprogressive disclosure: el modelo no carga todo el conocimiento siempre. Lee la descripción para decidir si la skill aplica, y solo entonces carga instrucciones, referencias o scripts.

Estructura oficial (directorio + SKILL.md)

deploy-check/ ├──SKILL.md ├── reference.md └── scripts/ └── validate.py

SKILL.md: frontmatter + instrucciones

--- name: Deploy Check description: Verificar que el proyecto está listo para desplegar. Comprobar tests, lint, build, variables de entorno y dependencias. Usar cuando se mencione deploy, release o ship. allowed-tools: Bash, Read, Grep, Glob ---

1. Ejecutar`npm test`y verificar que pasan 2. Ejecutar`npm run lint`sin errores 3. Ejecutar`npm run build`sin errores 4. Verificar que .env.example tiene todas las vars 5. Comprobar que no hay secretos en el código

Para referencia detallada, ver [reference.md](reference.md).

Campos del frontmatter

CampoObligatorioPara qué**nameSíNombre visible de la skilldescriptionSíEl modelo lee esto para decidir cuándo activarla. Incluirqué haceycuándo usarla****allowed\-tools**NoRestringe las herramientas disponibles (ej: solo lectura con Read, Grep, Glob)### Claves para una buena skill

• Description específica:“Helps with data” no funciona. “Analyze Excel spreadsheets, generate charts. Use when working with .xlsx files” sí
• Secciones estándar:\#\# Instructions(pasos),\#\# Examples(casos),\#\# Requirements(dependencias)
• **Progressive disclosure:**SKILL.md carga siempre; los ficheros extra solo cuando el modelo los necesita
• **allowed-tools:**úsalo para skills de solo lectura o con alcance limitado (seguridad, auditoría)

Seguridad de skills

RiesgoControldescription engañosarevisar SKILL.md completo antes de instalarherramientas demasiado ampliasusarallowed\-toolsmínimo necesarioscripts con efectos lateralesauditar scripts y ejecutarlos en sandboxcontexto excesivomover detalles a referencias cargadas bajo demandaPara ponerlo en práctica ahora

Crea~/\.claude/skills/mi\-review/SKILL\.mdcon un checklist de code review de tu equipo. Eldescriptiones lo más importante: si menciona las palabras clave correctas, el modelo la activará solo cuando haga falta. Pruébalo pidiendo un code review en tu siguiente sesión.

209Anatomía de un plugin: skills + agentes + hooks

Unpluginempaqueta skills, agentes, hooks y comandos en una unidad instalable y compartible. Es así como se distribuyen las extensiones de Claude Code.

Un plugin merece la pena cuando una práctica ya se repite en varios proyectos o personas. Antes de empaquetar, valida que una skill suelta resuelve bien el caso.

Estructura de directorios

├──.claude-plugin/ │ └──plugin.json ├──skills/ │ ├── deploy-check/ │ │ └──SKILL.md │ └── code-review/ │ └──SKILL.md ├──agents/ │ └── reviewer.md ├──hooks/ │ └── hooks.json └──commands/ └── setup.md

Cada pieza tiene su rol

ComponenteQué haceCuándo se activaSkillPrompt especializado con instruccionesEl usuario invoca/nombreo el modelo lo detectaAgenteSubproceso autónomo con sus propias toolsOtra skill o agente lo lanza conAgent toolHookScript que reacciona a eventos del sistemaEventos: PreToolUse, PostToolUse, Stop, SessionStart...ComandoSlash command con argumentos y lógicaEl usuario escribe/plugin:comando### Cuándo añadir cada pieza

PiezaAñádela cuandoEvítala cuandoSkillhay un procedimiento repetiblesolo quieres una nota genéricaAgentenecesitas contexto/herramientas aisladasla tarea es un paso simpleHookuna validación debe ejecutarse siemprerequiere juicio humano o creatividadComandoel usuario lo invoca explícitamentedebería activarse automáticamente por contexto### .claude-plugin/plugin.json mínimo

{ “name”:“mi-plugin”, “version”:“1.0.0”, “description”:“Herramientas de deploy y review”, “author”: { “name”:“Tu nombre” } }

Para ponerlo en práctica ahora

Empieza con una sola skill en un directorio. Cuando tengas 2-3, empaquétalas en un plugin con suplugin\.json. No necesitas agentes ni hooks desde el principio: la complejidad se añade cuando la necesitas, no antes.

210AI agents en producción: lecciones aprendidas

Tras un año de agentes en producción real, estas son laslecciones que no aparecen en los tutoriales.

La lección central es sobria: producción premia sistemas pequeños, medibles y recuperables. La demo premia autonomía; el negocio premia errores bajos, coste controlado y trazabilidad.

Lo que funciona

Tareas acotadas y repetitivas

Clasificar tickets, generar resúmenes, extraer datos de documentos, code review automatizado. Dominio claro, output verificable

Guardrails estrictos

Validación de output, permisos mínimos, spending limits, timeouts agresivos. Los agentes que funcionan en producción tienen más restricciones que libertad

Lo que no funciona (todavía)

Autonomía total

“Déjalo trabajar solo toda la noche” suena bien, pero genera errores que se acumulan sin supervisión. El coste de corregir supera el ahorro

Planificación a largo plazo

Los agentes son buenos en tareas de 10-30 minutos. Proyectos de horas o días requieren intervención humana frecuente para no desviarse

El “agent tax”

• **Tiempo de supervisión:**un agente autónomo necesita que alguien revise su trabajo. Ese tiempo es el “agent tax”
• **Coste de tokens:**un agente que itera 10 veces consume 10x más tokens. Sin límites, las facturas se disparan
• **Debugging opaco:**cuando un agente multi-paso falla, diagnosticar cuál paso falló y por qué es más difícil que debuggear código normal

Checklist antes de poner un agente en producción

ÁreaPregunta de controlScope¿la tarea tiene inicio, fin, inputs y outputs definidos?Tools¿cada tool tiene schema, permisos, logs y límites?Evals¿hay dataset de regresión y umbral de aceptación?HITL¿qué acciones requieren aprobación humana?Observabilidad¿puedes reconstruir una ejecución fallida?Coste¿mides coste por tarea aceptada y no solo tokens?Regla de oro para producción

Empieza con el agente más simple que resuelva tu problema. Añade complejidad solo cuando el simple no baste. Muchos casos de uso reales se resuelven con un prompt bien diseñado + una tool, no con un sistema multi-agente de 5 capas.

211Lo que deberías saber: construir con IA

ConceptoSlideIDE web, Playground, IDE con agente, terminal y CI: cuándo usar cada superficie187Comparativa de AI coding assistants: UX, modelo, permisos, coste y gobernanza188Benchmarks: familias, métricas, SWE-bench y lectura crítica de leaderboards189-191IA en CI/CD: PR review, testing, seguridad automatizada y controles mínimos192Prompt injection, data leakage, supply chain poisoning y OWASP LLM Top 10193Guardrails: input validation, output validation, sandboxing, policy y evals194Red teaming: testear tu sistema intentando romperlo y medir attack success rate195EU AI Act: clasificación por riesgo y calendario de aplicación196Costes: tokens, cache, agentes y coste por tarea aceptada197Observabilidad: traces, costes, calidad, tool calls, prompt versions198Prompts como código: versionado, evals, A/B testing, release y rollback199Evals: dataset, rubric, baseline, umbral y revisión humana200Testing de código generado: build, unit, integration, E2E, security checks201Vibe coding y cambio de paradigma: intención, verificación y responsabilidad202-203Spec-first + test-first: workflow diario con IA204Configurar Claude Code, OpenCode y Cursor sin drift entre herramientas205-206Rules efectivas: específicas, verificables, mantenidas y con prioridad clara207Skills y plugins: progressive disclosure, allowed-tools, hooks y empaquetado208-209Agentes en producción: agent tax, autonomía real, evals, HITL y observabilidad210 212

Evals y medición avanzada

Cómo medir RAG, agentes, jueces LLM, coste por tarea aceptada y regresiones reales antes de confiar en un sistema de IA.

213Eval de RAG: retrieval, groundedness y abstención

Un RAG no se evalúa solo leyendo respuestas bonitas. Se separan dos problemas:si recupera la evidencia correctaysi responde apoyándose en ella.

La clave pedagógica es no mezclar causas. Si la respuesta falla, puede ser porque no recuperaste el documento correcto, porque recuperaste ruido, porque el modelo ignoró la evidencia o porque debía abstenerse y respondió igual.

Pregunta→Retrieval→Rerank→Generación→Citas / abstención

Capas de medición

CapaMétrica útilQué detectaRetrievalRecall@k, MRR, nDCGSi los chunks relevantes aparecen arribaRerankingPrecisión top-k, cobertura por fuenteSi el ranking mejora o entierra evidenciaGroundednessRespuesta soportada por citasAlucinación aunque hubiera documentos buenosAnswerabilityDebe responder / debe abstenersePreguntas sin evidencia o fuera de corpusUXCitas clicables, fragmentos y fechaSi el usuario puede verificar la respuesta### Fórmulas que conviene entender

MétricaFórmula / intuiciónQué optimizaRecall@krelevantes recuperados en top-k / relevantes totalesno perder evidencia necesariaPrecision@krelevantes en top-k / kno llenar contexto con ruidoMRR1 / posición del primer resultado relevanteque la evidencia buena aparezca prontonDCGranking con relevancia graduada y descuento por posiciónordenar mejor documentos parcialmente útilesFaithfulnessafirmaciones soportadas / afirmaciones totalesreducir alucinación sobre contexto recuperado### Diagnóstico por síntoma

SíntomaCausa probableQué probarrecall bajochunking, embeddings o filtros maloschunks solapados, híbrido keyword+vector, metadataprecision bajamucho ruido en top-kreranker, filtros, bajar k, mejorar query rewritefaithfulness bajamodelo rellena huecosprompt con citas obligatorias, abstención, juez de groundingabstención malano hay umbral de evidenciacasos no-answer y score mínimo de soporteDataset mínimo serio

Empieza con 50-100 preguntas reales: algunas con respuesta, otras sin respuesta, algunas ambiguas y otras con documentos contradictorios. Si todas tienen respuesta fácil, no estás midiendo el fallo que aparecerá en producción.

214LLM-as-judge: usar jueces sin autoengañarte

Un juez LLM puede acelerar evaluación, pero no convierte una rúbrica vaga en verdad objetiva. El juez también tiene sesgos, sensibilidad al prompt y preferencias de estilo.

Un juez sirve mejor cuando la respuesta no tiene una única cadena exacta: calidad de resumen, groundedness, tono, completitud o seguimiento de instrucciones. Si puedes usar un test determinista, úsalo primero.

Tipos de grader

GraderÚsalo paraLimitaciónDeterministaJSON válido, regex, tests, exact matchno mide calidad semántica ricaLLM-as-judgerúbricas de calidad, grounding, comparación A/Bsesgo, drift, coste y variabilidadHumanocalibración, alto riesgo, criterios ambiguoscaro, lento, inconsistente sin guíaTool / entornocódigo, agentes, tareas ejecutablessolo mide lo que el entorno observa### Checklist de juez fiable

Calibración mínima

MedidaQué preguntaAcción si fallaAcuerdo juez-humano¿el juez coincide con revisores?mejorar rúbrica o usar humano en casos fronteraConsistencia¿puntúa igual al repetir?bajar temperatura, fijar versión y ordenar salidaSensibilidad A/B¿detecta mejoras reales?añadir pares difíciles y ejemplos negativosSesgo de longitud¿premia respuestas largas?criterios separados: exactitud, concisión, evidenciaRegla práctica

Usa juez LLM para filtrar y comparar tendencias. Para decisiones críticas, añade revisión humana, tests verificables o métricas externas. El juez no debe ser la única puerta de producción.

215Eval de agentes: éxito, tools, coste y trazas

Un agente no es solo una respuesta final. Es un proceso: planifica, llama tools, observa resultados, corrige y decide cuándo parar. La eval debe medir el proceso completo.

En agentes hay dos niveles:outcome(si logró la tarea) ytrajectory(cómo llegó allí). Una tarea puede terminar bien usando una tool peligrosa, o terminar mal después de gastar demasiado coste.

Señales que importan

SeñalCómo medirlaFallo típicoTask successObjetivo logrado con criterios verificablesRespuesta convincente pero tarea sin completarTool successTool correcta, argumentos válidos, permisos mínimosLlamada innecesaria o destructivaCosteTokens, tool calls, duración y coste por tarea aceptadaResolver con 20 pasos lo que bastaba con 2RobustezReintentos, timeouts, errores de tool y recuperaciónBucle infinito o abandono silenciosoAuditabilidadTrace con plan, acciones, observaciones y verificaciónNo saber por qué actuó ni cómo revertir### Outcome vs trajectory

NivelPreguntaEjemplo de graderOutcome¿la tarea quedó resuelta?tests pasan, ticket creado, documento correctoTrajectory¿el camino fue seguro y eficiente?trace grading, tool calls permitidas, max stepsState¿el entorno final es el esperado?diff, BD, filesystem, navegador, artefactosRecovery¿se recuperó de errores?timeout controlado, retry razonable, escalado humano### Fallos que solo ves en trazas

FalloSeñalMitigacióntool innecesariallama APIs para datos ya disponiblesbudget de tools y prompt de lectura previaargumentos peligrosostool correcta, parámetros malosschema, validación, dry-runsobreingenieríamuchos ficheros tocados para cambio pequeñométrica de diff y reviewer humanoloop sin información nuevarepite búsqueda o test sin cambiar nadadetector de progreso y max retriesEval mínima para agentes

20 tareas reales, límite de coste, límite de pasos, tools permitidas, criterios de éxito, logs completos y revisión de diffs/acciones. Sin trazas no hay debugging ni confianza.

216Coste por tarea aceptada: la métrica que decide

El precio por token no decide producción. Decide elcoste por tarea aceptada: cuánto pagas por una salida que pasa calidad, seguridad y revisión humana.

1Tokens

Input, output, reasoning, cache hit/miss y batch.

2Intentos

Retries, rollouts, herramientas y llamadas encadenadas.

3Revisión

Tiempo humano para aceptar, editar o rechazar.

4Calidad

Tasa de aceptación, regresiones y errores evitados.

Lectura FinOps

OptimizaciónCuándo ayudaRiesgoRouting barato/caroTareas fáciles abundantes y pocas críticasFalsos negativos: mandar difícil al baratoPrompt cachingSystem prompt, reglas o corpus fijo repetidoAsumir cache donde el prefijo cambiaBatch / flexProcesos offline sin latencia estrictaNo sirve para UX interactivaModelo caro primeroError caro o revisión humana muy costosaSobrepagar por tareas triviales### Ejemplo numérico

ElementoCálculoResultadoInferencia4 llamadas × 0\.1350.54Toolsbúsqueda + BD + navegador$0.04Revisión humana2 min × 60/h2.00Aceptación80% de tareas pasandividir por 0.8Coste por tarea aceptada($0.54 + $0.04 + 2\.00\) / 0\.8**3.23**### Guardrails de presupuesto

LímiteEjemploQué evitamax tokens20k input / 4k outputcontexto hinchado o respuestas infinitasmax steps8 vueltas de agenteloops sin progresomax tool calls3 búsquedas, 1 escrituracoste externo y efectos repetidosstop on low confidenceabstener o escalarpagar por respuestas que no deberían existirFórmula práctica

Coste real = coste de inferencia + coste de tools + coste de reintentos + coste de revisión. Divide por tareas aceptadas, no por tareas intentadas.

217Lo que deberías saber: evals avanzadas

ConceptoLectura correctaRAGMedir retrieval y respuesta por separado: recall@k, precision@k, MRR, nDCG, citas, groundedness y abstención.DiagnósticoUn fallo puede venir de chunking, embeddings, reranking, generación o ausencia de umbral de evidencia.LLM-as-judgeÚtil para escalar revisión, peligroso sin rúbrica, calibración, evaluación ciega y casos negativos.AgentesEvaluar outcome y trajectory: task success, estado final, tools, coste, límites, trazas y recuperación.CosteDecidir por coste por tarea aceptada: inferencia + tools + reintentos + revisión, dividido por tareas aceptadas.ProducciónUna eval madura es una puerta de despliegue con baseline, umbrales, owners y rollback.Pregunta final del bloque

Antes de cambiar modelo, prompt, embeddings o tools, deberías poder decir: qué eval lo cubre, qué métrica decide, cuánto cuesta, qué falla y cómo vuelves atrás si empeora.

218

Producto y UX de IA

De medir a diseñar: cómo convertir incertidumbre, citas, abstención, confirmaciones humanas, memoria, límites y recuperación de errores en una experiencia que el usuario pueda controlar.

219Diseñar para incertidumbre: confianza, citas y abstención

La UX de IA debe enseñar al usuario cuándo confiar, cuándo verificar y cuándo el sistema no sabe. Una respuesta segura pero falsa es peor que una abstención honesta.

Patrones de interfaz

Buen criterio de producto

La IA debe reducir trabajo, no esconder incertidumbre. En tareas de riesgo, una interfaz honesta vale más que una respuesta elegante.

220Aprobación humana: confirmar, editar y revertir

Human-in-the-loop no es poner un humano al final de todo. Es diseñar puntos de control donde el usuario pueda entender, corregir y revertir acciones.

Matriz de aprobación

AcciónControl UXRegistro mínimoLeer / resumirCitas y feedback rápidoFuentes usadas, modelo, timestampCrear borradorEditar antes de enviarPrompt, versión y cambios humanosModificar datosPreview de diff + confirmaciónAntes/después, usuario aprobadorEjecutar tool externaPermiso por scope, no token genéricoTool, argumentos, resultado, costeAcción irreversibleDoble confirmación o prohibiciónJustificación, rollback o ausencia de rollbackRollback como requisito

Si una acción no se puede revertir, no debería ser automática por defecto. El diseño correcto es dry-run, diff, confirmación y límites de permisos.

221Conversaciones recuperables: memoria, límites y handoff

Un producto con IA falla de formas distintas a un formulario clásico: se desvía, olvida, mezcla contexto o no sabe cuándo parar. La UX debe tener salidas claras.

Controles que espera un usuario real

Memoria controlable

• Ver qué recuerda el sistema
• Editar o borrar memoria
• Separar memoria personal, proyecto y sesión
• No mezclar tenants ni conversaciones

Handoff y recuperación

• Escalar a humano cuando hay riesgo o bloqueo
• Reanudar una tarea con estado visible
• Exportar contexto, decisiones y próximos pasos
• Marcar respuesta como incorrecta y re-evaluar

Señal de madurez

Un buen producto de IA no obliga al usuario a discutir con el modelo. Ofrece controles: rehacer, limitar, verificar, escalar y cerrar.

222Lo que deberías saber: producto y UX de IA

ÁreaRegla prácticaConfianzaNo finjas certeza. Muestra evidencia, límites y qué no se ha comprobado.CitasLa cita debe sostener la afirmación concreta, no solo enlazar un documento relacionado.AprobaciónAcciones con impacto necesitan preview, diff, confirmación, permisos mínimos y rollback.MemoriaDebe ser visible, editable, separada por scope y borrable.HandoffCuando la IA no puede resolver, debe cerrar bien: humano, ticket, export o siguiente paso. 223

Operar IA en producción

LLMOps, serving de modelos, routing, budgets, EvalOps, DataOps, post-training avanzado y disciplina operativa.

224LLMOps: de demo a servicio fiable

LLMOps empieza cuando una respuesta mala, cara o lenta deja de ser una anécdota y pasa a ser un incidente de producto.

Control plane

Modelos permitidos, prompts, versiones, flags y límites. Sin esto, nadie sabe qué cambió.

Runtime

Streaming, retries, fallback, tools y timeouts. Sin esto, una llamada fallida rompe la experiencia.

Observabilidad

Traces, tokens, coste, latencia y errores. Sin esto, debuggear es adivinar.

Evals

Regresiones antes de desplegar. Sin esto, un prompt nuevo puede romper casos reales.

Gobernanza

Datos permitidos, retención, acceso y auditoría. Sin esto, el riesgo aparece tarde.

Preguntas de producción

VersiónQué modelo/prompt respondió

CosteCuánto costó esa tarea

ContextoQué datos vio el modelo

ToolsQué acciones ejecutó

RollbackCómo vuelves atrás

Señal de madurez

Un sistema LLM está en producción cuando puedes responder: qué versión contestó, cuánto costó, qué contexto vio, qué tools usó, qué eval cubría ese caso y cómo haces rollback.

225Serving open weights: vLLM, SGLang, TensorRT-LLM

Servir un modelo no es “hacer un import”: es gestionar memoria, colas, latencia y coste por token.

Traducción de términos

Serving

Poner el modelo detrás de una API.

Throughput

Peticiones o tokens por segundo que aguanta.

Runtime

Software que carga el modelo y ejecuta inferencia.

Batching

Juntar peticiones para aprovechar mejor la GPU.

KV cache

Memoria de tokens ya leídos para no recalcularlos.

PagedAttention

Organiza KV cache por bloques para gastar menos VRAM.

Prefix cache

Reutiliza cálculos de prompts repetidos.

GGUF / edge

Formato local; ejecutar cerca del usuario o en tu equipo.

226Escalar inferencia: batching, KV cache y especulación

Escalar inferencia es elegir qué sacrificas: latencia individual, throughput total, memoria o coste.

1. AgruparContinuous batching

Mezcla peticiones que llegan en momentos distintos para llenar mejor la GPU.

2. RecordarKV cache

Guarda tokens ya procesados para generar sin recalcular todo el contexto.

3. OrdenarPagedAttention

Gestiona esa memoria en bloques para reducir fragmentación de VRAM.

4. ReutilizarPrefix caching

Aprovecha prompts comunes: system prompt, reglas o contexto fijo.

5. AcelerarSpeculative decoding

Un modelo pequeño propone tokens y el grande valida si sirven.

Cuadro de mando mínimo

TTFTtime to first token: tiempo hasta el primer token

p95/p99percentiles 95/99: latencia de cola, no media feliz

tok/svelocidad de generación

$/okcoste por respuesta aceptada

**GPU%**saturación y memoria

Métrica correcta

No optimices solo tokens/segundo. MideTTFT(time to first token), tiempo total, tokens por segundo, coste por respuesta aceptada, tasa de timeout y saturación de GPU.

227Routing, fallback y budgets por tarea

El modelo más caro no siempre gana. Gana la ruta que resuelve la tarea con calidad suficiente, coste controlado y riesgo aceptable.

EntradaClasificar

Tipo de tarea, riesgo, datos y dificultad.

RutaElegir modelo

Barato, medio, frontier, local o humano.

LímiteFijar budget

Tokens, tiempo, tools, reintentos y coste.

ControlObservar

Logs, traces, calidad, latencia y coste.

SalidaFallback

Otro modelo, respuesta parcial o humano.

Coste por tarea resuelta

El modelo barato puede salir caro si falla y requiere tres reintentos. El modelo caro puede salir barato si resuelve a la primera. Mide coste por output aceptado, no precio por token aislado.

228EvalOps: regresiones, canary y release gates

Una eval no es un informe: es una puerta de despliegue que evita degradar calidad, coste o seguridad sin darte cuenta.

Gate 1Offline eval

Dataset fijo con casos reales y edge cases.

Gate 2Shadow run

Nuevo sistema responde sin afectar al usuario.

Gate 3Canary

Porcentaje pequeño de tráfico real.

Gate 4Promote

Subir tráfico si calidad/coste/latencia aguantan.

SalidaRollback

Volver a versión anterior por flag o config.

Métricas que sí importan

Successtareas aceptadas

$/successcoste por éxito

p95/p99percentiles de latencia real

Safetyregresiones de riesgo

229DataOps para IA: linaje, PII, licencias y drift

En IA, los datos no son un input pasivo: son el producto que define qué sabe, qué cita y qué puede romper tu sistema.

Linaje

Documento, dataset, versión, hash y cita recuperable. Sin linaje no hay auditoría.

PII y secretos

Escanear antes de indexar o entrenar. Un embedding también merece protección.

Licencia

Registrar origen, restricciones y uso permitido: entrenamiento, eval o solo consulta.

Calidad

Detectar duplicados, OCR malo, docs obsoletos, metadatos rotos y fuentes contradictorias.

Drift

Re-muestrear casos reales porque producción cambia y la eval envejece.

Pipeline de datos mínimo

1Clasificar

Tipo de dato, sensibilidad y licencia.

2Limpiar

Deduplicar, normalizar, quitar PII y secretos.

3Versionar

Snapshot, hash, owner y fecha.

4Medir

Eval de retrieval, calidad y cobertura.

Error común

Tratar embeddings como datos inocuos. Un vector puede revelar información sobre el texto original por ataques de inferencia o por exposición de metadatos. Protege la vector DB como protegerías el corpus fuente.

230Post-training avanzado: SFT, preferencias y refuerzo

Post-training no es una técnica: eliges una señal. El refuerzo “solo” merece sitio cuando la recompensa se puede verificar.

1Ejemplos

Imitar respuestas buenas escritas o curadas.

2Preferencias

Comparar respuesta A contra respuesta B.

3Recompensa

Puntuar outputs con humanos, IA o verificadores.

4Optimización

Hacer más probables las respuestas mejor puntuadas.

Mapa de métodos

231Lo que deberías saber: operar IA en producción

Operar IA no es elegir un modelo: es convertir prompts, datos, tools, costes y riesgos en un sistema observable, reversible y medible.

Operar

Control plane, runtime, owners, límites, trazas y rollback probado.

142

Servir

vLLM, SGLang, TensorRT-LLM, llama.cpp u Ollama según hardware, latencia y formato.

143

Escalar

Continuous batching, KV cache, prefix cache, speculative decoding y colas con p95/p99.

144

Decidir

Routing, fallback y budgets por riesgo: modelo barato, caro, humano o abstención.

145

Medir

Offline evals, shadow runs, canary, release gates y regresiones por versión.

146

Gobernar datos

Linaje, PII, licencias, calidad, drift, datasets de eval y post-training.

147-148

Checklist antes de llamarlo producción

ÁreaDebe existirSeñal de madurezCalidadEval versionada con casos reales y negativosBloquea releases cuando baja calidadObservabilidadTrace por petición: prompt, modelo, tools, coste y latenciaDebuggable sin reproducir a manoCosteBudget por usuario, tarea o tenantCoste por tarea aceptada, no solo tokensSeguridadPermisos mínimos, dry-run y aprobación humanaAcciones críticas son reversibles o no automáticasCambioVersionado de prompts, modelos, datasets y toolsCanary, rollback y owner claro por fallo 232

Seguridad, gobernanza y confianza

Riesgos específicos de agentes, OWASP LLM Top 10, privacidad, despliegues privados, marcos de gobernanza e interpretabilidad.

233Seguridad agentic: tools, MCP y permisos

El salto de chatbot a agente cambia el daño posible: ya no solo responde, también puede actuar con permisos.

Tool poisoning

La descripción de una tool o de un servidor MCP induce al modelo a usarla de forma peligrosa.

Control: tools revisadas, allowlist y descripciones mínimas.

Confused deputy

El agente usa permisos del usuario para acciones que el usuario no pretendía autorizar.

Control: scopes explícitos, confirmaciones y logs por acción.

Prompt injection indirecta

Un documento, web o resultado RAG ordena al agente ignorar reglas o filtrar contexto.

Control: separar datos de instrucciones y no ejecutar órdenes recuperadas.

Exceso de agencia

Tools demasiado potentes: shell, email, pagos, deploy o APIs administrativas.

Control: permisos mínimos, sandbox, dry-run, HITL (human-in-the-loop) y rollback.

Exfiltración

Una tool externa recibe secretos, contexto sensible o datos de otro usuario.

Control: DLP (Data Loss Prevention), redacción, egress control y clasificación de datos.

Modelo de amenazas mínimo

FronteraQué no debe cruzar sin controlControl prácticoUsuario → modeloInstrucciones maliciosas o datos prohibidosValidación, clasificación y límites por tenantRAG → modeloInstrucciones escondidas en documentosTratar retrieval como datos, no como órdenesModelo → toolsAcciones no pretendidas por el usuarioScopes, confirmación, dry-run y allowlistTools → exteriorSecretos, PII o contexto sensibleDLP, redacción, egress control y logsRegla de diseño

Una tool debe tener el permiso mínimo para una acción concreta. Evita tools genéricas tiporun\_any\_sql,shellosend\_http\_requestsalvo en sandboxes controlados.

234OWASP LLM Top 10 aplicado

OWASP LLM Top 10 sirve para convertir riesgos conocidos en controles probables, testeables y operables.

Prompt injection

Documento RAG con “ignora instrucciones” o una web que intenta controlar al agente.

Separar datos/instrucciones y crear eval adversarial.

Sensitive information disclosure

El modelo revela contexto de otro usuario, secretos o datos internos.

Aislamiento por tenant, redacción y tests de fuga.

Supply chain

Modelo, dataset, plugin, dependencia o MCP server comprometido.

Pinning, firmas, revisión de fuentes y SBOM (Software Bill of Materials).

Data poisoning

Corpus o feedback contaminado para sesgar retrieval, entrenamiento o respuestas.

Linaje, revisión de datos y detección de anomalías.

Excessive agency

Agente con permisos para borrar, enviar, comprar o desplegar sin aprobación.

Least privilege, HITL (human-in-the-loop), dry-run y rollback.

Convertir riesgo en prueba

1Dataset adversarial

Ataques directos e indirectos versionados.

2CI

Ejecutar al cambiar prompt, retrieval, modelo o tool.

3Control

Registrar qué capa bloqueó cada ataque.

4Deuda

Si nada lo bloquea, no es edge case: es riesgo pendiente.

235Privacidad, retención y private AI

La decisión no es “cloud o local”: es qué datos viajan, quién los procesa, cuánto se guardan y con qué garantías.

Checklist antes de enviar datos

DatosClasificación

Público, interno, confidencial o regulado.

TiempoRetención

Prompts, outputs, archivos y logs.

LugarRegión

Dónde se procesa y almacena la información.

UsoTraining

Si puede usarse para entrenar o mejorar modelos.

LegalContrato

DPA (Data Processing Agreement), términos enterprise, auditorías y subprocesadores.

236Gobernanza: EU AI Act, NIST AI RMF e ISO 42001

Gobernanza no es frenar IA: es decidir qué se despliega, con qué controles y con qué evidencia.

Evidencia mínima para aprobar despliegue

Ficha del sistema

Propósito, usuarios, datos, modelos, tools, owners y límites.

Evals

Dataset, métricas, fallos conocidos y umbral de despliegue.

Registro de riesgos

Prompt injection, datos, sesgos, seguridad y humanos afectados.

Supervisión humana

Cuándo interviene, qué puede anular y cómo se registra.

237Interpretabilidad: SAEs, features y límites de confianza

Interpretabilidad ayuda a investigar modelos; no sustituye evals, controles ni supervisión en producto.

Mechanistic interpretability

Analizar circuitos internos, activaciones y componentes del modelo.

SAEs

Sparse autoencoders: descomponer activaciones en features más interpretables.

Feature steering

Modificar activaciones para aumentar o reducir ciertos comportamientos.

Auditoría conductual

Medir outputs con evals, red teaming y casos adversariales.

Lectura correcta

Investigapatrones internos

Explicahipótesis causales

No pruebaseguridad total

No reemplazaevals y permisos

Lectura correcta

La interpretabilidad ayuda a investigar y detectar patrones, pero en producto la confianza sigue necesitando evals, controles, observabilidad, permisos mínimos y supervisión humana.

238Lo que deberías saber: seguridad y gobernanza

La seguridad de IA se diseña por fronteras: qué entra al modelo, qué contexto usa, qué tools puede ejecutar y qué datos pueden salir.

Mapa mental de defensaNo basta con un prompt seguro: cada frontera necesita un control verificableUsuarioinput, permisosContexto/RAGdatos, citasModelorazona, decideTools/MCPacciones, scopesExteriorAPIs, datos, redvalidarseparar datos/instruccionesallowlist + HITLDLP + egress151: permisos mínimos152: ataques repetibles155: límites de confianza151: tools auditables153-154: datos y gobierno### Lectura operativa

CapaPregunta que debe responderEvidencia mínimaPermisos¿Qué puede hacer el agente y quién lo aprobó?Scopes, logs, dry-run y rollbackAtaques¿Hemos probado prompt injection, data leakage y tool abuse?Dataset adversarial en CIDatos¿Dónde se procesan, cuánto se retienen y bajo qué contrato?DPA, región, retención y clasificaciónGobierno¿Qué marco aplica según riesgo y dominio?EU AI Act, NIST AI RMF, ISO/IEC 42001Confianza¿Qué sabemos por evals y qué solo sospechamos por interpretabilidad?Evals, red teaming y límites documentados 239

Modelos open weights en la nube

Ollama Cloud: ejecutar modelos open weights sin GPU local, catálogo de modelos, integración con herramientas de coding y cuándo elegir cloud vs local.

240Ollama Cloud: modelos open weights sin GPU

Ollama Cloud da acceso a modelos open weights (DeepSeek, Kimi, GLM, Mistral, Gemma...) a través de una API en la nube. Misma experiencia de Ollama, pero sin comprar ni mantener GPU.

Sin GPU local

Accede a modelos grandes sin depender de la VRAM de tu portátil. Ideal para evaluar modelos que no caben en local.

Misma API de Ollama

Cloud funciona como un host remoto de Ollama. En local usaslocalhost:11434; en cloud apuntas aollama\.com.

Modelo freemium

Plan gratuito con límites. Plan Pro a $20/mes y Max a $100/mes para más uso y concurrencia.

Integración directa

Funciona con Claude Code, Codex CLI, OpenCode y herramientas que soporten Ollama como provider.

Caso de uso principal

Tienes un portátil sin GPU dedicada pero quieres probar modelos grandes de código o razonamiento como kimi-k2.6, deepseek-v4-pro/flash o mistral-large-3. Ollama Cloud te da un endpoint sin montar infraestructura.

241Catálogo de modelos (mayo 2026)

Selección representativa del catálogo de Ollama Cloud a mayo de 2026. La lista cambia rápido: confirma siempre el tagcloud, tamaño, contexto y soporte de tools antes de fijar un modelo en producción.

CategoríaModeloDetalleCódigo****kimi-k2.6cloudMultimodal agentic, enfocado en long-horizon coding, diseño y ejecución autónomaqwen3-coder-nextcloudModelo de código de la familia Qwen para workflows agentic codingminimax-m2.7cloudOrientado a coding, agentes y productividad profesionalRazonamiento****deepseek-v4-procloudMoE frontier con contexto 1M y tres modos de razonamientodeepseek-v4-flashcloudMoE 284B total / 13B activos, contexto 1Mglm-5.1cloudModelo flagship de Z.AI para agentic engineering y codingMultimodal****mistral-large-3cloudMoE multimodal generalista para producción y herramientasgemma4cloudFamilia Gemma con visión, tools, thinking y audioqwen3.5cloudFamilia multimodal con tamaños desde pequeños hasta 122B

242Primeros pasos con Ollama Cloud

Configurar Ollama Cloud lleva poco tiempo. Solo necesitas una cuenta de Ollama y una API key.

1. Obtener la API key

export OLLAMA_API_KEY=“sk-...”

curl -s https://ollama.com/api/tags \ -H“Authorization: Bearer $OLLAMA_API_KEY“| jq’.models[:3]’

2. Primer chat

curl https://ollama.com/api/chat \ -H“Authorization: Bearer $OLLAMA_API_KEY“\ -H“Content-Type: application/json“\ -d’{“model”: “gpt-oss:120b”, “messages”: [{“role”: “user”, “content”: “Hola”}], “stream”: false}’

3. Desde Python

importos fromollamaimportClient

client = Client( host=“https://ollama.com”, headers={“Authorization”:“Bearer “+ os.environ[“OLLAMA_API_KEY”]} ) resp = client.chat( model=“gpt-oss:120b”, messages=[{“role”:“user”,“content”:“Explica async/await”}], stream=False )

Dato clave

Cloud directo usa la API nativa de Ollama. Ollama local también expone endpoints OpenAI-compatible bajo/v1cuando una herramienta necesita ese formato.

243Ollama Cloud + herramientas de coding

Cómo integrar Ollama Cloud en herramientas habituales de AI coding.

Claude Code

Ollama puede lanzar Claude Code con un modelo cloud usandoollama launch. Útil para probar modelos open weights sin cambiar de herramienta.

Codex CLI

Ollama puede lanzar Codex apuntando a un modelo cloud. El modelo se sirve desde Ollama y la herramienta sigue trabajando en terminal.

OpenCode

Ollama puede lanzar OpenCode con un modelo cloud usando el mismo patrón deollama launch.

Continue / Cursor / otros

Usa el provider Ollama local y un modelo:cloudcuando la herramienta soporte Ollama como backend.

Configuración rápida por herramienta

HerramientaCómo configurarComandoClaude Codeollama signinoOLLAMA\_API\_KEY``ollama launch claude \-\-model kimi\-k2\.6:cloudCodex CLIollama signinoOLLAMA\_API\_KEY``ollama launch codex \-\-model kimi\-k2\.6:cloudOpenCodeollama signinoOLLAMA\_API\_KEY``ollama launch opencode \-\-model kimi\-k2\.6:cloudContinue / CursorProvider Ollama localUsar un tag:cloudsi la herramienta lo aceptaConsejo práctico

Usa modelos propietarios (Claude, GPT, Gemini) cuando necesites máxima fiabilidad o integración específica. Usa modelos open weights vía Ollama Cloud para evaluación rápida, tareas repetitivas de código y evitar depender de un único proveedor. Para datos sensibles, revisa región, retención y política contractual.

244Cloud vs local: cuándo usar cada uno

No es una cuestión de cuál es mejor, sino de cuál encaja en tu situación.

CriterioCloud (Ollama)Local (LM Studio / Ollama)Hardware necesarioNinguno localGPU/RAM suficientes para el modelo y la quantizaciónModelos muy grandesSí, si están en el catálogo cloudLimitado por VRAM, RAM, quantización y número de GPUsLatenciaDepende de red, región, cola, modelo y planSin red externa; depende de GPU y runtimeVelocidadGestionada por infraestructura cloud; no fija por planLimitada por GPU, quantización, batch y contextoPrivacidadDatos viajan a Ollama Cloud; Ollama declara no logging ni trainingTodo queda en tu máquina si no llamas servicios externosCoste mensualFree / Pro $20 / Max $100; uso medido por GPU timeElectricidad + inversión y mantenimiento de hardwareFormatoPesos nativos del proveedor; hardware cloud optimizadoGGUF/MLX/safetensors o formato del runtime elegidoOfflineNoSíElige cloud cuando...

No tienes GPU, necesitas modelos muy grandes, quieres setup rápido o trabajas en equipo y necesitas un endpoint compartido.

Sin inversión HWSetup instantáneo

Elige local cuando...

Manejas datos sensibles (código propietario, datos de clientes), necesitas latencia mínima, trabajas offline o ya tienes una GPU potente.

Privacidad totalSin costes recurrentes

Recomendación

Lo más práctico: usa ambos. Cloud para modelos grandes y pruebas rápidas, local para código sensible y trabajo diario si tienes GPU. Mantén una capa de configuración para cambiar host/modelo sin reescribir la aplicación.

245Lo que deberías saber: Ollama Cloud

ConceptoSlideOllama Cloud: modelos open weights sin GPU, misma experiencia que local240Catálogo cloud: kimi-k2.6, deepseek-v4-pro/flash, glm-5.1, gemma4...241Setup: API key + curl o Python con la API nativa de Ollama242Integración: Claude Code, Codex CLI, OpenCode y herramientas con provider Ollama243Cloud para modelos grandes y prototipos; local para privacidad extrema244Laboratorios guiados para búsqueda, planning, ML clásico, ontologías, RAG y agentes246-258Recursos, checklist de exactitud, glosario y ruta de estudio259-267 246

Laboratorios IA aplicada

Ejercicios cortos para convertir teoría clásica y sistemas LLM en artefactos medibles: búsqueda, planning, ML clásico, grafos y agentes.

247Labs: qué hace bueno a un ejercicio

Un laboratorio bueno no es una demo que impresiona. Es una práctica que deja un artefacto medible, repetible y discutible.

Un laboratorio debe terminar con algo que otra persona pueda ejecutar y criticar. La práctica no está completa hasta que deja claro qué se probó, con qué datos, qué métrica salió y qué decisión permite tomar.

Teoría aplicada

Un lab enseña ingeniería cuando produce evidencia reproducible, no una captura bonita.

Fórmula / criterio

Lab bueno = baseline + hipótesis + métrica + resultado + decisión.

Ejemplo

Comparar reglas vs modelo pequeño enseña más que enseñar solo el modelo ganador.

Decisión

Cada ejercicio debe terminar en seguir, parar, simplificar o medir de nuevo.

Objetivo explícito

Qué concepto se aprende y qué decisión permite tomar.

Reproducible

Datos, versiones, seed, instrucciones y salida esperada.

Evaluable

Métrica, rúbrica o checklist de aceptación.

Comparativo

Baseline simple frente a alternativa más sofisticada.

248Lab 1: A* en un problema pequeño

Modela un problema de rutas o cruce de río como espacio de estados y resuélvelo con A*.

Este lab enseña a pasar de una historia a una formulación. El valor no está solo en obtener el camino final, sino en justificar estado, acciones, costes y heurística para que la solución sea revisable.

Teoría aplicada

El valor del lab es formular estado, acción, coste y heurística, no solo obtener una ruta.

Fórmula / criterio

A*: f(n)=g(n)+h(n); h admisible no sobreestima el coste restante.

Ejemplo

En rutas, distancia en línea recta puede ser admisible; tiempo con tráfico inventado no necesariamente.

Decisión

Entrega traza de frontera y visitados para que el resultado sea auditable.

EntregableQué debe incluirModeloestado inicial, acciones, objetivo y costeHeurísticadefinición y justificación de admisibilidad o trade-offTrazafrontera, visitados y camino elegidoReflexiónqué cambia con BFS, DFS o coste uniforme

249Lab 2: mini planner de una tarea real

Convierte una tarea cotidiana en acciones con precondiciones y efectos. El objetivo es pensar como diseñador de agentes.

El mini planner entrena la habilidad más útil para agentes: convertir instrucciones vagas en pasos ejecutables. Si no puedes escribir precondiciones y efectos, probablemente tampoco puedes automatizar la tarea con seguridad.

Teoría aplicada

Modelar tareas fuerza a separar intención de ejecución verificable.

Fórmula / criterio

Acción = precondiciones + efectos; plan = secuencia que satisface objetivo.

Ejemplo

Publicar release requiere tests verdes antes de etiquetar versión y anunciar.

Decisión

Si una precondición no se puede comprobar, esa acción requiere humano o rediseño.

Elegir tarea→Definir estado→Acciones→Precondiciones→Efectos→Plan

Ejemplos

Enviar factura, preparar release, revisar PR, publicar post, responder ticket con aprobación humana.

250Lab 3: planner vs LLM

Pide a un LLM que proponga un plan y compáralo con tu modelo de precondiciones/efectos.

La comparación muestra dónde brilla el LLM y dónde necesita barandillas. Un plan textual puede ser creativo y útil, pero el modelo formal revela omisiones, dependencias y permisos que el texto puede saltarse.

Teoría aplicada

La comparación enseña qué aporta lenguaje natural y qué aporta modelo formal.

Fórmula / criterio

Tasa de plan válido = planes sin precondiciones violadas / planes generados.

Ejemplo

El LLM sugiere enviar factura antes de validarla; el modelo formal lo marca inválido.

Decisión

Mide omisiones, orden incorrecto, permisos y pasos no ejecutables.

PasoQué medirPlan LLM sin modelopasos plausibles, omisiones y ordenPlan con restricciones explícitasprecondiciones violadas y dependenciasValidaciónqué pasos necesitan tool, datos o aprobaciónConclusióndónde ayuda el LLM y dónde necesitas reglas

251Lab 4: clasificador simple con scikit-learn

Entrena un clasificador con un dataset pequeño, separa train/test y reporta matriz de confusión.

Este ejercicio baja el machine learning a tierra. El objetivo no es usar el modelo más potente, sino recorrer el ciclo mínimo: separar datos, entrenar, predecir, medir y explicar errores.

Teoría aplicada

El lab mínimo de ML debe cubrir datos, split, entrenamiento, predicción y error.

Fórmula / criterio

train_test_split separa aprendizaje de evaluación; reporta precision, recall y F1.

Ejemplo

Un árbol puede acertar mucho train y fallar test si memoriza reglas accidentales.

Decisión

No aceptes accuracy sin matriz de confusión y explicación de errores.

from sklearn.model_selection import train_test_split
from sklearn.metrics import classification_report, confusion_matrix
from sklearn.tree import DecisionTreeClassifier

X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=42)
model = DecisionTreeClassifier(random_state=42).fit(X_train, y_train)
y_pred = model.predict(X_test)
print(confusion_matrix(y_test, y_pred))
print(classification_report(y_test, y_pred))

252Lab 5: interpretar la matriz de confusión

El objetivo no es sacar accuracy alta: es entender qué errores comete el modelo y qué coste tienen.

Interpretar errores es más importante que celebrar una métrica. La matriz obliga a decidir qué fallo duele más y qué cambio harías después: datos, features, umbral, modelo o definición del problema.

Teoría aplicada

Interpretar errores convierte métrica en decisión operativa.

Fórmula / criterio

Coste = c_FP*FP + c_FN*FN; el mejor umbral minimiza coste esperado.

Ejemplo

En soporte, un FP puede enviar un ticket al equipo equivocado; un FN deja un urgente sin tratar.

Decisión

Propón el siguiente cambio: datos, feature, umbral, modelo o redefinición del objetivo.

PreguntaRespuesta esperadaQué clase falla másmirar filas reales y columnas predichasQué error duele másrelacionar FP/FN con impacto de negocioQué métrica elegirprecision, recall, F1 o coste ponderadoQué harías despuésmás datos, features, threshold, otro modelo

253Lab 6: k-means visual

Aplica k-means sobre datos sencillos, visualiza centroides y prueba qué ocurre al cambiar k o escalar variables.

La visualización ayuda a ver que los clusters dependen de decisiones previas. Cambiar escala, k o variables puede cambiar la historia que cuentas, así que el lab debe incluir sensibilidad y no solo una imagen bonita.

Teoría aplicada

La visualización muestra sensibilidad a escala, k e inicialización.

Fórmula / criterio

Inertia baja al subir k; por sí sola no demuestra clusters útiles.

Ejemplo

Con dos variables en escalas distintas, el gráfico cambia al normalizar.

Decisión

Incluye análisis de sensibilidad: k, seed, escala y variables usadas.

1. Carga un dataset numérico pequeño.
2. Normaliza features.
3. Ejecuta k-means con distintos k.
4. Visualiza asignaciones y centroides.
5. Explica qué clusters son estables y cuáles parecen artefactos.

254Lab 7: ontología pequeña + SPARQL

Crea una ontología mínima de un dominio conocido y consulta relaciones con SPARQL.

Crear una ontología pequeña obliga a nombrar conceptos y relaciones con precisión. SPARQL después comprueba si ese modelo responde preguntas exactas, algo que una búsqueda vectorial no garantiza.

Teoría aplicada

Una ontología pequeña enseña precisión conceptual: clases, propiedades, individuos y consultas.

Fórmula / criterio

SPARQL busca patrones; ejemplo: ?x :perteneceA ?y con filtros.

Ejemplo

Un dominio de cursos: Alumno, Curso, Profesor, matriculadoEn, imparte.

Decisión

La ontología vale si responde preguntas exactas que el equipo reconoce como importantes.

ArtefactoMínimo aceptableClases3-5 conceptos principalesPropiedadesrelaciones entre conceptos y atributosIndividuosejemplos concretos del dominioConsultas3 preguntas SPARQL con respuesta verificableExportRDF/Turtle u OWL/XML

255Lab 8: vector search vs SPARQL

Resuelve la misma pregunta con búsqueda vectorial y con consulta estructurada. Observa qué falla en cada una.

Resolver la misma pregunta con dos enfoques hace visible la diferencia entre parecido y estructura. Esa comparación es clave para elegir arquitecturas RAG, GraphRAG o híbridas con criterio.

Teoría aplicada

El mismo problema resuelto de dos formas revela diferencia entre parecido y estructura.

Fórmula / criterio

Vector: ranking por similitud. SPARQL: satisfacción de patrón.

Ejemplo

“Casos parecidos” favorece vector; “quién supervisa a X” favorece grafo.

Decisión

Documenta una pregunta donde cada enfoque falle para aprender el límite real.

PreguntaVectorialSPARQL/KG“Busca casos parecidos”fuertedébil si no hay relaciones suficientes“Qué entidad cumple relación exacta”puede fallarfuerte“Resume evidencia textual”fuerte con citasnecesita documentos asociados“Valida una regla”no garantizafuerte con restricciones

256Lab 9: reglas vs RAG vs agente

Toma una tarea pequeña y resuélvela de tres formas: reglas, RAG y agente con tool. No busques ganador universal: busca límites.

Este lab evita la trampa del martillo único. La misma tarea puede resolverse con reglas, RAG o agente, pero cada enfoque cambia cobertura, coste, riesgo, mantenibilidad y forma de evaluar.

Teoría aplicada

Comparar enfoques evita usar el martillo de moda para todo.

Fórmula / criterio

Eval común: éxito, coste, latencia, cobertura, trazabilidad y riesgo.

Ejemplo

Una política simple puede resolverse con reglas; un caso abierto necesita RAG o agente.

Decisión

Elige el sistema más simple que cumpla la eval y el riesgo aceptable.

Reglas→RAG→Agente con tool→Eval común→Decisión

SistemaMideReglasprecisión, mantenimiento, coberturaRAGgroundedness, citas, abstenciónAgenteéxito, coste, tool calls, errores recuperables

257Lab 10: del notebook a producción

El notebook es laboratorio. Producción requiere convertir intuiciones en scripts, tests, versionado y release gates.

El salto a producción consiste en quitar manualidad y azar. Un notebook valioso debe convertirse en script reproducible, dependencias fijadas, prompts versionados, tests y una eval que bloquee regresiones.

Teoría aplicada

Producción exige quitar azar: dependencias, datos, prompts, seeds y tests fijados.

Fórmula / criterio

Experimento reproducible = código + datos + versión + seed + métrica + artefacto.

Ejemplo

Un notebook que depende de “último modelo” no permite comparar regresiones en junio.

Decisión

Convierte cada celda manual importante en script, test o pipeline.

NotebookProduccióncélulas manualesscript o pipeline reproducibledependencias implícitaslockfile / containerobservación visualtests y métricasprompt sueltoprompt versionado y evalmodelo “actual”ID de modelo y fecha fijados

258Qué debe saber: laboratorios

Un lab bueno termina con evidencia, no con sensación. Si no puedes repetirlo y medirlo, todavía es una demo.

La rúbrica convierte el aprendizaje en evidencia. Si alguien puede reproducir tus resultados, ver tus errores y entender por qué decides seguir o parar, el laboratorio ya enseña ingeniería y no solo uso de herramientas.

Teoría aplicada

La rúbrica transforma aprendizaje en evidencia evaluable por otra persona.

Fórmula / criterio

Nota del lab = reproducibilidad + medición + análisis de error + decisión.

Ejemplo

Un resultado mediocre con buen análisis enseña más que una demo brillante sin trazas.

Decisión

Pide siempre README, comandos, resultados y límites conocidos.

Entregable finalDebe contenerREADMEobjetivo, datos, pasos, decisiónCódigo/notebookversiones, seed, dependenciasResultadosmétricas, errores y ejemplos concretosComparaciónbaseline y alternativaConclusiónseguir, parar o simplificar

259Recursos: mapa de estudio

No intentes leerlo todo linealmente. Elige recursos según la habilidad que quieras consolidar esta semana.

Si quieres aprender...Empieza porQué mirarFundamentos de LLMsStanford CS324Modelado, datos, sistemas, riesgos y comportamiento de modelos grandesPrompting serioPrompt Engineering GuideZero-shot, few-shot, CoT, ReAct, self-consistency y límitesUso profesional de ClaudeAnthropic CoursesClaude API, tool use, MCP, Claude Code y patrones de agenteML desde ceroGoogle ML Crash CourseDatasets, pérdida, gradiente, overfitting, fairness y debugging MLIngeniería aplicadaDeepLearning.AIRAG, agentes, fine-tuning, LangChain, MCP y evaluación prácticaAPIs y producciónOpenAI Docs/Anthropic DocsStructured outputs, tool use, streaming, batch, cache, evals y costesRegla práctica

Por cada hora de lectura, dedica otra hora a reproducir algo mínimo: un notebook, una eval, una llamada API o un agente con una sola tool.

260Recursos: papers y benchmarks que sí merecen tiempo

Estos papers no se leen para memorizar fórmulas: se leen para entender por qué existen las piezas que usas cada día.

BloqueLecturaQué deberías extraerTransformerAttention Is All You NeedAtención, Q/K/V, encoder-decoder y paralelizaciónVisualThe Illustrated TransformerLa intuición visual antes de entrar en álgebraRAGRetrieval-Augmented GenerationSeparar memoria paramétrica de recuperación externaAlineamientoInstructGPT / RLHFPor qué un modelo útil no es solo pretrainingAgentesReAct/ReflexionRazonar, actuar, observar y mejorar con feedbackFine-tuning eficienteLoRA/QLoRAAdaptar comportamiento sin reentrenar todo el modeloEvaluaciónSWE-bench/Hugging Face EvaluateMedir tareas reales, no solo demos bonitas

261Recursos: laboratorio para probar hoy

El objetivo no es instalar veinte cosas. Es tener un laboratorio mínimo para comprobar hipótesis con modelos, datos, costes y evals.

ÁreaHerramientaExperimento buenoAgentes de códigoClaude Code/Codex CLIArreglar un bug con test rojo, diff pequeño y revisión humanaModelos localesLM Studio/OllamaComparar Q4 vs Q8 en latencia, memoria y calidadModel cardsHugging Face ModelsLeer licencia, arquitectura, formato, evals y requisitos de inferenciaNotebooksGoogle ColabPipeline HF, LoRA pequeño, RAG mínimo o Diffusers reproducibleTokens y costeOpenAI Tokenizer/tiktokenCalcular coste antes de mandar 200 páginas al modeloVisualizar arquitecturasTransformer Explainer/CNN ExplainerVer atención, capas y convoluciones con ejemplos interactivosMCPEspecificación oficial/serversExponer una API interna como tool reutilizable por agentesEntregable mínimo

Todo experimento serio termina con: prompt/modelo/versiones, dataset o casos, métrica, coste aproximado, errores observados y decisión de siguiente paso.

262Glosario I: modelos, datos y evaluación

Si una sigla aparece en la presentación, debe poder leerse sin buscarla fuera. Este primer bloque cubre modelos, entrenamiento, retrieval y evaluación.

SiglaSignificadoLectura prácticaLLMLarge Language ModelModelo de lenguaje a gran escala que genera tokens.VLMVision-Language ModelModelo que combina texto e imagen como entrada o salida.MoEMixture of ExpertsMuchos expertos almacenados; pocos activos por token.SSMState Space ModelArquitectura eficiente para secuencias largas; Mamba es la referencia conocida.BPEByte Pair EncodingAlgoritmo de tokenización por fusiones frecuentes.RoPERotary Position EmbeddingsCodificación posicional usada por muchos Transformers modernos.MRLMatryoshka Representation LearningEmbeddings que permiten recortar dimensiones manteniendo utilidad.RAGRetrieval-Augmented GenerationBuscar documentos externos y pasarlos al modelo con citas.GraphRAGGraph Retrieval-Augmented GenerationRetrieval que usa relaciones entre entidades, no solo chunks sueltos.BM25Ranking lexical clásicoBúsqueda por palabras clave; útil junto a embeddings.CRAGCorrective RAGRAG que verifica si el retrieval es suficiente y corrige si no.MRR / nDCGMean Reciprocal Rank / normalized Discounted Cumulative GainMétricas de ranking: si lo relevante aparece arriba y en buen orden.SFT / DPOSupervised Fine-Tuning / Direct Preference OptimizationSFT imita ejemplos; DPO aprende de pares preferido/rechazado.RLHF / RLAIFReinforcement Learning from Human/AI FeedbackRefuerzo con feedback humano o de un juez IA.RFT / RLVRReinforcement Fine-Tuning / Reinforcement Learning from Verifiable RewardsRefuerzo con graders o recompensas verificables como tests o checkers.LoRA / QLoRALow-Rank Adaptation / Quantized LoRAFine-tuning eficiente entrenando adaptadores pequeños.GPTQ / AWQ / GGUFQuantizaciones y formato localReducen memoria o empaquetan modelos para ejecución local.

263Glosario II: agentes, operación y seguridad

Segundo bloque de siglas prácticas: herramientas, despliegue, latencia, seguridad, gobierno y experiencia de usuario.

SiglaSignificadoLectura prácticaMCP / A2AModel Context Protocol / Agent-to-AgentMCP conecta agentes con tools; A2A conecta agentes entre sí.ADK / SDKAgent Development Kit / Software Development KitToolkits para construir agentes o integrarse con una plataforma.API / CLI / IDEApplication Programming Interface / Command-Line Interface / Integrated Development EnvironmentAPI integra software; CLI opera por terminal; IDE concentra edición y herramientas.HITLHuman-in-the-loopHumano aprueba pasos críticos antes de ejecutar acciones.STT / TTSSpeech-to-Text / Text-to-SpeechTranscribir audio a texto o sintetizar voz desde texto.TTFT / p95 / p99Time to First Token / percentiles 95 y 99Miden latencia inicial y latencia de cola, no solo la media.SLA / SLOService Level Agreement / Service Level ObjectiveCompromiso contractual y objetivo interno de fiabilidad.KV cacheKey-Value cacheMemoria de atención reutilizable durante inferencia autoregresiva.CPU / GPU / VRAMCentral/Graphics Processing Unit / Video RAMHardware y memoria que condicionan si un modelo cabe y a qué velocidad.PIIPersonally Identifiable InformationDatos que identifican o pueden identificar a una persona.DLP / DPA / VPCData Loss Prevention / Data Processing Agreement / Virtual Private CloudControles de fuga, contrato de tratamiento de datos y red privada cloud.SBOM / SASTSoftware Bill of Materials / Static Application Security TestingInventario de dependencias y análisis estático de seguridad.CI/CDContinuous Integration / Continuous DeliveryAutomatizar tests, builds, seguridad y despliegues.CoTChain-of-ThoughtRazonamiento paso a paso; no siempre debe exponerse al usuario.SAESparse AutoencoderTécnica de interpretabilidad para descomponer activaciones en features.RMF / ISORisk Management Framework / International Organization for StandardizationMarcos de gestión de riesgo y sistemas de gestión auditables.

264Checklist de exactitud para claims de IA

La presentación circula mucho, así que los claims temporales deben leerse como snapshots verificables, no como verdades permanentes.

ClaimCómo verificarRiesgo si no lo hacesNombre de modeloDocs oficiales o model card; usar ID exacto cuando existaInventar versiones como si fueran públicas.Estado del modeloComprobar si está en preview, estable, legacy, deprecated o discontinuadoRecomendar un endpoint que ya no sirve o está de salida.PrecioPricing oficial, región, cache, batch, input/output y planCostes reales distintos a los de la slide.Context windowDocs del endpoint concreto; separar input, output y thinking tokensPrometer 1M tokens sin medir recuperación ni coste.LicenciaModel card, LICENSE y condiciones comercialesConfundir open weights con open source clásico.BenchmarkSplit, fecha, scaffold, herramientas, presupuesto y contaminaciónLeer un leaderboard como si midiera tu producto.API exampleEjecutar snippet o enlazar docs activasEnseñar parámetros obsoletos o métodos inventados.Seguridad/legalOWASP, política de datos del proveedor, DPA y retenciónMandar datos sensibles sin base contractual clara.

265Pipeline de entrega IA: de idea a producción

Un proyecto de IA no termina cuando una demo responde bien. Termina cuando puedes decidir con datos si seguir, parar o simplificar.

1Caso

Tarea repetitiva, usuario, riesgo y coste de error.

2Dataset

20-100 casos reales con expected o rúbrica.

3Baseline

Humano, script, búsqueda clásica o modelo barato.

4Intervención

Prompt, RAG, tool, fine-tune o agente.

5Medición

Calidad, coste, latencia, seguridad y revisión humana.

6Entrega

Canary, logs, rollback, owner y decisión escrita.

SeñalBuena prácticaRed flagCalidadEval con fallos reales y casos límiteSolo screenshots de una demo felizCoste$/tarea aceptada, no solo $/tokenNo contar reintentos ni revisión humanaRiesgoPermisos mínimos, HITL y logs por acciónTool genérica con acceso amplioMantenimientoVersiones, datasets, prompts y modelos fijadosCambiar modelo sin regresión automática

266Benchmarks contaminados y eval privada

Un benchmark público orienta, pero no sustituye tu eval. Cuanto más famoso es un benchmark, más probable es que parte del dataset, soluciones o estilo hayan entrado en datos de entrenamiento o tuning.

Benchmark público

Sirve para comparar tendencias, familias de modelos y scaffolds. Lee fecha, split, presupuesto, herramientas y reproducibilidad.

orientaciónriesgo de contaminación

Eval privada

Casos recientes de tu dominio, tests ocultos, datos no publicados y métricas ligadas a negocio. Es lo que decide producción.

decisión realregresión continua

SWE-bench Verified

OpenAI dejó de usar SWE-bench Verified en febrero de 2026 por contaminación y recomienda SWE-bench Pro para evaluar coding agents frontier. La lectura correcta: leaderboard público para contexto; eval privada para decidir.

267Siguiente paso: ruta de 30 días

La ruta no es “aprender IA” en abstracto. Es escoger una tarea real, medir un baseline, añadir IA solo donde aporte y terminar con una decisión escrita.

SemanaFocoEntregableCriterio de calidad1Problema, baseline y costeTarea real + 30 casos + comparativa de 3 modelosMismos datos, versión de modelo, latencia y coste por tarea2Contexto y UX verificableRAG mínimo o long-context con citas, abstención y conflictos30 preguntas: con respuesta, sin respuesta y con fuentes contradictorias3Evals y seguridadCSV de eval + rúbrica/juez + tests adversariales básicosFalla cuando debe fallar; mide groundedness, formato, seguridad y coste4Tool, operación y decisiónAgente pequeño con una tool, HITL, logs, rollback y release gateTrace por tarea, permisos mínimos, presupuesto y decisión seguir/parar/simplificar### Entrega final

ADecisión

Seguir, parar o simplificar con razones escritas.

BArquitectura

Prompt, RAG, tool, agente o fine-tune y por qué.

CMétrica

Calidad, latencia, coste por tarea aceptada y riesgos.

DReuso

README, dataset de eval, script y demo reproducible.

Proyecto final recomendado

Automatiza una tarea repetitiva de tu trabajo, pero entrega el expediente completo: caso de uso, datos, eval, modelos probados, arquitectura elegida, coste, controles de seguridad y decisión final.