Un ingénieur de red_mad_robot a montré comment monter un service NER pour les CV : de l'annotation à l'API

Un article pratique a été publié sur Habr sur la résolution des tâches NER non pas en théorie, mais sur un cas d'usage réel avec des CV pour un système RH. L'auteur démontre le chemin complet : du choix des entités et de la préparation d'un ensemble de données à l'entraînement d'un modèle et au lancement d'une API qui peut être intégrée dans un produit fonctionnel.

De la Tâche au Schéma

Au cœur du cas se trouve une tâche pratique : les recruteurs ont besoin d'un module qui prend des CV au format PDF ou DOC, extrait le texte et trouve les noms, prénoms, adresses e-mail, numéros de téléphone, compétences et salaire attendu. C'est précisément ce scénario qui motive le choix de l'approche NER. Un point important dans l'article : l'auteur commence non pas par le modèle, mais par clarifier les exigences commerciales.

Tout d'abord, vous devez 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ésoudrait le mauvais problème. Après formalisation des exigences, l'auteur définit des étiquettes spécifiques : NAME, SURNAME, EMAIL, PHONE, SKILL et SALARY.

Pour l'annotation, il choisit le schéma BIO car dans les CV, les compétences apparaissent souvent consécutives, et il est important que le modèle comprenne où chaque entité individuelle commence. Un exemple comme « Python SQL Docker » est révélateur : si le schéma d'annotation est mal choisi, le système peut fusionner plusieurs compétences en une. C'est précisément le cas où une décision apparemment mineure au départ affecte ultérieurement la qualité de tout le système.

Où les Ensembles de Données Échouent

La plus grande section de l'article est consacrée aux données, et c'est logique : c'est ici que la plupart du temps est généralement dépensé. Pour l'annotation manuelle, l'auteur utilise Label Studio, mais résout séparément deux problèmes pratiques : le service ne peut pas analyser correctement les PDF par lui-même et fonctionne mal avec l'importation simple de TXT. Donc avant l'annotation, il écrit un petit script Python qui extrait le texte des PDF et convertit les documents en format JSON pratique pour Label Studio.

« Garbage in — garbage out ».

Ce qui suit est particulièrement utile pour les équipes appliquées. L'auteur n'a trouvé aucun ensemble de données de CV en langue russe prêt sur Hugging Face, Kaggle ou autres plates-formes populaires. Il a donc dû combiner plusieurs approches pour la préparation du corpus :

• annotation manuelle de CV réels ou préparés dans Label Studio
• traduction d'ensembles de données de CV en anglais en russe avec vérification supplémentaire
• génération de CV synthétiques via LLM et données fictives de Faker
• annotation supplémentaire de EMAIL et PHONE via regex où le LLM a fait des erreurs

L'article montre bien que LLM ne résout pas le problème de la qualité des données, il change simplement sa forme. Lors de la traduction des CV, les e-mails, les numéros de téléphone et les noms de technologies pouvaient être altérés, et lors de l'annotation automatique, le modèle classait parfois les employeurs comme Oracle comme des compétences, ou inversement, omettait des étiquettes évidentes. Une autre conclusion importante : les compétences doivent être annotées dans tout le texte, et non seulement dans la section « Compétences », sinon le modèle apprendra le modèle de la section plutôt que l'entité elle-même.

Pour la démonstration, l'auteur a rassemblé 114 documents et six modèles de CV différents, mais note directement que la production nécessite généralement des milliers d'exemples.

Pourquoi mBERT a Été Choisi

La phase de modélisation est construite autour de la famille BERT. Pour l'expérience, il compare six modèles pré-entraînés, y compris mBERT, XLM-RoBERTa, ruBERT et ruRoBERTa-large. L'entraînement s'est déroulé sur RTX 3090 avec 16 Go de VRAM, et les longs documents ont été divisés en chunks pour tenir dans la fenêtre de contexte du modèle.

Le score F1 a été utilisé pour l'évaluation, et formellement ruRoBERTa-large a obtenu les meilleurs résultats. Mais l'auteur ne s'arrête pas là et passe à une question qui compte plus dans les projets réels qu'un tableau de métriques : combien coûte chaque fraction supplémentaire de qualité ? Le choix final s'est porté non sur le leader du benchmark, mais sur bert-base-multilingual-cased.

La raison est simple : mBERT a 178M paramètres contre 355M pour ruRoBERTa-large, et la différence de F1 était environ 0,01. Ce compromis offre une inférence plus rapide et des exigences matérielles moins strictes, ce qui est particulièrement important si le service doit fonctionner par la suite non seulement sur GPU mais aussi sur CPU. Au-dessus du modèle sélectionné, l'auteur construit un service FastAPI avec un endpoint /predict qui prend le texte du CV et retourne les entités trouvées.

En d'autres termes, l'article porte le cas non pas à un notebook avec une expérience, mais à une API minimalement viable.

Ce Que Cela Signifie

L'analyse de red_mad_robot est précieuse car elle présente NER comme une tâche d'ingénierie, pas un exercice académique. La conclusion principale est simple : les résultats fonctionnels proviennent non du choix d'un modèle à la mode, mais d'une combinaison de formulation correcte du problème, de schéma d'annotation rigoureux, de vérification manuelle des données et d'un compromis pragmatique entre qualité et coût d'inférence.