"에이전트란 무엇인가?"
나는 이 질문을 거의 매일 받는다. LangChain에서는 개발자들이 LLM 애플리케이션을 구축하도록 도와주는 도구를 만드는데, 특히 추론 엔진으로 작용하고 외부 데이터 및 계산 소스와 상호작용하는 것들이다. 이는 일반적으로 "에이전트"라고 불리는 시스템을 포함한다.
모두가 AI 에이전트가 무엇인지에 대해 약간 다른 정의를 가지고 있는 것 같다. 내 정의는 아마도 대부분보다 더 기술적이다:
💡
AI 에이전트는 LLM을 사용하여 애플리케이션의 제어 흐름을 결정하는 시스템이다.
여기서도 내 정의가 완벽하지 않다는 것을 인정해야 한다. 사람들은 종종 에이전트를 고급스럽고, 자율적이며, 인간 같은 것으로 생각한다. 그러나 LLM이 두 가지 다른 경로 사이를 라우팅하는 간단한 시스템은 어떨까? 이는 내 기술적 정의에 맞지만, 에이전트가 무엇을 할 수 있어야 한다는 일반적인 인식에는 맞지 않는다. 에이전트가 정확히 무엇인지 정의하기는 어렵다!
그래서 나는 Andrew Ng의 지난주 트윗을 정말 좋아했다. 그 안에서 그는 "어떤 작업을 진정한 AI 에이전트로 포함시킬지 제외할지에 대해 논쟁하기보다는, 시스템이 에이전트적일 수 있는 정도가 다양하다는 것을 인정할 수 있다"고 제안한다. 예를 들어 자율 주행 자동차가 자율성의 수준을 가지고 있듯이, 우리는 AI 에이전트의 능력을 스펙트럼으로 볼 수도 있다. 나는 이 관점에 정말 동의하고 Andrew가 이것을 잘 표현했다고 생각한다. 앞으로 에이전트가 무엇인지에 대해 질문을 받을 때, 나는 대신 "에이전트적"이 무엇을 의미하는지에 대해 논의하도록 대화를 돌릴 것이다.
에이전트적이라는 것은 무엇을 의미하는가?
나는 지난해 LLM 시스템에 대한 TED 강연을 했고, LLM 애플리케이션에 있는 자율성의 다양한 수준을 설명하기 위해 아래 슬라이드를 사용했다.
LLM이 시스템이 어떻게 행동할 수 있는지 결정할수록 시스템은 더 "에이전트적"이다.
LLM을 사용하여 입력을 특정 다운스트림 워크플로우로 라우팅하는 것은 약간의 "에이전트적" 행동을 가진다. 이는 위의 다이어그램의 Router 범주에 속할 것이다.
여러 LLM을 사용하여 여러 라우팅 단계를 수행한다면? 이는 Router와 State Machine 사이 어딘가에 있을 것이다.
그 단계 중 하나가 계속할지 또는 마칠지를 결정하는 것이라면 - 효과적으로 시스템이 완료될 때까지 루프에서 실행되도록 허용한다면? 그것은 State Machine에 속할 것이다.
시스템이 도구를 구축하고, 그것들을 기억하고, 그 다음 단계에서 그것들을 사용한다면? 그것은 Voyager 논문이 구현한 것과 유사하며, 매우 에이전트적이며, 더 높은 Autonomous Agent 범주에 속한다.
"에이전트적"의 이러한 정의들은 여전히 상당히 기술적이다. 나는 "에이전트적"의 더 기술적인 정의를 선호한다. 왜냐하면 LLM 시스템을 설계하고 설명할 때 유용하다고 생각하기 때문이다.
"에이전트적"이 왜 도움이 되는 개념인가?
모든 개념과 마찬가지로, 우리가 왜 "에이전트적"이라는 개념이 필요한지 묻는 것은 가치가 있다. 그것이 무엇을 도와줄까?
당신의 시스템이 얼마나 에이전트적인지 아는 것은 개발 프로세스 중 결정 내리기를 안내할 수 있다 - 그것을 구축하기, 실행하기, 상호작용하기, 평가하기, 그리고 모니터링하기를 포함하여.
당신의 시스템이 더 에이전트적일수록, 오케스트레이션 프레임워크가 더 도움이 될 것이다. 복잡한 에이전트적 시스템을 설계하는 경우, 이러한 개념을 생각하기 위한 올바른 추상화를 가진 프레임워크가 있으면 더 빠른 개발을 가능하게 할 수 있다. 이 프레임워크는 분기 논리와 사이클에 대한 최상위 지원을 가져야 한다.
당신의 시스템이 더 에이전트적일수록, 실행하기가 더 어렵다. 그것은 점점 더 복잡해질 것이고, 완료하는 데 오랜 시간이 걸릴 일부 작업을 가질 것이다. 이는 당신이 백그라운드 실행으로 작업을 실행하길 원할 것을 의미한다. 이는 또한 당신이 도중에 발생하는 모든 오류를 처리하기 위해 내구성 있는 실행을 원한다는 것을 의미한다.
당신의 시스템이 더 에이전트적일수록, 실행 중에 그것과 상호작용하길 원할 것이다. 정확한 단계가 미리 알려지지 않을 수 있으므로, 당신은 내부에서 무엇이 일어나고 있는지 관찰할 수 있는 능력을 원할 것이다. 당신은 특정 시점에 에이전트의 상태나 명령을 수정할 수 있는 능력을 원할 것이다. 의도된 경로에서 벗어나고 있다면 그것을 다시 궤도에 올리기 위해.
당신의 시스템이 더 에이전트적일수록, 이러한 유형의 애플리케이션을 위해 구축된 평가 프레임워크를 더 원할 것이다. 누적된 무작위성의 양이 있으므로, 당신은 평가를 여러 번 실행하길 원할 것이다. 당신은 최종 출력뿐만 아니라 중간 단계도 테스트할 수 있는 능력을 원할 것이다. 에이전트가 얼마나 효율적으로 행동하는지 테스트하기 위해.
당신의 시스템이 더 에이전트적일수록, 새로운 유형의 모니터링 프레임워크를 더 원할 것이다. 당신은 에이전트가 취하는 모든 단계를 자세히 살펴볼 수 있는 능력을 원할 것이다. 당신은 또한 에이전트가 취하는 단계를 기반으로 실행을 쿼리할 수 있는 능력을 원할 것이다.
당신의 시스템에서 에이전트적 능력의 스펙트럼을 이해하고 활용하면 당신의 개발 프로세스의 효율성과 견고성을 개선할 수 있다.
에이전트적은 새롭다
나는 종종 이 모든 열풍에서 실제로 무엇이 새로운지에 대해 생각한다. 우리는 사람들이 구축하는 LLM 애플리케이션을 위해 새로운 도구와 새로운 인프라가 필요한가? 아니면 LLM 이전 시대의 일반적인 도구와 인프라로 충분할 것인가?
내 생각에, 당신의 애플리케이션이 더 에이전트적일수록, 새로운 도구와 인프라를 가지는 것이 더 중요하다. 그것이 정확히 우리가 LangGraph(에이전트 빌딩, 실행, 그리고 상호작용을 도와주는 에이전트 오케스트레이터)와 LangSmith(LLM 앱을 위한 테스팅 및 관찰성 플랫폼)를 구축하도록 동기를 부여한 것이다. 우리가 에이전트적 스펙트럼에서 더 나아갈수록, 지원 도구의 전체 생태계를 다시 상상해야 한다.