hskwon
aca1767eb9
- URL 하드코딩 → .env APP_URL 기반 동적 URL로 변경 - DB 연결 하드코딩 → .env 기반으로 변경 - MySQL strict mode DATE 오류 수정
3.5 KiB
3.5 KiB
Notion API를 이용한 RAG 구축: 현재 방식 vs 고도화(Vector) 방식
현재 구축된 챗봇은 **"검색 기반(Search-Based) RAG"**입니다. Notion의 실시간 검색 기능을 활용해 가볍고 빠르게 구축한 버전입니다. 질문하신 대로, 더 높은 정확도와 의미 기반 검색이 가능한 "임베딩(Vector) 기반 RAG"(=순수 RAG)를 구축하려면 훨씬 더 복잡한 파이프라인이 필요합니다.
1. 현재 방식: Search-Based RAG (Live Search)
Notion이 제공하는 '검색 창' 기능을 API로 대신 누르는 것과 같습니다.
구조
- User: "오타 수정 기능 있어?"
- AI (Keyword Gen): 질문을 Notion 검색어로 변경 -> "오타 수정"
- Notion API: 해당 단어가 포함된 제목/본문을 찾아서 리턴
- AI (Answer): 찾은 내용을 읽고 답변 생성
장점:
- 구축이 매우 빠름 (별도 DB 필요 없음).
- Notion에서 수정하면 즉시 반영됨 (실시간).
단점:
- 의미 검색 불가: "급여"를 검색할 때 "월급"이라는 단어만 있는 문서는 못 찾을 수 있음 (단어 일치 기반).
- 속도/양 제한: Notion API의 검색 속도에 의존하며, 가져올 수 있는 문서 양에 한계가 있음.
2. 고도화 방식: Vector RAG (Standard RAG)
AI가 문장의 '의미'를 숫자로 변환(임베딩)하여 저장해두고 찾는 방식입니다.
필요 단계 (구축 파이프라인)
RAG를 제대로 구현하려면 아래 5단계를 수행하는 별도의 서버와 DB를 구축해야 합니다.
- 데이터 추출 (Extract)
- Notion API를 통해 주기적으로 모든 페이지를 긁어옵니다. (매일 밤 or 변경 시마다)
- 청킹 (Chunking)
- 긴 문서를 문단 단위나 의미 단위로 잘게 쪼갭니다. (예: 500자 단위)
- 임베딩 (Embedding)
- 쪼갠 텍스트를 AI 모델(OpenAI Embeddings, Google Vertex Embeddings 등)에 넣어 **숫자 벡터(Vector)**로 변환합니다.
- 예: "사과" ->
[0.1, 0.5, -0.3, ...]
- 벡터 저장소 적재 (Vector Vector)
- 변환된 숫자를 검색할 수 있는 전용 DB(Pinecone, Milvus, Elasticsearch 등)에 저장합니다.
- 검색 및 생성 (Retrieval & Generation)
- 사용자가 질문하면, 질문도
[0.2, ...]숫자로 변환합니다. - DB에서 숫자가 가장 비슷한(의미가 가까운) 문서를 찾아냅니다. (이때 "급여"로 검색해도 "월급" 문서를 찾습니다)
- 찾은 문서를 AI에게 주어 답변을 생성합니다.
- 사용자가 질문하면, 질문도
비교 요약
| 구분 | 현재 방식 (Live Search) | 고도화 방식 (Vector RAG) |
|---|---|---|
| 핵심 기술 | Notion 키워드 검색 API | Vector 임베딩 & Similarity Search |
| 준비물 | API 키만 있으면 됨 | 별도 DB, 임베딩 모델, 동기화 서버 |
| 검색 품질 | 키워드 일치 여부에 의존 | 의미(문맥) 기반 추론 가능 |
| 최신성 | 실시간 (즉시 반영) | 동기화 주기(예: 1시간)에 따라 지연 발생 |
| 구축 난이도 | 하 (반나절 소요) | 상 (최소 1~2주 소요) |
결론
현재는 **"구축 비용 대비 효율"**이 가장 좋은 방식을 채택했습니다. 만약 사내 문서가 수천 개 이상으로 늘어나고, "단어는 다르지만 의미가 같은" 문서들을 찾아야 하는 니즈가 커진다면, 그때 **벡터 DB 도입(2번 방식)**을 고려하시는 것이 좋습니다.