# 데이터 기반 데이터베이스를 활용한 AI 자동 채우기 구인 필터
구직자들은 헤드헌터(HeadHunter), 슈퍼잡(SuperJob), 자르플라타(Zarplata.ru), 트루드브셈(TrudVsem) 같은 사이트의 필터 기능에서 자주 어려움을 겪습니다. 분석 결과, 사용자들은 필터 패널을 열고 무작정 데이터를 입력한 뒤 수천 개의 청소부 일자리부터 빈 목록까지 엉뚱한 결과를 보고 이탈합니다. 면책 조항, 필수 필드, 강조 표시 같은 개선책도 실패했습니다. 사용자들이 위축되거나 "일자리" 같은 터무니없는 입력을 하면서 전환율이 오히려 떨어졌죠.
핵심 인사이트: 문제는 복잡성입니다. 각 플랫폼은 도시(헤드헌터는 1,600개에 ID 부여, 슈퍼잡은 자체 체계), 전문 분야, 경력 수준에 고유 ID를 사용합니다. 전체 사전을 LLM에 그대로 넣으면 쿼리당 140,000 토큰(25~40루블)이 들고, 환각 현상이나 파산 위험이 따릅니다.
데이터 기반 AI 파이프라인 아키텍처
기존 데이터베이스의 job_filters, job_filter_options, job_service_filters, city_master, city_source_map 테이블을 활용합니다. 이 테이블들은 표준 값(예: 모스크바 → 헤드헌터=1, 슈퍼잡=4)을 플랫폼별 ID로 매핑합니다.
is_ai_eligible = true로 표시된 필터를 자동 분류합니다:
- 작은 사전 (≤30개 옵션): 경력(
noExperience,between1And3), 고용 형태(FULL,PART). 프롬프트에 포함(~400 토큰). - 큰 사전 (>30개): 도시, 직무. LLM이 텍스트("모스크바") 출력, 코드가 DB에서 ID 해결.
- 자유 텍스트: "파이썬 백엔드 개발자" 같은 쿼리.
- 숫자: 이력서나 LLM에서 추출한 급여.
프롬프트는 DB에서 동적으로 생성됩니다. 예시:
== 다중 선택 필터 ==
경력: noExperience="경력 없음", between1And3="1-3년"
고용형태: FULL="풀타임"
== 사전 필드 ==
도시명: "모스크바"
== 텍스트 필드 ==
텍스트: 2-8단어
입력: 이력서 요약(스킬, 경력), 희망 직무, 대상 사이트. 출력—ID 없는 JSON:
{
"text": "Python backend developer",
"area_name": "Moscow",
"experience": "between1And3",
"salary": {"from": 250000}
}
처리 단계와 해결
1단계: 프롬프트 생성 및 LLM 호출
BuildSearchFiltersPromptTask가 지시어를 조립합니다. LLM(GigaChat)이 사용자 의도를 파악해 작은 사전에서 선택하고, 큰 사전은 명명합니다.
2단계: 코드 후처리
- 해결:
SearchCitiesAction이 "모스크바"를city_master에서 조회하고city_source_map으로 ID 매핑. - 적응:
between1And3을 플랫폼 API 형식으로 변환. - 조립:
unified_filters+filter_labels로 프론트엔드에 전달.
결과: 모든 사이트의 사전 채워진 필터. 사용자가 검토 후 저장합니다.
확장성: 새 사이트/필터 추가 시 DB 데이터만 넣으면 프롬프트와 파이프라인이 자동 적응.
성능 지표
| 접근법 | 토큰 | 쿼리당 비용 | 정확도 |
|--------|------|-------------|--------|
| 단순(전체 사전) | 140,000 | 25–40 RUB | 낮음(환각) |
| 데이터 기반 | 850 + 150 | 0.1 RUB | 높음(DB 해결) |
절감 효과: 150배. 검색 이탈률 하락, 유료 기능 사용자당 평균 수익 증가.
주요 교훈
- 역할 분리: LLM은 의미 처리, DB는 ID 매핑—토큰과 오류 대폭 감소.
- 자동 분류: 30개 기준 동적; 새 필터 코드 없이 통합.
- JSON 출력: 엄격한 LLM 형식으로 파싱 간소화.
- 확장성: 수천 사용자 처리 시 비용 급증 없음.
- UX: 자동 채우기로 진입 장벽 낮춤.
— Editorial Team
아직 댓글이 없습니다.