RAG 기본 원리 설명 보고서

1. LLM, 똑똑하지만 가끔 엉뚱한 친구? RAG가 필요한 이유

LLM(Language Learning Models)은 정말 똑똑한 친구 같아요. 사람처럼 글을 이해하고, 질문에 답하고, 심지어 새로운 글도 만들어낼 수 있답니다. 하지만 LLM에게도 약점이 있어요. 마치 백과사전을 통째로 외운 친구 같지만, 가끔은 최신 정보를 모르거나, 심지어 사실이 아닌 이야기를 진짜처럼 말하기도 해요. 이걸 '환각(hallucination)'이라고 부르기도 합니다.

RAG(Retrieval Augmented Generation)는 바로 이런 LLM의 약점을 보완해주는 똑똑한 비서 같은 존재입니다. RAG는 외부의 믿을 수 있는 정보를 가져와서 LLM에게 알려주고, 그 정보를 바탕으로 답변을 만들게 도와줘요. 덕분에 LLM은 더 정확하고 최신 정보를 반영한 답변을 할 수 있게 된답니다.

2. RAG, 똑똑한 비서가 정보를 찾아주는 과정

RAG 시스템은 마치 도서관 사서가 필요한 책을 찾아주는 과정과 비슷해요. 질문을 받으면 RAG는 먼저 가지고 있는 많은 자료들(기업 문서 같은) 속에서 질문과 가장 관련 있는 정보를 찾아냅니다. 마치 책의 색인을 보고 원하는 내용을 찾는 것과 같죠.

이렇게 찾아낸 정보는 LLM에게 전달됩니다. LLM은 이 정보를 참고해서 질문에 대한 답변을 만들어내는데, 이때 단순히 정보를 나열하는 것이 아니라, 질문에 딱 맞는 형태로 새롭게 구성해서 답변을 만들어줘요. 덕분에 우리는 원하는 정보를 쉽고 정확하게 얻을 수 있게 됩니다.

3. RAG, 어디에 활용될까? 우리 주변의 RAG 찾아보기

RAG 기술은 우리 주변의 다양한 곳에서 이미 활용되고 있어요. 정말 여러 분야에서 유용하게 쓰일 수 있답니다.

예를 들어, 병원이나 법률 회사에서는 RAG를 이용해 방대한 양의 의료 기록이나 법률 문서에서 필요한 정보를 빠르고 정확하게 찾아내고 있어요. 덕분에 의사나 변호사들이 더 나은 결정을 내릴 수 있도록 돕고 있죠.

우리가 흔히 사용하는 고객 서비스 챗봇 중에도 RAG가 사용되는 경우가 많습니다. 챗봇이 우리의 질문을 이해하고 회사 정책이나 제품 정보 같은 것을 정확하게 알려줄 수 있는 것도 RAG 덕분일 수 있어요. 마치 똑똑한 상담원처럼 말이죠.

또한, 콘텐츠 제작이나 추천 시스템에서도 RAG가 사용됩니다. 사용자의 관심사나 이전 데이터를 분석해서 맞춤형 콘텐츠를 만들거나 추천해주는 데 도움을 줄 수 있답니다.

4. RAG, 단순한 질문부터 복잡한 질문까지!

RAG는 질문의 난이도에 따라 단순 RAG와 복잡 RAG로 나눌 수 있어요.

단순 RAG는 "영업시간이 어떻게 되나요?"처럼 하나의 정보만 찾으면 답할 수 있는 질문에 적합합니다. 마치 한 권의 책에서 원하는 페이지를 바로 찾는 것과 같아요.

반면에 복잡 RAG는 좀 더 어려운 질문에 답하기 위해 만들어졌어요. 예를 들어, "최신 당뇨병 치료법과 그 부작용은 무엇인가요?" 같은 질문에는 하나의 정보만으로는 답하기 어렵겠죠.

이럴 때는 multi-hop retrieval이라는 기능이 필요해요. 마치 여러 권의 책을 넘나들며 정보를 찾는 것처럼, 복잡 RAG는 여러 문서나 정보 소스에서 필요한 정보들을 단계별로 찾아 조합해서 답변을 만들어냅니다. 예를 들어, 먼저 '최신 당뇨병 치료법'에 대한 정보를 찾고, 그 치료법들에 대한 '부작용' 정보를 다른 곳에서 추가로 찾는 식이죠.

A.기업 환경에서 RAG의 중요성 및 활용 사례

• RAG는 기업 환경에서 LLM의 가장 적용 가능한 활용 사례 중 하나임.
  • RAG는 LLM의 가장 큰 비즈니스 활용 사례이며, RAG의 프로세스, 조직 적용 가능성 및 관련 도구를 이해하는 것이 중요해지고 있음.
• RAG는 외부 관련 데이터를 사용하여 프롬프트를 보강함으로써 모델 성능을 향상시키는 프레임워크임.
  • LLM 응답을 실제 신뢰할 수 있는 정보에 기반하도록 함.
  • 사용자는 회사 문서를 벡터 데이터베이스에 쉽게 통합하여 LLM이 해당 문서에 대한 질문에 효율적으로 답변할 수 있도록 함.
• 2023년 Retool 보고서에 따르면, 기업 LLM 사용 사례의 36.2%가 RAG 기술을 사용하고 있음.
  • RAG는 구조화 및 비구조화 데이터에 LLM의 힘을 가져와 기업 정보 검색을 그 어느 때보다 효과적이고 효율적으로 만듦.
• RAG는 기업이 기존 데이터 저장소를 활용하여 의사 결정 및 정보 접근성을 향상시키는 강력한 도구임.
• RAG는 다양한 산업 및 사용 사례에 걸쳐 관련성 있는 솔루션임.
  • 법률 및 의료 분야에서는 방대한 판례, 연구 논문 및 임상 지침 데이터베이스에서 정확한 정보를 참조하는 데 도움을 주어 정보에 입각한 의사 결정을 촉진함.
  • 고객 서비스에서는 정교한 챗봇 및 가상 비서를 강화하는 데 사용되어 사용자 쿼리에 정확하고 상황에 맞는 응답을 제공함.
  • 콘텐츠 제작 및 추천 시스템에서도 사용자 선호도 및 과거 데이터를 이해하여 개인화된 콘텐츠 및 추천을 생성하는 데 도움을 줌.

B. RAG 작동 방식 및 예시

• 일반적인 RAG 프로세스는 다음 요소를 포함함.
  • LLM (대규모 언어 모델)
  • 기업 문서 모음
  • 정보 검색 및 답변 구성을 개선하기 위한 지원 인프라
• RAG 파이프라인은 데이터베이스에서 질문과 유사한 개념 및 데이터를 찾음.
  • 벡터 데이터베이스에서 데이터를 추출함.
  • 추출된 데이터를 질문에 맞춰진 답변으로 재구성함.
• 대규모 프로덕션 RAG 구현의 예시는 Twitter/X의 '유사 게시물 보기' 기능임.
  • RAG 시스템은 트윗을 청크하고 벡터 데이터베이스에 저장함.
  • '유사 게시물 보기'를 클릭하면 쿼리가 유사한 트윗을 검색함.
  • 검색된 트윗을 LLM에 전달하여 어떤 게시물이 원본과 가장 유사한지 결정함.
  • 이는 의미 및 유사 개념을 이해하는 LLM의 강력하고 유연한 인지 능력을 모두 얻을 수 있도록 함.
  • 유사성, 의미, 감정 및 오타 등을 고려하지 않는 전통적인 기술보다 효과적임 (예: 키워드 검색).

C. RAG와 Fine-Tuning 비교

• LLM으로 "데이터와 대화"하기 위한 두 가지 경쟁 솔루션은 RAG와 LLM 모델 Fine-Tuning임.
• 일반적으로 둘 다 혼합하여 사용하는 것이 좋지만, 리소스 절충 고려 사항이 있을 수 있음.
• 주요 차이점은 회사 데이터가 저장되고 사용되는 위치와 방식에 있음.
• 모델을 Fine-Tuning할 때, 기존 블랙박스 LLM을 회사 데이터를 사용하여 재학습시키고 사용 사례의 요구 사항을 충족하도록 모델 구성을 조정함.
• 반면에 RAG는 외부 저장된 회사 문서에서 데이터를 검색하고 응답 생성을 안내하기 위해 블랙박스 LLM에 제공함.
• Fine-Tuning은 길고 비용이 많이 드는 프로세스이며, 자주 변경되는 회사 문서/사실과 작업하는 데 좋은 솔루션이 아님.
• 그러나 Fine-Tuned 모델은 톤 및 콘텐츠 생성의 미묘한 뉘앙스를 인식하고 응답하는 데 매우 능숙함.
  • '아브라함 링컨처럼 말하기' 또는 '내 글쓰기 스타일로 작성하기'와 같은 기능을 생각할 수 있음.
• Fine-Tuning은 좁고 잘 정의된 정적 지식 및 형식 도메인이 있는 시나리오에 더 적합함.
  • Anyscale이 언급했듯이, "Fine-Tuning은 사실이 아닌 형식을 위한 것"임.
  • 예를 들어, 스타일과 톤이 특정 지침이나 고유한 목소리에 맞춰야 하는 브랜딩 또는 창의적인 글쓰기 애플리케이션에서 Fine-Tuned 모델은 출력이 원하는 언어적 스타일 또는 주제 일관성과 일치하도록 함.
• 실제로 RAG는 방대한 최신 데이터를 동적으로 가져오는 기능이 가장 정확하고 포괄적인 응답을 가능하게 하는 법률, 고객 서비스 및 금융 서비스와 같은 환경에서 선호될 가능성이 높음.
  • RAG는 광범위한 지식 기반에서 특정 데이터를 검색하여 최신 제품 정보 또는 회사 정책을 신속하게 제공할 수 있는 고객 서비스 애플리케이션에서 뛰어남.
• 기업들은 지저분하고 비구조화된 내부 문서를 명확하게 하기 위해 RAG 시스템을 사용하는 데 가장 흥미를 느끼고 있음.
  • LLM 기술의 주요 장점은 지저분하고 비구조화된 대규모 내부 문서 코퍼스를 처리하는 능력임.

D. RAG 시스템 구축 시 고려 사항 및 질문 유형 분석

• 첫 번째 RAG 시스템을 구축할 때 다음 사항을 고려해야 함.
  • RAG로 자동화하려는 워크플로우를 구체적으로 명시해야 함. (예: 고객 서비스 워크플로우, 특정 질문 3~4개 자동화).
  • 대상 사용자 그룹과 협력하여 그들이 어떤 유형의 질문을 할지 이해해야 함.
  • 이 정보가 어디에 저장되어 있는지 파악해야 함. (예: 한 곳에 답변이 있는지, 여러 소스에서 정보를 취합해야 하는지).
• 답변에 필요한 정보가 구조적으로 분리되어 저장되는 산업 및 워크플로우가 있음.
  • 가장 명확한 예시는 법률 워크플로우임.
  • 계약의 특성상 항상 여러 하위 문서로 분할되고 서로를 참조하는 계약 및 세부 정보가 있을 수 있음.
  • 이러한 의미에서 많은 법률 질문은 법률 문서가 준비되는 방식 때문에 Multi-hop reasoning이 필요함.
• 처음에는 간단해 보이는 질문도 실제로는 Multi-hop reasoning이 필요할 수 있음.
  • 상점 영업 시간 예시로 돌아가서, 직원은 '공휴일에 시카고 지점 영업 시간은 어떻게 되나요?'라고 합리적으로 질문할 수 있음.
  • 공휴일이 영업 시간에 미치는 영향에 대한 정보('상점은 1시간 일찍 문을 닫을 수 있습니다')가 시카고 지점 영업 시간('시카고 지점은 오전 9시부터 오후 5시까지 영업합니다')과 같은 문서에 없을 수 있음.
• 실제 시나리오에서, 심지어 정교한 회사 리더들도 제대로 구성되지 않은 다양한 질문을 한다는 점을 주목해야 함.
  • 멜린다 게이츠 예시에서 볼 수 있듯이, 질문자가 '멜린다 게이츠가 설립한 회사는 무엇인가요?'라고 말했다면 질문은 '간단한' RAG 질문이 될 수 있었음.
  • 이는 사용자가 다른 사람과 대화하는 데 익숙하며 질문에 지원 맥락을 포함하는 것을 잊기 쉽다는 사실을 반영함.
  • 따라서 Multi-hop reasoning이 필요한 제대로 구성되지 않은 쿼리가 예상보다 더 흔함.
• 잠재적인 해결책은 특정 질문을 특정 방식으로 표현하도록 요구하는 것임.
  • 그러나 편리한 솔루션을 찾는 사용자가 그렇게 하는 것을 기억하거나 편리하다고 생각할 가능성은 낮음.
  • 따라서 Multi-hop 기능이 있는 RAG 시스템이 마련되지 않으면 잘못된 사용자 쿼리로 인해 RAG 채택이 흔들릴 가능성이 있음.
• 더 복잡하지만, LLM 및 RAG에 의해 점점 더 복잡한 워크플로우가 자동화됨에 따라 궁극적으로 나타날 질문, 데이터 소스 및 사용 사례의 범위를 수용하기 위해 Day 1부터 Multi-hop 기능이 있는 RAG 시스템을 구축하는 것이 가치 있는 투자임이 입증될 수 있음.