RAG 벡터DB의 필터링 성능 차이, 뭘 기준으로 봐야 할까?

결론부터 말하면 "어떤 벡터DB가 필터링이 빠른가"보다 "내 필터 선택도에서 재현율이 무너지지 않는가"를 먼저 물어야 한다. 100M 벡터·15~25% 필터 통과율 조건에서는 Qdrant 1.10이 p99 18.4ms·Recall@10 0.97을 기록했지만, 통과율이 1% 이하로 떨어지는 멀티테넌시 조건에서는 같은 제품도 다른 숫자가 나올 수 있다출처. 2026년 기준으로 벤치마크 표를 그대로 믿기보다, 자신의 필터 조건으로 재현해보는 과정이 필요하다.

  • 필터 선택도가 50~99.9%로 좁아질수록 쿼리 속도가 수십~수백 배 흔들릴 수 있다출처.
  • post-filtering 방식은 전역 Top-K를 먼저 뽑은 뒤 조건을 거르기 때문에, 1%만 통과하는 조건에서는 반환 결과가 K보다 적어질 수 있다.
  • Qdrant·Milvus는 필터 카디널리티에 맞춰 그래프 탐색과 전체 스캔을 전환하는 방식(ACORN 등)으로 고선택도 조건에서의 재현율 저하를 줄이려는 접근을 취한다.
  • Recall 수치 하나만 보면 안 되고, 같은 조건에서 QPS와 p99 지연시간을 함께 기록해야 운영 가능 여부를 판단할 수 있다.
  • pgvector는 비용이 가장 낮게 제시되지만 post-filtering 구성 여부를 먼저 확인해야 한다출처.

흔히 빠지는 함정은 벤더가 공개한 "평균 지연시간"이나 "Recall@10 0.9x" 숫자를 필터 조건 없이, 혹은 10~20% 수준의 느슨한 필터로 측정한 결과를 그대로 자신의 tenant_id 단일 조건(통과율 1% 미만)에 적용하는 것이다. VDBBench 1.0도 이 문제를 의식해 필터 선택도 50~99.9% 구간을 별도 변수로 측정하도록 설계했다출처. 선택도가 다르면 같은 제품, 같은 인덱스에서도 결과가 전혀 다르게 나온다.

필터 선택도가 낮아지면 왜 속도와 재현율이 동시에 흔들릴까?

인덱스가 "희소한 결과 집합"을 처리하도록 설계되지 않았기 때문이다. HNSW 같은 그래프 인덱스는 전체 벡터 공간을 효율적으로 탐색하도록 최적화돼 있는데, 필터가 데이터의 99% 이상을 제외하면 그래프를 아무리 따라가도 조건에 맞는 노드가 드물게 나타나 탐색 비용이 급증한다. VDBBench 1.0은 이 구간에서 쿼리 속도가 수십~수백 배까지 흔들릴 수 있다고 보고했다출처.

같은 자료에서 Cohere 1M 데이터셋 테스트 결과, Milvus는 다양한 선택도 구간에서 상대적으로 안정적인 재현율을 유지한 반면 OpenSearch는 일부 조건에서 Recall이 0.8 미만으로 떨어진 사례가 소개됐다. 다만 이 수치는 Milvus 측이 공개한 벤치마크 소개 자료라는 점을 감안해야 한다. 같은 조건을 다른 하드웨어·버전에서 재현했을 때 동일한 격차가 나오는지는 별도로 확인할 필요가 있다.

실무에서 체감하는 문제는 "느려지는 것"보다 "결과가 줄어드는 것"이다. 전체 1%만 통과하는 tenant_id = org_42 같은 조건에서 post-filtering 구조를 쓰면, 먼저 뽑은 Top-K 중 조건에 맞는 문서가 거의 없어 반환 결과 수가 K보다 눈에 띄게 적어지거나 사실상 재현율이 무너질 수 있다출처. RAG 파이프라인에서는 이게 "검색이 느려졌다"가 아니라 "답변 근거 문서가 안 나온다"는 형태로 나타나기 때문에 원인 추적이 더 까다롭다.

같은 100M 벡터 조건에서 제품별 수치 차이는 어디서 올까?

핵심은 필터를 검색 경로 어디에 끼워 넣는지의 구조 차이다. 2025년 공개 비교표(768차원 임베딩, 필터 통과율 15~25%, 자체 호스팅)에서 나온 수치는 아래와 같다출처.

제품 p99 지연(ms) Filtered Recall@10
Qdrant 1.10 18.4 0.97
Pinecone Serverless 22.1 0.96
Milvus 2.4 24.7 0.94
Weaviate 1.26 31.2 0.95
pgvector 0.7.0 58.3 0.91

Qdrant는 payload 값과 그래프 탐색을 함께 활용해 필터 조건을 HNSW 검색 경로에 통합하는 구조가 특징으로 제시된다. 필터 카디널리티에 따라 그래프 탐색과 전체 스캔 중 하나를 선택할 수 있다는 설명이며, 50M 벡터의 강한 필터 조건에서 약 41 QPS·99% Recall을 기록했다는 수치도 함께 소개됐다. 다만 이 수치는 Qdrant 측 벤치마크 계열 자료에 의존하므로 동일 조건 재검증이 필요하다출처.

다른 2026년 공개 비교에서는 Milvus의 최악 조건 Filtered Recall이 0.984, 필터 QPS 268~732로 보고됐고, Qdrant는 0.981·153~376 QPS, Chroma는 0.979·11~19 QPS로 제시됐다출처. 숫자가 벤치마크마다 다르게 나오는 건 인덱스 종류(HNSW·IVF), ef_search·nprobe 값, 샤딩·복제 수, 하드웨어, 필터 통과율 설정이 전부 다르기 때문이다. 제품 "순위"를 외우기보다 자신의 데이터·하드웨어·필터 조건으로 같은 표를 다시 만들어보는 쪽이 안전하다.

post-filtering 구조가 품질 저하를 숨기는 이유는 뭘까?

post-filtering은 "먼저 Top-K를 찾고 나중에 거른다"는 순서 때문에 선택적인 필터에서 구조적으로 결과가 부족해질 수 있다. pgvector 비교 자료는 PostgreSQL WHERE 조건과의 SQL 통합을 장점으로 들면서도, post-filtering 구성에서는 벡터 검색 이후 조건을 적용하기 때문에 선택적인 필터에서 결과 부족 문제가 발생할 수 있다고 설명한다출처. tenant_id, 문서 상태, 접근권한처럼 모든 쿼리에 항상 붙는 조건은 "필터링이 느린가"보다 "필터링 방식이 pre-filtering인가 post-filtering인가"를 먼저 확인해야 한다.

문제는 이 구조적 한계가 평균 지연시간이나 평균 Recall 지표에는 잘 안 보인다는 점이다. 전체 쿼리의 95%가 느슨한 필터(통과율 50% 이상)이고 5%만 강한 필터(통과율 1% 미만)라면, 평균 수치는 멀쩡해 보여도 그 5% 구간에서 실제 사용자가 "검색 결과가 비어 있다"는 경험을 할 수 있다. VDBBench가 필터 복잡도·선택도·동시성을 별도 변수로 측정하도록 설계한 이유도 여기에 있다출처. 운영 중인 RAG 시스템이라면 평균값 대신 선택도 구간별 Recall과 "빈 결과율"을 별도 대시보드로 분리해 보는 편이 함정을 더 빨리 발견하게 해준다.

재현율 숫자 하나만 보면 안전하다는 건 오해다?

맞다, 재현율만으로는 동시 사용자 수를 감당할 수 있는지 알 수 없다. 2026년 공개 비교에서 최악 조건 Filtered Recall은 Weaviate와 pgvector 모두 1.00으로 동일하게 제시됐지만, 필터 QPS 범위는 Weaviate 58~861, pgvector 10~56으로 크게 벌어졌다출처. 즉 "두 제품 다 재현율은 완벽하다"는 문장만 보고 선택하면, 실제 트래픽이 몰리는 시점에 처리량 차이로 지연이 누적되는 상황을 놓칠 수 있다.

이건 벤치마크 수치를 인용할 때 흔히 생기는 오해이기도 하다. Recall과 QPS는 같은 축이 아니라서, 둘 중 하나만 보고 "이 제품이 더 낫다"고 단정하기는 어렵다. 또한 이 모든 수치는 Qdrant 1.10, Milvus 2.4, Weaviate 1.26, pgvector 0.7.0 등 특정 버전·인덱스 설정(ef_search, nprobe)·하드웨어에 종속된 값이라는 점도 함께 고려해야 한다출처. 실측표를 볼 때는 Recall, QPS, p99 지연시간을 한 세트로 읽는 습관이 필요하다.

필터링 성능 차이를 비용으로 환산하면 얼마나 벌어질까?

같은 100M 벡터 조건에서 월간 추정 비용은 pgvector 약 180달러, Qdrant 약 280달러, Milvus·Weaviate 약 310달러, Pinecone Serverless 약 650달러로 제시됐다출처. 이 추정치는 AWS 인스턴스와 관리형 서비스 구성을 가정한 값이라 실제 리전, 복제 수, 스토리지, 트래픽에 따라 달라진다는 전제가 붙어 있다.

여기서 운영 관점의 질문은 "가장 싼 걸 쓸까"가 아니라 "내 필터 조건에서 비용 대비 재현율·지연시간이 맞는가"다. 예를 들어 강한 멀티테넌시·권한 필터를 쓰는 서비스라면 pgvector의 낮은 비용이 1% 이하 선택도에서의 결과 부족 문제로 상쇄될 수 있으므로, Qdrant나 Milvus를 우선 실측 후보로 두고 빈 결과율을 먼저 확인하는 쪽이 비용 대비 안전할 수 있다출처. 반대로 운영 인력이 제한적이고 예측 가능한 p99가 더 중요한 서비스라면, 비용은 더 높아도 Pinecone Serverless 같은 관리형 서비스가 운영 부담 감소 측면에서 비교 후보가 된다. 평가표에는 p50/p95/p99 지연시간, QPS, Recall@10·Recall@50, 빈 결과율, 반환 결과 수 부족률, 메모리·스토리지 비용을 함께 넣어야 post-filtering으로 인한 품질 저하를 놓치지 않는다.

핵심 정리

  • 필터링 성능 비교는 평균 지연시간이 아니라 필터 선택도(1%·10%·50%)별로 나눠 측정해야 의미가 있다.
  • 100M 벡터·15~25% 필터 통과율 조건에서는 Qdrant 1.10이 p99 18.4ms·Recall@10 0.97, pgvector 0.7.0이 58.3ms·0.91로 제시됐지만 조건이 바뀌면 순서도 바뀔 수 있다.
  • post-filtering 구조는 선택적인 필터(통과율 1% 미만)에서 반환 결과 수 부족 문제를 구조적으로 안고 있다.
  • Recall 수치만 보면 QPS·처리량 격차를 놓친다. Weaviate·pgvector는 최악 조건 Recall이 둘 다 1.00이어도 QPS 범위는 58~861 대 10~56으로 달랐다.
  • 비용은 pgvector(약 180달러)에서 Pinecone Serverless(약 650달러)까지 벌어지므로, 선택도별 재현율·빈 결과율과 함께 비교해야 한다.