[LLM] RAG란 무엇인가?

2024. 6. 20. 23:19DL

안녕하세요 오랜만에 또 글을 써봅니다.

최근 데이터엔지니어 이지만... 회사에서의 요구사항으로 LLM으로 서비스를 개발하고 있는데요, 특정 도매인의 최신 정보를 가지고 있는 Chatbot을 만들어야 하다보니 자연스럽게 RAG에 대해서 알게되었고 이 RAG에 대해서 제가 이해한 부분까지 정리해 보려 합니다.

 

각종 단어 Embedding이나, 프롬프트나 LLM과 같은 단어들에 대한 세부적 설명은 제외합니다.


- RAG(Retrieval Argumented Generation)

RAG(Retrieval Agumented Generation)는 검색-증강-생성 이라고 합니다. 무슨 의미를 가지고 있느냐.. 우리는 LLM모델을 먼저 이해할 필요가 있습니다. 

 

LLM모델은 Transformer라는 DL모델로 인간의 언어 신경망을 구축했고, 이 구축된 신경망에 2B~ 220B까지 엄청난 량의 파라메터를 학습시켜 집단지성같은 모델을 만들어냈습니다. 다만 문제가 있습니다. 바로 학습시킨 데이터의 한계가 있다는것이죠. 

 

실제로 GPT에게 물어보면 자신이 답변할 수 있는 데이터는 23년 11월정도까지라는것을 알 수 있습니다. 그래서 RAG가 필요합니다. 특정 도매인의 필요한 지식을 정리하여 DB를 구축하고, 이 DB를 외장하드 처럼 사용하여 필요한 지식을 얻을 수 있도록 하여 답변을 생성하는데 도움을 주는것이죠.

RAG 활용 절차

 

- Vector Database

그럼 우리는 LLM에 어떻게 문서 데이터를 제공할 수 있을가요? 그건 바로 VectorDB를 사용하는 방법입니다. VectorDB는 데이터를 embedding하여 컴퓨터가 인식 할 수 있는 형태인 list(float)형태로 변환하고 이를 다수의 차원형태로 저장하여 공간좌표 처럼 데이터를 저장하고 있습니다.  이 데이터를 유사도 검색 방법을 이용하여 조회하여 특정 키워드 또는 질문 형태의 문장으로 부터 유사도가 높은 문서들을 검색할 수 있도록 합니다.

VectorDB의 이미지화

- VectorDB를 사용한 RAG의 일반적인 사용 사례

예를 들어서 컴퓨터 부품에 대한 전문성을 가진 Agent(Assistant)를 개발한다고 합니다. 컴퓨터 부품(그래픽카드, CPU, Power, MainBoard 등등..) 다양한 부품은 하루가 다르게 매번 신제품, 새로운 스펙의 부품들을 쏟아냅니다. 그럼 이런 상황에서 정확한 정보를 주기 위해서는 최신의 출시정보 및 자세한 스펙이 필요하게 됩니다.

 

  1. 웹에서 다양한 컴퓨터 부품관련 내용을 수집합니다. 
    HTML이 됐든, PDF가 됐든, 이미지가 됐든 컴퓨터 부품과 관련된 모든 데이터를 수집하는 크롤러를 개발하게 됩니다.
  2. 수집된 데이터를 원하는 크기로 자르고, 조정하여 Embedding합니다.
  3. Embedding된 데이터를 VectorDB에 저장합니다.
  4. LLM에서 프롬프트를 작성할 때 Vector DB에서 질문과 관련된 문서를 조회하여 더욱 풍부한 내용과, 현재의 지식을 제공합니다.
  5. 답변을 얻고 피드백을 합니다.

위 5단계의 과정을 거쳐서 RAG를 이용한 LLM의 답변을 얻을 수 있습니다. 이렇게 얻어진 답변은 아마도 최신 부품의 정보 곧 출시될 부품의 정보들까지도 모두 알 수 있을것입니다.

 

- 주의 사항

  1. RAG를 구현하는것은 매우~~~~~~ 어렵습니다 그 이유는 다음과 같습니다.
    1. 문서를 얻는것 자체가 어렵다. 세상에는 많은 문서가 있고 각기 다른 형태, 종류로 존재하기 때문에 데이터를 수집 저장 처리하는데 많은 리소스가 사용됩니다.
    2. 문서를 얻는다고 해도, 이 문서의 유효성을 일일히 검증하기 어렵다. 예를들어 최신 데이터인줄 알았던 기사 혹은 문서가 가짜 뉴스, 가짜 정보일경우 낭패를 볼 수 있습니다.
    3. 데이터를 너무 큰 조각으로 잘라도, 너무 작게 잘라도 문제가 될 수 있습니다. 너무 큰 조각으로 자르면 비용, 속도의 문제가 너무 작은 조각으로 자르면 문맥을 적절하게 포함하지 못해 답변 성능 자체에 문제가 생길 수 있습니다.
    4. 이미 Embedding되어 저장된 데이터를 관리해주어야 하는데, 이 부분도 어려울 수 있습니다.
    5. Langchain 또는 llamaIndex를 사용하여 VectorDB를 사용한다고 할 때 아직 출시된지 얼마 안된 프레임워크의 특성상 직접 커스텀해야하는 여러가지 함수 또는 클래스가 있습니다.
    6. 이외 더더더 많지만... 여기까지만 설명하겠습니다.
  2. RAG를 사용하는데 있어서 가장 큰 문제는 비용입니다.
    적은 파라메터를 가지고 있는 모델들에 RAG를 사용하여 다수의 문서를 제공하면 결과물이 잘 나올것 같지만 그렇지 않습니다. 파라메터가 적은만큼, RAG에서 검색된 결과물에 대한 이해도가 떨어져 문맥이 누락되거나 이상한 답변을 할 수 있습니다. 
    그럼 우리는 좀더 비싸고 강한 모델을 찾게되는데, 이럴경우 문맥을 모두 담아 prompt를 작성하기 때문에, 그냥 질문만 할때보다 훨씬 많은 Token을 사용하게되어 비용문제를 불러일으킬 수 있습니다.

 

이상 내용을 간단하게 정리해봤습니다. 사실 위의 RAG에 대한 설명보다 여러분께서 주의사항에 깊게 동의하기를 바랍니다. 

 

출처:

https://weaviate.io/blog/distance-metrics-in-vector-search

https://www.content.upstage.ai/blog/business/document-ai-ocr-for-llm