Fundamentos antes que herramientas: cómo evaluar y construir con IA generativa

Un equipo adopta un asistente de chat, obtiene buenos resultados durante un mes y entonces el proveedor cambia el modelo, el precio o el límite de solicitudes. Nadie en la sala puede decir si la alternativa es mejor, peor o simplemente distinta, porque el equipo aprendió un producto, no un mecanismo. Esa brecha es el tema de este artículo: qué hay que entender de la IA generativa para evaluar sus límites, elegir tecnologías con criterio, evitar depender de una sola herramienta y, en algún momento, construir aplicaciones con un modelo dentro, en lugar de solo escribir en la de otro.^[9]

1. Los fundamentos duran más que las herramientas

La IA generativa suele conocerse a través de una interfaz: una caja de texto, un autocompletado en el editor, un botón que redacta un correo. La interfaz es cómoda y también engañosa, porque esconde lo único que se transfiere entre productos: el mecanismo. Quien sabe cómo produce texto un modelo puede prever dónde va a fallar, decidir qué revisar y leer un lanzamiento nuevo por lo que cambió de verdad. Quien solo sabe qué botones pulsar empieza de nuevo cada vez que los botones cambian de lugar.

• Evaluar limitaciones. Saber que un modelo muestrea de una distribución aprendida explica por qué puede ser fluido y estar equivocado al mismo tiempo, y por qué una frase más segura no es más evidencia.
• Elegir con criterio. Entender la estructura de costos de la inferencia convierte "¿cuál es el mejor modelo?" en "¿qué modelo es adecuado para esta carga, este presupuesto y este listón de calidad?".
• Evitar la dependencia. Cuando sabe qué hace el modelo y qué hace su aplicación, pasar a otro proveedor o a un modelo alojado por usted es una tarea de ingeniería, no una reescritura.

En un ecosistema donde los nombres cambian cada trimestre, el conocimiento conceptual es el activo con mayor vigencia. El resto de este artículo construye ese conocimiento en el orden en que un ingeniero lo necesita: primero las capas, luego el mecanismo, luego los criterios, luego el sistema.^[9,10]

2. Dónde se ubican los LLM: IA generativa, machine learning y deep learning

Los términos suelen usarse como sinónimos, y esa es la primera fuente de decisiones superficiales. Están anidados. El machine learning es el campo de los programas que mejoran a partir de datos en lugar de escribirse regla por regla. El deep learning es el subconjunto que usa redes neuronales con muchas capas para aprender representaciones directamente de los datos brutos.^[1] Los modelos generativos son modelos, en general profundos, entrenados para producir muestras nuevas que siguen los patrones de sus datos de entrenamiento. Los grandes modelos de lenguaje (LLM) son una familia de modelos generativos, construida sobre la arquitectura Transformer y entrenada con texto a una escala enorme.^[2,3] Un asistente de chat no es ninguna de estas cosas: es una aplicación construida sobre un LLM.

La jerarquía importa porque cada nivel responde una pregunta distinta. Cuando alguien usa un chatbot, interactúa con una aplicación: prompts, memoria, herramientas e interfaz son decisiones de aplicación. Cuando elige un LLM, elige una familia de modelo: tamaño, licencia, ventana de contexto y costo son decisiones de modelo. Cuando discute datos de entrenamiento, funciones de pérdida o cómo se representa el significado en vectores, está en el nivel del machine learning y el deep learning. Separar las capas vuelve más preciso el análisis técnico e impide confundir una función de un producto con una propiedad del campo.

Tabla 1 — Los cuatro niveles, la pregunta que responde cada uno y las decisiones que le pertenecen. Una puntuación de benchmark es un hecho del nivel del modelo; una buena respuesta en su producto es un resultado del nivel de la aplicación.^[6]

Practica: abrir en el Lab: Ejercicio 1, Dónde están los LLM

3. El mecanismo detrás de los modelos generativos

Un modelo generativo es un sistema entrenado para aprender los patrones de una distribución de datos y producir salidas nuevas coherentes con esos patrones. Para texto, la receta es concreta: el modelo se entrena para predecir el siguiente token dados los anteriores, sobre un corpus enorme; en la inferencia, un prompt fija el contexto y el modelo muestrea un token a la vez, realimentando cada elección como contexto para la siguiente.^[3] El artículo sobre qué es la IA generativa, más adelante en esta serie, presenta esa factorización en detalle; aquí el interés está en lo que implica para el ingeniero.

Tres consecuencias salen directamente de la ecuación (1). Primera: el modelo no tiene noción de verdad, solo de verosimilitud bajo los datos que vio; una continuación plausible se prefiere a una exacta cuando las dos difieren. Segunda: todo lo que el modelo "sabe" queda congelado en sus parámetros en el momento del entrenamiento; lo que ocurrió después tiene que llegar por el prompt. Tercera: la salida depende de un sorteo, así que el mismo prompt puede producir respuestas distintas, y los parámetros de muestreo forman parte de la superficie de ingeniería, no son un detalle.

Por eso entender el mecanismo cambia la forma de usar la herramienta. Un modelo que responde bien en un contexto y falla en otro no está siendo caprichoso: el primer contexto se parecía a sus datos de entrenamiento y el segundo no, o el prompt dejó fuera lo que los pesos no podían contener. La respuesta pasa a ser una decisión de diseño — recuperar el contexto que falta, restringir el formato de la salida, bajar la temperatura, añadir un paso de validación — en lugar de una petición mejor redactada. La pregunta nunca es solo "¿qué respondió?", sino "¿de dónde viene esta capacidad, y qué límites vienen con ella?".^[7]

Practica: abrir en el Lab: Ejercicio 2, Qué predice el modelo

4. Comparar arquitecturas con criterios de ingeniería

Elegir un modelo por popularidad, o por la impresión que dejó una demostración, es el equivalente, en el nivel de la aplicación, a elegir una base de datos porque está de moda. Una comparación madura mira criterios de ingeniería: cuánto cuesta ejecutar el modelo con la carga esperada, cuánto tarda una solicitud, qué tan bien puede especializarse, qué calidad alcanza en su tarea y qué tan bien encaja en las restricciones del caso — privacidad, licencia, despliegue, idioma.^[6] Un modelo que lidera un benchmark público puede ser la elección equivocada para producción si es demasiado caro o lento para el tráfico, y un modelo modesto puede ser el correcto si la tarea es estrecha y el volumen es alto.

Tabla 2 — Criterios de ingeniería para comparar modelos generativos. "Qué medir" trata deliberadamente de su carga de trabajo: un ranking público mide una distribución de solicitudes distinta de la que verá su producto.^[6,11]

5. Compromisos: calidad, costo, velocidad y especialización

No existe un modelo ideal para todos los escenarios; existen compromisos. Subir la calidad suele significar un modelo más grande, lo que eleva el costo por solicitud y el tiempo de respuesta. Buscar velocidad significa un modelo más pequeño o salidas más cortas, lo que puede reducir la precisión. Especializar una solución para un dominio puede entregar más valor que el modelo más general disponible, al precio de mantener actualizada la versión especializada. Los resultados de escala hacen explícita la forma de esas curvas: la capacidad crece suavemente con parámetros, datos y cómputo, y la factura también.^[4,5]

Dos fórmulas concretan el lado del costo y la velocidad. El costo de una solicitud es el número de tokens de entrada por el precio de entrada más el número de tokens de salida por el precio de salida; los tokens de salida suelen ser varias veces más caros que los de entrada, así que las respuestas verbosas cuestan más que los prompts largos. La latencia de una solicitud es el tiempo hasta el primer token más el número de tokens de salida dividido por la tasa de generación; ese segundo término es la razón de que una respuesta de 500 tokens parezca lenta incluso viniendo de un modelo rápido.^[11]

El trabajo de ingeniería consiste en equilibrar esas variables según el objetivo de negocio, el presupuesto y la experiencia que espera el usuario. Un hábito útil es escribir las restricciones antes de mirar cualquier modelo: una latencia máxima, un costo máximo por solicitud, una calidad mínima en la muestra de evaluación. Los candidatos que violan una restricción quedan fuera, sea cual sea su reputación; los restantes se ordenan por una puntuación ponderada. El script siguiente hace exactamente eso, con los pesos como una entrada explícita y revisable.

from dataclasses import dataclass

@dataclass
class Candidato:
    nombre: str
    calidad: float        # 0–1, exactitud en SU muestra de evaluación
    costo: float          # moneda por solicitud, de la ecuación (2)
    latencia_p95: float   # segundos, de la ecuación (3) medida bajo carga
    dependencia: float    # 0–1, qué tan difícil es reemplazarlo (licencia, formatos, alojamiento)

def ordenar(candidatos, costo_max, latencia_max, calidad_min, w):
    """Descarta todo candidato que viola una restricción dura y ordena el resto
    por una puntuación ponderada. w = pesos de calidad, costo, latencia y dependencia."""
    viables = [c for c in candidatos
               if c.costo <= costo_max and c.latencia_p95 <= latencia_max and c.calidad >= calidad_min]
    if not viables:
        raise ValueError("ningún candidato cumple las restricciones: relájelas o cambie el diseño")
    # normaliza costo y latencia contra el peor valor viable, de modo que menor es mejor
    peor_costo = max(c.costo for c in viables)
    peor_lat   = max(c.latencia_p95 for c in viables)
    def puntuacion(c):
        return (w["calidad"] * c.calidad
                + w["costo"]    * (1 - c.costo / peor_costo)
                + w["latencia"] * (1 - c.latencia_p95 / peor_lat)
                + w["dependencia"] * (1 - c.dependencia))
    return sorted(viables, key=puntuacion, reverse=True)

# ejemplo: un asistente de soporte interno, 50 mil solicitudes/día, interactivo
pesos = {"calidad": 0.45, "costo": 0.25, "latencia": 0.20, "dependencia": 0.10}
ordenados = ordenar([
    Candidato("grande alojado",     calidad=0.93, costo=0.012, latencia_p95=4.8, dependencia=0.8),
    Candidato("mediano abierto",    calidad=0.84, costo=0.004, latencia_p95=2.9, dependencia=0.3),
    Candidato("pequeño ajustado",   calidad=0.88, costo=0.001, latencia_p95=1.1, dependencia=0.2),
], costo_max=0.010, latencia_max=3.0, calidad_min=0.80, w=pesos)
print([c.nombre for c in ordenados])   # el grande alojado queda fuera: demasiado lento y caro para este caso

Lo importante del script no es la aritmética sino la disciplina: restricciones primero, pesos explícitos, calidad medida en su propia muestra. Con esos tres en su lugar, "elegimos el modelo X" se convierte en una afirmación que alguien puede auditar y revisar cuando cambien los números.^[8]

Practica: abrir en el Lab: Ejercicio 3, Criterios de trade-off

6. Construir soluciones reales con IA

Construir una solución real significa dejar el uso pasivo de una herramienta y diseñar una aplicación que resuelve un problema concreto del día a día de alguien. El modelo es un componente de esa aplicación, y rara vez el más grande. A su alrededor están el código que arma el prompt a partir de la solicitud del usuario y del contexto relevante, la recuperación que trae documentos que los pesos no podían contener, las herramientas que el modelo puede invocar, la validación que revisa la salida antes de que llegue a alguien y la observabilidad que dice cuánto cuesta y con qué frecuencia falla.^[7,10]

Aquí es donde los fundamentos rinden. Seleccionar el modelo es una decisión entre varias: evaluar la arquitectura, entender el impacto en el flujo de trabajo, decidir qué puede hacer el modelo por su cuenta y qué debe confirmar una persona, y alinear la solución con el tipo de tarea que el equipo o el producto realmente ejecuta. Un profesional que domina estos fundamentos deja de consumir IA y empieza a diseñar sistemas con IA como componente. Ese paso es lo que separa la experimentación de la ingeniería aplicada, y también lo que mantiene vivo el sistema cuando se cambia un modelo: los prompts, la recuperación, las verificaciones y las métricas permanecen.^[10]

Practica: abrir en el Lab: Ejercicio 4, Restricciones duras

7. Un ecosistema que se mueve rápido: adaptarse sin empezar de cero

El ecosistema de la IA generativa se mueve rápido: aparecen continuamente nuevos modelos, herramientas y técnicas, y un ranking de hace seis meses es historia. Seguir el campo, por tanto, no es opcional; forma parte de la competencia técnica necesaria para seguir siendo relevante. Pero seguirlo no significa memorizar nombres de productos. Significa mantener criterios estables para juzgar novedad, madurez y utilidad, de modo que cada lanzamiento pueda leerse rápido: qué cambió en el nivel del modelo, cuánto cuesta, qué cambiaría en su aplicación y si su muestra de evaluación confirma la promesa.^[9,12]

Quien entiende los fundamentos absorbe estos cambios sin empezar de cero con cada nueva tecnología. El Transformer de 2017 sigue siendo la arquitectura bajo los modelos de hoy; el comportamiento de escala descrito en 2020 sigue explicando por qué los modelos más grandes cuestan más; el pipeline de la Figura 2 no ha cambiado. Lo que cambia es la posición de cada producto en el gráfico de compromisos, y para eso exactamente sirven los criterios estables.^[2,4]

Practica: abrir en el Lab: Ejercicio 5, Ecosistema acelerado

8. De usuario a creador

Dominar la IA generativa significa asumir una posición activa en la creación de aplicaciones, y no solo usar interfaces listas. Ese dominio combina el entendimiento técnico del mecanismo, la lectura de un contexto — la tarea, los usuarios, las restricciones — y el oficio de convertir un modelo en una solución útil. En los equipos de software se traduce en decisiones más conscientes sobre adopción, integración y retorno práctico: qué tareas ganan, cuánto cuesta la ganancia y qué hay que revisar. El resultado esperado no es solo productividad individual; es la capacidad de construir mejores productos y mejores flujos de trabajo, con el modelo como una parte bien entendida de ellos. El próximo artículo sigue lo que este cambio significa para la propia profesión: hacia dónde se mueve el diferencial del desarrollador cuando el código deja de serlo, cómo la IA amplifica la competencia y qué cambia para el liderazgo técnico y para los productos.