RAG 시스템 구축 5단계 - 골든 데이터셋과 에러 분석으로 실전 검색증강생성 만들기

핵심 메시지

• RAG가 실패하는 전형적인 패턴은 문서를 벡터 DB에 넣고 답이 나올 걸 아는 질문으로만 시연한 뒤 실제 사용자 앞에서 무너지는 것이다.
• 1단계는 사용자, 사용 사례, 데이터 원본을 각각 하나로 좁히는 MVP 범위 설정이다. 모든 사용자와 모든 문서를 담으려다 프로젝트가 좌초한다.
• 2단계 골든 데이터셋은 사용자 입력과 정답 문맥의 쌍이며, 개발용과 테스트용으로 분할해야 데이터셋에 과최적화되지 않는다.
• 검색 시스템은 정밀도, 상위 K 재현율, 평균 역순위 중 목적에 맞는 지표로 평가하고, 응답 품질은 정해진 지표가 없으므로 에러 분석으로 실패 유형을 태깅한다.
• 개선은 한 번에 하나씩 바꾸는 실험으로 진행하며, 대개 병목은 원본 문서의 추출·전처리·청킹에 있다.

쉽게 이해하기

RAG는 검색 증강 생성의 줄임말로, 모델이 가진 지식에만 의존하지 않고 필요한 문맥을 자동으로 찾아 컨텍스트 창에 넣어 주는 구조다. 텍스트 파일이나 워드 문서, PDF는 물론이고 사내 매뉴얼, 기술 문서, 영상 자막, 회의록, 이미지 같은 비텍스트 데이터까지 대상이 된다. 이렇게 하면 환각을 줄이고, 파인튜닝 없이 시스템의 지식을 관리할 수 있으며, 학습 시점 이후의 정보나 외부에 공개되지 않은 사내 정보까지 다룰 수 있다. 그런데 현실에서 반복되는 문제는 하나로 요약된다. 인상적인 데모는 만들어 내지만 배포 결과가 실망스럽다는 것이다. 전형적인 전개는 이렇다. 문서를 잔뜩 모아 벡터 DB에 밀어 넣고 검색을 붙인다. "X가 무엇인가", "Y는 어떻게 하나" 같은, 답이 나올 것을 아는 질문으로 시연하면 잘 돌아간다. 그러나 실제 사용자가 쓰기 시작하면 같은 시스템이 제대로 작동하지 않는다.

그래서 제시하는 것이 5단계 절차다. 1단계는 MVP 범위 설정으로, AI나 코딩과는 아무 상관이 없는 기본적인 프로젝트 관리다. 누가 쓰는지, 어떤 문제를 푸는지, 그리고 어떤 원본 데이터를 지식 베이스에 넣을지를 정한다. 여기서 흔한 함정이 초기 버전을 과하게 잡는 것이다. 모든 사용자와 모든 사용 사례, 모든 데이터 원본을 담는 시스템은 만들기 어렵고 오래 걸리며 투자를 정당화할 성과가 안 나올 수 있다. 발표자는 자신의 사례로 사용자는 자기 AI 코호트 수강생, 사용 사례는 기술 Q&A로만 한정, 원본은 자신의 유튜브 자막 하나만 쓴 답변 엔진을 들었다. 6주 정도에 끝낼 수 있는 크기로 시작해야 다음 단계가 보인다.

2단계는 골든 데이터셋이다. 사용자 입력과 그에 대응하는 정답 문맥의 쌍을 모은 것으로, 검색 시스템을 평가할 기준선 역할을 한다. 질의응답에만 해당하는 개념이 아니어서, 입력이 보험 청구서이고 검색 결과가 유사 청구 건이라면 그 쌍이 골든 데이터셋이 된다. 여기서 중요한 기술적 주의사항은 개발용과 테스트용 분할이다. 전체를 최적화에 다 쓰면 그 데이터셋에만 맞는 시스템이 되어 다른 입력에 일반화되지 않는다. 만드는 방법은 두 가지다. 가장 좋은 것은 이미 운영 중인 시스템에서 실제 사용자 질의를 뽑아 정답 문맥을 사람이 붙이는 방식이다. 다만 대부분은 기준선 시스템 자체가 없어서 합성 질의 생성으로 간다. 이때 프롬프트를 LLM에 맡기고 방치하면 저품질 질의가 시스템 전체의 품질을 끌어내린다. 페르소나, 사용 사례, 기능 같은 축을 정의해 조합별로 질의를 만들게 하는 방식이 권장된다. 발표자는 영상 자막과 해당 영상의 댓글을 함께 근거로 주고 사실형·개념형·절차형 세 유형에 상·중·하 난이도를 걸어 영상당 9개를 생성한 뒤, 직접 검토해 6개로 추렸다. 양보다 질이 중요하기 때문이다.

3단계는 검색 시스템의 초기 버전을 만드는 것인데, 요즘 도구들이 추상화를 다 제공하므로 벡터 검색이든 키워드 기반 렉시컬 검색이든 하이브리드든 만드는 일 자체는 쉽다. 정작 중요한 건 성공의 정의다. 정밀도는 검색된 청크 중 관련 있는 것의 비율, 상위 K 재현율은 전체 관련 청크 중 상위 K 안에 들어온 비율, 평균 역순위는 여러 질의를 순위 기반으로 묶어 보는 집계 지표다. 관련 문서가 결과에 들어오기만 하면 되는 상황에서는 재현율이, 결과의 순도가 중요하면 정밀도가 적합하다. 4단계는 응답 생성부다. 검색부와 응답부는 독립된 구성요소이므로 따로 만들고 따로 평가해야 한다. 구조는 질의가 오면 무조건 검색을 실행하는 고전적 RAG와, 검색을 도구로 넘겨 모델이 필요할 때 호출하게 하는 에이전틱 RAG로 나뉜다. 전자는 단순하지만 인사말에도 검색이 돌고, 후자는 질의 재작성 부담이 줄지만 필요할 때 검색하지 않거나 불필요할 때 검색하는 새로운 실패가 생긴다. 발표자는 고전적 RAG로 시작해 다른 실패를 먼저 정리한 뒤 넘어가기를 권한다.

응답 품질에는 정밀도나 재현율 같은 기성 지표를 쓸 수 없다. 그래서 에러 분석으로 간다. 입력과 출력을 놓고 사람이 직접 읽으며 자유 형식 메모를 남기는 방식으로, 최소 30건, 가능하면 100건 정도를 읽으면 패턴이 드러난다. 발표자의 사례에서는 모델이 자막을 사용자가 제공한 것처럼 말하는 실패가 반복돼 '나쁜 프레이밍'이라는 태그가 붙었고, 이 실패가 응답의 50%에서 나타났다. 그 밖에 지나치게 어려운 표현, 낡은 파이썬 코드, 구조 없는 서술 같은 유형이 나왔다. 태그가 정리되면 평가를 자동화한다. 나쁜 프레이밍처럼 예측 가능한 문구가 반복되는 경우는 단순 문자열 검사로 충분하고, 서술 구조 같은 항목은 LLM 심판이 필요하다. 다만 LLM 심판의 라벨은 처음부터 사람 라벨과 잘 맞지 않으므로 정렬에 상당한 시간을 들여야 하며, 여기서도 개발·테스트 분할이 필요하다. 발표자는 가능하면 코드 기반 평가를 쓰라고 권한다. 단순해서 어디서 깨지는지 알 수 있는 반면, LLM 심판은 언제 믿을 수 있는지가 분명하지 않기 때문이다. 마지막 5단계는 실험이다. 초기 버전을 기준선으로 두고 프롬프트, 모델, 검색 구성 중 한 번에 하나만 바꿔 지표 변화를 본다. 발표자의 실제 수치로는 프롬프트를 고쳐 나쁜 프레이밍 비율이 50%에서 7%로 떨어졌다. 개선 순서는 대개 검색부부터이고, 그중에서도 원본 문서의 추출·전처리·청킹이 가장 큰 몫을 차지한다. 그 밖에 데이터 형식이나 사용 사례별 인덱스 분리, 임베딩 모델 교체, 메타 태그 기반 하이브리드 검색, 리랭커 추가, 질의 재작성, 더 강한 모델이나 질의 라우팅 같은 선택지가 있다. 선택지가 워낙 많기 때문에, 고치려는 실패를 먼저 정하고 그 실패를 대표하는 지표를 세운 다음 한 번에 하나씩 바꾸는 절차가 필요하다.

주요 인사이트

• RAG 프로젝트의 실패는 대부분 기술이 아니라 범위 설정에서 시작된다. 모든 사용자와 모든 문서를 노린 초기 버전은 구성요소마다 충분한 주의를 못 받거나 아예 완성되지 못한다.
• 골든 데이터셋은 평가 도구가 아니라 개발의 방향타다. 합성 질의의 품질이 낮으면 그 위에서 최적화된 시스템의 품질도 함께 낮아진다.
• 검색부와 응답부를 분리해 따로 평가하라는 원칙이 중요한 이유는, 합쳐 놓으면 답이 나쁠 때 문서를 못 찾은 건지 문맥을 못 쓴 건지 구분할 수 없기 때문이다.
• 에러 분석에서 30건 이상을 읽으라는 조언의 요지는, 한 번 나온 이상함은 우연이지만 반복되는 이상함은 고칠 수 있는 실패 유형이라는 점이다. 나쁜 프레이밍처럼 프롬프트 한 줄로 50%에서 7%까지 떨어지는 실패도 있다.
• LLM 심판보다 코드 기반 평가를 우선하라는 권고는 신뢰의 관측 가능성 문제다. 단순한 문자열 검사는 어디서 깨지는지 알 수 있지만, LLM 심판은 언제 믿을 수 있는지가 불투명하다.

자주 묻는 질문

관련 AI 소식