OpenAI의 인지 아키텍처에 대한 베팅

3주 전 OpenAI는 많은 기대를 모았던 개발자 데이를 개최했습니다. 그들은 수많은 새로운 기능들을 공개했습니다. 저에게 가장 흥미로웠던 두 가지는 Assistants API와 GPTs였습니다. 제 생각에 이 둘은 모두 특정하고 에이전트 같은, 폐쇄적인 “인지 아키텍처”에 대한 베팅을 나타냅니다. 이들은 서로 다른 최종 사용자들에게 어필하지만, 둘 다 애플리케이션들을 이 특정한 인지 아키텍처로 이끌고자 하는 OpenAI의 야망을 보여줍니다. LangChain에서는 LLM이 진정으로 혁신적인 에이전트 같은 시스템에 동력을 공급하는 세상을 믿습니다. 하지만 우리는 그곳에 도달하는 경로는 기업들이 자신들의 인지 아키텍처를 통제할 수 있는 길이라고 생각합니다. 여러분은 OpenGPTs와 같은 프로젝트를 통해 오늘날 그것을 할 수 있습니다. 이는 Assistants API(그리고 GPTs)의 개방적이고, 편집 가능하며, 구성 가능한 버전입니다.

GPTs 및 Assistants API

둘 중에서는 GPTs가 인터넷에서 더 일반적으로 논의되는 편일 것입니다. 이들은 자신만의 “GPT”를 만들 수 있는 (대부분) 노코드 방식을 제공합니다. 이러한 GPTs는 사용자 지정 지침(custom instructions), 사용자 지정 지식(custom knowledge), 그리고 사용자 지정 함수(custom functions)로 맞춤 설정될 수 있습니다. 이 GPTs는 플러그인(Plugins, 샘 올트만(Sam Altman)의 말에 따르면 제품 시장 적합성(product market fit)을 찾지 못했던)에 이어 일종의 앱 스토어 재도전처럼 보입니다.

Assistants API는 이러한 아이디어의 개발자 중심적인 버전입니다. Assistants API는 이전 메시지를 저장하고, 파일을 업로드하며, 내장된 도구(코드 인터프리터)에 접근할 수 있는 상태 유지형(stateful) API이며, 함수 호출(function calling)을 통해 다른 도구를 제어하는 데 사용될 수 있습니다. 이 과정에서 개발자는 호출해야 할 함수를 지정하고, 이는 클라이언트 측에서 실행될 수 있습니다.

인지 아키텍처 (Cognitive Architectures)

내부적으로 볼 때, 이 둘은 모두 유사한 유형의 “인지 아키텍처”를 나타냅니다. 여기서 저는 인지 아키텍처라는 용어를 LLM 애플리케이션의 오케스트레이션(orchestration)을 설명하는 데 사용합니다. 제가 이 용어를 처음 들은 곳은 Flo Crivello(자율 에이전트 스타트업인 Lindy의 창립자)가 사용한 것이었고, 저는 이것이 환상적인 용어라고 생각합니다.

💡

가장 흥미로운 LLM 애플리케이션들은 컨텍스트 인식 추론(context-aware reasoning) 애플리케이션으로 설명될 수 있습니다. 여기에는 두 가지 주요 구성 요소가 있습니다. (1) 애플리케이션에 컨텍스트를 어떻게 제공하는지, 그리고 (2) 애플리케이션이 어떻게 ‘추론’하는지입니다. 이 두 구성 요소가 애플리케이션의 인지 아키텍처(cognitive architecture)를 구성합니다.

LangChain에서는 오랫동안 인지 아키텍처에 대해 고민해 왔습니다. 최근 TedAI 강연(영상은 아직 공개되지 않음)에서 저는 개발자들이 구축하는 다양한 수준의 인지 아키텍처에 대해 이야기했습니다. 여기에는 다음이 포함됩니다:

• 단일 LLM 호출: 애플리케이션의 출력만을 결정함
• LLM 호출 체인: 여전히 애플리케이션의 출력만을 결정함
• 라우터(router)로서의 LLM 사용: 어떤 액션(도구, 검색기(retriever), 프롬프트)을 사용할지 선택함
• 상태 기계(State machines): LLMs를 사용하여 단계 간에 경로를 지정하고, 일종의 루프 내에서 작동하지만 여전히 코드에 열거된 허용 가능한 전이 옵션을 가짐
• 에이전트(Agents): 많은 스캐폴딩(scaffolding)을 제거하여 전이 옵션이 LLM 자체에 의해 완전히 결정되도록 함

에이전트 (Agents)

Assistants API와 GPT 모두 위에서 설명한 ‘에이전트’ 인지 아키텍처의 예시입니다. Sam Altman은 이들을 발표할 때도 정확히 그 용어(‘agent’)를 사용했습니다. 비록 에이전트가 수많은 다양한 애플리케이션을 설명하는 데 사용되어 과부하된 용어일 수는 있지만, OpenAI가 이 용어를 사용하는 방식은 대체로 저희의 이해와 일치합니다. 즉, LLM만을 사용하여 전이 옵션을 정의한다는 것입니다.

실제로는 이런 애플리케이션들이 어떻게 생겼을까요? 이것은 루프(loop)로 생각하는 것이 가장 좋습니다. 사용자 입력이 주어지면, 이 루프가 시작됩니다. 그런 다음 LLM이 호출되어 사용자에게 대한 응답이 나오거나 OR 취해야 할 액션(action)이 나옵니다. 만약 응답이 필요하다고 결정되면, 그것이 사용자에게 전달되고 그 사이클은 끝납니다. 액션이 필요하다고 결정되면, 그 액션이 수행되고 관찰값(observation, 즉 액션 결과)이 생성됩니다. 이 액션과 해당 관찰값이 프롬프트에 다시 추가됩니다 (우리는 이것을 '에이전트 스크래치패드(agent scratchpad)'라고 부릅니다). 그리고 루프가 재설정되어, LLM이 다시 호출됩니다 (업데이트된 에이전트 스크래치패드를 가지고).

높은 수준에서 볼 때, GPTs가 하는 일이 바로 이것입니다. 사용자가 제공한 도구(tool)나 검색(retrieval), 코드 인터프리터 같은 내장 도구를 호출할 때, 화면에 돌아가는 위젯이 보일 수 있습니다. 이것은 취해지고 있는 액션을 나타내며, GPT는 관찰값을 기다리고 있습니다. 어떤 시점에서는 단순히 텍스트로 응답만 하고—취해야 할 액션은 없고—루프가 끝납니다.

Assistants API도 마찬가지입니다. 유일한 차이점은 API가 도구를 자동으로 호출해주지 않는다는 것입니다 (검색이나 코드 인터프리터 같은 내장 도구가 아니라면). 대신, 어떤 유형의 메시지로 응답하여 어떤 도구(들)를 호출해야 하는지 (그리고 해당 도구들의 입력값은 무엇이어야 하는지) 알려주고, 그 다음 클라이언트 측에서 사용자가 직접 도구를 호출하고 결과를 다시 전달할 때까지 기다립니다.

이러한 “에이전트(agent)” 인지 아키텍처는 지난 1년 반 동안 진화해 왔습니다. AI21 Labs가 MRKL 논문을 발표한 것은 1년 반 전입니다. ReAct 프롬프팅 전략(ReAct prompting strategy) (1년 전에 발표됨)은 이러한 유형의 아키텍처를 가능하게 하는 특정 유형의 프롬프팅 전략이었습니다. 저희는 약 1년 전에 LangChain에 ReAct를 통합했으며, 빠르게 더 일반적인 제로샷(zero-shot) 프롬프팅 전략으로 확장했습니다. AutoGPT는 약 9개월 전에 등장했는데, 이와 동일한 인지 아키텍처를 사용하지만 더 많은 도구, 더 영속적인 메모리(persistent memory), 그리고 일반적으로 완료해야 할 더 큰 작업을 부여받았습니다.

OpenAI가 거는 베팅 (The Bet OpenAI is Making)

저는 모든 면에서 볼 때 이 인지 아키텍처가 심각한 애플리케이션에 충분히 신뢰할 수 있지 않다는 점을 감안할 때, OpenAI가 에이전트에 얼마나 크게 의존하는지 보는 것에 매우 흥미를 느꼈습니다. 그들은 근본적인 모델(underlying model)을 통제하고 있기 때문에 이 작업을 성공시킬 가장 좋은 위치에 있습니다. 하지만 이것은 여전히 베팅입니다. 그들은 시간이 지남에 따라 에이전트들을 괴롭히는 문제들이 사라질 것이라고 베팅하고 있는 것입니다.

실제로 유용하다고 볼 수 있는 “자율 에이전트(autonomous agents)”의 거의 모든 것은 두 가지 핵심적인 면에서 차이가 납니다.

첫째, 많은 것들이 실제로 이 “에이전트” 인지 아키텍처가 아니라, 오히려 정교하고 복잡한 체인(chain)이거나 또는 “상태 머신(state machines)”과 더 유사합니다. 이에 대한 두 가지 훌륭한 공개 예시는 GPT-Researcher와 Sweep.dev입니다.

저희는 GPT-Researcher에 대해 여러 번 길게 작성했으며, 지난주에는 LangChain 템플릿을 출시하기 위해 그들과 협력했습니다. 이들은 가치 있는 결과를 산출하는 몇 안 되는 복잡한 LLM 기반 애플리케이션 중 하나이지만, 그들의 인지 아키텍처는 더 복잡한 체인과 같습니다. 아래 다이어그램을 보면 한 방향으로 흐르는 것을 볼 수 있습니다. 많은 복잡한 단계를 거치지만, 정의된 방식으로 진행됩니다: 먼저 하위 질문(sub questions)을 생성하고, 다음 각 질문에 대한 링크를 가져온 후, 각 링크를 요약하고, 마지막으로 이 요약들을 연구 보고서로 결합합니다.

Sweep.dev도 또 다른 훌륭한 예시입니다. 그들은 여름 동안 자신들의 인지 아키텍처를 설명하는 블로그 글을 작성했으며, 환상적인 다이어그램까지 포함하고 있습니다.

명확하게 정의된 전환(transitions)과 단계들이 존재합니다. 먼저 검색이 수행됩니다. 다음으로 계획이 생성됩니다. 그리고 그 계획이 실행됩니다. 이후 검증 단계가 있습니다. 만약 통과하면 PR(Pull Request)을 만들고 Sweep을 완료합니다. 만약 실패하면 새로운 계획을 세웁니다. 이는 서로 다른 상태들 사이에 잘 정의된 전환들이 있는, 상당히 명확한 상태 기계(state machine)입니다.

저희가 함께 작업하는 많은 빌더들과 팀들은 자신들의 애플리케이션에 복잡한 체인/상태 기계를 동력으로 사용하고 있습니다.

💡

이러한 인지 아키텍처의 이점은 간단합니다: **더 많은 제어(control)**입니다. 어떤 두 문제도 같지 않기 때문에, 문제 공간에 맞는 적절한 인지 아키텍처를 선택하는 것이 좋은 경험을 제공하는 데 매우 중요합니다.

이러한 에이전트 아키텍처와 더 유사하게 무언가를 사용하는 애플리케이션의 경우, GPT들과는 또 다른 방식으로 차이가 나는데, 바로 에이전트에게 컨텍스트가 어떻게 제공되는지입니다.

저는 Flo Crivello와 인지 아키텍처에 대해 대화했는데, 그는 에이전트 아키텍처에서 한 가지 차이점은 컨텍스트를 에이전트에게 제공하는 방식이라고 언급했습니다. 우리가 흥미로운 LLM 애플리케이션의 대부분을 설명하는 방식이 '컨텍스트 인식 추론(context-aware reasoning) 애플리케이션'이라는 것을 기억하세요.

💡

컨텍스트는 풀링(pulling) 방식으로 제공되거나 푸싱(pushing) 방식으로 제공될 수 있습니다. 가장 성능이 좋고 신뢰할 수 있는 에이전트들에서는 푸싱을 통해 상당한 양의 컨텍스트가 제공되는 것을 볼 수 있습니다.

에이전트가 컨텍스트를 **풀(pull)**한다는 것은 무엇을 의미할까요? 이는 에이전트가 자신이 어떤 컨텍스트가 필요한지 결정하고, 그 컨텍스트를 요청한다는 것을 의미합니다. 이것은 일반적으로 도구(tool)를 통해 이루어집니다. 구체적인 예로, SQL 데이터베이스와 상호 작용하도록 만들어진 에이전트는 해당 SQL 데이터베이스에 어떤 테이블들이 존재하는지 알아야 할 수 있습니다. 따라서 저희는 데이터베이스의 테이블 목록을 반환하는 도구를 제공할 수 있고, 에이전트는 그 도구를 시작 시점에 호출할 수 있습니다.

반면, 컨텍스트가 언어 모델로 **푸시(pushed)**될 때는 특정 컨텍스트 조각을 가져와 프롬프트에 삽입해야 하는 애플리케이션의 로직 내에서 인코딩됩니다. 위 SQL 에이전트 예시의 경우, 이는 미리 SQL 테이블들을 자동으로 가져와 프롬프트에 삽입하는 것에 해당합니다.

에이전트 아키텍처를 사용하는 대부분의 애플리케이션은 상당한 양의 푸시된 컨텍스트를 사용합니다. 한 가지 예로, LangChain의 SQL 및 Pandas 에이전트는 시스템 메시지의 일부로 테이블 스키마를 가지고 있습니다. 또 다른 예로는 Rubrics 팀이 Cal.com을 위해 구축한 에이전트가 프롬프트에 상당한 양의 사용자 정보를 푸시하는 경우입니다.

컨텍스트의 이러한 푸시 대 풀(push vs pull) 방식은 개발자에게 다시 한번 더 많은 제어권을 제공합니다. 이는 무엇을 할지 결정할 때 어떤 컨텍스트가 LLM에 관련성이 있는지 강제할 수 있게 해줍니다. 구체적으로, 어떤 컨텍스트가 가장 관련성이 높은지, 그 컨텍스트를 어떻게 가져올지, 그리고 그것을 어떻게 제공할지는 품질과 성능에 큰 영향을 미칠 수 있는 사소한 결정들입니다.

GPTs—그리고 어느 정도는 Assistant API도—은 필요할 때 컨텍스트를 풀(pull)하는 것에 더 의존하는 제약 없는 에이전트 아키텍처로 애플리케이션을 크게 강화합니다. 이는 빠르게 시작하거나 간단한 작업에는 좋을 수 있지만, 더 복잡한 사용 사례의 경우 당면한 문제에 적합한 인지 아키텍처를 제어하는 것에는 대안이 없습니다.

오픈(Open) vs 클로즈드(Closed)

인지 아키텍처 선택 외에도, Assistants API와 GPTs의 또 다른 주목할 만한 속성은 인지 아키텍처 자체가 **클로즈드(closed)**하다는 것입니다. 우리는 내부에서 무슨 일이 일어나고 있는지 알지 못합니다. 정확한 알고리즘을 알지 못합니다. 채팅 기록의 컨텍스트를 관리하기 위해 무엇이 수행되고 있는지 알지 못합니다. 검색에 대해 무엇이 수행되고 있는지 알지 못합니다.

현재로서는 이 두 가지 모두 추측할 수 있습니다. 하지만 이것들이 점점 더 추가되고, 점점 더 복잡해짐에 따라, 이는 점차 블랙박스가 될 것입니다.

💡

오픈 소스 대 폐쇄형(closed-source)에 대한 논의는 주로 모델 자체를 중심으로 이루어집니다. 하지만 고려해야 할 또 다른 요소가 있습니다: 오픈 소스 인지 아키텍처 대 폐쇄형 인지 아키텍처입니다.

시간이 지나면서, 저는 이것이 모델 자체보다 더 큰 논의 주제가 될 것이라고 예상합니다. 1년 전만 해도 대부분의 새로운 기능(그리고 내부적으로도 대부분의 초점은) 더 나은 모델에 맞춰져 있었습니다. 이제는 핵심 모델 개선과 에이전트적인 방식으로 이를 가장 잘 연결하는 방법을 찾는 것 사이에서 50대 50으로 나뉘는 것 같습니다. 이러한 중요성에 대한 증거가 쌓일수록, Karpathy의 트위터 피드(AGI 관련 모든 것에 대한 결정적인 읽기 목록)는 LLM을 OS로 보는 이 아이디어 쪽으로 점점 더 이동하고 있습니다. 지난 주말 동안 그는 바로 그 주제에 대한 환상적인 비디오를 공개했습니다.

저는 이러한 추세가 계속될 것이고, OpenAI(그리고 아마도 다른 연구소들)가 모델 자체보다는 모델 주변의 플랫폼과 툴링에 더 투자할 것으로 예상합니다. AGI로 가는 길은 (단지) 더 나은 모델에 있는 것이 아니라—주변 환경에 이를 연결하는 데에도 있습니다. 이러한 연구소들의 초점이 이동함에 따라, 저는 오픈 대 폐쇄에 대한 논의가 단순히 모델뿐만 아니라 인지 아키텍처에 대해서도 이루어질 것으로 예상하고 바랍니다.

인지 아키텍처가 맥주 맛을 좋게 만드나요?