Elasticsearch 벡터 검색, RAG에 써도 될까 실험기

Q: BBQ 압축과 재채점 비율, 어떻게 잡아야 Recall이 안 깨질까?

답은 "`num_candidates`를 `k`보다 충분히 크게 잡고, 재채점 후보 수를 별도로 평가해야 한다"는 것이다.

Q: 실제 RAG 운영 사례는 어디서 확인할 수 있을까?

공개된 사례 두 건이 참고가 됐다.

Elasticsearch 벡터 검색, RAG 벡터DB로 골라도 될까?

결론부터: "항상 빠르다"는 아니다. Elasticsearch BBQ 압축은 공개된 조건(버전, 하드웨어, num_candidates)에서 인덱스 크기와 지연시간을 크게 줄였지만, 이미 Elasticsearch를 쓰고 있지 않다면 벡터 검색만 보고 고를 근거로는 약하다. BM25·필터·권한 검색을 한 시스템에서 합치고 싶을 때 도입 근거가 더 분명해진다.

이 글의 핵심

Elasticsearch 9.0 BBQ는 OpenSearch FAISS 대비 평균 지연시간 3.9배 낮고 인덱스 크기 95% 감소라는 수치가 공개됐지만, 이는 특정 하드웨어·데이터셋 조건의 단일 실험이다.
BBQ의 실질 동작은 "압축 검색 + 원본 재채점"이라, k만 보지 말고 num_candidates와 재채점 후보 수를 함께 조정해야 한다.
Recall@10은 문서 4만 건 규모에서도 98.8% 이상으로 보고됐지만, 한국어 사내 문서·다른 임베딩 모델로 일반화하면 안 된다.
bbq_hnsw, bbq_disk, vectordb_document는 메모리·디스크·운영 단순화라는 서로 다른 트레이드오프를 가진다.
버전 차이(8.x / 9.0 / 9.2)에 따라 기본 압축 방식이 달라지므로 실험 결과에 버전을 반드시 못 박아야 한다.

이번 실험에서 검증하려는 건 단순하다. "공개된 BBQ 수치를 우리 RAG 조건(임베딩 모델, 청크 수, 동시 사용자)에 그대로 적용해도 되는가"다. 수치를 그대로 믿기보다, 어떤 변수를 재측정해야 하는지 체크리스트를 만드는 게 목표였다.

BBQ 압축과 재채점 비율, 어떻게 잡아야 Recall이 안 깨질까?

답은 "num_candidates를 k보다 충분히 크게 잡고, 재채점 후보 수를 별도로 평가해야 한다"는 것이다. BBQ는 여러 차원의 임베딩을 1비트 표현으로 압축해 1차 후보를 빠르게 뽑은 뒤, 상위 일부만 원본 정밀도 벡터로 다시 계산하는 구조다. 이 재채점 단계가 생략되거나 후보 수가 너무 적으면 압축으로 인한 Recall 손실이 그대로 드러난다 출처: elastic.co/search-labs.

공개된 Recall@10 실험에서는 문서 수를 1,000건에서 4만 건까지 늘렸을 때 각각 1.000, 0.998, 0.992, 0.999, 0.992로 나타났다. 수치 자체보다 중요한 건 이 실험이 "정확 검색 대 근사 검색" 비교였고, 특정 데이터셋·특정 num_candidates 설정에서 나온 결과라는 점이다. 실제 RAG 파이프라인에서는 청크 길이, 임베딩 차원, 거리 함수가 다르면 같은 압축 설정에서도 Recall 곡선이 달라질 수 있다. 따라서 이 단계에서 기록해야 할 건 숫자 하나가 아니라 "Recall@10이 0.99 아래로 떨어지는 지점의 num_candidates 값"이다.

bbq_hnsw·bbq_disk·vectordb_document, 뭘 기준으로 나눠 써야 할까?

기준은 메모리 예산과 인덱스 준비 속도다. bbq_hnsw는 메모리 중심의 빠른 ANN 검색에 적합하고, 검색 후보를 넉넉히 뽑아 재채점하는 구성이 핵심이다. bbq_disk는 압축 벡터만 메모리에 두고 원본 정밀도 벡터는 디스크에서 읽어 재채점하는 방식이라, 대규모 데이터에서 메모리 비용은 줄지만 디스크 I/O와 캐시 적중률을 같이 측정해야 한다 출처: elastic.co/search-labs.

모드	저장 위치	주로 맞는 상황
bbq_hnsw	압축+원본 메모리	지연시간 최우선, 메모리 여유 있음
bbq_disk	압축 메모리 / 원본 디스크	대규모 문서, 메모리 비용 민감
vectordb_document	원본 bfloat16 저장	벡터 전용 인덱스 운영 단순화

vectordb_document 모드는 2026년 공개 벤치마크에서 원본 벡터를 bfloat16으로 저장해 디스크 사용량을 절반 수준으로 줄이고, bbq_hnsw 사용 시 최대 2배 QPS, bbq_disk 사용 시 인덱스 준비 시간 약 20% 단축을 보고했다 출처: elastic.co/search-labs. 다만 이는 2026년 기준 최신 기능 설명이라, Elasticsearch 8.x나 초기 9.x 운영 경험과 섞어서 판단하면 안 된다. 버전이 다르면 기본 압축 방식도 다르다는 점을 매번 다시 확인해야 했다.

사내 환경에서 재현하려면 뭘 기록해야 할까?

실험 로그에 남겨야 할 항목은 생각보다 많다. Elasticsearch 버전과 클러스터 토폴로지, 임베딩 모델명·차원·거리 함수, 문서 수·청크 수·평균 청크 길이, bbq_hnsw/bbq_disk 여부, k·num_candidates·재채점 여부, 필터 조건 유무와 선택도, 샤드·복제본 수, 노드 CPU/메모리/스토리지, 동시 사용자 수와 p50·p95·p99 지연시간, Recall@k·nDCG·답변 정확도, 그리고 임베딩 생성비·저장비·검색 클러스터 비용·LLM 호출비까지.

이 목록을 전부 채우기 전까지는 "BBQ가 3.9배 빠르다"는 문장을 우리 환경의 결론으로 쓸 수 없다. 공개 벤치마크는 동일 GCP 하드웨어, 동일 데이터셋(NQ, 250만 건) 조건에서 Elasticsearch 9.0과 OpenSearch 2.19를 비교한 것이고, 임베딩 모델과 하드웨어가 달라지면 재현 결과가 달라질 수 있다는 단서가 실험 작성자 본인에게서도 나온다 출처: LinkedIn 비교 게시물.

실제 RAG 운영 사례는 어디서 확인할 수 있을까?

공개된 사례 두 건이 참고가 됐다. 하나는 Elastic 내부 AI 어시스턴트 ElasticGPT/SmartSource로, 사내 Wiki와 ServiceNow 지식문서·뉴스 기사를 청크로 나눠 임베딩을 생성하고 Elasticsearch에 저장한 뒤, 질의 시 검색된 문맥을 Azure 호스팅 GPT-4o에 전달하는 구조다. LangChain이 RAG 오케스트레이션 계층을 맡았다. 다만 지연시간, 비용, Recall, 사용자 수 같은 운영 수치는 공개 자료에서 확인되지 않는다 출처: ZenML LLMOps 사례.

다른 하나는 Red Hat OpenShift AI의 'AI Generation with LLM and RAG' Validated Pattern으로, Elasticsearch가 공식 지원 벡터DB로 포함됐다. 배포 흐름은 Operator 설치, 벡터 검색 클러스터 생성, 임베딩 적재, RAG 애플리케이션 연결, 질의 시 문맥 검색 순이다. 이 자료는 배포·통합 패턴을 검증한 것이지, 다른 벡터DB와의 정량 성능 비교 자료는 아니라는 점을 분명히 해둬야 했다.

이 벤치마크들이 못 보여주는 건 뭘까?

여기서 막힌다. 공개 수치는 모두 Elastic이 설계한 설정과 데이터셋 기준이고, 한국어 임베딩 모델이나 사내 특화 질의에 대한 Recall, 동시 사용자 100명 이상에서의 p99 지연시간, 필터가 섞인 하이브리드 검색의 성능은 어느 자료에도 없었다. BBQ 수치도 Qdrant·Milvus와의 "동일 임베딩·동일 하드웨어·동일 Recall 목표" 재측정이 아니라 OpenSearch와의 1:1 비교였다는 점도 짚어야 한다. 즉 "Elasticsearch가 다른 벡터DB보다 전반적으로 빠르다"는 결론은 이 자료만으로는 내릴 수 없다.

또 하나는 버전 혼동 위험이다. BBQ가 기본값이 되는 시점(9.2)과 그 이전 버전의 결과를 섞어 인용하면 재현 불가능한 비교가 된다. 실험 로그에 버전을 명시하지 않은 글은, 그게 설령 공식 블로그라도 그대로 인용하지 않는 편이 안전했다.

그래서 결론은 뭘까?

이번 실험으로 확인한 건 "Elasticsearch 벡터 검색이 좋다/나쁘다"가 아니라 판단 순서다. 이미 Elasticsearch로 로그·문서·키워드 검색을 돌리고 있다면, 벡터·BM25·필터·권한을 한 클러스터에서 합칠 수 있다는 점이 가장 현실적인 도입 근거였다. 반대로 벡터 검색만 필요한 신규 시스템이라면 공개된 BBQ 수치를 그대로 믿지 말고, 같은 임베딩·같은 하드웨어·같은 Recall 목표로 다른 벡터DB와 직접 재측정하는 과정이 필요했다. 다음 실험에서는 bbq_disk의 디스크 I/O 캐시 적중률을 실제 사내 문서 규모로 측정해볼 예정이다.

핵심 정리

Elasticsearch BBQ의 지연시간·인덱스 크기 수치는 특정 하드웨어·버전·데이터셋 기준이며, 다른 조건에서 그대로 재현된다고 보장되지 않는다.
Recall@10은 num_candidates와 재채점 후보 수에 좌우되므로 k만 고정하고 비교하면 의미가 없다.
bbq_hnsw는 지연시간, bbq_disk는 메모리 비용, vectordb_document는 운영 단순화라는 서로 다른 목적을 가진다.
ElasticGPT, Red Hat Validated Pattern 모두 배포·통합 사례이지 정량 성능 비교 자료는 아니다.
신규 벡터 검색 전용 시스템이라면 Elasticsearch 수치를 그대로 쓰지 말고 동일 조건에서 다른 벡터DB와 재측정하는 과정이 필요하다.