자체 배포된 Milvus 벡터 데이터베이스와 Snowpark Container Services로 RAG 구축하기
장첸, Zilliz의 생태계 및 AI 플랫폼 책임자는 최근 Unstructured Data Meetup의 발표에서 Milvus를 Snowflake와 원활하게 통합하는 방법을 논의했습니다. 구체적으로 그는 Milvus 벡터 데이터베이스로 Retrieval Augmented Generation (RAG) 시스템을 구축하고, Snowpark Container Service(SPCS)를 사용해 이를 Snowflake 생태계와 통합하는 방법을 살펴보았습니다.
이 글에서는 Jiang의 핵심 요점을 요약하고 세 가지 중요한 주제를 다룹니다.
먼저 RAG 시스템 구축에 필수적인 단계인 벡터 검색에 Milvus를 활용하는 방법을 논의합니다. 다음으로 SPCS를 통해 Milvus를 Snowflake에 통합하는 방법을 살펴보겠습니다. 마지막으로 RAG의 미래 지형도 논의하겠습니다. 주제를 깊이 다루기 전에, AI가 information retrieval을 어떻게 변화시켰는지 살펴보겠습니다.
AI가 정보 검색 프로세스를 혁신하는 방법
AI의 발전과 대중화는 정보 검색의 전체 지형을 빠르게 변화시켰습니다. AI가 부상하기 전에는 정보 검색이 통계 모델과 태깅 같은 키워드 매칭 방식에 크게 의존했습니다. 예를 들어 온라인 쇼핑몰 운영자는 각 제품의 태그를 미리 정의된 카테고리에 수동으로 입력해야 했습니다. 제품 카탈로그가 방대하다면 이 과정은 실용적이지 않을 것입니다.
마찬가지로 고객인 우리도 원하는 정확한 제품을 얻기 위해 적절한 태그를 입력해야 했습니다. 문제는 정확하지는 않지만 원하는 제품과 유사한 의미를 가진 태그를 입력하면, 태깅 방식의 정보 검색은 적절한 제품을 제공하지 못한다는 것입니다. 다시 말해, 태깅 방식은 쿼리의 의미론적 의미를 고려하지 않습니다.
AI가 비정형 데이터를 사용하는 방식을 혁신합니다
AI가 비정형 데이터를 사용하는 방식을 혁신합니다
embedding models의 등장은 정보를 검색하는 방식을 완전히 변화시켰습니다. 대부분의 임베딩 모델은 유명한 Transformer 아키텍처를 백본으로 사용합니다. Transformer 모델은 여러 개의 인코더-디코더 블록을 활용하며, 각 블록에는 특화된 어텐션 레이어가 포함되어 있습니다. 이 레이어는 모델이 전체 입력 시퀀스와 관련하여 각 입력 토큰의 의미론적 의미를 감지할 수 있게 해 주어, 임베딩 모델이 입력 단어의 의미론적 의미를 추론할 수 있도록 합니다.
Transformer 아키텍처
Transformer 아키텍처
임베딩 모델은 쿼리, 이미지 또는 텍스트 설명을 vector embeddings라고 하는 수치 표현으로 변환합니다. 벡터 임베딩은 자신이 나타내는 입력의 풍부한 의미론적 의미를 담고 있으며, 우리는 cosine similarity 또는 코사인 거리로 두 벡터 임베딩 간의 유사도를 비교할 수 있습니다. 유사도가 높으면 두 벡터 임베딩은 유사한 의미를 가지며, 그 반대도 마찬가지입니다.
원시 텍스트를 벡터 임베딩으로.png
원시 텍스트를 벡터 임베딩으로
이러한 강력한 특성 덕분에 임베딩 모델은 정보 검색 개념을 구현하는 일을 훨씬 더 쉽고 유연하게 만듭니다.
검색 증강 생성(Retrieval Augmented Generation, RAG)
임베딩 모델의 빠른 발전과 대규모 언어 모델(LLMs)의 부상은 매우 정교한 정보 검색 방법인 RAG의 탄생으로 이어졌습니다. RAG는 쿼리와 함께 내부 지식 베이스의 관련 컨텍스트를 LLM에 제공함으로써 LLM의 응답 품질을 향상하도록 설계되었습니다. 그러면 LLM은 제공된 컨텍스트를 사용하여 쿼리에 답변합니다.
RAG 아키텍처
RAG 아키텍처
RAG 애플리케이션에서는 선택한 임베딩 모델을 사용하여 데이터와 입력 쿼리를 임베딩으로 변환합니다. 그런 다음 쿼리의 임베딩과 자체 데이터의 임베딩 간 유사도를 계산합니다. 쿼리와 가장 유사한 데이터는 쿼리와 함께 컨텍스트로 LLM에 전달됩니다. 궁극적으로 LLM은 제공된 컨텍스트를 기반으로 쿼리에 대한 답변을 생성할 수 있습니다. 이런 방식으로 LLM을 파인튜닝할 필요 없이 응답 정확도를 향상할 수 있습니다.
Milvus 벡터 데이터베이스와 Snowflake를 Snowpark Container Service와 통합하기
Milvus는 RAG 애플리케이션에 유용한 방대한 양의 벡터 임베딩을 저장하고, 이에 대해 순식간에 벡터 검색을 수행할 수 있게 해주는 오픈 소스 벡터 데이터베이스입니다. Milvus를 설치하고 사용하는 방법에는 여러 가지 옵션이 있습니다:
- Milvus Lite: 빠른 프로토타이핑에 적합한 Milvus의 경량 버전입니다. Milvus Lite는 서버가 필요하지 않으며, 사용자의 자체 기기에서 실행할 수 있습니다. 설치 과정은 pip install 명령을 사용하는 것만큼 간단합니다.
!pip install "pymilvus>=2.4.2"
from pymilvus import MilvusClient
client = MilvusClient("milvus_demo.db")
- Docker에서의 Milvus: 프로덕션에서 Milvus 벡터 데이터베이스를 사용하고 싶고 데이터 양이 적은 경우, Docker 컨테이너로 실행할 수 있습니다. 이 과정도 간단하며, 명령줄에서 다음 명령을 실행하기만 하면 됩니다:
# Download the installation script
$ curl -sfL <https://raw.githubusercontent.com/milvus-io/milvus/master/scripts/standalone_embed.sh> -o standalone_embed.sh
# Start the Docker container
$ bash standalone_embed.sh start
# In your Python IDE
from pymilvus import MilvusClient
client = MilvusClient(
uri="<http://milvus:19530>",
)
- Kubernetes에서의 Milvus: 방대한 양의 데이터를 보유하고 있거나 RAG 애플리케이션에 매우 많은 사용자가 있는 경우 이 옵션이 적합합니다. Kubernetes를 사용하면 최대 1,000억 개의 벡터를 저장할 수 있습니다. Kubernetes를 이용한 설치 과정은 Milvus Lite 및 Docker보다 다소 더 복잡합니다. 따라서 자세한 정보는 설치 문서를 참조하세요.
Milvus는 OpenAI, HuggingFace, Cohere, LangChain, LlamaIndex, Snowflake와 같은 인기 AI 툴킷과 원활한 통합을 제공합니다. 이러한 통합을 통해 자체 RAG 시스템이나 기타 GenAI 애플리케이션을 쉽게 구축할 수 있습니다. 이 섹션에서는 Snowflake 생태계 내에서 Milvus를 실행하는 방법을 보여줍니다.
Milvus는 모든 인기 AI 툴킷과 원활한 통합을 제공합니다
Milvus는 모든 인기 AI 툴킷과 원활한 통합을 제공합니다
Snowflake는 데이터를 효율적이고 안정적으로 저장, 처리, 분석할 수 있게 해주는 데이터 웨어하우징 플랫폼입니다. Snowpark Container Service(SPCS)가 도입되면서 이제 Snowflake 환경 내에서 컨테이너화된 애플리케이션을 실행할 수 있습니다. 이렇게 하면 앱이 Snowflake 내부에 저장된 데이터와 상호 작용할 수 있어 RAG 시스템을 포함한 다양한 애플리케이션을 구축할 수 있습니다.
이 섹션에서는 먼저 벡터 검색을 수행하는 Milvus 앱을 구축합니다. 다음으로 Docker를 사용해 애플리케이션을 컨테이너화하고 SPCS로 Snowflake 내에서 컨테이너를 실행합니다.
시작하려면 Jupyter Notebook으로 벡터 검색을 수행하는 Milvus 앱을 구축해 보겠습니다. 함께 따라 해보고 싶다면 전체 노트북과 임베딩 모델을 빌드하는 스크립트는 이 저장소를 참조하세요.
from pymilvus import MilvusClient
from pymilvus import DataType
import os
import mode
# init client
client = MilvusClient(
uri="<http://milvus:19530>",
)
# init model
model = model.Onnx()
# Create a collection in quick setup mode
client.create_collection(
collection_name="quick_demo",
dimension=model.dimension,
)
print("Collection Created!")
위 코드에서는 Milvus 벡터 데이터베이스 안에 “quick_demo”라는 컬렉션을 만들고, 텍스트를 임베딩으로 변환하는 모델을 로드했습니다. 임베딩 모델로 ALBERT를 사용할 것이며, 이는 입력 텍스트를 768차원 벡터 임베딩으로 매핑합니다.
다음으로, “quick_demo” 컬렉션에 일부 텍스트 데이터를 삽입합니다.
# Data from which embeddings are to be generated
docs=[
"Artificial intelligence was founded as an academic discipline in 1956.",
"Alan Turing was the first person to conduct substantial research in AI.",
"Born in Maida Vale, London, Turing was raised in southern England.",
]
# Insert data into the collection
data=[]
for i in range(len(docs)):
data.append({
'id': i,
'vector': model.to_embeddings(docs[i]),
'doc_str': docs[i]
})
res = client.insert(
collection_name="quick_demo",
data=data
)
위 코드에서는 ALBERT로 입력 텍스트를 임베딩으로 변환하고, 해당 ID 및 원문 텍스트와 함께 컬렉션 안에 저장합니다.
이제 “누가 AI 연구를 시작했나요?”와 같은 쿼리가 있고, 해당 쿼리에 대한 관련 답변을 포함할 수 있는 관련 컨텍스트를 얻고자 한다면, 다음과 같이 Milvus로 벡터 검색을 쉽게 수행할 수 있습니다.
# Search with a text query
query = "Who started AI research?"
query_embeddings = model.to_embeddings(query)
res = client.search(
collection_name="quick_demo",
data=[query_embeddings],
limit=1,
output_fields=["doc_str"],
)
print(res)
"""
Expected output:
"Alan Turing was the first person to conduct substantial research in AI."
"""
이것으로 Milvus 앱은 완성입니다.
이 단계에서 우리는 Milvus로 벡터 검색을 수행하는 Jupyter Notebook을 갖게 되었습니다. 이 노트북을 컨테이너화하여 Snowflake 생태계 내에서 실행하고 싶다고 가정해 봅시다. 가장 먼저 해야 할 일은 Snowflake가 제공하는 서비스를 생성하고 실행하기 위한 역할과 권한을 구성하는 것입니다.
먼저, SnowSQL 설치 문서 페이지의 지침에 따라 SnowSQL을 다운로드합니다. 다음으로, 터미널에서 다음 명령을 실행합니다.
snowsql -a ${instance_name} -u ${user_name}
여기서 ${instance_name}의 형식은 ${org_name}-${acct_name}이며, 이 두 필드에 대한 정보는 Snowflake 계정 안에서 찾을 수 있습니다. 이제 SnowSQL 셸 안에서 다음 명령을 사용하여 역할과 권한을 구성할 수 있습니다.
USE ROLE ACCOUNTADMIN;
CREATE SECURITY INTEGRATION SNOWSERVICES_INGRESS_OAUTH
TYPE=oauth
OAUTH_CLIENT=snowservices_ingress
ENABLED=true;
USE ROLE ACCOUNTADMIN;
GRANT BIND SERVICE ENDPOINT ON ACCOUNT TO ROLE SYSADMIN;
USE ROLE SECURITYADMIN;
CREATE ROLE MILVUS_ROLE;
USE ROLE USERADMIN;
CREATE USER milvus_user
PASSWORD='milvususerok'
DEFAULT_ROLE = MILVUS_ROLE
DEFAULT_SECONDARY_ROLES = ('ALL')
MUST_CHANGE_PASSWORD = FALSE;
USE ROLE SECURITYADMIN;
GRANT ROLE MILVUS_ROLE TO USER milvus_user;
Snowflake는 데이터 웨어하우징 플랫폼이므로, 위에서 볼 수 있듯이 SQL 쿼리와 유사한 명령을 통해 Snowflake 내부의 모든 객체와 상호작용합니다. 다음으로, 다음 명령을 사용하여 Snowflake 안에 데이터 웨어하우스와 데이터베이스를 만들 수 있습니다.
USE ROLE SYSADMIN;
CREATE OR REPLACE WAREHOUSE MILVUS_WAREHOUSE WITH
WAREHOUSE_SIZE='X-SMALL'
AUTO_SUSPEND = 180
AUTO_RESUME = true
INITIALLY_SUSPENDED=false;
USE ROLE SYSADMIN;
CREATE DATABASE IF NOT EXISTS MILVUS_DEMO;
USE DATABASE MILVUS_DEMO;
CREATE IMAGE REPOSITORY MILVUS_DEMO.PUBLIC.MILVUS_REPO;
CREATE OR REPLACE STAGE YAML_STAGE;
CREATE OR REPLACE STAGE DATA ENCRYPTION = (TYPE = 'SNOWFLAKE_SSE');
CREATE OR REPLACE STAGE FILES ENCRYPTION = (TYPE = 'SNOWFLAKE_SSE');
--GRANT ROLE PRIVILEGES--
USE ROLE SECURITYADMIN;
GRANT ALL PRIVILEGES ON DATABASE MILVUS_DEMO TO MILVUS_ROLE;
GRANT ALL PRIVILEGES ON SCHEMA MILVUS_DEMO.PUBLIC TO MILVUS_ROLE;
GRANT ALL PRIVILEGES ON WAREHOUSE MILVUS_WAREHOUSE TO MILVUS_ROLE;
GRANT ALL PRIVILEGES ON STAGE MILVUS_DEMO.PUBLIC.FILES TO MILVUS_ROLE;
--CONFIGURE ACL--
USE ROLE ACCOUNTADMIN;
USE DATABASE MILVUS_DEMO;
USE SCHEMA PUBLIC;
CREATE NETWORK RULE allow_all_rule
TYPE = 'HOST_PORT'
MODE= 'EGRESS'
VALUE_LIST = ('0.0.0.0:443','0.0.0.0:80');
CREATE EXTERNAL ACCESS INTEGRATION allow_all_eai
ALLOWED_NETWORK_RULES=(allow_all_rule)
ENABLED=TRUE;
GRANT USAGE ON INTEGRATION allow_all_eai TO ROLE SYSADMIN;
Snowflake 안에서 컨테이너화된 앱을 실행하려면, 로컬 머신에서 앱의 Docker 이미지를 빌드해야 합니다. 이 프로젝트에서는 두 가지 서로 다른 Docker 이미지를 빌드해야 합니다. 하나는 Milvus 벡터 데이터베이스를 인스턴스화하기 위한 것이고, 다른 하나는 위에서 만든 노트북 파일을 실행하기 위한 것입니다.
하지만 Docker 이미지를 빌드하려면 Dockerfile이 필요합니다. 작업을 더 쉽게 하려면 다음 저장소를 클론하세요. 이 저장소에서 필요한 두 이미지를 빌드하는 데 필요한 모든 파일을 찾을 수 있습니다. 저장소를 클론한 후, 로컬 터미널에서 다음 명령을 사용하여 두 Docker 이미지를 빌드할 수 있습니다.
cd ${repo_git_root_path}
docker build --rm --no-cache --platform linux/amd64 -t milvus ./images/milvus
docker build --rm --no-cache --platform linux/amd64 -t jupyter ./images/jupyter
그런 다음, 다음 명령을 사용하여 새로 빌드한 두 이미지에 적절한 태그를 추가할 수 있습니다.
docker login ${instance_name}.registry.snowflakecomputing.com -u ${user_name}
docker tag milvus ${instance_name}.registry.snowflakecomputing.com/milvus_demo/public/milvus_repo/milvus
docker tag jupyter ${instance_name}.registry.snowflakecomputing.com/milvus_demo/public/milvus_repo/jupyter
마지막으로, 다음 명령을 사용하여 이미지를 SPCS로 푸시할 수 있습니다.
docker push ${instance_name}.registry.snowflakecomputing.com/milvus_demo/public/milvus_repo/milvus
docker push ${instance_name}.registry.snowflakecomputing.com/milvus_demo/public/milvus_repo/jupyter
이제 이미지를 SPCS에 푸시했으므로, 우리가 해야 할 일은 각 이미지에 대해 하나씩, 총 두 개의 컴퓨팅 서비스를 생성하는 것뿐입니다. SnowSQL 셸 안에서 다음 명령을 보면 확인할 수 있습니다:
USE ROLE SYSADMIN;
CREATE COMPUTE POOL IF NOT EXISTS MILVUS_COMPUTE_POOL
MIN_NODES = 1
MAX_NODES = 1
INSTANCE_FAMILY = CPU_X64_S
AUTO_RESUME = true;
CREATE COMPUTE POOL IF NOT EXISTS JUPYTER_COMPUTE_POOL
MIN_NODES = 1
MAX_NODES = 1
INSTANCE_FAMILY = CPU_X64_S
AUTO_RESUME = true;
이전에 클론한 repo 안에는 “specs”라는 폴더가 있습니다. 그 폴더 안에는 각 이미지에 하나씩, 두 개의 YAML 파일이 있습니다. 각 YAML 파일을 열고, image 필드의 ${org_name}-${acct_name}을 자신의 Snowflake 계정에 맞게 변경하세요.
다음으로, SnowSQL을 사용하여 다음 명령으로 수정된 YAML 파일을 업로드합니다:
PUT file://${path/to/jupyter.yaml} @yaml_stage overwrite=true auto_compress=false;
PUT file://${path/to/milvus.yaml} @yaml_stage overwrite=true auto_compress=false;
마지막으로, 다음과 같이 두 이미지 모두에 대한 서비스를 생성할 수 있습니다:
USE ROLE SYSADMIN;
USE DATABASE MILVUS_DEMO;
USE SCHEMA PUBLIC;
CREATE SERVICE MILVUS
IN COMPUTE POOL MILVUS_COMPUTE_POOL
FROM @YAML_STAGE
SPEC='milvus.yaml'
MIN_INSTANCES=1
MAX_INSTANCES=1;
CREATE SERVICE JUPYTER
IN COMPUTE POOL JUPYTER_COMPUTE_POOL
FROM @YAML_STAGE
SPEC='jupyter.yaml'
MIN_INSTANCES=1
MAX_INSTANCES=1;
이제 SHOW SERVICE 명령을 입력하면 다음과 같은 출력이 표시됩니다:
SHOW SERVICES;
+---------+---------------+-------------+----------+----------------------+--------------------------------------------------------+-----------------
| name | database_name | schema_name | owner | compute_pool | dns_name | ......
|---------+---------------+-------------+----------+----------------------+--------------------------------------------------------+-----------------
| JUPYTER | MILVUS_DEMO | PUBLIC | SYSADMIN | JUPYTER_COMPUTE_POOL | jupyter.public.milvus-demo.snowflakecomputing.internal | ......
| MILVUS | MILVUS_DEMO | PUBLIC | SYSADMIN | MILVUS_COMPUTE_POOL | milvus.public.milvus-demo.snowflakecomputing.internal | ......
+---------+---------------+-------------+----------+----------------------+--------------------------------------------------------+-----------------
이제 Snowflake 내부에서 Milvus 벡터 데이터베이스를 실행하고 노트북을 테스트할 준비가 되었습니다. 먼저, 이전에 생성한 role에 컨테이너화된 앱에 접근할 수 있는 권한을 부여합니다.
USE ROLE SECURITYADMIN;
GRANT USAGE ON SERVICE MILVUS_DEMO.PUBLIC.JUPYTER TO ROLE MILVUS_ROLE;
다음으로, 다음 명령을 사용하여 Snowflake 내부의 노트북 컨테이너 엔드포인트를 확인합니다:
USE ROLE SYSADMIN;
SHOW ENDPOINTS IN SERVICE MILVUS_DEMO.PUBLIC.JUPYTER;
ingress_url에 표시된 Jupyter 엔드포인트
ingress_url에 표시된 Jupyter 엔드포인트
모든 것이 원활하게 실행되면 출력으로 “ingress_url”이라는 열을 볼 수 있습니다. 브라우저를 열고 해당 “ingress_url”을 복사해 붙여넣으면 Jupyter가 시작되는 것을 확인할 수 있습니다. 그런 다음 컨테이너 안의 노트북 파일을 열고 노트북의 각 셀을 평소처럼 실행할 수 있습니다.
RAG의 미래 전망
RAG는 요즘 매우 인기 있는 기법입니다. 하지만 현재의 적용 방식은 완벽과는 거리가 멉니다. Jiang Chen에 따르면, RAG 애플리케이션의 향후 사용과 개선에 관한 몇 가지 예측은 다음과 같습니다.
지속적인 평가와 관측 가능성
RAG 개발 프로세스를 단순화하고 추상화하는 다양한 플랫폼이나 라이브러리를 사용할 수 있게 되면서 RAG 구축은 더 쉬워졌습니다. 예를 들어, Milvus, LangChain, OpenAI라는 세 가지 서로 다른 플랫폼의 도움으로 몇 분 안에 RAG 프로토타입을 만들 수 있습니다.
하지만 RAG 기반 애플리케이션을 프로토타입에서 프로덕션으로 옮길 때 우리는 종종 어려움에 직면합니다. 프로덕션에서 우리의 RAG 시스템은 수백만 또는 심지어 수십억 개의 문서를 처리해야 하므로, LLM이 생성하는 응답 품질을 지속적으로 모니터링하는 것이 매우 중요합니다
RAG 시스템의 지속적 평가
RAG 시스템의 지속적 평가
RAG의 품질을 향상하기 위한 개선 사항을 구현하기 전에, 이를 지속적으로 평가하고 개선하기 위한 체계적인 접근 방식을 확립하는 것이 중요합니다.
이 체계적인 접근 방식의 몇 가지 핵심 요소는 다음과 같습니다:
전용 개선 인프라 구축: 이 인프라에서 RAG의 품질을 개선하기 위한 다양한 방법을 구현한 다음, A/B 테스트를 통해 해당 응답들을 비교할 수 있습니다.
릴리스 주기 계획: 사용 사례에 따라 RAG의 품질을 개선하는 접근 방식을 찾으면, 사용자 경험을 방해하지 않고 기존 시스템을 대체할 수 있도록 이를 시스템에 릴리스하고 통합하는 방법을 계획해야 합니다.
관찰 가능성 시스템 구현: 또한 프로덕션에서 RAG의 성능을 관찰하고 그 효과를 판단하기 위한 시스템을 구축해야 합니다. 성능이 만족스럽지 않다면, 전용 개선 인프라를 통해 개선 사항을 탐색하고 구현할 수 있습니다.
멀티모달 RAG
지금까지 우리는 주로 자연어 처리에서 RAG를 활용해 왔습니다. 이는 텍스트를 프롬프트 또는 쿼리로 사용하고, LLM의 응답 또한 텍스트 형태라는 의미입니다.
하지만 멀티모달 RAG의 등장으로 향후 RAG 환경은 변화할 수 있습니다. 멀티모달 RAG는 최근 몇 년 동안 멀티모달 임베딩 모델이 부상하면서 가능해졌습니다. 지난 몇 년간의 연구는 Transformers가 자연어를 입력으로 처리할 수 있을 뿐 아니라 이미지와 소리 같은 다른 모달리티도 처리할 수 있다고 결론지었습니다.
Vision Transformers (ViT)와 DETR 모델은 Transformers가 강력한 이미지 분류 및 객체 감지 모델로 사용될 수 있음을 입증했습니다. ViT를 기반으로 OpenAI는 CLIP이라는 멀티모달 모델을 소개했으며, 이 모델은 서로 다른 모달리티인 텍스트와 이미지의 두 입력 간 유사도를 계산할 수 있습니다.
이러한 Transformer 기반 모델들이 보여준 멀티모달 기능은 미래의 멀티모달 RAG 애플리케이션을 위한 기반이 될 수 있습니다. 이 시스템에서는 텍스트와 이미지를 조합하여 쿼리로 사용할 수 있으며, LLM은 우리의 멀티모달 쿼리를 기반으로 이미지를 생성할 것입니다.
예를 들어, 제공된 쿼리 이미지와 매우 유사한 이미지를 LLM이 생성하길 원한다고 해봅시다. 아래 시각화에서 볼 수 있듯이, LLM이 생성하길 원하는 이미지의 종류를 더욱 세밀하게 조정하기 위해 쿼리 이미지에 텍스트 설명을 추가할 수 있습니다:
텍스트와 이미지 쿼리의 조합인 멀티모달 RAG 애플리케이션
텍스트와 이미지 쿼리의 조합인 멀티모달 RAG 애플리케이션
위 시각화에서 우리는 임베딩 모델에게 왼쪽 상단의 이미지와 유사한 이미지를 반환하도록 요청했으며, 왼쪽 상단 이미지와 함께 "골든 아워의 산 사진,"과 같은 텍스트 프롬프트를 추가했습니다. 결과는 멀티모달 쿼리를 기반으로 생성된 다른 세 개의 이미지입니다.
RAG에 대한 이러한 멀티모달 접근 방식은 텍스트와 시각적 모달리티의 강점을 결합하여, 더 직관적이고 표현력 있는 정보 검색 및 생성의 새로운 가능성을 열어줍니다.
좋은 RAG는 좋은 데이터에서 나옵니다
RAG 시스템의 품질은 데이터베이스에 보유한 데이터 품질에 크게 의존합니다. 따라서 RAG가 생성한 응답이 최적이 아닐 때, 모델을 개선해야 한다는 결론으로 성급히 넘어가서는 안 됩니다. 먼저 항상 데이터의 품질을 확인해야 합니다.
이미 알고 계실 수도 있듯이, RAG의 응답 품질은 쿼리와 함께 전달되는 컨텍스트에 따라 달라집니다. LLM이 제공된 컨텍스트에서 쿼리에 대한 적절한 답변을 찾을 수 없다면, RAG 시스템이 생성하는 응답 품질이 낮아지는 것은 놀라운 일이 아닙니다.
따라서 RAG 시스템의 임베딩 모델과 LLM을 개선하기로 선택하기 전에, 우리는 항상 다음 질문들을 해야 합니다:
데이터베이스에 올바른 데이터가 있는가?
데이터 소스에서 사용 가능한 모든 데이터를 데이터베이스로 수집했는가?
데이터를 임베딩 모델에 전달하기 전에 올바른 데이터 정제 프로세스를 구현했는가?
데이터에 적절한 청킹 접근 방식을 구현했는가?
데이터에 올바른 데이터 전처리 방법(예: PDF 파싱, OCR 파싱)을 구현했는가?
데이터 관련 문제를 해결하는 것은 RAG 기반 애플리케이션의 성능을 최적화하는 데 있어 중요한 첫 단계입니다. 데이터 품질을 검증한 후에야 임베딩 모델, LLM 또는 RAG 시스템의 다른 구성 요소를 개선하는 것을 고려해야 합니다.
에이전트: 하위 쿼리를 통한 쿼리 라우팅
현재 일반적인 RAG 시스템은 내부 데이터베이스에 저장된 텍스트와 임베딩에서 주어진 쿼리에 대한 관련 컨텍스트를 검색합니다. 그러나 컨텍스트가 내부 데이터베이스와 웹 검색과 같은 외부 소스에서 검색될 수 있으므로, 이 접근 방식은 발전할 수 있습니다.
쿼리 라우팅을 위한 에이전트 시각화
쿼리 라우팅을 위한 에이전트 시각화
이 분야의 연구는 아직 진행 중이지만, RAG 시스템 내에 이른바 "에이전트"를 추가하면 주어진 쿼리에 적절한 컨텍스트 소스를 결정하는 데 도움이 될 수 있습니다.
예를 들어, "AI 연구는 누가 시작했는가?"와 같은 쿼리가 주어졌을 때 에이전트는 해당 질문에 답하기 위해 RAG가 필요한지 여부를 결정할 수 있습니다. 필요하지 않다면, 시스템은 추가 컨텍스트 없이 LLM이 쿼리에 대한 응답을 직접 생성하도록 할 수 있습니다.
RAG가 필요하다고 판단되면, 에이전트는 컨텍스트의 소스가 내부 데이터베이스인지 외부 소스인지 결정해야 합니다. 또 다른 접근 방식은 에이전트가 다양한 소스의 정보를 LLM이 적절한 답변을 생성하는 데 사용할 수 있는 하나의 요약된 컨텍스트로 집계하는 것입니다.
결론
LLM이 인간과 유사한 텍스트 응답을 생성하는 강력한 성능은 정보 검색의 전체 지형을 변화시켰습니다. RAG의 도입은 주어진 쿼리에 관련 컨텍스트를 제공함으로써 LLM의 응답 정확도를 향상시키기 위해 설계되었습니다. 이러한 컨텍스트는 일반적으로 임베딩으로 저장되며, Milvus와 같은 벡터 데이터베이스에 저장되어야 합니다.
고급 벡터 검색 기능을 갖춘 오픈 소스 벡터 데이터베이스인 Milvus는 Snowflake와 같은 인기 있는 AI 툴킷과의 원활한 통합을 제공합니다. Snowflake의 Snowpark Container Service (SPCS)를 통해 사용자는 이제 Snowflake 생태계 내에서 Milvus를 실행할 수 있으며, Snowflake에 저장된 데이터를 사용하여 Milvus와 쉽게 상호 작용할 수 있습니다.
계속 읽기
Why I’m Against Claude Code’s Grep-Only Retrieval? It Just Burns Too Many Tokens
Learn how vector-based code retrieval cuts Claude Code token consumption by 40%. Open-source solution with easy MCP integration. Try claude-context today.
Our Journey to 35K+ GitHub Stars: The Real Story of Building Milvus from Scratch
Join us in celebrating Milvus, the vector database that hit 35.5K stars on GitHub. Discover our story and how we’re making AI solutions easier for developers.
Vector Databases vs. Hierarchical Databases
Use a vector database for AI-powered similarity search; use a hierarchical database for organizing data in parent-child relationships with efficient top-down access patterns.