RAG를 위한 저장소/DBMS Azure 서비스 선택

1. 서론

RAG(Retrieval-Augmented Generation) 아키텍처에서 가장 중요한 요소 중 하나는 “정보를 어디에, 어떻게 저장하고 검색할 것인가”입니다. 단순한 데이터 보관을 넘어, 벡터 검색 · meta data · 필터링 · 검색 품질 최적화까지 고려해야 합니다. Azure는 이를 위해 다양한 선택지를 제공하며, 각 서비스는 특징과 적합한 시나리오가 다릅니다.

 

2. 본론

(1) Azure AI Search

• 특징: 하이브리드 검색(키워드+벡터), Reciprocal Rank Fusion(RRF), Semantic ranker 지원.
• 적합 시나리오: “검색 품질+운영 편의”가 최우선일 때.
• 장점: Blob/ADLS 등에서 문서를 직접 인덱싱 가능, 관리형 서비스.

(2) Azure Cosmos DB

• 특징: 벡터 필드를 문서/레코드와 함께 저장 가능, 글로벌 분산, 낮은 지연.
• 적합 시나리오: 트랜잭션 데이터베이스와 벡터 검색을 통합하고 싶을 때.
• 장점: MongoDB vCore/NoSQL 모두 벡터 검색 지원.

(3) Azure Database for PostgreSQL (pgvector)

• 특징: pgvector 확장을 통한 HNSW/IVF 인덱스, SQL 기반 운영.
• 적합 시나리오: 오픈소스 생태계 활용, SQL 친화 환경에서 자유롭게 벡터 검색을 통제하고 싶을 때.

(4) Azure Cache for Redis (Enterprise)

• 특징: 인메모리 벡터 검색, 초저지연 응답.
• 적합 시나리오: 세션 캐시, 피드 재랭킹, 실시간 추천 등 고QPS 환경.
• 장점: 주 스토어 앞단 캐싱/가속 계층으로 사용.
• 주의 : 벡터 검색은 Basic/Standard 에서 사용 불가. Premium 혹은 Enterpise 만 가능

(5) Azure SQL Database (벡터 기능)

• 특징: SQL 환경 그대로 벡터 저장 및 유사도 검색 제공(미리보기/지역 한정 기능).
• 적합 시나리오: 기존 SQL 생태계 변경 없이 최소한의 수정으로 RAG 통합.

3. 결론

• 검색 품질 최우선: Azure AI Search → 기본 선택
• 데이터베이스 일원화: Cosmos DB → 문서+벡터 통합
• SQL 친화적·자유도: PostgreSQL(pgvector) → 세밀한 컨트롤
• 극저지연 요구: Redis → 캐시형 보조 레이어
• 레거시 SQL 유지: Azure SQL 벡터 기능
• 즉, 단일 정답은 없으며, RAG의 목적(검색 품질, 데이터 통합, 성능 요구)에 따라 적합한 서비스를 조합하는 것이 가장 효과적

4. 참고 자료

• Azure AI Search — Hybrid + Semantic Search 개요 https://learn.microsoft.com/en-us/azure/search/hybrid-search-overview
• Azure Cosmos DB — 벡터 검색 공식 가이드 https://learn.microsoft.com/en-us/azure/cosmos-db/vector-search
• Azure Cache for Redis — 벡터 검색 개요 https://learn.microsoft.com/en-us/azure/redis/overview-vector-similarity
• Azure Database for PostgreSQL — pgvector 사용 가이드  https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/how-to-use-pgvector?utm_source=chatgpt.com
• https://medium.com/@testerest901/rag%EB%A5%BC-%EC%9C%84%ED%95%9C-%EC%A0%80%EC%9E%A5%EC%86%8C-dbms-azure-%EC%84%9C%EB%B9%84%EC%8A%A4-%EC%84%A0%ED%83%9D-59ea035ff802