랭체인 프로젝트 경영진 인텔리전스

계획 실행 인텔리전스는 이전 설계보다 더 빠르고 비용 효율적이며 성능이 뛰어난 작업 실행 솔루션을 제공합니다. 이 글에서는 LangGraph에서 세 가지 계획 인텔리전스를 구축하는 방법을 안내합니다.

저희는 LangGraph 플랫폼에 세 가지 "계획 및 실행" 모드 인텔리전스를 도입했습니다. 이러한 인텔리전스는 기존의 ReAct(Reason and Act) 모드 인텔리전스보다 몇 가지 개선된 기능을 보여줍니다.

첫째, 각 작업을 완료한 후 다시 대규모 인텔리전스의 참여를 요청할 필요가 없기 때문에 다단계 작업 프로세스를 보다 빠르게 수행할 수 있습니다. 각 하위 작업은 추가적인 대규모 언어 모델(LLM) 호출이나 경량 LLM 지원 호출 없이도 완료할 수 있습니다.

둘째, ReAct 인텔리전스에 비해 비용을 효과적으로 절감할 수 있습니다. 하위 작업에 LLM 호출이 필요한 경우 일반적으로 더 작은 도메인별 모델이 사용됩니다. 대규모 모델은 (재)계획 단계를 수행하고 최종 응답을 생성해야 할 때만 호출됩니다.

마지막으로, 기획자에게 전체 작업을 완료하는 데 필요한 프로세스에 대해 단계별로 명시적으로 '생각'하도록 요청함으로써 이러한 지능은 작업 완료율과 품질 측면에서 더 나은 성과를 낼 수 있습니다. 세부적인 추론 단계를 개발하는 것은 결과를 개선하기 위한 검증된 큐잉 기법입니다. 또한 문제를 세분화하면 보다 집중적이고 효율적인 작업 수행으로 이어질 수 있습니다.

배경

지난 한 해 동안 언어 모델에 기반한 지능형 에이전트와 상태 머신은 유연하고 효율적인 AI 제품 개발을 위한 유망한 설계 패러다임으로 부상했습니다.

에이전트의 핵심은 질문에 답하거나 작업을 수행하기 위해 외부 리소스에 연결하는 일반적인 문제 해결 도구로서의 언어 모델입니다.

일반적으로 언어 모델을 기반으로 하는 지능형 에이전트는 다음과 같은 주요 단계를 거칩니다:

1. 작업 제안: 언어 모델은 사용자에게 직접 응답하거나 함수에 전달되는 텍스트를 생성합니다.
2. 작업 실행: 코드가 다른 소프트웨어를 호출하여 데이터베이스 쿼리, API 호출 및 기타 작업 등을 수행합니다.
3. 관찰 관찰: 다른 함수를 호출하거나 사용자에게 응답하여 도구 호출의 피드백에 반응합니다.

ReAct 지능형 에이전트는 사고, 행동, 관찰의 반복적인 주기를 사용하여 언어 모델을 안내하는 좋은 예입니다:

생각: Search()를 호출하여 현재 경기의 점수를 조회해야 합니다.
액션: 검색("현재 X 경기의 점수는 얼마입니까?")
관찰: 현재 점수는 24-21입니다.
... (N회 반복)

이것은 전형적인 ReAct 스타일의 지능형 에이전트 궤적입니다.

이 접근 방식은 다음을 활용합니다.생각의 연쇄프롬프트가 표시되어 각 단계에서 한 번의 작업 결정만 이루어지도록 합니다. 이 방법은 간단한 작업에는 효과적일 수 있지만 몇 가지 큰 단점이 있습니다:

1. 각 도구 호출에는 언어 모델 호출이 필요합니다.
2. 언어 모델은 한 번에 하나의 하위 문제를 계획합니다. 이는 전체 작업에 대해 '추론'하지 않기 때문에 최적이 아닌 처리 궤적을 초래할 수 있습니다.

이 두 가지 단점을 극복하는 효과적인 방법은 명시적인 계획 단계를 포함하는 것입니다. 다음은 LangGraph에서 구현한 이러한 설계의 두 가지 예입니다.

계획-실행 시스템

프로그램 실행 에이전트

이 간단한 구조는 Wang 등의 논문을 기반으로 합니다.계획 및 해결 팁에서 제안하고 나카지마 요헤이의 [BabyAGI] 프로젝트에서 시작되었으며, 이는 전형적인 플래닝 에이전트 아키텍처가 되었습니다. 여기에는 두 가지 주요 기본 구성 요소가 포함되어 있습니다:

1. 플래너(A) 플래너)는 복잡한 작업에 대한 다단계 계획을 생성하도록 언어 모델(LLM)을 지시하는 역할을 담당합니다.
2. 여러 액추에이터(실행자()는 사용자의 쿼리 요구 사항과 계획의 단계를 처리하고 해당 작업을 수행하기 위해 하나 이상의 도구를 호출할 수 있습니다.

작업 실행이 완료되면 상담원에게 새로운 계획 프롬프트가 다시 표시되며, 이 시점에서 단순히 응답을 제공하여 작업을 종료할지 아니면 필요에 따라 추가 계획을 생성할지(원래 계획이 목표에 도달하지 못한 경우) 결정합니다.

이 에이전트 설계는 도구를 호출할 때마다 대규모 계획 언어 모델에 의존할 필요가 없습니다. 하지만 변수에 대한 할당 연산을 지원하지 않고 도구를 연속적으로 호출해야 하므로 각 작업마다 별도의 언어 모델이 필요합니다.

독립적인 관찰을 넘어선 추론

에서 [ReWOO] 연구에서 쉬 등은 각 작업이 대규모 언어 모델(LLM)에 의존해야 하는 기존의 방식을 뒤집어 후속 작업이 이전 작업의 결과에 의존할 수 있도록 하는 새로운 에이전트 모델을 고안했습니다. 이 모델은 출력 계획에 변수 할당 기능을 통합하여 구현됩니다. 다음 그림은 이 에이전트 모델의 설계를 보여줍니다.

ReWOO 에이전트 모델

플래너는 "계획"(추론)이 "E#" 줄과 번갈아 가며 포함된 계획 목록을 생성할 책임이 있습니다. 예를 들어 "올해 슈퍼볼 우승 후보의 쿼터백 통계는 무엇인가요?"라는 쿼리에 대해 플래너는 다음과 같은 계획을 생성할 수 있습니다:

계획: 올해 슈퍼볼에 출전하는 팀을 알아야 합니다.
E1: [누가 슈퍼볼에 출전하나요?]를 검색하세요. 계획: 모든 팀의 쿼터백이 누구인지 알아야겠어요.
E2: LLM [첫 번째 팀의 QB #E1] 계획: 각 팀의 QB가 누구인지 알아야 합니다.
E3: LLM [2팀 QB #E1] 계획: 첫 번째 쿼터백의 통계를 조회해야 합니다.
E4: [#E2의 QB 통계] 검색 계획: 두 번째 쿼터백의 통계를 조회해야 합니다.
E5: [#E3의 쿼터백 통계] 검색하기

플래너(플래너) `#E2`와 같은 구문을 통해 이전 출력을 참조할 수 있습니다. 즉, 매번 일정을 다시 잡을 필요 없이 일련의 작업을 수행할 수 있습니다.

"작업자(worker")" 노드는 각 작업을 반복하고 그 출력을 미리 결정된 변수에 할당합니다. 그리고 후속 작업 호출이 실행될 때 이러한 변수는 해당 결과로 대체됩니다.

궁극적으로 '해결사(솔버) "모든 출력을 통합하여 최종 답변에 도달합니다.

이 에이전트 설계 철학은 각 작업에 필요한 컨텍스트 정보(즉, 입력 및 변수 값)만 포함하므로 단순한 계획 실행 모델보다 더 효율적일 수 있습니다.

그러나 이 설계는 여전히 순차적 작업 실행을 기반으로 하므로 전체 실행 시간이 길어질 수 있습니다.

LLMCompiler

LLMCompiler 에이전트

LLMCompiler 의 조합입니다.팀 킴)는 앞서 설명한 ReWOO 에이전트를 사용한 계획 실행보다 작업 실행 효율을 개선하고 OpenAI 병렬 도구 호출보다 더 빠르게 작업 실행을 수행할 수 있도록 설계된 에이전트 아키텍처를 개발했습니다.

LLMCompiler는 다음과 같은 주요 부분으로 구성됩니다:

1. 플래너: 작업의 방향성 비순환 그래프(DAG)를 생성합니다. 각 작업에는 도구, 매개변수 및 종속성 목록이 포함됩니다.

2. TFU(작업 가져오기 단위) 작업 스케줄링 및 실행을 담당합니다. 작업 스트림을 수락하고 종속성이 충족되면 작업을 예약할 수 있습니다. 많은 도구가 추가 검색 엔진 또는 LLM 호출을 필요로 하기 때문에 이 병렬 실행을 통해 속도를 크게 향상시킬 수 있습니다(논문에 따르면 최대 3.6배).

3. 커넥터(조인너)작업 실행 결과를 포함한 작업 실행의 전체 이력을 기반으로 작업을 동적으로 다시 계획하거나 종료할 수 있는 부분입니다. 최종 결과를 직접 제시할지 아니면 추가 작업을 위해 진행 상황을 플래너에게 반환할지 결정하는 LLM 세션의 단계입니다.

구현을 가속화하기 위한 이 아키텍처의 핵심은 다음과 같습니다:

• 플래너의 출력은스트리밍작업 매개변수와 해당 종속성을 즉시 출력할 수 있습니다.
• 작업 획득 단위 스트리밍된 작업을 수신하고 모든 종속성이 충족되면 스케줄링을 시작합니다.
• 작업 매개 변수는 다음과 같습니다.변형즉, 방향성 비순환 그래프에서 이전 작업의 출력을 나타냅니다. 예를 들어, 모델은 다음과 같이 표현할 수 있습니다. search("${1}") 를 호출하여 작업 1에서 생성된 검색 콘텐츠를 쿼리합니다. 이 접근 방식을 사용하면 에이전트가 OpenAI의 일반적인 병렬 도구 호출보다 더 효율적으로 작업할 수 있습니다.

작업을 방향성 비순환 그래프로 구성하면 도구를 호출할 때 귀중한 시간을 절약할 수 있을 뿐만 아니라 더 나은 사용자 경험을 제공할 수 있습니다.

요약

이 세 가지 프록시 아키텍처는 Plan-Do 디자인 패턴의 프로토타입으로, LLM 기반 '플래너'를 도구 실행 런타임에서 분리합니다. 애플리케이션에서 도구 또는 API를 여러 번 호출해야 하는 경우 이러한 접근 방식을 사용하면 최종 결과를 얻는 데 걸리는 시간을 단축하고 상위 수준의 LLM에 대한 호출 횟수를 줄여 비용을 절감할 수 있습니다.