RAG·데이터 추출 실험에서 출력 추적과 평가 워크플로 정리

작성자는 자신의 경험을 적고 다른 팀의 방식을 묻는 형태로 글을 마무리했기 때문에 커뮤니티에서는 유사한 경험과 플랫폼별 실무 팁이 교환될 가능성이 높다. 많은 참가자가 평가셋 고정과 프롬프트 파일화 같은 기본 관행을 공감할 가능성이 크며, 일부는 자동화 스크립트·CI 파이프라인으로 반복 평가를 전환한 사례를 공유할 수 있다. 플랫폼 선택이나 스냅샷 주기 같은 세부 운용 방식에서는 의견이 갈릴 여지가 있어 토론이 활발해질 수 있다.

• 평가를 반복할 때는 노트북이 아니라 스크립트를 사용해 자동화하는 것이 바람직하다. 스크립트는 동일한 평가셋을 입력으로 받아 모델·프롬프트 조합별로 결과를 표준화된 형식으로 출력하고 결과 파일명에 모델, 프롬프트 버전, 날짜, 온도, max tokens 같은 메타데이터를 포함해 저장하므로 수동 비교 비용을 줄인다. 자동화된 로그와 결과 형식을 유지하면 실패 사례 재검토와 집계 통계 산출이 쉬워진다.
• 프롬프트는 개별 파일로 관리하고 형상관리 시스템에 커밋해 변경 이력을 남겨야 한다. 각 프롬프트 파일에는 버전 식별자와 변경 이유를 주석으로 남기고, 실험 레지스트리나 간단한 메타데이터 CSV/JSON에 프롬프트 파일명과 연결하면 어떤 출력이 어떤 프롬프트에서 생성되었는지 명확해진다. 이 방식은 협업 환경에서 충돌을 줄이고 롤백이 가능하게 만든다.
• 실험 산출물과 평가 데이터는 인스턴스 로컬에만 두지 말고 영구 스토리지로 옮겨 보관해야 한다. 게시물 작성자는 Datadrive(Glows AI 예시)를 검토했고 RunPod·Lambda·로컬 GPU 등 어디서든 영구 볼륨을 사용하면 인스턴스 재생성 시에도 데이터 손실을 피할 수 있다고 언급했다. 스토리지 정책은 비용·접근성·보안 요구사항을 고려해 결정하되, 임시 인스턴스 의존을 최소화하는 것이 중요하다.

RAG

— 검색 증강 생성(RAG)은 외부 문서·지식베이스에서 관련 컨텍스트를 검색하여 LLM의 입력으로 결합하고, 모델이 그 컨텍스트를 바탕으로 답변을 생성하는 방식이다. 입력 쿼리에 대해 검색된 문서들이 임베딩·유사도 매칭으로 선택되고 선택된 문서들이 프롬프트에 주입되어 모델 출력의 정확도와 최신성을 개선한다. RAG는 특히 도메인 지식이 분산되어 있고 모델의 토큰 컨텍스트가 한정적일 때 유용하다.

Evaluation set

— 평가 데이터셋은 모델 및 프롬프트 변경을 비교하기 위해 고정해두는 소량의 검증 샘플 세트로, 게시물에서는 약 50~100개를 권장했다. 이 데이터셋은 실험 반복에서 입력을 동일하게 유지하여 출력 차이를 재현 가능하게 만들고 모델·프롬프트 변경의 효과를 수치적으로 비교할 수 있게 한다. 평가 항목과 정답 기준을 문서화하면 비교의 신뢰도가 높아진다.

Prompt versioning

— 프롬프트 버전 관리는 각 실험에서 사용한 프롬프트를 파일 단위로 분리해 변경 이력을 명확히 남기는 관행으로, 동일한 프롬프트를 반복 편집하는 대신 별도 파일로 관리하여 어떤 출력이 어떤 프롬프트에서 나왔는지 추적 가능하게 한다. 파일명이나 버전 태그에 변경 이유·수정 내용·작성일을 기록하면 재현성과 협업이 개선된다. Git 같은 형상관리 도구와 결합하면 롤백과 비교가 쉬워진다.

Environment snapshot

— 실행환경 스냅샷은 의존성 버전, 런타임 설정, 시스템 이미지 등을 특정 시점에 저장해 동일 환경에서 재실행할 수 있게 하는 절차로, 모든 실험이 아니라 '환경이 안정화된 시점'에 한해 저장하는 것을 권장했다. 스냅샷에는 패키지 버전, GPU 드라이버, 컨테이너 설정, 스크립트 버전 등이 포함되어 재현 가능한 결과 산출에 기여한다. 클라우드 디스크 이미지나 컨테이너 레지스트리와 결합하면 복원성이 높아진다.