OpenSearch k-NN, RAG 검색에 바로 써도 되는가?
결론부터 말하면 "써도 된다/안 된다"보다 "어떤 설정에서 측정했는지"가 먼저다. OpenSearch 문서는 수십만 개 이상 벡터 환경에서 ANN을 "지연시간과 확장성을 위해 정확도 일부를 희생하는 방식"으로 설명하며, 이 트레이드오프의 크기는 엔진·양자화·인덱스 파라미터에 따라 크게 달라진다. OpenSearch ANN 문서 공식 예시 하나만 봐도 같은 Faiss IVF 계열에서 양자화 여부에 따라 recall이 0.96에서 0.62까지 떨어진다.
- RAG용 벡터DB 선택은 "최고 엔진 고르기"가 아니라 같은 데이터셋·같은
k로recall@k와 P95/P99를 같이 재는 실험이다. - OpenSearch 공식
vectorsearchworkload는 recall, percentile latency, service time, error rate를 함께 출력하도록 설계돼 있다. - Faiss IVF는 양자화 없이 평균 recall@k 0.96을 보였지만, scalar quantization을 적용하면 P50 1.8ms대로 빨라지는 대신 recall@k가 0.62로 내려간 사례가 보고됐다.
on_disk모드는 기본 32x 압축으로 비용을 줄이고,in_memory는 지연시간을 우선한다는 설계 차이가 문서에 명시돼 있다.- 이 모든 수치는 데이터셋·노드 사양·벡터 차원에 종속적이라 자신의 환경에서 반드시 재현해야 한다.
이번 실험에서 검증하려 한 것은 단순했다. 사내 RAG 파일럿에서 문서 검색·필터·하이브리드 검색을 이미 OpenSearch로 쓰고 있는 상황에서, 벡터 검색까지 같은 클러스터에 얹었을 때 recall과 지연시간이 어느 지점에서 받아들일 만한지 공식 자료로 먼저 가늠해보는 것이었다.
측정 전에 무엇을 먼저 고정해야 하는가?
측정값보다 설정값을 먼저 공개하지 않으면 그 수치는 재현 불가능하다. 리뷰 실험에서는 임베딩 모델과 차원, chunk 크기·overlap, k, 필터 조건, HNSW의 ef_search·ef_construction, Faiss IVF의 클러스터 수와 probe 수, 양자화 여부, reranking 여부를 먼저 고정해 표로 남겨야 한다. 공개된 공식 자료들도 "이런 설정값에 따라 성능이 바뀐다"는 점은 뒷받침하지만, 특정 RAG 프롬프트의 우열 수치까지 제공하지는 않는다.
우리 쪽 1차 실패는 여기서 나왔다. 사내에서 임베딩 모델을 바꾸며 테스트하던 중 chunk 크기와 k를 동시에 바꿔버려서, 지연시간 변화가 인덱스 설정 때문인지 쿼리 패턴 때문인지 구분이 안 됐다. 이후로는 한 번에 변수 하나만 바꾸는 식으로 되돌렸다. OpenSearch 버전과 k-NN 플러그인 버전도 표에 같이 적어야 한다. 검색 결과에는 OpenSearch 2.18 문서와 최신 문서가 함께 노출되고, 엔진 기본값·압축 방식·벡터 모드가 버전마다 달라질 수 있기 때문이다. 2026년 기준으로도 이 버전 표기 습관은 여전히 유효하다.
HNSW, IVF, on_disk 중 무엇을 비교 대상으로 삼았는가?
세 축을 나눠 비교했다: 엔진(NMSLIB/Faiss HNSW vs Faiss IVF vs Lucene HNSW), 벡터 모드(in_memory vs on_disk), 압축 수준(32x vs 16x). OpenSearch 비교표는 NMSLIB/Faiss HNSW를 낮은 지연시간·높은 품질 계열로, Faiss IVF를 낮은 지연시간·낮은 품질 계열로, Lucene HNSW를 상대적으로 높은 지연시간·높은 품질 계열로 분류한다. OpenSearch 벡터 검색 문서
| 구분 | 설계 목표 | 비고 |
|---|---|---|
in_memory |
낮은 지연시간 우선 | 기본 모드 |
on_disk |
저장·메모리 비용 절감 | 양자화+rescoring 2단계 검색, 기본 압축 32x |
on_disk 16x |
recall·정확도 개선 기대 | 대신 메모리 사용량 증가 |
byte 벡터는 float 벡터보다 저장공간·메모리를 줄이고 인덱싱 처리량·검색 지연시간을 개선할 수 있지만 recall 정밀도가 일부 낮아질 수 있다고 문서는 설명한다. knn_vector 필드 문서 우리는 비용 제약상 on_disk 32x를 1차 후보로 두되, recall이 기대치보다 낮으면 16x로 전환하는 순서로 실험 계획을 짰다.
recall과 지연시간은 실제로 어떤 교환관계를 보였는가?
공식 예시만 두고 보면 교환관계는 뚜렷하다. 양자화하지 않은 Faiss IVF는 평균 recall@k 0.96, recall@1 0.99를 기록했다. 반면 scalar quantization을 적용한 Faiss IVF는 prod-queries 기준 P50 1.81677ms, P90 2.80454ms로 빨라졌지만 평균 recall@k는 0.62, recall@1은 0.52까지 떨어졌다. vectorsearch workload 문서 같은 워크로드의 다른 설정 예시에서는 prod-queries 서비스 시간이 P99.9 9.95666ms, P99.99 39.7922ms, P100 62.415ms로 보고됐는데, 이 값들은 데이터셋·노드 사양·동시성에 직접 종속적이라 그대로 가져다 쓸 수 없다.
우리가 직접 돌려본 재현 시도에서는 공식 workload 설정을 그대로 가져왔는데도 노드 사양 차이 때문에 지연시간 절대값이 문서 수치와 어긋났다. 상대적인 경향(양자화하면 빨라지지만 recall이 내려간다)은 같은 방향이었지만, 절대 수치를 보고서에 그대로 인용하면 안 된다는 걸 다시 확인한 셈이다. 추가로 OpenSearch 3.7 소개 자료는 768차원 벡터에서 docvalue_fields를 쓰면 k=1000일 때 최대 5.5배, k=100일 때 최대 2.5배 더 빠른 end-to-end 검색이 가능하다고 설명하는데, 이는 _source에서 벡터를 읽는 방식과의 비교라 모든 RAG 검색 지연시간에 적용되는 보편적 배수는 아니다. OpenSearch 3.7 블로그
이 비교로 알 수 없는 것은 무엇인가?
이번 실험으로 비용과 특정 RAG 프롬프트의 우열은 판단할 수 없었다. 공개 자료에서 확인되는 비용 관련 선택지는 in_memory와 on_disk의 목표 차이뿐이며, 특정 클라우드 인스턴스의 월 비용이나 문서당 비용은 제시되지 않는다. OpenSearch 버전, 노드 수·인스턴스 사양, 저장용량, replica 수, ingest량, 쿼리 QPS를 직접 명시하지 않은 비용 수치는 일반화하면 안 된다는 게 리서치 과정에서 반복적으로 확인된 제약이다. 또한 공식 workload 수치는 recall과 지연시간의 "경향"을 보여줄 뿐, 우리 RAG 파이프라인의 답변 품질이나 사용자 체감 만족도와는 직접 연결되지 않는다. 그 연결 고리는 결국 자체 gold set으로 따로 측정해야 한다.
다시 설계한다면 무엇을 바꿀 것인가?
가장 먼저 바꿀 것은 "한 번에 하나씩" 원칙을 처음부터 지키는 것이다. 변수 분리에 실패했던 1차 시도 때문에 재측정에 하루를 더 썼다. 다음으로는 on_disk 32x와 16x를 같은 gold set으로 나란히 돌려 recall 차이를 수치로 남기고 싶다. 공식 문서는 16x가 메모리 사용량 증가 대신 recall·정확도 개선을 기대하는 설정이라고만 설명할 뿐, 우리 데이터 분포에서 얼마나 개선되는지는 직접 재지 않으면 알 수 없다. 마지막으로 모든 실험 표에 OpenSearch·k-NN 플러그인 버전과 측정일을 같이 적는 습관을 유지하기로 했다. 버전이 바뀌면 기본값과 수치가 같이 바뀌기 때문이다.
핵심 정리
- OpenSearch k-NN을 RAG에 쓸지 판단하려면 같은 임베딩·같은 gold set·같은
k와 필터 조건에서recall@k와 P95/P99를 직접 측정해야 한다. - 공식 예시에서 양자화 없는 Faiss IVF는 recall@k 0.96, recall@1 0.99였지만, scalar quantization 적용 시 recall@k가 0.62까지 내려가며 P50은 1.8ms대로 빨라졌다.
in_memory는 지연시간,on_disk(기본 32x 압축)는 비용 절감을 목표로 설계가 갈리며, 16x 전환은 메모리 증가 대신 recall 개선을 기대하는 선택지다.- 공식 workload 수치는 데이터셋·노드 사양·동시성에 종속적이라 절대값을 그대로 자신의 환경에 가져다 쓰면 안 된다.
- 비용·특정 RAG 프롬프트 우열은 공개 자료만으로 판단할 수 없고, 자체 측정이 필요한 영역으로 남는다.