Seleção alinhada com JD e limite de honestidade

Como construímos o motor de pontuação

Comecei definindo um contrato claro entre a descrição do trabalho e o currículo. O motor lê texto simples, extrai cláusulas e mapeia cada cláusula para uma habilidade ou frase de requisito. Evitei qualquer modelo que tente adivinhar traços ocultos; em vez disso, forcei o sistema a mostrar o texto exato que usou para cada correspondência.

Entradas de dados

A ferramenta aceita dois blocos de texto: a descrição do trabalho e o currículo. Sem análise de arquivos, sem extração de metadados, apenas as strings brutos que você cola. Mantenho o formato original dentro do bloco de evidências para que você possa ver a frase exata que acionou uma pontuação.

Lógica de correspondência

Para cada cláusula de requisito, calculo uma pontuação de similaridade usando um vetor de frequência de termos e frequência inversa de documentos. Se a similaridade ultrapassa um limiar, marco como uma força; caso contrário, torna-se uma lacuna. A pontuação final de ajuste é a média ponderada de todas as pontuações de cláusula, escalonada para 1-10.

Captação de evidências

Cada força ou lacuna armazena a frase de origem do currículo e a cláusula de origem da descrição do trabalho. Armazeno-as como fragmentos de texto simples, não como incorporações, para que você possa auditar a decisão posteriormente. Este bloco de evidências é o que torna a pontuação explicável.

Tabela de exemplo de campos de entrada

Campo | Descrição | Exemplo Descrição do trabalho | Texto livre da função | "Experiência com Python e REST APIs" Currículo | Texto livre do candidato | "Construiu REST APIs usando Python por dois anos" Cláusula correspondente | Cláusula da descrição do trabalho que encontrou uma similaridade acima do limiar | "Experiência com Python e REST APIs" Fragmento de evidência | Frase exata do currículo usada para a correspondência | "Construiu REST APIs usando Python por dois anos"

Fluxo de trabalho típico para um recrutador

Eu uso a ferramenta todas as manhãs quando abro uma nova requisição. As etapas são curtas, repetíveis e deixam um registo escrito.

Etapa 1: Colar descrição do trabalho

Eu copio a descrição completa do trabalho do e-mail do gestor de contratações e cola-a na caixa da esquerda. Eu não edito ou resumo; mantenho a redacção original.

Etapa 2: Upload de currículo

Eu colo o texto do currículo na caixa da direita. Se eu tiver um PDF, primeiro o converto para texto simples com uma ferramenta offline gratuita, e depois colo.

Etapa 3: Revisar scorecard

O motor devolve uma pontuação de ajuste, uma lista de pontos fortes, uma lista de lacunas e as evidências para cada uma. Eu desço pelo registo de evidências para verificar se a correspondência é real e não é um artefacto de palavras-chave aleatórias.

Etapa 4: Adicionar notas

Eu adiciono uma nota curta no meu sistema de acompanhamento de candidatos com um link para a URL do scorecard. Esta nota regista a data, a pontuação e quaisquer perguntas de follow-up que eu tenha para o candidato.

O que o scorecard contém

A saída é deliberadamente limitada ao que pode ser rastreado até os documentos de origem.

Escala de pontuação de ajuste

A pontuação varia de 1 (pouca sobreposição) a 10 (quase sobreposição completa). Considero pontuações abaixo de 4 como uma clara discordância, pontuações 5-7 como dignas de conversa e pontuações 8-10 como fortes candidatos para uma entrevista.

Pontos fortes vs Descrição do Cargo

Cada ponto forte é uma cláusula da Descrição do Cargo que o currículo satisfez. Mostro o texto da cláusula, o percentual de semelhança e o trecho de evidência do currículo.

Indicadores de lacunas

Cada lacuna é uma cláusula da Descrição do Cargo que não atingiu o limiar. Mostro o texto da cláusula, a melhor semelhança encontrada e uma nota de que nenhuma evidência atingiu o corte.

Linhas de evidência

Para cada ponto forte e lacuna, forneço uma citação direta do currículo. Nunca infiro significado; mostro apenas o que o candidato realmente escreveu.

Como nos mantemos dentro das diretrizes da EEOC

Desenvolvi o sistema para evitar qualquer inferência sobre características protegidas. As seguintes seções explicam os passos concretos que tomei.

Atributos que ignoramos

O modelo nunca olha para o nome, endereço, ano de graduação ou qualquer campo que possa sugerir idade, gênero, raça, deficiência ou origem nacional. Removo esses campos antes do processamento se eles aparecerem no texto do currículo.

Como evitamos sinais proxy

Verifico por pistas indiretas, como nomes de escolas que se correlacionam com certos grupos, ou frases que possam revelar afiliação. Se um termo aparece em uma lista de vigilância interna, marco-o para revisão manual e não o uso no cálculo de similaridade.

Registro de auditoria

Cada execução escreve um registro de log que inclui o hash dos textos de entrada, a versão do código de pontuação e o carimbo de data/hora. Mantenho esses registros por seis meses para que possa demonstrar que nenhum dado demográfico foi usado em uma decisão.

O que isto não é

Quero ser claro sobre os limites da ferramenta para que não a confunda com algo que não é.

Não é uma garantia de contratação

A pontuação reflete apenas a semelhança com a descrição do trabalho escrita. Não prediz o desempenho futuro, o ajuste cultural ou a dinâmica da equipa. Nunca apresento a pontuação como uma promessa de que o candidato terá sucesso.

Não é um substituto do julgamento humano

O recrutador ou gestor de contratações deve rever as evidências, falar com o candidato e tomar a decisão final. A ferramenta apenas fornece consistência e rastreabilidade.

Não é um classificador de caixa preta

Ao contrário de modelos opacos que dão um único número sem explicação, o Candidate Score mostra todas as forças, todas as lacunas e o texto exato que produziu cada resultado. Pode ver por que um candidato obteve a pontuação que obteve.

Como lidamos com casos limite

As entradas do mundo real são desordenadas. Eu construí guardas específicas para as situações que vejo com mais frequência.

Secções em falta

Eu não penalizo um candidato por um layout não padrão.

Documentos muito longos

Eu truncar as entradas para 10 000 caracteres antes da pontuação de semelhança para manter os tempos de execução previsíveis. Eu armazeno o texto completo no bloco de evidências para que nada seja perdido para revisão.

Múltiplos idiomas

Eu detecto o idioma de cada bloco com um classificador leve. Se o currículo e o JD estiverem em idiomas diferentes, eu retorno um aviso e não calculo uma pontuação.

Abreviaturas ambíguas

Eu expando acrónimos comuns usando um dicionário interno antes de calcular a semelhança. Se um acrónimo não estiver no dicionário, eu trato-o como um token literal.

Como atualizamos o modelo

As melhorias vêm dos comentários dos utilizadores e da orientação externa sobre o uso seguro da IA.

Ciclo de feedback

Todos os meses, exporto cartões de pontuação anonimizados com notas de recrutadores sobre falsos positivos e falsos negativos. Reviso essas notas para ajustar o limiar de semelhança ou para adicionar novas palavras de paragem.

Normas externas

Sigo o OWASP Top 10 para Aplicações LLM quando avalio os riscos de injeção de prompts, mesmo que a ferramenta não exponha uma interface de prompt aos utilizadores finais.

Controlo de versões

Cada lançamento recebe uma etiqueta de versão semântica. Publico um breve registo de alterações que lista quaisquer alterações à lista de palavras de paragem, ao limiar de semelhança ou à lógica de extração de evidências.

Lista de verificação do operador para triagem alinhada com JD e limite de honestidade

Mantenho uma lista de verificação escrita ao lado de cada lançamento que toca neste tópico. A lista é propositadamente monótona: nomear o proprietário, nomear o artifact de evidência e nomear o rollback. Se um passo não puder produzir um arquivo, um ticket ou uma linha de log, não é um passo - é um desejo.

Antes de alterar a produção

- Congele o branch ou a revisão de configuração que você medirá. - Registre o modo de falha atual com uma entrada concreta e uma saída concreta. - Confirme qual identidade o trabalho é executado e se essa identidade pode alcançar dados que não deve. - Abra as referências principais que você citará: https://owasp.org/www-project-top-10-for-large-language-model-applications, https://www.nist.gov/itl/ai-risk-management-framework.

Enquanto você executa a verificação

- Prefira um caminho reprodutível em vez de dez capturas de tela anedóticas. - Escreva o resultado seguro esperado antes de acionar a ferramenta ou consulta. - Capture o comando exato, prompt, esquema ou regex em teste - não uma paráfrase. - Se o sistema puder agir (enviar, escrever, excluir, transferir), exija um limite de confirmação no mesmo passe.

Depois de terminar

- Arquive o risco residual com um proprietário e uma data, mesmo quando a varredura estiver limpa. - Não converta um check verde em linguagem de vendas que afirme completude. - Execute a mesma lista de verificação quando o modelo, a ferramenta de esquema ou as regras de validação mudarem.

Sinal | O que registrar | Parar o envio? Escrita ou envio inesperado | Nome da ferramenta, args, identidade | Sim até que seja bloqueado Falta de confirmação em ação destrutiva | Caminho de chamada e bypass | Sim Texto não confiável tratado como instrução | Superfície de origem e ação resultante | Sim para alcance do agente Varredura limpa, julgamento aberto | Itens adiados + proprietário | Apenas se o caminho central for seguro

candidatescore ajuda com o primeiro passe mensurável. Escolhas de arquitetura, aprovação legal e afirmações voltadas para o cliente ainda precisam de um proprietário humano. Trate cada linha da lista de verificação como suporte à decisão, não como um certificado.

Como explico limites aos compradores

Quando um prospecto pergunta se o produto "cobrir tudo", respondo com o limite: verificações automatizadas detectam padrões conhecidos; cadeias novas e julgamento de política ainda precisam de revisão. Essa honestidade mantém a carga de suporte baixa e mantém o blog alinhado com o que o produto realmente faz.

Se precisar de uma segunda opinião, combine este texto com as referências abaixo e com a sua própria reprodução de teste. Não pule o passo de reprodução apenas porque um modelo escreveu um resumo confiante.

Referências

- https://owasp.org/www-project-top-10-for-large-language-model-applications - https://www.nist.gov/itl/ai-risk-management-framework

Perguntas frequentes

O que está no scorecard?

Lista pontos fortes correspondentes ao JD, flags de lacunas e as evidências por trás de cada chamada.

A pontuação é explicável?

Sim. Cada chamada inclui evidências, para que você possa ver por que um candidato obteve a pontuação que obteve.

Preciso formatar o currículo?

Você cola o currículo e o JD; a ferramenta lida com a comparação.

Quem deve usá-lo?

Recrutadores e gestores de contratação que desejam uma triagem consistente e baseada em evidências contra um JD escrito.

Sim, todos esses são compatíveis e respeitados.

Referências

- EEOC — Políticas de emprego proibidas - NIST AI RMF

Quer experimentar o produto? Candidate Score

Gerado a 2026-09-17 · apenas fontes primárias · sem métricas de tráfego fabricadas

Leituras relacionadas

- Cartões de pontuação de currículos comprovados por evidências superam classificações de caixas pretas — Candidate Score - A matriz de tópicos de Micro-SaaS de IA da LX