안녕하세요 오늘은 BESPIN GLOBAL AX실 양재현님이 작성해주 AI 이것만은 알고가자 5편 : LLM을 똑똑하게 Text Splitters & Embedding’ 대해 소개해드리도록 하겠습니다.
4편에서는 RAG의 주요 구성 요소 중 하나인 Document Loader에 대해 알아보았는데요, 이번 편에서는 Text Splitters를 알아보도록 하겠습니다.
목차
- Text Splitters
- Text Embeddings
1. Text Splitters
문서에서 데이터를 읽고나서 문서도 사이즈가 큰 문서가 있다 보니 컴퓨터에서도 이를 효율적으로 검색하고 정리하는 과정이 필요할 겁니다. 이 작업을 보통 임베딩 과정이라고 합니다.
이 임베딩 과정을 하기 전에 문서에 있는 내용을 Text Splitters 그대로 한국말로 해석하면 텍스트를 나누는 작업을 Text Splitters 라고 합니다. 이렇게 텍스트를 나누는 이유(인공지능에서는 Chunk 작업이라고 합니다)는 나중에 텍스트를 효율적으로 검색하기 위해서입니다.
쪼개는 단위는 Chunk Size 라고 이야기 합니다. 해당 사이트에서 테스트도 해볼 수 있습니다. (https://chunkviz.up.railway.app/)
2. Text Embeddings
왜 텍스트를 쪼개야하는 지에 대해 설명드리자면, 너무 많은 텍스트를 한번에 담아 놓게 되면 나중에 지식기반에서 자료를 찾을때 검색 속도가 현저하게 떨어 지기 때문입니다. 그리고 이 텍스트 Chunk 한 내용을 바탕으로 임베딩 벡터를 만들게 됩니다. 이 작업을 Text Embeddings(텍스트 임베딩) 작업이라고 합니다. 이 단계에서는 텍스트를 숫자로 변환하여서 문장 간의 유사성을 비교할수 있도록 합니다.
이 임베딩 모델 과정에서 사용하는 유료 임베딩 모델은 aws bedrock 같은 경우는 titan-embed-text-v1을 사용하며 허깅페이스같은 무료 임베딩 모델에서는 ko-Sentence-BERT (한국어 문장 임베딩 위해 개발된 모델 ) 을 사용합니다. 따라서 이 임베딩 모델을 고르는것도 RAG 를 구성할때 가장 중요한 부분 입니다.
이렇게 임베딩 모델을 사용하여 벡터 저장소 ( aws opensearch – 유료 ) , Milvus , FAISS – 무료를 사용합니다.
이렇게 벡터 저장소에 저장되며 이 벡터 저장소에서 조회 할때는 prompt에서의 질문이 벡터화 되어 유사도 측정을 통해( cosine similarity ) 적절한 답변을 찾게 됩니다. 이렇게 임베딩되어 벡터에 저장을 잘해야 좋은 성능을 낼 수 있습니다. 하지만 이 방법도 단점이 있기에 임베딩 모델은 의미적 관계를 포착하는 데 뛰어나지만, 중요한 정확한 일치 항목을 놓칠 수 있습니다.
이러한 한계점을 극복하고자 도움되는 기술이 있는데 BM25(Best Matching 25) 어휘적 일치를 사용하여 정확한 단어나 구문 일치 항목을 찾는 순위 함수를 사용하여 어느정도 해결할 수 있습니다. 이건 RAG 응용편으로 마지막 시간에 배우도록 하겠습니다.
지금까지의 내용을 정리하면 아래와 같습니다.
- 일반적으로 수백 개의 토큰을 넘지 않는 작은 텍스트 청크로 나눕니다.
- 임베딩 모델을 사용하여 이러한 청크를 의미를 인코딩하는 벡터 임베딩으로 변환합니다.
- 의미적 유사성에 따른 검색을 가능하게 하는 벡터 데이터베이스에 이러한 임베딩을 저장합니다.
- 런타임 시 사용자가 모델에 쿼리를 입력하면 벡터 데이터베이스가 쿼리와의 의미적 유사성에 따라가장 관련성 있는 청크를 찾는 데 사용됩니다.
- 그런 다음 가장 관련성 있는 청크가 생성 모델에 전송된 프롬프트에 추가됩니다.
여기까지 ‘AI 이것만은 알고가자 5편 : LLM을 똑똑하게 Text Splitters & Embedding’에 대해 소개해드렸습니다. 다음 시간에는 Vector Stores 에 대해서 자세히 알아 보도록 하겠습니다. 유익한 정보가 되셨길 바랍니다. 감사합니다.
Written by 양 재현/ AX실
BESPIN GLOBAL