이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
저는 LLM 성능 평가에서 지표 선택을 사용 목적에 따라 나눠야 한다고 봅니다. 요약이나 번역처럼 정해진 출력이 있는 경우 BLEU·ROUGE 같은 자동 지표가 유용하지만, 오픈엔드 대화나 추론 태스크에서는 자동 지표와 사람 평가 간 상관관계가 낮아 한계가 있습니다. 실제 프로젝트에서 ROUGE-L만으로 평가했더니 유창하지만 핵심이 빠진 요약이 높은 점수를 받는 경우가 있었고, 이후 사람 평가 10%를 섞어 검증하는 방식으로 보완했습니다. 최근에는 강력한 모델을 심판으로 쓰는 LLM-as-a-Judge 방식도 확산되고 있는데, 평가자 모델의 편향을 별도로 검증할 필요가 있다는 점도 인식하고 있습니다.
LLM 관련 수업에서 여러 태스크에 같은 자동 지표를 적용했을 때 태스크마다 지표의 의미가 달라진다는 것을 경험했습니다. 문서 요약 태스크에서는 ROUGE 지표가 어느 정도 방향을 보여줬는데, 질문 답변 태스크에서는 같은 지표가 실제 답변 품질을 반영하지 못하는 경우가 많았습니다. 정해진 답이 있는 태스크와 열린 형식의 답변이 가능한 태스크에서는 평가 방식 자체를 다르게 설계해야 한다는 것을 알게 됐습니다. 열린 형식 태스크에서는 사람이 직접 평가하거나 평가 기준을 더 세밀하게 정의하는 방식이 필요하다는 것을 배웠습니다. LLM 성능 평가에서 지표 하나로 전체 품질을 판단하려 하면 태스크의 특성을 놓치게 되고, 태스크의 목적에 맞는 평가 방식을 선택하는 것이 출발점이라는 것을 이 경험에서 배웠습니다.
LLM을 활용한 프로젝트에서 모델의 응답 품질을 평가할 때 정확도나 유창성 지표만으로는 충분하지 않다는 것을 경험했습니다. 답변이 유창하고 내용이 관련 있어 보이는데 사실이 아닌 정보가 포함된 경우가 있었고, 자동 지표는 이것을 잡아내지 못했습니다. 특히 사용자에게 실제로 전달되는 서비스에서는 잘못된 정보의 영향이 크기 때문에 안전성과 사실 정확도를 별도로 평가하는 것이 필요하다는 것을 알게 됐습니다. 지표를 선택할 때 모델이 얼마나 잘 답하는지와 함께 어떤 상황에서 잘못된 답을 내는지를 함께 평가하는 것이 실제 서비스에서 중요하다는 것을 이 경험에서 배웠습니다. LLM 성능 평가는 좋은 답변을 찾는 것만이 아니라 나쁜 답변이 언제 나오는지를 파악하는 것도 포함해야 완성도가 높아진다는 것을 알게 됐습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 스마일게이트(사업부문) ML 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.