똑똑한 LLM이 왜 우리 회사 문서는 모를까
ChatGPT와 Claude 등 거대 언어모델(LLM, Large Language Model)들은 똑똑합니다. 셰익스피어 4대 비극의 구조를 비교해 달라고 해도 답하고, 파이썬 코드를 읽어 버그를 짚어내기도 합니다. 그런데 막상 실무에서 “이번 분기 우리 팀 OKR이 뭐였지?”라고 물으면 답하지 못합니다. ChatGPT가 우리 회사 위키를 본 적이 없기 때문입니다. 학습이 끝난 시점 이후의 뉴스도 모릅니다. 모르면서 모른다고 하면 차라리 낫습니다. 더 흔한 건 그럴듯한 거짓말, 즉 환각(hallucination) 입니다.
이 두 가지 문제, 즉 도메인 지식의 부재와 지식의 시간적 단절을 푸는 방법은 크게 세 가지입니다.
- 사용자가 매번 도메인 지식과 맥락을 프롬프트에 넣어서 전달하거나,
- 모델 자체를 우리 데이터로 다시 훈련시키거나(fine-tuning),
- 모델은 그대로 두고 답할 때마다 외부 지식을 자동으로 꺼내다 끼워주는 방식입니다.
세 번째가 비용·속도·갱신 면에서 압도적으로 유리하기 때문에, 지난 몇 년간 사실상의 표준이 됐습니다. 이 세 번째 방식의 이름이 RAG(검색 증강 생성, Retrieval-Augmented Generation)입니다.
1. RAG의 정의: “검색”과 “생성”의 결합
RAG를 한 줄로 풀면 다음과 같습니다.
LLM이 답을 만들기 전에, 외부 지식 베이스에서 관련 정보를 먼저 찾아와 프롬프트에 끼워주는 아키텍처.
이름 그대로 “Retrieval(검색)으로 Augmented(보강)된 Generation(생성)”입니다. 머릿속 지식만 쓰는 학생이 아니라, 시험장에 책을 들고 들어가 펼쳐 보고 답하는 학생을 떠올리면 됩니다. 오픈북 시험입니다.
오픈북 시험이 무엇을 해결하는지 정리하면 다음과 같습니다.
- 환각이 줄어듭니다. 모델이 자기 기억을 짜내는 게 아니라, 실제 문서를 보고 답하기 때문입니다.
- 학습 이후 정보를 반영할 수 있습니다. 지식 베이스를 갱신하면 그게 바로 다음 답변에 반영됩니다.
- 도메인 특화가 가능합니다. 우리 회사 위키, 법률 판례집, 의료 가이드라인을 모델 재훈련 없이 붙일 수 있습니다.
- 출처를 추적할 수 있습니다. 어떤 문서의 어떤 청크에서 답이 나왔는지 표기할 수 있습니다. 신뢰성과 감사 가능성이 따라옵니다.
여담이지만, RAG라는 이름은 그리 만족스러운 작명이 아니었다고 합니다. 2020년 이 개념을 처음 정의한 논문의 1저자 Patrick Lewis는 한 인터뷰에서, 자기들 작업이 이렇게 광범위하게 퍼질 줄 알았다면 이름에 좀 더 공을 들였을 거라고 말한 바 있습니다. 더 좋은 이름을 찾으려 했지만 논문 마감일까지 아무도 묘안을 내지 못했다고 합니다. 지금 우리가 이 약자를 매일 쓰고 있는 건 그 사정의 결과입니다.
RAG가 매력적인 가장 큰 이유는, 모델 재훈련 없이 도메인을 갈아끼울 수 있다는 점입니다. 지식이 바뀌면 인덱스만 다시 만들면 됩니다. 모델은 그대로 둔 채로 말입니다.
파인튜닝(Fine-tuning)과의 차이
RAG를 처음 접하면 자연스럽게 떠오르는 질문이 있습니다.
“그냥 우리 회사 데이터로 모델을 다시 훈련시키면 되는 것 아닌가?”
이게 파인튜닝(미세 조정, fine-tuning) 입니다. 둘 다 “LLM에게 우리 데이터를 알게 한다”는 목적은 같지만, 본질이 다릅니다.
핵심은 지식이 어디에 있느냐입니다. 파인튜닝은 지식을 모델 안에 집어넣습니다. 가중치를 조정해 모델 자체가 그 지식을 “기억하게” 만드는 방식입니다. RAG는 지식을 모델 밖에 둡니다. 모델은 그대로 두고, 답할 때마다 외부 문서를 찾아와 프롬프트에 끼워주는 방식입니다.
지식이 모델 안에 들어가 있으면, 그걸 바꾸려면 모델을 다시 훈련시켜야 합니다. 그래서 fine-tuning은 변경 비용이 높고 갱신이 느립니다. 잘못된 정보를 고치는 것도 어렵습니다. 가중치 어딘가에 분산되어 들어간 정보를 콕 집어 수정할 방법이 없기 때문입니다. 출처 추적도 마찬가지입니다. 모델이 답을 했을 때 “이 답이 어느 문서에서 왔느냐”를 물어도 답할 수 없습니다. 정보가 가중치에 녹아 있을 뿐 어디서 왔는지의 흔적은 사라진 상태이기 때문입니다.
지식이 모델 밖에 있으면 정반대입니다. 문서를 갱신하면 다음 답변에 즉시 반영됩니다. 잘못된 정보는 해당 문서만 고치면 됩니다. 답에 사용한 청크를 그대로 표기할 수도 있습니다. 모델이 그 청크를 받아 답을 만들었다는 사실이 명확하기 때문입니다.
| 비교 축 | Fine-tuning | RAG |
|---|---|---|
| 지식이 어디에 있는가 | 모델 안 (가중치) | 모델 밖 (외부 인덱스) |
| 변경 비용 | 높음 (GPU·시간·라벨링 데이터) | 낮음 (인덱스 재구축) |
| 갱신 주기 | 느림 (재훈련 필요) | 빠름 (문서 업데이트 즉시 반영) |
| 잘못된 정보 수정 | 어려움 (재훈련 또는 추가 튜닝) | 쉬움 (해당 문서만 수정) |
| 출처 추적 | 어려움 (가중치에 녹아듦) | 가능 (어느 청크에서 왔는지 표기) |
그렇다면 파인튜닝은 언제 쓰는 걸까요?
지식이 아니라 행동을 바꾸고 싶을 때입니다. 회사 특유의 어조, 일관된 출력 형식, 도메인 특유의 추론 패턴 같은 것들은 외부 문서를 끼워준다고 바뀌지 않습니다. 모델 자체의 “말하는 습관”을 바꿔야 하는 영역 처럼요. 반대로 “우리 회사 매뉴얼을 알게 만들기” 같은 지식 주입형 과제는 RAG가 압도적입니다. 실제로는 fine-tuning으로 어조를 잡고 RAG로 지식을 얹는 하이브리드도 흔하지만, “회사 문서를 LLM이 알게 만들기”라는 목적에 한정하면 첫 시도는 거의 항상 RAG입니다.
2. RAG의 작동 원리: 4단계 파이프라인
RAG는 네 단계로 움직입니다. 이 흐름을 이해하면 이후 한계가 어디서 나오는지가 자연스럽게 보입니다.
| 단계 | 이름 | 시점 | 무엇을 하는가 | 입력 | 출력 |
|---|---|---|---|---|---|
| 1 | 인덱싱 | 오프라인 (사전 작업) | 문서를 청크로 자르고, 임베딩 모델로 벡터 변환해 벡터 DB에 저장 | 문서 원본 (PDF, 위키, 매뉴얼 등) | 벡터 DB 인덱스 |
| 2 | 쿼리 임베딩 | 온라인 (질문 시) | 사용자 질문을 같은 임베딩 모델로 벡터 변환 (청크와 같은 좌표계에 올리기 위함) | 자연어 질문 | 질문 벡터 |
| 3 | 검색 | 온라인 (질문 시) | 질문 벡터와 가장 가까운 청크 벡터를 벡터 DB에서 찾음 (상위 N개, 보통 5~20) | 질문 벡터 + 벡터 DB | 관련 청크 N개 |
| 4 | 생성 | 온라인 (질문 시) | 찾아온 청크를 프롬프트에 끼워 LLM에 전달, 답변 생성 | 질문 + 청크 N개 | 최종 답변 |
1단계: 인덱싱 (오프라인)
문서를 적당한 길이의 조각, 즉 청크(chunk) 로 자릅니다. 한 청크가 한 단락이 될 수도, 몇 문장이 될 수도 있습니다. 자른 청크 각각을 임베딩 모델에 넣어 벡터(숫자 좌표의 나열)로 변환하고, 그 벡터를 벡터 DB에 저장합니다. 여기까지가 사전 작업입니다.
2단계: 쿼리 임베딩
사용자가 질문을 던지면, 그 질문도 같은 임베딩 모델로 벡터로 만듭니다. 청크와 질문이 “같은 좌표계 위에” 놓여야 비교가 되기 때문입니다.
3단계: 검색
질문 벡터와 가장 가까운(유사한) 청크 벡터를 벡터 DB에서 찾습니다. 보통 상위 N개를 가져옵니다 (N은 5~20 정도가 흔합니다).
4단계: 생성
찾아온 청크들을 프롬프트에 끼워서 LLM에 전달합니다. 프롬프트는 대체로 다음과 같은 형식입니다. “다음 문서를 참고해서 질문에 답하라. [청크1] [청크2] [청크3] / 질문: …”. LLM은 이 청크들을 읽고 답을 만듭니다.
이 파이프라인을 굴리려면 다음 부품들이 필요합니다.
| 부품 | 역할 | 대표 옵션 (2026년 4월 기준) |
|---|---|---|
| 임베딩 모델 | 텍스트 → 벡터 변환 | – OpenAI text-embedding-3-small/largetext-embedding-005– Voyage voyage-3-large– Cohere embed-v4.0– 오픈소스(BGE, E5, Jina v4, Qwen3) |
| 벡터 DB | 벡터 저장 및 유사도 검색 | – 관리형: Pinecone, Zilliz Cloud – 오픈소스: Milvus, Weaviate, Qdrant, Chroma, pgvector |
| LLM | 답변 생성 | OpenAI GPT, Anthropic Claude, Google Gemini, 오픈소스(Llama, Qwen, Mistral) |
| 오케스트레이션 | 부품들을 엮는 글루 코드 | LangChain, LlamaIndex |
4단계 중 제품의 답변 품질을 좌우하는 결정적 단계는 3단계 검색입니다. 검색이 엉뚱한 청크를 가져오면 LLM이 아무리 똑똑해도 답이 어긋납니다. “Garbage In, Garbage Out”이 그대로 적용됩니다. 그래서 다음 섹션이 중요합니다.
3. 임베딩과 벡터 DB: RAG의 심장 들여다보기
RAG의 검색은 우리가 익숙한 키워드 검색이 아닙니다. 의미 유사도(semantic similarity) 기반입니다. 여기가 RAG의 강력함의 원천이자, 동시에 마지막 섹션에서 드러날 한계의 뿌리이기도 합니다.
1) 임베딩: 텍스트를 좌표로 바꾸기
임베딩(embedding) 은 텍스트를 수백~수천 차원의 숫자 벡터로 변환하는 작업입니다. 본격적으로 들어가기 전에 벡터가 무엇인지부터 짚고 가겠습니다.
벡터는 숫자들의 나열입니다. 학창 시절 좌표평면에서 점의 위치를 (x, y)로 표시했던 그 (x, y)가 2차원 벡터입니다. 3차원이라면 (x, y, z), 1,536차원이라면 1,536개의 숫자가 나열된 형태입니다. 각 숫자는 좌표 공간 위에서 그 점이 어느 축으로 얼마나 떨어져 있는지를 나타냅니다.
차원이 높아지면 머릿속에 그림으로 그릴 수는 없지만, 수학적으로는 똑같이 작동합니다. 두 점 사이의 거리도 계산할 수 있고, 어느 점이 어느 점과 가까운지도 판단할 수 있습니다. 임베딩은 텍스트 한 조각을 이 고차원 좌표 공간 위의 한 점으로 변환하는 작업입니다. 비슷한 의미를 가진 텍스트는 가까운 점으로, 다른 의미를 가진 텍스트는 먼 점으로 배치됩니다.
예를 들어 OpenAI의 text-embedding-3-small 모델은 기본적으로 1,536차원의 벡터를 만듭니다. text-embedding-3-large는 최대 3,072차원입니다. 1,536차원이라는 말은, 한 문장 또는 한 청크가 1,536개의 숫자로 표현된다는 뜻입니다.
차원이 그렇게 많은 이유는 의미가 한두 축으로 표현되지 않기 때문입니다. “강아지”라는 단어 하나만 봐도 동물성, 크기, 친근감, 책임감, 털 길이, 짖는 소리처럼 다양한 축의 정보가 한 단어에 응축되어 있습니다. 차원이 많을수록 이런 미묘한 차이를 더 잘 잡아냅니다.
핵심 성질은 다음과 같습니다. 의미가 비슷한 텍스트는 좌표가 가깝다. “강아지 키우는 법”과 “반려견 양육 가이드”는 단어가 다르지만 좌표가 가깝습니다. 그래서 키워드가 일치하지 않아도 검색이 됩니다. 이것이 의미 검색(semantic search)입니다.
2) 키워드 검색 vs 의미 검색
| 비교 축 | 키워드 검색 | 의미 검색 (RAG) |
|---|---|---|
| 매칭 기준 | 단어 일치 | 벡터 거리 (의미 유사도) |
| “강아지” 질의 시 | “강아지” 들어간 문서만 | “강아지”, “반려견”, “댕댕이” 모두 잡힘 |
| 동의어·유사어 처리 | 어휘 사전 등록 필요 | 자동으로 처리됨 |
| 오탈자 내성 | 약함 | 비교적 강함 |
| 약점 | 표현이 다르면 못 찾음 | 정확한 식별자(ID, 모델명, 통계 수치)가 약함 |
순수한 의미 검색만으로는 약한 자리가 있습니다. 정확한 식별자(예: ORD-2024-7821)나 도메인 고유 명사가 그렇습니다. “강아지”와 “반려견”의 좌표는 가깝지만, ORD-2024-7821과 ORD-2024-7822의 좌표도 임베딩 입장에서는 가까워 보입니다. 숫자 한 자리 차이를 의미적 차이로 인식하지 못하기 때문입니다. 그래서 키워드 검색이 압도적으로 잘 푸는 영역이 의미 검색에서는 오히려 약점이 됩니다.
이 약점을 메우는 방법이 하이브리드 검색입니다. 벡터 기반 의미 검색과 키워드 검색(BM25 등 sparse)을 동시에 돌려 두 결과의 순위를 합치는 방식입니다. 의미 검색이 “비슷한 의미의 페이지”를 가져오고, 키워드 검색이 “정확한 단어가 들어간 페이지”를 가져온 뒤, 두 결과를 점수화해 최종 순위를 만듭니다. 의미 유사도와 어휘 일치를 모두 잡는 셈입니다.
순위 합치기에는 RRF(Reciprocal Rank Fusion)나 가중 평균이 흔히 쓰입니다. 두 검색의 결과가 다르게 나왔을 때 어느 쪽 신호를 얼마나 신뢰할지를 정해주는 단계입니다. 도메인에 따라 가중치를 조정합니다. 예를 들어, 법률 문서는 키워드 신호 비중을 높이고, 일반 FAQ는 의미 신호 비중을 높이는 식입니다.
2026년 4월 현재 주요 벡터 DB 대부분이 이 기능을 네이티브로 제공합니다. Weaviate(BM25 가속을 위한 BlockMax WAND, fusion은 RankedFusion 또는 RelativeScoreFusion), Milvus 2.5+(빌트인 BM25 함수로 sparse 벡터 자동 생성), Qdrant(named vector로 dense·sparse 동시 보유), Pinecone(sparse-dense 단일 하이브리드 인덱스) 등이 대표적입니다.
3) 벡터 DB가 하는 일
문서가 100만 개라면 청크는 수백만 개를 넘어갑니다. 질문이 들어올 때마다 이 모든 벡터와 일일이 거리를 계산하면 한 번 답을 받는 데 수 초가 걸립니다. 벡터 검색이 실용성을 가지려면, 빠르게 가까운 이웃을 찾는 별도의 자료구조가 필요합니다.
벡터 DB가 바로 이 역할을 수행합니다. 핵심 기법은 ANN(Approximate Nearest Neighbor)로, 우리말로 풀면 “근사 최근접 이웃 검색”입니다. 이름 그대로 100% 정확한 1등을 찾는 대신, 99% 정도 정확한 1등을 1/1000의 시간에 찾는 방식입니다. RAG처럼 “딱 한 개의 정답”이 아니라 “관련성 높은 N개”를 가져오면 충분한 시나리오에서는, 1%의 정확도를 양보하고 1000배의 속도를 얻는 것이 가능해집니다.
가장 널리 쓰이는 ANN 알고리즘은 HNSW(Hierarchical Navigable Small World) 입니다. 이름이 어렵지만 발상은 단순합니다. 벡터들을 여러 층으로 쌓되, 위층은 듬성듬성하게(고속도로처럼) 아래층은 촘촘하게(골목길처럼) 연결합니다. 검색이 들어오면 먼저 위층에서 큰 방향만 잡고, 점점 아래층으로 내려가면서 정밀하게 찾아 들어갑니다. 항공편으로 도시까지 간 다음 지하철로 동네까지 가고 마지막에 걸어서 집을 찾는 것과 같은 구조입니다.
벡터 DB가 단순히 “벡터를 저장하는 데이터베이스”가 아니라 벡터 검색에 특화된 인덱스 엔진으로 분류되는 이유가 여기에 있습니다. 일반 RDB에 벡터 컬럼을 추가한다고 RAG가 굴러가지 않습니다. 검색 속도가 받쳐주지 않으면 사용자 경험이 무너지기 때문입니다. 다만 PostgreSQL의 pgvector 확장처럼 기존 DB에 ANN 인덱스를 얹는 방식도 자주 쓰이는데, 이 경우 데이터 규모가 수천만 벡터를 넘지 않는 선에서 운영 단순성과 검색 성능을 동시에 챙길 수 있습니다.
RAG의 똑똑함은 결국 임베딩의 똑똑함입니다. 임베딩이 의미를 잘 잡으면 RAG도 잘 답하고, 임베딩이 놓친 것은 RAG도 놓칩니다. 벡터 DB는 그 임베딩을 빠르게 꺼내올 뿐, 임베딩이 표현하지 못한 정보를 만들어내지는 못합니다. 마지막 섹션에서 RAG의 한계를 짚을 때 이 지점이 다시 등장합니다.
4. RAG의 강점: 어디서 빛나는가
여기까지가 RAG의 작동 원리였습니다. 이제 “그래서 어디서 쓸 만한가”를 정리할 차례입니다. RAG가 진가를 발휘하는 시나리오는 대략 네 가지입니다.
| 강점 | 무엇이 가능해지는가 | 대표 시나리오 |
|---|---|---|
| 비정형 문서 활용 | 정형 DB의 행·열로 표현되지 않는 자료를 검색 대상으로 삼을 수 있음 | PDF 매뉴얼, 정책 문서, 회의록, 위키, 이메일, 슬랙 메시지 |
| 도메인 특화 챗봇 | 모델 재훈련 없이 자사 지식을 LLM에 얹을 수 있음 | 법률 사무소의 판례·계약서 어시스턴트, 병원의 진료 가이드라인 임상 보조, 고객 지원팀의 제품 매뉴얼 상담 봇 |
| 빠른 갱신 주기 | 문서가 바뀌면 임베딩만 다시 만들어 인덱스를 갱신하면 됨 | 법규, 가격, 정책, 뉴스처럼 일·주 단위로 정보가 바뀌는 도메인 |
| 출처 추적 (traceability) | “이 답은 어떤 문서의 몇 페이지에서 나왔다”를 표시할 수 있음 | 의료, 금융, 법률, 정부 (운영의 전제 조건)처럼 신뢰가 중요한 도메인 |
회사 안에 쌓이는 지식의 대부분이 사실 비정형입니다. PDF, 회의록, 위키 같은 자료를 정형 DB로 옮기는 건 현실적이지 않고, 옮긴다 해도 의미를 잃습니다. RAG는 이런 자료를 그대로 둔 채 검색 가능한 형태로 만든다는 점에서 기업 환경과 잘 맞습니다. 거기에 갱신이 빠르고 출처를 표시할 수 있다는 운영상의 이점이 더해지면, 신뢰성이 중요한 도메인에서도 실전 투입이 가능해집니다.
이 네 가지가 모이면, 왜 AWS·Microsoft·Google·IBM·Oracle 같은 대형 클라우드/엔터프라이즈 사업자가 RAG에 본격적으로 베팅하고 있는지가 보입니다. 기업 내부 지식을 AI에 연결하는 가장 현실적인 방법이기 때문입니다.
5. RAG는 어디서 막히는가
지금까지의 이야기만 보면 RAG는 만능에 가깝습니다. 그런데 실제 운영에 들어가 보면 이상한 패턴이 보입니다. 단순한 사실 조회에는 잘 답하는데, 조금만 복잡한 질문이 들어오면 답이 흔들립니다. 이 섹션이 다음 편의 출발점입니다.
연구자들이 RAG의 한계를 체계적으로 짚기 시작하면서 반복적으로 등장하는 약점은 여섯 가지로 정리됩니다.
| 한계 | 무엇이 문제인가 | 왜 RAG로는 어려운가 |
|---|---|---|
| 다중 홉 추론 | 정보를 두세 단계 이어가야 풀리는 질문에 약함 | 벡터 검색은 한 번에 “질문과 의미가 비슷한 청크”를 가져올 뿐, 청크 간 연결 고리를 만들어 주지 못함 |
| 관계의 부재 | 청크 사이의 의미적 관계가 인덱스에 표현되지 않음 | “이 청크는 저 청크의 후속편”, “X는 Y의 부하”처럼 명시적으로 적어두지 않은 관계는 어디에도 저장되지 않음 |
| 다중 소스 종합 | 여러 문서에 흩어진 사실을 합쳐 결론을 만드는 작업이 약함 | 비슷한 청크 N개를 가져오는 것까지는 잘하지만, 종합 책임이 LLM 추론에 통째로 넘어감 |
| 모호성과 동음이의어 | 같은 단어가 여러 의미를 가질 때 분리가 어려움 | 임베딩 좌표가 가까우면 회사 Apple과 과일 사과가 함께 잡혀 들어옴 |
| 청킹의 정보 손실 | 청크 경계에서 맥락이 끊김 | 청크를 키우면 노이즈가 늘고, 줄이면 맥락이 끊김. “그러므로”, “이에 따라” 같은 연결어는 앞 청크와의 관계를 잃음 |
| 데이터 신선도 | 인덱스가 원본 변경을 즉시 따라가지 못함 | 갱신 파이프라인이 늦으면 옛 정보로 답함. 실시간성이 중요할수록 운영 부담이 커짐 |
가장 본질적인 두 가지는 다중 홉 추론과 관계의 부재입니다. 나머지 네 가지는 청킹 전략, 메타데이터 보강, 갱신 파이프라인 설계 같은 운영 차원에서 어느 정도 완화할 수 있는 반면, 앞의 두 가지는 벡터 유사도라는 메커니즘 자체가 만들어내는 한계라 운영으로 메우기 어렵습니다.
1) 다중 홉 추론
다중 홉 추론을 한 예로 풀어보겠습니다.
“A의 직속 상사가 누구이고, 그 상사가 작년에 담당한 프로젝트의 평균 리드 타임은 얼마였나?”
이 질문은 ‘A → 상사 → 그 상사의 프로젝트 → 프로젝트의 리드 타임’과 같이 적어도 세 번의 정보 연결이 필요합니다. 운 좋게 한 청크 안에 이 모든 정보가 들어 있으면 풀리지만, 정보가 흩어져 있으면 RAG는 답을 만들지 못합니다. 첫 번째 검색에서 “A의 상사” 정보가 담긴 청크를 가져왔다 해도, 그 결과를 받아 “그 상사의 프로젝트”를 다시 검색하는 단계가 표준 RAG 파이프라인에는 없습니다.
2) 관계의 부재
관계의 부재는 한 단계 더 깊은 문제입니다. RAG의 인덱스에는 청크가 좌표 위에 점으로 흩어져 있을 뿐, 점과 점을 잇는 선이 없습니다. “이 인물은 저 부서 소속이다”, “이 사건은 저 사건의 결과다” 같은 관계는 원본 문서에 자연어로 적혀 있어도, 인덱스 단계에서는 사라집니다. LLM이 검색 결과를 받아 추론으로 복원해 주기를 기대해야 하는데, 청크가 짧고 관계가 멀수록 이 복원은 빠르게 무너집니다.
3) 그렇다면 실무에서 RAG를 어떻게 활용해야 하는가
이 한계들이 실제 질문 유형별로 어떻게 드러나는지 정리하면 다음과 같습니다.
| 질문 유형 | 예시 | RAG 적합도 |
|---|---|---|
| 단일 사실 조회 | “환불 정책의 최대 기간은?” | ◎ 강함 |
| 의미 유사 검색 | “반려동물 보험에 대해 알려줘” | ◎ 강함 |
| 정의·요약 | “RAG란 무엇인가” | ○ 보통 |
| 다중 홉 관계 추론 | “X의 상사가 담당한 작년 프로젝트는?” | △ 약함 |
| 다중 소스 통합 결론 | “여러 부서 보고서를 종합한 위험 요인은?” | △ 약함 |
| 동음이의 분리 | “Apple 최근 동향” (회사? 과일?) | △ 약함 |
| 정확한 식별자 매칭 | “주문번호 ORD-2024-7821 상태” | × 부적합 (구조화된 검색이 더 적합) |
RAG가 강한 경우(◎)와 약한 경우(△·×)의 차이는 결국 질문이 청크 하나에 답이 들어 있는 형태인가, 청크 여러 개를 이어야 답이 만들어지는 형태인가로 갈립니다. 비유하자면 RAG는 비슷한 의미의 페이지를 찾아주는 사서입니다. 책 제목이 정확히 일치하지 않아도 비슷한 주제의 책을 가져다 줍니다. 하지만 사서가 해 주지 않는 것이 있습니다. 이 책과 저 책 사이의 관계, 이 인물과 저 인물의 연결까지는 알려주지 않습니다. 그건 책에 적혀 있어도 사서의 머릿속에 들어 있지는 않기 때문입니다.
다음 편은 여기서 출발합니다. 청크와 청크 사이의 관계를 인덱스 단계에서 어떻게 표현할 것인가. 지식 그래프(Knowledge Graph) 와 온톨로지(Ontology) 가 이 질문에 답하는 방식이고, 둘을 RAG와 결합한 구조가 GraphRAG입니다.
RAG 시리즈