RAG가 단순히 '검색 후 생성'이라고? 수학적 실체는 전혀 다르다

많은 이들이 RAG를 단순한 데이터 검색 도구로 오해하지만, 실제로는 확률 분포의 조건부 최적화 과정이며 이를 이해해야만 할루시네이션을 잡을 수 있습니다.

대부분의 기업과 개발자들이 RAG(Retrieval-Augmented Generation, 검색 증강 생성)를 도입할 때 가지는 생각은 단순합니다. ‘LLM이 모르는 최신 데이터나 내부 문서를 데이터베이스에서 찾아와서 프롬프트에 넣어주면, AI가 그걸 읽고 대답하겠지’라는 식의 논리입니다. 마치 오픈북 테스트를 치르는 학생처럼, 옆에 참고서를 두고 정답을 베껴 쓰는 과정으로 이해하는 것입니다. 하지만 이러한 직관적인 이해는 RAG의 실제 작동 방식과 그 한계를 파악하는 데 있어 치명적인 오해를 불러일으킵니다.

우리가 RAG를 단순한 ‘검색 + 생성’의 결합으로만 본다면, 왜 여전히 할루시네이션(환각 현상)이 발생하는지, 왜 검색 결과가 정확함에도 불구하고 엉뚱한 답변이 나오는지 설명할 수 없습니다. RAG의 본질은 단순한 텍스트의 결합이 아니라, 모델이 생성해야 할 토큰의 확률 분포를 외부 지식을 통해 강제로 변형시키는 수학적 과정에 가깝기 때문입니다.

RAG의 수학적 실체: 조건부 확률의 재구성

LLM은 기본적으로 다음에 올 가장 확률 높은 토큰을 예측하는 확률 모델입니다. 일반적인 생성 과정에서 모델은 자신이 학습한 내부 파라미터 $\theta$에 의존하여 $P(y|x; \theta)$를 계산합니다. 여기서 $x$는 질문이고 $y$는 답변입니다. 하지만 RAG는 여기에 ‘검색된 문서’라는 새로운 조건 $z$를 추가합니다. 즉, 확률 식은 $P(y|x, z; \theta)$로 변합니다.

여기서 중요한 점은 $z$(검색된 문서)가 단순히 텍스트로 추가되는 것이 아니라, 모델이 주목해야 할 ‘어텐션(Attention)’의 가중치를 완전히 뒤바꾼다는 것입니다. 수학적으로 보면, RAG는 모델의 사전 지식(Parametric Memory)과 외부 지식(Non-parametric Memory) 사이의 충돌을 해결하는 최적화 과정입니다. 만약 검색된 문서 $z$가 모델이 이미 알고 있는 강한 편향과 충돌한다면, 모델은 수학적으로 더 높은 확률을 가진 ‘잘못된 내부 지식’을 선택할 가능성이 큽니다. 이것이 바로 검색 결과가 맞는데도 AI가 거짓말을 하는 근본적인 이유입니다.

단순 RAG가 실패하는 결정적인 이유들

많은 실무자가 겪는 RAG의 한계는 기술적 구현의 미숙함보다는 RAG의 작동 원리에 대한 오해에서 비롯됩니다. 단순히 벡터 DB에 데이터를 넣고 유사도 검색(Cosine Similarity)을 돌린다고 해서 정답이 도출되지 않는 이유는 다음과 같습니다.

의미적 유사성과 정답의 불일치: 벡터 검색은 ‘의미적으로 유사한’ 문장을 찾을 뿐, ‘질문에 대한 정답’을 찾는 것이 아닙니다. 질문과 단어 구성이 비슷하지만 내용은 전혀 다른 문서가 상위에 랭크될 때, 모델은 그 오답을 정답으로 믿고 생성하게 됩니다.
컨텍스트 윈도우의 노이즈: 너무 많은 검색 결과를 프롬프트에 넣으면 ‘Lost in the Middle’ 현상이 발생합니다. 모델이 입력값의 중간 부분에 있는 핵심 정보를 무시하고 앞뒤 정보에만 가중치를 두는 수학적 특성 때문입니다.
구조적 데이터 해석 능력의 부재: PDF의 표나 복잡한 레이아웃은 단순 텍스트 청킹(Chunking) 과정에서 파괴됩니다. 수학적으로 파편화된 데이터는 모델에게 아무런 맥락을 제공하지 못하며, 결국 모델은 부족한 정보를 자신의 내부 파라미터로 메우려다 환각을 일으킵니다.

고급 RAG로 나아가기 위한 전략적 접근

단순한 ‘검색-생성’ 루프를 넘어, 수학적 확률 분포를 제어하기 위해서는 더 정교한 파이프라인이 필요합니다. 이제는 단순히 데이터를 넣는 것이 아니라, 데이터가 모델에 전달되는 ‘경로’를 최적화해야 합니다.

먼저 쿼리 변형(Query Transformation) 단계가 필수적입니다. 사용자의 질문을 그대로 검색어로 쓰는 것이 아니라, LLM을 이용해 검색에 최적화된 여러 개의 가상 질문으로 확장(Multi-Query)하거나, 질문의 의도를 분석해 검색 쿼리를 재작성해야 합니다. 이는 검색 단계에서의 재현율(Recall)을 수학적으로 높이는 작업입니다.

다음으로는 재순위화(Re-ranking) 과정입니다. 벡터 유사도만으로는 부족합니다. 1차적으로 검색된 상위 K개의 문서들을 다시 한번 정밀한 Cross-Encoder 모델에 통과시켜, 질문과의 실제 관련성을 다시 계산해야 합니다. 이는 단순한 거리 계산이 아니라 두 문장 사이의 상호작용을 직접 계산하는 방식이기에 훨씬 정확합니다.

실무 적용을 위한 단계별 액션 가이드

RAG 시스템의 성능을 비약적으로 높이고 싶은 기업이나 개발자라면 다음의 순서로 시스템을 개선하십시오.

데이터 전처리 최적화: 단순 글자 수 기반 청킹을 버리고, 의미 단위(Semantic Chunking) 또는 문서 구조(Markdown, HTML) 기반의 청킹을 도입하십시오. 특히 표 데이터는 Markdown 형식으로 변환하여 문맥을 보존해야 합니다.
하이브리드 검색 도입: 벡터 검색(Dense Retrieval)과 키워드 검색(BM25, Sparse Retrieval)을 결합하십시오. 고유 명사나 특정 제품 번호 같은 정밀한 검색은 여전히 키워드 방식이 수학적으로 더 정확합니다.
검색 결과 필터링 및 정제: 검색된 문서 중 관련성이 낮은 내용을 제거하는 ‘필터링’ 단계를 추가하십시오. 불필요한 노이즈를 제거하는 것만으로도 모델의 생성 정확도가 크게 향상됩니다.
평가 프레임워크 구축: RAGAS나 TruLens 같은 도구를 사용하여 ‘충실도(Faithfulness)’, ‘답변 관련성(Answer Relevance)’, ‘컨텍스트 정밀도(Context Precision)’를 수치화하십시오. 감에 의존한 튜닝은 끝이 없습니다.

결론: 도구가 아니라 시스템으로 바라보라

RAG는 단순히 LLM에 외부 데이터를 붙이는 ‘플러그인’이 아닙니다. 그것은 데이터 엔지니어링, 정보 검색(IR), 그리고 확률적 언어 모델링이 정교하게 맞물려 돌아가는 하나의 ‘시스템’입니다. RAG가 생각보다 성능이 안 나온다고 느낀다면, 그것은 RAG라는 개념이 틀려서가 아니라 우리가 RAG를 너무 단순하게 생각했기 때문일 가능성이 큽니다.

결국 핵심은 모델이 생성하는 확률 분포를 우리가 원하는 방향으로 얼마나 정확하게 유도하느냐에 달려 있습니다. 이를 위해서는 단순한 프롬프트 엔지니어링을 넘어, 데이터의 구조화와 검색 알고리즘의 고도화라는 본질적인 접근이 필요합니다. 지금 당장 여러분의 RAG 파이프라인에서 ‘검색된 문서가 정말 정답을 포함하고 있는가’와 ‘모델이 그 정답을 선택할 확률이 충분히 높은가’를 분리해서 측정해 보시기 바랍니다.

FAQ

RAG Is Not What You Think It Is. The Math Says Something Else Entirely의 핵심 쟁점은 무엇인가요?

핵심 문제 정의, 비용 구조, 실제 적용 방법, 리스크를 함께 봐야 합니다.

RAG Is Not What You Think It Is. The Math Says Something Else Entirely를 바로 도입해도 되나요?

작은 범위에서 실험하고 데이터를 확인한 뒤 단계적으로 확대하는 편이 안전합니다.

실무에서 가장 먼저 확인할 것은 무엇인가요?

목표 지표, 대상 사용자, 예산 범위, 운영 책임자를 먼저 명확히 해야 합니다.

법률이나 정책 이슈도 함께 봐야 하나요?

네. 데이터 수집 방식, 플랫폼 정책, 개인정보 관련 제한을 반드시 점검해야 합니다.

성과를 어떻게 측정하면 좋나요?

비용, 전환율, 클릭률, 운영 공수, 재사용 가능성 같은 지표를 함께 보는 것이 좋습니다.

지금 바로 시작할 수 있는 실무 액션

현재 팀의 AI 활용 범위와 검증 절차를 먼저 문서화합니다.
작은 파일럿 프로젝트로 KPI를 정하고 2~4주 단위로 검증합니다.
보안, 품질, 리뷰 기준을 자동화 도구와 함께 연결합니다.

RAG가 단순히 ‘검색 후 생성’이라고? 수학적 실체는 전혀 다르다