System design de IA en entrevista: estructurar la respuesta en seis pasos

Qué se evalúa realmente

Un enunciado de system design de IA casi siempre es una frase demasiado corta: «diseña un asistente que responda preguntas internas», «propón un sistema que clasifique las solicitudes entrantes». La imprecisión es deliberada. No se observa tu capacidad de producir un esquema completo en cuarenta minutos, sino cómo avanzas cuando el problema todavía no está planteado.

Se miran tres cosas a la vez: cómo encuadras, cómo eliges asumiendo un compromiso y cómo hablas de lo que falla. Quien dibuja de inmediato una arquitectura completa pierde lo primero; quien apila componentes sin jerarquía pierde lo segundo; quien describe un sistema sin mencionar nunca sus modos de fallo pierde lo tercero.

Esta guía cubre solo el ejercicio de diseño. La preparación del conjunto de una entrevista de AI Engineer, con sus otros formatos, se trata aparte.

Encuadrar antes de diseñar

Los primeros minutos convierten una petición en una especificación. Lo esperado es que preguntes en voz alta y expliques por qué cada respuesta cambiaría el diseño. Una pregunta cuya respuesta no cambia nada no aporta en una entrevista.

Usuario y decisión

Quién usa el sistema, en qué momento de su trabajo y qué decide después. Un asistente consultado por un agente de soporte durante una llamada no tiene nada que ver con una herramienta de análisis que se abre una vez por semana. La frecuencia de uso, el nivel del usuario y el coste de un error para él marcan la mayor parte de los compromisos posteriores.

Restricciones funcionales y no funcionales

• Funcional: qué preguntas entran en el alcance, cuáles deben rechazarse, qué formato de respuesta se espera.
• Volumen: número de usuarios, picos de tráfico, tamaño del corpus y frecuencia de actualización.
• Latencia: respuesta percibida como inmediata, tolerancia de unos segundos o proceso asíncrono aceptable.
• Exactitud: coste de una respuesta errónea y obligación o no de citar la fuente.
• Despliegue: alojamiento, región y qué datos pueden o no salir del sistema de información.

Datos disponibles y permisos

Los datos van antes que el modelo. Dónde están, en qué formatos, quién tiene derecho a leerlos y si ese derecho varía según el usuario. Un corpus documental de empresa casi nunca es homogéneo en permisos. Preguntarlo pronto evita diseñar un sistema que habrá que rehacer en la revisión de seguridad.

Elegir una arquitectura y saber justificarla

La progresión esperada va de lo simple a lo complejo, y cada capa se introduce por una necesidad surgida del encuadre. Empezar por la arquitectura más elaborada es un error de método, aunque acabe siendo necesaria.

• Sin búsqueda: una llamada al modelo con instrucciones y contexto aportado por la aplicación basta cuando el alcance es estrecho y el conocimiento estable.
• Búsqueda documental (RAG): se justifica cuando la respuesta depende de un corpus amplio y cambiante, o cuando hay que citar la fuente.
• Herramientas: en cuanto la respuesta exige un dato transaccional, un cálculo o una acción en otro sistema.
• Orquestación en varios pasos o agéntica: reservada a tareas realmente descomponibles y verificables paso a paso, aceptando en voz alta el coste en latencia y variabilidad.

Formula cada añadido como consecuencia, no como preferencia: «como el corpus cambia cada semana y citar la fuente es obligatorio, añado una capa de búsqueda». El tribunal retiene esa frase más que el esquema.

Retrieval y gestión del contexto

En un sistema basado en búsqueda, la calidad percibida rara vez viene del modelo: viene de lo que se le da a leer. Por eso hay que detallar las decisiones de indexación y de selección.

• Troceado: por unidad de sentido más que por tamaño fijo, conservando título, sección y fecha de origen.
• Metadatos: fuente, alcance, versión y permisos; sirven tanto para filtrar como para citar.
• Selección: búsqueda léxica y vectorial combinadas cuando el vocabulario de negocio es específico, reordenamiento cuando prima la precisión.
• Presupuesto de contexto: cuántos pasajes se conservan, cómo se tratan los documentos contradictorios y qué ocurre si no hay nada pertinente.
• Frescura: reindexar al actualizar y hacer efectivas las supresiones.

El caso «ningún pasaje pertinente» merece una respuesta explícita. Un sistema que responde igualmente es un sistema que inventa.

El papel del modelo, sin comparativa

No se pide coronar un modelo, sino decir qué papel cumple y bajo qué restricciones se elige: longitud de contexto útil, coste por petición al volumen previsto, latencia aceptable, capacidad de devolver salida estructurada y alojamiento compatible con los datos tratados. Enunciar esos criterios y añadir que la decisión se zanja con una prueba sobre el conjunto de evaluación es más sólido que dar un nombre.

Lo verdaderamente diferencial es el aislamiento: el sistema debe sobrevivir a un cambio de modelo. Una interfaz de llamada única, instrucciones versionadas y salida validada por esquema hacen ese cambio posible sin reescritura.

Evaluación y gestión de fallos

Es la parte que más se pasa por alto y la que mejor separa niveles. Diseñar sin decir cómo se mide equivale a entregar una intuición.

• Un conjunto de evaluación construido con casos reales, incluidas preguntas fuera de alcance y preguntas ambiguas.
• En la búsqueda: si se recuperan los pasajes correctos y en qué posición.
• En la respuesta: exactitud, anclaje en las fuentes recuperadas y respeto del formato esperado.
• Revisión humana periódica sobre una muestra, para lo que la automatización no capta.
• Seguimiento de la tasa de rechazos y de respuestas sin fuente.

Sobre los fallos, describe el comportamiento esperado: caída del proveedor, tiempo de espera agotado, salida que no valida contra el esquema, ausencia de fuente. Un repliegue explícito —respuesta parcial, derivación a una persona, mensaje de indisponibilidad— vale más que una respuesta producida a toda costa.

Latencia, coste y observabilidad como restricciones de diseño

Estos tres temas no son ajustes de final de proyecto: deciden la arquitectura. Una exigencia de dos segundos descarta cinco llamadas secuenciales. Un volumen alto obliga a una caché, a reducir el contexto transmitido o a usar un modelo más ligero en los pasos intermedios.

• Latencia: desglosarla por etapa (búsqueda, generación, posprocesado) y decir cuál domina.
• Coste: razonarlo por petición y al volumen objetivo, señalando la palanca principal en vez de prometer una optimización general.
• Observabilidad: trazar cada petición, los pasajes recuperados, la versión de instrucciones y de modelo, la latencia por etapa y el resultado de las validaciones.
• Deriva: vigilar el cambio de comportamiento tras una actualización del corpus o del modelo del proveedor.

Seguridad y permisos

Un sistema de respuesta sobre un corpus interno es un sistema de acceso a la información. Los permisos deben aplicarse en el momento de la búsqueda, filtrando por la identidad del usuario, y no después de generar: un pasaje confidencial que entra en el contexto ya se ha filtrado, aunque la respuesta final parezca inocua.

• Filtrar los documentos por los derechos del usuario en el propio índice.
• Tratar las instrucciones incrustadas en los documentos recuperados como datos, nunca como órdenes.
• Acotar las herramientas: permisos mínimos y confirmación humana en las acciones sensibles.
• Registrar accesos, tratar los datos personales y fijar una retención para las trazas.

Caso práctico: asistente de respuestas internas

Enunciado deliberadamente vago: «un equipo de soporte pierde demasiado tiempo buscando en la documentación interna, diseña un asistente». Así se desarrolla.

1. 1

   Encuadrar

   5 min

   Soporte de nivel 1, durante la llamada con el cliente, respuesta en segundos, fuente obligatoria para que el agente pueda verificar. Corpus: documentación de producto y procedimientos, actualizado cada semana, con secciones reservadas a ciertos equipos.

2. 2

   Plantear la versión simple

   5 min

   Búsqueda sobre el corpus filtrado por permisos, respuesta corta con cita y rechazo explícito si no hay pasaje pertinente. Sin agente y sin herramientas: la tarea es pregunta-respuesta anclada.

3. 3

   Detallar la cadena de búsqueda

   10 min

   Troceado por sección conservando los títulos, metadatos de alcance y versión, búsqueda híbrida para absorber el vocabulario de producto y reordenamiento para pasar solo unos pocos pasajes.

4. 4

   Definir la evaluación

   8 min

   Cien preguntas reales sacadas de los tickets, diez de ellas fuera de alcance. Medir la recuperación de pasajes, la exactitud y la proporción de respuestas sin fuente. Revisión humana mensual sobre una muestra.

5. 5

   Tratar las restricciones

   7 min

   Latencia dominada por la generación: respuesta en streaming y caché de preguntas frecuentes. Seguridad: filtrado por permisos en el índice. Observabilidad: traza completa por petición y alerta sobre la tasa de rechazo.

6. 6

   Asumir los límites

   5 min

   Sin respuestas sobre casos contractuales particulares, derivación al nivel 2. Extensión posible a la consulta del expediente del cliente, pero implica herramientas y una revisión de seguridad aparte.

Asumir los compromisos y los límites

Cierra enunciando lo que el sistema no hace, qué has sacrificado y por qué, y qué medirías primero tras la puesta en producción. Ese último minuto suele decidir la evaluación: demuestra que diseñas para un contexto real y no para un esquema.

La misma exigencia de justificación aplica cuando cuentas un proyecto ya entregado: el razonamiento pesa más que el stack. Es otro ejercicio, pero se mira con los mismos ojos.

• AI Engineering
• Evaluación
• Cloud y producción