성능 평가와 품질 관리

품질은 느낌이 아니라 기준이다

Qwen을 서비스에 붙인 뒤 가장 위험한 판단은 "답변이 꽤 괜찮아 보인다"는 감각에 의존하는 것이다. LLM 서비스의 품질은 매번 달라질 수 있다. 프롬프트를 조금 바꾸거나, 모델을 교체하거나, RAG 문서가 갱신되면 같은 질문에도 다른 답이 나온다. 그래서 운영 단계에서는 반복해서 측정할 수 있는 기준이 필요하다.

먼저 평가 지표를 정한다. 정확성은 사실이 맞는지 보는 기준이다. 근거성은 답변이 제공된 문서나 검색 결과에 기반하는지 확인한다. 유용성은 사용자가 바로 행동할 수 있을 만큼 도움이 되는지 본다. 일관성은 같은 조건에서 비슷한 품질을 유지하는지 평가한다. 안전성은 개인정보, 금칙어, 위험한 조언을 피하는지 확인한다. 여기에 업무별 기준을 더할 수 있다. 예를 들어 고객센터 챗봇이라면 친절함, 정책 준수, 상담 이관 판단이 중요하다.

대표 질문 세트와 골든 답변 만들기

평가는 실제 사용자가 물을 만한 질문에서 시작해야 한다. 자주 묻는 질문, 실패했던 대화, 중요한 업무 시나리오를 모아 대표 질문 세트를 만든다. 질문은 쉬운 것만 넣지 않는다. 모호한 질문, 문서에 답이 없는 질문, 여러 조건을 동시에 따져야 하는 질문도 포함한다.

각 질문에는 기준 답변, 즉 골든 답변을 붙인다. 골든 답변은 모델이 반드시 똑같이 따라야 하는 문장이 아니라, 포함해야 할 핵심 사실과 금지해야 할 내용을 정리한 평가 기준이다. 예를 들어 "환불 가능 여부를 묻는 질문"이라면 필수 포함 항목은 환불 조건, 기간, 예외 규정이고, 금지 항목은 없는 정책을 지어내는 것이다.

이 세트를 이용해 회귀 테스트를 수행한다. 회귀 테스트란 변경 전에는 잘 되던 기능이 변경 후에도 유지되는지 확인하는 절차다. 프롬프트를 수정하거나 Qwen 모델을 바꾸거나 RAG 문서를 업데이트할 때마다 같은 질문 세트를 다시 실행한다. 점수가 떨어진 항목은 출시 전에 원인을 찾아야 한다.

모델과 프롬프트를 같은 조건에서 비교하기

Qwen 모델군 안에서도 크기와 특성이 다르면 결과가 달라진다. 더 큰 모델이 항상 정답은 아니다. 어떤 업무에서는 작은 모델이 충분히 빠르고 저렴할 수 있고, 복잡한 추론이나 긴 문서 분석에서는 큰 모델이 더 안정적일 수 있다.

비교할 때는 조건을 맞춰야 한다. 같은 질문, 같은 시스템 프롬프트, 같은 RAG 문서, 같은 출력 형식을 사용한다. 그런 다음 정확성, 응답 속도, 비용, 형식 준수율을 함께 본다. 품질만 보고 모델을 고르면 운영비가 커질 수 있고, 속도만 보면 사용자 신뢰가 떨어질 수 있다. 서비스에 맞는 균형점을 찾는 것이 목표다.

평가 결과는 표로 관리하는 것이 좋다. 질문 ID, 모델명, 프롬프트 버전, 점수, 실패 유형, 코멘트를 남기면 나중에 개선 방향이 보인다. 특히 "어떤 모델이 좋다"보다 "어떤 유형의 질문에서 어떤 모델이 강하다"를 파악하는 것이 더 중요하다.

자동 점검으로 실패 유형을 줄이기

모든 답변을 사람이 직접 확인할 수는 없다. 그래서 자동 평가 프롬프트를 함께 사용한다. 평가용 프롬프트는 Qwen의 답변을 다시 입력으로 받아 문제를 찾는다. 주요 점검 항목은 환각, 누락, 형식 오류, 금칙어 위반이다.

예를 들어 평가 프롬프트는 이렇게 구성할 수 있다. "아래 답변이 제공된 근거 문서에 없는 내용을 주장했는지 확인하라. 필수 항목 중 빠진 것이 있는지 확인하라. 출력 형식이 JSON 스키마를 따르는지 확인하라. 개인정보나 금칙어가 포함되었는지 확인하라. 결과는 통과/실패와 이유로만 작성하라."

자동 평가는 완벽하지 않다. 하지만 반복되는 문제를 빠르게 찾는 데 효과적이다. 특히 형식 오류, 근거 없는 문장, 답변 누락처럼 규칙화할 수 있는 문제는 자동 점검에 잘 맞는다. 중요한 서비스라면 자동 평가와 사람 검수를 함께 사용해야 한다.

사용자 피드백을 개선 루프로 연결하기

출시 후 품질 관리는 사용자 피드백에서 완성된다. 사용자가 답변에 만족했는지, 다시 질문했는지, 상담원에게 이관했는지, 신고 버튼을 눌렀는지를 기록한다. 단순한 별점보다 "왜 도움이 되지 않았는지"를 선택하게 하면 개선에 더 유용하다.

피드백은 세 갈래로 반영한다. 첫째, 질문 의도는 맞지만 답변 방식이 나쁘면 프롬프트를 고친다. 둘째, 문서에 정보가 없어서 틀렸다면 RAG 지식베이스를 보강한다. 셋째, 복잡한 추론을 계속 실패한다면 더 적합한 Qwen 모델로 바꾸거나 파인튜닝을 검토한다.

품질 관리는 한 번의 평가표로 끝나지 않는다. 질문 세트를 갱신하고, 실패 유형을 분류하고, 변경 사항을 다시 테스트하는 순환 과정이다. 이 루프가 자리 잡으면 Qwen 서비스는 운에 기대는 데모가 아니라 안정적으로 개선되는 제품이 된다.