Claude 3.5 Sonnet, LlamaIndex 및 Milvus를 사용한 에이전트형 RAG 구현하기
AI 시스템이 빠르게 계속 발전함에 따라, 대규모 언어 모델 (LLMs)에만 의존하는 것은 더 이상 오늘날 산업의 다양한 요구를 충족하기에 충분하지 않습니다. 이러한 증가하는 과제는 문제를 더 효율적이고 효과적으로 해결할 수 있는 더 복잡한 아키텍처의 개발을 요구합니다.
Zilliz가 주최한 Unstructured Data Meetup에서 Zilliz의 엔지니어링 디렉터인 Bill Zhang은 Berkeley AI Research (BAIR) blog에 소개된 Compound AI Systems 개념을 소개했습니다. 이 모듈식 접근 방식은 단일 AI 모델에 의존하기보다 여러 구성 요소를 통합하여 다양한 작업을 처리함으로써, 더 맞춤화되고 효율적인 결과를 제공합니다. Bill의 발표는 Zilliz YouTube 채널에서 시청할 수 있습니다.
이 블로그에서는 LLM 앱 아키텍처의 진화, Retrieval Augmented Generation(RAG) 및 Agentic RAG의 개념, 그리고 이들의 과제와 이점을 포함한 Bill의 핵심 내용을 요약합니다. 또한 Claude 3.4 Sonnet, LlamaIndex, Milvus 벡터 데이터베이스를 사용하여 Agentic RAG를 구축하는 과정도 안내합니다.
LLM 애플리케이션의 아키텍처 발전
LLM은 10년 넘게 AI 환경의 일부였지만, 지난 3년 동안 공개적으로 사용 가능한 파운데이션 모델, 특히 OpenAI의 ChatGPT의 등장은 LLM 애플리케이션 개발을 크게 가속화하여 빠른 확장을 이끌었습니다. Unstructured Data Meetup에서 Bill은 현재 AI 아키텍처의 주요 구성 요소와 그 발전을 요약했습니다.
그림 1- LLM 시스템 진화 .png
그림 1: LLM 시스템 진화
LLM의 사전 학습된 지식에만 의존하기
LLM을 사용하는 가장 간단한 방법은 쿼리에 답하기 위해 LLM “자체” 지식에 의존하는 것입니다. 그러나 이 방법에는 한계가 있습니다. LLM은 모든 주제나 사용 사례를 포괄할 수 없으며, 이는 부정확하거나 “환각”된 답변으로 이어질 수 있습니다. 이 문제를 해결하는 한 가지 방법은 각각 서로 다른 유형의 질문에 맞춘 여러 LLM을 사용하는 것이지만, 이 방법은 시스템을 지나치게 복잡하고 확장하기 어렵게 만들 수 있습니다.
Compound AI 시스템: LLM 파이프라인에 추가 구성 요소 더하기
그렇다면 이 문제를 어떻게 해결할 수 있을까요? 해답은 Compound AI systems에 있습니다. LLM 파이프라인에 추가 구성 요소를 더하면 시스템 성능을 향상할 수 있습니다. 일반적인 예는 Retrieval Augmented Generation (RAG)입니다. RAG는 일반적으로 Milvus 또는 Zilliz Cloud(관리형 Milvus)와 같은 벡터 데이터베이스에 저장되는 "지식 베이스" 또는 "컨텍스트"를 도입하며, 여기에는 유사도 검색을 위한 특정 정보가 저장됩니다. 지식을 RAG 시스템에 주입함으로써 사용 사례에 맞춤화된 정보에 접근할 수 있습니다. RAG는 사용자 쿼리와 벡터 데이터베이스에서 검색된 컨텍스트로 구성된 맞춤형 프롬프트와 결합된 LLM의 능력을 활용하여 더 정확하고 관련성 높은 응답을 생성합니다.
에이전트
그렇다면 더 많은 모듈을 구현해야 할까요? 이는 특정 사용 사례에 따라 달라집니다. 그러나 LLM과 마찬가지로 RAG도 특정 모델에 의존하기 때문에 한계가 있습니다. 예를 들어, 쿼리에 비교 작업 수행이 포함되어 있는데 모델은 요약용으로 학습되었다면 어떻게 될까요? 다양한 유형의 질문을 어떻게 효과적으로 관리할 수 있을까요? 바로 여기서 추가 모듈인 Agents가 실제로 활용됩니다. AI agents는 추론, 사용되는 도구, 계획과 같은 “인간과 유사한” 단계를 파이프라인에 추가하는 복잡한 시스템입니다. agents의 이점을 이해하기 위해 먼저 RAG의 기본 사항을 살펴보겠습니다.
검색 증강 생성(RAG)
위에서 언급했듯이, RAG 시스템은 지식 기반으로 벡터 데이터베이스를 통합하여 LLM 출력을 향상시킵니다. RAG 시스템을 구축하는 기본 단계는 다음과 같이 요약할 수 있습니다:
청킹: Zilliz Cloud 및 Milvus와 같은 벡터 데이터베이스의 핵심 특성인 시맨틱 검색을 사용하여 벡터 데이터베이스에서 검색된 콘텐츠의 관련성을 높이기 위해 문서를 더 작은 조각으로 분할합니다.
임베딩: 벡터 데이터베이스에 수집될 청크를 벡터화(숫자 표현 생성)합니다.
프롬프트: 답변을 얻기 위해 쿼리를 기반으로 벡터 데이터베이스에서 검색하도록 LLM에 주어진 지침
쿼리: LLM에 주어진 질문
이러한 단계는 주로 유사성을 기반으로 합니다. 모델은 데이터베이스에서 가장 유사한 청크를 검색하고, 이를 바탕으로 가장 정확한 응답을 생성합니다.
Figure 2- Basic steps of RAG .png
그림 2: RAG의 기본 단계
그러나 시맨틱 유사도 검색은 마법 같은 해결책이 아닙니다. 가장 유사한 청크가 충분히 정확하지 않다면 결과 답변도 부족할 수밖에 없습니다. Bill은 특히 요약, 비교, 다중 파트 질문을 포함하여 LLM이 최적으로 수행하지 못할 수 있는 사용 사례에서 RAG 시스템의 몇 가지 약점을 탐구했습니다.
하지만 RAG의 문제, 즉 추론 능력의 부족과 필요한 문서를 정확하게 검색하지 못하는 문제는 Agents의 도입으로 효과적으로 해결될 수 있습니다. 이러한 엔터티는 전체 프로세스에서 중요한 역할을 하며, RAG가 제기하는 과제에 대한 잠재적 해결책을 제공합니다.
Agentic RAG
이제 LLM과 RAG의 한계를 이해했으므로, agents의 이점을 더 깊이 탐구할 수 있습니다. 아래 다이어그램에서 LLM agents는 반복적인 프로세스에서 서로 상호작용하는 여러 구성 요소를 포함합니다. 이제 이는 단순히 유사성에 관한 것이 아니라 계획, 추론, 도구 사용, 기억에 관한 것이기도 합니다.
Figure 3- LLM Agents .png
그림 3: LLM Agents
여러 agentic 아키텍처와 프레임워크가 있지만, 가장 인기 있는 것 중 하나는 ReAct(Reasoning/Acting)입니다. ReAct는 계획/추론, 행동(도구 사용), 관찰/평가, 답변 생성의 여러 단계를 포함합니다. Bill은 이러한 단계를 반복적인 프로세스의 일부로 강조했습니다.
관찰/평가 단계에서 모델이 답변을 찾지 못하면, 추론 단계로 돌아가거나 사용자에게 추가 프롬프트를 요청하는 방식으로 대안을 계속 검색합니다.
Figure 4- ReAct Framework.png
그림 4: ReAct Framework (출처)
그렇다면 이러한 에이전트를 RAG 파이프라인에서 어떻게 사용할 수 있을까요? 좋은 점은 라우팅/플래닝을 다운스트림 RAG 파이프라인으로 보내는 것이든 도구 호출이든, 파이프라인의 모든 단계 내에서 구현할 수 있다는 것입니다. 지식 베이스조차도 도구 또는 ReAct 프레임워크로 간주될 수 있습니다.
Figure 5- How An Agentic RAG works .png
그림 5: Agentic RAG의 작동 방식
강연 중 Bill은 RAG 파이프라인 내에서 가능한 다섯 가지 에이전트형 구현 방식을 설명했습니다:
라우팅: 사용자 쿼리가 해당 쿼리와 관련된 특정 지식 베이스로 리디렉션됩니다.
- 예: 사용자가 특정 유형의 책에 대한 추천을 요청하면, 쿼리는 해당 유형의 책에 대한 정보를 포함하는 지식 베이스로 라우팅될 수 있습니다.
쿼리 플래닝: 쿼리가 하위 쿼리로 분할되며, 각 하위 쿼리는 관련 RAG 파이프라인으로 전달됩니다.
- 예: 지난 3년간 한 회사의 재무 실적을 알고 싶다면, 에이전트는 각 연도에 대한 하위 쿼리를 생성하고 각각을 적절한 지식 베이스로 전달합니다.
도구 사용: LLM이 외부 API 또는 도구와 상호작용하며, 그 상호작용에 필요한 매개변수를 결정합니다.
- 예: 사용자가 일기 예보를 요청하면, LLM은 날씨 API를 호출하고 위치 및 날짜와 같은 매개변수를 결정한 뒤 API의 응답을 처리하여 답변을 제공합니다.
ReAct: 추론과 행동을 포함하는 반복 프로세스로, 계획, 도구 사용, 관찰 단계를 포함합니다.
- 예: 상세한 여행 일정을 생성하기 위해 시스템은 사용자의 요구를 추론하고, API를 사용해 명소, 식사, 숙박에 대한 정보를 수집하며, 결과의 정확성과 관련성을 관찰한 다음 포괄적인 여행 계획을 제공합니다.
동적 쿼리 플래닝: 에이전트가 여러 작업 또는 하위 쿼리를 순차적으로가 아니라 병렬로 실행하고 결과를 집계합니다
예: 두 회사의 재무 실적을 비교하고 특정 지표의 차이를 계산하려는 경우, 에이전트는 두 회사의 데이터를 병렬로 처리한 다음 결과를 결합하여 비교를 제공합니다. LLMCompiler는 병렬 함수 호출의 효율적이고 효과적인 오케스트레이션을 가능하게 하는 예시 프레임워크입니다.
Figure 6- LLM Compiler.png
그림 6: LLM Compiler (출처)
따라서 에이전트는 RAG 파이프라인에 추가 계층을 더해 전체 프로세스의 효율성을 향상시키고 개선합니다. 그러나 LLM과 RAG가 독립형 시스템으로서 그렇듯이, 에이전트 역시 내부 단계를 제어하고 특정 사용 사례에 최상의 결과를 얻도록 맞춤화하는 등의 과제를 제시합니다.
이제 Milvus 벡터 데이터베이스를 사용한 간단한 에이전트형 파이프라인을 보여드리겠습니다.
Claude 3.5 Sonnet, LlamaIndex, Milvus를 사용한 Agentic RAG
다음 노트북은 에이전트형 프레임워크로 LlamaIndex, 벡터 데이터베이스로 Milvus , LLM으로 Claude 3.5 Sonnet을 사용해 구축한 Agentic RAG 파이프라인의 예입니다. 이 섹션에서는 이 에이전트형 RAG를 구축하는 방법을 단계별로 안내하겠습니다.
전체 코드는 이 노트북에서도 확인할 수 있습니다.
1단계: 데이터 로딩
간단한 RAG 파이프라인에 적합한 데이터 소스인 Milvus Documentation 2.4.x의 FAQ 페이지를 RAG의 비공개 지식으로 사용합니다.
!pip install -qq llama-index pymilvus llama-index-vector-stores-milvus llama-index-llms-anthropic
!wget https://github.com/milvus-io/milvus-docs/releases/download/v2.4.6-preview/milvus_docs_2.4.x_en.zip
!unzip -q /content/milvus_docs_2.4.x_en.zip -d /content/milvus_docs
from llama_index.core import SimpleDirectoryReader
# load documents
documents = SimpleDirectoryReader(
input_files=["/content/milvus_docs/en/faq/operational_faq.md"]
).load_data()
print("Document ID:", documents[0].doc_id)
2단계: 환경 변수
두 개의 API 키, Anthropic과 OpenAI를 가져와야 합니다.
import os
from google.colab import userdata
os.environ["ANTHROPIC_API_KEY"] = userdata.get('ANTHROPIC_API_KEY')
os.environ["OPENAI_API_KEY"] = userdata.get('OPENAI_API_KEY')
3단계: 데이터 인덱싱
Milvus 벡터 데이터베이스를 사용하여 문서의 인덱스가 생성됩니다. 이것이 우리의 지식 베이스가 됩니다. OpenAI는 LlamaIndex의 기본 임베딩 모델이므로(변경 가능), MilvusVectorStore에서 동일한 차원(dim = 1536)을 정의해야 합니다. 또한 다음 코드를 실행한 후 로컬 데이터베이스가 생성되며, 여기에는 우리의 지식 베이스가 포함됩니다.
from llama_index.core import VectorStoreIndex, StorageContext
from llama_index.vector_stores.milvus import MilvusVectorStore
vector_store = MilvusVectorStore(dim=1536)
storage_context = StorageContext.from_defaults(vector_store=vector_store)
index = VectorStoreIndex.from_documents(documents, storage_context=storage_context)
4단계: 간단한 쿼리 엔진
먼저 에이전트 없이 쿼리 엔진을 테스트해 보겠습니다. 이는 Claude 3.5 Sonnet으로 구동되며 인덱스 내에서 관련 콘텐츠를 검색합니다.
llm = Anthropic(model="claude-3-5-sonnet-20240620")
query_engine = index.as_query_engine(similarity_top_k=5, llm=llm)
res = query_engine.query("What is the maximum vector dimension supported in Milvus?")
print(res)
"""
Output:
Milvus supports vectors with up to 32,768 dimensions by default. However, if you need to work with vectors of even higher dimensionality, you have the option to increase the value of the 'Proxy.maxDimension' parameter. This allows Milvus to accommodate vectors with dimensions exceeding the default limit.
"""
5단계: 에이전트형 쿼리 엔진
이제 QueryEngineTool을 추가합니다. 이는 쿼리 엔진을 위한 래퍼 도구로 작동하며, 에이전트가 사용하게 됩니다.
from llama_index.core import VectorStoreIndex
from llama_index.core.tools import QueryEngineTool, ToolMetadata
from llama_index.llms.anthropic import Anthropic
llm = Anthropic(model="claude-3-5-sonnet-20240620")
query_engine = index.as_query_engine(similarity_top_k=5, llm=llm)
query_engine_tool = QueryEngineTool(
query_engine=query_engine,
metadata=ToolMetadata(
name="knowledge_base",
description=(
"Provides information about Milvus FAQ."
"Use a detailed plain text question as input to the tool."
),
),
)
6단계: AI 에이전트 생성
이 경우 사용되는 에이전트는 LlamaIndex의 FunctionCallingAgentWorker로, 쿼리 엔진 도구를 사용하여 쿼리 응답에 대해 critic reflection을 적용해 개선된 답변을 생성합니다.
from llama_index.core.agent import FunctionCallingAgentWorker
agent_worker = FunctionCallingAgentWorker.from_tools(
[query_engine_tool], llm=llm, verbose=True
)
agent = agent_worker.as_agent()
response = agent.chat("What is the maximum vector dimension supported in Milvus?")
print(str(response))
"""
Output:
Added user message to memory: What is the maximum vector dimension supported in Milvus?
=== LLM Response ===
To answer your question about the maximum vector dimension supported in Milvus, I'll need to consult the Milvus FAQ knowledge base. Let me do that for you.
=== Calling Function ===
Calling function: knowledge_base with args: {"input": "What is the maximum vector dimension supported in Milvus?"}
=== 함수 출력 ===
Milvus는 기본적으로 최대 32,768차원의 벡터를 지원합니다. 그러나 더 높은 차원의 벡터로 작업해야 하는 경우 'Proxy.maxDimension' 매개변수의 값을 늘릴 수 있는 옵션이 있습니다. 이를 통해 Milvus는 기본 제한을 초과하는 차원의 벡터를 수용할 수 있습니다.
=== LLM 응답 ===
Milvus FAQ 지식 베이스의 정보를 바탕으로, 다음과 같은 답변을 제공할 수 있습니다:
Milvus에서 지원되는 최대 벡터 차원은 기본적으로 32,768입니다. 이는 Milvus가 기본 설정 상태에서 최대 32,768차원의 벡터를 처리할 수 있다는 의미이며, 대부분의 애플리케이션에 적합합니다.
그러나 Milvus는 더 높은 차원의 벡터로 작업해야 할 수 있는 경우를 위해 유연성을 제공한다는 점에 유의해야 합니다. 사용 사례에서 32,768을 초과하는 차원의 벡터가 필요한 경우, 이 제한을 늘릴 수 있는 옵션이 있습니다. 이는 Milvus 구성에서 'Proxy.maxDimension' 매개변수를 조정하여 수행할 수 있습니다.
요약하면:
1. 기본 최대 차원: 32,768
2. 증가 가능 여부: 예, 'Proxy.maxDimension' 매개변수를 수정하여 가능
이러한 유연성 덕분에 Milvus는 일반적인 머신 러닝 및 AI 애플리케이션부터 매우 높은 차원의 벡터가 필요할 수 있는 보다 특수한 시나리오까지 광범위한 사용 사례를 수용할 수 있습니다.
Milvus FAQ 지식 베이스의 정보를 바탕으로, 다음과 같은 답변을 제공할 수 있습니다:
Milvus에서 지원되는 최대 벡터 차원은 기본적으로 32,768입니다. 이는 Milvus가 기본 설정 상태에서 최대 32,768차원의 벡터를 처리할 수 있다는 의미이며, 대부분의 애플리케이션에 적합합니다.
그러나 Milvus는 더 높은 차원의 벡터로 작업해야 할 수 있는 경우를 위해 유연성을 제공한다는 점에 유의해야 합니다. 사용 사례에서 32,768을 초과하는 차원의 벡터가 필요한 경우, 이 제한을 늘릴 수 있는 옵션이 있습니다. 이는 Milvus 구성에서 'Proxy.maxDimension' 매개변수를 조정하여 수행할 수 있습니다.
요약하면:
1. 기본 최대 차원: 32,768
2. 증가 가능 여부: 예, 'Proxy.maxDimension' 매개변수를 수정하여 가능
이러한 유연성 덕분에 Milvus는 일반적인 머신 러닝 및 AI 애플리케이션부터 매우 높은 차원의 벡터가 필요할 수 있는 보다 특수한 시나리오까지 광범위한 사용 사례를 수용할 수 있습니다.
"""
에이전트의 출력은 정보의 출처, 답변의 근거, 그리고 주제와 관련된 몇 가지 추가 제안을 포함하여 더 자세한 답변을 제공합니다. 이는 LLM 모델이 제공한 답변을 더 잘 이해하는 데 도움이 됩니다.
Agentic RAG 아키텍처
방금 구축한 agentic RAG의 전체 아키텍처는 아래와 같습니다.
Milvus, LlamaIndex, Cluade 3.5 Sonnet으로 구축한 agentic RAG 아키텍처.png
그림 7: Milvus, LlamaIndex, Cluade 3.5 Sonnet으로 구축한 agentic RAG 아키텍처
결론
Bill Zhang은 그의 강연에서 LLM 시스템의 진화하는 환경을 살펴보며, 단독 모델에서 RAG와 에이전트를 통합한 더 복잡한 아키텍처로의 전환을 강조했습니다. 각 구성 요소—LLM, RAG, 에이전트—에는 강점과 약점이 있습니다. Compound AI 개념은 다양한 병목 현상을 해결하도록 설계된 모듈식 시스템의 생성을 가능하게 하여, 파이프라인의 전반적인 효율성을 향상시킵니다.
이러한 고급 시스템의 결과는 유망하며 프로덕션 준비가 된 구현도 점점 더 흔해지고 있지만, 특히 이러한 시스템 내에서 에이전트 동작을 관리하고 사용자 지정하는 데는 여전히 여러 과제가 남아 있습니다. 특정 사용 사례에서 효율적으로 작동하도록 이러한 구성 요소를 미세 조정하는 것은 지속적인 개발 영역입니다.
GenAI, VectorDB, ML에 대한 추가 리소스
계속 읽기
From Vector Database to Vector Lakebase
Zilliz offers a fully managed Vector Lakebase powered by Milvus, unifying real-time vector search, lake-scale discovery, and Al data operations.
The Real Bottlenecks in Autonomous Driving — And How AI Infrastructure Can Solve Them
Autonomous driving faces a data bottleneck. Learn how AI-native vector databases like Zilliz solve scale, cost, and insight challenges across AV pipelines.
Building RAG Pipelines for Real-Time Data with Cloudera and Milvus
explore how Cloudera can be integrated with Milvus to effectively implement some of the key functionalities of RAG pipelines.