Un ingeniero de red_mad_robot muestra cómo montar un servicio NER para currículos, del etiquetado a la API

En Habr ha aparecido un artículo práctico sobre cómo abordar el NER no en teoría, sino con un caso real: currículos para un sistema de RR. HH. El autor muestra el recorrido completo, desde la elección de entidades y la preparación del dataset hasta el entrenamiento del modelo y el lanzamiento de una API que puede integrarse en un producto en producción.

De la tarea al esquema

El caso parte de un problema bastante aplicado: los reclutadores necesitan un módulo que reciba un currículo en PDF o DOC, extraiga el texto y localice el nombre, el apellido, el email, el teléfono, las habilidades y el salario esperado. Es justo para ese escenario para el que se elige el enfoque NER.

Un punto importante del artículo: el autor no empieza por el modelo, sino por aclarar los requisitos de negocio. Primero hay que entender el dominio, el idioma de los documentos, el formato de entrada y qué campos necesita realmente el cliente. Sin eso, incluso un buen modelo resolverá un problema equivocado.

Tras formalizar los requisitos, el autor fija etiquetas concretas: NAME, SURNAME, EMAIL, PHONE, SKILL y SALARY. Para el etiquetado elige el esquema BIO, porque en los currículos las habilidades suelen aparecer una tras otra y el modelo debe entender dónde empieza cada entidad. El ejemplo "Python SQL Docker" es ilustrativo: si el etiquetado se elige mal, el sistema puede fusionar varias habilidades en una. Es justo el tipo de caso en el que una decisión aparentemente menor al principio acaba afectando a la calidad de todo el sistema.

Dónde se rompe el dataset

El bloque más extenso del artículo se dedica a los datos, lo cual es lógico: ahí suele irse la mayor parte del tiempo. Para el etiquetado manual el autor usa Label Studio, pero resuelve aparte dos problemas prácticos: el servicio no sabe analizar PDF por sí solo y funciona mal con la importación simple de TXT. Por eso, antes de etiquetar, escribe un pequeño script en Python que extrae el texto de los PDF y convierte los documentos a un formato JSON cómodo para Label Studio.

«Garbage in — garbage out».

A continuación llega la parte especialmente útil para los equipos aplicados. El autor no encontró un dataset de currículos en ruso ya hecho ni en Hugging Face, ni en Kaggle, ni en otras plataformas populares. Así que tuvo que combinar varios enfoques para preparar el corpus:

• etiquetado manual de currículos reales o preparados en Label Studio
• traducción al ruso de datasets de currículos en inglés, con comprobación adicional
• generación de currículos sintéticos con un LLM y datos ficticios de Faker
• reetiquetado de EMAIL y PHONE con regex donde el LLM se equivocaba

El artículo muestra bien que un LLM no elimina el problema de la calidad de los datos, solo cambia su forma. Al traducir, los emails, teléfonos y nombres de tecnologías podían quedar deformados, y en el etiquetado automático el modelo a veces clasificaba como habilidad a un empleador como Oracle o, al contrario, omitía etiquetas evidentes. Otra conclusión importante: las habilidades hay que etiquetarlas en todo el texto, no solo en el bloque "Habilidades"; de lo contrario, el modelo aprende la plantilla de la sección y no la entidad en sí. Para la demostración el autor reunió 114 documentos y seis plantillas de currículo distintas, pero advierte expresamente que para producción suelen hacer falta miles de ejemplos.

Por qué se eligió mBERT

El autor construye la etapa de modelado en torno a la familia BERT. Para el experimento compara seis modelos preentrenados, entre ellos mBERT, XLM-RoBERTa, ruBERT y ruRoBERTa-large. El entrenamiento se hizo en una RTX 3090 con 16 GB de memoria de vídeo, y los documentos largos se dividieron además en fragmentos para que cupieran en la ventana de contexto del modelo.

Para la evaluación se usó la medida F1, y formalmente el mejor resultado fue el de ruRoBERTa-large. Pero el autor no se queda ahí y pasa a una pregunta que en los proyectos reales importa más que una tabla de métricas: cuánto cuesta cada décima extra de calidad. La elección final no recayó en el líder del benchmark, sino en bert-base-multilingual-cased.

El motivo es sencillo: mBERT tiene 178 millones de parámetros frente a los 355 millones de ruRoBERTa-large, y la diferencia en F1 fue de alrededor de 0,01. Ese intercambio ofrece una inferencia más rápida y requisitos de hardware menos exigentes, lo que importa sobre todo si el servicio después debe ejecutarse no solo en GPU, sino también en CPU.

Sobre el modelo elegido, el autor monta un servicio FastAPI con un endpoint /predict que recibe el texto del currículo y devuelve las entidades encontradas. Es decir, el artículo lleva el caso no hasta un notebook de experimentos, sino hasta una API mínimamente viable.

Qué significa

El análisis de red_mad_robot es valioso porque presenta el NER como un problema de ingeniería y no como un ejercicio académico. La conclusión principal es simple: un resultado funcional no nace de elegir un modelo de moda, sino de combinar un planteamiento correcto, un esquema de etiquetado estricto, la revisión manual de los datos y un compromiso sensato entre calidad y coste de inferencia.