Entrevista de AI Engineer en 2026: RAG, Evaluación y System Design
Hola HaWkers, estudiar nombres de modelos ya no basta para explicar cómo funciona una aplicación de IA. El repositorio abierto AI Engineering Interview Questions Company Wise, creado en septiembre de 2026, organiza preguntas sobre recuperación de información, inferencia, agentes, evaluación y seguridad. En la consulta a GitHub realizada para este artículo, registraba 1.562 estrellas. Es una señal de interés por el tema, no una prueba de que cada pregunta haya aparecido en un proceso de selección real.
Si una persona entrevistadora te pidiera diseñar un asistente que responde con documentos internos, ¿por dónde empezarías? Aquí construirás una respuesta verificable: definir el problema, crear un pequeño conjunto de casos, medir la recuperación, observar los fallos y defender las decisiones de arquitectura. Esta guía sirve para practicar en español y adaptarse a una entrevista en inglés, portugués o francés.
Empieza por el trabajo que el sistema debe hacer
Antes de elegir un modelo, describe al usuario, la información disponible y el resultado aceptable. Imagina un equipo de soporte que consulta políticas internas. La pregunta «¿puedo cancelar después de la renovación?» parece sencilla, pero la respuesta depende de la versión de la política, el país, el tipo de contrato y los permisos de quien pregunta. Si ignoras esos detalles, una respuesta fluida puede ser incorrecta.
En una entrevista, explica qué documentos entran en el índice, con qué frecuencia cambian y quién puede acceder a ellos. Después define la salida: una respuesta breve, una referencia al fragmento de origen y una negativa cuando no haya pruebas suficientes. Eso demuestra comprensión del producto y de sus riesgos. La documentación de evaluaciones de OpenAI destaca que probar una aplicación exige casos representativos y criterios claros. El AI Risk Management Framework del NIST también ayuda a pensar en contexto, medición y seguimiento, sin convertir una lista de principios en una garantía automática de seguridad.
Una buena pregunta para devolver es: «¿qué error cuesta más aquí: no responder o responder con una política desactualizada?». La respuesta cambia el umbral de confianza, la necesidad de revisión humana e incluso la experiencia de uso. Haz esa pregunta antes de prometer precisión. Vale más que recitar una arquitectura genérica.
Convierte preguntas sueltas en casos de prueba
Muchas personas practican para entrevistas leyendo largas listas de preguntas e intentando memorizar las respuestas. Para puestos de AI Engineer, conviene convertir algunas en pequeños experimentos. Si el tema es RAG, crea un conjunto con pregunta, documento esperado y respuesta aceptable. Incluye un caso sin respuesta: un sistema fiable debe saber decir que no encontró información.
El siguiente ejemplo usa únicamente la biblioteca estándar de Python. Guárdalo como casos.py y ejecútalo con python casos.py. Los datos son ficticios y sirven para practicar; no representan las reglas de ninguna empresa. La validación inicial evita casos sin pregunta o referencia, un error frecuente en hojas de evaluación preparadas con prisa.
# Casos ficticios para practicar una entrevista técnica.
casos = [
{"pergunta": "Qual é o prazo de cancelamento?", "fonte": "politica_2026", "resposta": "Consulte o contrato vigente."},
{"pergunta": "Como redefinir a senha?", "fonte": "acesso", "resposta": "Use a página de recuperação."},
{"pergunta": "Qual é o preço do plano futuro?", "fonte": None, "resposta": None},
]
for numero, caso in enumerate(casos, start=1):
assert caso["pergunta"], f"Caso {numero} sem pergunta"
assert (caso["fonte"] is None) == (caso["resposta"] is None), f"Caso {numero} incoerente"
print(numero, "respondível" if caso["fonte"] else "sem evidência")Este conjunto todavía es demasiado pequeño para estimar el rendimiento real. En la entrevista, explica cómo ampliarlo: preguntas frecuentes, formulaciones ambiguas, documentos contradictorios, actualizaciones de políticas e intentos de acceder a datos de otra persona. Separa los ejemplos de desarrollo de los de evaluación final para evitar ajustar el sistema mirando las respuestas del examen. Si el ámbito está regulado, solicita una revisión por especialistas.
El repositorio que inspiró este tema sirve como catálogo de asuntos, pero trata sus descripciones de procesos de selección como relatos de sus autores. Comprueba siempre la oferta de trabajo y el contacto de la empresa. Las preguntas públicas cambian; la capacidad de construir una prueba reproducible sigue siendo útil aunque cambie el guion de la entrevista.
Explica RAG como una secuencia de decisiones
RAG combina la recuperación de fragmentos con la generación de respuestas. El diseño mínimo incluye ingesta, división de documentos, indexación, búsqueda, selección de fragmentos y generación con indicación de las fuentes. Pero cada etapa puede perder información. Partir un contrato en medio de una excepción puede eliminar la condición que hace válida una cláusula. Una búsqueda que encuentra el documento correcto, pero usa una versión antigua, también falla.
Demuestra que distingues la calidad de la búsqueda de la calidad de la respuesta. Si el fragmento correcto nunca llega al modelo, cambiar el prompt no resuelve el problema principal. Una métrica sencilla para practicar es recall@k: ¿en cuántos casos aparece el documento esperado entre los primeros k resultados? Este código recibe resultados simulados y cuenta los aciertos sin depender de un servicio externo.
# Comprueba si la fuente esperada apareció entre los tres primeros resultados.
avaliacoes = [
{"esperado": "politica_2026", "recuperados": ["faq", "politica_2026", "arquivo"]},
{"esperado": "acesso", "recuperados": ["acesso", "suporte"]},
{"esperado": "faturamento", "recuperados": ["vendas", "faq"]},
]
k = 3
acertos = sum(item["esperado"] in item["recuperados"][:k] for item in avaliacoes)
recall = acertos / len(avaliacoes)
print(f"recall@{k}: {recall:.1%} ({acertos}/{len(avaliacoes)})")El resultado mide únicamente esta muestra ficticia. No demuestra que la respuesta generada sea correcta ni que la fuente citada respalde la frase final. Dilo explícitamente. Después propón filtros por versión, idioma y permisos; compara búsquedas léxicas, vectoriales e híbridas con los mismos casos; examina manualmente los errores antes de cambiar de herramienta. Una respuesta sólida para la entrevista incluye también las condiciones para detener o revisar el sistema.
Evalúa la respuesta, la negativa y la fuente
Una respuesta puede citar el documento correcto y aun así inventar una conclusión. Por eso la evaluación debe observar al menos tres cosas: si responde a la pregunta, si el fragmento respalda el contenido y si el sistema se niega a responder cuando no hay base suficiente. No reduzcas todo a una sola nota sin saber qué errores oculta. Para una política interna, una afirmación falsa puede ser más grave que una negativa prudente.
El siguiente ejercicio muestra un verificador determinista muy limitado. Solo acepta respuestas cuyas frases aparezcan literalmente en los fragmentos permitidos. En producción, las paráfrasis legítimas requieren una evaluación más sofisticada y revisión humana; aquí la regla estricta sirve para hacer visible el contrato y discutirlo durante la entrevista.
# Verificación didáctica: la respuesta debe estar en el fragmento autorizado.
def verificar_resposta(resposta, trechos):
if not resposta.strip():
return "recusa"
texto_permitido = " ".join(trechos).casefold()
return "sustentada" if resposta.casefold() in texto_permitido else "revisar"
trechos = ["Use a página de recuperação para redefinir a senha."]
print(verificar_resposta("Use a página de recuperação", trechos))
print(verificar_resposta("A senha é enviada por SMS", trechos))
print(verificar_resposta("", []))No presentes el código como un detector universal de alucinaciones. Falla con paráfrasis, negaciones y textos largos. Una solución seria combina criterios automáticos, muestras revisadas por personas, investigación de incidentes y seguimiento tras la publicación. Durante la conversación, explica qué medirías por segmento: idioma, tipo de documento, versión y clase de pregunta. El promedio general puede ocultar un fallo grave en un grupo pequeño.
Registra también el origen de cada afirmación que presenta el sistema. Si se actualiza un documento, debes poder reconstruir qué versión respaldó la respuesta anterior. Sin ese rastro, una reclamación se convierte en una discusión basada en la memoria. Este requisito conecta la evaluación con la arquitectura: el identificador del documento, la versión, la hora de indexación y los fragmentos utilizados deben acompañar la respuesta.
Defiende el system design con límites explícitos
En la pizarra o en el documento de la entrevista, dibuja dos recorridos. El primero actualiza los documentos: recibe una versión, valida los metadatos, aplica el control de acceso y publica un índice nuevo. El segundo atiende la pregunta: autentica a la persona, recupera solo lo que puede ver, genera una respuesta con referencias y registra la operación. Explica cómo evitas que una actualización parcial mezcle fragmentos viejos y nuevos.
Luego habla del presupuesto: límite de tiempo, coste por solicitud, tamaño del contexto y capacidad para atender picos de demanda. No inventes un objetivo de latencia si el enunciado no lo proporciona. Pide el objetivo de servicio y explica cómo lo medirías. Una cola, una caché o un modelo más pequeño pueden ayudar, pero cada elección tiene un coste: la caché necesita invalidarse cuando cambia la política; un modelo más pequeño debe evaluarse con los casos difíciles; una cola puede ser inadecuada para una interacción en tiempo real.
Un registro mínimo ayuda a comparar alternativas. El siguiente código mide una función local y guarda identificadores ficticios sin registrar texto sensible. En un sistema real, los identificadores deben respetar la política de privacidad y el plazo de conservación definido por la organización.
# Cronometra la operación y registra solo los metadatos necesarios.
from time import perf_counter
def responder(pergunta):
return "Consulte a política vigente" if pergunta else "Pergunta vazia"
inicio = perf_counter()
resposta = responder("Posso cancelar?")
duracao_ms = (perf_counter() - inicio) * 1000
evento = {"documento": "politica_2026", "modelo": "exemplo_local", "duracao_ms": round(duracao_ms, 2)}
print(resposta, evento)Este ejemplo no mide una llamada de red ni predice el rendimiento en producción. Demuestra una disciplina: medir la operación real, registrar la versión utilizada y comparar resultados en condiciones equivalentes. En la entrevista, explica qué sucede cuando falla la búsqueda, el modelo tarda demasiado o la cita apunta a un documento eliminado. Una ruta de error clara suele mostrar más madurez que un diagrama lleno de cajas.
La seguridad forma parte de la respuesta técnica
Los documentos recuperados son datos, no instrucciones fiables. Un fragmento puede contener una frase maliciosa que ordene ignorar las reglas o enviar información a otra dirección. El proyecto OWASP Top 10 para aplicaciones con LLM reúne riesgos como la inyección de prompt y la exposición de información sensible. Usa esa referencia para estructurar preguntas de seguridad, sin suponer que un filtro de texto elimina todos los riesgos.
Describe límites concretos: autorización antes de la recuperación, herramientas con permisos mínimos, confirmación para acciones sensibles, aislamiento entre datos de clientes y pruebas con entradas adversarias. Si la aplicación solo responde, no le concedas acceso de escritura. Si puede actuar, registra quién autorizó la acción, qué se solicitó y cuál fue el resultado. Una respuesta responsable distingue con claridad entre leer, sugerir y ejecutar.
Esto también se relaciona con la carrera profesional. Quien está empezando puede demostrar madurez sin construir un producto completo. Un proyecto pequeño con casos de prueba, fallos documentados y decisiones justificadas enseña más que una demostración perfecta basada en un solo prompt. El artículo sobre cómo destacar en las ofertas de empleo júnior de 2026 profundiza en cómo presentar pruebas de tu propio trabajo. Aquí la prueba es sencilla: mostrar qué comprobaste, dónde falló y qué harías después.
Una guía práctica para la próxima entrevista
Dedica una sesión a comprender la oferta y enumerar las tareas que realmente pide. «AI Engineer» puede significar un producto con LLM, infraestructura de inferencia, evaluación o integración de datos. Divide los temas que aparecen en la descripción en tres grupos: puedo explicarlo y demostrarlo; puedo explicarlo, pero necesito practicar; todavía no puedo defenderlo. Esta clasificación evita que dediques todo el tiempo de estudio a novedades irrelevantes para esa selección.
En la siguiente sesión, elige un problema pequeño y construye los casos. Escribe primero la respuesta manual esperada y su fuente; después implementa una búsqueda sencilla y mide dónde se equivoca. En otra sesión, presenta tu arquitectura en voz alta: entrada, permisos, actualización, búsqueda, generación, evaluación y recuperación ante fallos. Pide a alguien que te interrumpa con «¿y si el documento está desactualizado?» o «¿cómo sabes que la respuesta es correcta?». Practicar objeciones prepara mejor que memorizar siglas.
Termina con una hoja de decisiones: supuestos conocidos, preguntas abiertas, alternativas descartadas y métricas pendientes. Si la persona entrevistadora cambia el escenario, podrás adaptar el diseño en vez de defender una receta fija. Sé honesto sobre los límites de los ejemplos. El código de este artículo es didáctico; una aplicación real exige autorización, datos representativos, seguimiento y pruebas proporcionales al riesgo.
Perspectivas: menos memorización, más pruebas
Las listas públicas de preguntas ayudan a conocer el terreno, pero no sustituyen una explicación que resista un caso nuevo. La mejor señal en una entrevista técnica es poder decir qué debe hacer el sistema, cómo verificarías el resultado y en qué condiciones no debería responder. RAG, evaluación y system design forman parte de la misma conversación porque un error en una etapa afecta a las demás.
Lleva un proyecto pequeño que puedas abrir, ejecutar y criticar. Si la oferta pide otra tecnología, conserva el método: delimita el problema, muestra una prueba, explica las decisiones y deja visible la incertidumbre. Eso demuestra práctica de ingeniería, incluso cuando la respuesta correcta es pedir más contexto antes de elegir una herramienta.
¡Vamos con todo! 🦅
📚 ¿Quieres Seguir lo Que Viene Por Delante?
Este artículo trató las entrevistas de AI Engineer, pero el ecosistema cambia cada semana y no todas las novedades se convierten en artículos aquí.
En X comparto lo que estoy probando, los detalles de mis proyectos y las novedades que aparecen antes de convertirse en posts.
Sígueme Allá
💡 Contenido diario sobre desarrollo, carrera y las herramientas que realmente uso