작곡: Jiayu, Cage
AI Agent는 우리가 면밀히 추적하고 있는 패러다임 변화이며, Langchain의 일련의 기사는 Agent의 개발 동향을 이해하는 데 매우 도움이 됩니다. 이 편집본의 첫 번째 부분은 Langchain 팀이 발표한 AI 에이전트 현황 보고서입니다. 개발자, 제품 관리자, 회사 임원 등 1,300명 이상의 실무자를 인터뷰하여 올해 에이전트의 현재 상황과 구현 병목 현상을 밝혔습니다. 90%의 회사가 AI 에이전트에 대한 계획과 요구 사항을 가지고 있지만 에이전트 기능의 한계로 인해 이를 어렵게 만듭니다. 사용자는 몇 가지 프로세스와 시나리오에서만 구현할 수 있습니다. 모든 사람은 비용과 대기 시간보다는 에이전트 기능 개선과 에이전트 동작의 관찰 가능성 및 제어 가능성에 더 관심을 갖습니다.
두 번째 부분에서는 LangChain 공식 웹사이트에 게재된 In the Loop 시리즈 기사에서 AI Agent의 핵심 요소인 기획 능력, UI/UX 상호 작용 혁신 및 메모리 메커니즘 에 대한 분석을 정리했습니다. 이 기사에서는 5가지 LLM 네이티브 제품의 상호 작용 방법을 분석하고 3가지 복잡한 인간 기억 메커니즘을 비유하여 AI 에이전트를 이해하고 이러한 핵심 요소를 이해하는 데 영감을 줄 수 있습니다. 이번 편에서는 Reflection AI 창립자들의 인터뷰 등 Agent 기업의 대표적인 사례 연구도 추가하여 2025년 AI Agent의 주요 혁신을 기대해 봅니다.
이러한 분석 프레임 하에서 우리는 AI 에이전트 애플리케이션이 2025년에 등장하기 시작하여 인간-기계 협업의 새로운 패러다임으로 진입할 것으로 예상합니다. AI Agent의 기획력은 o3를 필두로 하는 모델들이 강한 반성과 추론 능력을 보이고 있으며, 모델 기업의 발전은 추론기에서 에이전트 단계에 가까워지고 있다. 추론 능력이 지속적으로 향상됨에 따라 에이전트의 "라스트 마일"은 제품 상호 작용 및 메모리 메커니즘이 될 것이며 이는 스타트업이 돌파할 수 있는 기회가 될 가능성이 더 높습니다. 상호 작용에 관해서는 AI 시대의 "GUI 순간"을 기대해 왔으며, 개인 수준에서는 컨텍스트 개인화, 기업 수준에서는 컨텍스트 통합이 핵심 단어가 될 것이라고 믿습니다. Agent의 제품 경험이 크게 향상됩니다.
01. 에이전트 사용 동향:
모든 회사는 Agent 배포를 계획하고 있습니다.
에이전트 분야의 경쟁이 치열해지고 있습니다. 작년에는 많은 에이전트 프레임 인기를 얻었습니다. 예를 들어 추론과 행동을 위해 LLM과 결합된 ReAct를 사용하거나, 오케스트레이션을 위해 다중 에이전트 프레임 사용하거나, LangGraph와 같이 보다 제어 가능한 프레임 사용하는 등이 있습니다.
Agent를 둘러싼 소문이 모두 Twitter의 과대광고만은 아닙니다. 응답자의 약 51%가 현재 프로덕션 환경에서 에이전트를 사용하고 있습니다. Langchain의 회사 규모별 데이터에 따르면 직원이 100~2000명인 중견 기업이 Agent를 생산에 투입하는 데 가장 적극적으로 참여하며 그 비율은 63%입니다.
또한 응답자의 78%는 가까운 시일 내에 Agent를 프로덕션에 투입할 계획을 갖고 있습니다. 분명히 모든 사람이 AI Agent에 큰 관심을 갖고 있지만 실제로 프로덕션에 사용할 수 있는 Agent를 만드는 것은 많은 사람들에게 여전히 어려운 문제입니다.
기술 산업은 종종 에이전트의 얼리 어답터로 간주되지만 에이전트에 대한 관심은 모든 산업 분야에서 증가하고 있습니다. 비기술 기업에 근무하는 응답자의 90%는 이미 에이전트를 프로덕션에 투입했거나 투입할 계획입니다(89%로 기술 회사와 거의 같은 비율).
에이전트의 일반적인 사용 사례
에이전트에 대해 가장 일반적으로 사용되는 사용 사례에는 연구 수행 및 요약(58%)이 포함되며, 맞춤형 에이전트를 통한 작업 프로세스 단순화(53.5%)가 그 뒤를 이었습니다.
이는 시간이 너무 많이 걸리는 작업을 제품으로 처리하기를 원하는 사람들의 욕구를 반영합니다. 사용자는 방대한 양의 데이터를 직접 선별한 후 데이터 검토 또는 연구 분석을 수행하는 대신 AI Agent를 사용하여 대량 의 정보에서 핵심 정보와 통찰력을 클레임 할 수 있습니다. 마찬가지로 AI 에이전트는 일상적인 작업을 지원하여 개인 생산성을 높이고 사용자가 중요한 일에 집중할 수 있도록 합니다.
이러한 효율성 향상은 개인뿐만 아니라 기업, 팀에도 필요합니다. 고객 서비스(45.8%)는 에이전트의 또 다른 주요 응용 분야입니다. 에이전트는 기업이 상담, 문제 해결을 처리하고 팀 전반에 걸쳐 고객 응답 시간을 단축하는 데 도움을 주며, 4위와 5위는 하위 수준 코드 및 데이터 응용 프로그램입니다.
모니터링: 에이전트 애플리케이션에는 관찰성과 제어성이 필요합니다.
에이전트 구현이 더욱 강력해짐에 따라 에이전트를 관리하고 모니터링하는 방법이 필요합니다. 추적 및 관찰 도구는 개발자가 에이전트의 동작과 성능을 이해하는 데 도움이 되는 필수 목록 중 1위를 차지합니다. 많은 회사에서는 에이전트가 궤도를 벗어나는 것을 방지하기 위해 가드레일(보호 제어)을 사용하기도 합니다.
LLM 지원서를 테스트할 때 온라인 평가(32.5%)보다 오프라인 평가(39.8%)를 더 자주 사용하는 것으로 나타났는데, 이는 LLM을 실시간으로 모니터링하는 데 어려움이 있음을 반영합니다. LangChain이 제공하는 개방형 응답 중 많은 회사에서는 추가 예방 단계로 인간 전문가가 수동으로 응답을 검토하거나 평가하도록 합니다.
사람들은 에이전트에 대해 매우 열정적이지만 에이전트 권한 측면에서는 일반적으로 보수적입니다. 에이전트가 자유롭게 읽고, 쓰고, 삭제할 수 있도록 허용한 응답자는 거의 없습니다. 대신 대부분의 팀에서는 도구에 대한 읽기 액세스만 허용하거나 상담원이 쓰기 또는 삭제와 같은 리스크 작업을 수행하기 전에 사람의 승인을 요구합니다.
다양한 규모의 회사는 에이전트 제어의 우선순위도 다릅니다. 당연히 대기업(직원 2,000명 이상)은 불필요한 리스크 피하기 위해 더 조심스럽고 "읽기 전용" 권한에 크게 의존합니다. 또한 가드레일 보호와 오프라인 평가를 결합하는 경향이 있으며 고객이 어떤 문제도 보지 않기를 바랍니다.
한편, 소규모 회사와 스타트업(직원 100명 미만)은 에이전트 애플리케이션에서 발생하는 상황을 이해하기 위해 다른 컨트롤보다 추적에 더 중점을 둡니다. LangChain 조사 데이터에 따르면 소규모 회사는 결과를 이해하기 위해 데이터를 보는 데 집중하는 경향이 있는 반면, 대기업은 전반적으로 더 많은 통제권을 갖고 있습니다.
에이전트를 프로덕션으로 전환하는 데 따른 장벽과 과제
LLM의 고품질 성능을 보장하는 것은 어렵습니다. 답변은 매우 정확하고 올바른 스타일과 일치해야 합니다. 이는 에이전트 개발자와 사용자가 가장 우려하는 문제로, 비용, 보안 및 기타 요소보다 두 배 이상 중요합니다.
LLM 에이전트는 확률론적 콘텐츠 출력이므로 예측할 수 없음을 의미합니다. 이로 인해 오류가 발생할 가능성이 더 높아져 팀이 상담원이 정확하고 상황에 맞는 응답을 일관되게 제공하는지 확인하기가 어려워집니다.
이는 성능 품질이 다른 고려 사항보다 훨씬 중요한 소규모 기업의 경우 특히 그렇습니다. 45.8%가 이를 주요 관심사로 꼽았고, 비용(두 번째로 큰 관심사)은 22.4%에 불과했습니다. 이러한 격차는 에이전트를 개발에서 생산으로 이동하는 조직에서 신뢰할 수 있는 고품질 성능의 중요성을 강조합니다.
엄격한 규정 준수를 요구하고 고객 데이터를 민감하게 처리하는 대기업의 경우에도 보안 문제가 널리 퍼져 있습니다.
도전은 품질에서 끝나지 않습니다. LangChain이 제공한 공개 답변에서 많은 사람들은 회사가 에이전트 개발 및 테스트에 계속 투자할 것인지에 대해 여전히 회의적입니다. 모두가 두 가지 뛰어난 장애물을 언급했습니다. 에이전트를 개발하려면 많은 지식이 필요하고 최신 기술을 유지해야 합니다. 에이전트를 개발하고 배포하는 데는 많은 시간과 비용이 소요되며 안정적인 운영의 이점은 불확실합니다.
기타 새로운 주제
공개질문에서는 AI 에이전트가 보여준 능력에 대해 많은 칭찬이 있었습니다.
• 다단계 작업 관리: AI 에이전트는 더 깊은 추론과 상황 관리가 가능하여 더 복잡한 작업을 처리할 수 있습니다.
• 반복 작업 자동화: AI 에이전트는 자동화된 작업 처리의 핵심으로 계속해서 인식되고 있으며, 이를 통해 사용자는 더 창의적인 문제를 해결하는 데 시간을 투자할 수 있습니다.
• 작업 계획 및 협업: 더 나은 작업 계획을 통해 특히 다중 에이전트 시스템에서 올바른 에이전트가 적시에 올바른 문제를 처리할 수 있습니다.
• 인간과 유사한 추론: 기존 LLM과 달리 AI Agent는 새로운 정보를 기반으로 과거 결정을 검토하고 수정하는 등 소급하여 결정을 내릴 수 있습니다.
또한 모두가 가장 기대하는 두 가지 개발이 있습니다.
• 오픈 소스 AI 에이전트에 대한 기대: 사람들은 분명히 오픈 소스 AI 에이전트에 관심을 갖고 있으며, 많은 사람들은 집단 지능이 에이전트 혁신을 가속화할 수 있다고 언급했습니다.
• 더 강력한 모델에 대한 기대: 많은 사람들은 더 크고 더 강력한 모델에 의해 구동되는 AI 에이전트의 다음 도약, 즉 에이전트가 더 큰 효율성과 자율성을 가지고 더 복잡한 작업을 처리할 수 있는 시대를 기대하고 있습니다.
Q&A에서도 많은 분들이 Agent 개발에 있어 가장 큰 과제인 Agent의 행동을 이해하는 방법을 언급하셨습니다. 일부 엔지니어들은 AI 에이전트의 기능과 행동을 기업 이해관계자들에게 설명하는 데 어려움을 겪었다고 언급했다. 때때로 시각화 플러그인이 에이전트의 동작을 설명하는 데 도움이 될 수 있지만 대부분의 경우 LLM은 여전히 블랙박스입니다. 추가적인 해석 부담은 엔지니어링 팀에 있습니다.
02. AI Agent 핵심요소
에이전트 시스템이란 무엇입니까?
AI 에이전트 현황 보고서가 발표되기 전에 Langchain 팀은 에이전트 분야에 자체 Langraph 프레임 작성하고 In the Loop 블로그를 통해 AI 에이전트의 많은 주요 구성 요소에 대해 논의했습니다. 다음은 주요 내용을 편집한 것입니다.
우선 AI Agent에 대한 정의는 사람마다 조금씩 다릅니다. LangChain의 창립자인 Harrison Chase는 다음과 같이 정의했습니다.
AI 에이전트는 LLM을 사용하여 프로그램 제어 흐름 결정을 내리는 시스템입니다.
AI 에이전트는 LLM을 사용하여 애플리케이션의 제어 흐름을 결정하는 시스템입니다.
구현과 관련하여 이 기사에서는 인지 아키텍처의 개념을 소개합니다. 인지 아키텍처는 에이전트가 생각하는 방식과 시스템이 코드/프롬프트 LLM을 정렬하는 방식을 나타냅니다.
• 인지: 에이전트는 LLM을 사용하여 코드/프롬프트 LLM 배열 방법을 의미론적으로 추론합니다.
• 아키텍처: 이러한 에이전트 시스템에는 여전히 기존 시스템 아키텍처와 유사한 대량 엔지니어링이 필요합니다.
아래 그림은 다양한 수준의 인지 아키텍처의 예를 보여줍니다.
• 표준화된 소프트웨어 코드(코드): 모든 것이 하드 코드이며, 출력 또는 입력의 관련 매개변수가 소스 코드에 직접 고정되어 있습니다. 이는 인지적인 부분이 없기 때문에 인지 아키텍처를 구성하지 않습니다.
• LLM 호출(일부 데이터 전처리를 제외하고) 단일 LLM 호출이 애플리케이션의 대부분을 구성하며 간단한 Chatbot이 이 범주에 속합니다.
• 체인: 일련의 LLM 호출입니다. 체인은 문제 해결 방법을 여러 단계로 나누고 문제 해결을 위해 다른 LLM을 호출합니다. 복잡한 RAG가 이 범주에 속합니다. 첫 번째 LLM은 검색 및 쿼리를 위해 호출되고 두 번째 LLM은 답변을 생성하기 위해 호출됩니다.
• 라우터: 이전 세 시스템에서 사용자는 프로그램이 수행할 모든 단계를 미리 알 수 있지만 라우터에서는 LLM이 어떤 LLM을 호출하고 어떤 단계를 수행할지 자체적으로 결정하므로 더 많은 무작위성과 예측 불가능성이 추가됩니다.
• 라우터와 함께 LLM을 사용하는 상태 머신은 루프에 넣음으로써 시스템이 (이론적으로) 무제한 LLM 호출을 할 수 있기 때문에 훨씬 더 예측하기 어렵습니다.
• 에이전트 시스템: 사람들은 이를 "자율 에이전트"라고도 부릅니다. State Machine을 사용할 때 어떤 작업을 수행할 수 있는지, 작업을 수행한 후 어떤 프로세스를 수행할지에 대한 제한이 여전히 있지만 Autonomous Agent를 사용하면 이러한 제한이 제거됩니다. LLM은 수행할 단계와 다양한 LLM을 조정하는 방법을 결정합니다. 이는 다양한 프롬프트, 도구 또는 코드를 사용하여 수행할 수 있습니다.
간단히 말해서, 시스템이 "에이전트적"일수록 LLM이 시스템 작동 방식을 더 많이 결정합니다.
Agent의 핵심요소
계획
상담원의 신뢰성은 큰 문제점입니다. 에이전트를 구축하기 위해 LLM을 사용하는 회사가 종종 있지만 에이전트는 계획과 추론을 잘 할 수 없다고 언급합니다. 여기서 계획과 추론은 무엇을 의미합니까?
상담원의 계획 및 추론은 취해야 할 조치에 대해 생각하는 LLM의 능력을 나타냅니다. 여기에는 LLM이 사용 가능한 모든 정보를 평가한 후 다음을 결정하는 단기 및 장기 추론이 포함됩니다. 어떤 일련의 단계를 수행해야 하며 지금 취해야 할 첫 번째 단계는 무엇입니까?
많은 경우 개발자는 함수 호출을 사용하여 LLM이 수행할 작업을 선택하도록 합니다. 함수 호출은 OpenAI가 2023년 6월 LLM API에 처음 추가한 기능입니다. 함수 호출을 통해 사용자는 다양한 함수에 대한 JSON 구조를 제공하고 LLM이 구조 중 하나 이상과 일치하도록 할 수 있습니다.
복잡한 작업을 성공적으로 완료하려면 시스템이 일련의 작업을 수행해야 합니다. 이러한 종류의 장기 계획 및 추론은 LLM에게 매우 복잡합니다. 먼저 LLM은 장기 실행 계획을 고려한 다음 에이전트가 점점 더 많은 작업을 수행함에 따라 취해야 할 단기 조치로 돌아가야 합니다. , 작업 결과가 LLM으로 피드백되어 컨텍스트 창이 커지고 이로 인해 LLM이 "산만"해지고 성능이 저하될 수 있습니다.
계획을 개선하는 가장 쉬운 솔루션은 LLM이 적절한 추론/계획에 필요한 모든 정보를 갖추고 있는지 확인하는 것입니다. 간단해 보이지만 LLM에 전달된 정보만으로는 LLM이 합리적인 결정을 내리기에 충분하지 않은 경우가 많으며 검색 단계를 추가하거나 프롬프트를 명확하게 하는 것만으로도 간단한 개선이 될 수 있습니다.
그런 다음 애플리케이션의 인지 아키텍처 변경을 고려할 수 있습니다. 추론을 향상시키기 위한 인지 아키텍처에는 일반 인지 아키텍처와 영역별 인지 아키텍처라는 두 가지 범주가 있습니다.
1. 일반 인지 아키텍처
일반적인 인지 아키텍처는 모든 작업에 적용될 수 있습니다. 여기에는 두 가지 일반 아키텍처를 제안하는 두 개의 논문이 있습니다. 하나는 Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models 기사에서 제안된 "계획 및 해결" 아키텍처입니다. 아키텍처에서 에이전트는 먼저 계획을 제안한 다음 계획의 각 단계를 실행합니다. 또 다른 일반적인 아키텍처는 Reflexion: Language Agents with Verbal Reinforcement Learning에서 제안된 Reflexion 아키텍처입니다. 이 아키텍처에는 에이전트가 작업을 올바르게 수행했는지 여부를 반영하기 위해 작업을 수행한 후 명시적인 "반사" 단계가 있습니다. 여기서는 자세히 다루지 않겠지만 자세한 내용은 두 논문을 읽어보세요.
이러한 아이디어는 개선된 모습을 보여주지만 프로덕션 에이전트가 실제로 사용하기에는 너무 일반적인 경우가 많습니다. (번역자 주: 이 기사가 게재될 당시 o1 시리즈 모델은 없었습니다)
2. 영역별 인지 아키텍처
대신, 에이전트가 도메인별 인지 아키텍처를 사용하여 구축되었음을 알 수 있습니다. 이는 일반적으로 도메인별 분류/계획 단계, 도메인별 검증 단계에서 나타납니다. 계획과 성찰의 일부 아이디어가 여기에 적용될 수 있지만 일반적으로 도메인별 방식으로 적용됩니다.
AlphaCodium의 논문은 구체적인 예를 제시합니다. 최첨단 성능은 소위 "스트림 엔지니어링"(인지 아키텍처에 대해 말하는 또 다른 방법)을 사용하여 달성됩니다.
에이전트의 프로세스는 해결하려는 문제에 매우 구체적이라는 것을 알 수 있습니다. 에이전트에게 단계적으로 수행할 작업을 알려줍니다. 즉, 테스트를 제안한 다음 솔루션을 제안하고 추가 테스트를 반복하는 등의 작업을 수행합니다. 이러한 인지 아키텍처는 특정 분야에 고도로 집중되어 있으며 다른 분야로 일반화될 수 없습니다.
사례 연구:
Agent의 미래에 대한 Reflection AI 창립자 Laskin의 비전
Sequoia Capital의 Reflection AI 창립자 Misha Laskin과의 인터뷰에서 Misha는 RL의 검색 기능을 LLM 에이전트 모델과 결합하여 자신의 새 회사인 Reflection AI에서 최고의 검색 기능을 구축하려는 비전을 실현하기 시작했다고 언급했습니다. 그와 공동 창업자인 Ioannis Antonoglou(AlphaGo, AlphaZero, Gemini RLHF 대표)는 Agentic Workflows를 위해 설계된 훈련 모델입니다. 인터뷰의 주요 관점 다음과 같습니다.
• 깊이는 AI Agent에서 누락된 부분입니다. 현재 언어 모델은 폭 측면에서 뛰어나지만 작업을 안정적으로 완료하는 데 필요한 깊이가 부족합니다. Laskin은 진정으로 유능한 AI 에이전트를 만드는 데 "심층적인 문제"를 해결하는 것이 중요하다고 믿습니다. 여기서 기능은 여러 단계를 통해 복잡한 작업을 계획하고 실행할 수 있는 에이전트를 의미합니다.
• 학습과 검색을 결합하는 것이 초인적인 성과를 달성하는 열쇠입니다. 알파고의 성공을 토대로 라스킨은 AI의 가장 심오한 개념은 학습(LLM 활용)과 검색(최적 경로 찾기)의 조합이라고 강조했다. 이 접근 방식은 복잡한 작업에서 인간보다 뛰어난 성능을 발휘할 수 있는 에이전트를 만드는 데 중요합니다.
• 교육 후 및 보상 모델링은 상당한 과제를 안겨줍니다. 명확한 보상이 있는 게임과 달리 실제 작업에서는 실질적인 보상이 부족한 경우가 많습니다. 신뢰할 수 있는 보상 모델을 개발하는 것은 신뢰할 수 있는 AI 에이전트를 만드는 데 있어 핵심 과제입니다.
• 만능 대리인은 우리가 생각하는 것보다 더 가까이 있을 수 있습니다. Laskin은 폭과 깊이를 모두 갖춘 AI 시스템인 '디지털 AGI'를 달성하는 데 단 3년이 걸릴 수 있다고 추정합니다. 이렇게 가속화된 타임라인은 역량을 개발하는 동시에 안전 및 신뢰성 문제를 해결해야 하는 시급성을 강조합니다.
• Universal Agent로 가는 길에는 접근이 필요합니다. Reflection AI는 브라우저, 코딩, 컴퓨터 운영 체제 등 일부 특정 환경에서 시작하여 에이전트 기능을 확장하는 데 중점을 둡니다. 그들의 목표는 특정 작업에 국한되지 않는 Universal Agent를 개발하는 것입니다.
UI/UX 상호작용
앞으로 몇 년 안에 인간-컴퓨터 상호 작용은 연구의 핵심 영역이 될 것입니다. 에이전트 시스템은 대기 시간, 불안정성 및 자연어 인터페이스가 새로운 과제를 가져오기 때문에 과거의 기존 컴퓨터 시스템과 다릅니다. 결과적으로 이러한 에이전트 애플리케이션과 상호 작용하기 위한 새로운 UI/UX 패러다임이 등장할 것입니다. 에이전트 시스템은 아직 초기 단계에 있지만 몇 가지 새로운 UX 패러다임이 이미 등장하고 있습니다. 아래에서 논의됩니다.
1. 대화형 상호작용(채팅 UI)
채팅은 일반적으로 스트리밍 채팅과 비스트리밍 채팅의 두 가지 유형으로 구분됩니다.
스트리밍 채팅은 가장 일반적인 UX입니다. 생각과 행동을 채팅 형식으로 다시 스트리밍하는 Chatbot입니다. ChatGPT가 가장 인기 있는 예입니다. 이 상호 작용 모드는 단순해 보이지만 다음과 같은 이유로 좋은 결과도 있습니다. 첫째, 자연어를 사용하여 LLM과 대화할 수 있습니다. 즉, 고객과 LLM 사이에 장애물이 없으며, 둘째, LLM이 작동하는 데 시간이 걸릴 수 있습니다. , 스트리밍을 통해 사용자는 백그라운드에서 무슨 일이 일어나고 있는지 정확하게 이해할 수 있습니다. 셋째, LLM은 종종 실수를 저지르며, Chat은 이를 자연스럽게 수정하고 안내할 수 있는 훌륭한 인터페이스를 제공하며, 모두가 채팅에서 후속 대화와 반복을 하는 데 매우 익숙해졌습니다. 것들.
그러나 스트리밍 채팅에는 단점도 있습니다. 첫째, 스트리밍 채팅은 상대적으로 새로운 사용자 경험이므로 기존 채팅 플랫폼(iMessage, Facebook Messenger, Slack 등)에는 이러한 기능이 없습니다. 둘째, 장시간 실행되는 작업의 경우 다소 어색합니다. 그냥 앉아서 에이전트가 작동하는 것을 지켜보기만 하면 되나요? 셋째, 스트리밍 채팅은 일반적으로 사람에 의해 시작되어야 합니다. 즉, 루프에 대량 사람이 필요합니다.
비스트리밍 채팅과의 가장 큰 차이점은 응답이 일괄적으로 반환되고, LLM이 백그라운드에서 작동하며, 사용자가 LLM이 즉시 응답하기 위해 서두르지 않는다는 점입니다. 즉, 기존 워크플로에 통합하는 것이 더 쉬울 수 있습니다. 사람들은 이미 인간에게 문자 메시지를 보내는 데 익숙합니다. 왜 AI를 사용한 문자 메시지에 적응할 수 없습니까? 스트리밍되지 않는 채팅을 사용하면 보다 복잡한 상담원 시스템과 더 쉽게 상호 작용할 수 있습니다. 이러한 시스템은 종종 시간이 걸리므로 즉각적인 응답이 기대되는 경우 실망스러울 수 있습니다. 스트리밍되지 않는 채팅은 종종 이러한 기대를 없애고 더 복잡한 작업을 더 쉽게 수행할 수 있게 해줍니다.
이 두 가지 채팅 방법에는 다음과 같은 장점과 단점이 있습니다.
2. 백그라운드 환경(Ambient UX)
사용자는 위에서 언급한 Chat인 AI에 메시지를 보내는 것을 고려할 것입니다. 그러나 Agent가 백그라운드에서만 작동한다면 Agent와 어떻게 상호 작용해야 할까요?
에이전트 시스템이 진정한 잠재력을 발휘하려면 AI가 백그라운드에서 작동할 수 있도록 하는 이러한 변화가 필요합니다. 사용자는 일반적으로 작업이 백그라운드에서 처리될 때 더 긴 완료 시간에 더 관대합니다(낮은 대기 시간에 대한 기대를 완화하기 때문입니다). 이를 통해 상담원은 더 많은 작업을 수행할 수 있으며 일반적으로 채팅 UX보다 더 신중하고 부지런히 추론할 수 있습니다.
또한 백그라운드에서 에이전트를 실행하면 인간 사용자의 능력이 확장됩니다. 채팅 인터페이스는 종종 한 번에 하나의 작업으로 제한됩니다. 그러나 에이전트가 백그라운드 환경에서 실행 중인 경우 동시에 여러 작업을 처리하는 에이전트가 많이 있을 수 있습니다.
에이전트를 백그라운드에서 실행하려면 사용자 신뢰가 필요합니다. 이 신뢰를 설정하는 방법은 무엇입니까? 간단한 아이디어: 에이전트가 수행하는 작업을 사용자에게 정확하게 보여줍니다. 수행 중인 모든 단계를 표시하고 사용자가 무슨 일이 일어나고 있는지 관찰할 수 있도록 합니다. 이러한 단계는 응답을 스트리밍할 때와 같이 즉시 표시되지 않을 수 있지만 사용자가 클릭하고 관찰할 수 있어야 합니다. 다음 단계는 사용자가 무슨 일이 일어나고 있는지 볼 수 있을 뿐만 아니라 에이전트를 수정하도록 하는 것입니다. 10단계 중 4단계에서 에이전트가 잘못된 선택을 한 것을 발견한 경우 클라이언트는 4단계로 돌아가 어떤 방식으로든 에이전트를 수정할 수 있습니다.
이 접근 방식은 사용자를 "In-the-loop"에서 "On-the-loop"로 이동시킵니다. '온더루프'를 위해서는 에이전트가 수행하는 모든 중간 단계를 사용자에게 표시하여 사용자가 중간에 워크플로를 일시 중지하고 피드백을 제공한 다음 에이전트가 계속되도록 할 수 있어야 합니다.
AI 소프트웨어 엔지니어인 Devin은 유사한 UX를 구현하는 애플리케이션입니다. Devin을 실행하는 데 시간이 더 걸리지만 고객은 수행된 모든 단계를 확인하고 특정 시점에서 개발 상태를 되돌리고 거기에서 수정 사항을 발행할 수 있습니다. 에이전트가 백그라운드에서 실행될 수 있다고 해서 완전히 자율적으로 작업을 수행해야 한다는 의미는 아닙니다. 에이전트가 무엇을 해야 할지, 어떻게 대응해야 할지 모르는 경우가 있는데, 이 경우 사람의 주의를 끌고 도움을 요청해야 합니다.
한 가지 구체적인 예는 해리슨 요원이 구축하고 있는 이메일 도우미입니다. 이메일 도우미는 기본 이메일에 응답할 수 있지만 복잡한 LangChain 버그 보고서 검토, 회의 참석 여부 결정 등을 포함하여 해리슨이 자동화하고 싶지 않은 특정 작업을 입력해야 하는 경우가 많습니다. 이 경우 이메일 도우미는 응답하려면 정보가 필요하다는 사실을 해리슨에게 전달할 수 있는 방법이 필요합니다. 직접적인 답변을 요구하는 것이 아니라 특정 작업에 대한 해리슨의 의견을 요구하며, 이를 사용하여 멋진 이메일을 작성하고 보내거나 캘린더 초대장을 예약할 수 있습니다.
현재 Harrison은 Slack에 어시스턴트를 설정했습니다. 해리슨에게 질문을 보내고 해리슨은 워크플로에 기본적으로 통합된 대시보드에서 답변합니다. 이러한 유형의 UX는 고객 지원 대시보드의 UX와 유사합니다. 이 인터페이스는 어시스턴트가 사람의 도움이 필요한 모든 영역, 요청 우선순위 및 기타 데이터를 표시합니다.
3. 스프레드시트 UX
스프레드시트 UX는 일괄 처리 작업을 지원하는 매우 직관적이고 사용자 친화적인 방법입니다. 각 테이블 또는 각 열은 특정 사항을 연구하기 위한 자체 에이전트가 됩니다. 이 일괄 처리를 통해 사용자는 여러 에이전트와의 상호 작용을 확장할 수 있습니다.
이 UX에는 또 다른 이점이 있습니다. 스프레드시트 형식은 대부분의 사용자에게 친숙한 UX이므로 기존 워크플로우에 잘 맞습니다. 이러한 유형의 UX는 각 열이 강화할 서로 다른 속성을 나타낼 수 있는 일반적인 LLM 사용 사례인 데이터 강화에 이상적입니다.
Exa AI, Clay AI, Manaflow 및 기타 회사의 제품이 이 UX를 사용하고 있습니다. 다음은 Manaflow를 예로 들어 이 스프레드시트 UX가 워크플로우를 처리하는 방법을 보여줍니다.
사례 연구:
Manaflow가 에이전트 상호 작용을 위해 스프레드시트를 사용하는 방법
Manaflow는 창립자 Lawrence가 근무했던 회사인 Minion AI에서 영감을 받아 제작한 제품이 Web Agent입니다. 웹 에이전트는 로컬 Google Chrome을 제어하여 항공편 예약, 이메일 전송, 세차 예약 등의 애플리케이션과 상호 작용할 수 있습니다. Manaflow는 Minion AI에서 영감을 받아 Agent가 스프레드시트와 같은 도구를 작동하도록 선택했습니다. 이는 Agent가 인간 UI 인터페이스를 잘 처리하지 못하기 때문입니다. 따라서 Manaflow를 사용하면 Agent가 UI 인터페이스, 데이터베이스 인터페이스, 링크 API의 Python 스크립트를 호출한 후 읽기 시간, 예약, 이메일 보내기 등을 포함한 데이터베이스를 직접 작동할 수 있습니다.
워크플로는 다음과 같습니다. 매나플로우의 주요 인터페이스는 스프레드시트(Manasheet)로, 각 열은 워크플로의 단계를 나타내고, 각 행은 작업을 수행하는 AI 에이전트에 해당합니다. 각 스프레드시트 워크플로우는 자연어를 사용하여 프로그래밍할 수 있습니다(기술에 익숙하지 않은 사용자도 자연어로 작업 및 단계를 설명할 수 있음). 각 스프레드시트에는 각 열이 실행되는 순서를 결정하는 내부 종속성 그래프가 있습니다. 이러한 시퀀스는 에이전트의 각 행에 할당되어 작업을 병렬로 실행하고 데이터 변환, API 호출, 콘텐츠 검색 및 메시지 전송과 같은 프로세스를 처리합니다.
마나시트를 생성할 수 있는 방법은 위의 빨간색 상자에 있는 것과 유사한 자연어를 입력하는 것입니다. 예를 들어, 위 그림에서 고객에게 가격 이메일을 보내려면 채팅을 통해 프롬프트를 입력하여 마나시트를 생성할 수 있습니다. . 마나시트를 통해 고객의 이름, 고객의 이메일, 고객의 업종, 이메일 발송 여부 등의 정보를 확인할 수 있으며, 마나시트 실행을 클릭하면 작업이 실행됩니다.
4. 생성 UI
"생성 UI"에는 두 가지 구현이 있습니다.
한 가지 방법은 모델이 필요한 기본 구성요소를 자체적으로 생성하도록 하는 것입니다. 이는 Websim과 같은 제품과 유사합니다. 뒤에서 에이전트는 주로 원시 HTML을 작성하여 표시되는 내용을 완전히 제어할 수 있습니다. 그러나 이 접근 방식은 생성된 웹 앱의 품질에 높은 불확실성을 허용하므로 최종 결과가 불안정해 보일 수 있습니다.
좀 더 제한적인 또 다른 접근 방식은 일반적으로 도구 호출을 통해 일부 UI 구성 요소를 미리 정의하는 것입니다. 예를 들어 LLM이 날씨 API를 호출하면 날씨 지도 UI 구성 요소의 렌더링이 트리거됩니다. 렌더링된 구성 요소는 실제로 생성되지는 않지만(그러나 더 많은 옵션이 있음) 생성된 UI는 생성할 수 있는 내용이 완전히 유연하지는 않더라도 더 세련됩니다.
사례 연구:
개인 AI 제품 도트
예를 들어 2024년 최고의 개인 AI 제품으로 꼽혔던 Dot은 좋은 생성 UI 제품입니다.
Dot은 New Computer의 제품입니다. Dot의 목표는 더 나은 작업 관리 도구가 아니라 사용자의 장기적인 동반자가 되는 것입니다. 공동 창립자 Jason Yuan에 따르면 Dot의 느낌은 어디로 가야할지 모를 때입니다. 또는 무엇을 해야 하는지 또는 무엇을 말해야 하는지에 관해서는 Dot을 선택하세요. 다음은 제품의 기능을 소개하는 두 가지 예입니다.
• 창업자 제이슨 유안은 술에 취해 쉬고 싶다며 닷에게 밤늦게까지 술집을 추천해 달라고 자주 부탁했다. 이는 퇴근 후 몇 달 동안 계속됐고 닷은 이를 반복했다. 실제로 제이슨은 이미 이런 식으로 계속할 수 없다고 설득하기 시작했습니다.
• Fast Company 기자 Mark Wilson도 Dot에서 몇 달을 보냈습니다. 한번은 그가 캘리그라피 수업에서 쓴 "O"를 Dot에게 공유한 적이 있습니다. Dot는 실제로 몇 주 전에 자신이 직접 쓴 "O" 사진을 꺼내서 그의 서예 실력이 향상되었다고 칭찬했습니다.
• Dot을 사용하는 시간이 늘어날수록 Dot은 사용자가 카페를 방문하는 것을 더 잘 이해하고, 이 카페가 좋은 이유를 포함하여 주인 근처의 좋은 카페를 적극적으로 추천하고, 마침내 길을 가고 싶은지 신중하게 묻습니다.
이 카페 추천 예시에서 Dot은 사전 정의된 UI 구성 요소를 통해 LLM 기본 상호 작용 효과를 달성하는 것을 볼 수 있습니다.
5. 협업 UX
에이전트와 사람이 함께 작업하면 어떤 일이 발생하나요? 고객이 팀원과 협력하여 문서를 작성하거나 편집할 수 있는 Google Docs를 생각해 보세요. 하지만 공동작업자 중 한 명이 상담원이라면 어떻게 될까요?
Geoffrey Litt 와 Ink & Switch 의 Patchwork 프로젝트는 인간-에이전트 협업의 좋은 예입니다. (역자 주: 이는 최근 OpenAI Canvas 제품 업데이트에 영감을 준 것일 수 있습니다.)
협업 UX는 앞서 논의한 Ambient UX와 어떻게 비교됩니까? LangChain 창립 엔지니어 Nuno는 둘 사이의 주요 차이점은 동시성이 있는지 여부라고 강조했습니다.
• 협업 UX 에서는 클라이언트와 LLM이 동시에 작업하여 서로의 작업을 입력으로 받아들이는 경우가 많습니다.
• 주변 UX 에서 LLM은 사용자가 다른 것에 완전히 집중하는 동안 백그라운드에서 계속 작동합니다.
메모리
좋은 에이전트 경험을 위해서는 메모리가 매우 중요합니다. 당신이 말한 내용을 전혀 기억하지 못하는 동료가 있어서 계속해서 정보를 반복하도록 강요한다면 이는 매우 열악한 공동 작업 경험이 될 것입니다. 사람들은 LLM 시스템이 타고난 기억을 갖고 있다고 기대하는 경우가 많습니다. 아마도 LLM이 이미 인간과 매우 유사하다고 느끼기 때문일 것입니다. 그러나 LLM 자체는 아무것도 기억하지 못합니다.
에이전트의 메모리는 제품 자체의 요구 사항을 기반으로 하며, 다양한 UX는 정보를 수집하고 피드백을 업데이트하는 다양한 방법을 제공합니다. Agent 제품의 메모리 메커니즘에서 다양한 고급 메모리 유형을 볼 수 있습니다. 이는 인간의 메모리 유형을 모방하고 있습니다.
CoALA: Cognitive Architectures for Language Agents 논문은 인간의 메모리 유형을 에이전트 메모리에 매핑하며, 분류 방법은 아래 그림과 같습니다.
1. 절차적 기억: 작업 수행 방법에 대한 장기 기억으로, 뇌의 핵심 명령 세트와 유사합니다.
• 인간의 절차적 기억: 자전거 타는 방법을 기억합니다.
• 에이전트의 절차적 메모리: CoALA 문서에서는 절차적 메모리를 에이전트 작동 방식을 근본적으로 결정하는 LLM 가중치와 에이전트 코드의 조합으로 설명합니다.
실제로 Langchain 팀은 에이전트 시스템이 자동으로 LLM을 업데이트하거나 코드를 다시 작성하는 것을 본 적이 없지만 실제로 에이전트가 시스템 프롬프트를 업데이트하는 몇 가지 예가 있습니다.
2. 의미기억: 장기 지식 보유
• 인간 의미기억: 학교에서 배운 사실, 개념, 이들 간의 관계 등의 정보 조각으로 구성됩니다.
• 에이전트의 의미 기억: CoALA 논문에서는 의미 기억을 사실 저장소로 설명합니다.
실제로 이는 LLM을 사용하여 에이전트의 대화나 상호 작용에서 정보를 클레임 함으로써 달성되는 경우가 많습니다. 이 정보가 정확히 어떻게 저장되는지는 일반적으로 애플리케이션마다 다릅니다. 그런 다음 이 정보는 향후 대화에서 검색되고 시스템 프롬프트에 삽입되어 에이전트의 응답에 영향을 줍니다.
3. 일화기억(Episodic Memory): 과거의 특정 사건을 회상하는 것
• 인간의 일화 기억: 사람이 과거에 경험한 특정 사건(또는 "일화")을 회상하는 경우.
• 에이전트의 에피소드 메모리: CoALA 논문에서는 에피소드 메모리를 에이전트의 과거 작업 시퀀스를 저장하는 것으로 정의합니다.
이는 주로 에이전트가 예상대로 작업을 수행하도록 하는 데 사용됩니다. 실제로 에피소드 메모리는 Few-Shots Prompt 방법을 통해 업데이트됩니다. 관련 업데이트에 대한 Few-Shots 프롬프트가 충분하면 다음 업데이트는 동적 Few-Shots 프롬프트를 통해 완료됩니다.
처음에 에이전트가 작업을 올바르게 완료하도록 안내하는 방법이 있는 경우 나중에 동일한 문제가 대면 하거나 올바른 작업 방법이 없거나 에이전트가 계속 새로운 작업을 수행하는 경우 이 방법을 직접 사용할 수 있습니다. 그렇다면 의미기억이 더 중요하겠지만 앞의 예에서는 의미기억이 별로 도움이 되지 않을 것입니다.
에이전트에서 업데이트할 메모리 유형을 고려하는 것 외에도 개발자는 에이전트 메모리를 업데이트하는 방법도 고려해야 합니다.
에이전트의 메모리를 업데이트하는 첫 번째 방법은 "핫 경로" 입니다. 이 경우 에이전트 시스템은 응답하기 전에 사실을 기억하고(일반적으로 도구 호출을 통해) ChatGPT는 이 접근 방식을 사용하여 메모리를 업데이트합니다.
에이전트의 메모리를 업데이트하는 또 다른 방법은 "백그라운드에서" 입니다. 이 경우 세션 후에 백그라운드 프로세스가 실행되어 메모리를 업데이트합니다.
두 접근 방식을 비교하면 "핫 경로" 접근 방식의 단점은 응답이 전달되기 전에 약간의 지연이 있고 메모리 로직과 에이전트 로직을 결합해야 한다는 것입니다.
그러나 "백그라운드에서"는 이러한 문제를 방지합니다. 대기 시간이 추가되지 않으며 메모리 논리가 독립적으로 유지됩니다. 그러나 "백그라운드"에는 고유한 단점이 있습니다. 즉, 메모리가 즉시 업데이트되지 않으며 백그라운드 프로세스를 시작할 시기를 결정하기 위해 추가 논리가 필요합니다.
메모리를 업데이트하는 또 다른 방법에는 사용자 피드백이 포함되며, 이는 특히 에피소드 메모리와 관련이 있습니다. 예를 들어 사용자가 상호작용(포스트 피드백)에 높은 평점을 준 경우 상담원은 향후 통화를 위해 피드백을 저장할 수 있습니다.
위의 정리된 내용을 바탕으로 계획, 상호작용, 기억의 세 가지 구성 요소가 동시에 발전하면 2025년에는 더 많은 AI 에이전트가 등장하고 인간-기계 협업의 새로운 시대로 진입할 수 있을 것으로 기대합니다.
