# Notion API를 이용한 RAG 구축: 현재 방식 vs 고도화(Vector) 방식

현재 구축된 챗봇은 **"검색 기반(Search-Based) RAG"**입니다. Notion의 실시간 검색 기능을 활용해 가볍고 빠르게 구축한 버전입니다.
질문하신 대로, 더 높은 정확도와 의미 기반 검색이 가능한 **"임베딩(Vector) 기반 RAG"**(=순수 RAG)를 구축하려면 훨씬 더 복잡한 파이프라인이 필요합니다.

---

## 1. 현재 방식: Search-Based RAG (Live Search)
Notion이 제공하는 '검색 창' 기능을 API로 대신 누르는 것과 같습니다.

### 구조
1. **User**: "오타 수정 기능 있어?"
2. **AI (Keyword Gen)**: 질문을 Notion 검색어로 변경 -> "오타 수정"
3. **Notion API**: 해당 단어가 포함된 제목/본문을 찾아서 리턴
4. **AI (Answer)**: 찾은 내용을 읽고 답변 생성

> **장점**: 
> - 구축이 매우 빠름 (별도 DB 필요 없음).
> - Notion에서 수정하면 즉시 반영됨 (실시간).
>
> **단점**: 
> - **의미 검색 불가**: "급여"를 검색할 때 "월급"이라는 단어만 있는 문서는 못 찾을 수 있음 (단어 일치 기반).
> - **속도/양 제한**: Notion API의 검색 속도에 의존하며, 가져올 수 있는 문서 양에 한계가 있음.

---

## 2. 고도화 방식: Vector RAG (Standard RAG)
AI가 문장의 '의미'를 숫자로 변환(임베딩)하여 저장해두고 찾는 방식입니다.

### 필요 단계 (구축 파이프라인)
RAG를 제대로 구현하려면 아래 5단계를 수행하는 **별도의 서버와 DB**를 구축해야 합니다.

1.  **데이터 추출 (Extract)**
    *   Notion API를 통해 주기적으로 모든 페이지를 긁어옵니다. (매일 밤 or 변경 시마다)
2.  **청킹 (Chunking)**
    *   긴 문서를 문단 단위나 의미 단위로 잘게 쪼갭니다. (예: 500자 단위)
3.  **임베딩 (Embedding)**
    *   쪼갠 텍스트를 AI 모델(OpenAI Embeddings, Google Vertex Embeddings 등)에 넣어 **숫자 벡터(Vector)**로 변환합니다.
    *   예: "사과" -> `[0.1, 0.5, -0.3, ...]`
4.  **벡터 저장소 적재 (Vector Vector)**
    *   변환된 숫자를 검색할 수 있는 전용 DB(Pinecone, Milvus, Elasticsearch 등)에 저장합니다.
5.  **검색 및 생성 (Retrieval & Generation)**
    *   사용자가 질문하면, 질문도 `[0.2, ...]` 숫자로 변환합니다.
    *   DB에서 **숫자가 가장 비슷한**(의미가 가까운) 문서를 찾아냅니다. (이때 "급여"로 검색해도 "월급" 문서를 찾습니다)
    *   찾은 문서를 AI에게 주어 답변을 생성합니다.

### 비교 요약

| 구분 | 현재 방식 (Live Search) | 고도화 방식 (Vector RAG) |
| :--- | :--- | :--- |
| **핵심 기술** | Notion 키워드 검색 API | Vector 임베딩 & Similarity Search |
| **준비물** | API 키만 있으면 됨 | 별도 DB, 임베딩 모델, 동기화 서버 |
| **검색 품질** | 키워드 일치 여부에 의존 | **의미(문맥) 기반 추론 가능** |
| **최신성** | 실시간 (즉시 반영) | 동기화 주기(예: 1시간)에 따라 지연 발생 |
| **구축 난이도** | 하 (반나절 소요) | **상 (최소 1~2주 소요)** |

### 결론
현재는 **"구축 비용 대비 효율"**이 가장 좋은 방식을 채택했습니다.
만약 사내 문서가 수천 개 이상으로 늘어나고, "단어는 다르지만 의미가 같은" 문서들을 찾아야 하는 니즈가 커진다면, 그때 **벡터 DB 도입(2번 방식)**을 고려하시는 것이 좋습니다.