Engenheiro da red_mad_robot mostrou como montar um serviço de NER para currículos: da rotulagem à API

Um artigo prático foi publicado no Habr sobre como resolver tarefas de NER não em teoria, mas em um caso de uso real com currículos para um sistema de RH. O autor demonstra o caminho completo: desde a escolha de entidades e preparação de um dataset até o treinamento de um modelo e lançamento de uma API que pode ser integrada em um produto em funcionamento.

Da Tarefa ao Schema

No coração do caso está uma tarefa prática: recrutadores precisam de um módulo que pegue currículos em formato PDF ou DOC, extraia texto e encontre nomes, sobrenomes, endereços de email, números de telefone, habilidades e salário esperado. É precisamente esse cenário que impulsiona a escolha da abordagem de NER. Um ponto importante no artigo: o autor começa não com o modelo, mas com o esclarecimento dos requisitos de negócio.

Primeiro, você precisa entender o domínio, o idioma dos documentos, o formato de entrada e quais campos o cliente realmente precisa. Sem isso, até um bom modelo resolveria o problema errado. Após formalizar os requisitos, o autor define tags específicas: NAME, SURNAME, EMAIL, PHONE, SKILL e SALARY.

Para anotação, ele escolhe o esquema BIO porque em currículos, as habilidades frequentemente aparecem consecutivamente, e é importante para o modelo entender onde cada entidade individual começa. Um exemplo como "Python SQL Docker" é revelador: se o esquema de anotação for escolhido mal, o sistema pode mesclar várias habilidades em uma. Este é precisamente o caso em que uma decisão aparentemente menor no início afeta posteriormente a qualidade de todo o sistema.

Onde os Datasets Falham

A seção maior do artigo é dedicada aos dados, e isso faz sentido: é aqui que a maioria do tempo é geralmente gasta. Para anotação manual, o autor usa Label Studio, mas resolve separadamente dois problemas práticos: o serviço não consegue fazer parse de PDF corretamente por si só e funciona mal com simples importação de TXT. Então antes da anotação, ele escreve um pequeno script em Python que extrai texto de PDF e converte documentos em formato JSON conveniente para Label Studio.

"Garbage in — garbage out".

O que vem a seguir é particularmente útil para equipes aplicadas. O autor não encontrou nenhum dataset de currículo em idioma russo pronto em Hugging Face, Kaggle ou outras plataformas populares. Então ele teve que combinar várias abordagens para preparação do corpus:

• anotação manual de currículos reais ou preparados em Label Studio
• tradução de datasets de currículo em inglês para russo com verificação adicional
• geração de currículos sintéticos através de LLM e dados fictícios do Faker
• anotação adicional de EMAIL e PHONE via regex onde o LLM cometeu erros

O artigo demonstra bem que LLM não elimina o problema de qualidade dos dados—ele apenas muda sua forma. Durante a tradução de currículos, emails, números de telefone e nomes de tecnologias poderiam ficar desfigurados, e durante anotação automática, o modelo às vezes classificava empregadores como Oracle como habilidades, ou inversamente, pulava tags óbvias. Outro insight importante: habilidades precisam ser anotadas em todo o texto, não apenas na seção "Habilidades", caso contrário o modelo aprenderá o template da seção em vez da entidade em si. Para demonstração, o autor coletou 114 documentos e seis templates diferentes de currículo, mas nota diretamente que a produção tipicamente requer milhares de exemplos.

Por Que mBERT Foi Escolhido

A fase de modelagem é construída em torno da família BERT. Para o experimento, ele compara seis modelos pré-treinados, incluindo mBERT, XLM-RoBERTa, ruBERT e ruRoBERTa-large. O treinamento ocorreu em RTX 3090 com 16 GB de VRAM, e documentos longos foram adicionalmente divididos em chunks para caber dentro da janela de contexto do modelo.

F1-score foi usado para avaliação, e formalmente ruRoBERTa-large teve o melhor desempenho. Mas o autor não para aí e passa para uma questão que importa mais em projetos reais do que uma tabela de métricas: quanto custa cada fração extra de qualidade? A escolha final recaiu não no líder do benchmark, mas em bert-base-multilingual-cased.

A razão é simples: mBERT tem 178M parâmetros versus 355M para ruRoBERTa-large, e a diferença de F1 foi cerca de 0,01. Esse trade-off oferece inferência mais rápida e requisitos de hardware menos rigorosos, o que é especialmente importante se o serviço precisar rodar mais tarde não apenas em GPU mas também em CPU. No topo do modelo selecionado, o autor constrói um serviço FastAPI com um endpoint /predict que pega texto de currículo e retorna entidades encontradas.

Em outras palavras, o artigo leva o caso não para um notebook com um experimento, mas para uma API minimamente viável.

O Que Isso Significa

A análise do red_mad_robot é valiosa porque apresenta NER como uma tarefa de engenharia, não um exercício acadêmico. A conclusão principal é simples: resultados em funcionamento vêm não da escolha de um modelo em voga, mas de uma combinação de formulação correta do problema, esquema rigoroso de anotação, verificação manual de dados e compromisso pragmático entre qualidade e custo de inferência.