Engenheiro da red_mad_robot mostra como montar um serviço de NER para currículos, da anotação à API

Saiu no Habr um material prático sobre como resolver NER não na teoria, mas num caso real: currículos para um sistema de RH. O autor mostra o caminho completo, da escolha das entidades e da preparação do dataset ao treinamento do modelo e ao lançamento de uma API que pode ser integrada a um produto em operação.

Da tarefa ao esquema

O caso parte de um problema bem aplicado: recrutadores precisam de um módulo que receba um currículo em PDF ou DOC, extraia o texto e encontre nele nome, sobrenome, email, telefone, habilidades e pretensão salarial. É justamente para esse cenário que se escolhe a abordagem de NER.

Um ponto importante do artigo: o autor não começa pelo modelo, e sim pelo esclarecimento dos requisitos de negócio. Primeiro é preciso 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 resolverá o problema errado.

Depois de formalizar os requisitos, o autor fixa tags concretas: NAME, SURNAME, EMAIL, PHONE, SKILL e SALARY. Para a anotação, escolhe o esquema BIO, porque em currículos as habilidades costumam vir em sequência e o modelo precisa entender onde começa cada entidade. O exemplo "Python SQL Docker" é ilustrativo: se a anotação for mal escolhida, o sistema pode juntar várias habilidades em uma só. É exatamente o tipo de caso em que uma decisão que parece pequena no início acaba afetando a qualidade de todo o sistema.

Onde o dataset quebra

O maior bloco do artigo é dedicado aos dados, o que faz sentido: é aí que normalmente se gasta mais tempo. Para a anotação manual o autor usa o Label Studio, mas resolve separadamente dois problemas práticos: o serviço não consegue processar PDF direito por conta própria e funciona mal com a importação simples de TXT. Por isso, antes de anotar, ele escreve um pequeno script em Python que extrai o texto dos PDFs e converte os documentos para um formato JSON conveniente para o Label Studio.

«Garbage in — garbage out».

Depois vem a parte especialmente útil para times aplicados. O autor não encontrou um dataset pronto de currículos em russo nem no Hugging Face, nem no Kaggle, nem em outras plataformas populares. Por isso foi preciso combinar várias abordagens para montar o corpus:

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

O artigo mostra bem que o LLM não elimina o problema da qualidade dos dados, apenas muda sua forma. Na tradução, emails, telefones e nomes de tecnologias podiam ser deturpados, e na anotação automática o modelo às vezes classificava como habilidade um empregador como a Oracle ou, ao contrário, deixava passar tags óbvias. Outra conclusão importante: as habilidades devem ser anotadas em todo o texto, não só no bloco "Habilidades"; caso contrário, o modelo aprende o modelo da seção, e não a entidade em si. Para a demonstração o autor reuniu 114 documentos e seis templates diferentes de currículo, mas ressalva expressamente que em produção normalmente são necessários milhares de exemplos.

Por que escolheram o mBERT

O autor constrói a etapa de modelagem em torno da família BERT. No experimento, compara seis modelos pré-treinados, incluindo mBERT, XLM-RoBERTa, ruBERT e ruRoBERTa-large. O treinamento rodou numa RTX 3090 com 16 GB de memória de vídeo, e os documentos longos foram divididos em chunks para caber na janela de contexto do modelo.

A avaliação usou a métrica F1, e formalmente o melhor foi o ruRoBERTa-large. Mas o autor não para aí e passa a uma pergunta que, em projetos reais, importa mais que uma tabela de métricas: quanto custa cada fração extra de qualidade. A escolha final não recaiu sobre o líder do benchmark, e sim sobre o bert-base-multilingual-cased. O motivo é simples: o mBERT tem 178 milhões de parâmetros contra 355 milhões do ruRoBERTa-large, e a diferença no F1 foi de cerca de 0,01. Essa troca entrega inferência mais rápida e requisitos de hardware menos rígidos, o que pesa principalmente se o serviço depois tiver de rodar não só em GPU, mas também em CPU.

Sobre o modelo escolhido, o autor monta um serviço FastAPI com um endpoint /predict que recebe o texto do currículo e devolve as entidades encontradas. Ou seja, o artigo leva o caso não até um notebook de experimento, mas até uma API minimamente viável.

O que isso significa

A análise da red_mad_robot é valiosa porque mostra o NER como um problema de engenharia, e não como um exercício acadêmico. A conclusão principal é simples: um resultado que funciona não vem da escolha de um modelo da moda, mas da combinação de uma formulação correta, um esquema de anotação rígido, revisão manual dos dados e um compromisso sensato entre qualidade e custo de inferência.