Preguntas de entrevista Ingeniero de IA

La decisión depende de los patrones de acceso a datos, los requisitos de latencia y la naturaleza del conocimiento que necesita el sistema. Si la tarea es generativa y el modelo base ya tiene el conocimiento del dominio integrado, la ingeniería de prompts con un modelo alojado como GPT-4o o Claude suele ser el camino más rápido. El fine-tuning tiene sentido cuando dispones de ejemplos etiquetados de alta calidad del formato de salida exacto que quieres, o cuando la latencia y el coste requieren un modelo más pequeño y especializado. RAG es la elección correcta cuando el sistema necesita acceder a información reciente, propietaria o que cambia frecuentemente. En la práctica, muchos sistemas de producción combinan los tres enfoques: un modelo ajustado para tono y formato, recuperación para conocimiento en tiempo real, y diseño de prompt cuidadoso para unirlos.

Empezaría por la capa de recuperación. Para un caso de uso de soporte, la base de conocimientos incluye típicamente documentación del producto, tickets resueltos anteriormente y documentos de política. Trocearia el contenido cuidadosamente, apuntando a fragmentos de 300 a 500 tokens con superposición significativa, y embedderia cada fragmento con text-embedding-3-large de OpenAI. Almacenaría los embeddings en una base de datos vectorial como Pinecone o pgvector, con filtros de metadatos por categoría de producto e idioma. En la generación, usaría un enfoque en dos etapas: recuperar los cinco fragmentos superiores por similitud coseno, re-clasificarlos con un cross-encoder y pasar los tres mejores al prompt final. También añadiría clasificación de consultas para responder preguntas FAQ obvias directamente sin recuperación.

La evaluación para sistemas LLM debe ocurrir en dos niveles. El primero es la evaluación offline contra un conjunto fijo de entradas y salidas esperadas, que construyo antes de construir la funcionalidad. Creo un conjunto de prueba de al menos 50 casos representativos que cubran entradas típicas, casos límite y modos de fallo conocidos. Puntuo las salidas usando métricas automatizadas como BLEU o ROUGE para tareas extractivas, puntuaciones LLM-as-judge para generación abierta, y revisión humana de una muestra aleatoria. El segundo nivel es la evaluación online en producción mediante señales de usuario: valoraciones, tasas de edición, tasas de escalado y abandono de sesión. Instrumento estas señales desde el primer día porque las evaluaciones offline nunca predicen perfectamente la experiencia del usuario.

La inyección de prompts es uno de los riesgos más serios en cualquier sistema donde la entrada del usuario se incorpora a un prompt. Mi enfoque estándar es una defensa por capas. En la capa de entrada, valido y sanearizo las entradas de usuario antes de que lleguen al prompt, marcando cadenas que contienen patrones de instrucción como 'ignora las instrucciones anteriores'. En el propio prompt, uso un encuadre de rol estricto y delimitadores tipo XML para separar el contenido del sistema de confianza del contenido del usuario no confiable. En la capa de salida, aplico validación para detectar respuestas desviadas antes de que lleguen al usuario. Para aplicaciones de mayor riesgo también registro todas las entradas y salidas para auditoría, y realizo ejercicios periódicos de red-teaming contra el prompt de producción.

Construí una funcionalidad de resumen de documentos para una herramienta interna de gestión del conocimiento. En las pruebas funcionaba bien, produciendo resúmenes precisos y concisos. Tras el lanzamiento, los usuarios reportaron que los resúmenes de contratos legales largos omitían cláusulas clave. La causa raíz era una estrategia de troceado que dividía los documentos en límites de tokens fijos en lugar de límites semánticos como los encabezados de sección. Reescribí el troceador para respetar la estructura del documento, usando encabezados y patrones de listas numeradas para crear fragmentos lógicos. Tras la corrección, la tasa de cláusulas omitidas bajó de aproximadamente el 18% a menos del 3% de los documentos. La lección: la estrategia de troceado es tan importante como la elección del modelo en un sistema RAG.

El equipo de producto de mi empresa anterior quería que nuestro asistente de IA respondiera preguntas sobre los precios de la competencia, usando información extraída de sitios web públicos. Tenía preocupaciones sobre la precisión porque los precios cambian con frecuencia, y el riesgo de reputación si el asistente afirmaba con confianza cifras desactualizadas. Preparé una evaluación de riesgos corta que cubría la vida útil de precisión de los datos, el volumen de tickets de soporte previsible y el riesgo legal en ciertos mercados regulados. El equipo de producto aceptó el argumento de precisión pero aún quería cierta conciencia de la competencia. Acordamos un compromiso: el asistente reconocería las preguntas sobre competidores y redireccionaría a un humano para comparaciones detalladas.

Estábamos ejecutando todas las consultas a través de GPT-4o y nuestro gasto mensual en API había crecido hasta un punto donde la economía unitaria no funcionaba. Realicé un análisis de clasificación de consultas en una muestra de 2.000 consultas y encontré que alrededor del 60% eran búsquedas factuales simples que no necesitaban un modelo grande. Introduje una capa de enrutamiento que enviaba consultas simples a GPT-4o mini y reservaba el modelo completo para tareas de razonamiento complejas. Validé el enrutamiento contra un conjunto de prueba etiquetado manualmente antes del despliegue. El resultado fue una reducción del 54% en el coste de API con puntuaciones de calidad disminuyendo menos del 1%. La lógica de enrutamiento se convirtió en una plantilla usada en otras tres funcionalidades de IA del producto.

La clave es separar las preocupaciones del preprocesamiento, la inferencia del modelo y el postprocesamiento en etapas distintas e independientemente escalables. Para el preprocesamiento mantengo las transformaciones sin estado para que puedan ejecutarse en paralelo. Para la inferencia uso un framework de servicio optimizado como vLLM o TGI para LLMs, que gestiona el batching continuo y la reutilización del KV-cache para aumentar drásticamente el rendimiento. También cuantifico los modelos cuando es posible: pasar de FP16 a INT8 con GPTQ típicamente reduce la memoria a la mitad con una pérdida de calidad mínima. Configuro colas de solicitudes con carriles prioritarios para que las solicitudes interactivas no sean bloqueadas por trabajos por lotes. Finalmente añado caché de respuestas para consultas deterministas mediante una capa de caché semántica.

La monitorización de LLMs difiere de la monitorización ML clásica porque no puedes confiar en una única métrica numérica. Sigo cuatro categorías de señales. Primero, métricas de infraestructura: percentiles de latencia (p50, p95, p99), tasas de error, recuentos de tokens por solicitud y gasto en API. Segundo, señales de calidad de salida: puntuaciones LLM-as-judge automatizadas sobre una muestra de salidas de producción y retroalimentación del usuario como valoraciones con pulgar. Tercero, indicadores de deriva de datos: cambios en la distribución de tipos de consultas de entrada. Cuarto, señales de seguridad: la tasa a la que se activa el filtro de salida o la capa de moderación de contenido. Envío todo esto a un panel de control en Grafana o Datadog con alertas en las métricas que históricamente han precedido las quejas de usuarios.

Empiezo construyendo cuidadosamente el conjunto de entrenamiento, porque la calidad del conjunto de datos importa más que la técnica de fine-tuning. Apunto a al menos 500 ejemplos de alta calidad en el formato de seguimiento de instrucciones que espera el modelo base, con una división 90/10 entrenamiento/evaluación. Uso LoRA o QLoRA para fine-tuning eficiente en parámetros, lo que me permite ajustar un modelo 7B en una sola A100 sin actualizaciones de peso completo, reduciendo significativamente el coste de cómputo. Ejecuto el fine-tune con Axolotl o el Hugging Face Trainer, siguiendo la pérdida de entrenamiento y evaluación por época para detectar sobreajuste. Tras el entrenamiento, evalúo el checkpoint contra el conjunto de evaluación con métricas específicas de la tarea y comparo con el rendimiento del modelo no ajustado. También verifico que el fine-tuning no ha degradado los rechazos en entradas dañinas.