Análisis de Currículos con IA: Intercambios de Precisión Entre Regex, NLP y LLMs
La evolución del análisis de currículos (y sus huellas)
El análisis de currículos solía ser verdaderamente terrible. Durante décadas, la mejor solución era contratar a una empresa como Sovren para ejecutar patrones regex en PDFs y extraer name, email, phone, experience. Los patrones funcionaban en el 60% de los casos: currículos bien formateados con estructuras predecibles. Los casos atípicos (diseños no convencionales, formatos internacionales, emojis, tablas, encabezados) caían entre las grietas.
Este compromiso era aceptable porque no existía alternativa. Por lo tanto, los equipos de contratación construyeron soluciones alternativas: revisión manual de datos analizados, verificaciones de calidad en el backend, validación de números de teléfono y una reluctante aceptación de que el 15% de los datos de los candidatos quedaría dañado.
Luego, NLP (spaCy, StanfordNLP) prometió algo mejor. Reconocimiento de entidades nombradas en texto sin procesar, sin necesidad de regex. Funcionó, pero para tareas de identificación de entidades. Sin embargo, el análisis de currículos no es solo identificación de entidades. Un currículum es un documento semántico: "2020–2022" bajo un encabezado no es solo una fecha, es una fecha de inicio y fin del trabajo. Un modelo de NLP entrenado en artículos de noticias no captura ese contexto.
Ahora, los LLMs (Claude, GPT) pueden leer el contexto semántico. Pero los LLMs son probabilísticos. Sin estructura, alucínan campos, inventan títulos de trabajo y a veces omiten secciones de experiencia completas. La pregunta es: ¿cómo hacer que un LLM analice de forma confiable?
Dónde falla cada enfoque
Regex (era Sovren):
- Falla en: Formato no estándar (línea de tiempo horizontal en lugar de viñetas), encabezados de sección en diferentes fuentes, formatos internacionales de nombres, artefactos de extracción de PDF (espacios adicionales, saltos de línea rotos).
- Funciona en: Currículos bien formateados, de una sola columna, en inglés, de recién graduados o de entornos corporativos.
- Problema: Fragilidad. Un PDF de Canva rompe el patrón.
NLP (spaCy, StanfordNLP):
- Falla en: Comprensión semántica. "2020–2022" parece una fecha para NLP. Pero, ¿por qué está en este currículum? ¿Bajo qué trabajo? ¿Es una fecha de inicio/fin o una credencial independiente?
- Funciona en: Extracción de entidades si el documento está limpio y etiquetado claramente.
- Problema: Sin contexto semántico. Un modelo de NLP no sabe que "Python" bajo "Skills" es diferente de "Python" en "Python consulting firm" (herramienta frente a nombre de empresa).
LLM sin estructura:
- Falla en: Alucinación. "Extrae la experiencia laboral del candidato" devuelve:
[{ title: "Senior Software Engineer", company: "Google", start: "2018", end: "2022" }, { title: "Principal Engineer", company: "Apple", start: "2015", end: "2018" }]— pero solo uno de esos está en el currículum. O faltan secciones completamente porque la ventana de contexto del modelo se cortó. - Funciona en: Resúmenes e interpretaciones abiertas.
- Problema: Sin barandillas. El modelo puede inventar datos que suenen plausibles.
LLM con prompting estructurado (Zod/JSON Schema):
- Falla en: Casos límite complejos (candidato con 15 trabajos, currículum en inglés mixto/no inglés, formato de certificación inusual). Pero rara vez alucinación.
- Funciona en: ~95% de currículos que no son adversariales.
- Problema: Requiere definición de esquema y ajuste de prompting por adelantado.
Lo que el prompting estructurado realmente resuelve
El prompting estructurado + validación (Zod, JSON Schema) obliga al LLM a mantenerse dentro de los límites:
Extract resume data into this schema:
{
name: string,
email: string,
phone: string,
experience: [{ title, company, start, end, summary }],
skills: [string],
education: [{ degree, field, school, graduationYear }]
}
Rules:
- If a field is missing, return null, not a fabricated value.
- Dates must be YYYY or YYYY-MM, not fuzzy strings.
- Skills should be tools/languages mentioned, not vague adjectives.
El esquema + validación detecta alucinaciones. Si el modelo inventa un sexto trabajo cuando el currículum lista cuatro, un validador puede marcarlo. Si devuelve start: "early 2020" (no válido), el esquema lo rechaza y solicita que el modelo se conforme.
Esto no elimina errores —un LLM todavía puede malinterpretar "2020–2022" como "2020–2023"—, pero previene los tipos de errores que regex y NLP no pueden detectar: reordenamiento semántico, extracción contextual y análisis de múltiples documentos.
Los compromisos de precisión
| Enfoque | Precisión* | Latencia | Coste | Robustez |
|---|---|---|---|---|
| Regex | 60–70% | <100ms | $0.01/currículum (in situ) | Frágil |
| NLP | 70–80% | 200–500ms | $0.02/currículum | Medio |
| LLM (sin estructura) | 80–90% | 1–3s | $0.10–0.50/currículum | Propenso a alucinación |
| LLM + estructura + validación | 92–98% | 1–3s | $0.10–0.50/currículum | Robusto |
*Precisión = los campos extraídos coinciden con el currículum de verdad fundamental (nombre, correo electrónico, fechas de trabajo, habilidades). Varía según el formato y la complejidad del currículum.
Cuándo usar cada uno
- Startup de reclutamiento con 50 currículos/mes: LLM + estructura. El coste es insignificante, la precisión importa para la experiencia del candidato.
- ATS empresarial con 10.000 currículos/mes: Híbrido. LLM para nuevas incorporaciones, pero valida contra la base de datos de empleados existentes. Si LLM falla, vuelve a la revisión humana.
- Abastecimiento de alto volumen y bajo contacto: Regex en tu propia pila de análisis de PDF. Acepta un error del 20% y utiliza filtros posteriores para detectarlo.
- Cumplimiento/legal: Nunca confíes únicamente en la extracción automatizada. Siempre verifica humanamente antes de archivar.
Cómo ClarityHire gestiona el análisis de currículos
Cuando un candidato carga o pega un currículum, ClarityHire extrae datos estructurados usando Claude + validación Zod. La extracción incluye nombre, información de contacto, historial laboral, educación y habilidades. Los candidatos entonces revisan y corrigen los datos extraídos antes de que entren en el pipeline: un ser humano en el bucle que mitiga el riesgo del resultado del LLM.
Este enfoque negocia coste (llamadas a API) por precisión y experiencia del candidato. Un candidato ve sus datos analizados y sabe que es correcto antes de ser evaluado. También previene la sorpresa de "tenemos tus datos mal" más tarde cuando una carta de oferta tiene su nombre mal escrito o tu sistema de HR muestra que trabajaron en algún lugar donde no lo hicieron.