Un ingeniero de red_mad_robot mostró cómo montar un servicio de NER para currículums: del etiquetado a la API

Se publicó un artículo práctico en Habr sobre cómo resolver tareas de NER no en teoría, sino en un caso de uso real con currículos para un sistema de RR.HH. El autor demuestra el camino completo: desde la elección de entidades y la preparación de un conjunto de datos hasta el entrenamiento de un modelo y el lanzamiento de una API que se puede integrar en un producto en funcionamiento.

De la Tarea al Esquema

En el corazón del caso está una tarea práctica: los reclutadores necesitan un módulo que tome currículos en formato PDF o DOC, extraiga texto y encuentre nombres, apellidos, direcciones de correo electrónico, números de teléfono, habilidades y salario esperado. Es precisamente este escenario el que impulsa la elección del enfoque de NER. Un punto importante en el artículo: el autor comienza no con el modelo, sino con la aclaración de requisitos comerciales.

Primero, debe entender el dominio, el idioma de los documentos, el formato de entrada y qué campos realmente necesita el cliente. Sin esto, incluso un buen modelo resolvería el problema equivocado. Después de formalizar los requisitos, el autor define etiquetas específicas: NAME, SURNAME, EMAIL, PHONE, SKILL y SALARY.

Para la anotación, elige el esquema BIO porque en los currículos, las habilidades a menudo aparecen consecutivamente, y es importante para el modelo entender dónde comienza cada entidad individual. Un ejemplo como "Python SQL Docker" es revelador: si el esquema de anotación se elige mal, el sistema puede fusionar varias habilidades en una. Este es precisamente el caso en el que una decisión aparentemente menor al principio afecta posteriormente la calidad de todo el sistema.

Dónde Fallan los Conjuntos de Datos

La sección más grande del artículo está dedicada a los datos, y esto tiene sentido: aquí es donde se suele dedicar la mayor parte del tiempo. Para la anotación manual, el autor usa Label Studio, pero resuelve por separado dos problemas prácticos: el servicio no puede analizar PDF correctamente por sí solo y funciona mal con la simple importación de TXT. Así que antes de anotar, escribe un pequeño script en Python que extrae texto de PDF y convierte documentos a formato JSON conveniente para Label Studio.

"Garbage in — garbage out".

Lo que sigue es particularmente útil para equipos aplicados. El autor no encontró ningún conjunto de datos de currículo en idioma ruso listo en Hugging Face, Kaggle u otras plataformas populares. Así que tuvo que combinar varios enfoques para la preparación del corpus:

• anotación manual de currículos reales o preparados en Label Studio
• traducción de conjuntos de datos de currículos en inglés al ruso con verificación adicional
• generación de currículos sintéticos a través de LLM y datos ficticios de Faker
• anotación adicional de EMAIL y PHONE mediante regex donde el LLM cometió errores

El artículo demuestra bien que LLM no elimina el problema de calidad de datos, sino que solo cambia su forma. Durante la traducción de currículos, los correos electrónicos, números de teléfono y nombres de tecnologías podían quedar distorsionados, y durante la anotación automática, el modelo a veces clasificaba empleadores como Oracle como habilidades, o al revés, omitía etiquetas obvias. Otra conclusión importante: las habilidades deben anotarse en todo el texto, no solo en la sección "Habilidades", de lo contrario el modelo aprenderá la plantilla de la sección en lugar de la entidad en sí. Para la demostración, el autor recopiló 114 documentos y seis plantillas de currículo diferentes, pero señala directamente que la producción típicamente requiere miles de ejemplos.

Por Qué Se Eligió mBERT

La fase de modelado se construye alrededor de la familia BERT. Para el experimento, compara seis modelos preentrenados, incluidos mBERT, XLM-RoBERTa, ruBERT y ruRoBERTa-large. El entrenamiento ocurrió en RTX 3090 con 16 GB de VRAM, y los documentos largos se dividieron en chunks para caber dentro de la ventana de contexto del modelo.

Se utilizó la puntuación F1 para la evaluación, y formalmente ruRoBERTa-large tuvo el mejor desempeño. Pero el autor no se detiene ahí y pasa a una pregunta que importa más en proyectos reales que una tabla de métricas: ¿cuánto cuesta cada fracción extra de calidad? La elección final recayó no en el líder del benchmark, sino en bert-base-multilingual-cased.

La razón es simple: mBERT tiene 178M parámetros frente a 355M para ruRoBERTa-large, y la diferencia de F1 fue alrededor de 0,01. Este equilibrio proporciona inferencia más rápida y requisitos de hardware menos estrictos, lo cual es especialmente importante si el servicio posteriormente necesita ejecutarse no solo en GPU sino también en CPU. Sobre el modelo seleccionado, el autor construye un servicio FastAPI con un endpoint /predict que toma texto de currículo y devuelve entidades encontradas.

En otras palabras, el artículo lleva el caso no a un notebook con un experimento, sino a una API mínimamente viable.

Lo Que Esto Significa

El análisis de red_mad_robot es valioso porque presenta NER como una tarea de ingeniería, no un ejercicio académico. La conclusión principal es simple: los resultados en funcionamiento provienen no de la elección de un modelo de moda, sino de una combinación de formulación correcta del problema, esquema riguroso de anotación, verificación manual de datos y un compromiso pragmático entre calidad y costo de inferencia.