LLM 공부 09 | RAG와 Vector DB: LLM 밖에서 근거를 찾는 방식

1편에서 가장 먼저 버린 오해가 있었다.

LLM은 내부 Vector DB에서 답을 검색하는 시스템이다.

이 표현은 직관적이지만 정확하지 않다.

LLM 기본 동작은 검색이 아니라 다음 token 생성이다. prompt가 token ID가 되고, embedding vector가 되고, Transformer block을 지나고, LM head가 다음 token 후보 점수를 만든다. 이 흐름은 1~8편에서 계속 본 내부 계산이다.

그런데 실제 제품에서는 LLM이 최신 문서, 회사 위키, 내부 DB, 웹 검색 결과를 참고하는 것처럼 보인다.

여기서 RAG가 나온다.

RAG는 LLM 내부에 문서 DB가 들어 있다는 뜻이 아니다. LLM 바깥에서 근거를 찾아 context에 넣고, LLM이 그 context를 읽고 답변 token을 생성하게 만드는 패턴이다.

이번 글의 핵심은 이 구분이다.

검색 시스템은 근거를 가져온다.
LLM은 그 근거가 들어간 context를 읽고 token을 생성한다.

RAG는 LLM 내부 검색이 아니다

RAG는 Retrieval-Augmented Generation의 줄임말이다.

말 그대로 retrieval로 generation을 보강한다.

사용자 질문
-> 외부 검색
-> 관련 문서나 데이터 반환
-> prompt/context에 추가
-> LLM 답변 생성

LLM 자체가 외부 문서를 알고 있는 것이 아니다. 검색 결과가 prompt 안에 들어왔기 때문에 모델이 그 내용을 읽고 답할 수 있는 것이다.

그래서 RAG를 이렇게 이해하면 안전하다.

LLM parameter = 학습으로 압축된 패턴
RAG retrieval = 외부 근거를 찾아오는 과정
LLM generation = 주어진 context로 다음 token을 생성하는 과정

RAG가 필요한 이유는 명확하다.

학습 이후 정보가 필요하다
회사 내부 문서처럼 학습 데이터에 없는 자료가 필요하다
출처가 있는 답변이 필요하다
환각을 줄이고 싶다

RAG는 모델의 기억을 바꾸지 않는다. 모델이 읽는 입력을 바꾼다.

RAG와 Vector DB, Graph RAG는 LLM 바깥에서 근거를 찾는 retrieval 계층이다. LLM은 그 결과가 들어간 context를 읽고 다음 token을 생성한다.

Vector DB는 원본이 아니라 검색용 파생 index다

회사 문서나 wiki를 Vector DB로 만든다고 해 보자.

그 말은 원본 문서를 Vector DB 안으로 영구 이사시킨다는 뜻이 아니다. 원본은 그대로 둔다. 원본 문서, wiki, raw, DB record가 source of truth다.

Vector DB는 그 원본을 검색하기 위한 파생 index다.

원본 문서
-> chunk로 나눔
-> embedding model로 vector 변환
-> Vector DB에 저장

질문이 들어오면 질문도 vector로 변환한다. 그리고 Vector DB에서 가까운 chunk를 찾는다.

질문
-> retrieval embedding
-> 유사 vector 검색
-> 관련 chunk 반환
-> LLM context에 추가

이 vector는 LLM parameter가 아니다.

2편에서 embedding table은 token ID를 vector로 바꾸는 모델 내부 parameter라고 했다. Vector DB의 retrieval embedding은 다르다. 외부 embedding model이 문서 chunk를 읽고 계산한 결과값이다.

LLM token embedding:
token ID -> vector
모델 내부 parameter

retrieval embedding:
문서 chunk -> vector
검색용 파생 데이터

hidden state:
LLM 추론 중 생기는 문맥 반영 vector
요청 중 activation

이 셋을 섞으면 RAG를 잘못 이해하게 된다.

Vector DB는 의미적으로 비슷한 chunk를 잘 찾는다

Vector DB RAG의 장점은 의미 유사도 검색이다.

사용자가 정확한 단어를 쓰지 않아도 비슷한 의미의 문서를 찾을 수 있다.

질문: "요금제 해지하면 환불돼?"
문서: "구독 취소 및 잔여 기간 환불 정책"

키워드가 완전히 같지 않아도 embedding 공간에서 가까우면 검색될 수 있다.

그래서 Vector DB RAG는 이런 상황에 강하다.

문서가 많다
질문 표현이 다양하다
정확한 키워드를 사용자가 모른다
관련 문단을 빠르게 찾고 싶다

하지만 약점도 있다.

Vector DB는 기본적으로 "비슷한 문장"을 찾는다. 문서들 사이의 관계, 정책의 상하위 구조, 시간 순서, 의사결정 이력, 어떤 문서가 어떤 문서를 대체했는지는 별도 설계가 없으면 약하다.

비슷한 문단은 찾았지만
그 문단이 최신 정책인지
상위 규칙과 충돌하지 않는지
어떤 결정의 결과인지
다른 문서와 어떤 관계인지

이런 질문은 단순 유사도 검색만으로 부족할 수 있다.

Graph RAG는 관계까지 검색한다

Graph RAG는 RAG의 한 방식이다.

차이는 indexing 방식이다.

Vector DB RAG는 문서 chunk를 vector로 index한다.

Graph RAG는 문서에서 entity와 relation을 뽑아 graph index를 만든다.

문서
-> entity 추출
-> relation 추출
-> node / edge / property / source evidence
-> graph index

질문이 들어오면 관련 node, edge, subgraph를 찾고, 그 근거 문서를 함께 context에 넣는다.

질문
-> 관련 entity 찾기
-> 연결된 관계 탐색
-> 관련 subgraph와 source 문서 수집
-> LLM context에 추가
-> 답변 생성

그래서 Graph RAG는 이런 질문에 강하다.

이 정책은 어떤 상위 규칙에 의해 생겼나?
이 결정은 어떤 회의와 이슈에서 이어졌나?
이 고객 문제는 어떤 제품 기능과 연결되나?
이 개념은 어떤 전제와 예외를 가지고 있나?

단순히 비슷한 문단을 찾는 것이 아니라 관계를 따라간다.

Graph RAG가 항상 graph-only는 아니다

Graph RAG라고 해서 Vector DB를 완전히 버리는 것은 아니다.

실제 시스템은 hybrid가 많다.

vector search로 후보 문서 찾기
+ graph traversal로 관계 확장하기
+ metadata filter로 scope 제한하기
+ keyword/BM25 search로 정확한 용어 보강하기

Graph RAG는 "Vector DB의 반대말"이라기보다, retrieval에 관계 구조를 추가하는 방식에 가깝다.

비교하면 이렇다.

구분	Vector DB RAG	Graph RAG
기본 index	chunk vector	node, edge, property, source
검색 기준	의미 유사도	의미 유사도 + 관계 탐색
강점	관련 문단 빠른 검색	다중 홉, 정책 관계, 의사결정 맥락
약점	관계/시간/출처 맥락 약함	구축과 유지보수 비용
실제 구현	vector search 중심	vector + graph + metadata hybrid 가능

중요한 점은 둘 다 LLM 내부 구조를 바꾸지 않는다는 것이다.

검색 결과가 context에 들어오면 그 다음은 동일하다.

context
-> tokenization
-> embedding
-> Transformer
-> LM head
-> next token generation

Search tool은 Vector DB보다 넓은 개념이다

RAG 대화에서 search tool도 같이 나왔다.

Vector DB는 검색 도구의 한 종류다. search tool은 더 넓다.

Vector DB search
web search
파일 검색
사내 검색 API
SQL query
Elasticsearch/BM25
Graph DB query
ticket system query
code search

업무형 AI 시스템에서는 하나만 쓰지 않는 경우가 많다.

예를 들어 사용자가 묻는다.

지난달 환불 정책 변경 이후 VIP 고객 클레임이 늘었나요?

이 질문은 한 번의 Vector DB 검색으로 끝나지 않는다.

정책 문서 검색
-> 환불 정책 변경 내용 확인
고객 DB 조회
-> VIP 고객 범위 확인
ticket system 조회
-> 클레임 수 변화 확인
통계 계산
-> 전후 비교
LLM 답변
-> 근거와 한계 포함

이런 흐름은 tool-augmented RAG 또는 agentic RAG에 가깝다.

Tool-augmented RAG는 LLM 호출이 두 번 이상일 수 있다

RAG를 단순하게 생각하면 LLM 호출 전에 검색을 끝낸다.

orchestrator
-> 문서 검색
-> DB 조회
-> context 구성
-> LLM 호출
-> 답변

이 방식은 안정적이다. 검색 순서가 정해져 있고, 시스템이 어떤 자료를 넣을지 통제한다.

하지만 질문이 복잡하면 LLM이 먼저 어떤 tool을 써야 할지 판단해야 할 수 있다.

사용자 질문
-> LLM 1차 호출: 어떤 tool이 필요한지 결정
-> vector search 실행
-> DB query 실행
-> web/search tool 실행
-> tool 결과를 conversation/context에 추가
-> LLM 2차 호출: 최종 답변 생성

이때 첫 번째 LLM 출력은 최종 답변이 아니다. tool call 계획이나 tool call 자체일 수 있다.

그리고 tool 결과가 다시 context에 들어간다. LLM은 그 결과를 읽고 최종 답변 token을 만든다.

이 구조를 이해하면 "LLM이 DB를 안다"는 말을 피할 수 있다.

LLM은 DB를 아는 것이 아니다. DB query 결과가 context에 들어왔기 때문에 그것을 읽고 답하는 것이다.

회사 문서 원본은 Vector DB가 아니라 wiki/DB에 있어야 한다

중요한 운영 원칙이 있다.

회사 문서나 업무 도메인 지식의 source of truth는 Vector DB가 아니다.

원본은 회사 wiki, 업무 도메인 wiki, 운영 DB, 문서 저장소에 있어야 한다. Vector DB나 Graph DB는 검색을 위한 파생 index다.

source of truth:
company-wiki
business-domain wiki
operational DB
document repository

derived index:
Vector DB
Graph DB
search index
cache

이 원칙이 무너지면 운영 위험이 커진다.

Vector DB index는 재생성 가능해야 한다. embedding model이 바뀌거나 chunking 정책이 바뀌면 다시 만들 수 있어야 한다. Graph index도 마찬가지다. relation extraction 규칙이 바뀌면 다시 만들 수 있어야 한다.

이 repo의 원칙도 같다.

raw -> wiki -> output/blog -> site

raw/는 원본이고, wiki/가 source of truth다. 미래 RAG/vector DB는 이 wiki를 소비하는 파생 계층이어야 한다. 위키 본체를 RAG에 맞춰 먼저 비틀면 안 된다.

RAG는 답변 품질을 보장하지 않는다

RAG를 붙이면 hallucination이 줄 수 있다. 하지만 RAG가 모든 문제를 해결하지는 않는다.

실패 지점이 여러 개 생긴다.

원본 문서가 틀림
chunking이 나쁨
embedding model이 질문 의도를 못 잡음
검색 결과가 누락됨
오래된 문서가 최신 문서보다 먼저 나옴
graph relation이 잘못 추출됨
tool이 잘못 선택됨
DB query가 틀림
LLM이 검색 결과를 잘못 해석함

그래서 RAG 시스템에는 retrieval evaluation이 필요하다.

정답 문서가 top-k에 들어오는가
출처가 최신인가
근거 없는 답변을 거절하는가
문서 간 충돌을 표시하는가
DB query 결과를 과장하지 않는가

RAG는 "검색을 붙이면 정확해진다"가 아니라, 검색과 생성 사이에 검증 가능한 근거 경로를 만드는 작업이다.

정리

RAG는 LLM 내부 검색이 아니다. 외부 retrieval 계층이 근거를 찾아 context에 넣고, LLM은 그 context를 읽고 다음 token을 생성한다.

Vector DB RAG는 문서 chunk를 embedding vector로 index해 의미적으로 비슷한 문단을 찾는다. 이 vector는 LLM parameter가 아니라 원본 문서에서 파생된 retrieval embedding 결과다.

Graph RAG는 문서의 entity와 relation을 graph index로 만들고, 관계 탐색과 문서 근거를 함께 context에 넣는다. 실제 구현은 vector search와 graph traversal을 결합한 hybrid일 수 있다.

Search tool은 Vector DB보다 넓다. 내부 문서 검색, 내부 DB 조회, web search, code search, Graph DB query가 모두 tool이 될 수 있다. 복잡한 업무형 RAG는 LLM이 tool을 고르고, tool 결과를 다시 context에 넣고, 다시 LLM이 최종 답변을 만드는 agentic RAG 흐름으로 간다.

이 글의 핵심은 하나다.

LLM은 검색하지 않는다.
검색 시스템이 context를 만들고,
LLM은 그 context로 답변을 생성한다.

이 구분이 잡히면 RAG, Vector DB, Graph RAG, tool calling이 같은 지도 위에 놓인다.