기업용 LLM 평가셋 만들기: 실패 사례부터 배포 승인까지

기업용 LLM 기능을 바꿀 때 답변 몇 개가 좋아 보인다는 이유만으로 배포하면 이전에 잘 처리하던 업무가 나빠질 수 있습니다. 문장 표현의 개선과 업무 정확도, 권한 준수와 실행 안전성은 서로 다른 평가 대상입니다. 실제 사용 범위와 실패 영향을 기준으로 평가 자료와 승인 절차를 연결해야 합니다.

이 글은 사내 문서 요약과 업무 정보 추출 기능을 운영하는 가상의 상황을 따라갑니다. 특정 모델의 성능을 비교하는 순위표보다 팀이 어떤 사례를 평가하고 무엇을 배포 기준으로 삼을지 정하는 방법을 설명합니다. 모델과 프롬프트, 검색 설정이 달라져도 같은 근거로 결과를 검토하는 것이 목적입니다.

1. 업무 성공을 답변의 모양과 구분한다

먼저 사용자가 결과를 어디에 쓰는지 적습니다. 사람이 읽을 회의 요약과 프로그램이 처리할 주문 정보는 필요한 조건이 다릅니다. 자연스러운 문장, 원문과의 일치, 필요한 항목의 완전성과 정해진 출력 형식을 따로 평가해야 어느 부분이 좋아졌는지 알 수 있습니다.

실패 영향도 분류합니다. 요약의 표현이 어색한 경우와 금액이나 납기를 잘못 추출한 경우를 같은 오류 하나로 세지 않습니다. 자동으로 다음 업무를 실행하는 기능이라면 잘못된 값이 어디까지 전달되는지 확인하고 그 영향에 맞춰 배포 검토 강도를 정합니다.

평가 범위에는 답변 보류와 추가 질문도 포함합니다. 근거가 없거나 입력이 모호한 상황에서 억지로 답하는 것이 성공은 아닙니다. 사용자가 필요한 정보를 더 주도록 안내하거나 담당자에게 넘기는 조건을 먼저 합의해야 정상적인 보류와 기능 실패를 구분할 수 있습니다.

2. 실제 업무에서 평가 사례를 모은다

자주 쓰는 정상 입력만 모으지 말고 운영 문의와 정정 이력, 담당자의 수동 처리 사례를 살펴봅니다. 문서 종류와 길이, 표현 방식과 사용자 역할을 나눠 봅니다. 자료가 많이 모인 유형의 점수가 전체 평균을 좌우하지 않도록 평가 구성을 표시합니다.

평가 자료에는 입력과 기대 결과, 판단 근거를 연결합니다. 정답 문장 하나를 그대로 따라야 하는지 핵심 사실이 맞으면 되는지 구분합니다. 문서에서 특정 값을 찾는 작업이라면 기대 값뿐 아니라 해당 원문 위치와 미확인으로 남겨야 하는 조건도 기록합니다.

실제 고객 자료를 사용할 때는 평가 목적의 접근과 보관 범위를 확인합니다. 비밀 정보와 개인정보를 필요 이상 복제하지 않으며 공유할 예시는 적절히 가공합니다. 평가 자료가 어디에서 왔고 어떤 변경을 했는지 남기면 이후 결과 해석과 정정이 쉬워집니다.

3. 실패 유형을 겹치지 않게 정리한다

원문에 없는 주장, 중요한 항목 누락, 잘못된 근거 연결과 형식 오류를 구분합니다. 하나의 답변에 여러 문제가 있으면 복수로 기록할 수 있게 하되 집계의 의미를 설명합니다. 오류 건수와 실패한 질문 수를 같은 지표처럼 비교하지 않도록 기준을 정합니다.

검색이 포함된 기능은 검색 단계와 생성 단계를 나눕니다. 필요한 문서가 전달되지 않은 경우와 전달된 문서를 잘못 해석한 경우는 개선 방법이 다릅니다. 도구를 사용하는 기능에서는 잘못된 호출과 올바른 호출 뒤 결과 설명 오류도 따로 확인합니다.

분류가 어려운 사례는 임의의 정상 판정으로 닫지 않습니다. 추가 원문이나 업무 해석이 필요한지 표시하고 확인 담당자를 지정합니다. 같은 유형에서 의견 차이가 반복되면 모델을 바꾸기 전에 업무 정의와 평가 기준이 모호하지 않은지 먼저 검토합니다.

4. 자동 검사와 사람 검토를 조합한다

자료형과 필수 필드, 허용 코드와 계산 가능한 값은 자동 검사로 확인할 수 있습니다. 문장 의미와 근거의 충분성, 예외 조건 반영은 별도 검토가 필요할 수 있습니다. 어떤 검사로 무엇을 보장하는지 적어 자동 점수가 모든 품질을 대표하지 않게 합니다.

사람 검토에는 판단 기준과 예시를 제공합니다. 검토자가 후보 모델 이름을 보고 선호를 반영하지 않도록 결과 제시 방법도 검토합니다. 의견이 다르면 근거를 대조해 합의하고 변경한 기준은 이전 결과에 어떤 영향을 주는지 확인해야 비교가 유지됩니다.

다른 모델이 답변을 채점하는 방식도 참고 도구로 사용할 수 있습니다. 다만 그 채점이 실제 업무 기준과 맞는지 사람의 표본 검토로 확인합니다. 채점 모델이나 기준 문구가 바뀌면 평가 체계 자체의 변경이므로 기존 점수와 무조건 같은 척도로 비교하지 않습니다.

5. 비교 조건과 버전을 고정한다

모델 이름뿐 아니라 프롬프트와 검색 자료, 도구 정의와 주요 설정을 함께 기록합니다. 같은 질문에 다른 문서 버전이 들어갔다면 결과 차이를 모델 개선으로 단정하기 어렵습니다. 입력 묶음과 설정을 다시 실행할 수 있는 단위로 보관합니다.

LLM 결과가 실행마다 달라질 수 있다는 점도 고려합니다. 중요한 사례는 반복 결과의 흔들림을 확인하고 한 번 잘 나온 답만 선택하지 않습니다. 반복 평가의 범위와 기록 방법은 업무 위험과 비용에 맞춰 정하되 비교 대상에 같은 조건을 적용합니다.

개발 중 자주 확인한 자료와 최종 배포 검토 자료의 관계도 관리합니다. 특정 예시의 표현만 맞추는 수정이 전체 업무 개선처럼 보이지 않게 합니다. 새로운 실패 사례를 추가할 때는 기존 기준 자료를 보존하고 평가 집합의 변경 이유를 남깁니다.

6. 평균 점수 외에 배포 금지 조건을 둔다

전체 평균이 좋아져도 권한 없는 정보 노출이나 잘못된 외부 실행이 새로 생겼다면 별도 판단이 필요합니다. 업무 영향이 큰 실패 유형에 대해 배포를 멈출 조건과 승인 책임자를 정합니다. 높은 점수 하나로 중요한 실패를 상쇄하는 방식은 피합니다.

평가 표에는 개선과 회귀를 함께 보여줍니다. 어떤 문서 유형이 좋아졌고 어떤 사용자나 입력 조건에서 나빠졌는지 드러나야 합니다. 표본이 적어 결론을 내리기 어려운 구간은 불확실성을 표시하고 추가 검토나 제한 운영을 선택할 수 있게 합니다.

비용과 응답 시간도 같은 업무 조건에서 봅니다. 품질이 좋아져도 사용자가 기다릴 수 없거나 검토 대기량이 늘면 실제 적용이 어려울 수 있습니다. 정답성, 운영 부담과 사용자 경험을 구분해 보여주고 최종 승인에서 어떤 조건을 수용했는지 기록합니다.

7. 제한 배포와 복귀 절차를 준비한다

배포 전 평가가 모든 운영 입력을 대표하지는 않습니다. 처음에는 대상 업무와 사용자 범위를 제한하고 담당자가 결과를 확인합니다. 새 버전에 해당하는 작업을 식별할 수 있게 해 운영 오류가 어느 설정에서 발생했는지 조사할 수 있도록 합니다.

문제가 생기면 이전 설정으로 돌아갈 수 있어야 합니다. 모델과 프롬프트뿐 아니라 검색 색인과 도구 규칙의 호환성도 확인합니다. 이전 버전 복귀가 이미 실행된 업무를 취소하는 것은 아니므로 영향받은 결과의 확인과 정정 절차를 따로 둡니다.

관찰할 신호에는 오류 신고와 보류, 사람 수정과 업무 반영 실패를 포함합니다. 요청 수나 응답 속도가 정상이어도 잘못된 결과가 조용히 쌓일 수 있습니다. 담당자가 실제 입력과 결과를 검토할 표본과 연락 경로를 정해 출시 이후의 확인을 이어갑니다.

8. 운영 실패를 다음 평가에 반영한다

운영에서 발견한 문제는 입력과 설정, 기대 행동과 실제 결과를 연결해 평가 사례로 만듭니다. 재현할 수 없는 정보가 있다면 그 한계를 표시합니다. 원인을 모델, 검색, 도구와 업무 절차로 나눠 같은 문제가 다시 발생하는지 확인할 기준을 마련합니다.

수정 후에는 새 사례와 기존 회귀 자료를 함께 실행합니다. 하나의 실패를 고치면서 정상 입력이 나빠지지 않았는지 검토합니다. 정답이나 기준 자체가 바뀌었다면 변경 이력을 남겨 점수 상승이 평가 기준 완화 때문인지 실제 개선 때문인지 설명할 수 있게 합니다.

평가 운영의 책임자는 자료 정리와 기준 승인, 배포 판단을 연결합니다. 평가셋을 한 번 만드는 것으로 끝내지 말고 실제 업무 변화에 맞춰 갱신합니다. 좋은 평가 체계는 모델을 선발하는 시험보다 새로운 변경을 같은 언어로 검토하고 실패를 복구하는 운영 기반에 가깝습니다.

9. 요약 개선이 정보 추출을 망가뜨린 사례를 가정한다

새 프롬프트가 회의 요약의 읽기 흐름을 개선했지만 주문 정보 추출에서는 원문에 없는 기본 납기를 채우는 상황을 가정합니다. 검토자는 전체 평균이 좋아졌다는 설명만 받지 않고 업무 유형별 결과를 확인합니다. 요약 품질과 필수 필드 검증, 미확인 처리의 결과를 나눠 배포 승인에 어떤 조건이 충족되지 않았는지 표시합니다.

문제가 된 문서에는 납기가 없다는 사실과 기대 결과가 미확인이라는 근거를 남깁니다. 모델이 반환한 날짜가 형식상 올바르더라도 업무 기준을 위반했다는 점을 기록합니다. 검색 자료나 후속 도구가 기본값을 넣은 것은 아닌지 실행 흐름을 확인하고, 원인이 확인되기 전에는 프롬프트만 탓하며 임의의 수정부터 하지 않습니다.

후보 설정을 수정한 뒤에는 해당 사례뿐 아니라 명시된 납기와 여러 날짜가 함께 있는 문서도 시험합니다. 날짜 추출을 모두 보류하게 만들어 오류만 없애는 방식으로 품질이 좋아졌다고 판단하지 않습니다. 올바른 추출과 올바른 보류, 불필요한 보류가 각각 얼마나 발생했는지 같은 정의로 비교합니다.

제한 배포에서는 결과를 업무에 자동 반영할지 담당자가 먼저 검토할지 범위를 정합니다. 새 설정으로 처리한 문서와 사람의 수정 결과를 연결하고, 문제 발생 시 이전 설정으로 돌아갈 담당자를 지정합니다. 이미 확정한 거래에 잘못된 납기가 들어갔다면 설정 복귀 외에 별도 정정이 필요하다는 점도 확인합니다.

연습을 마칠 때에는 개선된 기능과 아직 제한할 기능을 구분해 승인 기록에 남깁니다. 담당자가 다른 평가 결과를 보더라도 같은 실패 유형에 같은 판단을 내릴 수 있어야 합니다. 실제로 발견한 문제를 회귀 사례로 보관하고 다음 모델과 프롬프트 변경에서도 같은 검사를 반복할 수 있도록 입력과 설정 버전을 함께 관리합니다.

적용 전 체크리스트

• 업무 성공과 중요한 실패의 기준을 분리했는가
• 입력·기대 결과·근거와 설정 버전을 연결하는가
• 검색·생성·도구 실패를 구분해 평가하는가
• 평균 개선과 회귀·배포 금지 조건을 함께 보는가
• 제한 배포와 복귀·업무 정정까지 확인하는가

참고 자료와 적용 범위

• NIST AI RMF Playbook — Measure

위험과 사용 맥락에 맞는 평가의 배경은 NIST 자료를 참고했습니다. 평가셋 구성, 회귀 사례와 배포 흐름은 실무 설계 제안입니다.

대표 이미지는 AI로 제작한 개념 시각화이며, 본문 도식과 함께 이해를 돕기 위한 자료입니다. 실제 고객의 설비·데이터·서비스 화면을 나타내지 않습니다.

#LLM평가 #평가셋 #회귀검증 #배포승인 #AI품질 #기업AI #사람검토 #AI운영 #모델검증 #네이처프랙탈