긴 컨텍스트 LLM이 검색 증강 생성(RAG)을 죽일까?
AI에서 혁신과 패권을 추구하는 움직임은 둔화될 조짐을 보이지 않습니다. 최근 Google은 최신 대규모 언어 모델인 Gemini가 공개된 지 불과 두 달 만에, 최대 1,000만 토큰에 달하는 인상적인 컨텍스트를 처리할 수 있는 Gemini 1.5,를 공개했습니다(LLM). 동시에 OpenAI는 매혹적인 시각 효과로 주목받는 강력한 텍스트-투-비디오 모델인 Sora로 무대에 올랐습니다. 이 두 최첨단 기술의 대결은 AI의 미래, 특히 검색 증강 생성(RAG)의 역할과 잠재적 종말에 대한 논의를 촉발했습니다.
이 블로그에서는 Gemini의 긴 컨텍스트 기능, 한계, 그리고 검색 증강 생성 기법의 발전에 미치는 영향을 자세히 살펴보겠습니다. 무엇보다도 RAG가 종말의 기로에 서 있는지, 그리고 RAG systems를 어떻게 최적화할 수 있는지 논의하겠습니다.
Gemini의 긴 컨텍스트 기능 이해하기
Sora의 시각 효과가 더 많은 관심을 끌고 있지만, 저는 Gemini와 그에 수반되는 50페이지가 넘는 technical report에 더 관심이 있습니다. 이 보고서는 Gemini의 긴 컨텍스트 및 멀티모달 기능 테스트를 탐구합니다. 이 보고서에 따르면 Gemini 1.5 Pro는 최대 1,000만 토큰의 초장문 컨텍스트와 멀티모달 데이터 처리를 지원하여, 책 한 권 전체와 방대한 문서 모음부터 대규모 코드 라이브러리와 1시간 분량의 영화에 이르기까지 다양한 데이터와 Gemini가 원활하게 상호작용할 수 있게 합니다.
Gemini 1.5 Pro는 최대 1,000만 토큰의 초장문 컨텍스트를 지원합니다. 이미지 출처: https://blog.google/technology/ai/google-gemini-next-generation-model-february-2024/
검색 안정성과 정확도
이 보고서는 Gemini 1.5 Pro와 GPT-4의 검색 능력을 테스트하고 비교하기 위해 "건초더미 속 바늘" 평가 방법을 소개합니다. 이 테스트에서 Google은 긴 문서("건초더미")의 서로 다른 위치에 텍스트 세그먼트("바늘")를 삽입하고, Gemini와 GPT가 관련 문서를 찾아 이름을 지정해 검색하도록 합니다.
테스트 결과에 따르면 Gemini 1.5 Pro는 최대 530,000토큰에서 100% 재현율을 달성하고, 최대 100만 토큰에서도 99.7% 이상의 재현율을 유지합니다. 1,000만 토큰의 초장문 문서에서도 이 모델은 인상적인 99.2%의 재현율을 유지합니다. GPT-4가 128,000토큰 미만을 훌륭하게 처리하는 반면, Gemini는 더 긴 컨텍스트를 처리하는 데 더 능숙합니다. 이러한 결과는 최대 1,000만 토큰에 이르는 예외적으로 긴 컨텍스트에서 Gemini의 뛰어난 정보 검색 능력, 안정성 및 정확도를 강조합니다.
이미지 출처: https://storage.googleapis.com/deepmind-media/gemini/gemini_v1_5_report.pdf
질의응답
Gemini의 검색 능력을 테스트하는 것 외에도, Google은 컨텍스트를 제공하고 그 질의응답 능력을 평가합니다. 이 테스트에서 Google은 책 Les Misérables(710,000토큰)를 컨텍스트로 사용하고 Gemini 1.5 Pro, Gemini 1.0 Pro 및 Anthropic의 Claude 2.1에게 이 책에 대한 질문에 답하도록 요청합니다.
Gemini 1.0 Pro와 Claude 2.1은 710,000토큰보다 더 작은 컨텍스트 길이를 지원하기 때문에, 이들은 검색 증강 생성(RAG) 기법을 활용하여 책에서 Top-K의 가장 관련성 높은 구절(최대 4,000토큰)을 컨텍스트로 접근해야 합니다. Gemini는 더 큰 컨텍스트 창을 가지고 있으므로 책 전체를 컨텍스트로 참조합니다. 이 테스트는 또한 컨텍스트로 아무것도 제공하지 않는 0-shot 설정에서 세 모델의 성능을 비교합니다.
테스트 결과는 Gemini 1.5 Pro가 질문에 답하는 데 있어 다른 RAG 기반 LLM보다 뛰어난 성능을 보이며, 방대한 텍스트 컬렉션을 이해하고 처리하는 데 있어 그 우위를 보여줍니다. 이 테스트는 또한 검색 증강 생성 기법이 장거리 의존성을 가진 데이터 소스 전반의 참조 표현과 추론을 해결하는 데 종종 어려움을 겪는다는 점도 드러냅니다.
이미지 출처: https://storage.googleapis.com/deepmind-media/gemini/gemini_v1_5_report.pdf
장문 컨텍스트 LLM이 RAG를 없앨까요?
검색 증강 생성 프레임워크는 벡터 데이터베이스, LLM, prompt-as-code를 통합하여, 외부 지식 소스를 원활하게 결합함으로써 정확하고 관련성 높은 문서와 답변을 위해 LLM의 지식 기반을 풍부하게 하는 최첨단 기술입니다. 이는 환각 및 도메인별 지식 부족과 같은 근본적인 LLM 과제를 효과적으로 해결하는 검증된 솔루션입니다.
Gemini가 긴 컨텍스트를 처리하는 인상적인 성능을 목격하면서, 일부 목소리는 RAG의 종말을 빠르게 예측합니다. 예를 들어 Twitter에서 Gemini 1.5 Pro를 리뷰하며 Dr. Yao Fu는 “1,000만 컨텍스트가 RAG를 죽인다”고 과감하게 말했습니다.
이 주장이 사실일까요? 제 관점에서 답은 “아니요”입니다. RAG 기술의 발전은 이제 막 시작되었으며 계속 진화할 것입니다. Gemini는 확장된 컨텍스트를 관리하는 데 뛰어나지만, Velocity, Value, Volume, Variety라는 4V로 요약되는 지속적인 과제와 씨름하고 있습니다.
LLM의 4V 과제
Velocity: Gemini는 광범위한 컨텍스트에 대해 1초 미만의 응답 시간을 달성하는 데 장애물에 직면해 있으며, 이는 360,000개 컨텍스트에 응답하는 데 30초 지연이 발생한 것으로 입증됩니다. LLM의 연산 발전에 대한 낙관론에도 불구하고, 긴 컨텍스트를 검색할 때 1초 미만 수준의 빠른 응답은 대형 트랜스포머 기반 모델에게 여전히 어려운 과제로 남아 있습니다.
Value: LLM의 가치 제안은 긴 컨텍스트에서 고품질 답변을 생성하는 데 드는 상당한 추론 비용으로 인해 약화됩니다. 예를 들어, 1000토큰당 1.50에 이를 가능성이 있습니다. 이러한 비용 요인은 일상적인 활용에 있어 이처럼 높은 지출을 비현실적으로 만들며, 광범위한 도입에 중대한 장벽이 됩니다.
Volume: 최대 1,000만 토큰의 대형 컨텍스트 창을 처리할 수 있는 능력에도 불구하고, Gemini의 볼륨 용량은 비정형 데이터의 방대함과 비교하면 왜소해집니다. 예를 들어 Gemini를 포함한 어떤 LLM도 Google 검색 색인 내에서 발견되는 거대한 규모의 데이터를 충분히 수용할 수 없습니다. 또한 민간 기업 데이터는 소유자의 경계 내에 머물러야 하며, 소유자는 RAG를 사용하거나 자체 모델을 학습하거나 private LLM을 사용할 수 있습니다.
다양성: 실제 사용 사례에는 긴 텍스트, 이미지, 동영상과 같은 비정형 데이터뿐만 아니라 시계열 데이터, 그래프 데이터, 코드 변경 사항처럼 학습 목적으로 LLM이 쉽게 포착하지 못할 수 있는 다양한 구조화 데이터도 포함됩니다. 이러한 다양한 데이터를 효율적으로 처리하려면 간소화된 데이터 구조와 검색 알고리즘이 필수적입니다.이 모든 과제는 AI 애플리케이션 개발에서 균형 잡힌 접근 방식의 중요성을 강조하며, 인공지능의 진화하는 환경에서 RAG가 점점 더 중요해지고 있음을 보여줍니다.
RAG 효과 최적화를 위한 전략
검색 증강 생성은 LLM 환각을 줄이는 데 유익한 것으로 입증되었지만, 한계도 있습니다. 이 섹션에서는 RAG 시스템을 더 넓은 범위의 애플리케이션에 걸쳐 더 잘 적응할 수 있도록 정확성과 성능 사이의 균형을 맞추기 위해 검색 증강 생성 효과를 최적화하는 전략을 살펴보겠습니다.
긴 컨텍스트 이해 향상
기존의 검색 증강 생성 기법은 주로 임베딩 모델의 크기 제한과 컨텍스트 창 때문에 비정형 데이터를 벡터화하기 위해 청킹에 의존하는 경우가 많습니다. 그러나 이 청킹 접근 방식에는 두 가지 주목할 만한 단점이 있습니다.
- 첫째, 입력 시퀀스를 고립된 청크로 분할하여 컨텍스트의 연속성을 방해하고 임베딩 품질에 부정적인 영향을 미칩니다.
- 둘째, 연속된 정보가 서로 다른 청크로 분리될 위험이 있어 필수 정보가 불완전하게 검색될 가능성이 있습니다.
이러한 과제에 대응하여 LLM을 기반으로 하는 새로운 임베딩 전략이 효율적인 솔루션으로 주목받고 있습니다. 이 전략들은 더 나은 임베딩 기능을 자랑하며 확장된 컨텍스트 창을 지원합니다. 예를 들어, Huggingface MTEB LeaderBoard에서 가장 우수한 성능을 보이는 두 임베딩 언어 모델인 SRF-Embedding-Mistral과 GritLM7B는 32k 토큰 길이의 컨텍스트를 지원하여 임베딩 기능의 상당한 개선을 보여줍니다. 비정형 데이터 임베딩의 이러한 향상은 RAG의 긴 컨텍스트 이해도도 높입니다.
위의 과제를 해결하기 위한 또 다른 효과적인 접근 방식은 최근 공개된 BGE Landmark Embedding 전략입니다. 이 접근 방식은 청킹 없는 아키텍처를 채택하며, 예를 들어 문장과 같은 세분화된 입력 단위의 임베딩을 일관된 긴 컨텍스트를 기반으로 생성할 수 있습니다. 또한 위치 인식 함수를 활용하여 긴 컨텍스트 내에서 여러 개의 연속 문장으로 구성된 유용한 정보를 완전하게 검색하도록 돕습니다. 따라서 landmark embedding은 RAG 시스템이 긴 컨텍스트를 이해하고 처리하는 능력을 향상하는 데 유익합니다.
landmark embedding의 아키텍처. Landmark (LMK) 토큰은 각 문장의 끝에 추가됩니다. LLM의 컨텍스트 창보다 긴 입력 텍스트를 처리하기 위해 슬라이딩 창이 사용됩니다. 이미지 출처: https://arxiv.org/pdf/2402.11573.pdf
이 도표는 RAG 앱이 질문에 답하도록 돕는 데 있어 Sentence Embedding과 Landmark Embedding 방법을 비교합니다. 전자는 청크된 컨텍스트로 작동하며, 이는 두드러진 문장을 선택하는 경향이 있습니다. 후자는 일관된 컨텍스트를 유지하여 올바른 문장을 선택할 수 있게 합니다. 파란색과 보라색으로 강조 표시된 문장은 각각 두 임베딩 방법으로 검색된 답변입니다. Sentence embedding을 활용한 RAG 시스템은 잘못된 답을 제시한 반면, Landmark embedding 기반 RAG는 올바른 답을 제시했습니다. 이 이미지는 다음에서 각색되었습니다: https://arxiv.org/abs/2402.11573
향상된 검색 품질을 위한 Hybrid Search 활용
검색 증강 생성 응답의 품질은 고품질의 관련 정보를 검색하는 능력에 달려 있습니다. 데이터 정제, 구조화된 정보 추출, hybrid search는 모두 검색 품질을 향상시키는 효과적인 방법입니다. 최근 연구에 따르면 Splade와 같은 sparse vector 모델은 도메인 외 지식 검색, 키워드 인식, 의미 검색 및 기타 여러 영역에서 dense vector 모델보다 뛰어난 성능을 보입니다.
최근 오픈소스로 공개된 BGE_M3 embedding model은 동일한 모델 내에서 sparse, dense, Colbert 유사 토큰 벡터를 생성할 수 있습니다. 이 혁신은 다양한 유형의 벡터 전반에 걸쳐 하이브리드 검색을 수행함으로써 vector database의 검색 품질을 크게 향상시킵니다. 특히 이 접근 방식은 Zilliz와 같은 vector database 벤더들 사이에서 널리 받아들여지는 hybrid search 개념과 일치합니다. 예를 들어, 곧 출시될 Milvus 2.4는 dense 및 sparse vectors에 대한 보다 포괄적인 hybrid search를 약속합니다.
RAG 성능 향상을 위한 고급 기술 활용
이 도표에서 Wenqi Glantz는 RAG pipeline을 개발하는 데 있어 12가지 난점을 나열하고, 이러한 과제를 해결하기 위한 12가지 해당 솔루션을 제안했습니다. 이미지 출처:https://towardsdatascience.com/12-rag-pain-points-and-proposed-solutions-43709939a28c
RAG 기능을 극대화하려면 수많은 알고리즘적 과제를 해결하고 정교한 엔지니어링 역량과 기술을 활용해야 합니다. Wenqi Glantz가 그녀의 블로그에서 강조했듯이, RAG pipeline을 개발하는 데에는 최소 12가지의 복잡한 엔지니어링 과제가 있습니다. 이러한 과제를 해결하려면 ML 알고리즘에 대한 깊은 이해와 query rewriting, intent recognition training data,, entity detection과 같은 복잡한 기법의 활용이 필요합니다.
Gemini 1.5와 같은 고급 모델조차도 상당한 장애물에 직면합니다. Google의 MMLU 벤치마크 테스트에서 90.0%의 정확도를 달성하려면 32회의 호출이 필요합니다. 이는 RAG 시스템에서 성능을 극대화하는 특성을 잘 보여줍니다.
벡터 데이터베이스는 최첨단 AI 기술 중 하나로, RAG 파이프라인의 핵심 구성 요소입니다. Milvus와 같은 더 성숙하고 진보된 벡터 데이터베이스를 선택하면 RAG 파이프라인의 기능이 답변 생성에서 분류, 구조화된 데이터 추출, 복잡한 PDF 문서 처리와 같은 작업으로 확장됩니다. 벡터 데이터베이스의 이러한 다면적인 향상은 더 넓은 범위의 애플리케이션 사용 사례에서 RAG 시스템의 적응성에 기여합니다.
결론: RAG는 AI 애플리케이션의 지속적인 성공을 위한 핵심 축으로 남아 있습니다.
대규모 언어 모델은 세계를 재편하고 있지만, 우리 세계의 근본 원칙을 바꿀 수는 없습니다. 연산, 메모리, 외부 데이터 저장소의 분리는 1945년 폰 노이만 아키텍처가 시작된 이래 존재해 왔습니다. 그러나 오늘날 단일 머신 메모리가 테라바이트 수준에 도달했음에도, SATA와 플래시 디스크는 여전히 다양한 애플리케이션 사용 사례에서 중요한 역할을 합니다. 이는 기술 발전에 직면해서도 기존 패러다임이 견고함을 보여줍니다.
RAG 프레임워크는 여전히 AI 애플리케이션의 지속적인 성공을 위한 핵심 축입니다. 대규모 언어 모델에 장기 메모리를 제공하는 것은 쿼리 품질과 비용 효율성 간의 최적 균형을 추구하는 개발자에게 필수적임이 입증됩니다. 대기업이 생성형 AI를 배포할 때 RAG는 응답 품질을 저하시키지 않으면서 비용을 제어하는 핵심 도구입니다.
대용량 메모리의 발전이 하드 드라이브를 몰아낼 수 없는 것처럼, 벡터 데이터베이스와 같은 지원 기술과 결합된 RAG의 역할은 여전히 필수적이고 적응적입니다. 이는 AI 애플리케이션과 정보 검색의 끊임없이 진화하는 새로운 데이터 환경 안에서 지속되고 공존할 준비가 되어 있습니다.
계속 읽기
Will Amazon S3 Vectors Kill Vector Databases—or Save Them?
AWS S3 Vectors aims for 90% cost savings for vector storage. But will it kill vectordbs like Milvus? A deep dive into costs, limits, and the future of tiered storage.
Zilliz Cloud Delivers Better Performance and Lower Costs with Arm Neoverse-based AWS Graviton
Zilliz Cloud adopts Arm-based AWS Graviton3 CPUs to cut costs, speed up AI vector search, and power billion-scale RAG and semantic search workloads.
Announcing the General Availability of Zilliz Cloud BYOC on Google Cloud Platform
Zilliz Cloud BYOC on GCP offers enterprise vector search with full data sovereignty and seamless integration.