기타/관심(●'◡'●)
RAG 챗봇 아키텍처: 벡터 단독 vs 그래프+벡터 하이브리드
sesam
2025. 8. 19. 10:34
728x90
아래 구성은 문서 기반 챗봇(매뉴얼 QA, FAQ, 내부 지식 검색)에 딱 맞는 실무형 구조입니다.
현재 상황(문서 QA 중심)에는 벡터 단독이 정석이며, 엔터티 간 관계 추론이 중요해지면 그래프+벡터 하이브리드로 확장합니다.
1) 벡터 DB 단독 RAG (문서 QA에 최적)
[문서/파일] ---> [청소/분할] ---> [임베딩 서비스] ---> [Vector DB]
^
|
[사용자 질문] --(임베딩)--> [Retriever (k-NN)] ---> [Top-k Chunk]
|
v
[Re-ranker (선택)]
|
v
[Prompt Composer]
|
v
[LLM]
|
v
[답변]핵심 컴포넌트
- Ingestion 파이프라인: PDF/Docx/HTML 파싱 → 텍스트 정규화 → 문단/문장 단위 분할(chunking)
- 임베딩 서비스: OpenAI, Voyage, Jina, bge 등(동일 모델을 질의/문서 모두에 사용 권장)
- Vector DB: Qdrant/Weaviate/Milvus 중 1개(실무 추천: Qdrant)
- Retriever: k-NN + 필터(메타데이터: 문서명/버전/언어 등)
- Re-ranker(선택): Cohere/LLM Rank로 상위 n개 재정렬
- Prompt Composer: 시스템 지침 + 문서 컨텍스트 삽입 + 사용자 질의
- LLM: GPT-4o-mini/4.1, Claude, Gemini 등
장점
- 단순/빠름/운영비 저렴, 구축 난이도 낮음
- 문서 기반 QA 정확도 높음(올바른 청크 분할 + 메타필터 + 재랭크 시)
한계
- "개념-개념" 관계 추적/경로 질의에는 약함(예: A → B → C 원인 추적)
2) 그래프+벡터 하이브리드 (관계 추론/지식 연결 강화)
[문서/파일] ---> [ETL: 파싱 → NER/RE → 삼중항(Subject-Relation-Object)]
|
v
[Graph DB]
(Neo4j 등)
[사용자 질문] --(임베딩)--> [Vector Retriever] ---> [Vector DB] ---> 후보 문서/청크 ----┐
|
v
[Graph Query Builder]
|
v
(Cypher / Gremlin 질의)
|
v
┌----------------[Evidence Merger / Reasoner]----------------┐
| |
v |
[Prompt Composer] ----------------------------------------------> |
|
v
[LLM]
|
v
[답변]핵심 컴포넌트
- 정보추출(NER/RE): 엔터티(부품, 공정, 규격) 및 관계(의존/원인/구성)를 추출해 삼중항으로 적재
- Graph DB: Neo4j(추천), TigerGraph, ArangoDB
- Graph Query Builder: 사용자 의도에 맞는 경로/패턴 질의를 자동 생성(Cypher)
- Evidence Merger: 벡터 후보 + 그래프 경로에서 증거를 결합(중복 제거/정렬)
장점
- 원인-결과, 상위-하위, 구성-의존 등 연결 기반 추론에 강함
- 감사추적(왜 이런 답이 나왔는가?)에 유리(경로/증거를 함께 제시)
한계
- 스키마 설계/정보추출 파이프라인 구축 비용↑
- 운영 복잡도↑ (두 스토어 동시 관리)
실무형 구성 예시
A. 벡터 단독 (추천 스타터 킷)
- 스토어: Qdrant (Local or Cloud)
- 임베딩: text-embedding-3-large 또는 bge-m3
- 재랭크: Cohere Rerank v3 (선택)
- 오케스트레이션: n8n / LangChain / LlamaIndex 중 택1
- 팩토리 세팅 팁
- Chunk: 250
500 tokens, overlap 50100 - 메타데이터: docId, section, page, version, updatedAt, locale
- 쿼리: hybrid(벡터 + 키워드 BM25) 혹은 벡터+k값 크게 + 재랭크
- Chunk: 250
B. 그래프+벡터 (확장 구성)
- Graph 스키마(예)
- Node: Equipment, Process, Spec, Defect, Action
- Edge: (Process)-[:USES]->(Equipment), (Defect)-[:CAUSES]->(Action)
- 추출 파이프라인
- NER(부품/공정/규격) → 관계 추출(RE) → 삼중항 적재 → 정규화(동의어 테이블)
- 쿼리 전략
- 1단계: 벡터로 후보 문서/엔티티 집합 소거
- 2단계: 그래프에서 경로 탐색(Cypher)로 근거 확대
- 3단계: 근거 합치기 + 인용(경로/노드 ID) 포함
의사결정 체크리스트
- 문서 QA만 필요: 벡터 단독 ✅
- 원인/의존 관계 추적: 그래프+벡터 ✅
- 데이터 변동 잦음(스키마 안정 미흡): 벡터 단독 권장
- 감사추적/근거경로 노출 필요: 그래프+벡터 권장
- 초기 리소스 제한: 벡터 → 이후 그래프 단계적 도입
빠른 시작 레시피 (n8n/LangChain 예시 스텝)
Ingestion
- 파일 업로드 → 텍스트 추출(PDF/Docx)
- 청크 분할(토큰 기준)
- 임베딩 생성 → Qdrant upsert(메타 포함)
Query
- 질문 임베딩 → Qdrant k-NN 검색
- (선택) Cohere Rerank로 상위 n개 재정렬
- Prompt Compose(시스템 지침+근거 청크) → LLM 호출
- 답변 + 인용(문서명/페이지/섹션)
Graph 확장 시
- Ingestion 시 NER/RE로 삼중항 생성 → Neo4j 적재
- Query 시 후보 엔티티 기준 Cypher 경로 탐색
- Evidence Merger로 중복/우선순위 정리 → LLM
운영 팁
- 동일 임베딩 모델(문서/질문)에 사용: 표현 공간 일치
- 하이브리드 검색: 벡터 + 키워드(BM25)로 노이즈 감소
- 버전 관리: docVersion, effectiveDate로 최신 우선
- 관찰성: 검색 로그/재현 프롬프트 저장 → 품질 튜닝
- PII/보안: 메타 필터로 접근 제어(role, project)
질문
그래프+벡터 하이브리드 (관계 추론/지식 연결 강화)에 벡터 디비라고 쓰여있는 곳이 없는데 왜 하이브리드라는건지?
RAG 챗봇 아키텍처: 벡터 단독 vs 그래프+벡터 하이브리드
아래 구성은 문서 기반 챗봇(매뉴얼 QA, FAQ, 내부 지식 검색)에 딱 맞는 실무형 구조입니다. 현재 상황(문서 QA 중심)에는 벡터 단독이 정석이며, 엔터티 간 관계 추론이 중요해지면 그래프+벡터 하이브리드로 확장합니다.
1) 벡터 DB 단독 RAG (문서 QA에 최적)
[문서/파일] --> [청소/분할] --> [임베딩 서비스] --> [Vector DB]
^ |
| v
[사용자 질문] --(임베딩)--> [Retriever (k-NN)] --> [Top-k Chunk]
|
v
[Re-ranker (선택)]
|
v
[Prompt Composer] --> [LLM]
|
v
[답변]
핵심 컴포넌트
- Ingestion 파이프라인: PDF/Docx/HTML 파싱 → 텍스트 정규화 → 문단/문장 단위 분할(chunking)
- 임베딩 서비스: OpenAI, Voyage, Jina, bge 등(동일 모델을 질의/문서 모두에 사용 권장)
- Vector DB: Qdrant/Weaviate/Milvus 중 1개(실무 추천: Qdrant)
- Retriever: k-NN + 필터(메타데이터: 문서명/버전/언어 등)
- Re-ranker(선택): Cohere/LLM Rank로 상위 n개 재정렬
- Prompt Composer: 시스템 지침 + 문서 컨텍스트 삽입 + 사용자 질의
- LLM: GPT-4o-mini/4.1, Claude, Gemini 등
장점
- 단순/빠름/운영비 저렴, 구축 난이도 낮음
- 문서 기반 QA 정확도 높음(올바른 청크 분할 + 메타필터 + 재랭크 시)
한계
- "개념-개념" 관계 추적/경로 질의에는 약함(예: A → B → C 원인 추적)
2) 그래프+벡터 하이브리드 (관계 추론/지식 연결 강화)
┌────────────────────────────────────────┐
[문서/파일] --> │ ETL: 파싱 → NER/RE → 삼중항(Subject-Relation-Object) │
└──────────────┬─────────────────────────┘
v
[Graph DB]
(Neo4j 등)
^
|
[사용자 질문] --(임베딩)--> [Vector Retriever] --> [Vector DB] --> 후보 문서/청크 ----┐
| |
v v
[Graph Query Builder] ---> (Cypher/Gremlin 질의)
| |
v v
[Evidence Merger / Reasoner] <----------------------------
|
v
[Prompt Composer] --> [LLM] --> [답변]핵심 컴포넌트
- 정보추출(NER/RE): 엔터티(부품, 공정, 규격) 및 관계(의존/원인/구성)를 추출해 삼중항으로 적재
- Graph DB: Neo4j(추천), TigerGraph, ArangoDB
- Graph Query Builder: 사용자 의도에 맞는 경로/패턴 질의를 자동 생성(Cypher)
- Evidence Merger: 벡터 후보 + 그래프 경로에서 증거를 결합(중복 제거/정렬)
장점
- 원인-결과, 상위-하위, 구성-의존 등 연결 기반 추론에 강함
- 감사추적(왜 이런 답이 나왔는가?)에 유리(경로/증거를 함께 제시)
한계
- 스키마 설계/정보추출 파이프라인 구축 비용↑
- 운영 복잡도↑ (두 스토어 동시 관리)
실무형 구성 예시
A. 벡터 단독 (추천 스타터 킷)
- 스토어: Qdrant (Local or Cloud)
- 임베딩: text-embedding-3-large 또는 bge-m3
- 재랭크: Cohere Rerank v3 (선택)
- 오케스트레이션: n8n / LangChain / LlamaIndex 중 택1
- 팩토리 세팅 팁
- Chunk: 250
500 tokens, overlap 50100 - 메타데이터: docId, section, page, version, updatedAt, locale
- 쿼리: hybrid(벡터 + 키워드 BM25) 혹은 벡터+k값 크게 + 재랭크
- Chunk: 250
B. 그래프+벡터 (확장 구성)
- Graph 스키마(예)
- Node: Equipment, Process, Spec, Defect, Action
- Edge: (Process)-[:USES]->(Equipment), (Defect)-[:CAUSES]->(Action)
- 추출 파이프라인
- NER(부품/공정/규격) → 관계 추출(RE) → 삼중항 적재 → 정규화(동의어 테이블)
- 쿼리 전략
- 1단계: 벡터로 후보 문서/엔티티 집합 소거
- 2단계: 그래프에서 경로 탐색(Cypher)로 근거 확대
- 3단계: 근거 합치기 + 인용(경로/노드 ID) 포함
의사결정 체크리스트
- 문서 QA만 필요: 벡터 단독 ✅
- 원인/의존 관계 추적: 그래프+벡터 ✅
- 데이터 변동 잦음(스키마 안정 미흡): 벡터 단독 권장
- 감사추적/근거경로 노출 필요: 그래프+벡터 권장
- 초기 리소스 제한: 벡터 → 이후 그래프 단계적 도입
빠른 시작 레시피 (n8n/LangChain 예시 스텝)
Ingestion
- 파일 업로드 → 텍스트 추출(PDF/Docx)
- 청크 분할(토큰 기준)
- 임베딩 생성 → Qdrant upsert(메타 포함)
Query
- 질문 임베딩 → Qdrant k-NN 검색
- (선택) Cohere Rerank로 상위 n개 재정렬
- Prompt Compose(시스템 지침+근거 청크) → LLM 호출
- 답변 + 인용(문서명/페이지/섹션)
Graph 확장 시
- Ingestion 시 NER/RE로 삼중항 생성 → Neo4j 적재
- Query 시 후보 엔티티 기준 Cypher 경로 탐색
- Evidence Merger로 중복/우선순위 정리 → LLM
운영 팁
- 동일 임베딩 모델(문서/질문)에 사용: 표현 공간 일치
- 하이브리드 검색: 벡터 + 키워드(BM25)로 노이즈 감소
- 버전 관리: docVersion, effectiveDate로 최신 우선
- 관찰성: 검색 로그/재현 프롬프트 저장 → 품질 튜닝
- PII/보안: 메타 필터로 접근 제어(role, project)
728x90