LLM RAG구현 과정에서 벡터검색 중 발생하는 정보손실을 줄이기 위한 생각

1. 문제인식

벡터검색의 도입은 LLM의 답변에 안정성을 일부 보장해주는 역할을 한다. 사용자가 원하는 임베드 지식을 제공함으로써 환각을 최소화/배제하고 원하는 방향의 답변을 얻어내고자 하는 것이다. 하지만 벡터검색을 도입해 RAG를 구현(https://pypi.org/project/easy-rag-llm) 하면서 몇가지 문제점에 노출되었고 이를 개선해가는 과정을 기록하고자 한다.

첫째는 정보손실이다. 내가 easy-rag-llm을 구현한 방식은 다음과 같다: PDF에서 텍스트를 추출하고, 청크를 나눈다. 이때 청크는 나중에 검색의 단위가 되는데, 예를 들어 질문쿼리를 통해 "우주방위군"에 대한 입력을 넣는다면 우주방위군과 상위유사도를 가진 청크를 선별해 llm에 전달하는 것이다. 이때 질문쿼리와 유사한 지식만을 선별해 LLM에 전달한다는 것은 RAG의 핵심이자 할루시네이션을 제거하는 Key지만, 벡터검색을 통해 전달 청크에 포함되지 못하는 지식이 발생할 수밖에 없다는 한계가 생긴다. 글을 조각으로 나누어 전달하므로 글의 맥락 정보가 손실되기도한다. 마이크로소프트팀에서는 이 문제를 해결하고자 대안으로 Graph RAG라는 개념을 제시했는데(https://arxiv.org/pdf/2404.16130) 이에 대한건 추후에 더 공부하여 easy-rag-llm에 도입하고자한다. 현재는 지원하고 있는 벡터검색의 성능을 개선하기 위한 방법을 생각한다.

 

2. 개선안

1) Overlap

맥락정보 손실에 대한 고민은 라이브러리를 개발하는 초기부터 했었고 그 대안으로 overlap에 대해 생각하여 적용하였다. 청크간에 앞뒤로 중복되는 토큰을 추가하는 것이다. 청크를 Discrete하게 구성하는 대신 overlap으로 연결을 만들어 맥락을 개념적으로 구현하고자한 것이다.  

 

2) 추정된 Chunk_size의 사용

초기(v1.0.x)엔 청크사이즈를 고정값으로 사용하였다. 토크나이저로 계산된 512개 토큰에 해당되는 문장을 1개 청크로 묶어 처리하는 것이다. 이런 처리과정을 거쳤을때 발생하는 문제는 문장단위의 소실이다. 청크 단위의 앞뒤가 거칠게 끊어진 채로 LLM에 전달되면 LLM은 단일 개체로 들어온 청크의 맥락을 원본의 맥락과 다른 방향으로 이해할 가능성이 증가한다. 이를 해결하기 위해 청크의 앞뒤를 매끄럽게 만들고자 끊김의 단위를 문장(., ), ], ; ," 등으로 끝나는)으로 강제하고, 문장의 개수로부터 chunk_size를 추정해 약 512토큰사이즈의 청크를 만든다. 이는 easy-rag-llm==1.1.5까지 반영되어 있는 사안이다. 

 

3) 정보의 Locality

우리는 컴퓨터 프로그램에 대해 이야기할때 로컬리티에 대한 가정을 한다. 특히 Spatial Locality에 따르면 특정 데이터에 접근했을때 다음 접근할 데이터는 주소상 근처에 있을 확률이 높다. 이는 컴퓨터 메모리에만 국한되지 않으며, 인간이 일반적으로 생성하는 데이터도 로컬리티를 가진다. 검색된 청크의 주변에 검색되지 않았더라도 맥락상, 유의미한 정보가 포함되어있을 가능성이 크다는 생각이다. 

이 생각을 토대로 검색된 상위 청크 앞뒤 청크를 연결해 augmented chunk를 제공하는 옵션을 구현하려한다. 이때 예상되는 문제는 불필요한 데이터처리량의 증가와 더불어 LLM의 처리한계에 쉽게 도달할 수 있다는 점이다. 따라서 augmented chunk 옵션에서는 청크의 추정사이즈를 줄이고, 증강하는 앞뒤 청크의 개수를 늘리는 방식을 생각중이다. 

대략 표현해보면 이런 방식인데, 좌측이 기존 v1.1.5까지의 방식, 우측이 고안한 방식이다. 청크사이즈를 줄이고 앞뒤에 다른 청크를 추가로 연결해 증강시키는 것이다. 이미지에서는 LLM에 넘기는 정보량에 변화가 없게 할 수 있다고 표현하기 위해 같은 양의 청크를 표현했다.