SK하이닉스의 RAG 플랫폼 구축 및 성능 평가/분석 연구 사례

이 블로그는 SK hynix 오세진 TL, 노정기 TL, 오태진 TL 이 함께 작성하였습니다.

SK 하이닉스는 AI 시대라는 새로운 세상의 중심에 반도체가 있다는 사명감을 가지고 최고의 기술력을 향해 끊임없는 혁신을 이뤄 가고 있습니다. 세계 최고 성능의 HBM3를 최초 개발 및 출시한 데 이어 확장 버전인 HBM3E 역시 세계 최초 양산에 성공하며 메모리 반도체 시장을 선도하고 있고, 세계 최고층 321단 낸드플래시 샘플을 최초로 공개하는 등 최초, 최고의 기록을 써내려 가며 기술력을 입증하고 있습니다.

SK 하이닉스의 Memory Systems Research (이하 MSR)에서는 Data Center와 Cloud 환경에서 SK 하이닉스의 차세대 메모리/스토리지 기술을 적용하기 위한 선행 연구를 진행하고 있습니다. 최근 Generative AI 기술이 급속도로 발전하면서, LLM(Large Language Model)과 같은 AI 워크로드에 최적화된 메모리 시스템 연구의 중요성은 더욱 부각되고 있습니다.

이 블로그에서는 MSR 조직이 AWS Cloud를 활용하여 Generative AI 플랫폼을 구축하고 성능을 평가/분석한 연구 사례를 공유합니다.

Cloud 활용 배경

MSR 조직은 기존에 On-Premise 환경에서 연구를 진행해 왔으나 자체 구축한 SW 플랫폼의 타당성 및 정합성의 판단 한계가 존재하였고, 인프라 구축에 있어 확장성, 유연성, 용도 전환 등에 어려움이 존재한다는 것을 파악하였습니다. 더욱이 빠르게 변화 중인AI 기술 연구를 위해 신속하고 고도화된 분석 대응이 필요하였습니다. 이에 On-Premise 환경의 Pain-Point를 극복하고, Cloud 시스템 이해 및 인프라 활용을 통해, AI 기술에서의 메모리/스토리지 연관성을 도출하고자 Cloud 활용을 추진하였습니다. 24년은 Cloud를 연구에 활용하기 위해 그 타당성을 검증하는 첫해였고, 타겟 응용은 RAG 플랫폼으로 선정하여 연구를 진행하였습니다. 본 연구에서는 RAG 시스템에서 벡터 검색 시 메모리와 스토리지 간의 상호작용이 성능에 미치는 영향을 중점적으로 분석하여, 향후 메모리 시스템 최적화 방향을 도출하고자 하였습니다.

RAG 연구 개요

대규모 언어 모델(LLM)을 사용한 AI 응용이 다양한 분야로 확대되면서 Retrieval Augmented Generation(RAG) 기술이 주목받으며 도입되고 있습니다. RAG는 대규모 언어 모델(LLM)을 사용하여 응답을 생성할 때, 학습된 데이터 소스 외부의 신뢰할 수 있는 지식 베이스를 참조하도록 하는 기술입니다 [1]. LLM을 사용한 응답 생성 시스템에 지식 데이터를 관리하고 검색하는 기능이 추가되는 구조로, 일반적으로 벡터 데이터베이스를 사용하여 해당 기능을 지원합니다. 본 연구에서는 RAG 시스템, 특히 Cloud 환경에서의 시스템 구조와 핵심 솔루션들을 검토하였습니다. 또한, 직접 시스템을 구축하여 성능 평가를 통해 추론(Inference) 수행 시 발생할 수 있는 문제점들을 분석하였습니다.

RAG 기술 소개 및 동향

RAG 기술 소개

LLM은 지능형 챗봇 및 기타 자연어 처리 애플리케이션을 지원하는 핵심 인공 지능 기술이지만, 훈련된 데이터에 의존하기 때문에 최신의 정확한 응답을 제공하는데 한계가 있으며, 응답이 없는 경우 허위 정보를 제공하는 문제가 알려져 있습니다. RAG는 이러한 문제점을 해결하기 위해서 제안되었으며, 파인튜닝(fine-Tuning)과 같이 특정 데이터를 사용해서 훈련(Training)하는 방법 대비 비용, 성능 측면에서 효과적입니다. 특히 조직의 독점 데이터 및 도메인 별 데이터에 맞게 관련성 높은 응답을 제공할 수 있어서 점차 사용이 늘어나고 있습니다. 기본 RAG 구성 및 동작 흐름을 간단하게 보여줍니다.

Figure 1. 기본 RAG 흐름도

RAG는 1) 지식 데이터를 추가하는 Data Ingestion과 2) 사용자의 질의에 대한 응답을 생성하는 Inference로 나뉩니다. 사용자 질의에 대한 지식 검색은 정확하게 일치하는 데이터를 검색하는 것이 아니라, 관련성이 높은 데이터를 검색하는 “유사성 검색(Similarity Search)”, “의미론적 검색(Semantic Search)” 방식을 사용합니다. 이와 같은 검색을 수행하기 위해 벡터 데이터 베이스를 사용하는데, 벡터 데이터 베이스는 데이터들을 벡터화하여 데이터 간의 거리 계산을 통해 관련성을 파악합니다. 따라서 Data Ingestion 시 Text, Image 형태의 일반 데이터를 임베딩 모델을 사용해서 벡터 데이터로 변환하여 저장합니다. Inference 시에는 동일한 임베딩 모델을 사용하여 사용자 쿼리를 벡터 데이터로 변환 후, 벡터 데이터베이스에서 검색을 수행합니다. 최종적으로 검색된 결과 원본 데이터를 사용자 질의와 함께 LLM에 입력으로 제공합니다. LLM은 사용자 질의와 함께 관련된 지식, 정보를 제공받기 때문에 보다 정확한 답변을 생성해 낼 수 있습니다. 최근에는 답변의 정확도를 더욱 높이기 위해서 지식 검색 전/후로 여러 가지 기술을 개발하여 적용하고 있으며, 이를 Advanced RAG라 합니다. 본 연구에서는 Advanced RAG 기술에 대해서는 다루지 않고, RAG 시스템의 기본 구조, 기술에 대해서만 다룹니다.

RAG 기술 동향

글로벌 AI 동향 연구 [2]에 따르면 Generative AI 응용이 다른 어떤 AI 응용보다 많이 채택되고 있습니다. 기업의 Generative AI 응용에서 LLM을 사용 시 여러 환경과 외부 소스에서 새로운 데이터를 효과적으로 검색하여 활용하는 것이 요구되고 있기 때문에 RAG가 핵심 역할을 수행할 수 있을 것으로 예상됩니다. “2024: The State of Generative AI in the Enterprise 보고서 [3]”에 따르면 RAG 채택률이 2023년 31%에서 2024년 51%로 상승하여 지배적이며, Fine-tunning 등 다른 기술의 채택은 감소하였습니다. 그리고 올해 도입된 Agent 기능이 RAG와 함께 미래 기술로 주목되고 있습니다.

RAG 응용, 사용자의 확대에 따라서 RAG에서 사용하는 데이터 셋 크기도 증가할 것으로 예상됩니다. 의료 분야의 경우 데이터의 양이 35% 이상의 CAGR(Compound Annual Growth Rate) 로 증가 [4]하는 것으로 전망되며, Text 외에 Audio, Video, Image 데이터를 사용하는 Multimodal 지원도 데이터 크기를 확대시키는 요인이 될 것입니다. 따라서 향후 RAG 시스템에서 사용되는 데이터 양 증가 시 검색 속도와 정확도를 보전할 수 있는 확장성이 중요한 과제가 될 수 있을 것입니다.

Figure 2. 기업의 AI 설계 구조

기술 검토 및 분석을 위한 Reference RAG 시스템

AWS Cloud RAG System 구축 내용

RAG 시스템과 솔루션은 AWS Solutions Architect들의 자문을 받아 실제 고객들이 사용하는 솔루션과 구조를 참고로 설계하였습니다. 아래 Figure 3은 위에서 소개한 RAG 기본 구성에 대응되는 AWS 사의 솔루션을 나타냅니다.

Figure 3. RAG 단계 별 AWS 솔루션

1. Amazon SageMaker Notebook – Computing Instance로 사용자의 작업 환경에 해당합니다. RAG 시스템에 요청할 질문을 생성하고 답변을 수신하는 어플리케이션이 동작합니다.
2. AWS Lambda – AWS의 Serverless Computing Service 입니다. 하나의 함수 단위로 실행하며, 사용자가 요청한 시점에 Cloud 시스템에서 자동으로 Computing Instance를 생성하여 구현된 함수를 실행합니다. 본 시스템에서는 사용자가 질의를 전달하면 이를 수신하여 RAG 전체 과정을 수행하는 Web Server와 같은 역할을 수행합니다. 다수의 요청이 동시에 발생되었을 경우에는 요청된 개수만큼 Lambda Instance가 생성되어 독립적으로 요청을 처리합니다.
3. Embedding Endpoint – 데이터 입력 시와 질문에 대한 정보 검색 수행 시 벡터 임베딩을 처리하는 역할을 수행합니다. NVIDIA A10G GPU 1 개로 구성된 시스템에 768 Dimension을 지원하는 “Jina Embeddings-v2-base-en” 모델을 사용하여 SageMaker Endpoint를 구성하였습니다.
4. Amazon OpenSearch Service – 벡터 데이터 베이스 시스템입니다. 실제 환경에서는 데이터 셋 크기, 처리 요구 성능 등에 따라 노드의 개수를 결정하는데, 본 실험에서는 하나의 데이터 노드로 구성하였습니다.
5. LLM Endpoint – NVIDIA A100 8개의 GPU를 사용한 시스템에 “Llama 3.1 8B instruct” model을 사용하여 SageMaker Endpoint를 구성하였습니다.

아래 Table 1 에 각 Component 별 주요 Hardware 스펙을 정리하였습니다.

Table 1. AWS RAG Component Hardware 사양

RAG Inference Work flow

RAG Inference를 수행하는 Work flow는 아래와 같습니다. 사용자는 1) Query를 생성하여 Lambda 함수를 호출합니다. RAG 시스템은 요청을 받으면, 2) Lambda Instance를 생성하여 함수를 실행합니다. Lambda 함수는 먼저 데이터 검색을 위해서 3) Query에 대한 벡터 임베딩 처리를 요청하여 결과를 수신합니다. 그러고 나서 4) OpenSearch에 유사한 데이터에 대한 검색을 요청합니다. 본 평가에서는 Top_K 값을 10으로 설정하여, 10개의 관련이 높은 데이터 검색 결과를 반환 받습니다. 마지막으로 사용자의 질문과 함께 검색 결과를 5) LLM으로 전달하여 최종 답변을 생성합니다.

Figure 4. RAG Inference Work flow

평가환경

1. 데이터 셋

Google의 Natural Question 데이터 셋[5]과 함께 웹크롤링 데이터를 사용하였습니다. Natural Question의 경우 질문과 답변을 모두 제공하기 때문에 RAG 성능 평가에 적합합니다. 하지만, Text 데이터만 추출 시 원본 데이터 크기가 약 300 MB 정도로 여러 종류의 실험을 수행하기에는 크기가 작기 때문에 웹 크롤링 데이터를 함께 사용하였습니다.

2. 사용자 질문

Google의 Natural Question 데이터 셋에서 1000 개의 질문을 추출하여 사용하였습니다. 사용자가 질문할 때 1000개의 질문 중에서 랜덤 하게 하나의 질문을 선택합니다. 지식 데이터 검색은 질문과 유사한 데이터를 검색하는 것이기 때문에 동일한 질문을 반복하지 않고, 실제와 유사한 패턴의 검색을 수행하고자 함입니다.

3. 벡터 검색을 위한 ANN 알고리즘

벡터 검색 알고리즘은 Hierarchical Navigable Small World Graph(HNSW)[6]를 사용하였습니다. Amazon OpenSearch의 경우 HNSW와 함께 Inverted File Index(IVF) 알고리즘을 지원하는데, HNSW 알고리즘의 성능과 정확도가 높아서 가장 많이 사용되는 것으로 알려져 있습니다.

• HNSW을 비롯한 ANN 알고리즘들은 벡터데이터들을 노드로 가지는 그래프를 구성하고 노드 간의 거리를 계산하여 유사성이 높은 데이터를 찾아내는 방식으로 검색을 수행합니다. 이를 위해 생성한 그래프와 필요한 정보를 통합하여 인덱스(Index)라고 합니다. HNSW 알고리즘은 벡터 데이터가 삽입되면, 벡터 데이터들에 대한 인덱스를 구성하고, 이를 모두 메모리에 로드한 상태에서 검색을 수행합니다.

4. 테스트 시나리오

HNSW 알고리즘은 인덱스를 모두 메모리에 로드한 상태에서 검색을 수행하는 것을 기본으로 하기 때문에 인덱스를 구성하는 데이터 셋 크기에 따라서 메모리 요구량, 연산량, 스토리지와의 연계 등의 변수가 발생됩니다. 인덱스를 중심으로 다음과 같은 3가지 테스트 시나리오를 정의하였습니다.

5. OpenSearch 인덱스 및 시스템 정보

6. 평가 방법

성능 평가는 Open Source 부하 Tool 인 Locust[7]에 필요한 기능을 구현하여 진행하였습니다.

• 사용자는 하나의 질문을 생성하여 RAG 시스템에 응답을 요청하고 최종 결과를 수신하는데, 3분 동안 반복적으로 수행하여 처리량과 실행 시간 등을 확인합니다.
• 동시에 RAG 시스템에 응답을 요청하는 사용자 수를 한 명에서 점진적으로 증가시키면서 시스템 부하를 증가시킵니다.

성능 평가 결과 및 분석 내용

테스트 시나리오 1 – 인덱스를 위한 메모리 용량이 충분한 경우

테스트 시나리오 1은 본 성능 평가에서 기준(Baseline)이 됩니다. 측정 결과 아래 Figure 5에서 볼 수 있듯이 사용자 수가 증가할수록 처리량 (Query Per Second, QPS)도 증가하다가 일정 수준에서 수렴됩니다. 시스템 내부적으로는 처리 부하가 증가하여 Query Response Time이 증가하는 결과를 보여줍니다.

Figure 5. Query Per Second, Query Response Time 측정 결과

Query Response Time을 아래 Figure 6과 같이 Breakdown 해 보면, 임베딩 < 지식 검색 < LLM 순서로 높은 비중을 차지하는 것을 확인할 수 있습니다. 임베딩의 경우 가장 짧은 시간에 처리되어 비중이 작을 뿐만 아니라, 사용자 수 증가 시에도 처리 시간이 크게 증가하지 않았습니다. LLM의 비중이 가장 높았지만, 사용자 수 증가 시 지식 검색의 상승폭이 38배(0.08초 -> 2.96초)로 LLM의 상승폭 15배(0.96초 -> 14.65초) 대비 높은 특징을 보였습니다.

Figure 6. Query Response Time Breakdown

RAG 시스템에서 LLM이 전체 응답을 생성하는 시간이 중요하지만, 사용자 경험 측면에서는 첫 번째 응답이 나오는 시간 TTFT(Time-To-First-Token)도 중요합니다. RAG Inference에서는 LLM 응답 생성을 위해서 임베딩과 지식 검색 단계가 추가되는데, 이로 인해서 TTFT가 아래 Figure 7과 같이 30~40% 증가하는 것을 확인하였습니다. 현재 업계에서의 RAG TTFT에 대한 요구 사항은 명확하게 정해져 있지 않고, 기업 또는 서비스 제공자가 RAG 시스템을 구축 시 자체 요구사항을 수립하여 운영한다고 합니다. 사용자에 따라서 성능 개선이 요구될 수 있으며, 이 경우 LLM 뿐만 아니라 지식 검색 성능 개선도 함께 검토, 진행되어야 할 것입니다.

Figure 7. RAG 에서의 TTFT와 측정 결과

테스트 시나리오 2 – 데이터 셋 크기 증가

데이터 셋 크기가 증가하면, 인덱스를 위한 메모리 요구량이 증가합니다. 데이터 셋 크기가 검색 성능에 어떤 영향을 미치는지 확인해 보기 위해서 데이터 셋 크기를 2 배 증가시켜 성능 평가를 진행하였습니다. 측정 결과 Figure 8과 같이 처리량(Query Per Second)이 줄고 Latency(Query Response Time)는 상승하였지만, 변동폭은 크지 않았습니다. 임베딩은 사용자의 질의를 대상으로 하는 것이고, LLM의 경우 Input Token에 의해서 응답 생성 시간이 영향을 받습니다. 데이터 셋 크기에는 영향을 받지 않기 때문에 측정 결과에서도 변화가 없음을 확인할 수 있습니다.

Figure 8. 데이터 셋 크기에 따른 성능 변화

지식 검색은 데이터 셋 크기에 영향을 받아서 시간이 약 30~40% 증가하였으며, 이로 인해서 아래 Figure 9와 같이 TTFT가 약 8 ~ 17% 상승하였습니다. 데이터 셋 크기가 커지면 검색 시간이 증가하여 TTFT도 동반 상승함을 확인하였습니다.

Figure 9. 데이터 셋 크기에 따른 TTFT 비교

데이터 셋 증가와 검색 간의 상관 관계 분석

테스트 시나리오 1과 2를 통해 인덱스를 위한 메모리 용량이 충분할 때 데이터 셋 크기에 따른 성능 변화를 확인해 보았습니다. HNSW 알고리즘의 경우, 데이터 셋 크기가 증가하면, 인덱스 내의 그래프를 구성하는 노드 수가 증가되어 크게 아래와 같은 2가지 변화가 발생됩니다.

1. 연산량 증가: 노드 수가 증가하면 유사한 데이터를 찾기 위한 탐색량(거리 계산, 정렬 등)이 증가될 수 있고, 이에 따라 검색 시간이 증가됩니다.
2. 메모리 사용량 증가: 인덱스를 위한 메모리 사용량은 데이터 셋 크기에 따라 증가합니다

Figure 10. 데이터 셋 크기에 따른 Memory 요구량 계산

Figure 11. OpenSearch HNSW Memory 요구량 계산 방법 (출처 OpenSearch Doc.)

• Amazon OpenSearch는 HNSW 알고리즘 사용 시 메모리 요구량을 위의 Figure 11과 같이 설명합니다[8]. 데이터 셋 크기 증가는 벡터 수 증가를 의미하는 것으로 데이터 셋 크기에 따라 메모리 사용량이 증가됩니다.
• 위의 계산식을 사용해서 데이터 셋 크기에 따른 메모리 요구량을 계산해 보면, 768 Dimension에 M값을 16으로 설정 시, 10억개의 Vector를 가지는 데이터 셋은 약7 TiB의 메모리가 필요합니다. 이를 In-memory에서 동작시키기 위해서는 AWS의 r5 인스턴스 기준으로 12 ~ 16개의 노드로 클러스터를 구성해야 합니다[6].

데이터 셋이 커지면 메모리 자원 사용이 늘고, 검색 시간도 증가합니다. 그런데, HNSW 알고리즘은 검색 복잡도가 O(log n)로 데이터 셋 크기가 증가해도 검색 시간이 선형적으로 증가하지 않는다고 설명하고 있습니다 [9].

HNSW 알고리즘 자체의 특성과 함께 Amazon OpenSearch 솔루션이 가지는 또 다른 특성이 있습니다. Amazon OpenSearch는 인덱스를 아래 Figure 12와 같이 Shard > Lucene Index > Segment 단위로 관리하며, Segment 당 하나의 HNSW 그래프를 생성하여 사용합니다. 검색 시 모든 HNSW 그래프를 대상으로 검색 후 결과를 종합하는데, 성능 개선을 위한 병렬 처리와 데이터 관리 목적으로 이러한 구조를 사용합니다. 이러한 구조에서는 HNSW 알고리즘 특성 외에 Segment 개수, 즉 그래프 개수도 검색시간에 영향을 미치게 됩니다.

Figure 12. OpenSearch 인덱스 내부 구조 (출처 AWS Blog)

테스트 시나리오 3 – 인덱스를 위한 메모리 용량이 부족한 경우

앞선 두 개의 테스트 시나리오에서는 인덱스를 위한 메모리 용량이 충분한 경우 데이터 셋 크기 별로 성능을 평가하고 결과를 분석하였습니다. 메모리 용량이 부족한 경우 성능 측정 결과는 아래 Table 2와 같습니다.

Table 2. 메모리 용량이 부족한 상황에서의 단일 쿼리 검색 시간

OpenSearch 시스템에서 인덱스를 위한 메모리 용량이 16GB로 제한될 때, 스토리지에 저장된 30GB 크기의 인덱스에 대해서 검색을 수행 시 122.06초가 걸렸습니다. 30GB 크기의 인덱스가 모두 메모리에 로드된 상태에서 검색 시 0.088초가 걸린 것 대비 약 1300배 검색 시간이 증가하였습니다. 검색 시간이 급 상승한 원인은 스토리지에 저장된 인덱스를 메모리로 읽어오는 동작 때문입니다. 테스트 환경에서 OpenSearch 시스템의 디스크 성능은 최대 250MB/s이므로 이론적으로 30GB의 데이터를 읽는데 122 초가 걸립니다. 실제 측정 결과가 122.06 초인 것은 대부분의 검색 시간이 데이터를 스토리지로부터 읽어오는데 소요된 것을 의미하며, 이는 검색 속도가 스토리지 성능에 의해 좌우됨을 보여줍니다. 그리고 HNSW 알고리즘은 인덱스의 메모리 캐싱 여부와 상관없이 모든 인덱스 데이터를 스토리지로부터 읽어오는 것으로 확인되었습니다. 만약 다수의 사용자가 동시에 검색을 요청하게 되면, 검색 수행 과정에서 인덱스를 반복적으로 읽어서 검색 시간이 급 상승하여 실제로 서비스가 어려울 것으로 예상됩니다.

• 검색을 위한 총 인덱스 Read 시간 = 인덱스 Read 시간 x (동시 요청 사용자 수 x 시스템의 병렬 처리 가능 수)

AWS는 OpenSearch에서 인덱스가 모두 메모리에 로드될 수 있는 시스템을 구성하여 사용할 것으로 권장하고 있는데, 메모리가 부족한 경우 위와 같은 성능 저하 때문인 것으로 보입니다.

성능 평가 결과 분석을 통해 파악된 고려 사항 정리

AWS Cloud 환경에서 RAG 시스템을 구축하여 성능 평가를 진행해 본 결과 다음과 같은 특징과 고려 사항을 확인하였습니다.

1. RAG Inference는 기존 LLM 서비스 대비 지식 데이터 검색을 수행해야 하며, 이에 의해서 TTFT(Time-To-First-Token)가 약 30% 증가됩니다. LLM에 의한 응답 생성 성능과 함께 검색 성능도 중요한 요소입니다.
2. 데이터 셋이 커지게 되면, 벡터 데이터 인덱스를 위한 메모리 사용이 증가할 뿐만 아니라, 검색 시간이 상승하여 TTFT도 동반 상승하게 됩니다.
3. 특히, 벡터 데이터 인덱스를 위한 메모리 용량이 부족한 경우 스토리지로부터 인덱스를 읽어서 검색 시간이 급격히 증가할 수 있습니다.

앞서 언급한 RAG 기술 동향에서 향후 RAG 시스템에서 사용되는 데이터 양 증가 시 검색 속도와 정확도를 보전할 수 있는 확장성이 중요한 과제가 될 수 있을 것이다고 하였습니다. 실험 결과 데이터 셋이 커지고, 사용자 수가 증가할수록 검색 시간이 상승하여 TTFT 를 포함 전체 성능에 영향을 미치는 것을 확인하였습니다. 이와 같은 상황에서 검색 성능을 보전 또는 개선하기 위해서는 Amazon OpenSearch, 즉 벡터 검색 시스템을 Scale-up 또는 Scale-out 하는 방법이 권장되고 있는데, 이는 비용 상승으로 이어집니다. 단순히 시스템 확장으로만 대응하기보다는 성능과 비용을 고려한 최적화 솔루션에 대한 검토가 필요합니다.

결론 및 향후 계획

Generative AI 응용 분야에서 정확한 응답을 생성/제공하기 위해 지식 데이터를 사용하는 RAG 기술이 점점 더 많이 도입되고 있으며, 사용하는 데이터 크기도 지속적으로 증가할 것으로 예상됩니다. 자체 구축한 Cloud RAG 시스템 환경에서 평가를 진행한 결과, LLM 응답 생성 시 지식 데이터를 검색하는 처리 단계가 추가되면서 TTFT가 약 30% 증가함을 확인하였습니다. 데이터 크기가 증가함에 따라 검색 시간이 더욱 증가할 가능성이 높기 때문에, 데이터 크기가 커질 때에도 검색 속도와 정확도를 보전할 수 있는 확장성이 중요한 과제가 될 수 있습니다. 현재 주로 사용 중인 In-memory 기반의 알고리즘의 경우, 데이터가 증가할 때 성능을 보장하려면 시스템을 확장해야 하며, 이는 비용 상승을 초래할 수 있습니다. 이에 따른 대안으로 Disk를 활용하여 메모리 소모량을 줄이면서 정확도를 보전하는 Disk 기반 벡터 검색 기법이 주목받고 있습니다. RAG를 비롯한 여러 벡터 검색 사용 분야에서 도입이 확대될 가능성이 높으며, 24년 11월에 Amazon OpenSearch에도 Disk-based vector search 알고리즘이 추가되어 실 서비스 중입니다[10]. Disk-based vector search 알고리즘은 In-memory 알고리즘 대비, 비용 및 성능 최적화 관점에서 활용 빈도가 상승 될 것으로 전망되어, 관련 기술에 대한 검토가 함께 필요할 것으로 예상됩니다.

마무리

Cloud를 활용하여 연구 진행 결과, Cloud 활용을 통해 업계 니즈를 반영하는 검증된 Reference 아키텍처를 설계하고, scalable하고 flexible하며 다양한 종류의 HW 인프라 자원 활용하여 빠른 플랫폼 빌드가 가능했습니다. 또한 최적화된 플랫폼 SW 기반으로 성능 평가를 진행하고, 기본 모니터링 시스템에서 지원하는 다양한 메트릭을 통해 성능 분석이 가능했다는 점에서 연구 효과를 얻을 수 있었습니다. 더불어 AWS 기술 지원을 통해 익숙하지 않은 Cloud 기능을 원활히 활용하여 연구에 적용할 수 있었습니다.

연구 진행에 있어서 다소 아쉬운 점으로는 Opensearch 등 원하는 서비스 매트릭에 대한 기본 리소스 모니터링 시스템 CloudWatch의 초 단위 고분해능 plot 의 미지원, 가상화 환경에서의 시스템 Memory Bandwidth 관측 불가, AWS Managed 서비스의 인스턴스 stop 기능 부재로 인한 비용 발생 등이 존재하였고, 연구의 고도화를 위해 추후 고려가 필요할 것으로 판단됩니다.

참조사항

[1] “RAG 란 무엇인가?,” [온라인]. Available: https://aws.amazon.com/ko/what-is/retrieval-augmented-generation/.
[2] S. Global, “2024 Global Trends in AI”.
[3] “2024: The State of Generative AI in the Enterprise,” [온라인]. Available: https://menlovc.com/2024-the-state-of-generative-ai-in-the-enterprise/.
[4] [온라인]. Available: https://www.lek.com/insights/hea/eu/ei/tapping-new-potential-realising-value-data-healthcare-sector.
[5] Google, “Natural Questions,” [온라인]. Available: https://ai.google.com/research/NaturalQuestions.
[6] AWS, “OpenSearch ANN 알고리즘 선택,” [온라인]. Available: https://aws.amazon.com/ko/blogs/tech/choose-the-k-nn-algorithm-for-your-billion-scale-use-case-with-opensearch/.
[7] “Locust,” [온라인]. Available: https://github.com/locustio/locust.
[8] OpenSearch, “k-NN Index,” [온라인]. Available: https://opensearch.org/docs/latest/search-plugins/knn/knn-index/.
[9] Y. A. Malkov, “Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs”.
[10] “OpenSearch Release Notes,” [온라인]. Available: https://github.com/opensearch-project/opensearch-build/blob/main/release-notes/opensearch-release-notes-2.17.0.md.