커스텀 평가 데이터셋

시스템이 이미 받은 프롬프트로 커스텀 데이터셋(custom dataset)을 만들면, 과거 성능을 깊이 이해하고 재설계가 실제 프롬프트에서 성능을 어떻게 바꿀지 실험할 수 있다. 이번 편은 그 데이터셋을 만드는 법과 활용을 정리한다.

 

 

1. 무엇을 저장할까

커스텀 데이터셋은 시스템이 이전에 처리한 프롬프트 모음과, 그 프롬프트가 시스템을 통과한 처리 경로 정보다. 초기 프롬프트와 최종 응답만 저장할 수도, 또는 검색된 문서 · re-ranker 전후 순위 · query rewriter의 출력 등 많은 정보를 담을 수도 있다. 유연성이 크므로 핵심 결정은 "무엇을 저장할까 = 무엇을 평가하고 싶은가"다.

그림 1. 커스텀 데이터셋 — 저장할 데이터는 "무엇을 평가하고 싶은가"로 결정된다.

 

입력 프롬프트와 최종 응답은 거의 반드시 저장한다 — 이 둘로 end-to-end 성능을 가늠하고, 프롬프트 수정에 따른 응답 변화를 추적한다. 하지만 이건 end-to-end 평가에만 유용하다. retriever·re-ranker·query rewriter가 얼마나 잘 하는지 component-level 평가를 하려면 각 component의 입출력 데이터도 저장해야 한다. 그래서 RAG 호출 로그 테이블은 customer ID부터 re-ranker가 검토한 chunk, agentic workflow의 각 router LLM 출력까지 수십 개 column을 갖게 되기도 한다.

 

 

2. 다차원 분석 — topic별 성능

이렇게 다양한 데이터를 저장하면 각 component를 개별 분석하고 여러 차원에서 성능을 볼 수 있다. 예로 고객 응대 챗봇이라면 질문 topic으로 필터해, 환불 질문은 좋은 응답을 받지만 배송 지연 질문은 전혀 안 좋다는 것을 발견할 수 있다. 원인을 조사하면 로그에서 retriever가 그 프롬프트에 관련 문서를 못 찾는다는 것이 드러날 수 있고 — knowledge base에 관련 정보를 더 넣어야 한다는 결론에 이른다.

그림 2. 예시 분석 — topic별 응답 품질과 component 지표(context precision·faithfulness·chunks retrieved)를 함께 본다.

 

 

3. 사례 — 잘못 라우팅된 다이어그램

강의에서 든 실제 사례다. 텍스트·이미지와 Mermaid.js 기반 차트·다이어그램을 생성하는 특수 RAG를 운영하던 중, 일부 다이어그램 품질이 낮다는 불만이 들어왔다. 로그를 거슬러 보니, 사용자가 "다이어그램을 그려 줘"라고 하면 router LLM이 이를 잘못 해석해 text-to-image 모델로 보냈던 것 — 이 모델은 사람·사물 이미지는 잘 만들지만 차트는 매우 못 만든다. 원인을 파악한 뒤 router LLM의 시스템 프롬프트를 수정해, 그런 요청은 이미지가 아니라 코드 기반 차트를 만들도록 고쳤다. 견고한 로깅 덕분에 원인 추적과 수정 반영이 간단했다.

그림 3. 사례 — router LLM이 다이어그램 요청을 이미지 모델로 잘못 보냄. 로그로 원인을 찾아 시스템 프롬프트를 수정.

 

 

4. 데이터 시각화 · 프롬프트 군집화

개별 프롬프트를 추적하는 것도 좋지만, 데이터가 많아지면 시각화해 전체·component의 고수준 추세를 보고 싶어진다.

그림 4. 시각화 — 클러스터링으로 프롬프트의 고수준 추세를 파악한다.

 

예를 들어 시스템을 통과한 모든 입력 프롬프트를 시각화하고 클러스터링으로 고객이 묻는 상위 topic(제품 출시, 문제 해결 등)을 식별할 수 있다. 이렇게 프롬프트 유형을 구분하면, 특정 유형에 대해서만 eval 파이프라인을 돌려 그 질문 유형에서 성능이 낮은지 확인할 수 있다.

그림 5. 쿼리 분류 — 프롬프트를 유형(기술/비기술 등)으로 나눠 유형별 성능을 평가한다.

 

다음 글에서는 모델·벡터를 압축해 메모리·비용을 줄이는 양자화(Quantization)를 다룬다.