RAG 개념 공부, 문서 검색과 생성을 붙이는 구조

 

요즘 AI 관련 글을 읽다 보면 RAG라는 말이 정말 자주 나옵니다.
Retrieval-Augmented Generation, 우리말로 하면 "검색으로 보강한 생성" 정도가 되겠네요.
처음에는 이름이 어렵게 느껴졌는데, 공부해 보니 아이디어 자체는 꽤 단순했어요.
모델이 모르는 내용을 찾아서 읽게 한 뒤에 답하게 하는 구조입니다.
예약 서비스에 자주 묻는 질문(FAQ) 응답을 붙인다면 어떻게 쓸 수 있을지를 떠올리며 공부한 내용을 정리해 봅니다.
직접 서비스에 적용해 본 이야기가 아니라, 개념을 이해하고 아이디어를 그려본 기록이라는 점을 먼저 말씀드려요.

 

ChatGPT 같은 모델은 학습한 데이터를 바탕으로 답합니다.
그래서 아무리 똑똑해도 모르는 것이 두 종류 있어요.
하나는 학습 이후에 생긴 새로운 정보이고, 다른 하나는 공개되지 않은 우리 쪽 문서입니다.

예를 들어 가상의 미용실 하나가 있다고 해볼게요.
이 업장의 "예약 변경은 방문 3시간 전까지, 파마 서비스는 보증금 1만 원, 주차는 건물 지하 1층 2시간 무료"라는 규정은 모델이 알 수 없는 정보입니다.
이걸 모른 채로 "주차 되나요?"라는 질문을 받으면, 모델은 모른다고 하기보다 그럴듯한 답을 지어낼 수 있어요.
이 문제를 줄이는 방법으로 크게 두 가지를 봤습니다.
모델을 업장 정보로 다시 학습시키는 방법과, 질문이 들어올 때마다 관련 문서를 찾아서 같이 보여주는 방법입니다.
앞의 것은 비용과 손이 많이 들고 정보가 바뀔 때마다 다시 해야 하는 반면, 뒤의 것이 바로 RAG예요.
규정이 바뀌면 문서만 고치면 되니까, 업장마다 내용이 다른 서비스에는 특히 잘 맞는다고 생각했습니다.

 

RAG의 흐름은 크게 준비 단계와 질문 단계로 나눠서 이해하면 쉬웠어요.

준비 단계에서는 문서를 쪼개고 검색할 수 있는 형태로 바꿔 둡니다.
먼저 청킹입니다.
긴 문서를 의미가 이어지는 작은 조각으로 나누는 일이에요.
FAQ라면 "질문과 답변 한 쌍"이 자연스러운 한 조각이 되겠죠.
그다음이 임베딩입니다.
각 조각의 의미를 숫자 목록(벡터)으로 바꿔서, 의미가 비슷한 글은 숫자도 비슷해지도록 만드는 과정이에요.
이렇게 만든 숫자들을 저장해 둔 곳이 벡터 저장소입니다.

질문 단계에서는 이 준비물을 활용합니다.
고객 질문이 들어오면 같은 방식으로 숫자로 바꾸고, 저장된 조각들 중 가장 가까운 몇 개를 찾습니다(검색).
그리고 찾은 조각을 질문과 함께 모델에게 건네며 "아래 자료만 근거로 답하세요"라고 지시해요(생성).
결국 모델은 자기 기억이 아니라 눈앞에 놓인 자료를 읽고 답하는 셈입니다.

이 구조를 한 줄로 줄이면 "찾고, 붙이고, 답하게 한다"예요.
이렇게 단순화해서 이해하니, 각 단계에서 무엇이 잘못될 수 있는지도 보이기 시작했습니다.

 

예약 서비스에서 운영자가 가장 반복적으로 받는 문의는 비슷한 질문들입니다.
"주차 되나요?", "예약 변경은 언제까지 가능해요?", "미성년자도 이용할 수 있나요?" 같은 것들이죠.
이걸 업장마다 문서로 정리해 두면 챗봇이 대신 답해 줄 수 있을 거라고 생각했어요.

테넌트 구조에서는 한 가지가 특히 중요합니다.
업장마다 FAQ가 다르기 때문에, 검색할 때 "이 업장의 문서 안에서만" 찾아야 해요.
A 업장의 질문에 B 업장의 정책이 섞여서 나오면 큰 문제가 됩니다.
그래서 벡터 저장소의 각 조각에 업장 식별자를 붙여 두고, 검색 시 반드시 그 값으로 걸러내는 구조가 필요하다고 정리했어요.
앞에서 공부한 데이터 격리 내용이 여기서도 그대로 이어지는 셈입니다.

답변 방식은 이렇게 구상해 봤습니다.
검색 결과가 충분히 관련 있어 보일 때만 답하고, 그렇지 않으면 "정확한 안내를 위해 매장에 확인해 주세요"라고 넘기는 방식입니다.
검색된 조각의 출처(어느 FAQ 항목인지)를 함께 보여주면 고객도 운영자도 근거를 확인할 수 있어요.

 

공부하면서 RAG가 만능이 아니라는 점도 분명히 알게 됐습니다.

첫째, 검색이 틀리면 답도 틀립니다.
엉뚱한 조각을 가져오면 모델은 그걸 근거로 열심히 틀린 답을 만들어요.
문서를 어떻게 쪼갰는지, 한 조각의 크기가 적당한지에 따라 검색 품질이 크게 달라진다고 합니다.

둘째, 문서에 없는 질문입니다.
FAQ에 없는 내용을 물으면 가장 비슷한 조각을 억지로 가져올 수 있어서, "모른다고 말하게 하는 설계"가 따로 필요해요.

셋째, 문서가 낡으면 답도 낡습니다.
가격이나 영업시간이 바뀌었는데 문서를 갱신하지 않으면 틀린 안내를 하게 되니까, 문서를 누가 어떻게 관리하는지가 운영의 문제로 남아요.

넷째, 예약처럼 실시간 정보는 문서로 해결되지 않습니다.
"오늘 오후 3시에 자리 있나요?"는 FAQ가 아니라 예약 시스템에서 조회해야 하는 정보입니다.
RAG는 "정해진 안내를 설명하는 일"에 맞고, "현재 상태를 확인하는 일"은 시스템의 역할이라고 선을 긋는 게 좋겠다고 생각했습니다.

 

만들어 놓고 잘 되는지 어떻게 알 수 있을까 하는 질문도 남았습니다.
감으로 몇 번 물어보고 괜찮다고 느끼는 것은 위험해요.
그래서 간단하게라도 평가 세트를 만들어 두는 방법을 공부했습니다.

예를 들어 실제 고객이 물을 법한 질문을 스무 개쯤 적고, 각 질문에 대해 "정답이 있어야 하는 FAQ 항목"을 미리 표시해 둡니다.
그리고 두 가지를 확인해요.
검색 단계에서 정답 조각이 상위 몇 개 안에 들어왔는가.
생성 단계에서 답변이 그 조각의 내용과 어긋나지 않는가.
이 두 가지를 나눠서 보면, 틀렸을 때 검색의 문제인지 생성의 문제인지 구분할 수 있습니다.
또 "문서에 없는 질문" 몇 개를 일부러 섞어서, 모른다고 말하는지도 확인하는 게 좋다고 합니다.
숫자 하나로 점수를 매기기보다 틀린 사례를 모아 보고 원인을 분류하는 쪽이 실제로 도움이 될 것 같았어요.

 

RAG를 공부하면서 가장 크게 남은 건, 기술 자체보다 "어떤 문서를 어떻게 관리할 것인가"가 품질을 좌우한다는 점입니다.
기획자가 할 수 있는 일도 여기에 많아요.
FAQ를 질문과 답 한 쌍으로 깔끔하게 쓰고, 정책이 바뀌면 갱신하는 흐름을 만들고, 모르는 질문에 어떻게 응답할지 정하는 것까지가 기획의 몫이라고 생각합니다.

 

앞으로 해보고 싶은 건, 작은 FAQ 문서 몇 개로 직접 준비 단계와 검색 단계를 따라 해보는 것입니다.
임베딩과 벡터 검색을 한 번 손으로 만져 보면, 지금 글로만 이해한 부분이 훨씬 선명해질 것 같아요.