최근 LLM을 활용한 서비스를 개발하면서 RAG(Retrieval-Augmented Generation)라는 기술을 자주 접하게 된다.
RAG는 LLM이 답변을 생성할 때 외부 지식이나 문서를 검색해 활용하도록 만드는 접근 방식이다.
쉽게 말하면 AI가 자신의 학습 데이터에만 의존하지 않고, 필요한 자료를 찾아본 뒤 답변하도록 만드는 것이다.
그렇다면 정답이 들어 있는 문서를 제공하기만 하면 정확한 답변을 얻을 수 있을까?
그렇지 않다.
관련 문서를 검색했는데도 틀린 답을 생성할 수 있다.
심지어 정답이 명확하게 적힌 문서를 제공했는데도 존재하지 않는 내용을 만들어내는 경우가 있다.
정답을 알려줬는데 왜 AI는 여전히 틀린 답을 할까?
이 문제를 이해하려면 RAG를 단순히 문서 검색과 LLM 호출의 조합으로 보는 것에서 벗어날 필요가 있다.
1. RAG는 어떻게 동작할까?
일반적인 LLM은 학습 과정에서 습득한 패턴과 입력된 문맥을 바탕으로 답변을 생성한다.
하지만 특정 기업의 내부 문서나 최근에 변경된 규정처럼 학습 과정에서 접하지 못한 정보에는 한계가 있다.
RAG는 이러한 문제를 보완하기 위해 외부 지식 검색 단계를 추가한다.
구조를 단순화하면 다음과 같다.
사용자 질문
|
▼
검색 시스템(Retriever)
|
▼
관련 문서 검색
|
▼
질문 + 검색 문서
|
▼
LLM(Generator)
|
▼
최종 답변예를 들어 회사 내부 규정을 검색하는 AI를 만든다고 가정하자.
사용자가 다음과 같이 질문한다.
“신입사원의 연차휴가는 어떻게 계산되나요?”
검색 시스템은 관련 인사 규정 문서를 찾는다.
LLM은 검색된 문서를 참고해 답변한다.
겉보기에는 단순한 구조다.
하지만 자세히 살펴보면 두 개의 서로 다른 문제가 존재한다.
첫째, 검색 시스템이 필요한 문서를 정확하게 찾았는가?
둘째, LLM이 검색한 문서의 내용을 정확하게 활용했는가?
이 두 문제가 RAG 시스템의 품질을 좌우한다.
2. 첫 번째 문제: 검색 결과가 정확하지 않다
RAG 시스템을 구축할 때 흔히 사용하는 방법이 벡터 검색이다.
문서와 질문을 임베딩 모델을 이용해 벡터로 변환하고, 벡터 사이의 유사도를 계산해 관련 문서를 찾는다.
사용자 질문
|
▼
Embedding Model
|
▼
질문 벡터
|
▼
Vector Database
|
▼
유사한 문서 검색이때 자주 사용하는 지표 중 하나가 코사인 유사도(Cosine Similarity)다.
코사인 유사도는 두 벡터가 이루는 각도를 기준으로 방향이 얼마나 유사한지 측정한다.
의미적으로 비슷한 문장을 찾는 데 유용하다.
예를 들어 “휴가를 어떻게 신청하나요?”라는 질문과 “휴가 신청 절차 안내”라는 문서가 유사하게 검색될 수 있다.
그런데 의미적으로 비슷하다는 것이 반드시 정답이라는 뜻은 아니다.
다음 두 문서를 생각해 보자.
문서 A
2025년 신입사원 연차휴가 규정
문서 B
2026년 신입사원 연차휴가 규정두 문서는 의미적으로 매우 유사하다.
하지만 사용자가 2026년 규정을 질문했는데 2025년 문서가 검색된다면 잘못된 답변으로 이어질 수 있다.
문서가 서로 비슷하다는 사실과 현재 질문에 대한 정답이라는 사실은 별개의 문제다.
이 문제는 문서의 버전, 날짜, 숫자, 제품 코드 등 정확한 정보가 중요한 상황에서 더 두드러진다.
키워드 검색과 벡터 검색을 함께 사용한다면?
이를 보완하기 위한 방법 중 하나가 Hybrid Search다.
BM25와 같은 키워드 검색과 Dense Vector Search를 결합하는 방식이다.
BM25는 질문과 문서에 등장하는 단어들의 관련성을 이용해 검색 점수를 계산한다.
반면 Dense Vector Search는 임베딩을 이용해 의미적인 유사성을 찾는다.
| 구분 | BM25 | Dense Vector Search |
|---|---|---|
| 주요 기준 | 단어 및 통계적 관련성 | 의미적 유사성 |
| 강점 | 정확한 용어, 코드, 특정 표현 | 표현이 다른 유사 의미 탐색 |
| 한계 | 표현이 달라지면 검색에 불리할 수 있음 | 정확한 숫자나 식별자 구분에 약할 수 있음 |
두 검색 결과를 결합하는 방법으로 RRF(Reciprocal Rank Fusion)를 사용할 수 있다.
RRF는 서로 다른 검색 결과의 순위를 이용해 결합 점수를 계산한다.
[
RRF(d)=\sum_{r\in R}\frac{1}{k+\operatorname{rank}_r(d)}
]
여기서 rank는 각 검색 시스템에서 해당 문서가 차지한 순위이고, k는 순위 점수의 영향을 조절하는 상수다.
RRF는 서로 다른 검색 시스템의 원래 점수 범위가 달라도 순위를 기준으로 결과를 결합할 수 있다는 장점이 있다.
하지만 하이브리드 검색을 도입했다고 해서 모든 검색 오류가 사라지는 것은 아니다.
검색 품질은 문서 분할(Chunking), 메타데이터 필터링, 임베딩 모델, 재정렬(Reranking) 등의 영향을 받는다.
그리고 무엇보다 관련 문서를 찾았다는 것만으로 정확한 답변이 보장되지는 않는다.
3. 두 번째 문제: 검색은 성공했는데 답변이 틀리다
이번에는 검색이 정확하게 이루어졌다고 가정하자.
사용자가 다음과 같이 질문한다.
“프로젝트 발표 시간은 몇 분인가요?”
검색 시스템은 다음 문서를 찾았다.
[프로젝트 운영 안내]
최종 발표 시간은 팀당 10분이며,
이후 5분간 질의응답을 진행한다.정답은 명확하다.
발표 10분, 질의응답 5분이다.
그런데 LLM이 다음과 같이 답변했다고 가정하자.
“최종 발표는 팀당 15분이며, 이후 별도로 질의응답을 진행합니다.”
검색된 문서는 정확했지만 답변은 틀렸다.
LLM이 발표와 질의응답 시간을 혼동하거나, 검색 문서에 없는 내용을 만들어낸 것이다.
이처럼 생성된 답변이 제공된 근거와 일치하지 않는 현상을 RAG의 생성 단계 오류로 볼 수 있다.
흔히 할루시네이션(Hallucination)이라는 용어로 설명하기도 한다.
여기서 중요한 점은 검색과 생성이 서로 다른 과정이라는 사실이다.
검색 성능이 좋다고 해서 생성 결과까지 반드시 정확한 것은 아니다.
4. RAG의 성능은 어떻게 평가할까?
일반적인 소프트웨어 테스트에서는 예상 결과와 실제 결과를 비교한다.
하지만 LLM은 동일한 의미의 답변을 여러 형태로 생성할 수 있다.
따라서 문자열이 정확히 일치하는지만 확인하는 방식으로는 품질을 평가하기 어렵다.
RAG 시스템에서는 검색 단계와 생성 단계를 나누어 평가할 필요가 있다.
대표적인 평가 지표를 살펴보자.
| 평가 지표 | 확인하는 내용 |
|---|---|
| Context Precision | 검색된 문서의 상위 순위에 관련 문서가 얼마나 잘 배치되는가 |
| Context Recall | 답변에 필요한 근거가 검색 결과에 충분히 포함되어 있는가 |
| Faithfulness | 생성된 답변의 주장들이 검색된 근거로 뒷받침되는가 |
| Answer Relevancy | 생성된 답변이 사용자 질문과 관련 있는가 |
이러한 지표를 활용하는 프레임워크로 RAGAS가 있다.
특히 Faithfulness는 흥미로운 개념이다.
답변이 검색된 문서의 내용을 얼마나 충실하게 반영하는지 평가한다.
가령 다음과 같은 상황을 생각해 보자.
검색된 문서:
발표 10분, 질의응답 5분
생성된 답변:
발표 15분, 질의응답 5분이 경우 생성된 답변의 일부 주장은 검색 문서와 일치하지 않는다.
Faithfulness 평가를 통해 이러한 문제를 발견할 수 있다.
다만 Faithfulness가 높다고 해서 항상 실제 세계의 사실과 일치한다는 의미는 아니다.
잘못된 문서를 충실하게 인용한 답변도 그 문서에 대한 Faithfulness는 높을 수 있기 때문이다.
따라서 검색된 문서 자체의 정확성과 최신성도 함께 관리해야 한다.
또한 LLM 기반 평가 지표는 평가 모델의 판단에 영향을 받으므로 절대적인 정답 판정기로 생각해서는 안 된다.
5. 프롬프트만 수정하면 해결되지 않을까?
생성 오류가 발생하면 가장 먼저 프롬프트를 수정하고 싶어진다.
예를 들어 다음과 같은 지침을 추가할 수 있다.
당신은 문서 기반 질의응답 시스템이다.
제공된 문서에 있는 정보만 사용하여 답변하라.
문서에 정답이 없다면
"제공된 문서에서 확인할 수 없습니다."
라고 답변하라.이러한 지침은 도움이 될 수 있다.
하지만 프롬프트만으로 모든 오류를 방지할 수는 없다.
검색 단계에서 잘못된 문서를 가져왔다면 LLM이 아무리 충실하게 답변하더라도 잘못된 정보가 전달될 수 있다.
검색된 문서가 서로 충돌하는 경우에도 우선순위를 판단해야 한다.
더 나아가 외부 문서 자체에 LLM의 지침을 바꾸려는 악의적인 내용이 포함되어 있다면 Prompt Injection 문제까지 고려해야 한다.
외부에서 검색한 문서는 신뢰할 수 있는 시스템 지침이 아니라, 검증이 필요한 데이터로 취급해야 한다.
따라서 RAG 시스템에서는 프롬프트 외에도 다음과 같은 전략을 고려할 수 있다.
- 문서의 출처와 최신 버전을 관리한다.
- 정확한 키워드 검색과 의미 검색을 결합한다.
- 필요한 경우 검색 결과를 재정렬한다.
- 답변에 사용한 근거 문서를 함께 제시한다.
- 근거가 부족하면 무리하게 답변하지 않도록 한다.
- 검색 실패와 생성 실패를 구분해 평가한다.
여기서 마지막 항목이 중요하다.
RAG의 답변이 틀렸다면 무조건 LLM의 성능 탓으로 돌릴 것이 아니라, 검색 단계에서 어떤 문서를 제공했는지부터 확인해야 한다.
6. RAG의 핵심은 검색이 아니라 근거다
처음 질문으로 돌아가 보자.
정답 문서를 제공했는데도 AI가 틀린 답을 하는 이유는 무엇일까?
크게 두 가지 가능성이 있다.
검색 시스템이 실제로 필요한 문서를 정확히 전달하지 못했거나, LLM이 전달된 문서를 충실하게 활용하지 못했기 때문이다.
물론 실제 시스템에서는 더 많은 요인이 복합적으로 작용한다.
문서의 품질, 분할 방식, 메타데이터, 검색 전략, 재정렬 모델, 프롬프트, 생성 모델 등이 모두 결과에 영향을 줄 수 있다.
따라서 RAG를 단순히 벡터 데이터베이스에 문서를 저장하고 LLM에 전달하는 기술로 이해해서는 부족하다.
검색된 문서가 정확한지, 생성된 답변이 그 문서에 근거하고 있는지, 문서 자체가 최신이고 신뢰할 수 있는지까지 검증하는 과정이 필요하다.
RAG의 목적은 단순히 AI에게 더 많은 정보를 제공하는 것이 아니라, 답변이 어떤 근거에서 나왔는지 확인할 수 있도록 만드는 데 있다고 생각한다.
잘못된 답변을 유창하게 생성하는 시스템보다는, 필요한 근거가 부족할 때 답변을 보류할 수 있는 시스템이 더 신뢰할 만하다.
결국 중요한 것은 AI가 얼마나 그럴듯하게 말하는지가 아니다.
AI의 답변을 신뢰할 수 있는 이유를 시스템이 얼마나 명확하게 제시할 수 있는가다.
생각해 볼 문제
Q1. BM25와 Dense Vector Search는 각각 어떤 상황에서 강점을 가질까?
Q2. RAG 시스템에서 검색된 문서가 정확한데도 잘못된 답변이 생성되었다. 어느 단계를 조사해야 할까?
Q3. Faithfulness 점수가 높다면 해당 답변은 반드시 사실이라고 볼 수 있을까?