RAG 의 검색 계층은 벡터 DB 부터 세우지 말고 문서의 성격과 규모로 고른다

RAG 를 만든다고 하면 임베딩 모델과 벡터 DB 부터 고르기 쉽다. 하지만 벡터 DB 가 기본값일 이유는 없다. 이 글은 검색 계층을 문서의 성격, 규모, 이미 운영할 수 있는 인프라로 고르는 기준과, 단순한 방식에서 시작해 단계적으로 올리는 순서를 정리한다.

로컬 환경의 RAG 구성 논의를 모은 Hacker News 스레드 Ask HN: 로컬에서 RAG를 어떻게 구현하고 있나요?(GeekNews 소개, 원문 HN 스레드)를 바탕으로 한다. 스레드의 내용은 참여자들의 경험과 의견이므로, 아래 기준도 검증된 법칙이 아니라 출발점으로 읽는다.

선택 기준

스레드에서 반복된 의견을 선택 기준으로 정리하면 다음과 같다.

선택 기준은 정확도만이 아니다. 운영을 다른 사람에게 넘길 수 있는지, 색인을 갱신하는 비용을 감당할 수 있는지도 포함한다. PostgreSQL 에 pgvector 를 얹는 선택이 거론된 이유도 기존 운영 지식을 그대로 쓰고 인수인계가 쉽기 때문이다.

벡터를 쓸 때의 저장소 선택지

스레드에 언급된 선택지는 다음과 같다.

전용 벡터 DB 제품을 서로 비교하는 글은 벡터 DB 어떻게 고를까에 있다. 이 글의 선택지는 그보다 앞 단계, 즉 전용 벡터 DB 가 정말 필요한지를 판단하는 쪽이다.

단계적으로 올리는 순서

검색을 처음부터 완성형으로 만들지 않고 아래 순서로 올린다.

1. 키워드 검색과 메타데이터 필터로 시작한다.
2. 부족한 질의 유형을 확인한 뒤에 벡터 검색을 더한다.
3. 두 검색의 순위를 RRF(Reciprocal Rank Fusion) 같은 순위 기반 방식으로 합친다.
4. 마지막에 재정렬 모델을 얹는다.

RRF 가 점수 대신 순위로 합치는 이유는 Milvus 벡터 데이터베이스 입문에 정리돼 있다.

각 단계를 올릴 때 무엇이 좋아졌는지 측정하지 않으면 복잡도만 남는다. 측정 장치를 먼저 두는 방법은 RAG 검색을 제품별로 만들지 않고 공통 파이프라인으로 둔다에서 다룬다.

한국어에서는 별도로 확인한다

스레드에는 한국어 처리 품질에 의문을 제기한 댓글도 있었다. BM25 는 토큰을 어떻게 나누느냐에 점수가 좌우되므로, 한국어 문서에서는 형태소 분석기를 쓰는지가 결과를 정한다. 스레드의 사례를 그대로 가져오기 전에, 자신의 문서로 키워드 검색의 recall 을 먼저 측정한다.

정리