Caso de uso
Filtrado de currículums
Comprueba los imprescindibles y puntúa el encaje general sin inventar experiencia.
El problema
La búsqueda por palabras clave premia los CV inflados y castiga a quienes cambian de carrera.
Qué hace tu código con la respuesta
Rechaza solo cuando falte claramente un imprescindible. Entrevista al resto.
Primero los imprescindibles, luego el encaje
El estado lleva el rol estructurado (listas must_have y nice_to_have) más el texto del currículum. Dos preguntas: meet_must_have (¿el currículum cubre todos los imprescindibles?) y fit (un score entre weak, possible, strong). La separación importa porque se comportan distinto: la cobertura de imprescindibles es verificación de checklist — TypeScript, Postgres y diseño de API contra cinco años de Node.js y dos sistemas de facturación — mientras que fit es un juicio graduado del que son dueños tus umbrales.
Entrevista a los humanos, no a las palabras clave
Rechaza solo cuando falte claramente un imprescindible (probabilidad baja de meet_must_have con confianza alta). Todo el resto sigue adelante — justamente a quien cambia de carrera lo castigan los filtros por palabras clave, y de eso va la lectura semántica. Mantén la lista nice_to_have en el estado: el score de fit la absorbe, pero tu barra para «possible» puede moverse según se llena el pipeline.
Riesgos propios del filtrado de currículums
La equidad es aquí una superficie legal: los scores enrutan, los humanos deciden, y los rechazos por imprescindibles deben ser operativos — una capacidad ausente, no una impresión sobre el encaje cultural. No envíes datos de identidad (nombres, direcciones, fechas de nacimiento) a la llamada de decisión; no se necesitan para la cobertura de imprescindibles. Y revisa las criteria trimestralmente: las credenciales envejecen, y un imprescindible que en realidad es deseable es sesgo por palabra clave.
La forma de la solicitud
Esta es la solicitud completa que el playground envía para este preset — el mismo JSON que tu servidor envía a /v1/systemone con una clave Bearer.
curl https://jevai.website/api/v1/systemone \
-H "Authorization: Bearer $JEV_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"state": {
"role": {
"title": "Backend engineer",
"must_have": [
"TypeScript",
"Postgres",
"API design"
],
"nice_to_have": [
"Workers",
"payments"
]
},
"resume": "5 years Node.js, shipped two billing systems, strong TypeScript and Postgres. No public-cloud certs."
},
"questions": {
"meet_must_have": {
"type": "noul",
"instructions": "Does the resume cover every item in `role.must_have`?"
},
"fit": {
"type": "score",
"instructions": "How strong is this candidate for the role?",
"criteria": [
"Weak",
"Possible",
"Strong"
]
}
}
}'Preguntas frecuentes sobre este caso de uso
- ¿Esto reemplaza a un reclutador?
- No — se adelanta a la parte que escala mal: la cobertura de imprescindibles de primera pasada. Las decisiones que cortan finalistas siguen siendo humanas, y el score de fit va a la preparación de entrevistas, no a un montón de rechazos.
- ¿Cómo evitamos el juego de palabras clave?
- El modelo lee semántica, lo que corta en ambos sentidos: «enviando sistemas de facturación» se lee más fuerte que una lista de skills. Declara los elementos must_have como capacidades, no solo nombres de herramientas, y la llamada premia la sustancia sobre el relleno.
- ¿Son los currículums datos sensibles?
- Sí. La pasarela reenvía la solicitud al modelo para calcular la respuesta y no conserva el contenido — aun así, obtén el consentimiento del candidato en el flujo y envía solo lo que la decisión necesita.