RAG는 왜 필요할까? - 기존 LLM의 문제점
RAG에 대해서 알아보기 이전에, RAG라는 기술이 왜 등장하게 되었는지 알아보도록 하자.
여러분들은 ChatGPT와 같은 훌륭한 LLM 노예들을 잘 활용하고 있는가?
기가 막히다고 소문난 LLM들을 사용한 경험이 있다면, 아래와 같은 경험을 한 적이 있을 것이다.
예를 들어, 특정 주제에 대해 ChatGPT에게 질문을 했더니 정말 말도 안 되는 거짓말을 했다던가....
ChatGPT와 같은 LLM들은 거의 대부분의 문제는 잘 해결해준다!
하지만 위에서 말했다시피, 거짓 정보를 생성해 내거나 최신 정보의 부재로 인해 이상한 정보를 받을 수도 있다.
다시 정리하면 기존 LLM들의 문제점들은 크게 아래 2가지로 정리할 수 있겠다.
- 최신 정보의 부재
- 거짓 정보 생성(할루시네이션 현상)
하지만 언제나 인류는 정답을 찾을 것이다...늘 그랬듯이...
그러다 보니 나오게 된 기술이 바로 RAG(Retrieval-Augmented Generation)이라는 녀석!
그렇다면 기존 LLM들의 문제점을 RAG는 어떤 방식으로 해결하는 것일까?
RAG(Retrieval-Augmented Generation)
RAG는 쉽게 말해 '검색 + 증강 + 생성'을 따서 만든 키워드이다.
여기서 핵심은 '검색 + 증강'인데, 해당 글에서는 생성 / 검색 + 증강을 나누어 알아보도록 하겠다.
생성(Generation)
생성(Generation) : LLM들에게 우리는 '프롬프트'라는 것을 작성해서 질문을 하게 되는데, LLM은 프롬프트에 대한 답변을 생성해서 응답으로 텍스트를 우리에게 전달해 준다. 이를 Generation이라고 한다.
하지만, 항상 모든 답변에서 정답을 얘기해 주는 것은 아니다.
문제점 ⇒ 최신 정보의 부재 / 거짓 정보 생성(할루시네이션)
검색(Retrieval) & 증강(Augmented)
우리는 위에서 '생성'이라는 기능에 있어 존재하는 문제점들을 해결하기 위해 RAG 프레임워크를 적용한다.
RAG를 적용시키기 위해서는 LLM에게 추가적인 지식을 학습시킬 수 있는 데이터베이스를 하나 추가해야 한다.
여기서 이 데이터베이스를 'Vector DB'라고 부르는데, 여기에는 퍼블릭 혹은 프라이빗한 데이터가 들어갈 수 있겠다.
아무튼 Vector DB를 추가하고, 여기에 학습시킬 데이터들을 'Embedding Vector'라는 것으로 저장시켜 준다.
즉 LLM + Vector DB를 추가시킨 형태의 시스템 = RAG 프레임워크라고 생각하면 편하다!
이렇게 Vector DB에 학습시킬 데이터들을 임베딩 벡터로 추가까지 하고 사용자가 LLM에 질문을 한다 생각해 보자.
특정 주제에 대해 사용자가 LLM에 질문을 던지면, LLM이 바로 해당 질문에 답변하는 것이 아니라
답변하기 이전에 'Vector DB 검색'이라는 작업이 하나 추가되며, 만약 Vector DB에 특정 주제에 대한 검색 결과가 존재할 경우 해당 검색 결과와 사용자의 질문을 함께 LLM에 전달하고, LLM은 그러한 Input으로부터 Output을 얻어 사용자에게 전달하는 형식으로 작동하게 된다.
RAG에 등장하는 Embedding Vector & Vector DB 간단히 알아보기
바로 위에서 RAG를 알아볼 때 Vector DB 그리고 Embedding Vector라는 키워드가 등장했다.
이에 대해서 정말 간단히 알아보도록 하자!
Embedding Vector & Vector DB
[Embedding Vector]
Embedding Vector는 텍스트(또는 이미지, 오디오 등)를 수치화한 고차원 벡터 표현이다. 즉 텍스트를 컴퓨터가 의미 기반으로 이해할 수 있도록 바꿔주는 과정이다. 비슷한 의미의 단어 및 문장은 벡터 공간상에서 가까운 거리를 가지게 된다.
ex)
예를 들어, 강아지와 반려견 그리고 고양이라는 단어를 고차원 벡터로 변환했다고 가정하자.
이때 각 단어에 대한 임베딩 벡터는 [0.2, 0.8, 0.4, ... 0.7] 대강 이런 형태라고 가정하면
강아지 & 반려견의 벡터 사이의 거리(비슷함) < 강아지 & 고양이 벡터 사이의 거리(거리가 멂)
이런 식으로 비슷한 의미를 가진 단어는 임베딩 벡터 공간상에서 가까운 거리를 가지게 된다고 이해하면 되겠다.
[Vector DB]
Vector DB는 임베딩 벡터를 저장하고, 어떤 문장이 가장 비슷한 의미를 갖고 있는지를 빠르게 찾아주는 유사 벡터 검색 전용 DB이다. 이 Vector DB는 일반적인 SQL DB처럼 정형 데이터가 아니라, 의미 기반 검색이 목적인 DB이다. 즉 Vector DB는 비정형 데이터(텍스트, 이미지 등)를 전처리해서 생성한 고차원 벡터를 빠르게 검색/탐색할 수 있도록 설계된 특수한 인덱스 기반 데이터베이스!
RAG 적용 유무에 따른 AI 챗봇의 동작 과정 비교
사용자가 챗봇을 통해 질문을 한다고 가정할 때, RAG 적용 유무에 따라 어떤 방식으로 동작하는지 살펴보자!
일반적인 AI 챗봇의 동작 과정
1. 사용자의 질문이 담긴 프롬프트가 챗봇(웹 화면)에 전달
2. 챗봇이 AI 모델에 프롬프트 전달
3. AI 모델이 답변
4. 챗봇이 AI 모델의 답변을 사용자에게 전달
RAG가 적용된 AI 챗봇의 동작 과정
* 이 때는 기본 구조(사용자 - 챗봇 - LLM)에 데이터 소스(최신 내용)가 새롭게 추가됨
1. 사용자의 질문이 담긴 프롬프트가 챗봇(웹 화면)에 전달
2. 챗봇이 사용자의 질문과 관련된 내용을 데이터 소스(Vector DB)에서 검색 및 활용함
3. 챗봇이 데이터 소스에서 찾은 내용과 사용자의 프롬프트를 합쳐 질문을 작성하여 AI 모델에 전달
4. AI 모델이 답변
5. 챗봇이 AI 모델의 답변을 사용자에게 전달
RAG 적용으로 인한 이점
- 최신 정보의 부재 ⇒ RAG를 적용시키면 새로운 정보가 생길 때마다 LLM을 학습시키는 게 아니라, Vector DB만 업데이트해 주면 최신 정보를 사용자가 받아볼 수 있게 된다. 또한 비용적인 측면에서도 굉장한 이득을 볼 수 있다!
- 거짓 정보 생성(할루시네이션) ⇒ Vector DB에 추가 학습시킨 데이터가 있기 때문에 LLM의 답변이 어떤 DB로부터 왔는지를 명확히 제시해 줄 수 있게 됨. 즉 근거를 들어 정보를 제시할 수 있게 된다!
이처럼 기존 LLM의 문제를 해결하기 위해 개발자들은 RAG라고 하는 시스템(프레임워크)을 고안해 내었다!
최근에는 RAG 외에도 수많은 기술들이 대거 등장했는데, 이후 다른 여러 가지 기술들에 대해서도 알아보도록 하자!
