RAG(검색 증강 생성)을 위한 AI 데이터베이스
Intro
Aeca 웹사이트에서 제공 중인 Aeca Search Demo는 검색 증강 생성(RAG) 데모입니다. 샘플 데이터는 국문/영문 위키피디아 전수 데이터로 약 3억 8천만 개의 임베딩이 저장되어 있습니다. 대략 1.1TB 정도이며, 위키피디아에서 새롭게 생성된 정보 또는 기존 문서 내 편집된 내용을 실시간으로 Aeca 데이터베이스에 저장 후 가장 최신 데이터를 제공하고 있습니다. 데이터 용량이 꽤 크지만 클라우드가 아닌 가정용 와이파이 환경 홈서버에서 기본 사양의 Mac Mini로 제공 중입니다. 샤딩과 같은 분산처리 없이 Aeca 단 1대 만으로 데이터 처리하고 있습니다. 매우 낮은 서버 비용으로 사용 가능합니다.
Retrieval Augmented Generation (RAG) 이해
RAG 모델이 외관상으로는 GPT와 비슷하지만 LLM이 학습된 정보를 바탕으로 답변하는 것이 아니라 검색 모델(Retrieval)이 외부 저장소에서 데이터를 검색하고 이를 근거로 생성 모델(Generation)이 답변하는 구조입니다. 학습된 내용이 아니라 검색된 내용을 근거로 하기 때문에 답변의 신뢰성을 높일 수 있고, 실시간 정보도 처리할 수 있습니다.
- 검색(Retrieval): 데이터베이스 또는 검색 엔진에 저장된 데이터에서 사용자의 질문에 가장 적합한 검색 결과를 반환합니다.
- 생성(Generation): 검색된 정보를 활용하여 새로운 문장, 답변, 요약 등을 생성합니다. 특히 회사가 갖고 있는 고유 데이터는 보안상 이슈로 학습이 어렵지만 RAG를 사용하면 학습되지 않은 내용이라 하더라도 질의응답이 가능합니다. 뉴스, SNS와 같은 실시간 업데이트 정보도 검색 모델이 검색하여 전달하므로 응답의 최신성을 확보할 수 있습니다.
RAG의 핵심, 검색 모델
RAG의 핵심은 검색입니다. 유저가 질문을 하면 질문 의도에 가장 적합한 내용을 찾아 LLM에 컨텍스트로 전달해야 합니다. “사용자 의도에 맞는” 검색 결과를 충실히 수행하는 검색 모델을 구축하는 게 간단하지 않습니다. Full-Text Search(FTS)만으로는 문맥을 파악하기 어렵습니다. 대표적으로 동의어 처리 이슈가 있는데, 예를 들어 프론트엔드 개발자 JD를 찾기 위해 웹 개발을 검색할 경우 같은 의미이지만 검색이 안 되는 경우가 자주 발생합니다. 반대로 동일한 단어가 포함되었다는 이유로 엉뚱한 결과가 나오기도 합니다.
이런 한계점을 보완하기 위해 Vector Search를 사용합니다. 임베딩 모델을 사용하여 텍스트(문장 혹은 문단)를 배열 형태의 벡터 임베딩으로 변환, 벡터 임베딩 간의 거리를 계산하여 가까울수록 유사하다고 판단하는 것입니다. Vector Search의 단점은 Parameter가 조금만 달라져도 검색 결과가 크게 틀어지는 문제가 있습니다. 결론적으로 FTS, Vector Search 중 한 가지 만을 사용해서는 문맥을 고려한 검색 결과를 찾기가 어렵고, FTS 결과와 Vector Search 결과에 가중치를 주어 최종 Scoring을 산출하는 Hybrid Search가 Retrieval 모델을 위한 방법론으로 떠오르고 있습니다.
이와 같이 수준 높은 RAG를 구현하기 위해서는 인프라가 복잡해질 수밖에 없습니다. 원본 데이터를 저장하는 데이터베이스에 Full-Text Search Engine, Vector Database를 연결하여 동기화해야 하는데, 특히 실시간성을 요할 경우 트랜잭션 발생 즉시 검색을 하기 위한 복잡한 작업이 필요합니다. 원활한 서비스를 위해서는 Cache DB(Redis 등)도 사용해야 합니다. 비용도 크지만, 그만큼 많은 시간이 걸릴 수밖에 없습니다. 구축 이후에는 안정적으로 운영하기 위해 모니터링을 위해 수많은 DevOps 작업도 필요합니다.
RAG의 검색 모델에 요구되는 사항은 아래와 같습니다.
- Real Time: 데이터 추가, 변경, 삭제를 실시간으로 처리
- Transaction: 검색 대상 데이터의 신뢰성과 일관성을 유지 (데이터를 효과적으로 관리하고 변경 이력을 추적하여 필요한 경우 이전 상태로 롤백하거나 복구 가능)
- Low Latency: 저장소에 있는 대용량 데이터를 지연 없이 검색
- Semantic Search: 단순 키워드 일치가 아니라 문맥을 고려한 사용자 의도와 유사한 정보를 검색
- Scalability: 사용자 수의 증가나 피크 시간에 발생하는 부하를 효과적으로 관리
AI 데이터베이스 단 1대로 구현하는 RAG
이렇게 다양하고 복잡한 기술 스택이 필요한 RAG를 단 하나의 제품으로 구축할 수 있다면 어떨까요? 기술 스택이 일원화 됨으로써 압도적인 비용/시간 절감을 달성할 수 있고 이는 서비스 경쟁력으로 이어질 것입니다.
Aeca는 AI 소프트웨어 개발에 필요한 기술 스택을 단 하나의 데이터베이스에서 제공하는 제품입니다. RAG 또한 여러 제품을 사용할 필요 없이 Aeca 단 하나로 쉽고 빠르게 구현할 수 있습니다. OLTP 데이터베이스인 동시에 OLAP, Full-Text Search, Vector Search, Time to Live를 모두 제공합니다. 원본 데이터, 임베딩 데이터 등을 여러 저장소에 분산하여 저장하고 동기화할 필요 없이 하나의 저장소에 보관하여 압도적인 개발 속도를 달성할 수 있습니다.
RAG의 검색 모델은 검색 대상, 환경이 바뀜에 따라 지속적으로 개선을 해야 합니다. Full-Text Search와 Vector Search를 따로 수행하여 이를 취합하는 기존의 비효율적인 Hybrid Search와 달리 Aeca는 Full-Text Search와 Vector Search를 Single Query로 제공합니다. 이를 통해 실시간으로 가중치를 변경하여 검색 결과를 빠르게 튜닝 할 수 있습니다. Full-Text Search와 Vector Search의 가중치를 조절하는 방법과 함께 Vector Search에 적용한 임베딩 모델 간 가중치를 변경하며 Vector Search 품질도 개선할 수 있습니다. 복수의 임베딩 모델을 사용하기 위해 임베딩 모델 개수만큼 Collection을 생성하는 기존 제품과 달리 Aeca는 여러 임베딩 모델을 하나의 Collection에 통합하여 임베딩 모델 간 Scoring 부여를 통해 압도적으로 빠르게 검색 품질을 향상시킬 수 있습니다.
Conclusion
RAG는 LLM의 한계점을 보완하는 방법론으로 주목받고 있지만, 효과적인 RAG를 구현하기 위한 검색 모델 구축에 많은 비용과 시간이 발생합니다. Aeca는 Real time, Transaction, FTS, Vector Search, Cache 등의 기술 스택을 모두 제공하여 단 하나의 제품만으로 RAG를 쉽고 단순하게 개발할 수 있는 'AI 데이터베이스'입니다.
함께 보면 좋을 글
벡터데이터베이스가 추천시스템에 필요한 이유
현대 애플리케이션에서 사용자의 체류 시간을 늘리기 위해 많은 서비스는 추천 시스템을 도입하고 있으며, 이는 특히 콘텐츠와 이커머스 분야에서 매출과 직접적인 연관이 있는 중요한 요소입니다. 추천 시스템은 사용자의 행동을 분석하여 관심사를 파악하고 관련 아이템을 제공함으로써 체류 시간을 늘리고 구매를 유도합니다. 여기에 어떻게 벡터데이터베이스가 활용될 수 있을까요?
By Tim Yang|2023-09-16
우리에게 벡터 검색이 필요한 이유
우리가 사용하는 모바일 애플리케이션이나 웹서비스에는 검색기능이 있습니다. 대부분은 데이터베이스에서 제공하는 기본적인 텍스트 검색이나 Elasticsearch 같은 검색 엔진에서 제공하는 전문 검색(Full-Text Search)을 사용하여 개발 합니다. Full-Text Search는 주로 텍스트 데이터 검색에 사용되는 전통적인 방법 중 하나로 문서, 웹 페이지, 데이터베이스 등에서 특정 키워드, 단어, 구문 등을 찾아내는 데 중점을 두고 있습니다. 주로 키워드 또는 짧은 문장을 입력하여 텍스트 데이터를 검색 하고, 키워드와 일치하는 문서를 찾는 과정을 거치는데, 문맥이나 의미적 유사성을 고려하지는 않습니다.
By Tim Yang|2023-09-14