RAG는 데이터가 쌓이면 멍청해질까: top-k와 검색 품질 이야기

왜 이 주제가 중요한가

사내 문서에 AI 챗봇을 붙이면 도입 첫 달이 제일 똑똑합니다. 문서 열 개짜리 인덱스에서는 뭘 물어도 정답 문서가 걸리니까요. 그런데 반년쯤 지나 문서가 수백 개로 불어나면 슬슬 이상한 답이 늘어납니다. "데이터를 더 넣었는데 왜 더 멍청해지지?"라는 질문은 RAG를 운영해 본 팀이라면 반드시 만나는 질문입니다.

결론부터 말하면, RAG는 애초에 데이터가 커지라고 만든 기술이라 원리적으로 불리해지지는 않습니다. 하지만 무관리로 쌓으면 확실히 나빠집니다. 그리고 나빠지는 부위는 거의 항상 생성이 아니라 검색입니다. 이 글은 어디가 어떻게 아파지는지, 그리고 무엇부터 손대면 되는지의 순서표입니다.

핵심 개념: top-k부터 이해하기

RAG의 검색 단계는 이렇게 돌아갑니다.

질문 → 모든 문서 조각과 유사도 점수 계산 → 점수순 정렬
→ 상위 k개(예: 12개)만 뽑아 LLM에게 전달   ← 이 숫자가 top-k

전부 주지 않고 상위 몇 개만 끊는 이유는 두 가지입니다. 모델이 한 번에 읽을 수 있는 분량(컨텍스트)이 유한하고, 넣을 수 있다 해도 관련 없는 조각이 섞일수록 모델이 헷갈리기 때문입니다. 시험 볼 때 참고서 세 권이 낫지, 도서관을 통째로 안겨주면 오히려 못 찾는 것과 같습니다.

문제는 이 k가 고정 예산이라는 점입니다. 데이터가 열 배로 늘어도 모델에게 전달되는 조각은 여전히 k개입니다. 여기서 대용량 RAG의 모든 증상이 출발합니다.

데이터가 커질수록 실제로 아파지는 지점

1. 정답과 "비슷한 오답"이 늘어납니다. 문서 10개일 때는 뭘 검색해도 정답이 상위에 듭니다. 500개가 되면 같은 주제의 기획서·회의록·개정판이 여럿 생기고, 임베딩 유사도만으로는 그중 어느 것인지 가리지 못합니다. 검색이 못 찾는 게 아니라, 후보가 많아져 헷갈릴 거리가 늘어나는 것에 가깝습니다.

2. 신구 충돌이 잦아집니다. 작년 요금표와 올해 요금표가 함께 검색되면 모델은 태연하게 작년 값으로 답합니다. 문서가 쌓일수록 "옛 정보가 상위에 걸릴 확률"이 함께 쌓입니다.

3. top-k 예산은 그대로인데 관련 문서는 늘어납니다. 관련 조각이 20개인데 k가 12면 커버리지가 구조적으로 깎입니다. 특히 "전부 나열해줘" 류의 목록 질문에서 가장 심하게 드러납니다. (이 문제는 k를 키워도 근본 해결이 안 됩니다. 저희가 재고 질문을 아예 RAG 밖으로 뺀 이유이기도 한데, 그 얘기는 앞선 글에 정리해 두었습니다.)

4. 검색 인프라 비용은 가장 나중에 옵니다. 조각 수천 개 수준이면 단순한 전수 비교로도 충분히 빠릅니다. 수십만 단위가 되면 전용 벡터 인덱스(ANN)로 넘어가야 하지만, 이건 품질 저하가 아니라 예측 가능한 인프라 업그레이드 문제입니다. 걱정 순서상 맨 뒤에 두면 됩니다.

실제 적용 포인트: 손대는 순서

1. 정형 질문은 RAG 밖으로 빼세요. 재고·집계·목록처럼 정답이 DB에 있는 질문은 데이터가 클수록 라우팅의 이득이 커집니다. 물건이 1만 개가 되면 RAG로 재고 질문은 절대 안 되지만, DB 조회는 똑같이 즉답입니다.
2. 버리는 정책을 먼저 만드세요. 아카이브·구버전 문서를 인덱스에서 제외하는 규칙이 리랭킹 도입보다 먼저입니다. 인덱스 품질은 넣는 것보다 빼는 것으로 관리됩니다. 근거에 문서 수정일을 함께 실어 모델이 최신본을 우선하게 하는 것도 저비용 처방입니다.
3. 검색 전 후보를 줄이세요. 문서 종류·부서·프로젝트 같은 메타데이터로 검색 공간을 나누면, 유사 오답의 모수 자체가 줄어듭니다. 라우팅의 검색판이라고 보면 됩니다.
4. 리랭킹을 넣으세요. 1차로 넉넉히(예: 50개) 검색한 뒤 정밀한 모델로 재정렬해 상위 몇 개만 생성에 투입하는 2단계 구조가 유사 오답 문제의 정석 처방입니다.
5. 골드셋으로 재세요. 대표 질문 20~30개와 기대 답을 정해두고 데이터가 늘 때마다 돌려보면, "요즘 멍청해진 것 같은데"를 감이 아니라 수치로 잡을 수 있습니다.

주의할 점

• k를 키우는 것은 해법이 아닙니다. 커버리지는 조금 늘지만 노이즈와 비용이 같이 늘고, "빠짐없이 전부"는 여전히 보장되지 않습니다. k 조절은 미세 튜닝이지 구조 처방이 아닙니다.
• 증상 없이 처방하지 마세요. 위 순서표의 3~4번은 검색이 헛도는 게 체감될 때 넣어도 늦지 않습니다. 작은 인덱스에 리랭커부터 붙이는 것은 비용만 쓰는 과잉 설계입니다.
• 평가 없는 운영이 진짜 리스크입니다. RAG 품질 저하는 갑자기 오지 않고 문서가 쌓이며 서서히 옵니다. 골드셋이 없으면 나빠진 시점을 아무도 모릅니다.

듀오랩스가 보는 관점

"데이터가 많아지면 AI가 더 똑똑해진다"는 기대는 학습에는 맞지만 검색에는 절반만 맞습니다. 검색 기반 시스템의 품질은 데이터의 양이 아니라 인덱스의 위생에서 나옵니다. 저희가 사내 문서 AI를 운영하며 얻은 교훈도 같습니다. 잘 버리고, 최신본을 표시하고, 정형 질문을 옆길로 빼는 낮은 기술의 관리가 비싼 모델 교체보다 먼저였습니다.

RAG 도입을 검토 중이라면 "데이터가 늘면 어쩌지"를 걱정하기보다, 늘어난 뒤에 무엇을 뺄지의 규칙을 처음부터 함께 설계하시길 권합니다.