Selecting a vector store for Amazon Bedrock Knowledge Bases

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon Bedrock Knowledge Bases의 고객 관리형 벡터 저장소는 검색 요구와 비용에 따라 선택해야 하며, 원문은 상품 검색에 적합한 Amazon OpenSearch Serverless의 최적화 방식과 벤치마크 설계를 설명하지만 측정 결과는 제공된 본문에 포함되지 않는다.

📌 핵심 요약

• Amazon Bedrock Knowledge Bases의 고객 관리형 구성은 Amazon OpenSearch Service, Amazon Aurora PostgreSQL with pgvector, Amazon S3 Vectors를 지원하며, 벡터 저장소 선택은 RAG의 성능과 비용에 영향을 준다.
• Amazon OpenSearch Service는 고속 검색과 하이브리드 검색을, Amazon Aurora PostgreSQL with pgvector는 관계형 데이터베이스와 벡터 검색의 결합을 제공한다. Amazon S3 Vectors는 1초 미만의 유사도 검색과 기존 벡터 데이터베이스 대비 최대 90%의 벡터 저장 비용 절감을 제공한다고 소개된다.
• 상품 카탈로그 검색에는 의미 검색과 키워드 검색, 복잡한 필터링·집계, 낮은 밀리초 단위 지연 시간을 지원하는 Amazon OpenSearch Serverless가 적합하다고 설명한다. 벤치마크 대상은 Classic 컬렉션이며, 2026년 5월 정식 출시된 NextGen 컬렉션은 원문 작성 시점에 Amazon Bedrock Knowledge Bases Retrieve API와 아직 호환되지 않는다.
• Amazon Titan Text Embedding v2의 1024·512·256차원, float·binary 자료형, on_disk 모드는 검색 품질·메모리·비용·지연 시간 간 절충을 만든다. on_disk는 float만 지원하며 내부적으로 32배 이진 양자화를 적용하고 디스크의 원래 정밀도 벡터로 재점수화하므로 binary 임베딩과 결합할 수 없다.
• 벤치마크는 ESCI의 미국 상품 1,215,851개 전체를 색인하고 5,000개 질의를 표본 추출해 7개 구성을 비교하도록 설계됐다. 평가 항목은 NDCG@10, 동시성 1·10에서의 p50·p95·p99 지연 시간, ANN 인메모리 크기이며, 제공된 본문은 평가 방법 설명 중 끊겨 실제 비교 결과는 확인할 수 없다.

🧩 주요 포인트

1. 세 백엔드는 검색 기능·관계형 데이터 결합·저장 비용이라는 서로 다른 강점을 제시하므로, 벡터 저장소 선택은 용도별 요구를 기준으로 판단해야 한다.
2. Classic과 NextGen의 기능·호환성 차이 때문에 Classic 벤치마크를 다른 배포 방식에 그대로 적용하기 어렵고, 상품 검색 적합성도 실제 검색 요구와 함께 해석해야 한다.
3. 차원·자료형·on_disk 변경은 품질과 자원 사용에 함께 영향을 주므로 NDCG@10·지연 시간·ANN 인메모리 크기를 함께 평가해야 하며, 측정 결과가 없는 현재 본문만으로 최적 구성을 확정할 수 없다.

🧠 상세 정리

1. 선택 범위와 RAG에서 벡터 저장소의 역할

Amazon Bedrock Knowledge Bases는 완전 관리형 선택지와 사용자가 벡터 저장소를 직접 선택하는 고객 관리형 선택지를 제공하며, 원문은 후자를 다룬다. RAG에서는 수집한 문서를 청크로 나누고 임베딩으로 변환해 저장한 뒤, 사용자 질의도 임베딩으로 변환하여 의미가 가까운 청크를 찾는다. 검색된 상위 n개 청크를 원래 질의와 함께 LLM에 전달하며, 원문은 상위 5개를 가져오는 경우를 예로 든다. 벡터 검색은 단어의 일치보다 의미의 유사성을 포착하는 데 유리하고, 검색 결과는 모델이 더 정확하고 맥락에 맞는 응답을 생성하도록 돕는다. 이 과정에서 벡터 인덱스는 고차원 임베딩의 효율적인 검색을 지원하므로, 저장소 선택은 단순한 보관 방식이 아니라 RAG의 응답 성능과 비용을 좌우하는 요소가 된다.

2. 세 가지 고객 관리형 백엔드의 특성

원문이 비교 대상으로 제시한 백엔드는 Amazon OpenSearch Service, Amazon Aurora PostgreSQL with pgvector, Amazon S3 Vectors다. Amazon OpenSearch Service는 메모리에 보관한 데이터를 통한 고속 검색과 고차원 벡터를 지원하고, k-NN 검색 및 어휘 검색과 벡터 검색을 결합하는 하이브리드 검색을 제공한다. Amazon Bedrock Knowledge Bases에서는 OpenSearch의 Managed Clusters와 Serverless를 모두 벡터 저장소로 사용할 수 있다. Amazon Aurora PostgreSQL with pgvector는 관계형 데이터베이스 기능에 벡터 유사도 검색을 결합하며, IVFFlat·HNSW 인덱스, L2·코사인·내적 거리 척도, 단정밀도 기준 최대 2,000차원 벡터를 지원한다. Amazon S3 Vectors는 네이티브 벡터 지원을 갖춘 객체 스토리지 기능으로 소개되며, 대규모 임베딩의 경제적인 저장·질의, 1초 미만 검색, 기존 벡터 데이터베이스 대비 최대 90%의 벡터 저장 비용 절감을 제시한다.

3. 상품 카탈로그 검색에서 OpenSearch를 권하는 이유

전자상거래 상품 검색은 수천 개의 상품 가운데 고객이 원하는 것을 찾아야 하며, 자연어 질의를 이해하면서 쇼핑 성수기에는 수천 개의 동시 질의에도 낮은 지연 시간을 유지해야 한다. 원문은 이러한 요구에 Amazon OpenSearch Serverless가 적합하다고 설명하며, 의미 이해와 기존 키워드 일치를 결합하는 하이브리드 검색을 주요 근거로 제시한다. 벡터 검색 지연 시간은 낮은 밀리초 단위라고 소개하지만, 제공된 본문에는 이를 상세하게 비교할 실제 측정 결과가 포함되지 않는다. 또한 복잡한 필터링과 집계를 기본 지원하므로 가격·브랜드·색상 같은 조건으로 상품을 좁히는 탐색 기능을 구현하는 데 유용하다고 설명한다. 코사인 유사도나 유클리드 거리 등 여러 거리 척도를 선택할 수 있어, 상품 유사도를 계산하는 방식을 요구에 맞게 조정할 수 있다는 점도 장점으로 제시한다.

4. Classic·NextGen·Managed Clusters의 적용 범위

이 글의 벤치마크는 Amazon OpenSearch Serverless Classic 컬렉션에서 수행되었으므로, 결과를 해석할 때 배포 방식의 차이를 구분해야 한다. 원문에 따르면 2026년 5월 정식 출시된 NextGen 컬렉션은 원문 작성 시점에 Amazon Bedrock Knowledge Bases Retrieve API와 아직 호환되지 않는다. NextGen은 인덱스 매핑에서 engine과 mode 매개변수를 제거해 생성을 단순화하고, 기본 32배 압축과 GPU 가속 인덱스 구축, scale-to-zero를 지원한다. 반면 본문의 Classic 실험에서는 engine, mode, HNSW 매개변수를 명시적으로 설정한다. Managed Clusters에는 auto-optimize, GPU 가속 인덱싱, 인스턴스 크기 설정 같은 추가 조정 선택지가 있으며, 원문은 이러한 차이로 다른 결과가 나올 수 있음을 명시한다.

5. 임베딩 차원과 자료형을 통한 비용 조정

OpenSearch의 설정은 벡터 인덱스 성능에 큰 영향을 줄 수 있으며, 원문은 특히 비용과 인덱스 크기를 줄이는 선택지를 살펴본다. 임베딩 벡터가 커지면 일반적으로 더 많은 의미 정보를 담을 수 있지만, 메모리 사용량과 인덱스 크기, 비용도 증가한다. Amazon Titan Text Embedding v2는 1024·512·256차원 임베딩을 제공하므로, 특정 사용 사례에서 차원별 검색 성능과 비용 영향을 직접 측정하는 방식이 권장된다. binary 임베딩처럼 정밀도가 낮은 자료형을 사용하면 벡터 인덱스 크기를 크게 줄일 수 있지만, 크기 절감만으로 검색 품질까지 보장되는 것은 아니다. 원문은 차원과 자료형의 변경이 임베딩 공간 자체를 바꾸므로, 자체 관련성 데이터를 기준으로 평가해야 한다고 강조하며 모델의 리전별 제공 여부는 별도 안내를 참조하도록 한다.

6. on_disk와 인덱스 자동 최적화의 절충

Classic 컬렉션의 on_disk 모드는 내부적으로 32배 이진 양자화를 적용하고, 디스크에서 읽은 원래 정밀도의 벡터로 재점수화하는 디스크 기반 벡터 검색 방식이다. 원문은 이 방식이 검색 품질을 유지하면서 인메모리 사용량을 줄이지만, 지연 시간이 늘어나는 대가가 있다고 설명한다. on_disk는 float 자료형을 요구하므로 binary 임베딩과 결합할 수 없으며, 1024차원 binary on_disk 구성도 유효하지 않다. HNSW의 ef_construction과 m은 인덱스 구축 시간·메모리·검색 정확도 사이의 균형을 조정하고, Classic에서는 메모리 절감을 위한 Faiss 16비트 스칼라 양자화도 사용할 수 있다. 차원과 자료형을 선택한 뒤에는 Faiss 엔진을 사용하는 Serverless와 Managed Clusters의 auto-optimize가 재현율과 지연 시간 기준으로 구성을 평가하여, 한 시간 미만에 나머지 HNSW·양자화 설정 조정을 자동화할 수 있다고 소개한다.

7. ESCI 데이터와 비교할 일곱 가지 구성

실험에는 Amazon의 Shopping Queries Data Set인 ESCI를 사용하며, 데이터에는 고유한 미국 상품 1,215,851개와 관련성이 평가된 질의 97,345개가 포함된다. 상품 정보는 제목·설명·주요 특징·브랜드로 구성되고 길이의 중앙값은 약 1,140자이며, 관련성은 Exact 3점, Substitute 2점, Complement 1점, Irrelevant 0점으로 구분된다. 원문은 창이 없는 자동 접착 봉투를 찾는 질의에 대해 창이 없는 상품과 이중 창이 있는 상품을 대비하여 관련성 판단을 보여준다. 벤치마크는 질의 5,000개를 표본 추출하고 전체 상품을 색인하며, 표본 질의당 평가된 상품은 약 19개, 관련 상품은 약 17개다. 비교 구성은 1024·512·256차원과 float·binary의 조합 6개에 1024차원 float on_disk 구성 하나를 더한 총 7개이며, 기준 구성은 1024차원 float 인메모리 방식이다.

8. 평가 절차와 제공된 본문의 한계

모든 실험 인덱스는 FAISS와 HNSW를 사용하고 ef_construction은 128, m은 24로 고정하며, float에는 l2 거리, binary에는 hamming 거리를 적용한다. 각 구성은 컬렉션에 단독으로 생성해 전체 상품을 적재하고 병합이 안정되기를 기다린 다음, 지연 시간이 안정될 때까지 적응형 워밍업을 수행하고 측정 후 삭제하며 다음 구성 전에 15분의 대기 시간을 둔다. 평가 항목은 NDCG@10 검색 품질, 동시성 1과 10에서의 p50·p95·p99 지연 시간, ANN 인메모리 크기이고, 지연 시간 측정은 질의 1,000개를 3회 반복하는 방식이다. 구성 순서는 자료형·차원과 실행 시간의 상관을 줄이도록 교차 배치하며, 주 벤치마크는 k-NN만 사용하는 의미 검색이고 하이브리드 검색은 별도로 평가한다고 설명한다. 다만 제공된 본문은 하이브리드 검색 설명 도중 끊기므로, 예고된 나머지 두 사용 사례와 실제 결과 표를 확인할 수 없으며 어느 구성이 최선인지 결론을 내릴 근거도 부족하다.

🧾 핵심 주장 / 시사점

• 상품 검색에서 OpenSearch의 적합성은 벡터 검색 속도뿐 아니라 키워드 결합, 필터링, 집계가 함께 필요한 요구에서 나온다.
• binary 임베딩과 on_disk의 내부 이진 양자화는 구분해야 한다. 두 방식 모두 메모리를 줄일 수 있지만, on_disk는 float 원본을 이용한 재점수화를 포함하며 binary 임베딩과 결합할 수 없다.
• 실험은 데이터·구성·측정 절차를 구체적으로 제시하지만 결과가 누락되어 있으므로, 비용 절감 설정의 실제 품질 손실이나 지연 시간 증가 폭을 이 본문만으로 판단할 수 없다.

✅ 액션 아이템

• 검색 기능·관계형 데이터 결합·저장 비용 요구를 기준으로 Amazon OpenSearch Service, Amazon Aurora PostgreSQL with pgvector, Amazon S3 Vectors의 적합성 비교.
• Amazon Bedrock Knowledge Bases Retrieve API 연동을 전제로 Classic과 NextGen의 호환성 및 벤치마크 적용 범위 확인.
• 차원·자료형·on_disk 구성별 NDCG@10·지연 시간·ANN 인메모리 크기의 측정 결과를 확보한 뒤 최적 구성 판단.

❓ 열린 질문

• 대상 RAG에서 검색 기능·관계형 데이터 결합·저장 비용 중 벡터 저장소 선택을 좌우하는 요구는 무엇인가?
• Amazon Bedrock Knowledge Bases Retrieve API와 NextGen의 호환성 제약은 상품 검색의 배포 방식 선택에 어떤 영향을 주는가?
• 7개 구성의 NDCG@10·지연 시간·ANN 인메모리 크기 측정 결과에서 품질과 비용의 절충은 어떻게 나타나는가?