요즘 RAG를 만든다고 할 때, BM25는 없어도 된다. 그래프도 없어도 된다. 하지만 벡터 검색은 빠지기 어렵다.

이 말은 BM25가 쓸모없다는 뜻이 아니다. GraphRAG가 과장이라는 뜻도 아니다. 둘 다 좋은 도구다. 다만 역할이 다르다.

BM25 = 같은 단어를 찾는다
Vector = 같은 의미를 찾는다
Graph = 관계를 따라간다

문제는 RAG의 입력이 보통 “검색어”가 아니라 “질문”이라는 점이다.

검색어가 아니라 질문이 들어온다

문서에는 이렇게 적혀 있을 수 있다.

HTTP 429 rate limit exceeded

그런데 사용자는 이렇게 묻는다.

요청을 너무 많이 보내서 막히면 어떻게 해야 해?

BM25는 겹치는 단어가 거의 없다. HTTP, 429, rate, limit 중 사용자가 직접 입력한 단어가 없다. 그래프도 이 관계를 미리 잘 만들어두지 않았다면 바로 답을 못 한다.

하지만 벡터 검색은 이 둘이 같은 상황을 말한다는 것을 잡아낸다. 이게 현대 RAG에서 벡터가 기본층이 되는 이유다.

BM25는 여전히 강하다

BM25는 정확한 단어가 중요할 때 강하다.

HTTP 429
Stripe webhook
org_id
BM25 k1
PostgreSQL VACUUM

이런 질의는 BM25가 벡터보다 나을 때가 많다. 숫자, 코드, 고유명사, 함수명, 에러 메시지는 “의미가 비슷한 것”보다 “정확히 같은 것”이 중요하다.

하지만 실제 사용자는 대개 문서 안의 단어를 모른다. 사용자는 issuer declines authorization이라고 검색하지 않는다. 그냥 이렇게 묻는다.

카드 한도 말고 결제가 막히는 이유가 뭐야?

여기서 RAG의 첫 번째 문제는 검색 기술이 아니다. 사용자의 표현과 문서의 표현이 다르다는 것이다.

벡터 검색은 이 간극을 메운다. 그래서 RAG에서 벡터는 “옵션 기능”이라기보다 자연어 질문을 받는 순간 필요한 기본 장치에 가깝다.

그래프는 의미 검색보다 관계 검색에 강하다.

이 고객이 속한 조직의 미결제 인보이스와 연결된 계약은?

이런 질문은 벡터만으로는 약하다. 고객, 조직, 인보이스, 계약 사이의 관계를 알아야 한다. 이때 그래프가 강력하다.

하지만 대부분의 블로그, 문서, FAQ, 정책, 제품 설명, 회의록 RAG에서는 먼저 해야 할 일이 있다.

질문과 관련된 문단을 찾기

이 기본 retrieval 문제에서는 벡터가 가장 넓게 먹힌다. 그래프는 관계가 중요한 도메인에서 정확도를 올리는 보강재다. BM25는 정확한 키워드를 놓치지 않게 하는 보강재다. 벡터는 자연어 질문과 문서 사이를 연결하는 기본 통로다.

좋은 RAG는 벡터만으로 끝나지 않는다. 하지만 벡터 없이 시작하기는 어렵다.

BM25는 정확한 단어를 잡는다. 그래프는 구조적 관계를 잡는다. 벡터는 사용자가 실제로 말하는 방식과 문서가 쓰인 방식 사이의 의미 차이를 잡는다.

그래서 요즘 RAG에서 BM25와 그래프는 없어도 되는 경우가 있다. 하지만 벡터는, 적어도 비정형 문서와 자연어 질문을 다루는 RAG라면, 거의 항상 출발점이다.