너멜엠 NumLM블로그 목록

시즌 2 — AI를 만드는 손

ChatGPT는 왜 검색을 할까? — RAG를 그림으로 뜯어보기

AI는 모르는 걸 모른다고 하지 않습니다. 기억에서 지어내는 대신 문서를 찾아 읽게 만드는 장치 — 검색 증강 생성, RAG를 해부합니다.

LLM 실전·RAG · 할루시네이션·12분 읽기

RAG 검색 증강 생성 — 네이비 배경에 질문에서 문서 창고로 화살표가 이어지고, 문서 세 장을 거쳐 근거가 달린 답변으로 연결되는 넘스탯 시즌 2 대표 이미지

🧪 이 글의 모든 차트는 정지 화면입니다. 문서 창고에서 어떤 근거가 뽑히는지, 검색 방식을 바꾸면 답이 어떻게 달라지는지 — 넘스탯 RAG 실험실에서 같은 질문을 직접 돌려보며 확인할 수 있어요. (링크는 글 끝에 모아 두었습니다)

⚡ 3분 요약

👉 한 문장으로 — RAG는 "AI를 더 똑똑하게 만드는 기술"이 아니라 "AI에게 커닝 페이퍼를 쥐여 주는 기술"이에요. 검색 방식 하나로 답이 어떻게 달라지는지는, 넘스탯 RAG 실험실에서 같은 질문을 두 방식으로 돌려 보면 10초 만에 드러납니다.

지난 13편에서 어텐션을 해부하며 이런 말을 했습니다 — 어텐션은 문장 안에서 벌어지는 검색이라고요. "그것"이 Query를 던지면 "동물"의 Key가 응답하는, 그 부드러운 검색이 ChatGPT의 심장이었죠. 오늘은 그 검색의 범위를 문장 밖으로 넓힙니다. 세상의 문서를 상대로 하는 검색 — RAG입니다.

먼저 이 질문부터요. 여러분은 챗봇에게 물었다가 있지도 않은 논문 제목이나 존재하지 않는 함수 이름을 받아 본 적이 있을 겁니다. 이상한 건 그 태도예요. 모델은 머뭇거리지 않습니다. 아주 자신 있게, 심지어 그럴듯한 저자명과 연도까지 붙여서 답하죠. 왜 AI는 "모르겠다"고 하지 않을까요?

모델은 거짓말을 하는 게 아니다.
애초에 사실을 확인하는 기능이 없을 뿐이다.

이 문장을 이해하면 RAG가 왜 필요한지, 그리고 왜 RAG가 완치제가 아니라 처방전인지까지 한 번에 풀립니다. 병부터 정확히 봅시다.

STEP 1병 — 자신 있게 지어내는 AI

LLM이 하는 일은 근본적으로 하나입니다. 지금까지의 단어들을 보고, 다음에 올 가장 그럴듯한 단어를 고르는 것. 여기 어디에도 "이게 사실인가?"를 확인하는 단계는 없습니다. 사실 여부가 아니라 그럴듯함이 기준이니, 배운 적 없는 질문을 받아도 모델은 멈추지 않고 조각들을 이어 붙여 문장을 완성해 버립니다. 이 현상을 할루시네이션(hallucination, 환각)이라고 부릅니다.

그리고 또 하나의 구멍이 있어요. 모델의 지식은 학습 데이터를 수집한 시점에서 멈춰 있습니다. 이 시점을 지식 컷오프(knowledge cutoff)라고 하는데, 문제는 모델이 그 경계를 스스로 자각하지 못한다는 점입니다. 컷오프 이후에 벌어진 일을 물으면, "제가 모르는 기간입니다"가 아니라 옛 정보나 지어낸 내용이 돌아옵니다.

할루시네이션이 태어나는 두 지점
배운 조각을 이어 붙일 때, 그리고 지식 컷오프 밖을 물었을 때
모델이 가진 지식의 범위 학습 데이터로 배운 기간 컷오프 이후 — 텅 비어 있음 지식 컷오프 사용자 질문 배운 범위 안 → 대체로 정확 배운 적 없음 → 조각을 이어 붙여 "완성" "세종대왕은 전구를 발명했어요" 같은 문장이 이렇게 태어난다 모델에게는 "모른다"는 선택지가 기본값이 아니다 확률이 가장 높은 다음 단어를 고를 뿐 — 사실 확인 단계가 구조에 없다

이 "조립형 지어내기"를 눈으로 보여주고 싶어서, LLM 강의 8장에 아주 작은 실습 하나를 만들었습니다. 말뭉치에 "세종대왕은 한글을 만들었어요""에디슨은 전구를 발명했어요"만 넣어 둔 초소형 모델이에요. "세종대왕은"으로 시작하면 배운 대로 잘 답합니다. 그런데 "세종대왕은 전구를"까지 주면? 모델은 태연하게 "발명했어요"를 붙입니다. 말뭉치 어디에도 없는 문장인데도요. 조각은 배운 것이고, 조합은 지어낸 것 — 할루시네이션의 정체가 이 두 줄짜리 데모에 다 들어 있었습니다.

장난감이 아니라 진짜 모델에서도 확인하고 싶었습니다. 그래서 1억 6천만(160M) 파라미터짜리 디코더-온리 트랜스포머를 한국어 코퍼스로 직접 사전학습시키는 중인데, 학습이 94%쯤 진행된 체크포인트를 꺼내 물어봤어요 — "대한민국 수도는 어디인가요?" 이 시점의 모델은 아직 "대화하는 법"을 따로 배우지 않은, 사전학습만 된 모델입니다. 사전학습이란 방대한 글을 읽으며 "다음에 올 단어 맞히기"만 반복하는 단계예요 — 그 뒤에 질문이 오면 답을 하라는 대화 규칙을 예시로 가르치는 별도 단계 — 지도 미세조정(SFT, Supervised Fine-Tuning)이라고 부릅니다 — 가 붙어야 비로소 챗봇 꼴이 됩니다. 지금 이 모델은 그 단계 전이라, 말 그대로 이어쓰기 기계예요.

직접 사전학습 중인 160M 파라미터 한국어 모델의 생성 플레이그라운드 — '대한민국 수도는 어디인가요?'라는 질문에 '2014년 3월 6일 서울이 대한민국 수도가 되겠습니다'로 시작해 대학 주소·설립 연혁을 끝없이 이어 붙이는 출력

출력은 이렇게 시작했습니다. "2014년 3월 6일 서울이 대한민국 수도가 되겠습니다." 그리고 멈추지 않았어요. 어느 대학의 주소, 설립 연혁, 위탁 운영 기관까지 — 백과사전 문체로, 아주 그럴듯하게, 사실과 무관한 문장이 200토큰이 다 찰 때까지 이어졌습니다. 이걸 "형편없다"고만 읽으면 핵심을 놓칩니다. 이 모델은 질문에 답하고 있는 게 아니라, "대한민국 수도는 어디인가요?"라는 텍스트 뒤에 올 법한 내용을 이어 쓰고 있어요 — 사전학습이 시킨 일이 정확히 그것이니까요. 그리고 자세히 보면 발전의 신호도 있습니다. 첫 문장에서 곧바로 "서울 = 대한민국 수도"를 연결했고(연도는 지어냈지만), 이어지는 주소·기관명 나열은 학습 코퍼스에 섞어 넣은 위키 문체가 그대로 배어 나온 것이에요. 배운 대로 잘하고 있는 겁니다. 다만 배운 것이 "다음에 올 법한 텍스트"일 뿐, "묻는 말에 사실로 답하기"가 아닐 뿐이죠. 다음 토큰을 그럴듯하게 고르는 능력과, 사실을 확인해 답하는 능력은 완전히 다른 것 — 제가 만든 모델이 몸으로 보여준 셈이었습니다. (사전학습이 끝나면 지도 미세조정(SFT)으로 대화하는 법을 가르칠 차례인데, 대화 형식을 배운 뒤에도 사실이 저절로 생기지는 않습니다 — 그 빈자리를 채우는 것이 바로 오늘 이야기할 RAG예요.)

STEP 2처방 — 기억에 맡기지 말고, 문서를 쥐여 준다

시험을 떠올려 봅시다. 암기한 것만으로 답하는 폐쇄형 시험이 있고, 교재를 펴 놓고 찾아가며 답하는 오픈북 시험이 있죠. 지금까지의 LLM은 폐쇄형이었습니다. 머릿속(모델 가중치)에 있는 것만으로 답해야 하니, 기억이 흐릿하면 지어낼 수밖에요. RAG(Retrieval-Augmented Generation, 검색 증강 생성)는 이걸 오픈북으로 바꿉니다.

2020년 페이스북 AI 연구진(Lewis 외)이 낸 논문이 이 이름의 출발점입니다. 논문의 핵심 표현을 그대로 옮기면, 모델 가중치 안에 녹아 있는 파라미터 기억(parametric memory)과 바깥에 문서 형태로 놓인 비파라미터 기억(non-parametric memory)을 결합한다는 것이었어요. 앞엣것은 말하는 법을 알고, 뒤엣것은 사실을 갖고 있습니다. 둘을 합치면 말도 잘하고 근거도 있는 답이 나오죠.

RAG의 3단계 — 검색해서, 쥐여 주고, 답하게 한다
모델을 바꾸는 게 아니라 모델에게 주는 입력을 바꾼다
① 질문 "환불 기간이 며칠?" ② 문서 창고에서 검색 사내 규정 문서 교환·반품 안내 ✔ 배송 지연 공지 이벤트 안내 임베딩으로 "뜻이 가까운" 문서 선택 ③ 프롬프트에 합치기 [찾은 문서] + [질문] + "이 문서를 근거로 답하라" 근거가 붙은 답변 "수령 후 7일 이내 환불 가능합니다." 📄 출처: 교환·반품 안내 3조 모델의 가중치는 전혀 건드리지 않는다 — 창고만 갱신하면 지식도 갱신

여기서 놓치면 안 되는 포인트가 있습니다. RAG는 모델을 재학습하지 않습니다. 바뀌는 건 오직 모델에게 건네는 입력이에요. 그래서 문서 창고만 갈아 끼우면 지식이 즉시 최신이 되고, 회사 내부 문서처럼 학습에 쓰인 적 없는 자료도 바로 활용할 수 있습니다. 어느 문서를 근거로 삼았는지 출처를 함께 보여줄 수 있다는 점도 실무에서는 결정적이고요.

STEP 3검색의 심장 — 단어가 안 겹쳐도 찾아낸다

그런데 ②번 "검색"을 어떻게 하느냐가 RAG의 성패를 가릅니다. 예전 방식은 키워드 일치였어요. 질문에 나온 단어가 많이 들어간 문서를 고르는 거죠. 문제는 사람이 늘 같은 단어를 쓰지 않는다는 겁니다. "환불"을 물었는데 문서에는 "반품"이라고 적혀 있으면? 키워드 검색은 그 문서를 놓칩니다. 반대로 "쿠폰 유효기간"처럼 엉뚱하게 글자만 겹치는 문서를 1등으로 끌어오기도 하고요.

그래서 현대 RAG는 임베딩을 씁니다. 질문도 문서도 전부 같은 좌표 공간의 점으로 바꾼 다음, 질문 점에서 가까운 문서 점을 고르는 거예요. 이 공간에서는 거리가 곧 의미라서, "환불"과 "반품"은 단어가 달라도 이웃입니다. 이런 방식을 밀집 검색(dense retrieval)이라 부르는데, 2020년 DPR 논문의 실측치를 보면 상위 20개 문서를 뽑는 정확도에서 키워드 검색(BM25)보다 9~19%p 높았습니다.

의미로 찾는 검색 — 좌표가 가까우면 뜻이 가깝다
질문과 문서를 같은 공간의 점으로 바꾸면, 단어가 겹치지 않아도 찾아낸다
임베딩 좌표 공간 (실제로는 수백 차원) 단어 0개 겹침 — 그래도 이웃 교환·반품 안내 질문 "환불 기간이 며칠?" 가깝다 ✔ 쿠폰 유효"기간" 글자는 겹치지만 뜻은 멀다 멀다 배송 지연 공지 두 검색의 차이 키워드 검색 "환불" 글자를 찾는다 → "반품" 문서를 놓친다 임베딩 검색 뜻이 가까운 점을 찾는다 → "반품" 문서를 찾아낸다 상위 20개 정확도 +9~19%p ※ 수치는 DPR 논문(Karpukhin 외, 2020)이 BM25와 비교해 보고한 실측 범위

🧪 이 대결, 직접 돌려볼 수 있습니다 — 넘스탯 RAG 실험실은 고객센터 문서 15건짜리 창고에 같은 질문을 던져 어휘 검색과 의미 검색이 각각 무엇을 집어오는지 나란히 보여줍니다. 어휘 검색의 색인·점수는 브라우저에서 실제로 계산되고, 의미 검색 쪽은 6개 의미 축 좌표로 코사인 값이 어떻게 나오는지 계산 과정까지 펼쳐 보여줍니다.

이 실험실을 만들면서 저는 제 예상이 틀리는 걸 봤습니다. "환불 기간이 며칠인가요?"의 함정 문서로 당연히 "기간 한정 할인 이벤트"가 1등일 줄 알고 검증 코드에 그렇게 적어 뒀는데, 돌려 보니 "쿠폰 유효기간"이 1등이더군요. 이유를 따라가 보니 이랬습니다 — 검색기는 질문을 두 글자씩 끊어 [환불] [기간] [간이]로 봅니다. 그런데 "쿠폰 유효기간이 지나면"이라는 문장에는 [기간]과 [간이]가 둘 다 들어 있어요. 반면 "기간 한정"에는 [기간]만 있습니다. 조각 하나 차이로 순위가 뒤집힌 겁니다. 정답 문서에는 "환불"도 "기간"도 없고 "수령 후 7일 이내"라고만 적혀 있어, 애초에 걸릴 수가 없었고요. 제 직관이 아니라 코드가 맞았습니다.

질문 5개로 전체를 재 보니 격차는 이렇게 나왔습니다 — 1순위 문서만 볼 때(Hit@1) 어휘 검색 3/5, 의미 검색 5/5. 다만 상위 3건까지 보면(Hit@3) 둘 다 5/5로 같아집니다. 그리고 "현금영수증 재발급"처럼 고유한 단어가 정확히 일치하는 질문에서는 어휘 검색도 1등이 정답이었어요. 의미 검색이 항상 이기는 게 아니라는 것, 이게 실무에서 두 방식을 함께 쓰는 이유입니다.

STEP 4쥐여 주는 기술 — 어디에 놓느냐가 성적을 바꾼다

문서를 찾았다면 이제 모델에게 건네야 합니다. 그런데 문서 전체를 통째로 넣을 수는 없어요. 모델이 한 번에 볼 수 있는 분량(문맥 창)에 한계가 있으니, 보통 문서를 문단 크기의 조각(청크)으로 잘라 두고 관련도 높은 상위 몇 개만 넣습니다.

여기서 많은 사람이 놓치는 함정이 하나 있습니다. 근거를 어디에 놓느냐에 따라 정답률이 달라진다는 거예요. 2023년 스탠퍼드 연구진(Liu 외)의 실험 결과가 유명한데, 논문의 표현을 그대로 옮기면 — 관련 정보가 입력의 앞이나 뒤에 있을 때 성능이 가장 높고, 긴 문맥의 한가운데에서 정보를 찾아야 할 때 성능이 크게 떨어진다고 합니다. 논문 제목 자체가 "Lost in the Middle(중간에서 길을 잃다)"이에요.

근거를 문맥 한가운데 넣으면 잘 안 읽힌다
Liu 외(2023, TACL)가 보고한 경향의 개념 도식 — 정확한 수치는 논문 참조
높음 낮음 ↑ 정답률 앞쪽에 두면 문맥 시작 한가운데 — 가장 낮다 문맥 중간 뒤쪽에 두면 문맥 끝 근거 문서의 위치가 같아도, 어디에 넣느냐에 따라 모델이 읽어내는 정도가 달라진다 실무 팁 — 중요한 근거일수록 앞이나 뒤에, 그리고 넣는 문서 수를 무작정 늘리지 않기

그래서 "문서를 많이 넣을수록 좋다"는 직관은 틀립니다. 문맥이 길어지면 정작 중요한 근거가 중간에 묻혀 버리거든요. 실무에서 RAG 성능을 올리는 작업의 상당 부분이 모델 튜닝이 아니라 무엇을, 몇 개나, 어떤 순서로 넣을지를 다듬는 일인 이유입니다.

STEP 5정직하게 — RAG는 완치제가 아니다

여기까지 읽으면 RAG가 만능처럼 보일 수 있는데, 그렇지 않습니다. 한계를 분명히 해 둬야 제대로 쓸 수 있어요.

그래서 정확한 표현은 이렇습니다 — RAG는 할루시네이션을 없애는 기술이 아니라, 크게 줄이면서 틀렸을 때 확인할 수 있게 만드는 기술입니다. 출처가 함께 오니까요. 실무에서 함께 쓰는 습관 세 가지도 같은 맥락이에요 — 출처를 요구하고, 온도(temperature)를 낮추고, 중요한 답은 모델 바깥에서 교차 검증하기.

자주 나오는 질문 하나만 정리하고 갈게요. "파인튜닝이랑 뭐가 다른가요?" 파인튜닝은 모델의 말투와 능력을 바꾸는 일이고, RAG는 모델에게 사실을 공급하는 일입니다. STEP 1의 제 160M 모델을 떠올려 보세요 — 앞으로 지도 미세조정(SFT)으로 대화하는 법을 가르치면 "질문에 답하는 형식"은 배우겠지만, 그것으로 사실이 생기지는 않습니다. 말하는 법은 파인튜닝(SFT)이, 사실은 RAG가 채웁니다. 회사 문서로 답하는 챗봇이 필요하다면 먼저 RAG를 검토하는 게 보통이에요 — 문서가 바뀔 때마다 재학습할 수는 없으니까요. 둘은 경쟁 관계가 아니라 역할이 다른 도구입니다.

🔗 시즌 2 네 편이 한 줄로 — 11편의 역전파는 배우는 방법, 12편의 CNN은 보는 구조, 13편의 어텐션은 읽는 구조, 그리고 오늘의 RAG는 모르는 것을 찾아오는 방법입니다. 재미있는 건 RAG의 검색조차 13편에서 본 그 원리 — Query와 Key의 유사도로 관련도를 재는 것 — 을 문서 단위로 확장한 것이라는 점이에요. 문장 안의 검색이 문장 밖으로 나간 셈입니다.

✅ 30초 복습 — 오늘 배운 것

RAG, 읽었다면 이제 직접 돌려볼 차례

넘스탯(NumStats) RAG 실험실에서는 문서 15건 창고에 같은 질문을 던져 두 검색 방식을 대결시키고,
코사인 유사도 계산 전개와 프롬프트가 조립되는 과정까지 단계별로 확인할 수 있습니다.

🧪 RAG 검색 대결 직접 돌려보기 → RAG 이론 단계별 학습 →

numlm.com/llm-lab/rag · numlm.com 이론 · RAG 검색 증강 생성

한 발 더 들어가고 싶다면

시즌 2는 학습 엔진 위에 구조를 하나씩 얹어 왔고, 이제 마지막 한 편이 남았습니다.

참고 자료

본문의 용어·수치·실험 결과는 다음 원문을 기준으로 작성했습니다.

마무리 — 모른다고 말할 수 있게 만드는 일

오늘 내용을 한 줄로 줄이면 이렇습니다. "RAG는 AI를 더 똑똑하게 만드는 게 아니라, 답하기 전에 근거를 찾아보게 만드는 장치다." 모델의 머리를 키우는 대신 책상 위에 자료를 올려 두는 쪽을 택한 해법이죠. 그래서 값도 싸고, 지식도 즉시 갱신되고, 무엇보다 틀렸을 때 어디서 틀렸는지 짚을 수 있습니다.

이제 기계는 배우는 법(11편), 보는 법(12편), 읽는 법(13편), 그리고 찾아보는 법(오늘)을 갖췄습니다. 시즌 2의 마지막 편에서는 이 기계가 스스로 도구를 골라 일을 처리하는 법AI Agent와 Tool Use를 해부합니다.

가장 믿을 만한 AI는
모든 걸 아는 AI가 아니라, 근거를 대는 AI입니다.

다음 편에서 만나요.

넘스탯(NumStats) — 확률부터 LLM까지, 원리부터 제대로 배우는 자기주도 학습 플랫폼

🔗 numlm.com

#RAG #검색증강생성 #할루시네이션 #ChatGPT원리 #LLM #임베딩 #AI공부

※ 이 글은 LLM 도구를 활용해 초안을 작성한 뒤, 학술 출처와 수치 정확성은 발행 전 직접 검증·편집했습니다. 본문에 사실과 다른 부분을 발견하시면 댓글로 알려주시면 즉시 반영하겠습니다.