에이전틱 AI

에이전트 AI 시스템은 다음과 같은 구성 요소로 이루어져 있습니다.

• 에이전트 오케스트레이션 구성 요소는 에이전트 집합의 작업을 관리하고 조정합니다. 에이전트 오케스트레이션 구성 요소는 복잡한 작업을 해결하기 위해 LLM을 사용하여 워크플로를 분해하고 동적으로 생성하거나, 정적으로 정의된 워크플로를 사용하거나, 비즈니스 프로세스 모델링 표기법(BPMN)이나 비즈니스 프로세스 실행 언어(BPEL) 또는 기타 워크플로 기술을 사용합니다.
  
  
• 하나 이상의 에이전트, 즉 지정된 목표를 달성하기 위해 스스로 행동을 결정하고 실행할 수 있는 소프트웨어 조각. 에이전트는 일반적으로 LLM을 사용하여 작업을 완료하기 위한 계획을 동적으로 생성합니다. 에이전트는 도구를 사용하여 외부 시스템과 상호 작용할 수도 있습니다. 예를 들어 엔터프라이즈 애플리케이션 API와 상호 작용하거나, 지식 저장소를 검색하거나, Wikipedia에 쿼리하거나, LLM만 사용해서는 정확하거나 효과적으로 수행할 수 없는 수학 연산과 같은 계산을 수행할 수 있습니다.
  
  
• 마지막으로, 이 도구는 기업 및 외부 소스 및 시스템과 상호 작용하여 정보를 검색하고 기록 시스템을 업데이트합니다.

에이전트에는 아래 그림과 같이 고유한 개념적 아키텍처가 있습니다.

에이전트는 다음과 같은 핵심 구성 요소로 구성됩니다.

• 입력 구성 요소는 에이전트가 동작을 수행하도록 트리거하는 하나 이상의 입력 소스입니다. 일반적으로 이는 사용자의 자연어 쿼리 또는 작업이지만 파일 생성, Kafka 대기열의 메시지 또는 구조화된 API 호출과 같은 시스템 이벤트일 수도 있습니다.
  
  
• 실행 구성 요소는 필요한 작업을 수행하기 위해 에이전트의 활동을 조정합니다. 일반적으로 실행 구성 요소에 의해 실행되는 첫 번째 작업은 (i) 에이전트가 사용할 수 있는 도구 및 리소스 목록을 정리하고, (ii) 계획 및 반영 구성 요소를 호출하여 작업을 수행하기 위한 활동 계획을 생성하는 것입니다. 그런 다음 실행 구성 요소는 생성된 계획을 실행하고, 필요에 따라 도구와 리소스를 호출하여 정보를 수집하거나 에이전트의 외부 환경을 변경합니다. 또한 도구 응답/실패에 따라 활동 계획을 조정하기 위해 계획 및 반영 구성 요소를 주기적으로 다시 호출할 수 있습니다.
  
  
• 일반적으로 LLM인 계획 및 성찰 구성 요소를 사용하면 에이전트가 단계별 실행 계획을 수립하여 입력에 따라 작업을 수행하고, 작업의 결과를 반영하며, 이에 따라 계획을 조정할 수 있습니다.
  
  
• 도구 통합 구성 요소를 통해 에이전트는 '도구'를 사용하여 API를 호출하고 리소스에 액세스하여 작업을 완료하고 정보를 수집하여 전체 작업 완료에 기여할 수 있습니다.
  
  
• 메모리 구성 요소는 단기, 작업 내, 컨텍스트 및 장기 지식을 관리하여 에이전트가 작업 호출(예: "마지막 구매 주문 취소") 전반에 걸쳐 컨텍스트를 유지하고, 과거 행동의 최적화와 미래 행동의 최적화를 제공하기 위한 분석 기반을 제공할 수 있도록 합니다.
  

그림에 표시되지 않은 추가 구성 요소를 추가하여 운영 에이전트 관리, 성능 모니터링, ID 전파 및 데이터 유출 방지와 같은 보안 제어를 제공할 수 있습니다.

아래 다이어그램은 개념적 아키텍처를 통한 제어 및 정보의 흐름을 보여줍니다.

1. 사용자가 생성형 AI 애플리케이션(예: 챗봇 또는 엔터프라이즈 애플리케이션 내 쿼리 인터페이스)에 쿼리를 제출합니다.
   
   
2. 생성형 AI 애플리케이션은 사용자의 쿼리를 원시 쿼리(예: AI 애플리케이션은 채팅 인터페이스) 또는 사전 정의된 워크플로 트리거(예: 구매 요청 시작) 형태로 에이전트 오케스트레이터에 전달합니다. 여기에서는 원시 쿼리를 예로 살펴보겠습니다.
   
   
3. 라우터는 튜닝된 LLM을 사용하여 사용자 쿼리를 답변에 도달하는 데 필요한 일련의 작업 또는 단계로 세분화합니다. 예를 들어, "캐나다 매니토바주 위니펙의 현재 기온은 몇 도인가요? 연중 이 시기의 과거 평균 기온과 비교하면 어떤가요?"라는 질문에 답변할 때, LLM은 다음과 같은 개념적 작업 목록으로 응답할 수 있습니다.
   
   
   • 날씨 에이전트를 사용하여 위니펙의 현재 온도 조회
   • 캘린더 에이전트를 사용하여 현재 날짜 조회
   • 검색 에이전트를 사용하여 해당 날짜에 위니펙의 평균 기온 조회
   • 계산기 에이전트를 사용하여 현재 기온과 과거 평균 기온의 차이 찾기
   • 언어 에이전트를 사용하여 자연어 응답 형성
     
     
4. 그런 다음 오케스트레이터는 목록의 각 작업에 대해 적절한 에이전트를 호출합니다. 3단계의 예를 계속 살펴보겠습니다.
   
   
   • 오케스트레이터는 The Weather 에이전트를 호출하여 위니펙의 현재 온도(-1°C)를 검색합니다.
   • 오케스트레이터는 캘린더 에이전트를 호출하여 현재 날짜인 2023년 11월 9일을 가져옵니다.
   • 오케스트레이터는 검색 에이전트를 사용하여 11월 9일 위니펙의 정상 온도인 1.4°C를 찾습니다.
   • 오케스트레이터는 계산기 에이전트를 호출하여 두 온도의 차이(-1 - 1.4 = -2.4)를 찾습니다.
   • 오케스트레이터는 언어 에이전트를 이용해 수집된 데이터를 사용하여 초기 쿼리에 대한 응답을 형성합니다.
      
5. 에이전트가 호출되면 오케스트레이터와 마찬가지로 LLM을 사용하여 작업을 계획할 수 있습니다. 예시를 계속 살펴보면, The Weather 에이전트는 "위니펙의 현재 기온은 얼마인가요?"라는 요청을 수신하고 다음과 같은 계획을 생성합니다.
   
   
   • 위니펙이 위치한 국가를 찾습니다.
   • 위니펙의 위치한 국가의 권위 있는 국립 기상청을 찾습니다.
   • 날씨 API를 사용하여 위니펙의 현재 기온을 날씨 서비스에 쿼리합니다.
   • 그런 다음 에이전트는 LLM 또는 외부 서비스를 사용하여 위니펙이 위치한 국가(캐나다)를 조회하고, 해당 값을 사용하여 캐나다의 국가 기상 서비스(Environment Canada)를 조회하고, 날씨 API를 사용하여 위니펙의 현재 온도를 파악합니다.
      
6. 그런 다음 결과 응답은 생성형 AI 애플리케이션으로 다시 전달됩니다. 이 예에서 응답은 다음과 같습니다. "현재 위니펙의 기온은 -1°C입니다. 이는 과거의 1.4°C보다 2.4°C 낮은 온도입니다."
   
   
7. 형성된 응답은 사용자에게 다시 전달됩니다.

위 다이어그램은 IBM 제품을 에이전트 AI 아키텍처에 매핑하는 방법을 보여줍니다.

watsonx Orchestrate는 다음을 결합하는 '올인원' 에이전틱 AI 솔루션입니다.

• 도구 게시 및 관리(watsonx Orchestrate™에서는 '스킬'이라고 함)
• 선언적 워크플로를 사용하여 기술을 복잡한 다단계 프로세스로 구성
• HR 및 구매와 같은 수평적 비즈니스 영역을 위해 사전 구축된 도메인별 에이전트

watsonx.ai Agent Builder는 개발자가 사전 구축된 플로우를 사용하여 에이전트를 구축하고 도구를 정의 및 관리할 수 있게 해주는 로우코드/노코드 도구입니다.

오케스트레이션 전략

에이전트 오케스트레이션은 다양한 접근 방식을 사용하여 구현할 수 있습니다. 중앙 집중식 오케스트레이션 접근 방식은 단일 마스터 오케스트레이션 구성 요소를 사용하여 시스템에 있는 다른 모든 에이전트의 작업을 관리합니다. 단일 구성 및 관리 지점이 있으면 전체 시스템의 관리 및 제어가 간단해지고 문제 해결도 쉬워집니다. 단점은 단일 제어 지점이 병목 현상이 될 수 있으며, 요청 볼륨 및/또는 에이전트 수가 증가할수록 확장성 문제가 발생할 수 있다는 것입니다.

분산형 오케스트레이션 접근 방식은 에이전트가 작업을 가져오고 결과를 게시하며, 여러 부분으로 구성된 작업을 서로 라우팅하는 작업 대기열을 구현합니다. 이는 블랙보드 시스템과 유사합니다. 분산형 오케스트레이션 솔루션은 매우 강력하고 내결함성이 뛰어나지만, 시스템 규모가 증가하고 기능이 광범위해질수록 설계하고 문제를 해결하기가 어려워집니다.

마지막으로, 계층적 오케스트레이션 접근 방식은 중앙 집중식 접근 방식과 분산형 접근 방식의 요소를 결합합니다. 계층적 오케스트레이션에서는 상위 수준 에이전트의 작업을 조정하는 데 마스터 오케스트레이터가 사용되며, 이 상위 수준의 에이전트는 다른 에이전트를 호출하여 복잡한 작업을 완료할 수 있습니다. 이는 중앙 집중식 접근 방식의 관리 및 제어 용이성을 상당 부분 유지하면서도 요청량이 많거나 에이전트 수가 많은 경우 중앙 제어 구성 요소에서 병목 현상이 발생할 가능성을 줄여 줍니다.

에이전트 세분화

AI 에이전트의 세분화는 에이전트가 수행할 수 있는 작업의 복잡성을 나타냅니다. 세분화 수준이 높은 에이전트는 다수의 작업 또는 소수의 작업을 매우 상세하게 수행할 수 있는 반면, 세분화 수준이 낮은 에이전트는 소수의 작업 또는 단일 작업만 낮은 상세도로 수행할 수 있습니다. 이를 보다 명확하게 이해하려면 고객 서비스 상담원을 생각해 보세요. 세분화 수준이 낮은 에이전트는 제품에 관한 간단한 질문(예: "검정색도 있나요?")에만 답변할 수 있는 반면, 세분화 수준이 높은 에이전트는 현지 재고를 확인하고 고객 자택으로의 제품 배송을 예약할 수 있습니다.

에이전트 솔루션 설계자는 시스템 내에서 개별 에이전트를 얼마나 세분화할 것인지 결정해야 합니다(예: 세분화 수준이 높은 소수의 에이전트 또는 세분화 수준이 낮은 다수의 에이전트). 세분화 수준이 높은 에이전트의 광범위한 능력에는 컴퓨팅 리소스 요구 사항이 증가하고 작업 완료 시간이 길어진다는 대가가 수반됩니다. 세분화 수준이 낮은 에이전트는 기능은 떨어지지만 초점이 좁기 때문에 컴퓨팅 리소스가 덜 필요하고 일반적으로 작업을 훨씬 더 빠르게 완료할 수 있습니다.

'적절한' 세분화 수준이 무엇인지 아직 알 수는 없지만, 초기 경험에 따르면 중요 비즈니스 프로세스에 맞춰 세분화 수준이 낮은 에이전트(예: Purchase_Order_Processing_Agent)를 만들면 리소스 요구 사항, 처리 속도와 솔루션 복잡성 간에 적절한 균형을 맞출 수 있습니다. 그런 다음 세분화 수준이 낮은 에이전트를 정적 워크플로에 통합하거나 더 큰 프로세스의 일부로 세분화 수준이 높은 에이전트가 호출하도록 할 수 있습니다.

정적 워크플로와 동적 워크플로의 비교

에이전틱 AI 솔루션 설계자는 사전 정의된 정적 프로세스 및 워크플로를 따르는 에이전트와 사용자 프롬프트에 따라 워크플로를 동적으로 생성하는 것 사이에서 균형을 유지해야 합니다. 정답이나 오답은 없지만, 아키텍트는 다음 권장 사항과 고려 사항을 고려하는 것이 좋습니다:

• 여러 지식 분야(예: 법률 및 회계)를 넘나드는 여러 복잡한 단계로 구성된 비즈니스 프로세스 또는 규제 감독이 적용되는 비즈니스 프로세스에는 정적 워크플로를 사용해야 합니다. 이러한 경우에 정적 워크플로를 사용하면 아키텍트는 다음과 같은 몇 가지 이점을 누릴 수 있습니다.

  • 정적 워크플로는 (상대적으로) 계측, 모니터링 및 감사가 간단하며 워크플로 자체를 규정 준수의 증거로 사용할 수 있습니다. 동적으로 생성된 워크플로는 실행 시 모니터링하기가 더 어려우며, 개별 프로세스 실행을 개별 에이전트 로그에서 재구성해야 합니다. 또한 동적 워크플로는 작업 순서를 변경할 수 있으며, 이는 감사 및 규정 준수 모니터링을 더욱 복잡하게 만들 수 있습니다.
    
    
  • 전문 분야 간의 '핸드오프'가 잘 정의되어 있으면 책임이 명확하게 분리되며, 전달된 정보가 완전하고 올바른지 쉽게 확인할 수 있습니다. 동적으로 생성된 워크플로에서도 동일한 상태를 달성할 수 있지만, 이를 위해서는 설계 및 구현 시 더 면밀한 주의가 필요합니다.
    
    
• 동적 워크플로는 시간적으로 매우 가깝게 수행되고 여러 지식 분야를 넘나들지 않으며 실행에 규제 감독이나 통제가 적용되지 않는 '단일 단계' 활동 또는 기능에 사용해야 합니다.