실제 업무를 반영한 LLM 평가 데이터 세트 구축

최근 연구에서는 데이터 세트 구조를 디자인 선택으로 만들었습니다.

2026년 6월 사전 인쇄본인 HieraRAG는 RAG 벤치마크에서 종합 질문의 세분성을 조사합니다. 특정 검색 구성 내에서 평가할 항목으로 세분성을 구성합니다. 이는 더 많은 질문이 자동으로 더 나은 벤치마크를 생성한다고 가정하는 대신 데이터 세트가 어떤 차이점을 노출하는지 묻는 것을 지원합니다.

증거: RAG 벤치마크는 얼마나 세분화되어야 합니까? 종합 질문 생성을 위한 계층적 프레임워크 [1]

평가 데이터와 훈련 데이터는 서로 다른 결정을 내립니다.

훈련 예제는 모델의 동작을 변경하는 데 도움이 됩니다. 평가 데이터 세트는 참조 증거 또는 채점 기준에 대해 정의된 행동을 테스트합니다. Rubrex는 프롬프트나 모델을 조정하는 데 사용되는 사례를 보류된 결정 세트와 별도로 보관할 것을 권장합니다. 팀이 실패한 테스트를 연구하고 이를 통과하도록 시스템을 변경하는 경우 해당 사례를 회귀 검사로 유지하되 새로 유지된 사례를 사용하여 변경 사항이 일반화되는지 평가합니다.

합성 예제는 비정상적인 입력, 누락된 증거 또는 권한 경계를 다루는 데 도움이 될 수 있습니다. 수락하기 전에 원본 자료와 비교하여 각 질문과 예상 결과를 확인하세요. 예제가 어떻게 만들어졌는지, 그리고 어떤 실패를 나타내는지 기록하세요. 대규모 훈련 자료 또는 자동으로 생성된 질문-답변 쌍 모음은 그 자체로는 검증된 평가 세트가 아닙니다.

사례를 수집하기 전에 기록을 정의하십시오.

Rubrex는 변경할 수 없는 식별자, 입력, 허용된 컨텍스트, 예상되는 동작, 소스 카테고리, 수집 날짜 및 검토자 상태가 포함된 사례 기록을 권장합니다. 도구를 사용하는 워크플로의 경우 초기 상태와 승인된 최종 상태를 포함합니다. 개방형 글쓰기의 경우 정확한 한 문장을 요구하는 대신 고정 루브릭을 사용하세요.

사례가 프로덕션, 지원 에스컬레이션, 도메인 전문가 또는 합성 생성에서 발생했는지 기록합니다. 원시 상호작용을 유지할 수 없는 경우에도 출처에 대한 공개 안전 설명을 보존하세요. 단지 로그 내보내기가 편리하다는 이유만으로 데이터 세트가 민감한 정보를 조용히 획득해서는 안 됩니다.

일부러 커버리지 구축

프롬프트를 작성하기 전에 제품을 의미 있는 조각으로 매핑하세요. 예로는 작업 유형, 문서 기간, 입력 길이, 증거 가용성, 언어 및 사용자 권한이 있습니다. 발생할 수 없는 조합을 생성하는 경우 전체 데카르트 곱을 피하세요. 실제 노출 또는 특정 실패 가설과의 조합에 우선순위를 둡니다.

합성 사례의 경우 강조되는 동작을 지정하고 별도의 검토 단계를 통해 입력이 타당하고 참조가 지원되는지 확인합니다. 모델은 결함이 있는 질문과 일치하는 결함이 있는 답변을 모두 생성할 수 있습니다. 두 아티팩트 간의 합의는 독립적인 검증이 아닙니다.

예시: 버전이 지정된 정책 질문

혜택 도우미는 현재 정책과 보관된 정책에 대한 질문을 받습니다. 현재 질문, 명시적인 과거 질문, 날짜가 없는 질문에 대해 고유한 사례를 만듭니다. 예상되는 동작은 다릅니다. 현재 규칙을 사용하거나, 과거에 대해 답변하거나, 해당 날짜를 명확히 합니다. 하나의 쉬운 예에서 단순히 이름을 변경하면 이러한 구별을 놓칠 수 있습니다.

실제 정책 업데이트가 모델 회귀로 나타나지 않도록 이러한 사례를 정책 버전에 연결하세요. 데이터세트에서 어려운 사례를 삭제하는 대신 설명과 함께 검토를 통해 유효하지 않은 기대치를 폐기합니다.

데이터 세트를 유지 관리되는 제품 아티팩트로 취급합니다.

의사결정 세트에서 개발 세트를 분리하고 각각에 대한 액세스를 기록합니다. 경량 검토 대기열을 통해 새로운 실패 사례를 추가합니다. 점수를 보고할 때 데이터 세트 버전을 식별하고 중요한 변경 사항을 설명하세요. 한 가지 작업 혼합에 대한 지난 달 결과를 이번 달 다른 작업 결과와 비교하면 트래픽 변화와 모델 개선을 혼동할 수 있습니다.

일반적인 질문