[질문]1. 공고 채용 관련된법이 그렇게 많지않은걸로 알고있는데 굳이 RAG기술까지 도입한 이유가 무엇인가요2. 청킹전략이 어떻게 되는지 설명해주시고 정확도는 어떤근거로 산출 하였나요3. 굳이 임베딩까지한 이유가 무엇인가요[답변]1. 공고 채용 관련 법이 그렇게 많지 않은데, 굳이 RAG까지 도입한 이유가 무엇인가요 핵심은 문서 수가 아니라 답변 신뢰성 때문입니다. 실제로 현재 source_data 기준으로도 PDF가 12개 정도라 절대량은 크지 않습니다. 그런데 이 자료들은 성격이 다릅니다. 법률 본문, 시행령, 시행규칙, 업무 매뉴얼, 공정채용 가이드북, 연도별 지도점검 결과가 섞여 있습니다.그래서 단순 프롬프트 주입 방식은 세 가지 문제가 있습니다.
RAG를 쓴 이유는 “문서가 많아서”가 아니라, 질문마다 관련 조항과 사례만 좁혀서 넣고 출처를 남기기 위해서입니다. 특히 이 기능은 법률 자문이 아니라 사전 리스크 점검 도구라서, 생성 능력보다 근거 선택 정확도가 더 중요하다고 판단했습니다.면접에서 더 냉정하게 말하면: 이 정도 문서량이면 기술적으로는 전량 프롬프트 주입도 가능하지만, 포트폴리오와 실서비스 관점에서는 근거 추적성과 개정 대응성을 위해 retrieval 계층을 두는 편이 더 합리적이라고 봤습니다.2. 청킹 전략이 어떻게 되는지 설명해주시고 정확도는 어떤 근거로 산출하였나요 청킹은 일반 문서처럼 고정 토큰 길이로 자르지 않고 법률/가이드 구조 기준으로 나눠야 합니다. 이유는 법률 문서는 조문 단위 의미가 강해서, 중간에서 잘리면 해석이 깨지기 때문입니다.제가 잡을 청킹 전략은 이렇습니다.• 1차 청킹: 문서 종류별 구조 분리 법률/시행령/시행규칙은 조/항/호 단위 가이드북/업무 매뉴얼은 절/소제목 단위 지도점검 결과는 위반 유형/사례/조치 내용 단위• 2차 청킹: 너무 긴 조항이나 절은 의미 보존 범위 내에서 추가 분할• 메타데이터 부착:문서명, 문서유형, 조항번호, 시행일, 페이지, 주제 태그예를 들어 키 180 이상 우대 같은 문장을 볼 때, 단순히 비슷한 텍스트를 찾는 게 아니라 신체조건, 성차별, 직무무관 자격요건, 공정채용, 실제 점검사례 같은 축으로 관련 chunk가 묶여야 합니다.정확도는 “모델이 맞다고 한 비율”로 보면 안 되고, retrieval과 최종 판정으로 나눠서 봐야 합니다.• Retrieval 정확도: 사람이 만든 질의셋 예를 들어 30~50개 JD 문구를 준비하고, 각 문구에 대해 정답 근거 문서/조항을 라벨링한 뒤Recall@k, MRR, Precision@k로 측정• 판정 정확도: 위험/주의/문제없음 같은 클래스 기준으로 법률 근거 라벨과 비교해서 precision, recall, F1 산출• 설명 품질: 출처 포함 여부, 잘못된 벌금 수치 생성 여부, 수정문구 유용성은 정성평가 + 체크리스트면접에서는 이렇게 말하면 된다. 정확도는 한 숫자로 말하지 않고, 검색 정확도와 최종 판정 정확도를 분리해 측정했습니다. 특히 법률 도메인에서는 정답 근거를 제대로 찾았는지가 먼저라서 Recall@k와 근거 일치율을 우선 봤습니다.3. 굳이 임베딩까지 한 이유가 무엇인가요 임베딩을 쓴 이유는 표현이 달라도 같은 위험을 찾기 위해서입니다.예를 들어 사용자가 공고에 이렇게 쓸 수 있습니다.
이 표현들은 법령 문구와 정확히 일치하지 않을 수 있습니다. 키워드 검색만으로는 일부는 잡히지만, 간접차별이나 우회표현은 놓칠 가능성이 큽니다. 임베딩은 이런 의미적 유사성을 잡는 데 필요합니다.다만 여기서 중요한 건, 나는 임베딩만 쓰겠다고 말하면 안 된다. 이 도메인은 법률 표현이 정형적이라 키워드/BM25도 매우 강하다. 그래서 답은 임베딩 단독이 아니라 하이브리드 검색이다.좋은 답변은 이거다.임베딩은 유사 의미 표현 탐지를 위해 넣었고, 법률 조항처럼 정확한 용어 매칭이 중요한 부분은 BM25가 더 강하기 때문에 두 방식을 같이 쓰는 하이브리드 검색으로 설계했습니다.한 줄로 압축하면:
냉정하게 말하면, 면접에서 제일 좋은 답은 “RAG가 멋있어서 넣었다”가 아니라 법률 리스크 기능은 생성보다 근거 검색이 핵심이라 retrieval 계층을 먼저 설계했다