[Azure] RAG(비정형 데이터)를 위한 저장소

1. RAG(Retrieval-Augmented Generation)의 특성

• 비정형 데이터: 문서, 대화 로그, PDF, JSON, 이미지 메타데이터 등 → 전통적인 RDBMS보다는 스키마 유연성이 중요
• 검색 최적화: 벡터 검색(embedding), Full-text 검색 필요
• 확장성: 대량 데이터 처리 가능해야 함 (수평 확장)
• Latency 고려: 실시간 질의/응답에 빠른 검색 필요

2. Azure DBMS 후보 비교

서비스 특징 (Azure Docs 근거) 장점 단점/제약 RAG 적합성

서비스	특징	장점	단점/제약	RAG 적합성
Azure Cosmos DB (NoSQL)	- JSON 기반 문서 저장 - 벡터 검색 지원 (DiskANN, HNSW, IVF)【Azure Docs】 - Azure OpenAI와 통합 가능 - 글로벌 분산, 낮은 지연시간	- 완전 관리형, 자동 확장 - 원본 데이터+벡터 함께 저장 가능 - 멀티리전 분산	- SQL 기반 질의에는 한계 - 비용이 PostgreSQL 대비 높을 수 있음	✅ RAG 최적 (추천)
Azure Database for PostgreSQL (pgvector)	- pgvector 확장으로 벡터 생성·저장·검색 지원【Azure Docs】 - SQL 친화적 환경 - Flexible Server에서 사용 가능	- 기존 RDBMS 익숙한 팀에 유리 - 구조적+비정형 혼합 처리 가능 - 오픈소스 생태계 활용 가능	- Cosmos DB 대비 확장성/글로벌 분산 제한 - 벡터 검색 성능은 튜닝 필요	✅ SQL 친화 RAG (대안)
Azure Cognitive Search (검색엔진)	- PDF/Word/HTML 등 인덱싱 지원 - 벡터+Full-text 검색, semantic ranking【Azure Docs】 - Cosmos DB, Blob, SQL과 연동	- 강력한 검색/랭킹 - 비정형 문서 색인 자동화	- DBMS 아님 (저장소는 별도 필요)	⚠️ 보조 계층 (DB와 함께 사용)
Azure Blob Storage	- 원본 문서 저장소 역할 - Cognitive Search와 연동	- 저렴하고 확장성 우수 - 모든 비정형 데이터 저장 가능	- 벡터/검색 불가 (별도 DB 필요)	⚠️ 원본 저장소
Azure SQL Database	- 전통 RDBMS - 벡터 검색 미지원	- 관리형 SQL 환경	- 비정형 데이터/RAG에는 부적합	❌ 부적합

 

A사는 Azure에서 RAG(Retrieval-Augmented Generation) 아키텍처를 구축하려고 한다.

비정형 텍스트 데이터를 벡터로 변환하여 저장하고, SQL 기반 질의 환경에서 기존 데이터와 함께 활용하려 한다.
이때 가장 적합한 Azure Database 서비스는 무엇인가?

① Azure SQL Database
② Azure Database for PostgreSQL Flexible Server (pgvector)
③ Azure Cosmos DB for NoSQL
④ Azure Cognitive Search

정답: ②
해설:

• Cosmos DB도 벡터 검색을 지원하지만, SQL 기반 질의 환경과 기존 구조적 데이터와의 조합이 필요하다면 PostgreSQL + pgvector가 적합.
• Cognitive Search는 저장소가 아니라 검색 전용 엔진.
• Azure SQL Database는 벡터 검색 미지원.

 

---

🔎 RAG (Retrieval-Augmented Generation)

1. 정의

• RAG = Retrieval-Augmented Generation
• LLM(대규모 언어 모델)의 한계를 보완하기 위한 아키텍처 패턴
  • LLM 자체 지식 한계: 학습 시점 이후의 최신 데이터, 도메인 전용 데이터(사내 문서 등)를 알지 못함
  • 해결 방법: 모델이 응답을 생성하기 전에 외부 지식 저장소에서 데이터를 검색(Retrieval) → 검색된 데이터를 LLM 입력 프롬프트에 추가(Augmentation) → 더 정확한 답변 생성(Generation)

2. 동작 흐름

1. 사용자가 질의(Query)를 입력
2. 질의를 벡터화(Embedding)
3. 벡터 DB(예: Cosmos DB, PostgreSQL + pgvector, Pinecone 등)에서 질의 벡터와 가장 유사한 문서 검색
4. 검색된 문서 내용을 LLM 입력에 포함시킴
5. LLM이 문맥을 반영해 최종 답변 생성

---

🔎 벡터(Vector)란?

1. 기본 개념

• 벡터 = 숫자의 배열(리스트)
• 예: [0.12, -0.85, 0.33, ...]
• 자연어, 이미지 같은 비정형 데이터를 수학적 형태로 표현한 것

2. 왜 필요한가?

• LLM은 문자열 자체를 이해하지 못하고, 벡터 공간에서 **유사도(거리)**를 계산함
• 비슷한 의미의 문장은 벡터 공간에서 가까이 위치
  • 예:
    • "Azure VM 만드는 방법" ↔ "Azure에서 가상머신 배포하기"
    • 두 문장은 단어가 달라도 의미적 유사성이 크므로 벡터 공간에서 가까움

3. 유사도 검색

• 벡터 간 코사인 유사도(Cosine Similarity), 유클리드 거리(Euclidean Distance) 등을 계산해 가장 가까운 문서 검색
• 이것이 RAG에서 외부 지식 검색의 핵심

---

📌 정리

• RAG: LLM이 외부 지식(DB/문서 등)을 검색해 응답 품질을 높이는 아키텍처
• 벡터: 문장/문서/이미지를 수학적 숫자 배열로 표현한 것 → 유사도 계산에 활용
• 시험 포인트:
  • RAG는 "외부 검색 + LLM 조합"
  • 벡터는 "텍스트를 의미 기반으로 표현하는 방식"

---

🔹 Cosmos DB (벡터 검색)

• Azure Cosmos DB 벡터 데이터베이스 개요
• Cosmos DB NoSQL – 벡터 검색 사용법

🔹 PostgreSQL + pgvector

• Azure Database for PostgreSQL – pgvector 확장 사용법
• Azure Database for PostgreSQL 개요

🔹 Cognitive Search (검색엔진)

• Azure AI Search(구 Cognitive Search) 개요
• 벡터 검색 – Azure AI Search

🔹 Blob Storage (원본 데이터 저장소)

• Azure Blob Storage 개요

 

• Cosmos DB → NoSQL + 벡터 검색(자동 확장/글로벌 분산)
• PostgreSQL(pgvector) → SQL 기반 워크로드 + AI 벡터 검색
• Cognitive Search → 문서 색인/검색 전용 (DB는 아님)
• Blob Storage → 원본 데이터 저장소