LangChain과 Elasticsearch를 사용하여 에이전트 RAG 어시스턴트 개발하기

Agent Builder는 현재 기술 미리보기 버전으로 제공됩니다. Elastic Cloud 체험판으로 시작한 뒤, Agent Builder 문서를 여기에서 확인하세요.

이 블로그 게시물에서는 에이전트 RAG 워크플로우의 주요 기능과 일반적인 디자인 패턴에 대해 자세히 설명합니다. 또한 Elasticsearch를 벡터 저장소로 사용하고 LangChain을 사용하여 에이전트 RAG 프레임워크를 구성하는 실습 예제를 통해 이러한 워크플로우를 구현하는 방법을 보여줍니다. 마지막으로 이러한 아키텍처의 설계 및 구현과 관련된 모범 사례와 과제에 대해 간략하게 설명합니다. 이 Jupyter 노트북을 사용하여 간단한 에이전트 RAG 파이프라인을 만들 수 있습니다.

에이전트 RAG 소개

검색 증강 생성(RAG)은 LLM 기반 애플리케이션의 초석이 되어 모델이 사용자 쿼리를 기반으로 관련 컨텍스트를 검색하여 최적의 답변을 제공할 수 있게 해줍니다. RAG 시스템은 사전 학습된 LLM 지식에 국한되지 않고 API 또는 데이터 저장소의 외부 정보를 활용하여 LLM 응답의 정확성과 컨텍스트를 향상시킵니다. 반면에 AI 에이전트는 자율적으로 작동하여 지정된 목표를 달성하기 위해 의사 결정을 내리고 조치를 취합니다.

에이전트 RAG는 검색 증강 생성과 에이전트 추론의 강점을 통합한 프레임워크입니다. RAG를 상담원의 의사 결정 프로세스에 통합하여 시스템이 동적으로 데이터 소스를 선택하고, 더 나은 컨텍스트 검색을 위해 쿼리를 구체화하고, 더 정확한 응답을 생성하고, 피드백 루프를 적용하여 출력 품질을 지속적으로 개선할 수 있도록 지원합니다.

에이전트 RAG의 주요 기능

에이전트 RAG 프레임워크는 기존 RAG 시스템보다 크게 발전한 것입니다. 고정된 검색 프로세스를 따르는 대신 실시간으로 결과를 계획, 실행 및 최적화할 수 있는 동적 에이전트를 활용합니다.

에이전트 RAG 파이프라인을 구별하는 몇 가지 주요 기능을 살펴보겠습니다:

동적 의사 결정: 에이전트 RAG는 추론 메커니즘을 사용하여 사용자의 의도를 파악하고 각 쿼리를 가장 관련성이 높은 데이터 소스로 라우팅하여 정확하고 맥락에 맞는 응답을 생성합니다.
종합적인 쿼리 분석: 에이전틱 RAG는 하위 질문과 전반적인 의도를 포함하여 사용자 쿼리를 심층적으로 분석합니다. 쿼리 복잡성을 평가하고 가장 관련성이 높은 데이터 소스를 동적으로 선택하여 정보를 검색함으로써 정확하고 완전한 응답을 보장합니다.
다단계 협업: 이 프레임워크는 전문 에이전트 네트워크를 통해 다단계 협업을 가능하게 합니다. 각 에이전트는 더 큰 목표의 특정 부분을 처리하며, 일관된 결과를 달성하기 위해 순차적으로 또는 동시에 작업합니다.
자체 평가 메커니즘: 에이전트 RAG 파이프라인은 자체 반영을 사용하여 검색된 문서와 생성된 응답을 평가합니다. 검색된 정보가 쿼리에 완전히 부합하는지 확인한 다음 출력물의 정확성, 완전성, 사실적 일관성을 검토할 수 있습니다.
외부 도구와의 통합: 이 워크플로는 외부 API, 데이터베이스 및 실시간 정보 소스와 상호 작용하여 최신 정보를 통합하고 진화하는 데이터에 동적으로 적응할 수 있습니다.

에이전트 RAG의 워크플로 패턴

워크플로 패턴은 에이전트 AI가 안정적이고 효율적인 방식으로 LLM 기반 애플리케이션을 구성, 관리 및 오케스트레이션하는 방법을 정의합니다. 이러한 에이전트 워크플로우를 구현하기 위해 LangChain, LangGraph, CrewAI, LlamaIndex와 같은 여러 프레임워크와 플랫폼을 사용할 수 있습니다.

순차적 검색 체인: 순차적 워크플로는 복잡한 작업을 단순하고 정돈된 단계로 나눕니다. 각 단계는 다음 단계의 입력을 개선하여 더 나은 결과로 이어집니다. 예를 들어 고객 프로필을 만들 때 한 상담원이 CRM에서 기본 세부 정보를 가져오고, 다른 상담원이 거래 데이터베이스에서 구매 내역을 검색한 다음, 최종 상담원이 이 정보를 결합하여 추천 또는 보고서를 위한 완전한 프로필을 생성할 수 있습니다.
라우팅 검색 체인: 이 워크플로 패턴에서는 라우터 에이전트가 입력을 분석하여 가장 적합한 프로세스나 데이터 소스로 라우팅합니다. 이 접근 방식은 겹치는 부분이 최소화된 여러 데이터 원본이 존재하는 경우에 특히 효과적입니다. 예를 들어 고객 서비스 시스템에서 라우터 상담원은 기술 문제, 환불, 불만 등 들어오는 요청을 분류한 후 해당 부서로 라우팅하여 효율적으로 처리합니다.
병렬 검색 체인: 이 워크플로 패턴에서는 여러 개의 독립적인 하위 작업이 동시에 실행되고 나중에 그 결과물을 집계하여 최종 응답을 생성합니다. 이 접근 방식은 처리 시간을 크게 단축하고 워크플로 효율성을 높입니다. 예를 들어 고객 서비스 병렬 워크플로우에서 한 상담원은 유사한 과거 요청을 검색하고 다른 상담원은 관련 지식창고 문서를 참조합니다. 그런 다음 애그리게이터는 이러한 출력을 결합하여 종합적인 해상도를 생성합니다.
오케스트레이터 워커 체인: 이 워크플로는 독립적인 하위 작업을 활용한다는 점에서 병렬화와 유사점을 공유합니다. 그러나 중요한 차이점은 오케스트레이터 에이전트의 통합에 있습니다. 이 에이전트는 사용자 쿼리를 분석하여 런타임 중에 하위 작업으로 동적으로 분류하고 정확한 응답을 작성하는 데 필요한 적절한 프로세스 또는 도구를 식별하는 역할을 담당합니다.

에이전트 RAG 파이프라인을 처음부터 구축하기

에이전트 RAG의 원리를 설명하기 위해 LangChain과 Elasticsearch를 사용해 워크플로우를 설계해 보겠습니다. 이 워크플로에서는 여러 상담원이 협업하여 쿼리를 분석하고 관련 정보를 검색하며 결과를 평가하고 일관된 응답을 생성하는 라우팅 기반 아키텍처를 채택하고 있습니다. 이 Jupyter 노트북을 참조하여 이 예제를 따라할 수 있습니다.

워크플로는 라우터 에이전트가 사용자의 쿼리를 분석하여 최적의 검색 방법, 즉 vectorstore, websearch, composite 중 하나를 선택하는 것으로 시작됩니다. 벡터스토어는 기존의 RAG 기반 문서 검색을 처리하고, 웹검색은 벡터스토어에 저장되지 않은 최신 정보를 가져오며, 여러 소스의 정보가 필요한 경우 이 두 가지를 결합하는 복합적인 접근 방식을 사용합니다.

문서가 적합하다고 판단되면 요약 에이전트가 명확하고 문맥에 맞는 답변을 생성합니다. 그러나 문서가 불충분하거나 관련성이 없는 경우 쿼리 재작성 에이전트가 검색을 개선하기 위해 쿼리를 다시 작성합니다. 그러면 수정된 쿼리가 라우팅 프로세스를 다시 시작하여 시스템이 검색을 개선하고 최종 결과를 향상시킬 수 있습니다.

필수 구성 요소

이 워크플로에서는 예제를 효과적으로 실행하기 위해 다음과 같은 핵심 구성 요소를 사용합니다:

Python 3.10
주피터 노트북
Azure OpenAI
Elasticsearch
LangChain

계속 진행하기 전에 이 예제에 필요한 다음 환경 변수 집합을 구성하라는 메시지가 표시됩니다.

데이터 소스

이 워크플로는 AG 뉴스 데이터 세트의 하위 집합을 사용하여 설명합니다. 이 데이터 세트는 국제, 스포츠, 비즈니스, 과학/기술 등 다양한 카테고리의 뉴스 기사로 구성되어 있습니다.

ElasticsearchStore 모듈은 langchain_elasticsearch 에서 벡터 저장소로 활용됩니다. 검색을 위해 Elastic의 독점적인 임베딩 모델인 ELSER를 사용하는 SparseVectorStrategy를 구현합니다. 벡터 저장소를 시작하기 전에 ELSER 모델이 Elasticsearch 환경에 올바르게 설치 및 배포되었는지 확인해야 합니다.

웹 검색 기능은 LangChain 커뮤니티 도구의 DuckDuckGoSearchRun을 사용하여 구현되어 시스템이 웹에서 실시간 정보를 효율적으로 검색할 수 있습니다. 보다 관련성 높은 결과를 제공할 수 있는 다른 검색 API를 사용하는 것도 고려해 볼 수 있습니다. 이 도구는 API 키 없이도 검색이 가능하기 때문에 선택되었습니다.

복합 검색기는 여러 소스를 조합해야 하는 쿼리를 위해 설계되었습니다. 웹에서 실시간 데이터를 검색하는 동시에 벡터 스토어에서 과거 뉴스를 참조하여 포괄적이고 맥락에 맞는 정확한 응답을 제공하는 데 사용됩니다.

상담원 설정하기

다음 단계에서는 이 워크플로 내에서 추론 및 의사 결정 기능을 제공하도록 LLM 에이전트를 정의합니다. 우리가 만들 LLM 체인에는 다음이 포함됩니다: router_chain, grade_docs_chain, rewrite_query_chain, 그리고 summary_chain.

라우터 에이전트는 LLM 어시스턴트를 사용하여 런타임에 주어진 쿼리에 가장 적합한 데이터 소스를 결정합니다. 채점 에이전트는 검색된 문서의 관련성을 평가합니다. 문서가 관련성이 있다고 판단되면 요약 에이전트로 전달되어 요약을 생성합니다. 그렇지 않으면 쿼리 재작성 에이전트가 쿼리를 재구성하여 라우팅 프로세스로 다시 보내 다른 검색을 시도합니다. 노트북의 LLM 체인 섹션에서 모든 에이전트에 대한 지침을 찾을 수 있습니다.

llm.with_structured_output 은 모델의 출력이 RouteQuery 클래스의 BaseModel에 정의된 사전 정의된 스키마를 따르도록 제한하여 결과의 일관성을 보장합니다. 두 번째 줄은 router_prompt 과 router_structured 을 연결하여 RunnableSequence 을 구성하여 입력 프롬프트가 언어 모델에 의해 처리되어 구조화된 스키마 준수 결과를 생성하는 파이프라인을 형성합니다.

그래프 노드 정의

이 부분에는 시스템의 여러 구성 요소 간에 흐르는 데이터를 나타내는 그래프의 상태를 정의하는 작업이 포함됩니다. 이러한 상태를 명확하게 지정하면 워크플로우의 각 노드가 어떤 정보에 액세스하고 업데이트할 수 있는지 알 수 있습니다.

상태가 정의되면 다음 단계는 그래프의 노드를 정의하는 것입니다. 노드는 데이터에 대한 특정 연산을 수행하는 그래프의 기능 단위와 같습니다. 파이프라인에는 7개의 서로 다른 노드가 있습니다.

query_rewriter 노드는 워크플로에서 두 가지 용도로 사용됩니다. 먼저, 자체 반영 에이전트가 평가한 문서가 불충분하거나 관련성이 없다고 판단되는 경우 검색을 개선하기 위해 rewrite_query_chain 을 사용하여 사용자 쿼리를 재작성합니다. 둘째, 쿼리가 재작성된 횟수를 추적하는 카운터 역할을 합니다.

노드가 호출될 때마다 워크플로 상태에 저장된 retry_count 이 증가합니다. 이 메커니즘은 워크플로우가 무한 루프에 빠지는 것을 방지합니다. retry_count 이 사전 정의된 임계값을 초과하면 시스템은 오류 상태, 기본 응답 또는 사용자가 선택한 기타 사전 정의된 조건으로 폴백할 수 있습니다.

그래프 컴파일하기

마지막 단계는 그래프의 가장자리를 정의하고 필요한 조건을 추가한 후 컴파일하는 것입니다. 모든 그래프는 워크플로우의 시작점 역할을 하는 지정된 시작 노드에서 시작해야 합니다. 그래프의 에지는 노드 간의 데이터 흐름을 나타내며 두 가지 유형이 있을 수 있습니다:

직선 가장자리: 한 노드에서 다른 노드로의 직접적이고 무조건적인 흐름을 정의합니다. 첫 번째 노드가 작업을 완료할 때마다 워크플로는 직선을 따라 다음 노드로 자동 진행됩니다.
조건부 에지: 현재 상태 또는 노드의 계산 결과에 따라 워크플로를 분기할 수 있습니다. 다음 노드는 평가 결과, 라우팅 결정 또는 재시도 횟수 등의 조건에 따라 동적으로 선택됩니다.

이제 첫 번째 에이전트 RAG 파이프라인이 준비되었으며 컴파일된 에이전트를 사용하여 테스트할 수 있습니다.

에이전트 RAG 파이프라인 테스트

이제 아래와 같이 세 가지 유형의 쿼리를 사용하여 이 파이프라인을 테스트해 보겠습니다. 결과는 다를 수 있으며, 아래 예시는 한 가지 가능한 결과를 보여주는 것일 뿐입니다.

첫 번째 쿼리의 경우 라우터는 websearch 을 데이터 소스로 선택합니다. 쿼리가 자체 반영 평가에 실패하면 출력에 표시된 것처럼 쿼리 재작성 단계로 리디렉션됩니다.

다음으로 두 번째 쿼리를 통해 vectorstore 검색이 사용되는 예시를 살펴봅니다.

최종 쿼리는 벡터스토어와 웹 검색을 모두 활용하는 복합 검색으로 진행됩니다.

위의 워크플로우에서 에이전트 RAG는 사용자 쿼리에 대한 정보를 검색할 때 사용할 데이터 소스를 지능적으로 결정하여 응답의 정확성과 관련성을 개선합니다. 에이전트를 테스트하기 위해 추가 예제를 만들고 출력을 검토하여 흥미로운 결과가 나오는지 확인할 수 있습니다.

에이전트 RAG 워크플로우 구축을 위한 모범 사례

이제 에이전트 RAG의 작동 방식을 이해했으니 이러한 워크플로를 구축하기 위한 몇 가지 모범 사례를 살펴보겠습니다. 이 가이드라인을 따르면 시스템을 효율적이고 쉽게 유지 관리하는 데 도움이 됩니다.

폴백에 대비하세요: 워크플로우의 어느 단계에서든 장애가 발생할 경우를 대비하여 미리 대체 전략을 계획하세요. 여기에는 기본 답변 반환, 오류 상태 트리거 또는 대체 도구 사용이 포함될 수 있습니다. 이렇게 하면 시스템이 전체 워크플로우를 중단하지 않고도 장애를 원활하게 처리할 수 있습니다.
포괄적인 로깅을 구현하세요: 재시도, 생성된 출력, 라우팅 선택, 쿼리 재작성 등 워크플로우의 각 단계에서 로깅을 구현해 보세요. 이러한 로그는 투명성을 개선하고 디버깅을 더 쉽게 하며 시간이 지남에 따라 프롬프트, 상담원 행동 및 검색 전략을 개선하는 데 도움이 됩니다.
적절한 워크플로 패턴을 선택합니다: 사용 사례를 검토하여 필요에 가장 적합한 워크플로 패턴을 선택하세요. 단계별 추론에는 순차적 워크플로를, 독립적인 데이터 소스에는 병렬 워크플로를, 다중 도구 또는 복잡한 쿼리에는 오케스트레이터-작업자 패턴을 사용합니다.
평가 전략을 통합하세요: 워크플로우의 여러 단계에 평가 메커니즘을 통합하세요. 여기에는 자기 반성 에이전트, 검색된 문서 채점, 자동화된 품질 검사 등이 포함될 수 있습니다. 평가는 검색된 문서가 관련성이 있는지, 답변이 정확한지, 복잡한 쿼리의 모든 부분이 해결되었는지 확인하는 데 도움이 됩니다.

도전 과제

에이전트 RAG 시스템은 적응성, 정확성, 동적 추론 측면에서 상당한 이점을 제공하지만, 설계 및 구현 단계에서 해결해야 하는 특정 과제를 안고 있기도 합니다. 주요 과제 중 일부는 다음과 같습니다:

복잡한 워크플로: 더 많은 상담원과 의사 결정 포인트가 추가됨에 따라 전체 워크플로우가 점점 더 복잡해집니다. 이로 인해 런타임에 오류나 장애가 발생할 가능성이 높아질 수 있습니다. 가능하면 중복 상담원과 불필요한 의사 결정 지점을 제거하여 워크플로우를 간소화하는 데 우선순위를 두세요.
확장성: 대규모 데이터 세트와 많은 쿼리 양을 처리하기 위해 에이전트 RAG 시스템을 확장하는 것은 어려울 수 있습니다. 효율적인 인덱싱, 캐싱 및 분산 처리 전략을 통합하여 규모에 맞게 성능을 유지하세요.
오케스트레이션 및 컴퓨팅 오버헤드: 여러 에이전트가 포함된 워크플로를 실행하려면 고급 오케스트레이션이 필요합니다. 여기에는 병목 현상과 충돌을 방지하기 위한 신중한 스케줄링, 종속성 관리, 상담원 조정이 포함되며, 이 모든 것이 전반적인 시스템 복잡성을 가중시킵니다.
평가의 복잡성: 각 단계마다 고유한 평가 전략이 필요하기 때문에 이러한 워크플로를 평가하는 데는 고유한 어려움이 있습니다. 예를 들어 RAG 단계에서는 검색된 문서의 관련성과 완전성을 평가해야 하며, 생성된 요약의 품질과 정확성을 확인해야 합니다. 마찬가지로 쿼리 재구성의 효과는 재작성된 쿼리가 검색 결과를 개선하는지 여부를 판단하기 위한 별도의 평가 로직이 필요합니다.

결론

이 블로그 게시물에서는 에이전트 RAG의 개념을 소개하고 에이전트 AI의 자율 기능을 통합하여 기존 RAG 프레임워크를 개선하는 방법을 강조했습니다. 에이전트 RAG의 핵심 기능을 살펴보고 실제 예제를 통해 이러한 기능을 시연했으며, Elasticsearch를 벡터 저장소로 사용하고 LangChain을 에이전트 프레임워크를 생성하는 뉴스 어시스턴트를 구축했습니다.

또한 에이전트 RAG 파이프라인을 설계하고 구현할 때 고려해야 할 모범 사례와 주요 과제에 대해서도 논의했습니다. 이러한 인사이트는 개발자가 검색, 추론 및 의사 결정을 효과적으로 결합하는 강력하고 확장 가능하며 효율적인 에이전트 시스템을 만드는 데 도움을 주기 위한 것입니다.

그럼 이제 무엇을 해야 할까요?

우리가 구축한 워크플로우는 단순하여 개선과 실험을 위한 충분한 여지를 남겨두고 있습니다. 다양한 임베딩 모델을 실험하고 검색 전략을 개선하여 이를 개선할 수 있습니다. 또한 검색된 문서의 우선 순위를 다시 지정하는 에이전트를 통합하면 도움이 될 수 있습니다. 또 다른 탐색 영역은 에이전트 프레임워크에 대한 평가 전략을 개발하는 것으로, 특히 다양한 유형의 프레임워크에 적용 가능한 공통적이고 재사용 가능한 접근 방식을 식별하는 것입니다. 마지막으로, 더 크고 복잡한 데이터 세트에서 이러한 프레임워크를 실험해 보세요.

그동안 비슷한 실험을 해보신 경험이 있으시다면 공유해 주시면 감사하겠습니다! 커뮤니티 Slack 채널이나 토론 포럼을 통해 자유롭게 피드백을 제공하거나 소통하세요.