Evaluación de competencias

Evaluación de competencias de Ingeniero de IA

Ingeniero de IA es el título más reetiquetado en tecnología ahora mismo: una tarde siguiendo un tutorial de API queda redactada como ingeniería de IA, y la habilidad que realmente importa —saber cómo saber que una funcionalidad funciona— nunca aparece en un CV. El puesto construye funcionalidades de producto respaldadas por LLM sobre modelos que entrenó otra persona: pipelines de recuperación, arneses de evaluación, orquestación de prompts y herramientas, todo dentro de un presupuesto de latencia y coste. Un candidato reetiquetado puede describir los prompts que escribió; el genuino puede decirte cómo demostró que la funcionalidad funcionaba.

Por eso las trivialidades de prompts y un currículum pulido son el filtro equivocado. La única señal fiable es trabajo con la forma del puesto: pon una funcionalidad LLM realista que está rota de una forma interesante frente al candidato, dale un modelo con el que trabajar, y observa cómo lo dirige, verifica su resultado y lo corrige cuando se equivoca con total seguridad. H-Evaluate genera esa tarea por descripción de puesto, en un entorno donde un modelo está disponible de verdad —generación por puesto, de modo que ningún candidato lo haya ensayado— y califica el comportamiento de fluidez en IA que define el puesto.

Qué evaluar

Las competencias que predicen el desempeño en este puesto, asignadas a los cinco pilares de contratación.

Práctico / sandbox

Muestra de trabajo de funcionalidad rota

Trabajar una funcionalidad rota realista con un modelo a mano —un endpoint de recuperación devolviendo respuestas fluidas pero incorrectas, un agente en bucle por una llamada a herramienta fallida— y ser observado en cómo dirigen, verifican y corrigen el modelo en lugar de confiar en él.

Conocimiento del dominio

Oficio de recuperación y orquestación

Pipelines reales en lugar de una única llamada de embeddings: chunking, ranking y gestión del caso donde la recuperación no devuelve nada útil, más suficiente oficio de software para ejecutar la funcionalidad en producción con logging y fallbacks.

Cognitivo

Disciplina de evaluación

La habilidad definitoria: construir el conjunto de evaluación antes de confiar en la corrección, distinguir la evaluación offline de la online, y tratar 'parecía correcto cuando lo probé' como una confesión, no como evidencia.

Juicio situacional

Criterio ante modos de fallo y coste

Nombrar alucinación, inyección de prompts y deriva sin que se les indique, diseñar para que el modelo sea incorrecto, y razonar en tokens y milisegundos: saber cuándo un modelo más barato es suficiente y cuánto cuesta una funcionalidad a escala.

Conductual

Propiedad y colaboración

Cómo gestionaron una funcionalidad que se desplegó y luego se rompió en producción: la historia de verificación y lo que cambiaron, en lugar de una narrativa ordenada sobre un prompt del que estaban orgullosos.

Práctico / sandbox

Fluidez en IA

La relación de trabajo entre la persona y el modelo, calificada según el marco 4D con Discernimiento y Diligencia ponderados más: detectar que el modelo se equivoca con total seguridad es el objetivo central del puesto.

Cómo estructurar la evaluación

  • 1Construye la tarea alrededor de una funcionalidad rota de forma interesante —un endpoint de recuperación devolviendo respuestas convincentes pero incorrectas, una cadena de prompts que silenciosamente supera el presupuesto de latencia— no un puzzle de pizarra.
  • 2Ejecútala en un entorno donde un modelo esté disponible de verdad en lugar de prohibido, porque es la única forma de ver el comportamiento de fluidez en IA que define el puesto.
  • 3Observa si buscan una evaluación antes de confiar en su propia corrección, nombran un modo de fallo que no mencionaste y notan la implicación de coste del modelo que eligieron.
  • 4Pondera el Discernimiento y la Diligencia por encima de las otras competencias: detectar que el modelo está equivocado importa más que la fluidez con prompts.
  • 5Mantenlo breve y califica con la misma rúbrica: una muestra de trabajo con la forma del puesto más una entrevista estructurada supera a seis rondas de vibraciones.

Señales que predicen el éxito

  • +Busca un conjunto de evaluación antes de confiar en su propio cambio
  • +Nombra un modo de fallo —alucinación, inyección de prompts, deriva— sin que se le indique
  • +Razona sobre coste y latencia sin que se le pregunte, y sabe cuándo un modelo más barato es suficiente
  • +Puede decirte exactamente cómo supo que su última funcionalidad funcionaba

Señales de alerta

  • Describe los prompts que escribió pero no puede decir cómo sabía que la funcionalidad funcionaba
  • Confía en 'parecía correcto cuando lo probé' como evidencia en lugar de construir una evaluación
  • Diseña como si el modelo siempre tuviera razón, sin plan para cuando esté equivocado
  • Publica un prototipo con una demo bonita pero no puede ejecutarlo en producción

Evaluación frente a entrevista

No puedes hacer visible la disciplina de evaluación solo con preguntas en una entrevista, porque el candidato reetiquetado ha leído los mismos posts de blog que tú. Una muestra de trabajo con un modelo a mano lo muestra directamente: observas si buscan una evaluación antes de confiar en una corrección, y si detectan que el modelo se equivoca con total seguridad. Usa la evaluación para reunir esa evidencia y luego la entrevista estructurada para recorrer la muestra de trabajo con ellos: por qué esa corrección, cómo la verificaron, qué comprobarían antes de desplegar. La historia de verificación importa más que la corrección.

Evaluación de competencias

Configura esta evaluación por puesto y seniority

Observa cómo cambia el énfasis en tiempo real al cambiar el puesto y el nivel — sin registro.

Lecturas relacionadas

Preguntas frecuentes

¿Cómo se evalúa a un ingeniero de IA?

Dales una tarea con la forma del puesto con un modelo a mano y obsérvalos trabajar: dirigirlo, verificar su resultado, corregirlo. Una funcionalidad de recuperación que devuelve respuestas convincentes pero incorrectas es un buen prompt. Buscas a alguien que busca una evaluación antes de confiar en su propia corrección, que nombra modos de fallo sin que se le indique, y que razona sobre coste y latencia sin que se le pregunte. Las trivialidades pulidas de prompts no son la señal.

¿Qué habilidades debe cubrir una evaluación de ingeniero de IA?

Disciplina de evaluación primero: la capacidad de demostrar que una funcionalidad funciona antes de que se despliegue, y de escribir el conjunto de evaluación que lo demuestre. Luego pensamiento sobre modos de fallo en torno a alucinación, inyección de prompts y deriva, más ingeniería de latencia y coste, oficio de recuperación y orquestación, y suficiente oficio de software para ejecutarlo en producción. La profundidad en entrenamiento de modelos es opcional: eso es el ingeniero de machine learning.

¿Cuál es la diferencia entre un ingeniero de IA y un ingeniero de machine learning?

Un ingeniero de machine learning entrena, ajusta y sirve modelos: el extremo más orientado a la investigación. Un ingeniero de IA construye funcionalidades de producto sobre modelos que entrenó otra persona: pipelines de recuperación, orquestación de prompts y herramientas, arneses de evaluación, y el presupuesto de latencia y coste a su alrededor. El ingeniero de IA trata el modelo como un componente alrededor del cual ingeniar. La mayoría de los equipos que despliegan funcionalidades LLM quieren a la segunda persona, no a la primera.

¿Es el ingeniero de IA un puesto real o un ingeniero de software reetiquetado?

Es un puesto real con una habilidad central distinta: la disciplina de evaluación. La versión impostora también existe: muchos CVs reetiquetan experiencia en tutoriales de API como ingeniería de IA. La señal delatora es si la persona puede decirte cómo sabía que una funcionalidad funcionaba. Un candidato reetiquetado describe los prompts que escribió; un genuino ingeniero de IA describe el conjunto de evaluación, los modos de fallo que buscó y el presupuesto de coste que mantuvo.