katsubee RAG 로우데이터 수집, 198건 분석

• katsubee는 매일 새벽 지식 청크에서 질문을 만들어 실제 검색 경로를 돌리고, 단계별 정답 순위를 기록한다.
• 10월 12일부터 25일까지 쌓인 198건을 보면 정답은 키워드 후보에 82.3%, 벡터 후보에 29.8% 들어 있었다.
• 정답이 후보 어디에도 없는 경우가 26건이고, RRF 12개 단계에서 잘린 경우가 43건이라 다음 개선 대상이 보인다.

이 글은 katsubee·katsubox 소개 글에서 이어지는 개선 시리즈의 다섯 번째 글이다. 앞선 글에서는 한 번 돌린 벤치마크 40문항으로 검색을 고치고 리랭킹을 쟀다. 이번에는 그 측정을 한 번으로 끝내지 않기 위해 만든 로우데이터 수집을 다룬다.

벤치마크 40문항 한 번으로는 부족했다

키워드 검색이 0건이던 문제를 찾은 것도, 리랭킹 효과를 잰 것도 벤치마크 40문항 덕분이었다. 문제는 그 40문항이 한 번 만든 고정 세트라는 점이다. 문서가 늘거나 모델을 바꾸면 같은 수치가 유지되는지 알 수 없고, 고정 세트에 맞춰 고치다 보면 세트에만 잘 맞는 검색이 될 수 있다.
그래서 검색 품질 개선과 골든셋 생성에 쓸 원재료를 주기적으로 쌓는 수집 스케줄을 만들었다. 이 수집기는 사용자 대화를 읽지 않고 지식 문서 청크만 쓴다.

수집기가 하는 일

매일 새벽 03:30에 한 번 돌고 한 번에 질문 15개를 만든다. 먼저 지식 청크를 고르는데 덜 쓰인 청크부터 고르고, 350자 미만이거나 한글이 적은 표와 코드 청크는 건너뛴다. 그래서 문서가 고르게 표본에 들어간다.
채팅 모델이 그 청크 하나만 읽고 답할 수 있는 질문을 한 개 만든다. 단락의 문구를 베끼지 않고 일상어로 바꿔 묻게 하고, 이 문서나 위 단락 같은 지시어는 금지했다. 그 질문으로 실제 검색 경로를 돌리면 질문의 출처 청크가 정답이 되므로 사람이 채점하지 않아도 단계별 순위가 나온다.
기록하는 값은 벡터, 키워드, RRF, 프롬프트에 쓰인 청크 각각에서 정답이 몇 위였는지다. 정답 문서가 프롬프트에 쓰였는지, 검색에 걸린 시간, 참고 자료만으로 만든 답변도 함께 남긴다. 결과는 DB 테이블과 날짜별 JSONL 파일에 쌓이고, 질문 하나가 실패하면 건너뛰고 계속한다. 한 번에 하나씩 순차로 돌려서 채팅과 GPU를 다투지 않는다.

198건에서 보인 것

10월 12일부터 25일까지 쌓인 표본은 198건이다. 모델은 모두 gemma4:26b이고 모든 표본이 리랭킹이 적용된 상태로 기록됐다. 이 글의 수치는 이 198건을 직접 집계한 값이다.

가장 눈에 띄는 것은 두 후보 경로의 차이다. 키워드 후보 20개 안에 정답이 든 비율이 82.3%(163건)였고, 벡터 후보 20개 안에는 29.8%(59건)뿐이었다. 키워드를 OR와 접두 매칭으로 고친 뒤 하이브리드 검색이 실제로 키워드가 끌고 가는 구조가 됐다는 뜻이다.

경로별로 나누면 키워드만 정답을 잡은 경우가 113건, 둘 다 잡은 경우가 50건, 벡터만 잡은 경우가 9건이었다. 두 경로 모두 정답을 못 잡은 경우가 26건(13.1%)이다. 벡터의 기여는 작지만 벡터만 잡은 9건이 있으니 없애도 되는 갈래는 아니다.

RRF에서 잘리는 정답과 리랭킹이 구한 정답

후보 단계에서 잡힌 정답이라도 RRF 12개로 줄이는 과정에서 43건이 잘렸다. 정답이 RRF 12개 안에 든 비율은 65.2%(129건)이고, 최종 프롬프트에 쓰인 4개 안에 든 비율은 62.6%(124건)다.
리랭킹의 기여도 따로 셀 수 있었다. RRF 순서 그대로였다면 정답이 상위 4개에 든 것은 57건(28.8%)이다. 리랭킹 뒤에는 124건이 됐다. RRF 5위에서 12위에 있던 정답 67건을 4개 안으로 끌어올렸고, 반대로 12개 안에 있던 정답을 빼 버린 경우는 5건이었다. 원래 상위 4개에 있던 정답을 잃은 경우는 없었다.

정답 청크는 아니어도 정답 문서의 다른 청크가 쓰인 경우까지 보면 193건(97.5%)이다. 질문의 출처 청크 하나만 정답으로 치기 때문에 엄격한 기준이고, 실제로 답변에 필요한 근거는 더 자주 들어갔다고 볼 수 있다.

비용도 같이 쌓인다

검색 시간의 중앙값은 6.5초이고 참고 자료 기반 답변은 3.9초였다. 검색 시간의 대부분은 리랭킹이다. 이전 글에서 잰 6.4초와 같은 수준이라, 정확도를 얻는 대신 지연을 치르고 있다는 점이 매일 같은 크기로 확인된다.

로우데이터 수집에도 빠진 날이 있다

수집 파일은 10월 12일부터 25일까지 13개이고 10월 23일 하루만 없다. 같은 날 새벽 04:00의 일반 질의 수집과 katsubox의 04:10 DB 백업도 비어 있다. 서로 다른 서비스의 새벽 작업 세 개가 같은 날 함께 빠진 것이다.
원인은 각 작업의 버그가 아니라 Mac 전체가 꺼져 있었던 것이다. 시스템 재부팅 기록에 따르면 10월 23일 02:36에 종료돼 같은 날 20:38에 다시 켜졌고, 세 작업의 실행 시각이 모두 그 사이에 있다. 종료된 이유는 확인하지 못했다. 로우데이터 수집은 하루가 빠져도 표본이 15건 줄 뿐이지만, 백업이라면 같은 공백이 더 아프다.

읽을 때 주의할 점과 다음 개선

이 수치에는 편향이 있다.

청크 단어가 섞여 키워드에 유리

질문을 LLM이 청크에서 만들기 때문에 청크의 단어가 질문에 섞여 들어가고, 이 경우 키워드 검색에 유리하다. 실제 사용자는 문서에 없는 단어로 묻거나 모호하게 묻는다. 같은 내용이 다른 청크에도 있으면 정답을 놓쳐도 답은 맞을 수 있다. 수집 대상이 사용자 대화가 아니라서 실제 질문 분포는 담지 못한다.
그래도 다음에 손댈 곳은 분명해졌다.

다음에 손댈 곳 세 가지

첫째는 정답이 후보에 없는 26건이다. 어떤 문서와 청크에서 실패하는지 사람이 검수해 골든셋으로 옮기면 배포 게이트에 들어간다. 둘째는 RRF 12개에서 잘린 43건이다. 후보 풀을 늘리면 리랭킹이 더 구할 수 있지만 지연도 늘어서 같은 수집 데이터로 실제 효과를 재 볼 계획이다. 셋째는 벡터 경로의 29.8%다. 임베딩을 바꾸면 얼마나 달라지는지 같은 질문으로 비교할 수 있게 됐다.