RAG 검색 증강 생성이란? LLM 답변 품질을 높이는 데이터 흐름과 활용법

핵심 메시지

• RAG(검색 증강 생성)는 LLM이 만드는 답변을 관련 있고 정확한 데이터에 '근거(grounding)'시켜 품질을 높이는 AI 아키텍처 접근법이다.
• 사전 처리 단계에서 웹페이지·양식·브로슈어 같은 데이터를 잘게 나눠 임베딩으로 만든 뒤 벡터 데이터베이스에 저장한다.
• 사용자가 질문하면 같은 임베딩 모델로 질문을 벡터화하고, 유사도 검색으로 관련 데이터를 찾아 프롬프트에 덧붙여 LLM에 전달한다.
• 임베딩 품질, 청크 크기와 중첩, 질문의 명확성이 RAG 성능을 크게 좌우한다.

쉽게 이해하기

RAG는 검색 증강 생성(Retrieval Augmented Generation)의 약자로, 3계층 웹 아키텍처처럼 AI 애플리케이션을 만드는 하나의 보편적 아키텍처다. 핵심 목적은 LLM이 생성하는 결과를 관련 있고 정확하다고 알려진 데이터에 근거시켜 더 나은 답변을 만들게 하는 데 있다.

RAG 앱에는 먼저 사전 처리 단계가 있다. 예를 들어 배심원 의무나 반려동물 등록 같은 정보를 안내하는 지역 정부 웹사이트 챗봇을 만든다면, 웹페이지뿐 아니라 양식·브로슈어·이미지 같은 자료까지 잘게 나눠(chunk) 임베딩을 만들고, 그 데이터와 임베딩을 함께 벡터 데이터베이스에 저장한다.

사용자가 질문하면 네 단계가 일어난다. ① 같은 임베딩 모델로 질문을 임베딩(벡터)으로 변환하고, ② 그 벡터로 유사도 알고리즘을 써서 데이터 저장소에서 관련 데이터를 찾고, ③ 찾아낸 관련 데이터를 원래 프롬프트에 덧붙이며(여기서 '다음 문서를 근거로 답하라' 같은 지시도 함께 넣는다), ④ 이렇게 보강된 프롬프트를 Gemini 같은 LLM에 보내 받은 응답을 사용자에게 돌려준다.

혼동하기 쉬운 지점은 '무엇이 검색되어 돌아오는가'다. 임베딩(숫자 배열)은 유사한 데이터를 찾는 데만 쓰이고, 벡터 데이터베이스가 실제로 반환하는 것은 텍스트·사진·영상·오디오 같은 원본 형식의 데이터다. LLM에 전달되는 것도 사람이 읽을 수 있는 이 원본 데이터다. 또한 질문을 임베딩하는 모델과 답변을 생성하는 LLM이 같을 필요는 없다.

성능을 높이려면 RAG의 심장인 임베딩에 신경 써야 한다. 임베딩 차원, 청크 크기와 청크 중첩이 검색 품질을 좌우한다. 사용자의 질문 자체가 부실하거나 오타가 많으면 결과가 나빠지므로, 질문을 먼저 LLM에 보내 다듬게 하는 방법이 효과적이다. 자주 묻는 질문에는 직접 정답을 작성해 DB에 넣어 두고, 한 번에 가져오는 관련 데이터의 개수도 바꿔 가며 응답 품질 변화를 확인하는 것이 좋다.

주요 인사이트

• 검색 시 반환되는 것은 임베딩(숫자 배열)이 아니라 원본 텍스트·이미지 등 원형 데이터다. 임베딩은 유사한 데이터를 찾는 용도로만 쓴다.
• 질문을 임베딩하기 전에 LLM에 먼저 질문을 다듬게 하면 오타·모호함을 줄여 검색 품질을 끌어올릴 수 있다.
• 자주 묻는 질문에 대한 정답을 사람이 직접 작성해 벡터 DB에 넣어 두면 더 높은 품질의 응답을 얻을 수 있다.
• 컨텍스트 창이 커지면(예: 200만 토큰) 더 많은 관련 데이터를 넣을 수 있지만, 넣는 양의 변화가 응답 품질에 어떻게 영향을 주는지 확인해야 한다.

자주 묻는 질문

관련 AI 소식