AI

LLM 과 RAG

hero_pin 2024. 6. 20. 18:34

LLM RAG (검색 증강 생성 Retrieval-Augmented Generation)

LLM의 단점을 보안하기 위한 기술

일단 LLM을 알아야 하는데 Large Languge Model의 약자로, 자연어 처리(NLP)에서 사용되는 인공지능 기술의 한 종류이다. 이 모델들은 대규모의 텍스트 데이터를 학습하여 언어의 구조와 의미를 이해하고, 그 학습을 바탕으로 텍스트 생성, 번역, 요약, 질문에 대한 답변 등 다양한 언어 관련 작업을 수행한다.

LLM의 특징

  • 방대한 지식 보유
  • 문맥 이해 능력
  • 자연어 생성 능력
  • 전이 학습 능력
  • 확장성

LLM의 단점

  1. 편향성 문제
    • 학습 데이터에 내재된 편향성을 그대로 반영할 수 있다.
    • 성별, 인종, 종교 등에 대한 고정관념이나 차별적 표현을 생성할 위험 존재
  2. 사실관계 오류 가능성
    • 방대한 데이터를 학습하지만, 항상 정확한 정보를 제공하지는 않는다.
    • 잘못된 정보나 허위 정보를 진실로 간주하고 전파할 수 있다.
  3. 맥락 이해의 한계
    • 문자 단위의 이해는 가능하지만, 장문의 글이나 복잡한 맥락 파악은 어려울 수 있다.
    • 세계 지식과 상식추론 능력이 부족하여 심층적인 이해에 한계 존재
  4. 일관성 문제
    • 동일한 입력에 대해 일관된 답변을 생성하지 않을 수 있다.
    • 모델의 확률적 특성상 생성 결과가 매번 달라질 수 있다.
  5. 윤리적 문제
    • 악용 가능성이 존재하며, 책임 소재 파일이 어려울 수 있다.
    • 모델의 출력 결과에 대한 토엦와 검증 체계 마련 필요

RAG는 LLM의 단점 중 무엇을 개선했나?

RAG는 LLM의 단점 중 '사실관계 오류 가능성'과 '맥락 이해의 한계'를 개선하는 데 초점을 맞춘 방법이다.
RAG는 LLM에 외부 지식 베이스를 연결하여 모델의 생성 능력과 사실 관계 파악능력을 향상시키느 기술이다.

구체적으로 RAG는 다음과 같은 방식으로 LLM의 한계를 보완한다.

  1. 외부 지식 활용
    • 대규모의 구조화된 지식 베이스를 모델에 연결 (해당 프로젝트에서는 백터DB를 사용)
    • 주어진 질으에 대한 관련 정보를 지식 베이스에서 검색 및 추출
  2. 증거 기반 생성
    • 검색된 지식 정보를 증거로 활용하여 보다 사사리에 기반한 답변 생성
    • 생성된 답변의 출처를 명시함으로써 신뢰성 향상
  3. 맥락 이해력 향상
    • 외부 지식을 통해 질의에 대한 배경 지식과 맥락 정보를 파악
    • 단순한 패턴 매칭이 아닌 추론 능력을 바탕으로 한 답변 생성

RAG의 주요 구성 요소

  1. 질의 인코더(Query Encoder) : 사용자의 질문을 이해하기 위한 언어 모델이다. 주어진 질문을 백터 형태로 인코딩한다. (인베딩?)
  2. 지식 검색기(Knowledge Retriever) : 인코딩된 질문을 바탕으로 외부 지식 베이스에서 관련 정보를 검색.
    예를 들어 Wikipedia, 뉴스 기사, 전문 서적 등 방대한 문서 집합에서 질문과 연관된 문단이나 구절을 찾아냄.
  3. 지식 증강 생성기(Knowlegde-Aunmented Generator) : 검색된 지식을 활용하여 질문에 대한 답변을 생성하는 언어모델.
    기존의 LLM과 유사하지만, 검색된 지식을 추가 입력으로 받아 보다 정확하고 풍부한 답변을 생성할 수 있다.

Rag Architecture

https://velog.io/@mertyn88/LLM-Rag-Architecture
all

Embedding

Retrival

Inference

LangChain

LangChain은 LLM을 기반으로하는 애플리케이션을 개발하기 위한 프레임워크이다.
link : https://python.langchain.com/v0.2/docs/introduction/

[langchain]

langchain.document_loaders 라이브러리로 무려 pdf를 string으로 읽어오는것이 가능하다!

백터 저장소 및 검색기의 추상화에 익숙해져야한다. 이러한 추상화는 LLM Workflow 와의 통합을 위해 백터 데이터베이스 에서 검색을 지원하도록 설계되었다.
이는 RAG의 경우처럼 모델 추론의 일부로 추론할 데이터를 가져오는 애플리케이션에 중요하다.

LangChain은 텍스트 단위 및 관련 메타데이터를 표현하기 위한 문서 추상화를 구현한다. 여기에는 두 가지 속성이 있다.

  • page_content : 내용을 나타내는 문자열
  • metadata : 임의의 메타데이터가 포함된 사전

번외 fitz

  • 단순하게 모든 Text를 읽어서 하나의 문자열을 하빌 때 유용
  • 페이지를 읽는 속도가 가장 빠름
  • 페이지 번호 제공
  • 페이지 번호를 제외한 metadata 미지원

Splitter의 종류

CharacterTextSplitter

  • 권장하는 방식이 아님 (소제목등이 잘리는 경우가 있음)
  • 분할 가능한 최소의 단위로 분할을 시도
    • 공백 이나 "."을 기준으로 분할
  • 중요한 문서의 소제목에서 텍스트가 잘릴 수 있음
    • 이는 chunk_overlap이 궁극적인 해결책이 안되는 경우가 많음

RecursiveCahracterTextSplitter

  • 범용적으로 많이 사용되는 분할 방식
  • 청크가 충분히 작아질 때까지 순서대로 분할하려고 시도
  • 기본 목록은 ["\n\n","\n"," ",""]
    • 단락 -> 문장 -> 단어 순서로 시도, 일반적으로 텍스트의 가장 강력한 의미 관련 부분으로 분할시도

TokenTextSplitter

  • 토큰 단위로 분할
  • 한글 처리가 모호함
  • KonlpyTextSplitter를 사용하면 해결책이 될 수 있음
    • Kkma 형태적 분석을 사용한다고한다.
    • 분석적 심도가 우선시되는 애플리케이션에 적합함. (빠르게 처리해야되는 상황보다는 정확도가 우선시될때 사용)

오픈소스

  • HuggingFace 에 업로드 된 다양한 Tokenizer를 활용가능
  • 속도와 성능 면에서 개선된 버전이 지속적으로 업데이트 되고 있음
  • 최적의 토크나이저를 다양하게 테스트 해 볼 수 있음
  • 신조어, 특정 도메인 용어(의료 용어) 등의 tokenizer.trainer로 Fine-Tuning 혹은 단순 add 가능
  • 대표적인 Tokenizer
    • Subword Tokenizer
    • BPE
    • WordPiece
    • SentencePirce
    • spaCy
    • Moses

참조 link :
http://github.com/huggingface/tokenizers

SemanticChunker

  • langchain_experimental 에 신규 추가된 Chunker
  • 텍스트를 의미 유사성에 따라 분할
  • 다른 Tokenizer와 달리 chunk_size, chunk_overlap과 같은 파라미터를 initialize에 사용하지 않는 것이 특징

import langchain_experimental
text_splitter = SemanticChunker(OpneAIEmbedding())

LLM 에서 임베딩(Embeddings)이란 뭘까

LangChain Text embedding models
https://python.langchain.com/v0.2/docs/how_to/embed_text/

임베딩이란?

  • 임베딩은 콘텐츠를 부동 소수점 숫자의 배열로 변환한 것
  • 이 배열의 핵심은 콘텐츠 내용의 길이에 관계없이 배열의 크기가 항상 같다
  • 배열의 크기는 사용하는 임베딩 모델에 의해서 결정된다 300, 1000, 1536(임베딩 모델이 몇개 있나보다,,,)
    다차원 공간에 나열된다 ??
  • 임베딩은 텍스트를 벡터 표현으로 만든다.
  • 벡터 공간에서 가장 유사한 텍스틀르 찾는 Semantic Serch(의미검색)과 같은 작업을 수행할 수 있다.
  • 문서에 적합한 Embedding모델을 선택하는 것이 중요하다. (한글등 다국어 고려)

임베딩이 필요한 이유

AI모델은 하나의 함수(function)이기 때문에 기본적으로 숫자 형태의 입력만 받을 수 있다.
텍스트는 이미 숫자 형태로 encoding된 결과물 이지만 길이가 길고 가변성 또한 매우 크다.
AI 모델은 이런 값을 다루는데 특화 되어 있지 않기 때문에 고정적인 길이의 입력값인 embedding으로 변환하는 것.

Embedding 클래스

  • LagnChain의 기본 Embedding 클래스

    • Document Embedding (데이터를 생성할때)
    • Query Embedding (사용자가 데이터를 요청할때)

  • 주요 Embedding 목록

    • OpenAIEmbedding 유료!!

    • OpenSource(HuggingFace) 무료!!

      • BGE
      • Mistral

      ! 문서를 만드는 모델과 쿼리할때 모델을 같은 모델을 쓰는것을 권장함 (데이터를 수집하는 시점에 사용한 버전을 관리하것이 필요)

Word embedding vs Sentence/Document embedding

원본 텍스트는 입력되기전 작은 조각들로 쪼개진다. 이때 조각을 ‘token’ 쪼개는 일을 하는 모델을 ‘tokenizer’ 라고 한다.

  • tokenizer 에 따라 조각이 단어 하나일 수도 있고 단어의 일부 조각이 될 수도 있다.

Chunk 를 나누는 기준은 어떻게 지정하는걸까...? 사용법에는 그저 사용자가 임의값을 주도록 되어있다

Vector stores and retrievers

백터 검색은 구조화되지 않은 데이터(ex: 구조화되지 않은 텍스트)를 저장하고 검색하는 일반적인 방법이다. 아이디어는 텍스트와 연관된 숫자형 백터를 저장하는 것이다.
쿼리가 주어지면 이를 동일한 차원의 백터로 삽입 하고 백터 유사성 메드릭을 사용하여 저장소에서 관련 데이터를 식별할 수 있다.

langchain vectorstores doc
https://api.python.langchain.com/en/latest/vectorstores/langchain_core.vectorstores.VectorStore.html

langchain vectorstores Document 개체에는 저장소에 텍스트와 개체를 추가하고 다양한 유사성 측정 항목을 사용하여 쿼리하는 메서드가 포함되어 있다. 텍스트 데이터가 숫자 백터로 변환되는 방삭을 결정하는 임베딩 모델 로 초기화되는 경우가 많다.

일부 백터 스토어는 공급자에 의해 호스팅 되며 사용하려면 특정 자격증명이 필요하다. 일부는 로컬 똔느 타사를 통해 실행될 수 있는 별도의 인프라에서 실행된다. 다른 것들은 가ㅕ운 작어 부하를 위해 메모리 에서 실행할 수 있다.

다음은 Chroma를 사용하여 LangChain VectorStores의 사용법이다. 

from langchain_chroma import Chroma
from langchain_openai import OpenAIEmbeddings

vectorstore = Chroma.from_documents(
    documents,
    embedding=OpenAIEmbeddings(),
)