Senior AI/ML Engineer — Preguntas de entrevista de ingeniero de IA/ML

Explica el KV caching y la cuantización en inferencia de LLM — ¿por qué importan?

El KV caching guarda los vectores key y value calculados para tokens anteriores, así generar cada token nuevo solo requiere calcular attention para ese único token nuevo en vez de recalcular toda la secuencia — sin esto, la generación autorregresiva sería cuadráticamente más lenta. La cuantización reduce la precisión de los pesos (de FP16 a INT8 o INT4, por ejemplo) para reducir el uso de memoria y aumentar el throughput, cambiando una pérdida de precisión pequeña, normalmente aceptable, por una gran reducción en el costo de serving. Ambas cosas son las que hacen económicamente viable servir un modelo de 70 mil millones de parámetros.

¿Qué es RLHF, y qué problema resuelve en realidad?

RLHF (reinforcement learning from human feedback) toma un modelo ya entrenado para predecir el siguiente token y lo ajusta más para que produzca salidas que las personas realmente prefieran — típicamente entrenando un modelo de recompensa con comparaciones humanas de salidas, y luego usando ese modelo de recompensa para hacer fine-tuning de la política con un algoritmo como PPO. Resuelve la brecha entre "predice texto plausible" y "es útil, honesto y sigue instrucciones", algo que la predicción cruda del siguiente token no optimiza en absoluto. Enfoques más nuevos como DPO logran resultados similares sin un modelo de recompensa separado ni un bucle de RL, por lo que cada vez más equipos se saltan el pipeline clásico de RLHF.

¿En qué se diferencian data, model y pipeline parallelism, y cómo se elige entre ellos?

Data parallelism replica todo el modelo en varios dispositivos y divide el batch, lo cual es simple pero requiere que el modelo completo quepa en un dispositivo. Model parallelism divide el modelo mismo entre dispositivos cuando es demasiado grande para uno solo — tensor parallelism divide capas individuales, pipeline parallelism divide el modelo en etapas procesadas secuencialmente. En la práctica, entrenar un modelo grande usa los tres a la vez, y el verdadero problema de ingeniería es minimizar el overhead de comunicación entre dispositivos, que es lo que realmente limita el throughput.

¿Cómo decides si construir sobre una API de foundation model, hacer fine-tuning de un modelo abierto, o entrenar desde cero?

Entrenar desde cero casi nunca se justifica fuera de un puñado de laboratorios bien financiados — el costo de datos y cómputo es enorme y la capacidad base que obtendrías es peor que la que ya existe. La decisión real es API versus modelo abierto self-hosted: una API se lanza más rápido y no requiere infraestructura propia, pero el costo escala linealmente con el uso y dependes del uptime y los límites de otro; un modelo self-hosted con fine-tuning tiene costo de ingeniería por adelantado, pero da control de datos, economía unitaria predecible a escala, y ninguna dependencia de los cambios de política de un proveedor externo. La sensibilidad y el volumen de los datos suelen resolver el debate más rápido que el modelado puro de costos.

¿Cómo decides entre fine-tuning, retrieval-augmented generation (RAG) y prompt engineering a secas?

Empieza por el prompting — es lo más barato de iterar y a menudo cubre el 80% del problema cuando lo que falta son mejores instrucciones o ejemplos. Recurre a RAG cuando el modelo necesita hechos con los que no fue entrenado o que cambian con frecuencia, porque el retrieval mantiene el conocimiento actualizado sin reentrenar nada y permite citar fuentes. El fine-tuning sirve para enseñar un estilo, formato o habilidad especializada consistente que el modelo base sigue fallando incluso con buen prompt y contexto — y es lo más caro de iterar, porque cada cambio implica un nuevo entrenamiento y una nueva evaluación. La mayoría de los sistemas en producción terminan combinando RAG para los hechos con un modelo ligeramente afinado para el tono y el formato, en vez de elegir solo una opción.