Análisis de currículum con IA: intercambios de precisión entre regex, NLP y LLM
La evolución del análisis de currículum (y sus huellas)
El análisis de currículum solía ser verdaderamente terrible. Durante décadas, la mejor solución era contratar una empresa como Sovren para ejecutar patrones regex en PDFs y extraer nombre, correo, teléfono, experiencia. Los patrones funcionaban en 60% de casos —currículos bien formateados con estructuras predecibles. Los valores atípicos (diseños no convencionales, formatos internacionales, emoji, tablas, encabezados) cayeron entre las grietas.
Este intercambio era aceptable porque no existía alternativa. Así que los equipos de contratación construyeron soluciones alternativas: revisión manual de datos analizados, verificaciones de calidad de backend, validación de número de teléfono, y una aceptación de mala gana de que 15% de los datos de candidatura serían destrozados.
Luego NLP (spaCy, StanfordNLP) prometió mejor. Reconocimiento de entidades nombradas en texto crudo, sin regex necesario. Funcionó —para tareas de identificación de entidades. Pero el análisis de currículum 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 de trabajo. Un modelo de NLP entrenado en artículos de noticias no captura ese contexto.
Ahora los LLM (Claude, GPT) pueden leer contexto semántico. Pero los LLM son probabilísticos. Sin estructura, alucina campos, inventa títulos de trabajo, y a veces salta secciones enteras de experiencia. La pregunta es: ¿cómo consigues que un LLM analice de manera confiable?
Dónde cada enfoque falla
Regex (era Sovren):
- Falla en: Formato no estándar (cronología horizontal en lugar de viñetas), encabezados de sección en diferentes fuentes, formatos de nombre internacionales, artefactos de extracción de PDF (espacios extra, saltos de línea rotos).
- Funciona en: Currículos bien formateados, una sola columna, en inglés de graduados recientes o fondos corporativos.
- Problema: Fragilidad. Un PDF de Canva rompe el patrón.
NLP (spaCy, StanfordNLP):
- Falla en: Comprensión semántica. «2020–2022» se parece a una fecha para NLP. Pero por qué está en este currículum? ¿Bajo qué puesto? ¿Es fecha de inicio/fin o una credencial independiente?
- Funciona en: Extracción de entidades si el documento es limpio y claramente etiquetado.
- Problema: Sin contexto semántico. Un modelo de NLP no sabe que «Python» bajo «Habilidades» es diferente de «Python» en «empresa de consultoría Python» (herramienta vs. nombre de empresa).
LLM sin estructura:
- Falla en: Alucinación. «Extrae la experiencia laboral de la candidatura» devuelve:
[{ title: "Ingeniero de software sénior", company: "Google", start: "2018", end: "2022" }, { title: "Ingeniero principal", company: "Apple", start: "2015", end: "2018" }]—pero solo uno está en el currículum. O faltan secciones completamente porque la ventana de contexto del modelo se cortó. - Funciona en: Resúmenes de final abierto e interpretaciones.
- Problema: Sin barreras. El modelo puede inventar datos plausibles.
LLM con estructura de prompt (Zod/JSON Schema):
- Falla en: Casos límite complejos (candidatura 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 anticipada y ajuste de prompt.
Qué estructura de prompt realmente resuelve
La estructura de prompt + validación (Zod, JSON Schema) fuerza el LLM a permanecer dentro de barreras:
Extrae datos de currículum en este esquema:
{
nombre: string,
correo: string,
teléfono: string,
experiencia: [{ title, company, start, end, summary }],
habilidades: [string],
educación: [{ degree, field, school, graduationYear }]
}
Reglas:
- Si falta un campo, devuelve null, no un valor fabricado.
- Las fechas deben ser YYYY o YYYY-MM, no strings difusos.
- Las habilidades deben ser herramientas/lenguajes mencionados, no adjetivos vagos.
El esquema + validación atrapa 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 pide al modelo conformarse.
Esto no elimina errores —un LLM todavía puede malinterpretar «2020–2022» como «2020–2023» —pero previene las clases de errores que regex y NLP no pueden atrapar: reordenamiento semántico, extracción contextual, y análisis de múltiples documentos.
Los intercambios de precisión
| Enfoque | Precisión* | Latencia | Costo | Robustez |
|---|---|---|---|---|
| Regex | 60–70% | <100ms | $0.01/curriculum (in situ) | Frágil |
| NLP | 70–80% | 200–500ms | $0.02/curriculum | Media |
| LLM (no estructurado) | 80–90% | 1–3s | $0.10–0.50/curriculum | Propensa a alucinación |
| LLM + estructura + validación | 92–98% | 1–3s | $0.10–0.50/curriculum | Robusta |
*Precisión = campos extraídos coinciden con currículum de verdad del terreno (nombre, correo, fechas de trabajo, habilidades). Varía según formato de currículum y complejidad.
Cuándo usar cada uno
- Startup de reclutamiento con 50 currículos/mes: LLM + estructura. El costo es negligible, la precisión importa para experiencia de candidatura.
- ATS empresarial con 10.000 currículos/mes: Híbrido. LLM para entrada nueva, pero valida contra base de datos de empleados existentes. Si LLM falla, vuelve a revisión humana.
- Obtención de alto volumen bajo contacto: Regex en tu propia pila de análisis de PDF. Acepta error de 20% y usa filtros descendentes para atraparlo.
- Cumplimiento/legal: Nunca confíes en extracción automatizada sola. Siempre verifica humano antes de archivo.
Cómo ClarityHire maneja el análisis de currículum
Cuando una candidatura 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. Las candidaturas luego revisan y corrigen los datos extraídos antes de que vayan a la canalización —derisking del LLM de entrada-humana-en-la-canalización.
Este enfoque intercambia costo (llamadas API) por precisión y experiencia de candidatura. Una candidatura ve sus datos analizados y sabe que son correctos antes de ser evaluada. También previene la sorpresa de «tenemos tus datos mal» después cuando una carta de oferta tiene su nombre mal escrito o tu sistema HR muestra que trabajaban en algún lugar donde no lo hicieron.