AI VIDEO BRIEFING
RAG 검색 심화 정리: BM25와 임베딩, 리랭커, 에이전틱 RAG 중 무엇을 골라야 하나
데모에서 잘 돌던 RAG는 운영에 올리는 순간 정확도와 지연, 비용, 문서 권한에서 무너집니다. 하이브리드 검색에 리랭커를 얹은 기본선부터 세우고, 정확도가 중요하면 에이전틱 검색으로 넘어가라는 실무 기준을 정리했습니다.

핵심 메시지
쉽게 이해하기
발표자는 기업 안에서 벌어지는 익숙한 장면으로 시작합니다. 사내 문서로 챗봇을 만들었더니 데모는 잘 돌아가는데, 막상 운영에 올리면 정확도가 떨어집니다. 평가를 단순한 정보 추출용 합성 데이터로 했는데 실제 사용자는 훨씬 복잡한 질문을 던지기 때문입니다. 여기에 응답이 너무 느리거나, 문서가 100개에서 100만 개로 늘어나며 확장이 막히거나, 복잡한 다중 에이전트 구성 탓에 질의 한 번에 1달러씩 드는 문제가 겹칩니다. 그리고 대부분이 놓치는 마지막 벽은 기업 안에서 모든 사람이 모든 문서를 볼 수 있는 것은 아니라는 권한 문제입니다.
그래서 기술 선택 이전에 트레이드오프 대화를 먼저 하라고 권합니다. 얼마나 빨라야 하는지, 비용은 어디까지 감당할 수 있는지, 문제의 복잡도는 어느 정도인지를 사용자와 미리 합의하라는 것입니다. 특히 실수의 비용이 기준이 됩니다. 개발자가 결과를 바로 확인할 수 있는 코딩 보조 도구에 생성형 AI가 빠르게 자리 잡은 것과, 환자의 생명이 걸린 의료 분야가 더딘 것은 같은 이유입니다. 사용자가 어떤 질문을 던질지도 미리 그려 봐야 합니다. 단순 키워드인지, 표현이 다른 의미 검색인지, 여러 문서를 오가는 다단계 질문인지, 아예 문서에 없는 지식을 묻는 경우인지에 따라 설계가 완전히 달라집니다.
본론인 검색 방식은 세 갈래로 정리됩니다. 첫째, BM25는 문서에 등장하는 단어로 역색인을 만들어 찾는 어휘 검색으로, 문서를 하나씩 훑는 선형 탐색보다 자릿수 단위로 빠릅니다. 약점은 표현 불일치입니다. 사용자가 physician을 물었는데 문서에는 doctor만 있거나, IBM과 그 정식 명칭이 서로 다른 단어로 취급되는 경우입니다. 둘째, 임베딩 모델은 텍스트를 숫자 공간으로 인코딩해 의미가 가까운 것끼리 붙여 놓기 때문에 이 문제를 풉니다. 단어마다 고정된 값을 주는 정적 임베딩은 훨씬 빠르지만, model이 통계 모델인지 패션 모델인지 같은 문맥 의존적 의미를 놓칩니다.
모델 선택은 공개 리더보드를 활용하되 함정을 알고 봐야 합니다. 다국어 임베딩 리더보드에는 300개 안팎의 모델이 올라와 있고, 최근 추가된 검색 임베딩 리더보드는 공개되지 않은 평가 데이터를 쓰기 때문에 벤치마크에 맞춰 학습하는 편법을 막아 줍니다. 같은 크기의 모델끼리도 점수 차가 나는데, 이는 학습 전략과 아키텍처가 개선된 세대 차이입니다. 여기에 차원을 줄여도 검색 품질이 유지되는 마트료시카 임베딩, 문장 단위로 학습된 센텐스 트랜스포머, 질의와 후보 청크를 교차 비교해 순위를 다시 매기는 리랭커가 실무 도구로 소개됩니다. 발표자가 권하는 기본선은 어휘 검색과 의미 검색을 융합한 하이브리드 검색에 리랭커를 얹는 조합입니다.
마지막은 에이전틱 RAG입니다. 한 번 검색해 끝내는 대신, 답이 충분한지 모델에게 되묻고 부족하면 질의를 다시 써서 검색을 반복하는 방식입니다. 발표자가 공개된 기술 지원 데이터로 직접 돌려 보니 원샷 RAG는 5초 안팎에 답하고 사실성 점수가 0.76이었던 반면, 반복 검색을 붙이자 시간은 늘었지만 점수가 0.93까지 올랐습니다. 더 흥미로운 것은 추론형 검색 벤치마크에서 구식으로 여겨지던 BM25가 임베딩 모델보다 좋은 성적을 냈다는 점입니다. 언어 모델이 스스로 질의를 바꿔 쓰기 때문에 의미 차이를 임베딩에 맡길 필요가 줄어든 것입니다.
주요 인사이트
- RAG의 실패는 대개 모델이 아니라 시스템 설계에서 옵니다. 문서 파싱과 청킹이 지저분하면 어떤 검색 모델을 붙여도 회복되지 않습니다.
- 논문을 더 찾아 읽는 것보다 기준선을 먼저 세우는 편이 낫습니다. 하이브리드 검색에 리랭커를 얹은 조합을 기준으로 두고, 어디서 부족한지 확인한 뒤 대안을 고르라는 조언입니다.
- 에이전틱 RAG의 점수는 목표치이자 진단 도구입니다. 반복 검색으로만 풀리는 질문들을 따로 모아 보면, 원샷 검색을 어떻게 고쳐야 하는지가 드러납니다.
- 언어 모델이 질의를 다시 쓸 수 있게 되면서 어휘 검색의 위상이 달라졌습니다. 벡터 데이터베이스 없이 텍스트 데이터베이스와 BM25만으로도 여러 도메인에서 쓸 만한 정확도가 나왔다는 실측이 제시됩니다.
- 속도와 정확도는 한쪽을 고르는 문제가 아닙니다. 간단한 유사도 검사를 1차로 두고 어려운 경우만 언어 모델에 넘기는 2단 구조처럼, 방식을 겹쳐 쓰는 설계가 현실적입니다.
자주 묻는 질문
RAG를 운영에 올릴 때 가장 흔한 실패 원인은 무엇인가요?
평가를 단순한 합성 질문으로 해서 실제 사용자의 복잡한 질문에 정확도가 떨어지는 경우가 대표적입니다. 여기에 응답 지연, 문서 수 증가에 따른 확장 문제, 질의당 비용, 그리고 모든 사용자가 모든 문서를 볼 수는 없다는 접근 권한 문제가 더해집니다.
처음 RAG를 만든다면 어떤 검색 구성을 권하나요?
어휘 검색과 의미 검색을 함께 돌린 뒤 결과를 융합하는 하이브리드 검색에 리랭커를 얹는 구성을 기본선으로 권합니다. 여러 대안을 시도하기 전에 이 기준선부터 만들어 어디가 부족한지 확인하라는 조언입니다.
에이전틱 RAG는 언제 쓰는 것이 맞나요?
정확도가 중요하고 사용자가 기다릴 수 있는 경우입니다. 3~5초 안에 답이 나와야 하는 서비스라면 원샷 검색이 여전히 유효하고, 여러 문서를 오가는 복잡한 질문이라면 반복 검색이 더 맞습니다.
원문과 출처
이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.
YouTube 원본 영상 보기 ↗