RAG를 빠르고 정확하게 해주는 인덱싱과 청킹

보다 빠르고 정확한 벡터간 계산을 위한 테크닉

지난시간에 임베딩 모델이 검색증강생성(RAG) 파이프라인에서 중요한 역할을 한다는 점을 살펴보았습니다. 이제 고차원 벡터간의 검색 통해 검색증강생성(RAG) 파이프라인을 더욱 빠르고 정확하게 만들어주기 위한 두 가지 중요한 기술인 청킹(Chunking)과 인덱싱(Indexing)에 대해 알아보겠습니다.

1. 청킹(Chunking): 큰 문서를 작은 조각으로 나누기

우리가 고차원 벡터로 변환하여 벡터DB에 보관하는 텍스트 데이터에는 어떤 것들이 있을까요? LLM의 활용 사례에 따라 다르겠지만 간단한 상품 설명서부터 매우 복잡하고 양이 많은 논문까지 다양한 문서 데이터가 있을 것입니다. 지금부터 설명드릴 청킹(Chunking)이라는 과정은 우리가 다루는 데이터의 종류와 양이 다르기 때문에 필요합니다.

'chunk' 즉 '덩어리'라는 단어 뜻에서 알 수 있듯이, 청킹은 간단히 말해 임베딩을 진행하기 전에 큰 텍스트를 더 작은 단위로 나누는 과정입니다. 특히 문서가 너무 길어서 벡터로 변환하기 어려운 경우, 청킹을 통해 문서의 의미를 보존하면서 작은 조각으로 나누어 처리할 수 있습니다. 예를 들어, 긴 뉴스 기사나 연구 논문을 문단이나 구절 단위로 나누어 각각 벡터화하면 검색과 생성 과정에서 더 효율적이고 정확한 결과를 얻을 수 있습니다.

문서를 더 작은 단위로 쪼개주는 청킹(Chunking)

청킹은 RAG 파이프라인에서 중요한 역할을 합니다. 사용자가 검색어를 입력하면, 청킹된 문서들 중에서 검색어와 가장 관련성이 높은 조각을 찾아내어 LLM이 적절한 답변을 생성할 수 있도록 돕습니다. 이 과정에서 청킹의 크기와 방식은 성능에 큰 영향을 미칠 수 있습니다. 

여기서 중요한 것은 성능개선을 위한 청킹에 천편 일률적인 정답은 없다는 것입니다. 임베딩 하고자 하는 문서의 종류와 성격에 따라서 같은 청킹 기법을 적용해도 성능이 달라지기도 합니다. 예를 들어, 너무 작은 청크는 문맥이 부족할 수 있고, 너무 큰 청크는 검색 정확도가 떨어질 수 있기 때문에, 적절한 청크 크기와 방식이 중요합니다.

2. 고차원 벡터 저장에는 왜 인덱싱(Indexing)이 필요할까?

임베딩이란 한국어, 영어, 중국어 등 텍스트 데이터를 숫자 데이터로 이루어진 고차원 벡터로 변환해주는 과정이라고 말씀드렸습니다. 검색증강생성(RAG) 파이프라인에서 임베딩이라는 복잡한 과정을 거치는 이유가 무엇이었는지 다시 한번 생각해 봅시다. 바로 텍스트로 구성된 외부 데이터(pdf, excel, ppt, txt 등)를 벡터DB에 저장하고 LLM이 필요할 때 검색해서 꺼내쓸 수 있도록 해주기 위함이었습니다.

임베딩 모델을 사용하여 텍스트를 고차원 벡터로 변환하는 과정은 매우 중요하지만, 이렇게 변환된 벡터들을 효율적으로 저장하고 검색할 수 있도록 하기 위한 인덱싱 작업 역시 빼놓을 수 없습니다. 임베딩의 목적 자체가 검색을 위한 것이기 때문입니다. 인덱싱이란 한마디로 벡터를 저장할 때, 검색 성능을 극대화할 수 있도록 데이터를 체계적으로 정리하는 과정이라고 할 수 있습니다.

고차원 벡터를 정리정돈 해주는 인덱싱(Indexing)

Elastic Search, Milvus, ChromaDB 등 다양한 벡터DB에는 수많은 고차원 벡터가 저장됩니다. 이 벡터DB들은 마치 수많은 책들이 보관되어 있는 도서관과 같습니다. 도서관에서 읽고싶은 책이 어디있는지 찾기 위해서는 색인 즉 인덱스(Index)가 필수적입니다. 다시말해 수많은 고차원 벡터 간의 유사도를 빠르게 계산하고, 사용자가 입력한 검색어와 가장 관련 있는 벡터를 빠르게 찾아내기 필요한 것이 바로 인덱싱 즉 색인작업인 것입니다.

이처럼 인덱싱 작업은 마치 책들을 도서관의 책장에 정리하고 색인 번호를 매기는 작업과도 같습니다. 도서관에서 책을 효율적으로 찾기 위해서는 각 책이 특정 주제나 키워드에 따라 잘 정리되어 있어야 하듯이, 변환된 고차원 벡터 역시 빠르게 검색될 수 있도록 체계적으로 인덱싱 되어있어야 검색 속도와 정확도를 높힐 수 있습니다. 인덱싱이 잘 되어 있다면 필요할 때 원하는 책을 쉽게 찾을 수 있는 것처럼, 벡터화된 텍스트도 효율적으로 검색하고 활용할 수 있게 되는 것이지요.

3. 청킹(chunking), 임베딩(embedding), 인덱싱(indexing)의 상호작용

앞서 살펴본 것 처럼 청킹과 임베딩 그리고 인덱싱은 서로 밀접하게 연관되어 있습니다. 청킹된 텍스트는 작은 단위로 나누어져 벡터화되고, 그 후 인덱싱을 통해 질서 정연하게 저장됩니다. 이후 사용자가 검색어를 입력하면 청킹된 벡터들과의 유사도 계산을 통해 가장 관련성 높은 문서를 찾아낼 수 있습니다. 이때, 인덱싱이 잘 되어 있으면 검색 시간이 훨씬 더 빨라지거나, 관련성 높고 정확한 정보가 검색됩니다. 따라서 이 세가지 요소는 서로 보완하며, 전체적인 RAG 파이프라인의 성능과 속도를 개선합니다. 다음 시간에는 벡터DB에 대해 더욱 자세히 알아보도록 하겠습니다.