[37일차] NC AI 개발자 과정

About this offer

26.10.07 개인프로젝트 6일차 - 정답지 재검토 및 재채점 평가셋 정답지 재검토 및 재채점 앞선 실험에서는 RAG의 검색과 답변 생성을 개선하면서 여러 단계의 성능을 측정했다. 그런데 실험 결과를 다시 살펴보면서 한 가지 의문이 생겼다. 정말 모델이 틀린 것인지, 아니면 내가 만든 정답지와 채점 기준이 잘못된 것인지 구분할 필요가 있었다. 특히 일부 문항에서는 챗봇이 질문에 필요한 내용을 어느 정도 답했는데도, 정답지에서 질문에 직접 요구되지 않은 내용을 필수 조건으로 설정해 놓아 부분정답이나 오답으로 처리되는 경우가 있었다. 따라서 이번에는 모델을 추가로 개선하기 전에 평가셋 자체를 다시 검토 했다. 1. 정답지 검토 기준 문제가 있는 문항을 다음 세 가지로 나누어 검토했다. 1 정답지가 잘못된 경우 질문과 실제 공고 원문을 기준으로 봤을 때 기존 정답 기준이 질문보다 과하거나, 원문과 맞지 않는 경우이다. → 정답지를 수정한다. 2 정답지에는 문제가 없는 경우 질문이 요구하는 내용과 정답 기준이 적절한데, 챗봇이 필요한 내용을 제대로 답하지 못한 경우이다. → 모델의 검색 또는 답변 생성을 개선한다. 3 애매한 경우 질문의 표현이나 의도에 따라 답변 범위가 달라질 수 있는 경우이다. → 질문과 정답 기준을 다시 검토한다. 여기서 가장 중요한 원칙은 챗봇의 답변을 보고 정답지를 수정하지 않는 것 이다. 정답지는 질문과 실제 공고 원문을 기준으로 판단하고, 챗봇의 답변은 그 이후에 평가한다. 2. 문제가 발견된 문항 검토 과정에서 주요하게 확인한 문항은 A03, A04, A05, A09, A14, A16 이었다. A03. 쿤텍 신입은 무슨 언어 할 줄 알아? 기존 정답 기준에는 시스템 프로그래밍 이 포함되어 있었다. 하지만 질문은 "무슨 언어를 할 줄 알아야 하는가" 를 묻고 있었다. 따라서 질문에서 직접 요구하지 않은 시스템 프로그래밍 까지 반드시 언급해야 정답으로 인정하는 것은 질문의 범위를 넘어선다고 판단했다. 판단: 1 정답지 수정 수정 후에는 질문에서 요구하는 언어 관련 정보가 정확하게 답변되었는지 를 중심으로 평가한다. A04. 아인잡 프론트엔드 연봉 기존 평가에서는 연봉 질문에 스톡옵션 정보 를 필수 옵션으로 추가했었다. 하지만 연봉과 스톡옵션은 서로 다른 보상 항목이고, 질문에서 직접 요구한 것은 연봉이었다. 따라서 연봉 질문에 스톡옵션까지 필수적으로 요구하는 기존 기준은 적절하지 않다고 판단했다. 판단: 1 정답지 수정 기존: 연봉 + 스톡옵션을 함께 언급해야 함 수정: 연봉 정보를 정확하게 안내했는지를 평가 스톡옵션은 별도의 보상 정보로 분리한다. A05. Spring만 해 봤는데 지원해도 돼? 기존 기준에서는 Spring 경험을 바탕으로 Java/Kotlin까지 연결해서 판단하도록 요구하고 있었다. 하지만 질문 자체는 "Spring만 해 봤는데 지원해도 돼?" 라는 질문이다. 따라서 Java/Kotlin까지 반드시 언급해야 하는지는 질문의 해석에 따라 달라질 수 있었다. 판단: 3 애매한 경우 질문 자체가 어느 범위까지 답변을 요구하는지 먼저 검토할 필요가 있다고 판단했다. A09. 들어가면 무슨 일 해? 기존 정답 기준에는 EMR·CRM 백엔드 API 설계 및 비즈니스 로직 구현 이라는 표현이 사용되어 있었다. 이 때문에 답변에서 CRM이 따로 언급되지 않으면 일부 내용이 빠졌다고 판단했다. 하지만 챗봇의 답이 정답 내용이 맞는데 정답 기준에서 특정 표현을 묶어서 필수적으로 요구했기 때문에 틀리다고 나온 것을 확인할 수 있었다. 판단: 1 정답지 수정 수정 후에는 질문의 의도에 맞춰 공고에 실제로 명시된 주요 업무를 정확하게 설명했는지 를 중심으로 평가한다. A14. 재택·유연근무 되는 곳 있어? A14는 정답지보다는 채점 과정에서 문제가 발생한 경우 였다. 챗봇은 재택·유연근무가 가능한 6곳을 찾아냈지만, LLM 채점 과정에서 특정 공고를 경력 공고라고 잘못 판단하면서 오답으로 처리된 문제가 있었다. 즉, 답변이 틀린 것이 아니라 채점 과정에서 잘못 판단한 경우 였다. 판단: 1 정답지/채점 기준 수정 실제 공고 원문을 기준으로 판단하고, 채점자가 근거 없이 공고의 경력 여부를 추측하지 않도록 채점 기준을 수정했다. A16. 신입 백엔드 공고에서 공통으로 요구하는 게 뭐야? A16은 가장 복잡한 문항이었다. 모델은 여러 공고를 검색했지만 일부 공고만 중심적으로 비교하는 문제가 있었다. 반면 기존 정답지는 특정 공고들을 묶어 공통 요구사항을 분석하고, 다른 공고들은 성격이 다르기 때문에 제외하는 과정을 요구하고 있었다. 따라서 다음 두 가지를 나누어 볼 필요가 있었다. 정말 모델이 여러 공고를 제대로 종합하지 못한 것인가? 아니면 정답지가 질문보다 지나치게 복잡한 분석을 요구하고 있는가? 판단: 3 애매한 경우 질문과 원문을 기준으로 정답지가 요구하는 범위가 적절한지 먼저 검토하기로 했다. 3. 정답지 수정 후 기존 실험 전체 재채점 정답지가 수정되었다면 최근 실험만 다시 채점해서는 안 된다. 예를 들어 A04의 정답 기준이 변경되었다면, 기준선 ↓ 공고 전체 투입 ↓ 기술 동의어 ↓ 조건 코드 필터 ↓ 분류-본문 차이 ↓ 지시문 개선 ↓ 공고별 균등 검색 ↓ 최종 설정 각 실험 결과를 새로운 정답지 기준으로 다시 채점해야 한다. 그래야 정답지 변경으로 인한 점수 변화와 실제 모델 개선으로 인한 점수 변화를 구분할 수 있다. 4. 답변 정확도 v2 → v4 기존 채점 기준을 v2, 수정된 채점 기준을 v4로 두고 기존 실험 결과를 다시 채점했다. 실행 v2 v4 변화 0 기준선 (A) 64.0% 70.0% +6%p 0 기준선 (B) 66.0% 72.0% +6%p 1 공고 전체 투입 70.0% 78.0% +8%p 2 기술 동의어 76.0% 76.0% 0%p 3 조건 코드 필터 82.0% 86.0% +4%p 4-v1 분류-본문 82.0% 88.0% +6%p 4-v2 82.0% 88.0% +6%p 5-a 지시문 v2 88.0% 92.0% +4%p 5-b 80.0% 92.0% +12%p 6-a 공고별 균등 검색 84.0% 96.0% +12%p 6-b 86.0% 90.0% +4%p top_k=10 순수 검색 a 78.0% 82.0% +4%p top_k=10 순수 검색 b 68.0% 76.0% +8%p top_k=10 최종 a 82.0% 90.0% +8%p top_k=10 최종 b 86.0% 96.0% +10%p 이번 결과에서 가장 중요한 점은 위의 변화가 코드 수정으로 인한 성능 향상이 아니라는 것이다. 동일한 기존 실험 결과를 대상으로 수정된 정답지 기준으로 다시 채점했기 때문에 발생한 변화이다. 따라서 예를 들어 최종 설정이 86%에서 96%가 되었다고 해서 "모델 성능이 10%p 향상되었다." 라고 해석하면 안 된다. 이번 변화는 평가 기준을 바로잡은 결과이다. 5. 최종 설정의 재채점 결과 최종 설정의 경우 다음과 같이 변경되었다. 실행 기존 v2 수정 v4 6-a 공고별 균등 검색 84% 96% 6-b 86% 90% 동일 설정을 2회 실행한 결과의 평균을 비교하면, 기존 v2 평균: 85% 수정된 v4 평균: 93% 이다. 즉, 평가 기준을 수정한 뒤 동일한 결과를 다시 채점했을 때 평균 점수가 8%p 높아졌다. 하지만 이 8%p를 모델의 성능 향상으로 해석하지는 않았다. 이는 정답지 및 채점 기준의 수정으로 인한 평가 결과 변화이기 때문이다. 6. 문서에 없음 정확도 문서에 없음 유형에서도 일부 결과가 달라졌다. 실행 v2 v4 5-a 지시문 v2 80% 100% 6-a 공고별 균등 검색 80% 100% top_k=10 순수 검색 b 100% 80% 나머지 실행은 모두 100% → 100% 로 동일했다. 이번 변화 역시 모델의 성능 변화가 아니라 N01·N02 의 재채점 결과가 달라진 것으로 확인했다. 따라서 이 지표도 정답지 수정에 따른 변화와 실제 모델 개선을 구분해서 해석했다. 7. 정답지 수정과 관계없는 지표 이번 정답지 수정으로 다음 지표에는 변화가 없었다. 최신성 출처 정확도 근거 표시 정확도 검색 적중률 즉, 이번 작업은 검색 시스템 자체를 개선한 실험이 아니었다. 기존 실험 결과를 새로운 정답 기준으로 다시 평가하여 평가셋의 신뢰도를 높이는 과정이었다. 8. 이번 작업에서 알게 된 점 이번 검토를 통해 모든 오답을 단순히 "RAG가 검색을 못했다." 라고 판단하면 안 된다는 것을 확인했다. 평가 결과가 낮은 이유는 크게 다음과 같이 나눌 수 있었다. 평가 결과가 낮음 │ ├── 검색 문제 │ ├── 답변 생성 문제 │ ├── 정답지/채점 기준 문제 │ └── 질문 자체가 애매한 문제 특히 A03, A04, A09처럼 질문보다 정답 기준이 과했던 경우에는 모델을 개선하는 것만으로는 평가의 문제를 해결할 수 없다. 반대로 정답 기준이 적절한 문항에서 답변이 부족하다면 그때는 모델의 검색이나 답변 생성 방식을 개선해야 한다. 9. 이후 평가 기준은 고정 이번 검토를 통해 수정된 정답지를 확정하고, 이후 실험에서는 새로운 정답 기준을 고정해서 사용하기로 했다. 앞으로 성능을 높이기 위해 결과에 맞춰 정답지를 다시 변경하지 않고, 동일한 기준으로 평가한다. 최종 측정은 다음 순서로 진행한다. 평가셋 정답지 검토 ↓ 정답지 수정 ↓ 기존 실험 전체 재채점 ↓ 수정된 결과 확정 ↓ 평가 기준 고정 ↓ 코드 동결 ↓ 새로운 홀드아웃 문항 준비 ↓ 최종 측정 특히 최종 홀드아웃에서는 고치는 동안 한 번도 보지 않은 새로운 문항을 사용하고, 결과가 마음에 들지 않는다고 다시 고치거나 문항을 바꾸지 않고 그대로 실패 사례로 기록할 예정이다. 마무리 이번 작업의 목적은 단순히 정확도 숫자를 높이는 것이 아니었다. 오히려 기존 평가 결과를 다시 살펴보면서, 모델이 틀린 것인지, 정답지가 틀린 것인지, 아니면 질문 자체가 애매한 것인지를 구분하는 것이 목적이었다. 실제로 정답지를 다시 검토한 결과, 일부 문항에서는 질문에서 직접 요구하지 않은 내용을 정답 조건으로 포함하고 있거나 채점 과정에서 잘못 판단하는 문제가 있었다. 따라서 해당 문항을 수정하고 기존 실험 전체를 새로운 기준으로 다시 채점했다. 그 결과 최종 설정의 평균 점수도 기존 85%에서 93% 로 변경되었다. 하지만 이 변화는 모델을 개선해서 얻은 성능 향상이 아니라 평가 기준을 수정한 뒤 동일한 결과를 다시 채점하면서 발생한 변화이다. 이번 과정을 통해 RAG 프로젝트에서는 검색과 생성 모델을 개선하는 것뿐만 아니라, 무엇을 정답으로 볼 것인지에 대한 평가 기준을 제대로 설계하는 것도 중요하다는 것을 확인했다. 이제 수정된 정답지를 고정하고, 이후에는 평가 기준을 변경하지 않은 상태에서 코드 동결 → 홀드아웃 측정 → 최종 성능 평가를 진행할 예정이다.