Arquitetura da Pipeline

A pipeline de processamento do backend é construída como um Grafo Acíclico Dirigido (DAG) onde os nós (microsserviços) interagem de forma assíncrona, consumindo e produzindo eventos.

Não há um orquestrador central, a sequência de execução de cada etapa da pipeline é determinada pela ordem de consumo e publicação dos eventos. Isso permite que a pipeline evolua de forma incremental, adicionando novos microsserviços e eventos sem a necessidade de alterar o fluxo de execução.

Pipeline de Processamento de Currículos

A pipeline de currículos se divide nos seguintes microsserviços principais:

• api: Recebe o currículo do usuário, submetido via tela de onboarding ou "Meu perfil", e publica o evento ResumeUploaded para iniciar a pipeline.
• loader-kaggle: Fonte alternativa de currículos. Lê datasets CSV do Kaggle e publica o evento ResumeRawLoaded, que também entra na pipeline a partir do processor-prompt-generator.
• processor-prompt-generator: Consome ResumeUploaded (via API) ou ResumeRawLoaded (via Kaggle). Seleciona o prompt de acordo com o atributo source do evento, injeta o texto do currículo no histórico de chat e publica ResumePromptGenerated.
• processor-skill-extractor: Chama o LLM através da API disponibilizada pelo Ollama com o histórico de mensagens gerado na etapa anterior e configurações de inferência (temperatura, top-p, etc.). Devolve uma lista de habilidades candidatas classificadas por tipo (ResumeSkillCandidateExtracted).
• processor-entity-linker: Vincula cada habilidade candidata a um conceito canônico da ESCO via Fuzzy Match e Duplo Diamante (KNN + PPR), consolidando em:
  • ResumeSkillLinked: habilidade vinculada a um URI oficial da ESCO.
  • ResumeSkillCustom: habilidade sem correspondência na ESCO — pode ser um termo legítimo não catalogado ou uma alucinação do LLM.
  • EntityLinkingAnalysisRecorded: evento de observabilidade publicado para cada skill, contendo os resultados intermediários do fuzzy, KNN e PPR.
• connector-neo4j: Consome ResumeSkillLinked e ResumeSkillCustom. Cria o nó (:Resume) (ou atualiza via profile_id) e cria a relação HAS_SKILL apontando para o nó (:Skill) correspondente na ESCO. Skills sem URI ESCO são persistidas como nó (:CustomSkill) com a relação HAS_SKILL.
• connector-mongodb: Consome os eventos da pipeline e armazena informações do currículo em três coleções:
  • raw_resumes: texto original submetido pelo usuário.
  • processed_resumes: lista de habilidades extraídas, profile_id e metadados de identificação do perfil.
  • llm_training_data: cópia de cada evento ResumeSkillLinked e ResumeSkillCustom para uso futuro em fine-tuning do LLM.
  • entity_linking: resultados intermediários do linking (fuzzy, KNN, PPR) persistidos a partir do evento EntityLinkingAnalysisRecorded.

Pipeline de Processamento de Oportunidades

Abaixo simulamos o processo reverso, em que o TCC coleta uma vaga de portal e aplica NLP reverso para parear vagas com currículos:

A pipeline de oportunidades se divide nos seguintes microsserviços principais:

• loader-kaggle: Fonte alternativa de oportunidades. Lê datasets CSV do Kaggle e publica OpportunityScraped, entrando na mesma pipeline a partir do processor-prompt-generator.
• processor-prompt-generator: Consome OpportunityScraped. Seleciona o prompt de acordo com o atributo source do evento, injeta o texto da vaga no histórico de chat e publica OpportunityPromptGenerated.
• processor-skill-extractor: Chama o LLM através da API disponibilizada pelo Ollama com o histórico de mensagens gerado na etapa anterior e devolve uma lista de habilidades candidatas classificadas por tipo (OpportunitySkillCandidateExtracted).
• processor-entity-linker: Vincula cada habilidade candidata a um conceito canônico da ESCO via Fuzzy Match e Duplo Diamante (KNN + PPR), consolidando em:
  • OpportunitySkillLinked: habilidade vinculada a um URI oficial da ESCO.
  • OpportunitySkillCustom: habilidade sem correspondência na ESCO.
  • EntityLinkingAnalysisRecorded: evento de observabilidade publicado para cada skill, contendo os resultados intermediários do fuzzy, KNN e PPR.
• connector-neo4j: Consome OpportunitySkillLinked e OpportunitySkillCustom. Cria o nó (:Opportunity) e a relação REQUIRES_SKILL apontando para o nó (:Skill) correspondente na ESCO. Skills sem URI ESCO são persistidas como nó (:CustomSkill) com a relação REQUIRES_SKILL.
• connector-mongodb: Consome os eventos da pipeline e armazena informações da oportunidade em quatro coleções:
  • raw_opportunities: conteúdo original da vaga obtido pelo loader.
  • processed_opportunities: vaga estruturada com a lista de habilidades extraídas.
  • llm_training_data: cópia de cada evento OpportunitySkillLinked e OpportunitySkillCustom para uso futuro em fine-tuning do LLM.
  • entity_linking: resultados intermediários do linking persistidos a partir do evento EntityLinkingAnalysisRecorded.