컨텍스트에 대한 이해 - 2부: 에이전트 AI와 컨텍스트 엔지니어링의 필요성

Agent Builder는 현재 기술 미리보기 버전으로 제공됩니다. Elastic Cloud 체험판으로 시작한 뒤, Agent Builder 문서를 여기에서 확인하세요.

LLM이 정보 검색의 기본 프로세스를 변화시킨 방식에 대한 (상당히 광범위한) 배경 지식을 바탕으로, 데이터 쿼리 방식도 어떻게 변화시켰는지 살펴봅시다.

데이터와 상호 작용하는 새로운 방법

제너레이티브(genAI) 및 에이전트 AI는 기존 검색과는 다른 방식으로 작업을 수행합니다. 과거에는 검색("구글에 검색해 볼게요...")을 통해 정보 조사를 시작했지만, 세대별 AI와 상담원 모두 채팅 인터페이스에 자연어를 입력하는 것이 시작 작업의 대부분을 차지합니다. 채팅 인터페이스는 LLM과의 토론으로, 의미론적 이해를 바탕으로 우리의 질문을 모든 종류의 정보에 대한 폭넓은 지식을 가진 오라클이 제공하는 것처럼 보이는 요약된 답변으로 바꿔줍니다. LLM의 진정한 매력은 드러나는 지식의 조각들을 하나로 묶어 일관성 있고 사려 깊은 문장을 만들어내는 능력입니다. 부정확하거나 완전히 환각적인 내용일지라도 진실성이 담겨 있습니다.

우리가 익숙한 검색창은 우리가 직접 추론 에이전트였을 때 사용했던 RAG 엔진이라고 생각할 수 있습니다. 이제 인터넷 검색 엔진도 기존의 '사냥과 쪼기' 방식의 어휘 검색 경험을 AI 기반 개요로 전환하여 검색어에 대한 답변과 결과 요약을 제공함으로써 사용자가 개별 결과를 직접 클릭하고 평가할 필요가 없도록 돕고 있습니다.

제너레이티브 AI & RAG

생성형 AI는 세상에 대한 의미론적 이해를 바탕으로 채팅 요청에 명시된 주관적 의도를 분석한 다음 추론 능력을 사용하여 즉석에서 전문가 답변을 생성합니다. 생성형 AI 상호작용에는 사용자의 입력/질문으로 시작하여 채팅 세션의 이전 대화를 추가 컨텍스트로 사용할 수 있으며, LLM에 추론 방법과 응답을 구성할 때 따라야 할 절차를 알려주는 지시 프롬프트 등 여러 부분이 있습니다. 안내 메시지는 " "5살짜리 아이처럼 설명해 주세요"라는 단순한 안내에서 요청 처리 방법에 대한 완전한 분석으로 발전했습니다. 이러한 분류에는 종종 AI의 페르소나/역할, 생성 전 추론/내부 사고 과정, 객관적 기준, 제약 조건, 출력 형식, 대상에 대한 세부 사항을 설명하는 별도의 섹션과 예상 결과를 입증하는 데 도움이 되는 예시가 포함됩니다.

검색 증강 생성(RAG)은 사용자의 쿼리와 시스템 프롬프트 외에도 "컨텍스트 창"이라고 하는 추가 컨텍스트 정보를 제공합니다. RAG는 아키텍처에 중요한 추가 기능으로, LLM이 세계를 의미론적으로 이해하는 데 있어 누락된 부분을 알려주는 데 사용됩니다.

컨텍스트 창은 무엇을, 어디에, 얼마나 제공해야 하는지에 대해 다소 까다로울 수 있습니다. 물론 어떤 컨텍스트가 선택되는지도 매우 중요하지만, 제공된 컨텍스트의 신호 대 잡음비와 창 길이도 중요합니다.

너무 적은 정보

쿼리, 프롬프트 또는 컨텍스트 창에 너무 적은 정보를 제공하면 LLM이 응답을 생성할 올바른 의미적 컨텍스트를 정확하게 판단할 수 없기 때문에 착각이 발생할 수 있습니다. 문서 청크 크기의 벡터 유사성에도 문제가 있습니다. 짧고 간단한 질문이 벡터화된 지식창고에 있는 풍부하고 상세한 문서와 의미적으로 일치하지 않을 수 있습니다. 가상의 문서 임베딩(HyDE) 과 같은 쿼리 확장 기법이 개발되어 LLM을 사용하여 짧은 쿼리보다 더 풍부하고 표현력이 풍부한 가상의 답변을 생성할 수 있습니다. 물론 여기서 위험은 가상의 문서 자체가 올바른 맥락에서 더욱 멀어지게 하는 환각이라는 점입니다.

너무 많은 정보

우리 인간과 마찬가지로, 컨텍스트 창에 너무 많은 정보가 있으면 LLM이 중요한 부분이 무엇인지 압도당하고 혼란스러워할 수 있습니다. 컨텍스트 오버플로(또는 "컨텍스트 썩음")는 생성 AI 작업의 품질과 성능에 영향을 미치며, LLM의 "주의 예산"(작업 메모리)에 큰 영향을 미치고 여러 경쟁 토큰 간의 관련성을 희석시킵니다. '컨텍스트 썩음'의 개념에는 LLM이 중간 섹션의 콘텐츠보다 컨텍스트 창의 시작 또는 끝에 있는 콘텐츠를 선호하는 위치 편향이 있다는 관찰 결과도 포함됩니다.

산만하거나 상충되는 정보

컨텍스트 창이 커질수록 불필요하거나 상충되는 정보가 포함될 가능성이 높아져 LLM이 올바른 컨텍스트를 선택하고 처리하는 데 방해가 될 수 있습니다. 어떤 면에서는 가비지 인/가비지 아웃의 문제가 됩니다. 문서 결과 집합을 컨텍스트 창에 덤핑하는 것만으로도 LLM이 처리해야 할 정보가 너무 많지만, 컨텍스트가 어떻게 선택되었는지에 따라 상충되거나 관련 없는 정보가 스며들 가능성이 더 커질 수 있기 때문입니다.

에이전틱 AI

다뤄야 할 내용이 많다고 말씀드렸지만, 드디어 에이전트 AI 주제에 대해 이야기하게 되었습니다! 에이전트 AI는 사용자가 제공한 지식과 문맥 정보를 바탕으로 답변을 합성하는 제너레이티브 AI의 (이미 '레거시'라고 불러도 될까요?) 기능을 확장한 LLM 채팅 인터페이스의 매우 흥미로운 새로운 사용법입니다. 제너레이티브 AI가 더욱 성숙해지면서 처음에는 사람이 쉽게 확인/검증할 수 있는 지루하고 위험도가 낮은 활동으로 한정했던 작업을 LLM이 수행할 수 있는 일정 수준의 작업과 자동화가 가능하다는 것을 깨달았습니다. 짧은 기간 동안 초기 범위가 확장되어 이제 LLM 채팅 창은 AI 에이전트가 자율적으로 계획을 수립하고 실행하며 지정된 목표를 달성하기 위해 계획을 반복적으로 평가하고 조정하도록 하는 촉매제가 될 수 있습니다. 상담원은 LLM의 추론, 채팅 기록 및 사고 기억(있는 그대로)에 액세스할 수 있으며, 이러한 목표를 위해 활용할 수 있는 특정 도구도 마련되어 있습니다. 또한 최상위 에이전트가 각각 고유한 로직 체인, 명령어 세트, 컨텍스트 및 도구를 갖춘 여러 하위 에이전트의 오케스트레이터로 기능할 수 있는 아키텍처도 등장하고 있습니다.

상담원은 대부분 자동화된 워크플로우의 시작점으로, 사용자와 채팅한 다음 '로직'을 사용하여 사용자의 질문에 답할 수 있는 도구를 결정할 수 있다는 점에서 자기 주도적입니다. 도구는 일반적으로 에이전트에 비해 수동적인 것으로 간주되며 한 가지 유형의 작업을 수행하도록 만들어집니다. 툴이 수행할 수 있는 작업의 유형은 무궁무진하지만(정말 흥미롭습니다!) 툴이 수행하는 주요 작업은 상담원이 워크플로우를 실행할 때 고려할 수 있도록 컨텍스트 정보를 수집하는 것입니다.

에이전트 AI는 아직 초기 단계의 기술로서 주의력 결핍 장애에 해당하는 LLM에 취약하며, 요청받은 작업을 쉽게 잊어버리고 업무에 전혀 포함되지 않은 다른 일을 하러 도망가는 경우가 많습니다. 겉보기에는 마술처럼 보이지만, LLM의 '추론' 능력은 여전히 시퀀스에서 다음으로 가능성이 높은 토큰을 예측하는 것을 기반으로 합니다. 추론(또는 언젠가는 인공 일반 지능(AGI)이)이 신뢰할 수 있고 신뢰할 수 있으려면 정확한 최신 정보가 주어졌을 때 우리가 기대하는 방식으로 추론할 수 있는지(그리고 우리가 미처 생각하지 못했던 것을 조금 더 제공할 수도 있는지) 검증할 수 있어야 합니다. 이를 위해서는 에이전트 아키텍처가 명확하게 커뮤니케이션하고(프로토콜), 워크플로와 제약 조건을 준수하며(가드레일), 작업의 현재 위치를 기억하고(상태), 사용 가능한 메모리 공간을 관리하고, 응답이 정확하고 작업 기준을 충족하는지 검증할 수 있는 기능이 필요합니다.

내가 이해할 수 있는 언어로 대화하기

새로운 개발 영역에서 흔히 그렇듯이(특히 LLM의 세계에서는 더욱 그렇습니다) 처음에는 에이전트 간 커뮤니케이션을 위한 여러 가지 접근 방식이 있었지만, 사실상의 표준인 모델 컨텍스트 프로토콜(MCP) 로 빠르게 수렴되었습니다. 모델 컨텍스트 프로토콜의 정의는 이름 그대로 모델이 컨텍스트 정보를 요청하고 수신하는 데 사용하는 프로토콜입니다. MCP는 LLM 에이전트가 외부 도구 및 데이터 소스에 연결할 수 있는 범용 어댑터 역할을 하며, 서로 다른 LLM 프레임워크와 도구가 쉽게 상호 운용될 수 있도록 API를 단순화하고 표준화합니다. 따라서 MCP는 에이전트가 목표를 달성하기 위해 자율적으로 수행하도록 에이전트에 제공되는 오케스트레이션 로직 및 시스템 프롬프트와 보다 격리된 방식으로 수행하도록 툴로 전송되는 작업(적어도 시작 에이전트와 관련해서는 격리된) 사이의 일종의 구심점 역할을 합니다.

이 에코시스템은 모든 방향이 새로운 개척지처럼 느껴질 정도로 모든 것이 새롭습니다. 에이전트 간 상호작용을 위한 유사한 프로토콜(에이전트2에이전트(A2A) natch!)과 에이전트 추론 메모리 개선(ReasoningBank), 현재 작업에 가장 적합한 MCP 서버 선택(RAG-MCP), 입력 및 출력의 제로 샷 분류 및 패턴 감지 등의 의미 분석을 가드레일로 사용하여 에이전트의 작업 허용 대상을 제어하기 위한 다른 프로젝트도 있습니다.

이러한 각 프로젝트의 기본 의도가 에이전트/genAI 컨텍스트 창에 반환되는 정보의 품질과 제어를 개선하는 것임을 눈치채셨나요? 에이전트 AI 생태계가 컨텍스트 정보를 더 잘 처리(제어, 관리 및 운영)할 수 있는 기능을 계속 개발하는 동안에도 에이전트가 밀링할 수 있는 가장 관련성 높은 컨텍스트 정보를 검색해야 할 필요성은 항상 존재할 것입니다.

컨텍스트 엔지니어링에 오신 것을 환영합니다!

제너레이티브 AI 용어에 익숙하다면 '프롬프트 엔지니어링'에 대해 들어보셨을 텐데요, 지금은 거의 유사 과학에 가깝다고 할 수 있습니다. 프롬프트 엔지니어링은 LLM이 응답을 생성할 때 사용할 동작을 사전에 설명하는 가장 효율적인 최선의 방법을 찾는 데 사용됩니다. '컨텍스트 엔지니어링'은 '프롬프트 엔지니어링' 기술을 에이전트 측면을 넘어 MCP 프로토콜의 도구 측면에서 사용 가능한 컨텍스트 소스 및 시스템까지 포함하도록 확장하며, 컨텍스트 관리, 처리 및 생성에 대한 광범위한 주제를 다룹니다:

• 컨텍스트 관리 - 장기 실행 및/또는 복잡한 상담원 워크플로 전반에서 상태 및 컨텍스트 효율성을 유지하는 것과 관련이 있습니다. 상담원의 목표를 달성하기 위한 작업 및 도구 호출의 반복적인 계획, 추적 및 오케스트레이션. 상담원이 작업할 수 있는 '주의 예산'이 제한되어 있기 때문에 컨텍스트 관리는 주로 컨텍스트 창을 세분화하여 전체 범위와 가장 중요한 컨텍스트(정확도 대비 회상률!)를 모두 포착하는 데 도움이 되는 기술과 관련이 있습니다. 압축, 요약, 이전 단계 또는 도구 호출의 컨텍스트를 유지하여 작업 메모리에 후속 단계의 추가 컨텍스트를 위한 공간을 확보하는 기술 등이 있습니다.
• 컨텍스트 처리 - 에이전트가 모든 컨텍스트를 다소 일관된 방식으로 추론할 수 있도록 서로 다른 소스에서 얻은 컨텍스트를 통합, 정규화 또는 정제하는 논리적이고 대부분 프로그램적인 단계입니다. 기본 작업은 에이전트가 최대한 효율적으로 소비할 수 있는 모든 소스(프롬프트, RAG, 메모리 등)에서 컨텍스트를 만드는 것입니다.
• 컨텍스트 생성 - 컨텍스트 처리가 검색된 컨텍스트를 상담원이 사용할 수 있도록 만드는 것이라면 컨텍스트 생성은 상담원이 마음대로 추가 컨텍스트 정보를 요청하고 수신할 수 있는 기능을 제공하지만 제약 조건도 함께 제공합니다.

LLM 채팅 애플리케이션의 다양한 형태는 컨텍스트 엔지니어링의 높은 수준의 기능에 직접적으로(때로는 중복되는 방식으로) 매핑됩니다:

• 지침/시스템 프롬프트 - 프롬프트는 생성(또는 에이전트) AI 활동이 사용자의 목표를 달성하기 위해 어떻게 사고를 유도할지에 대한 발판이 됩니다. 프롬프트는 그 자체로 컨텍스트이며, 단순한 톤의 지시가 아니라 사용자의 요청을 완전히 충족하는지 확인하기 위해 응답하기 전에 '단계별로 생각하기', '심호흡하기' 등의 작업 실행 로직과 규칙이 포함되어 있는 경우가 많습니다. 최근 테스트에 따르면 마크업 언어는 프롬프트의 여러 부분을 구성하는 데 매우 효과적이지만 너무 모호한 것과 너무 구체적인 것 사이의 적절한 지점으로 지침을 조정하는 데에도 주의를 기울여야 합니다. 우리는 LLM이 올바른 맥락을 찾을 수 있도록 충분한 지침을 제공하되 너무 규범적이어서 예상치 못한 통찰력을 놓치지 않기를 원합니다.
• 단기 메모리 (상태/기록) - 단기 메모리는 본질적으로 사용자와 LLM 간의 채팅 세션 상호작용입니다. 이는 라이브 세션에서 컨텍스트를 구체화하는 데 유용하며, 나중에 검색하고 계속 사용할 수 있도록 저장할 수 있습니다.
• 장기 기억 - 장기 기억은 여러 세션에 걸쳐 유용한 정보로 구성되어야 합니다. 또한 RAG를 통해 액세스하는 도메인별 지식 기반뿐만 아니라, 최근 연구에서는 이전 에이전트/제너레이티브 AI 요청의 결과를 사용하여 현재 에이전트 상호 작용 내에서 학습하고 참조할 수 있습니다. 장기 기억 공간에서 가장 흥미로운 혁신 중 일부는 에이전트가 중단한 부분을 다시 시작할 수 있도록 상태를 저장하고 연결하는 방식을 조정하는 것과 관련이 있습니다.
• 구조화된 출력 - 인지에는 노력이 필요하므로 추론 능력이 있더라도 (인간과 마찬가지로) LLM도 생각할 때 노력을 덜 들이고 싶어하며, 정의된 API나 프로토콜이 없는 경우 도구 호출에서 반환된 데이터를 읽는 방법에 대한 맵(스키마)이 있으면 매우 유용하다는 것은 놀라운 일이 아닐 수 없습니다. 에이전트 프레임워크의 일부로 구조화된 출력을 포함하면 이러한 기계 간 상호 작용을 더 빠르고 안정적으로 수행할 수 있으며, 사고에 기반한 구문 분석이 덜 필요하게 됩니다.
• 사용 가능한 도구 - 도구는 추가 정보 수집(예: 엔터프라이즈 데이터 리포지토리에 대한 RAG 쿼리 발행 또는 온라인 API를 통한)부터 상담원을 대신하여 자동화된 작업 수행(예: 상담원의 요청 기준에 따라 호텔 객실 예약)까지 모든 종류의 작업을 수행할 수 있습니다. 도구는 자체 에이전트 처리 체인을 가진 하위 에이전트가 될 수도 있습니다.
• 검색 증강 생성(RAG) - "동적 지식 통합"이라는 RAG에 대한 설명이 정말 마음에 듭니다. 앞서 설명한 것처럼 RAG는 학습할 때 LLM이 접근하지 못했던 추가 정보를 제공하거나 정답을 얻기 위해 가장 중요하다고 생각되는 아이디어, 즉 주관적인 질문과 가장 관련성이 높은 아이디어를 반복하는 기법입니다.

경이로운 우주의 힘, 아주 작은 생활 공간!

에이전트 AI에는 탐험할 수 있는 흥미롭고 새로운 영역이 정말 많습니다! 여전히 해결해야 할 오래된 전통적인 데이터 검색 및 처리 문제도 많지만, 새로운 LLM 시대를 맞아 이제야 빛을 보게 된 완전히 새로운 종류의 문제도 있습니다. 현재 우리가 당면한 많은 문제는 제한된 작업 메모리 공간에 부담을 주지 않으면서도 LLM에 필요한 추가 컨텍스트 정보를 제공하는 컨텍스트 엔지니어링과 관련이 있습니다.

다양한 도구(및 다른 에이전트)에 액세스할 수 있는 반자율 에이전트의 유연성으로 인해 AI 구현을 위한 새로운 아이디어가 너무 많이 생겨나서 어떤 방식으로 조합할 수 있을지 가늠하기조차 어렵습니다. 현재 대부분의 연구는 컨텍스트 엔지니어링 분야에 속하며 더 많은 양의 컨텍스트를 처리하고 추적할 수 있는 메모리 관리 구조를 구축하는 데 중점을 두고 있는데, 이는 LLM이 실제로 해결하기를 원하는 심층 사고 문제는 복잡성이 증가하고 기억이 매우 중요한 장기적이고 다단계적인 사고 단계가 존재하기 때문입니다.

현장에서 진행 중인 많은 실험은 에이전트에게 최적의 작업 관리 및 도구 구성을 제공하기 위해 노력하고 있습니다. 상담원의 추론 체인에서 각 툴 호출은 해당 툴의 기능을 수행하기 위한 컴퓨팅과 제한된 컨텍스트 창에 미치는 영향 측면에서 누적 비용을 발생시킵니다. LLM 에이전트의 컨텍스트를 관리하는 최신 기술 중 일부는 장기 실행 작업에 대해 누적된 컨텍스트를 압축/요약하면 손실이 너무 커지는' 컨텍스트 붕괴'와같은 의도하지 않은 연쇄 효과를 발생시켰습니다. 원하는 결과는 간결하고 정확한 컨텍스트를 반환하는 도구로, 불필요한 정보가 소중한 컨텍스트 창 메모리 공간으로 유출되지 않도록 하는 것입니다.

너무 많은/너무 많은 가능성

도구/구성 요소를 재사용할 수 있는 유연성을 갖춘 업무 분리를 원하므로 특정 데이터 소스에 연결하기 위한 전용 에이전트 도구를 만드는 것이 좋습니다. 각 도구는 한 유형의 리포지토리, 한 유형의 데이터 스트림 또는 하나의 사용 사례 쿼리에 특화될 수 있습니다. 하지만 주의하세요: 시간/비용을 절약하고 무언가 가능하다는 것을 증명하기 위해 LLM을 연합 도구로 사용하고 싶은 강한 유혹이 있을 것입니다... 그러지 마세요, 저희도 그 길을 가본 적이 있습니다! 연합 쿼리는 들어오는 쿼리를 원격 리포지토리가 이해하는 구문으로 변환한 다음 여러 소스의 결과를 어떻게든 일관된 응답으로 합리화해야 하는 '범용 번역기' 같은 역할을 합니다. 페더레이션은 소규모에서는 잘 작동하지만 대규모, 특히 데이터가 멀티모달인 경우 페더레이션은 너무 넓은 간격을 메우기 위해 시도합니다.

에이전트 세계에서는 에이전트가 페더레이터가 되고 도구(MCP를 통해)는 서로 다른 리소스에 수동으로 정의된 연결이 됩니다. 전용 도구를 사용하여 서로 연결되지 않은 데이터 원본에 접근하는 것은 쿼리별로 서로 다른 데이터 스트림을 동적으로 통합하는 강력하고 새로운 방법처럼 보일 수 있지만, 도구를 사용하여 여러 원본에 동일한 질문을 하는 것은 결국 해결되는 문제보다 더 많은 문제를 야기할 수 있습니다. 이러한 데이터 소스 각각은 그 아래에 서로 다른 유형의 리포지토리가 있을 가능성이 높으며, 그 안의 데이터를 검색, 순위 지정 및 보호하기 위한 고유한 기능을 갖추고 있습니다. 물론 리포지토리 간의 이러한 차이 또는 "임피던스 불일치"는 처리 부하를 증가시킵니다. 또한 상충되는 정보나 신호가 발생할 수 있는데, 점수 정렬 오류처럼 별것 아닌 것처럼 보이는 것이 반환된 컨텍스트의 중요성을 크게 떨어뜨리고 결국 생성된 응답의 관련성에 영향을 미칠 수 있습니다.

컴퓨터에서도 컨텍스트 전환은 어렵습니다.

에이전트를 임무에 파견할 때 가장 먼저 해야 할 일은 해당 에이전트가 액세스할 수 있는 모든 관련 데이터를 찾는 것입니다. 상담원이 연결한 각 데이터 소스가 서로 다르거나 분리된 응답으로 응답하는 경우 사람과 마찬가지로, 검색된 콘텐츠에서 중요한 맥락적 비트를 추출하는 것과 관련된 인지적 부하(정확히 같은 종류는 아니지만)가 발생할 수 있습니다. 여기에는 시간/계산이 필요하며, 에이전트 로직 체인에서 각각의 작은 부분이 합산됩니다. 따라서 MCP에 대해 논의되고 있는 것과 마찬가지로 대부분의 에이전트 툴은 알려진 입력 및 출력을 가진 격리된 함수, 즉 다양한 종류의 에이전트의 요구 사항을 지원하도록 조정된 API처럼 작동해야 한다는 결론에 도달하게 됩니다. 특히 자연어를 구조화된 구문으로 번역하는 작업과 같이 참조할 스키마가 있는 경우(실제로 RTFM!) 의미적 점들을 훨씬 더 잘 연결할 수 있다는 사실도 깨닫고 있습니다.

7회 연장!

지금까지 LLM이 데이터 검색 및 쿼리에 미치는 영향과 채팅 창이 상담원 AI 경험으로 어떻게 발전하고 있는지에 대해 살펴보았습니다. 이 두 가지 주제를 종합하여 컨텍스트 엔지니어링에서 새로운 검색 및 검색 기능을 사용하여 결과를 개선하는 방법을 살펴봅시다. 3부: 컨텍스트 엔지니어링에서 하이브리드 검색의 힘!