Plan-and-Execute 에이전트 소개

요약: 저희는 'Plan-and-Execute'라는 새로운 유형의 에이전트 실행기(agent executor)를 도입합니다. 이는 이전에 지원했던 'Action' 에이전트와 대조됩니다. Plan-and-Execute 에이전트는 BabyAGI와 최근의 Plan-and-Solve 논문에서 큰 영감을 받았습니다. 저희는 Plan-and-Execute가 더 복잡한 장기 계획에 매우 유용하지만, 언어 모델(language model) 호출 횟수가 늘어나는 단점이 있다고 생각합니다. 현재 빠른 변화가 예상되므로 초기 버전은 실험적 모듈(experimental module)에 배치할 예정입니다.**

링크:

지금까지 LangChain의 모든 에이전트는 ReAct 논문에서 개척한 프레임워크를 따랐습니다. 이를 'Action Agents'라고 부르겠습니다. 이들의 알고리즘은 대략 다음과 같은 의사 코드(pseudo-code)로 표현할 수 있습니다:

• 사용자 입력 일부가 수신됩니다.
• 에이전트는 어떤 도구(tool)를 사용할지, 그리고 그 도구의 입력값이 무엇이어야 할지 결정합니다.
• 해당 도구가 이 입력값으로 호출되고, 관찰(observation)이 기록됩니다 (이는 해당 도구를 해당 입력값으로 호출한 결과물일 뿐입니다).
• 도구, 도구 입력값, 관찰의 이력이 에이전트에게 다시 전달되며, 에이전트는 다음에 어떤 단계를 밟을지 결정합니다.
• 이는 에이전트가 더 이상 도구를 사용할 필요가 없다고 판단할 때까지 반복되며, 그 후 사용자에게 직접 응답합니다.

이 방식은 지금까지 잘 작동해 왔지만, 몇 가지 변화하는 요소들로 인해 이 알고리즘에 균열이 생기고 있습니다:

• 사용자 목표(User objectives)가 점점 더 복잡해지고 있습니다.
• 개발자와 조직들이 프로덕션 환경에서 에이전트에 의존하기 시작했습니다.

이 두 가지 요인은 에이전트 시스템이 더 복잡한 요청을 처리할 수 있어야 한다는 요구와 동시에, 더욱 신뢰성이 높아야 한다는 요구를 가져옵니다. 이 두 요소가 결합하면서 프롬프트 크기가 급격히 증가하고 있습니다:

• 목표가 복잡해질수록, 에이전트가 최종 목표에 집중하도록 유지하는 동시에 이전 단계를 기억하고 추론할 수 있도록 점점 더 많은 과거 기록을 포함하게 됩니다.
• 개발자들이 신뢰성을 높이려고 하면서 도구를 사용하는 방법에 대한 지침을 더 많이 포함시키고 있습니다.

점점 더 복잡한 능력과 증가된 신뢰성은 대부분의 언어 모델(LLM)로 작업할 때 문제를 야기하고 있습니다.

Plan-and-Execute 구현

이러한 맥락에서 우리는 새로운 스타일의 에이전트 프레임워크가 등장하는 것을 목격했습니다. 이러한 에이전트 프레임워크는 고수준 계획(higher level planning)을 단기 실행(shorter term execution)과 분리하려고 시도합니다. 구체적으로, 먼저 수행할 단계를 계획한 다음, 그 단계들을 반복적으로 실행합니다. 물론 이 핵심 알고리즘에는 몇 가지 흥미로운 변형들이 있습니다(나중에 논의할 수 있습니다). 우리가 “Plan-and-Execute” 에이전트라고 부르는 이러한 에이전트의 의사 코드는 다음과 같습니다:

• 수행할 단계 계획하기
• steps에 대한 각 step에 대해: 해당 단계를 달성하는 데 적절한 도구 또는 최선의 조치 결정하기

이것이 Python과 TypeScript로 구현된 핵심 에이전트 프레임워크입니다. 이 에이전트 프레임워크는 두 가지에 의존합니다: 플래너(planner)와 실행기(executor).

먼저 플래너에 대해 이야기해 보겠습니다. 이것은 거의 항상 언어 모델이어야 합니다. 이는 언어 모델의 추론 능력을 활용하여 무엇을 할지 계획하고 모호성/경계 사례를 처리할 것입니다. 우리는 끝에 출력 파서(output parser)를 추가하여 원시 LLM 출력을 문자열 목록(각 문자열이 하나의 단계임)으로 구문 분석할 수 있습니다.

이제 실행기에 대해 이야기해 보겠습니다. 초기 구현에서 우리는 이것을 액션 에이전트(Action Agent)로 만들었습니다. 이를 통해 실행기 에이전트는 고수준 목표(단일 단계)를 입력받아 그것을 달성하는 데 어떤 도구를 사용해야 할지 파악할 수 있습니다(하나의 단계 또는 두 단계에 걸쳐 수행될 수 있음).

이 접근 방식은 여러 가지 장점을 가지고 있습니다. 계획(planning)과 실행(execution)을 분리할 수 있다는 점입니다. 이는 하나의 LLM이 오직 계획에만 집중하고, 다른 LLM이 실행에 집중하도록 할 수 있게 합니다. 이로 인해 양쪽 모두에서 더 높은 신뢰성을 확보할 수 있습니다. 또한 미래에 이러한 구성 요소들을 작게 미세 조정된(fine tuned) 모델들로 교체하기가 더 쉬워집니다. 이 접근 방식의 주요 단점은 호출 횟수가 훨씬 많다는 것입니다. 하지만 관심사의 분리 덕분에, 이러한 호출들이 더 작고 (따라서 더 빠르고 저렴한) 모델들에게 이루어질 수 있기를 기대합니다.

향후 방향(Future Directions)

저희는 이것이 계획-실행 에이전트의 시작에 불과하다고 생각합니다. 향후 방향에는 다음과 같은 것들이 포함됩니다:

• 긴 단계 시퀀스에 대한 개선된 지원. 현재 이전 단계들은 리스트 형태로 전달됩니다. 하지만 계획 단계가 점점 길어짐에 따라, 이를 벡터 스토어(vectorstore)에 저장하고 중간 단계를 검색할 수 있기를 바랍니다.
• 계획 재검토(Revisiting plans). 현재는 시작 시점에 하나의 계획 단계만 존재하지만, 이후에는 이 계획을 재검토하고 조정하는 메커니즘이 필요할 가능성이 높습니다. 이는 매 단계마다 또는 필요할 때 수행될 수 있습니다.
• 평가(Evaluation). 현재 이러한 개선 사항들 중 상당수는 대체로 이론적이거나, 적어도 벤치마킹되지 않았습니다. 저희는 에이전트 프레임워크를 평가하는 더 엄격한 방법들을 갖기를 희망합니다.
• 실행 체인 선택(Selection of execution chain). 현재는 단일 실행 체인이 있습니다. 하지만 여러 개의 실행 체인을 원할 수도 있고, 계획기(planner)가 어떤 것을 사용할지 지정할 수 있어야 할 수도 있습니다. 예를 들어, 웹 리서치에 최적화된 실행 체인 하나와 분석에 최적화된 실행 체인 하나를 가질 수 있습니다.

이러한 향후 방향들 중 많은 부분에서 기존 연구로부터 영감을 얻을 수 있다는 점을 주목해야 합니다. 예를 들어, BabyAGI는 이미 중간 단계를 저장하기 위해 벡터 스토어를 사용하며, 매 반복마다 계획을 재검토합니다. Plan-and-Solve 논문은 벤치마크를 사용하여 출력에 대해 더 엄격한 평가를 수행합니다.

결론

우리는 BabyAGI에서 이 새로운 에이전트 패러다임이 등장한 것을 매우 기대했습니다(몇 주 전 게시물에서 주요 차별점 중 하나로 강조했습니다). Plan-and-Solve 논문이 유사한 아이디어에 대한 엄격한 평가로 나타난 것 역시 마찬가지로 기뻤습니다. 저희는 Plan-and-Execute 접근 방식이 어떻게 발전할지 기대하며, 여기(Python) 또는 여기(JS)에서 직접 사용해 보시기 바랍니다.