Un ingénieur de red_mad_robot montre comment bâtir un service NER pour CV, de l'annotation à l'API

Un article pratique publié sur Habr explique comment aborder le NER non pas en théorie, mais sur un cas réel : des CV pour un système RH. L'auteur présente le parcours complet, du choix des entités et de la préparation du jeu de données à l'entraînement du modèle et au lancement d'une API intégrable à un produit en production.

De la tâche au schéma

Le cas repose sur un problème très concret : les recruteurs ont besoin d'un module qui reçoit un CV au format PDF ou DOC, en extrait le texte et y repère le prénom, le nom, l'email, le téléphone, les compétences et la prétention salariale. C'est précisément pour ce scénario que l'approche NER est choisie.

Point important de l'article : l'auteur ne commence pas par le modèle, mais par la clarification des exigences métier. Il faut d'abord comprendre le domaine, la langue des documents, le format d'entrée et les champs dont le client a réellement besoin. Sans cela, même un bon modèle résoudra le mauvais problème.

Une fois les exigences formalisées, l'auteur fixe des étiquettes précises : NAME, SURNAME, EMAIL, PHONE, SKILL et SALARY. Pour l'annotation, il retient le schéma BIO, car dans les CV les compétences s'enchaînent souvent et le modèle doit comprendre où commence chaque entité. L'exemple "Python SQL Docker" est parlant : si l'annotation est mal choisie, le système peut fusionner plusieurs compétences en une seule. C'est exactement le cas où une décision qui semble mineure au départ finit par peser sur la qualité de l'ensemble du système.

Là où le jeu de données casse

Le plus gros bloc de l'article porte sur les données, ce qui est logique : c'est généralement là que passe le plus de temps. Pour l'annotation manuelle, l'auteur utilise Label Studio, mais il règle séparément deux problèmes pratiques : l'outil ne sait pas analyser correctement les PDF par lui-même et gère mal l'import TXT simple. Avant l'annotation, il écrit donc un petit script Python qui extrait le texte des PDF et convertit les documents au format JSON adapté à Label Studio.

« Garbage in — garbage out ».

Vient ensuite la partie particulièrement utile pour les équipes appliquées. L'auteur n'a trouvé aucun jeu de données de CV en russe déjà prêt, ni sur Hugging Face, ni sur Kaggle, ni sur d'autres plateformes populaires. Il a donc fallu combiner plusieurs approches pour constituer le corpus :

• annotation manuelle de CV réels ou préparés dans Label Studio
• traduction en russe de jeux de données de CV en anglais, avec vérification supplémentaire
• génération de CV synthétiques par LLM et de données fictives avec Faker
• ré-annotation des EMAIL et PHONE par regex là où le LLM se trompait

L'article montre bien qu'un LLM ne supprime pas le problème de qualité des données, il ne fait que le déplacer. À la traduction, les emails, les numéros de téléphone et les noms de technologies pouvaient être déformés, et lors de l'annotation automatique le modèle classait parfois un employeur comme Oracle parmi les compétences ou, à l'inverse, laissait passer des étiquettes évidentes. Autre enseignement important : les compétences doivent être annotées dans tout le texte, pas seulement dans le bloc "Compétences", sinon le modèle apprend le gabarit de la section plutôt que l'entité elle-même. Pour la démonstration, l'auteur a réuni 114 documents et six modèles de CV différents, mais précise expressément qu'en production il faut généralement des milliers d'exemples.

Pourquoi mBERT a été retenu

L'auteur construit l'étape de modélisation autour de la famille BERT. Pour l'expérience, il compare six modèles préentraînés, dont mBERT, XLM-RoBERTa, ruBERT et ruRoBERTa-large. L'entraînement a tourné sur une RTX 3090 avec 16 Go de mémoire vidéo, et les longs documents ont en outre été découpés en segments pour tenir dans la fenêtre de contexte du modèle.

L'évaluation a reposé sur la mesure F1, et c'est formellement ruRoBERTa-large qui l'a emporté. Mais l'auteur ne s'arrête pas là et aborde une question qui, dans les projets réels, compte plus qu'un tableau de métriques : combien coûte chaque point de qualité supplémentaire. Le choix final ne s'est pas porté sur le leader du benchmark, mais sur bert-base-multilingual-cased. La raison est simple : mBERT compte 178 millions de paramètres contre 355 millions pour ruRoBERTa-large, et l'écart de F1 est d'environ 0,01. Ce compromis donne une inférence plus rapide et des exigences matérielles moins strictes, ce qui compte surtout si le service doit ensuite tourner non seulement sur GPU, mais aussi sur CPU.

Sur le modèle retenu, l'auteur assemble un service FastAPI avec un endpoint /predict qui reçoit le texte du CV et renvoie les entités trouvées. Autrement dit, l'article mène le cas non pas jusqu'à un notebook d'expérimentation, mais jusqu'à une API minimale viable.

Ce que cela signifie

L'analyse de red_mad_robot a de la valeur parce qu'elle présente le NER comme un problème d'ingénierie et non comme un exercice académique. La conclusion principale est simple : un résultat qui fonctionne ne vient pas du choix d'un modèle à la mode, mais de la combinaison d'une formulation correcte, d'un schéma d'annotation strict, d'une vérification manuelle des données et d'un compromis lucide entre qualité et coût d'inférence.