Caso de uso
Triagem de currículos
Cheque os must-haves e pontue a aderência geral sem inventar experiência.
O problema
A busca por palavras-chave premia currículos inflados e pune quem mudou de carreira.
O que seu código faz com a resposta
Rejeite apenas quando um must-have estiver claramente ausente. Entreviste o restante.
Must-haves primeiro, aderência depois
O state carrega o cargo estruturado (listas must_have e nice_to_have) mais o texto do currículo. Duas perguntas: meet_must_have (o currículo cobre todos os must-haves) e fit (um score de weak a strong). Separar importa porque se comportam de forma diferente: a cobertura de must-haves é verificação de checklist — TypeScript, Postgres e design de API contra cinco anos de Node.js e dois sistemas de billing — enquanto fit é um julgamento graduado que os seus thresholds comandam.
Entreviste as pessoas, não as palavras-chave
Rejeite apenas quando um must-have estiver claramente ausente (probabilidade baixa de meet_must_have com confiança alta). Todo o restante segue em frente — o migrante de carreira que telas por palavras-chave punem é exatamente o ponto da leitura semântica. Mantenha a lista nice_to_have no state: o score de fit a absorve, mas a sua barra para "possible" pode se mover conforme o pipeline enche.
Pitfalls específicos de triagem de currículos
Justiça é uma superfície legal aqui: scores roteiam, humanos decidem, e as rejeições por must-have precisam ser operacionais — uma capacidade ausente, não uma vibe de encaixe cultural. Não mande dados de identidade (nomes, endereços, datas de nascimento) para a chamada de decisão; não são necessários para a cobertura de must-haves. E revise os criteria trimestralmente: credenciais envelhecem, e um must-have que na verdade é nice-to-have é viés por palavra-chave.
O formato da requisição
Esta é a requisição completa que o playground envia para este preset — o mesmo JSON que o seu servidor envia para /v1/systemone com uma chave Bearer.
curl https://jevai.website/api/v1/systemone \
-H "Authorization: Bearer $JEV_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"state": {
"role": {
"title": "Backend engineer",
"must_have": [
"TypeScript",
"Postgres",
"API design"
],
"nice_to_have": [
"Workers",
"payments"
]
},
"resume": "5 years Node.js, shipped two billing systems, strong TypeScript and Postgres. No public-cloud certs."
},
"questions": {
"meet_must_have": {
"type": "noul",
"instructions": "Does the resume cover every item in `role.must_have`?"
},
"fit": {
"type": "score",
"instructions": "How strong is this candidate for the role?",
"criteria": [
"Weak",
"Possible",
"Strong"
]
}
}
}'FAQ sobre este caso de uso
- Isso substitui um recrutador?
- Não — ele antecipa a parte que escala mal: a cobertura de must-haves de primeira passada. Decisões que cortam finalistas continuam humanas, e o score de fit vai para a preparação da entrevista, não para a pilha de rejeitados.
- Como evitamos manipulação por palavras-chave?
- O modelo lê semântica, o que corta dos dois lados: "fazer sistemas de billing" lê mais forte que uma lista de habilidades. Declare os itens de must_have como capacidades, não apenas nomes de ferramentas, e a chamada premia substância em vez de enchimento.
- Currículos são dados sensíveis?
- Sim. O gateway encaminha a requisição ao modelo para calcular a resposta e não guarda o conteúdo — ainda assim, consiga o consentimento do candidato no fluxo e envie apenas o que a decisão precisa.