PJB: A Reasoning-Aware Benchmark for Person-Job Retrieval

1. 문제 정의 (Problem Statement)

기존의 검색 모델 평가는 "어떤 모델이 더 높은 점수를 받는가"에 집중했으나, 실제 비즈니스 환경에서는 "시스템이 어디서 실패하고, 그 이유는 무엇인가"를 진단하는 것이 더 시급합니다. 특히 **사람 - 직무 매칭 (Person-Job Matching)**은 다음과 같은 복잡한 요구사항을 가지지만, 이를 체계적으로 진단할 수 있는 벤치마크가 부재했습니다.

• 복합적 추론 요구: 단순한 텍스트 유사도 매칭을 넘어, 명시적 제약 조건 (위치, 학력, 경력 등) 을 검증하는 **병렬 추론 (Parallel Reasoning)**과 직무 역량에 기반한 암시적 스킬 매핑, 이직 경험의 전이 능력 등을 추론하는 **직렬 추론 (Serial Reasoning)**이 동시에 필요합니다.
• 기존 벤치마크의 한계: BEIR, MTEB, BRIGHT 등의 기존 벤치마크는 일반적 검색이나 추론 중심 검색을 다루지만, 긴 문서 (이력서, 채용 공고), 다중 제약 조건, 그리고 직무 역량 기반의 관련성 판단이 필요한 실제 채용 시나리오를 체계적으로 다루지 못했습니다.
• 평가의 왜곡: 단순한 집계 점수 (Aggregate Score) 만으로는 특정 도메인이나 추론 유형에서의 시스템 실패 원인을 파악하기 어렵고, 이로 인해 잘못된 최적화 결정이 내려질 수 있습니다.

2. 방법론 (Methodology)

저자들은 PJB (Person-Job Benchmark) v1.0을 제안하며, 이는 재현 가능하고 진단 가능한 오프라인 검색 평가 데이터셋입니다.

2.1 데이터 구성

• 규모: 약 300 개의 완전한 채용 공고 (JD, Query) 와 약 20 만 개의 이력서 (Resume, Document) 로 구성.
• 관련성 판단 (Relevance): "채용 제안이 확정될 것인가"가 아닌, 직무 역량 (Job-Competency) 기반의 판단 (지원자가 해당 직무를 수행할 충분한 역량과 경험을 증명하는가) 으로 정의.
• 데이터 소스: 2025 년 1 월 이후의 실제 채용 로그 기반.
• 개인정보 보호: 모든 데이터는 이름, 연락처 등 PII(개인식별정보) 를 제거한 비식별화 (De-identification) 처리를 거쳤으며, 민감한 속성은 관련성 판단에 포함되지 않도록 설계되었습니다.

2.2 진단 레이블 (Diagnostic Labels)

단순한 점수 보고를 넘어 시스템의 능력 구조를 분석하기 위해 두 가지 차원의 레이블을 도입했습니다.

1. 도메인 패밀리 (Domain Families): 30 개 이상의 세분화된 직군을 핵심 역량 유사성에 따라 6 가지 패밀리로 통합 (기술 R&D, 제품/운영, HR/행정/재무, 영업/마케팅 지원, 기계/하드웨어, 프로젝트 관리).
2. 추론 유형 (Reasoning Types): 쿼리의 복잡도에 따라 분류.
   • 병렬 전용 (Parallel-only): 명시적 제약 조건만 필터링 (병렬 폭 ≥3, 직렬 깊이 = 0).
   • 혼합 균형 (Hybrid-balanced): 명시적 필터링과 의미적 추론이 모두 필요 (병렬 폭 ≥1, 직렬 깊이 ≥1).
   • 직렬 우세 (Serial-dominant): 광범위한 추론과 증거 조직이 필요 (직렬 깊이 ≥2).

2.3 평가 프로토콜

• 메트릭: 주 지표로 nDCG@10을 사용하며, Recall@20, MRR@10 등을 보조 지표로 활용.
• 분석 방식: 전체 점수뿐만 아니라 도메인 패밀리별, 추론 유형별, 저성능 쿼리 (Zero/Low-gain) 프로파일링을 통해 시스템의 약점을 구체화합니다.

3. 주요 기여 (Key Contributions)

1. 최초의 진단형 채용 검색 벤치마크: 실제 채용 데이터를 기반으로 하며, 도메인 및 추론 유형 레이블을 통해 시스템의 실패 원인을 체계적으로 진단할 수 있는 PJB v1.0 을 구축했습니다.
2. 데이터 구성 및 윤리: 채용 시나리오 특유의 편향 (Bias) 과 프라이버시 리스크를 해결하기 위해 비식별화, 역량 기반 관련성 정의, 민감 속성 배제 등의 준수 방안을 마련했습니다.
3. 시스템 최적화 통찰 제공: 단순 순위가 아닌 "어디에 투자해야 하는지"를 보여주는 능력 지도 (Capability Map) 를 제공합니다.

4. 실험 결과 (Results)

저자들은 자체 모델 (CRE-T1-0.6B) 과 범용 모델 (Qwen3-Embedding-0.6B) 을 대상으로 Query Understanding (QU) 및 Reranking (Rerank) 모듈을 조합한 8 가지 실험을 수행했습니다.

4.1 전체 성능 비교

• 도메인 적응의 중요성: 도메인 특화 훈련을 받은 CRE-T1이 범용 모델인 Qwen3보다 nDCG@10 에서 약 3.5 배 높은 성능을 보였습니다.
• 모듈의 상반된 효과:
  • Rerank: CRE-T1 에서는 안정적으로 성능을 향상시켰으나 (+8.9%), Qwen3 에서는 오히려 성능을 저하시켰습니다 (-26.1%).
  • Query Understanding (QU): 두 모델 모두에서 성능을 저하시켰으며, Rerank 와 결합 시 더 큰 성능 감소를 초래했습니다. 이는 원본 JD 의 구조적 매칭 정보가 손실되었음을 시사합니다.

4.2 도메인 및 추론 이질성 (Heterogeneity)

• 도메인 편차: 같은 모델이라도 도메인 (예: 영업 vs 프로젝트 관리) 에 따라 성능 편차가 매우 컸습니다. 범용 Rerank 는 데이터가 적은 도메인에서 완전히 실패하는 경우가 있었습니다.
• 추론 유형별 차이:
  • CRE-T1 + Rerank: 특히 직렬 우세 (Serial-dominant) 쿼리 (복잡한 추론이 필요한 경우) 에서 성능이 극적으로 향상되었습니다.
  • Qwen3: 모든 추론 유형에서 Rerank 와 QU 모듈이 성능을 악화시켰으며, 특히 직렬 우세 쿼리에서 점수가 0 에 수렴하는 등 심각한 실패를 보였습니다.

4.4 결론

• 기저 모델의 품질이 핵심: 모듈 (Rerank 등) 의 성능 향상 효과는 기저 검색기 (Base Retriever) 의 품질에 크게 의존합니다. 기저 모델의 Recall 이 부족하면 후처리 모듈은 노이즈만 추가할 뿐입니다.
• 단일 지표의 한계: 전체 평균 점수만으로는 시스템의 실제 비즈니스 가치를 판단할 수 없으며, 도메인 및 추론 유형별 세분화된 분석이 필수적입니다.

5. 의의 및 시사점 (Significance)

• 평가 패러다임의 전환: "누가 더 높은 점수를 받나"에서 "시스템이 어디서 왜 실패하는가"로 평가의 초점을 이동시켰습니다.
• 실무적 최적화 가이드: 채용 검색 시스템 개발 시, 무조건적인 모듈 추가보다는 도메인 특화 기저 모델의 강화가 우선되어야 함을 입증했습니다. 또한 Rerank 모듈은 특정 조건 (기저 모델이 강력하고, 직렬 추론이 필요한 경우) 에서만 유효함을 밝혔습니다.
• 윤리적 기준 제시: 채용 데이터의 민감성을 고려한 비식별화 및 편향 제거 프로세스를 벤치마크 구축 단계에 통합하여, AI 채용 도구의 공정성과 투명성 확보에 기여합니다.

요약하자면, PJB 는 채용 검색이라는 복잡한 실제 시나리오를 위해 설계된 최초의 진단형 벤치마크로, 단순한 성능 비교를 넘어 시스템의 구조적 한계를 파악하고 효율적인 최적화 전략을 수립하는 데 필수적인 도구입니다.