60 lines
3.5 KiB
Markdown
60 lines
3.5 KiB
Markdown
|
# 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번 방식)**을 고려하시는 것이 좋습니다.
|