에이전트를 위한 가장 완벽한 플레이북: 시나리오, 메모리 및 인터랙티브 혁신

지유, 케이지 편집

AI 에이전트는 우리가 면밀히 추적하고 있는 패러다임의 변화이며, 일련의 Langchain 기사는 에이전트의 트렌드를 이해하는 데 도움이 됩니다. 트렌드를 이해하는 데 도움이 됩니다. 그 첫 번째 편은 Langchain 팀에서 발표한 AI 에이전트 현황 보고서입니다. 개발자, 제품 관리자, 기업 임원 등 1,300명 이상의 실무자를 인터뷰하여 올해 에이전트의 현황과 랜딩의 병목현상에 대해 밝혔습니다: <강>90%의 기업이 AI 에이전트에 대한 계획과 니즈가 있지만 에이전트의 기능 한계로 인해 일부 프로세스 및 시나리오에서만 랜딩할 수 있는 상황입니다. 사람들은 비용과 지연 시간에 비해 에이전트의 기능 향상과 행동에 대한 관찰 및 제어 가능성에 더 큰 관심을 갖고 있습니다.

두 번째 파트에서는 LangChain 웹사이트에 게재된 In the Loop 시리즈 기사 중 계획 기능, UI/UX 상호작용 혁신, 메모리 메커니즘에서 AI 에이전트의 핵심 요소에 대한 분석을 정리했습니다. 이 기사에서는 5개의 LLM 네이티브 제품의 상호작용을 분석하고 인간의 복잡한 기억 메커니즘을 3가지로 비유하여 AI 에이전트를 이해하고 이러한 핵심 요소를 이해하는 데 영감을 줍니다. 이 섹션에서는 2025년 AI 에이전트의 주요 혁신을 미리 살펴보기 위해 Reflection AI의 창립자와의 인터뷰 등 대표적인 에이전트 기업의 사례 연구도 포함하고 있습니다.

이 분석 프레임워크에 따르면 2025년에는 인간과 컴퓨터의 협업이라는 새로운 패러다임으로 나아가는 AI 에이전트 애플리케이션이 등장하기 시작할 것으로 예상됩니다. AI 에이전트의 기획 능력에 있어서는 o3가 주도하는 모델들이 강력한 반영 및 추론 능력을 보여주고 있으며, 모델 기업들의 발전은 추론자에서 에이전트 단계로 접근하고 있습니다. 추론 능력이 계속 향상됨에 따라 에이전트의 '마지막 1km'는 제품 상호작용과 기억 메커니즘이 될 것이며, 이는 스타트업에게 획기적인 기회가 될 가능성이 높습니다. 인터랙션과 관련해서는 AI 시대의 'GUI 순간'을, 메모리와 관련해서는 컨텍스트가 에이전트 랜딩의 키워드가 될 것이며, 개인 수준에서의 컨텍스트 개인화와 기업 수준에서의 컨텍스트 통합이 에이전트의 제품 경험을 크게 개선할 것으로 예상합니다.

01. 상담원 사용 추세:

모든 기업이 상담원 배포를 계획하고 있습니다

모든 기업이 상담원 배치 계획. 상담원 배치 계획

상담원 분야는 점점 더 경쟁이 치열해지고 있습니다. 지난 한 해 동안 추론 및 액션을 위해 LLM과 결합된 ReAct를 사용하거나 오케스트레이션을 위해 멀티 에이전트 프레임워크를 사용하거나 LangGraph와 같은 보다 제어된 프레임워크를 사용하는 등 여러 에이전트 프레임워크가 인기를 얻었습니다.

트위터에서 에이전트에 대한 논의가 모두 과대 포장된 것은 아닙니다. 응답자의 약 51%가 현재 프로덕션 환경에서 에이전트를 사용하고 있으며, 기업 규모별 Langchain 데이터에 따르면 직원 수 100~2,000명의 중견 기업이 63%로 가장 적극적으로 에이전트를 프로덕션에 도입하고 있는 것으로 나타났습니다.

또한 응답자의 78%는 가까운 시일 내에 에이전트를 프로덕션에 도입할 계획이 있다고 답했습니다. AI 에이전트에 대한 관심이 높은 것은 분명하지만, 실제로 프로덕션에 적합한 에이전트를 도입하는 것은 여전히 많은 이들에게 어려운 과제입니다.

기술 업계는 종종 얼리 어답터로 간주되지만 에이전트에 대한 관심은 모든 업계에서 증가하고 있습니다. 비기술 기업에서 근무하는 응답자의 90%가 이미 에이전트를 도입했거나 도입할 계획이라고 답해 기술 기업과 거의 동일한 비율인 89%를 기록했습니다.

일반적인 에이전트 사용 사례

에이전트의 가장 일반적인 사용 사례는 조사 및 요약(58%)이었으며, 맞춤형 에이전트로 워크플로우 간소화(58%)가 그 뒤를 이었습니다. 맞춤형 에이전트를 통한 워크플로 간소화(53.5%)가 그 뒤를 이었습니다.

시간이 너무 많이 소요되는 작업을 처리할 수 있는 제품에 대한 요구가 반영된 결과입니다. 사용자는 방대한 양의 데이터를 직접 살펴보고 프로필 검토나 연구 분석을 수행하는 대신 AI 에이전트를 통해 방대한 양의 정보에서 핵심 정보와 인사이트를 추출할 수 있습니다. 마찬가지로 AI 에이전트는 일상적인 업무를 지원하여 사용자가 중요한 일에 집중할 수 있도록 함으로써 개인의 생산성을 높일 수 있습니다.

이러한 효율성 향상이 필요한 것은 개인뿐만 아니라 기업과 팀도 마찬가지입니다. 고객 서비스(45.8%)는 기업이 문의를 처리하고 문제를 해결하며 팀 전체의 고객 응답 시간을 단축하는 데 도움이 되는 에이전트의 또 다른 주요 애플리케이션이며, 4위와 5위는 하위 수준의 코드 및 데이터 애플리케이션이 차지했습니다.

모니터링: 에이전트 애플리케이션에는 통합 가시성과 제어 기능이 필요합니다

에이전트 구현이 더욱 강력해지면서 에이전트를 관리하고 모니터링할 방법이 필요해졌습니다. 추적 및 통합 가시성 도구는 개발자가 에이전트의 동작과 성능을 이해하는 데 도움이 되는 필수 목록의 최상위에 있습니다. 또한 많은 회사에서 가드레일을 사용하여 에이전트가 궤도를 벗어나는 것을 방지합니다.

LLM 앱을 테스트할 때 오프라인 평가( 39.8%)가 온라인 평가(32.5%)보다 더 자주 사용되었으며, 이는 실시간 모니터링이 어렵다는 점을 반영합니다. 또한, 많은 기업이 추가적인 예방 조치로 전문가가 직접 응답을 확인하거나 평가하는 것으로 나타났습니다.

이러한 열의에도 불구하고 사람들은 일반적으로 에이전트 권한에 대해 보수적인 태도를 보입니다. 상담원에게 읽기, 쓰기, 삭제 권한을 자유롭게 허용하는 응답자는 거의 없었습니다. 대신 대부분의 팀은 도구 권한에 대한 읽기 액세스만 허용하거나 에이전트가 쓰기나 삭제와 같은 보다 위험한 작업을 수행하려면 사람의 승인을 받아야 한다고 답했습니다.

회사 규모에 따라 에이전트 제어의 우선순위도 다릅니다. 또한 우선순위도 다릅니다. 당연히 직원 수가 2,000명 이상인 대규모 조직은 불필요한 위험을 피하기 위해 더 신중하고 '읽기 전용' 권한에 크게 의존합니다. 또한 가드레일 보호와 오프라인 평가를 결합하는 경향이 있으며 고객이 문제를 발견하는 것을 원하지 않습니다.

그러나 소규모 기업 및 스타트업(직원 100명 미만의 직원 100명 미만)은 다른 제어보다는 에이전트 애플리케이션에서 일어나는 일을 이해하기 위한 추적에 더 집중하고 있습니다. LangChain의 설문조사 데이터에 따르면, 소규모 기업은 결과를 이해하기 위해 데이터를 살펴보는 데 집중하는 경향이 있는 반면, 대규모 조직은 전반적으로 더 많은 제어 기능을 갖추고 있는 것으로 나타났습니다.

에이전트 투입의 장벽과 도전 과제 에이전트를 프로덕션에 투입하기 위한 장애물과 과제

LLM의 고품질 성능을 보장하는 것은 어렵고, 매우 정확하고 올바른 스타일로 답변해야 합니다. 이는 에이전트 개발자와 사용자에게 비용이나 보안과 같은 다른 요소보다 두 배 이상 중요한 주요 관심사입니다.

LLM 에이전트는 확률론적 콘텐츠 출력이므로 예측 불가능성이 더 높습니다. 따라서 오류가 발생할 가능성이 높아져 팀이 에이전트가 상황에 맞는 정확한 응답을 일관되게 제공하도록 보장하기가 어렵습니다.

성능 품질이 다른 고려 사항보다 훨씬 더 중요한 소규모 기업의 경우 특히 이러한 현상이 두드러지며, 45%의 사용자가 성능에 만족한다고 응답했습니다. 45.8%가 가장 중요한 고려 사항으로 꼽은 반면, 비용(두 번째로 중요한 고려 사항)은 22.4%에 불과하여 성능 품질이 다른 고려 사항보다 훨씬 더 중요했습니다. 이러한 차이는 에이전트를 개발에서 프로덕션으로 전환하는 조직에서 신뢰할 수 있는 고품질 성능이 얼마나 중요한지 잘 보여줍니다.

보안 문제 역시 엄격한 규정 준수가 필요하고 고객 데이터를 민감하게 다루는 대기업에서 만연합니다.

문제는 품질 그 이상입니다. LangChain이 제공한 개방형 응답을 보면, 많은 기업이 에이전트 개발 및 테스트에 지속적으로 투자할 의향이 있는지에 대해 회의적인 반응을 보였습니다. 에이전트 개발에 필요한 지식이 방대하고 최신 기술을 유지해야 하며, 에이전트 개발 및 배포에 필요한 시간이 많이 소요되고 안정적인 운영에 대한 이점이 불확실하다는 점이 두 가지 주요 장애물로 꼽혔습니다.

기타 떠오르는 주제

이러한 기능을 보여주는 AI 에이전트에 대한 주관식 질문에는 많은 칭찬이 있었습니다."

- 다단계 작업 관리: AI 에이전트가 심층적인 추론과 컨텍스트 관리를 수행할 수 있어 더 복잡한 작업을 처리할 수 있습니다.

- 반복 작업 자동화: 반복적인 작업을 자동화할 수 있습니다. 반복적인 작업 자동화: AI 에이전트는 자동화된 작업을 처리하는 핵심 요소로 계속 인식되고 있으며, 이를 통해 사용자는 보다 창의적인 문제를 해결할 수 있는 시간을 확보할 수 있습니다.

- 작업 계획 및 협업: 더 나은 작업 계획을 통해 특히 다중 에이전트 시스템에서 적절한 에이전트가 적시에 적절한 문제를 해결할 수 있습니다.

- 인간과 유사한 추론: 기존 LLM과 달리 AI 에이전트는 새로운 정보에 비추어 과거 결정을 검토하고 수정하는 등 소급적으로 의사 결정을 내릴 수 있습니다. 과거의 결정을 회상하고 수정할 수 있습니다.

또한 가장 기대되는 두 가지 발전이 있습니다.

- 오픈 소스 AI 에이전트에 대한 기대: 많은 사람들이 에이전트를 가속화하는 방법으로 집단 지성을 꼽는 등 오픈 소스 AI 에이전트에 대한 관심이 분명합니다. 사람들은 집단 지성이 에이전트 혁신을 가속화할 수 있다고 언급했습니다.

- 더 강력한 모델에 대한 기대: 많은 사람들이 더 크고 강력한 모델을 통해 에이전트가 훨씬 더 정교하고 강력한 수준으로 사용될 수 있는 AI 에이전트의 다음 도약을 기대하고 있습니다.

AI 에이전트의 다음 도약: 많은 사람들이 더 크고 강력한 모델에 기반하여 더 복잡한 작업을 더 효율적이고 자율적으로 처리할 수 있는 AI 에이전트의 다음 도약을 기대하고 있습니다.

Q&A에 참여한 많은 사람들이 에이전트 개발의 가장 큰 어려움으로 에이전트의 행동을 이해하는 방법을 언급하기도 했습니다. 일부 엔지니어는 회사 이해관계자에게 AI 에이전트의 기능과 동작을 설명하는 데 어려움을 겪었다고 언급했습니다. 어떤 경우에는 시각적 플러그인이 에이전트의 행동을 설명하는 데 도움이 될 수 있지만, 더 많은 경우에 LLM은 여전히 블랙박스로 남아 있습니다. 해석 가능성에 대한 추가적인 부담은 엔지니어링 팀에 맡겨집니다.

02.AI 에이전트의 핵심 요소

왜 에이전트인가? 시스템

인공지능 에이전트 현황 보고서가 발표되기 전에, 랭체인 팀은 이미 에이전트 영역에서 자체적인 랭그래프 프레임워크를 작성했으며, 인더루프 블로그를 통해 인공지능 에이전트의 많은 주요 구성 요소에 대해 논의했으며, 다음은 그 중 핵심 요소들을 정리한 것입니다.

우선, AI 에이전트에 대한 정의는 사람마다 조금씩 다른데, LangChain의 창립자 해리슨 체이스는 다음과 같이 정의합니다.

AI 에이전트는 LLM을 사용하여 프로그램을 제어하는 프로그램 제어 메커니즘입니다. 프로그램에 대한 제어 흐름 결정을 내리는 LLM입니다.

AI 에이전트는 LLM을 사용하여 애플리케이션의 제어 흐름을 결정하는 시스템입니다.

이 문서에서는 에이전트가 생각하는 방식과 시스템이 LLM을 코딩/프롬프트하는 방식을 나타내는 인지 아키텍처의 개념을 소개합니다.

. - 인지: 에이전트는 LLM을 사용하여 LLM을 코딩/프롬프트하는 방법을 의미론적으로 추론합니다.

- 아키텍처: 이러한 에이전트 시스템은 여전히 기존 시스템과 유사한 많은 아키텍처를 포함하고 있습니다. 기존 시스템 아키텍처와 유사한 많은 엔지니어링을 포함합니다.

다음 다이어그램은 다양한 수준의 코그너티브 아키텍처의 예를 보여줍니다:

- 표준화된 소프트웨어 코드: 모든 것이 하드 코드이며 출력 또는 입력과 관련된 파라미터가 소스 코드에 직접 고정되어 있어 인지 아키텍처를 구성하지 않습니다.

- 일부 데이터 전처리 외에도 단일 LLM 호출이 애플리케이션의 대부분을 구성하며, 간단한 챗봇이 이 범주에 속합니다.

- 체인: 일련의 LLM 호출, 체인은 여러 단계로 문제를 해결하려고 시도하고, 문제를 해결하기 위해 다른 LLM을 호출합니다. 첫 번째 LLM은 검색 및 쿼리를 위해 호출되고 두 번째 LLM은 답을 생성하기 위해 호출됩니다.

- 라우터: 앞의 세 시스템에서는 사용자가 프로그램이 수행할 모든 단계를 미리 알 수 있지만, 라우터에서는 다음과 같이 다릅니다. 라우터에서는 LLM이 스스로 어떤 LLM을 호출하고 어떤 단계를 수행할지 결정하기 때문에 더 많은 무작위성과 예측 불가능성이 추가됩니다.

- LLM과 라우터를 결합한 상태 머신은 다음과 같습니다. 이런 식으로 루프로 결합하면 시스템이 (이론적으로) 무한대의 LLM 호출을 할 수 있기 때문에 훨씬 더 예측 불가능합니다.

- 에이전트 시스템: 모두가 "자율적"이라고도 부르는 것 에이전트"라고도 불리는 시스템으로, 스테이트 머신을 사용할 때는 어떤 조치를 취할 수 있고 그 조치 후에 어떤 프로세스를 수행할 수 있는지에 대한 제한이 여전히 존재하지만, 자율 에이전트를 사용하면 이러한 제한이 제거됩니다. LLM이 수행할 단계와 다른 LLM을 프로그래밍하는 방법을 결정합니다. 다른 프롬프트, 도구 또는 코드를 사용하여 이 작업을 수행할 수 있습니다.

단순히 말해, 시스템이 "에이전트적"일수록 LLM이 시스템 작동 방식을 더 많이 결정합니다.

에이전트의 핵심 요소

계획

에이전트 신뢰성은 큰 골칫거리입니다. LLM을 사용하여 에이전트를 구축한 기업들은 종종 에이전트가 계획과 추론을 잘 하지 못한다고 언급합니다. 여기서 계획과 추론이란 무엇을 의미할까요?

에이전트 계획 및 추론이란 어떤 조치를 취할지 생각하는 LLM의 능력을 말합니다. 여기에는 단기 및 장기 추론이 모두 포함되며, LLM은 모든 가용 정보를 평가한 다음 어떤 일련의 단계를 거쳐야 하는지, 지금 당장 취해야 할 첫 번째 단계는 무엇인지 결정합니다.

대부분의 경우 개발자는 함수 호출을 사용하여 LLM이 수행할 작업을 선택할 수 있도록 합니다. 함수 호출은 2023년 6월 OpenAI가 LLM API에 처음 추가한 기능으로, 사용자가 다양한 함수에 대한 JSON 구조를 제공하고 LLM이 해당 구조 중 하나(또는 그 이상)와 일치하도록 할 수 있습니다.

복잡한 작업을 성공적으로 완료하려면 시스템이 일련의 작업을 순서대로 수행해야 합니다. 이러한 장기적인 계획과 추론은 LLM에게 매우 복잡합니다. 첫째, LLM은 장기적인 액션 계획을 고려한 다음 수행해야 할 단기적인 액션으로 돌아가야 하고, 둘째, 에이전트가 점점 더 많은 액션을 수행함에 따라 액션의 결과가 LLM에 피드백되어 컨텍스트 창이 커지고 이로 인해 LLM이 "주의가 산만해지고 "되어 성능이 저하될 수 있습니다.

계획 수립을 개선하는 가장 쉬운 해결책은 LLM이 적절하게 추론/계획하는 데 필요한 모든 정보를 확보하는 것입니다. 간단해 보이지만, 종종 LLM에게 전달되는 정보가 LLM이 합리적인 결정을 내리는 데 충분하지 않을 수 있으며, 검색 단계를 추가하거나 프롬프트를 명확히 하는 것만으로도 간단하게 개선할 수 있습니다.

그런 다음에는 앱의 인지 아키텍처를 변경하는 것을 고려하세요. 추론을 개선하기 위한 인지 아키텍처에는 일반 인지 아키텍처와 도메인별 인지 아키텍처의 두 가지 유형이 있습니다.

1. 일반 인지 아키텍처

일반 인지 아키텍처는 다음에 적용될 수 있습니다. 모든 작업에 적용할 수 있습니다. 여기에서는 두 가지 일반 아키텍처를 제안하는 두 개의 논문을 소개합니다. 하나는 '계획 및 해결 프롬프트: 대규모 언어 모델에 의한 제로 샷 연쇄 추론 개선'의 '계획 및 해결' 아키텍처입니다. 대규모 언어 모델에 의한 계획 및 해결 프롬프트는 에이전트가 먼저 계획을 제안한 다음 해당 계획의 각 단계를 실행하는 방식입니다. 또 다른 일반적인 아키텍처는 Reflexion: 언어 강화 학습을 갖춘 언어 에이전트에서 제안된 Reflexion 아키텍처로, 에이전트가 작업을 수행한 다음 명시적인 "반영 " 단계를 수행하여 에이전트가 작업을 수행한 후 작업을 올바르게 수행했는지 여부를 반영합니다. 여기서는 자세히 설명하지 않고 지난 두 개의 백서에서 자세한 내용을 확인할 수 있습니다.

이러한 아이디어는 개선 효과를 보여주지만 너무 일반적이어서 실제 프로덕션에서 에이전트가 사용하기에는 무리가 있는 경우가 많습니다. （

2. 도메인별 인지 아키텍처

대신 도메인별 인지 아키텍처를 사용하여 에이전트를 구축하는 것을 볼 수 있습니다. 도메인별 인지 아키텍처. 이는 종종 도메인별 분류/계획 단계, 도메인별 검증 단계에서 나타납니다. 계획과 성찰의 아이디어 중 일부는 여기에 적용될 수 있지만 일반적으로 도메인에 특화된 방식으로 적용됩니다.

이에 대한 구체적인 예는 AlphaCodium의 논문에 나와 있습니다. 이 회사는 "흐름 공학"(인지 아키텍처의 다른 표현)을 사용하여 최첨단 성능을 달성했습니다.

에이전트의 흐름은 그들이 해결하려는 문제에 매우 구체적이라는 것을 알 수 있습니다. 해결하려는 문제에 매우 구체적이라는 것을 알 수 있습니다. 에이전트는 테스트, 솔루션, 더 많은 테스트를 위한 반복 등 단계별로 해야 할 일을 에이전트에게 지시합니다. 이러한 인지 아키텍처는 매우 도메인에 특화되어 있으며 다른 도메인에 일반화할 수 없습니다.

사례 연구:

Reflection AI 설립자  Laskin 상담원의 미래에 대한 비전

Reflection AI의 창립자인 미샤 라스킨(Misha Laskin)은 Sequoia Capital과의 인터뷰에서 자신의 비전을 실현하기 시작했다고 언급합니다: 즉, RL의 검색 기능과 LLM을 결합하여 자신의 새로운 회사인 Reflection AI에서 최고의 에이전트 모델을 구축하는 것입니다. 그와 공동 설립자인 Ioannis Antonoglou(알파고, 알파제로, 제미니 RLHF의 대표)는 에이전트 워크플로우를 위해 설계된 모델을 훈련하고 있으며, 인터뷰의 주요 내용은 다음과 같습니다.

딥스는 AI 개발에서 가장 중요한 요소입니다. - 뎁스는 AI 에이전트에서 빠진 조각입니다.

- 학습과 검색의 결합은 초인적인 성능을 달성하는 데 핵심입니다. 라스킨은 알파고의 성공을 예로 들며 AI에서 가장 심오한 아이디어는 학습(LLM에 의존)과 검색(최적 경로 찾기)의 결합이라고 강조합니다. 이 접근 방식은 복잡한 작업에서 인간을 능가하는 에이전트를 만드는 데 매우 중요합니다.

- 사후 학습 및 보상 모델링은 중요한 과제를 제기합니다. 명시적인 보상이 있는 게임과 달리 실제 작업에는 실제 보상이 부족한 경우가 많습니다. 신뢰할 수 있는 보상 모델을 개발하는 것은 신뢰할 수 있는 AI 에이전트를 만드는 데 있어 핵심 과제입니다

- 유니버설 에이전트는 우리가 생각하는 것보다 더 가까워질 수 있습니다. 라스킨은 폭과 깊이를 모두 갖춘 AI 시스템, 즉 '디지털 AGI'가 불과 3년 앞으로 다가왔다고 예상합니다. 이렇게 빨라진 일정은 기능이 발전함에 따라 보안 및 안정성 문제를 해결해야 하는 시급성을 강조합니다.

- 유니버설 에이전트로 가는 길에는 접근 방식이 필요합니다. Reflection AI는 브라우저, 코딩, 컴퓨터 운영 체제 등 특정 환경부터 시작하여 에이전트의 기능을 확장하는 데 중점을 두고 있습니다. 특정 작업에 국한되지 않는 범용 에이전트를 개발하는 것이 목표입니다.

UI/UX 상호작용

인간과 컴퓨터의 상호작용은 향후 몇 년간 핵심 연구 분야가 될 것입니다. 에이전트 시스템은 지연 시간, 사용 불가능성, 다른 사람과 상호작용할 수 있어야 한다는 점에서 과거의 전통적인 컴퓨터 시스템과 다릅니다. 에이전트 시스템은 지연 시간, 불안정성, 자연어 인터페이스라는 새로운 과제를 안고 있기 때문에 과거의 전통적인 컴퓨터 시스템과는 다릅니다. 따라서 이러한 에이전트 애플리케이션과 상호 작용하기 위한 새로운 UI/UX 패러다임이 등장할 것입니다. 에이전트 시스템은 아직 초기 단계에 있지만 이미 다양한 새로운 UX 패러다임이 등장하고 있습니다. 아래에서 이에 대해 설명합니다.

1. 대화형 상호작용(채팅 UI)

챗은 일반적으로 스트리밍 채팅, 비스트리밍 채팅, n-스트리밍 채팅의 두 가지 카테고리로 나뉩니다.

일반적으로 두 가지 유형의 채팅이 있습니다: 스트리밍 채팅과 비스트리밍 채팅.

스트리밍 채팅은 가장 일반적인 UX로, 생각과 행동을 채팅 형식으로 다시 스트리밍하는 챗봇으로 가장 인기 있는 예로 ChatGPT가 있습니다. 이 상호작용 방식은 단순해 보이지만, 첫째, 자연어를 사용하여 LLM과 대화할 수 있으므로 클라이언트와 LLM 사이에 장벽이 없고, 둘째, LLM은 작업하는 데 시간이 걸릴 수 있는데 스트리밍을 통해 사용자는 백그라운드에서 무슨 일이 일어나고 있는지 정확히 알 수 있으며, 셋째, LLM은 종종 틀릴 수 있는데 채팅은 이를 자연스럽게 수정하고 안내하는 훌륭한 인터페이스를 제공하기 때문에 자연스럽게 수정하고 안내하며, 사람들은 채팅에서 후속 대화와 반복적인 토론을 하는 데 매우 익숙해졌습니다.

그러나 스트리밍 채팅에는 단점도 있습니다. 첫째, 스트리밍 채팅은 비교적 새로운 사용자 경험이기 때문에 기존 채팅 플랫폼(iMessage, Facebook Messenger, Slack 등)에는 제공되지 않으며, 둘째, 실행 시간이 긴 작업에는 다소 어색하다는 점, 셋째, 사용자가 에이전트가 작업하는 것을 지켜보고만 있어야 한다는 점 등입니다.

비스트리밍 채팅과의 큰 차이점은 응답이 일괄적으로 반환되고 LLM이 백그라운드에서 작동하며 사용자가 즉시 응답을 받기 위해 서두르지 않기 때문에 기존 워크플로에 통합하기가 더 쉽다는 점입니다. 워크플로우. 사람들은 사람과 문자 메시지를 주고받는 데 익숙해져 있는데, 왜 AI와 문자 메시지를 주고받는 데는 적응하지 못할까요? 비스트리밍 채팅을 사용하면 더 복잡한 상담원 시스템과 더 쉽게 상호작용할 수 있습니다. 이러한 시스템은 종종 시간이 걸리기 때문에 즉각적인 응답을 기대하는 경우 실망할 수 있습니다. 비스트리밍 채팅은 일반적으로 이러한 기대치를 제거하여 더 복잡한 작업을 더 쉽게 수행할 수 있습니다.

이 두 가지 유형의 채팅에는 다음과 같은 장단점이 있습니다.

2. 백그라운드 환경(앰비언트 UX)

사용자는 위에서 Chat에서 이야기한 것처럼 AI에게 메시지를 보내는 것을 고려하겠지만 에이전트가 백그라운드에서 작업만 한다면 어떻게 작업해야 할까요? 에이전트가 백그라운드에서 작업하는 경우 에이전트와 어떻게 상호 작용할까요?

에이전트 시스템이 그 잠재력을 제대로 발휘하려면 AI가 백그라운드에서 작업할 수 있도록 하는 방향으로 전환해야 합니다. 사용자는 작업이 백그라운드에서 처리될 때 짧은 지연 시간에 대한 기대치가 완화되므로 완료 시간이 길어지는 것을 더 잘 견뎌냅니다. 따라서 상담원은 더 많은 작업을 수행할 수 있으며, 채팅 UX에서보다 더 신중하고 부지런히 추론할 수 있습니다.

또한 백그라운드에서 에이전트를 실행하면 인간 사용자의 역량이 확장됩니다. 채팅 인터페이스에서는 한 번에 한 가지 작업만 할 수 있는 경우가 많습니다. 하지만 상담원이 백그라운드 환경에서 실행되는 경우에는 여러 상담원이 동시에 여러 작업을 수행할 수 있습니다.

상담원이 백그라운드에서 실행되도록 하려면 사용자의 신뢰가 필요한데 어떻게 신뢰를 구축할 수 있을까요? 간단한 아이디어는 에이전트가 수행하는 작업을 사용자에게 정확히 보여주는 것입니다. 에이전트가 실행하는 모든 단계를 보여주고 사용자가 어떤 일이 일어나고 있는지 관찰할 수 있도록 하세요. 이러한 단계는 응답을 스트리밍할 때처럼 즉시 보이지 않을 수도 있지만 사용자가 클릭하여 관찰할 수 있어야 합니다. 다음 단계는 사용자가 무슨 일이 일어나고 있는지 볼 수 있도록 하는 것뿐만 아니라 상담원을 수정할 수 있도록 하는 것입니다. 10단계 중 4단계에서 상담원이 잘못된 선택을 한 것을 발견하면 고객은 4단계로 돌아가서 어떤 식으로든 상담원을 바로잡을 수 있는 옵션이 있습니다.

이 접근 방식은 사용자를 "인더루프"에서 "온더루프"로 전환합니다. "온더루프"는 상담원이 수행하는 모든 중간 단계를 사용자에게 보여줄 수 있어야 하며, 사용자가 워크플로를 중간에 일시 중지하고 피드백을 제공한 다음 상담원이 계속할 수 있도록 해야 합니다.

AI 소프트웨어 엔지니어인 Devin은 UX를 구현하는 애플리케이션으로, 실행하는 데 시간이 오래 걸리지만 고객은 모든 단계를 확인하고 특정 시점의 개발 상태로 되돌리고 거기서부터 수정 사항을 게시할 수 있습니다. 에이전트가 백그라운드에서 실행되고 있다고 해서 완전히 자율적으로 작업을 수행해야 하는 것은 아닙니다. 에이전트가 무엇을 해야 할지, 어떻게 대답해야 할지 모를 때가 있는데, 이럴 때는 사람의 주의를 끌거나 도움을 요청해야 합니다.

해리슨이 구축 중인 이메일 어시스턴트 에이전트가 구체적인 예입니다. 이메일 어시스턴트는 기본적인 이메일에 응답할 수 있지만, 해리슨은 복잡한 LangChain 버그 보고서 검토, 회의 참석 여부 결정 등 자동화를 원하지 않는 특정 작업을 입력해야 하는 경우가 많습니다. 이 경우 이메일 어시스턴트는 응답을 위해 정보가 필요하다는 것을 해리슨에게 전달할 수 있는 방법이 필요합니다. 직접적인 답변을 요청하는 것이 아니라 특정 작업에 대한 해리슨의 의견을 요청하는 것이며, 이를 통해 멋진 이메일을 작성하여 보내거나 캘린더 초대를 예약하는 데 사용할 수 있다는 점에 유의하세요.

현재 해리슨은 Slack에서 이 도우미를 설정해 두고 있습니다. 이 도우미가 Harrison에게 질문을 보내면 Harrison은 워크플로와 기본적으로 통합된 대시보드에서 답변합니다. 이 인터페이스는 도우미가 사람의 도움이 필요한 모든 영역, 요청의 우선순위 및 기타 데이터를 표시합니다.

3. 스프레드시트( 스프레드시트 UX)

스프레드시트 UX는 매우 직관적이고 사용자 친화적인 방식으로 일괄 처리 작업을 지원합니다. 각 양식 또는 각 열은 특정 작업을 수행할 수 있는 자체 에이전트가 됩니다. 이러한 일괄 처리를 통해 사용자는 여러 에이전트와의 상호 작용을 확장할 수 있습니다.

이 UX에는 다른 이점도 있습니다. 스프레드시트 형식은 대부분의 사용자에게 익숙한 UX이므로 기존 워크플로우에 잘 맞습니다. 이러한 유형의 UX는 데이터 확장에 적합하며, 이는 각 열이 확장할 다른 속성을 나타낼 수 있는 일반적인 LLM 사용 사례입니다.

이 유형의 UX는 Exa AI, Clay AI, Manaflow 등의 제품에서 사용되며, 이 스프레드시트 UX가 워크플로를 처리하는 방법의 예로 Manaflow가 사용됩니다.

사례 연구:

Manaflow가 워크플로우에 전자 양식을 사용하는 방법.

매나플로우가 에이전트 상호 작용을 위해 스프레드시트를 사용하는 방법

매나플로우 설립자 Lawrence가 근무하던 회사에서 Web Agent라는 제품을 만든 Minion AI에서 영감을 얻었습니다. 이 에이전트는 로컬 Google Chrome을 제어하여 항공편 예약, 이메일 전송, 세차 예약 등의 애플리케이션과 상호 작용할 수 있습니다. 미니언 AI에서 영감을 받은 Manaflow는 에이전트가 스프레드시트를 조작할 수 있도록 선택했습니다. 에이전트는 인간 UI를 다루는 데 능숙하지 않고, 정말 잘하는 것은 코딩이기 때문에 Manaflow는 에이전트가 UI에서 Python 스크립트를 호출하고 데이터베이스에 인터페이스하고 API를 연결할 수 있도록 했습니다. Manaflow를 사용하면 에이전트가 UI에서 Python 스크립트를 호출하고, 데이터베이스에 인터페이스하고, API에 연결한 다음, 열람 시간, 예약, 이메일 전송 등 데이터베이스를 직접 조작할 수 있습니다.

워크플로는 다음과 같습니다: Manaflow의 기본 인터페이스는 스프레드시트로, 각 열은 워크플로의 단계를 나타내고 각 행은 작업을 수행하는 AI 에이전트에 해당합니다. 각 스프레드시트 워크플로는 자연어로 프로그래밍할 수 있습니다(기술 전문가가 아닌 사용자도 자연어로 작업과 단계를 설명할 수 있음). 각 스프레드시트에는 각 열의 실행 순서를 결정하는 내부 종속성 그래프가 있습니다. 이러한 순서는 각 행의 에이전트에 할당되어 데이터 변환, API 호출, 콘텐츠 검색 및 메시지 전송과 같은 프로세스를 처리하면서 작업을 병렬로 실행합니다.

맨시트 생성은 위 이미지에서 고객에게 가격 이메일을 보내려는 경우와 같이 위의 빨간색 상자에 있는 것과 유사한 자연어를 입력하면 채팅을 통해 프롬프트를 입력하여 맨시트를 생성할 수 있습니다. 고객의 이름, 이메일 주소, 업종 및 이메일 전송 여부를 확인할 수 있으며, 실행을 클릭하여 작업을 실행할 수 있습니다.

4. 생성 UI

생성 UI에는 두 가지 구현이 있습니다. "는 두 가지 방식으로 구현됩니다.

한 가지 방법은 모델이 필요한 원시 컴포넌트를 자체적으로 생성하는 것입니다. 이는 Websim과 같은 제품과 유사합니다. 에이전트는 백그라운드에서 주로 원시 HTML을 작성하여 표시되는 내용을 완전히 제어할 수 있습니다. 하지만 이 접근 방식은 생성된 웹 앱의 품질에 높은 수준의 불확실성을 허용하므로 최종 결과가 상당히 불안정해 보일 수 있습니다.

또 다른, 좀 더 제약적인 접근 방식은 일부 UI 컴포넌트 중 일부를 미리 정의하는 것입니다. 예를 들어 LLM이 날씨 API를 호출하면 날씨 맵 UI 컴포넌트의 렌더링이 트리거됩니다. 렌더링된 컴포넌트가 실제로 생성되는 것은 아니므로(하지만 더 많은 옵션이 있습니다), 생성된 UI는 더 세련되지만 생성할 수 있는 항목이 완전히 유연하지는 않습니다.

사례 연구:

개인용 AI 제품 도트

예를 들어, 2024년 최고의 개인용 AI 제품이라고 불리는 Dot은 훌륭한 제너레이티브 UI 제품입니다.

Dot은 더 나은 작업 관리 도구가 아니라 사용자의 장기적인 동반자가 되는 것이 목표이며, 공동 창립자 Jason Yuan에 따르면 어디로 가야 할지, 무엇을 해야 할지, 무엇을 말해야 할지 모를 때 Dot을 찾는다는 것이 Dot의 느낌이라고 합니다. 다음은 제품의 기능에 대한 두 가지 예입니다.

- 설립자 Jason Yuan은 종종 밤늦게 술에 취하고 싶다며 Dot에게 바를 추천해 달라고 부탁하고, 퇴근 후 어느 날 Yuan은 다음과 같이 말합니다. 어느 날 퇴근 후, 위안은 다시 비슷한 질문을 했고, 닷은 이렇게 계속할 수 없다고 제이슨을 설득하기 시작했습니다.

- 몇 달 동안 닷과 함께 일했던 Fast Company 기자 Mark Wilson도 이 문제에 대해 자신의 생각을 닷과 공유했습니다. 그가 캘리그라피 수업에서 손글씨로 쓴 'O'를 닷과 공유하자, 닷은 몇 주 전에 자신이 직접 쓴 'O'의 사진을 꺼내 보이며 놀라워했고, 그의 향상된 캘리그라피 실력에 칭찬을 아끼지 않았습니다.

- 닷을 사용하는 시간이 늘어날수록 닷은 사용자가 카페를 즐겨 찾는다는 것을 더 잘 이해하고, 이 카페가 좋은 이유를 첨부하여 주변의 좋은 카페를 주인에게 적극적으로 추천하고, 마지막으로 탐색할 것인지 묻습니다.

이 카페 추천 예시에서 이를 확인할 수 있습니다. Dot은 UI 컴포넌트를 미리 정의하여 LLM 네이티브 인터랙션을 구현합니다.

5. 협업 UX

에이전트와 사람이 함께 작업하면 어떤 일이 일어날까요? 고객이 팀원들과 협업하여 문서를 작성하거나 편집할 수 있는 Google 문서 도구를 생각해 보세요. 만약 협업자 중 한 명이 에이전트라면 어떻게 될까요?

Geoffrey Litt의 Patchwork 프로젝트와 Ink & Switch는 인간과 에이전트 협업의 좋은 예입니다. 에이전트 협업. (번역자 주: 최근 OpenAI Canvas 제품 업데이트의 영감이 되었을 수 있습니다).

협업 UX는 앞서 설명한 것과 어떻게 다른가요? LangChain의 창립 엔지니어인 Nuno는 이 둘의 주요 차이점은 동시성 유무라고 강조했습니다.

- Collaborative UX에서는 클라이언트와 LLM이 은 서로의 작업을 입력으로 받아 동시에 작업하는 경우가 많습니다.

- 환경적 UX에서는 사용자가 다른 것에 집중하는 동안 LLM이 백그라운드에서 지속적으로 작업합니다.

메모리

메모리는 우수한 상담원 경험에 매우 중요합니다. 동료가 자신이 말한 내용을 기억하지 못해 같은 정보를 계속해서 반복해야 한다면 협업 환경이 매우 열악할 것이라고 상상해 보세요. 사람들은 종종 LLM 시스템이 기억력을 가지고 태어날 것이라고 기대하는데, 이는 아마도 LLM이 이미 매우 인간적인 느낌을 주기 때문일 것입니다. 하지만 LLM은 본질적으로 아무것도 기억하지 못합니다.

에이전트 메모리는 제품 자체에 필요한 것을 기반으로 하며, UX에 따라 정보를 수집하고 피드백을 업데이트하는 방식이 다릅니다. 에이전트 제품의 메모리 메커니즘에서는 인간의 메모리 유형을 모방한 다양한 유형의 상위 수준 메모리를 볼 수 있습니다.

코알라: 언어 에이전트를 위한 인지 아키텍처 논문에서는 인간의 기억 유형을 에이전트 기억에 매핑하여 다음과 같이 분류하고 있습니다.

1. 절차적 기억: 작업을 수행한 방법에 대한 기억. strong>뇌의 핵심 명령어 집합과 유사한 작업 수행 방법에 대한 장기 기억

- 인간의 절차적 기억: 자전거 타는 방법을 기억하는 것과 유사합니다.

- 에이전트의 절차적 기억: CoALA 논문에서는 절차적 기억을 에이전트의 작동 방식을 근본적으로 결정하는 LLM 가중치와 에이전트 코드의 조합으로 설명합니다.

실제로, Langchain 팀은 에이전트 시스템이 LLM을 자동으로 업데이트하거나 코드를 다시 작성하는 것을 보지 못했지만, 시스템 프롬프트를 업데이트하는 에이전트의 몇 가지 예가 있습니다.

2. 시맨틱 메모리: 장기 지식 저장소

- 휴먼 의미 기억: 학교에서 배운 사실, 개념 및 이들 간의 관계와 같은 정보의 단편으로 구성됩니다.

- 에이전트의 의미 기억: CoALA 논문에서는 의미 기억을 사실의 저장소라고 설명합니다.

실제로는 에이전트의 대화나 상호작용에서 정보를 추출하기 위해 LLM을 사용하여 이를 달성하는 경우가 많습니다. 이 정보가 저장되는 정확한 방식은 일반적으로 애플리케이션에 따라 다릅니다. 그런 다음 이 정보는 향후 대화에서 검색되어 시스템 프롬프트에 삽입되어 상담원의 응답에 영향을 미칩니다.

3. 에피소드 메모리: 과거의 특정 사건 기억

-  인간 에피소드 메모리. 인간의 에피소드 기억: 과거에 경험한 특정 사건(또는 "에피소드")을 회상하는 경우.

-상담원의 상황 기억: CoALA 논문에서는 상황 기억을 상담원의 과거 행동이 저장된 시퀀스로 정의합니다.

이것은 주로 에이전트가 예상대로 작업을 수행할 수 있도록 하는 데 사용됩니다. 실제로 상황 메모리는 몇 샷 프롬프트를 통해 업데이트됩니다. 관련 업데이트가 포함된 몇-샷 프롬프트가 충분하면 다음 업데이트는 동적 몇-샷 프롬프트를 통해 이루어집니다.

처음부터 에이전트에게 올바른 방법을 알려주는 방법이 있다면 나중에 동일한 문제에 대해 해당 접근 방식을 사용하는 것이 간단하지만, 반대로 올바른 방법이 없거나 에이전트가 계속해서 새로운 작업을 수행하는 경우에는 시맨틱 메모리가 더 중요하지만, 앞의 예제에서처럼 에서는 시맨틱 메모리가 큰 도움이 되지 않습니다.

개발자는 에이전트에서 업데이트할 메모리 유형에 대해 생각하는 것 외에도 에이전트의 메모리를 업데이트하는 방법에 대해서도 생각해야 합니다.

에이전트의 메모리를 업데이트하는 첫 번째 방법은 "핫 경로에서"입니다. 이 경우 상담원 시스템은 응답하기 전에(보통 도구 호출을 통해) 사실을 기억하고 ChatGPT는 이 방식으로 메모리를 업데이트합니다.

상담원의 메모리를 업데이트하는 다른 방식은 "in the 백그라운드" 입니다. 이 경우 세션이 끝난 후 백그라운드 프로세스가 실행되어 메모리를 업데이트합니다.

이 두 가지 방법을 비교합니다. "핫 경로에서" 방법의 단점은 응답이 전달되기까지 약간의 지연이 발생하고 메모리 로직을 에이전트 로직과 결합해야 한다는 점입니다.

그러나 "백그라운드에서"는 이러한 문제를 피할 수 있으며 지연 시간이 추가되지 않고 메모리 로직이 별도로 유지됩니다. 그러나 "백그라운드에서"에는 메모리가 즉시 업데이트되지 않고 백그라운드 프로세스를 시작할 시기를 결정하기 위해 추가 로직이 필요하다는 단점이 있습니다.

메모리를 업데이트하는 또 다른 방법은 특히 상황별 메모리와 관련된 사용자 피드백을 이용하는 것입니다. 예를 들어 사용자가 상호작용을 높게 평가하는 경우(사후 피드백) 상담원은 나중에 불러올 수 있도록 해당 피드백을 저장할 수 있습니다.

위와 같이 계획, 상호작용, 메모리 구성 요소의 동시적인 발전을 통해 2025년에는 더 유용한 AI 에이전트를 만나고 인간과 기계의 새로운 협업 시대를 맞이할 수 있을 것으로 기대합니다.