LLM의 모든 것 1 [RAG-Retrieval Augmented Generation]
1. RAG - Retrieval Augmented Generation
: 검색 증강 생성
: 새로운 지식에 관한 텍스트 데이터 소스를 Embedding해서 Vector stores에 저장하고, 프롬프트 구성을 진행할 때 외부 데이터 소스로부터 가져온 텍스트 데이터를 함께 이용해서 프롬프트를 구성한 뒤 LLM으로부터 답변을 얻어낸다.
- 사용자 질문
- 질문 임베딩 및 내 데이터도 임베딩 진행
- 이후, 벡터 DB(저장소)에 임베딩된 데이터를 저장
- 질문을 이용해 저장해놓은 DB 저장소에서 검색
- 지시 프롬프트 구성 + 질문(query 재생성) + 검색 결과 n개 > 언어모델 GPT에게 제공
- 언어 모델이 답변 생성
- 답변 출력
2. RAG Review
원리 : LLM의 한계를 보완하고자, 추가 정보를 줌으로써 보다 근거 있는 답변과 정확한 답변을 통해 LLM의 환각 현상을 줄이고자 함 (+토큰길이 한계)
[ DB 구축 vs 실시간 반영 ]
→ 사용 목적에 따라 다르다.
정보 요약 or 주요 정보 추출 or 일회성 Demo 제공 ⇒ document + query
서비스 측면 ⇒ DB 구축
논문(연구) : 정보를 추가했더니, 성능이 올랐어요! 에 초점화된 연구이다보니, 실험할 document + 질문을 input으로 실험을 하게 된 것
적용(서비스) : 서비스 도입을 하는데 있어서는, DB를 구축해서 RAG 방법론을 써먹어보자! 로 변형이 되기 시작함 ⇒ ‘RAG를 활용한~’
⇒ 따라서, 원문을 기준으로 구현을 한 사람들의 경우 전자의 개념을, 기업/서비스 측에서는 후자의 개념을 지니고 있음의 차이가 존재할 수 밖에 없었다.
⇒ 연구 측면 ↔ 서비스 측면
※ 논문 실험 예시)
: (여러 문서들을 통합한 문서를 벡터화 + 사용자 질문) ~
- 위키피디아(18년도까지의 지도자)가 학습된 LLM에 한국의 비율은? 이라는 질문을 했을 경우, 34%
- 하지만 새로운 정보(23년도까지의 지도자)를 추가한 LLM에게 질문을 했을 경우, 한국 지도자의 비율은 56%
와 같이 보다 더 최신화 되고, 정확한 정보를 제공할 수 있다는 장점을 보여줌
3. RAG 진행 Process
1. 문서를 텍스트 임베딩으로 변환하여 Vector DB에 저장하기
- 문서를 읽어와서(Load) 분할(Split)하고 파싱(Parsing-구문분석)하기
- Load하기
- PDF Loader
- Fitz
- 단순하게 모든 Text를 읽어서 하나의 문자열을 합칠 때 유용
- 페이지를 읽는 속도가 가장 빠르다
- 사용자가 문서를 넣고 실시간으로 요약본을 받고 싶을 때 fitz를 사용한다
- 페이지 번호 제공(Meta Data) ↔ 페이지 번호를 제외환 metadata는 지원하지 않는다
- import fitz
- PyPDFLoader
- 가장 많이 사용되는 Loader
- 한글 인코딩 처리 우수
- page 단위로 데이터를 로드함
- ex) 20 page PDF 파일 로드시 : 20개의 문서로 로드
- metadata
- source : 파일명
- page : 페이지 번호
- from langchiain.document_loaders import PyPDFLoader
- UnstructuredPDFLoader
- 가장 많은 metadata 정보 제공
- 속도가 다른 Loader 대비 느림
- page 번호만 필요하다면 해당 모듈을 굳이 사용할 필요는 없음
- loader = UnstructuredPDFLoader('pdf저장링크') docs = loader.load()
- PDFPlumber
- 한글 인코딩 처리 능력이 우수, 다양한 meta data를 제공함
- 다양한 metadata 정보를 포함하고 있음
- 읽기 속도가 가장 느림(UnstructuredPDFLoader 비슷)
- from langchain_community.document_loader import PDFlumberLoader loader = PDFPlumberLoader('pdf저장링크') docs = loader.load()
- Fitz
- PDF Loader
- Text Split
- CharacterTextSplitter - 권장 x
- 분할이 가능한 최소의 단위로 분할 시도(공백이나 ‘.’를 기준으로 분할)
- 문장이 완성되지 못하고 짤리는 경우가 존재할 수 있음.. (공백이나 .을 기준으로 분할하기 때문에)
- 분할이 가능한 최소의 단위로 분할 시도(공백이나 ‘.’를 기준으로 분할)
- RecursiveCharacterTextSplitter - 추천 모듈
- 범용적으로 많이 쓰이는 분할 방식
- 단락 → 문장 → 단어 순서로 분할하려고 시도 (단락 자체가 큰 의미이기 때문)
- TokenTextSplitter
- 한글 처리가 모호함
- HuggingFace
- 다양한 토크나이저 사용
- BPE
- Subword Tokenizer
- WordPiece
- SentencePiece
- spaCy
- Moses
- 다양한 토크나이저 사용
- SemanticChunker(experimental)
- 의미 유사성에 따라 분할
- OpenAIEmbedding 선정
- CharacterTextSplitter - 권장 x
- Load하기
- Dense Vector 형태의 Sentence Embedding 변환하기
- Document Embedding / Query Embedding → 동일한 임베딩 모델(버전)을 사용해야 유사도 찾는 부분에서 에러가 발생하지 않는다.
- OpenAIEmbedding(유료) - CacheBackedEmbeddings(감싸서 사용할 것)
- GPU를 쓸 필요가 없음
- text-embedding-3-small
- text-embedding-3-large
- text-embedding-ada-002
- OpenSource(HuggingFace)
- BGE
- Mistral
- Open LLM Leaderboard - a Hugging Face Space by HuggingFaceH4
- 나중에 Retrieval 단계에서 빠르게 검색해서 사용할 수 있도록 Indexing하여 Vector DB에 저장(Store)하기
- FAISS
2. 입력 수신 (Input Reception)
3. 문서 검색 (Document Retrieval)
- 검색 시스템 활성화 (Retrieval System Activation): 첫 번째 주요 단계는 검색 시스템을 활성화하는 것입니다. 이 시스템은 대규모 문서 코퍼스나 데이터베이스(위키피디아나 전문화된 데이터셋과 같은)를 검색하도록 설계되었습니다.
- 쿼리 처리 (Retrieval System Activation): 입력 쿼리는 검색 시스템이 이해할 수 있는 검색 쿼리를 형성하기 위해 처리됩니다.
- 프로세스는 입력 쿼리 또는 프롬프트를 받는 것으로 시작됩니다. 이 쿼리가 RAG 프로세스를 활성화합니다.
- 문서 가져오기 (Document Fetching): 검색 시스템은 처리된 쿼리를 기반으로 코퍼스를 검색하고 관련 문서나 정보 스니펫을 검색합니다.
- Multi-Query Retriever
- 거리 기반 벡터 데이터베이스 검색은 유사한 Embedding된 문서를 찾음
- Query 문구가 미묘하게 변경되거나 Embedding이 데이터의 의미를 제대로 포착하지 못하는 경우, 검색 결과가 달라질 수 있음
- 결과 : Page Rank 알고리즘의 작동 원리는? / Rank 사용하는 이유와 효과에 대해서 설명하라 / Rank 기술에 대한 상세한 정보를 제공해줘라
- Ensemble Retriever(Spare + Dense)
- Semantic Search가 유사 의미를 가지는 문서의 검색에서는 유리하지만, 특정 키워드가 반드시 포함되어야 하는 검색 시 유사 단어가 포함된 문서가 검색될 수 있음
- ex) 비타민 A 영양제 추천해줘 → 검색결과로는 비타민 D, 비타민 C가 나올 수도 있다는 것.
- ⇒ 의미 검색을 하고 싶을 때에는 일반적으로 Dense Retriever(FAISSRetriever)을 사용
- Semantic Search가 유사 의미를 가지는 문서의 검색에서는 유리하지만, 특정 키워드가 반드시 포함되어야 하는 검색 시 유사 단어가 포함된 문서가 검색될 수 있음
- Multi-Vector Retriever
- 여러 VectorStore의 Retriever를 앙상블
- ContextualCompressor
- 긴 길이의 문서 검색 결과를 압축
- LLMChainFilter
- 문서의 검색 결과를 필터링
- Multi-Query Retriever
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 검색
www.google.com