LLM의 모든 것 1 [RAG-Retrieval Augmented Generation]

1. RAG - Retrieval Augmented Generation

: 검색 증강 생성

: 새로운 지식에 관한 텍스트 데이터 소스를 Embedding해서 Vector stores에 저장하고, 프롬프트 구성을 진행할 때 외부 데이터 소스로부터 가져온 텍스트 데이터를 함께 이용해서 프롬프트를 구성한 뒤 LLM으로부터 답변을 얻어낸다.

 

1. 사용자 질문
2. 질문 임베딩 및 내 데이터도 임베딩 진행
3. 이후, 벡터 DB(저장소)에 임베딩된 데이터를 저장
4. 질문을 이용해 저장해놓은 DB 저장소에서 검색
5. 지시 프롬프트 구성 + 질문(query 재생성) + 검색 결과 n개 > 언어모델 GPT에게 제공
6. 언어 모델이 답변 생성
7. 답변 출력

 

2. RAG Review

원리 : LLM의 한계를 보완하고자, 추가 정보를 줌으로써 보다 근거 있는 답변과 정확한 답변을 통해 LLM의 환각 현상을 줄이고자 함 (+토큰길이 한계)

[ DB 구축 vs 실시간 반영 ]

→ 사용 목적에 따라 다르다.

정보 요약 or 주요 정보 추출 or 일회성 Demo 제공 ⇒ document + query

서비스 측면 ⇒ DB 구축

논문(연구) : 정보를 추가했더니, 성능이 올랐어요! 에 초점화된 연구이다보니, 실험할 document + 질문을 input으로 실험을 하게 된 것

적용(서비스) : 서비스 도입을 하는데 있어서는, DB를 구축해서 RAG 방법론을 써먹어보자! 로 변형이 되기 시작함 ⇒ ‘RAG를 활용한~’

⇒ 따라서, 원문을 기준으로 구현을 한 사람들의 경우 전자의 개념을, 기업/서비스 측에서는 후자의 개념을 지니고 있음의 차이가 존재할 수 밖에 없었다.

⇒ 연구 측면 ↔ 서비스 측면

※ 논문 실험 예시)

: (여러 문서들을 통합한 문서를 벡터화 + 사용자 질문) ~

1. 위키피디아(18년도까지의 지도자)가 학습된 LLM에 한국의 비율은? 이라는 질문을 했을 경우, 34%
2. 하지만 새로운 정보(23년도까지의 지도자)를 추가한 LLM에게 질문을 했을 경우, 한국 지도자의 비율은 56%

와 같이 보다 더 최신화 되고, 정확한 정보를 제공할 수 있다는 장점을 보여줌

 

3. RAG 진행 Process

1. 문서를 텍스트 임베딩으로 변환하여 Vector DB에 저장하기

• 문서를 읽어와서(Load) 분할(Split)하고 파싱(Parsing-구문분석)하기
  1. Load하기
     1. PDF Loader
        1. Fitz
           • 단순하게 모든 Text를 읽어서 하나의 문자열을 합칠 때 유용
           • 페이지를 읽는 속도가 가장 빠르다
             • 사용자가 문서를 넣고 실시간으로 요약본을 받고 싶을 때 fitz를 사용한다
           • 페이지 번호 제공(Meta Data) ↔ 페이지 번호를 제외환 metadata는 지원하지 않는다
        2. import fitz
        3. PyPDFLoader
           • 가장 많이 사용되는 Loader
           • 한글 인코딩 처리 우수
           • page 단위로 데이터를 로드함
             • ex) 20 page PDF 파일 로드시 : 20개의 문서로 로드
           • metadata
             • source : 파일명
             • page : 페이지 번호
        4. from langchiain.document_loaders import PyPDFLoader
        5. UnstructuredPDFLoader
           • 가장 많은 metadata 정보 제공
           • 속도가 다른 Loader 대비 느림
             • page 번호만 필요하다면 해당 모듈을 굳이 사용할 필요는 없음
        6. loader = UnstructuredPDFLoader('pdf저장링크') docs = loader.load()
        7. PDFPlumber
           • 한글 인코딩 처리 능력이 우수, 다양한 meta data를 제공함
           • 다양한 metadata 정보를 포함하고 있음
           • 읽기 속도가 가장 느림(UnstructuredPDFLoader 비슷)
        8. from langchain_community.document_loader import PDFlumberLoader loader = PDFPlumberLoader('pdf저장링크') docs = loader.load()
  2. Text Split
     1. CharacterTextSplitter - 권장 x
        • 분할이 가능한 최소의 단위로 분할 시도(공백이나 ‘.’를 기준으로 분할)
          • 문장이 완성되지 못하고 짤리는 경우가 존재할 수 있음.. (공백이나 .을 기준으로 분할하기 때문에)
     2. RecursiveCharacterTextSplitter - 추천 모듈
        • 범용적으로 많이 쓰이는 분할 방식
        • 단락 → 문장 → 단어 순서로 분할하려고 시도 (단락 자체가 큰 의미이기 때문)
     3. TokenTextSplitter
        • 한글 처리가 모호함
     4. HuggingFace
        • 다양한 토크나이저 사용
          • BPE
          • Subword Tokenizer
          • WordPiece
          • SentencePiece
          • spaCy
          • Moses
     5. SemanticChunker(experimental)
        • 의미 유사성에 따라 분할
        • OpenAIEmbedding 선정
• Dense Vector 형태의 Sentence Embedding 변환하기
  • Document Embedding / Query Embedding → 동일한 임베딩 모델(버전)을 사용해야 유사도 찾는 부분에서 에러가 발생하지 않는다.
  1. OpenAIEmbedding(유료) - CacheBackedEmbeddings(감싸서 사용할 것)
     • GPU를 쓸 필요가 없음
     1. text-embedding-3-small
     2. text-embedding-3-large
     3. text-embedding-ada-002
     text-embedding-3-small
  2. OpenSource(HuggingFace)
     1. BGE
     2. Mistral
  3. Open LLM Leaderboard - a Hugging Face Space by HuggingFaceH4
• 나중에 Retrieval 단계에서 빠르게 검색해서 사용할 수 있도록 Indexing하여 Vector DB에 저장(Store)하기
  1. FAISS

---

2. 입력 수신 (Input Reception)

3. 문서 검색 (Document Retrieval)

• 검색 시스템 활성화 (Retrieval System Activation): 첫 번째 주요 단계는 검색 시스템을 활성화하는 것입니다. 이 시스템은 대규모 문서 코퍼스나 데이터베이스(위키피디아나 전문화된 데이터셋과 같은)를 검색하도록 설계되었습니다.
• 쿼리 처리 (Retrieval System Activation): 입력 쿼리는 검색 시스템이 이해할 수 있는 검색 쿼리를 형성하기 위해 처리됩니다.
  • 프로세스는 입력 쿼리 또는 프롬프트를 받는 것으로 시작됩니다. 이 쿼리가 RAG 프로세스를 활성화합니다.
• 문서 가져오기 (Document Fetching): 검색 시스템은 처리된 쿼리를 기반으로 코퍼스를 검색하고 관련 문서나 정보 스니펫을 검색합니다.
  1. Multi-Query Retriever
     • 거리 기반 벡터 데이터베이스 검색은 유사한 Embedding된 문서를 찾음
     • Query 문구가 미묘하게 변경되거나 Embedding이 데이터의 의미를 제대로 포착하지 못하는 경우, 검색 결과가 달라질 수 있음
     ex) ‘Page Rank’에 대해 알려줘
  2. 결과 : Page Rank 알고리즘의 작동 원리는? / Rank 사용하는 이유와 효과에 대해서 설명하라 / Rank 기술에 대한 상세한 정보를 제공해줘라
  3. Ensemble Retriever(Spare + Dense)
     • Semantic Search가 유사 의미를 가지는 문서의 검색에서는 유리하지만, 특정 키워드가 반드시 포함되어야 하는 검색 시 유사 단어가 포함된 문서가 검색될 수 있음
       • ex) 비타민 A 영양제 추천해줘 → 검색결과로는 비타민 D, 비타민 C가 나올 수도 있다는 것.
       ⇒ A가 포함된 결과(특정 키워드가 꼭 있는)를 얻고 싶으면, Sparse Retriever(BM25Retriever)을 사용
     • ⇒ 의미 검색을 하고 싶을 때에는 일반적으로 Dense Retriever(FAISSRetriever)을 사용
  4. Multi-Vector Retriever
     • 여러 VectorStore의 Retriever를 앙상블
  5. ContextualCompressor
     • 긴 길이의 문서 검색 결과를 압축
  6. LLMChainFilter
     • 문서의 검색 결과를 필터링

4. 정보 증강 (Information Augmentation)

• 맥락 통합 (Context Integration): 검색된 문서는 입력 쿼리를 증강하는 데 사용됩니다. 이 단계는 원래 입력과 문서에서 추출된 관련 정보를 결합하는 것을 포함합니다.
• 증강된 입력 형성 (Context Integration): 증강된 입력이 형성되며, 이제 원래 쿼리와 검색된 문서의 추가 맥락을 모두 포함하게 됩니다.

5. 언어 모델이 답변 생성 (Language Model Generation)

• 증강된 입력 공급 (Feeding Augmented Input): 이 증강된 입력은 일반적으로 GPT나 BART와 같은 시퀀스-투-시퀀스 모델인 언어 모델에 공급됩니다.
• 응답 생성 (Response Generation): 언어 모델은 증강된 입력을 처리하고 응답을 생성합니다. 이 응답은 모델의 사전 훈련된 지식뿐만 아니라 검색 단계에서 가져온 외부 정보에 의해 정보를 제공받습니다.

6. 출력 생성 (Output Production)

• 정제 및 형식화 (Refinement and Formatting): 생성된 응답은 필요에 따라 애플리케이션의 요구 사항에 맞게 정제되거나 형식화될 수 있습니다.
• 아웃풋 전달 (Output Delivery): 최종 응답은 RAG 프로세스의 출력으로 전달됩니다. 이 출력은 일반적으로 독립적인 언어 모델에 의해 생성된 응답보다 더 정보에 근거하고 정확하며 맥락적으로 관련성이 높습니다.

 

 

https://www.youtube.com/watch?v=KDM6UM-msZk

검색 증강 생성(Retrieval-augmented generation, RAG) - Google Search

🔎 검색 증강 생성(Retrieval-augmented generation, RAG): Google 검색