검색은 죽지 않았고, 단지 이동했을 뿐입니다.

따라서 주로 텍스트 상자를 통해 문맥을 검색하고 반환된 정보(문맥)를 사용하여 직접 답변을 구성하는 방식에서 이제는 자연어를 사용하여 상담원에게 원하는 것을 말하면 자동으로 검색하여 답변을 작성하는 방식으로 전환했습니다. 기술 업계의 많은 사람들이 이러한 변화를 지적하며 "검색은 죽었다"고 선언하고 있지만(물론 SEO와 애드워즈 세계는 확실히 변화하고 있습니다 . 누구세요?) 검색은 여전히 에이전트 운영에 절대적으로 중요하며, 지금은 대부분 도구를 통해 보이지 않는 곳에서 수행될 뿐입니다.

이전에는 사용자가 주관적인 관련성의 주요 중재자였습니다. 사용자마다 검색을 실행하는 이유가 다르고, 개인적인 경험에 따라 결과의 상대적 정확도가 달라집니다. 에이전트가 우리와 동일한(또는 더 나은) 결론에 도달할 수 있다고 믿으려면 에이전트가 액세스할 수 있는 컨텍스트 정보가 우리의 주관적인 의도에 최대한 가깝도록 보장해야 합니다. 우리는 그 목표를 향해 LLM을 제공하는 맥락을 설계해야 합니다!

하이브리드 검색 검색을 통한 컨텍스트 생성

1부에서 다시 한 번 말씀드리지만, Elastic의 하이브리드 검색은 기존 키워드 기반 검색의 강점(구문 유연성, 키워드 정밀도, 관련성 점수)과 벡터 유사성 검색의 의미론적 이해를 결합하고 다양한 재순위 지정 기술을 제공합니다. 이 시너지 효과(이 단어의 진정한 용도는 찾아볼 수 없습니다!) 를 사용하면 콘텐츠를 타겟팅하는 방식에 훨씬 더 미묘한 차이가 있는 쿼리를 통해 연관성이 높은 결과를 얻을 수 있습니다. 검색 단계 중 하나로 주관적 연관성을 적용할 수 있다는 것뿐만 아니라, 실제로는 1단계 검색에 다른 모든 모드와 함께 연관성 점수를 한 번에 포함할 수 있다는 것입니다.

뛰어난 정확도 & 효율성

분산 검색, 검색 및 순위 재지정을 제공할 수 있는 데이터 플랫폼을 기본 컨텍스트 검색 엔진으로 사용하는 것은 매우 합리적입니다. 고급 쿼리 구문을 사용하여 주관적 의도의 누락된 구성 요소를 추가하고, 반환된 문맥 정보의 가치를 흐리게 하거나 방해할 수 있는 콘텐츠를 필터링할 수 있습니다. 사용 가능한 개별 구문 옵션 중에서 선택하거나 각 유형의 데이터를 가장 잘 이해하는 방식으로 타겟팅하는 단일 검색으로 모달리티를 결합한 다음 순위를 재조정하여 결합/재배열할 수 있습니다. 원하는 필드/값만 포함하도록 응답을 필터링하여 불필요한 데이터를 차단할 수 있습니다. 상담원 서비스에서는 이러한 타겟팅 유연성을 통해 컨텍스트를 검색하는 방식이 매우 정확한 툴을 구축할 수 있습니다.

컨텍스트 세분화(집계 및 비콘텐츠 신호)

집계는 도구가 컨텍스트 창에 제공하는 콘텐츠를 구성하는 데 특히 유용할 수 있습니다. 집계는 자연스럽게 반환된 컨텍스트 데이터의 형태에 대한 수치 기반 사실을 제공하므로, LLM이 더 쉽고 정확하게 추론할 수 있습니다. 집계는 계층적으로 중첩될 수 있기 때문에 LLM에 다단계 세부 정보를 쉽게 추가하여 보다 미묘한 차이를 파악할 수 있습니다. 집계는 컨텍스트 창 크기를 관리하는 데도 도움이 됩니다. 10만 개의 문서에 대한 쿼리 결과를 수백 개의 집계된 인사이트 토큰으로 쉽게 줄일 수 있습니다.

비콘텐츠 신호는 인기도, 신선도, 지리적 위치, 카테고리, 호스트 다양성, 가격대 등 결과의 추가적인 특성을 나타내는 데이터의 내재적 지표로, 현재 보고 있는 내용에 대한 더 큰 그림을 알려줍니다. 이러한 정보는 상담원이 수신한 컨텍스트의 중요도를 평가하는 데 유용할 수 있습니다. 몇 가지 간단한 예시를 통해 이를 가장 잘 설명할 수 있습니다:

• 최근에 게시된 인기 콘텐츠 강화하기 - 문서에 대한 지식창고가 있다고 가정해 보세요. 사용자의 검색어와 관련된 문서를 찾고 싶지만, 최근 문서이면서 다른 사용자가 도움이 되었다고 판단한 문서(예: "좋아요" 수가 많은 문서)도 부스팅하고 싶을 수 있습니다. 이 시나리오에서는 하이브리드 검색을 사용하여 관련성 있는 문서를 찾은 다음 게시 날짜와 인기도를 조합하여 순위를 재조정할 수 있습니다.

• 판매 및 재고 조정 기능이 있는 전자상거래 검색 - 전자상거래 환경에서는 고객에게 검색어와 일치하는 제품을 표시하는 동시에 잘 팔리고 재고가 있는 제품을 홍보하고 싶을 수 있습니다. 또한 재고가 적은 제품의 순위를 낮춰 고객의 불만을 피할 수도 있습니다.

• 버그 트래커에서 심각도가 높은 이슈 우선 순위 지정하기 - 소프트웨어 개발팀의 경우 이슈를 검색할 때 심각도가 높고 우선 순위가 높으며 최근에 업데이트된 이슈를 먼저 표시하는 것이 중요합니다. '중요도' 및 '가장 많이 논의된' 등의 비신호를 사용하여 다양한 요소를 독립적으로 평가하여 가장 중요하고 활발하게 논의된 이슈가 맨 위에 표시되도록 할 수 있습니다.

이러한 예제 쿼리 등은 함께 제공되는 Elasticsearch Labs 콘텐츠 페이지에서 확인할 수 있습니다.

보안 시행

컨텍스트 엔지니어링을 위해 Elastic과 같은 검색 기반 속도 계층을 활용할 때의 중요한 장점은 기본 제공 보안 프레임워크입니다. Elastic의 플랫폼은 세분화된 역할 기반 액세스 제어(RBAC)와 속성 기반 액세스 제어(ABAC)를 통해 에이전트 및 생성 AI 작업에 제공되는 컨텍스트가 민감한 개인 보유 정보를 존중하고 보호하도록 보장합니다. 즉, 쿼리가 효율적으로 처리될 뿐만 아니라 요청을 시작한 상담원이나 사용자의 특정 권한에 따라 결과가 필터링됩니다.

에이전트는 인증된 사용자로 실행되므로 플랫폼에 내장된 보안 기능을 통해 보안이 암시적으로 적용됩니다:

• 세분화된 권한: 문서, 필드 또는 용어 수준에서 액세스 권한을 정의하여 AI 에이전트가 볼 권한이 있는 데이터만 받도록 하세요.

• 역할 기반 액세스 제어(RBAC): 에이전트 또는 사용자에게 역할을 할당하여 정의된 책임에 따라 특정 데이터 세트 또는 기능에 대한 액세스 권한을 부여합니다.

• 속성 기반 액세스 제어(ABAC): 데이터, 사용자 또는 환경의 속성을 기반으로 동적 액세스 정책을 구현하여 고도로 적응력이 뛰어나고 상황에 맞는 보안을 구현할 수 있습니다.

• 문서 수준 보안(DLS) 및 필드 수준 보안(FLS): 이러한 기능은 검색된 문서 내에서도 승인된 부분만 볼 수 있도록 하여 민감한 정보가 노출되는 것을 방지합니다.

• 엔터프라이즈 보안과 통합: 기존 ID 관리 시스템(예: LDAP, SAML, OIDC)과 원활하게 통합하여 조직 전체에 일관된 보안 정책을 적용할 수 있습니다.

이러한 보안 조치를 컨텍스트 검색 메커니즘에 직접 통합함으로써 Elastic은 보안 게이트키퍼 역할을 수행하여 AI 에이전트가 정의된 데이터 경계 내에서 작동하도록 보장하고 무단 데이터 노출을 방지하며 데이터 개인 정보 보호 규정을 준수하도록 유지합니다. 이는 기밀 또는 독점 정보를 처리하는 에이전트 AI 시스템에 대한 신뢰를 구축하는 데 가장 중요한 요소입니다.

추가로, 엔터프라이즈 데이터 소스에서 통합 데이터 속도 계층을 사용하면 에이전트 도구가 생성하는 리포지토리의 예기치 않은 임시 쿼리 부하를 완화할 수 있습니다. 한 곳에서 모든 것을 거의 실시간으로 검색하고 보안 및 거버넌스 제어를 적용할 수 있습니다.

하이브리드 검색 기반 도구

컨텍스트 엔지니어링의 추구를 가속화하는 Elastic 플랫폼의 몇 가지 핵심 기능( 계속 추가될 예정)이 있습니다. 여기서 가장 중요한 것은 플랫폼이 AI 생태계가 발전함에 따라 유연하게 적응, 변경, 확장할 수 있는 다양한 방법을 제공한다는 점입니다.

에이전트 빌더 소개

Elastic 에이전트 빌더는 Elastic에 이미 저장되어 있는 데이터와 채팅할 수 있도록 구축된 에이전트 AI 도구 영역에 처음으로 진출한 제품입니다. 에이전트 빌더는 사용자가 Kibana 내에서 자신만의 에이전트와 도구를 생성하고 관리할 수 있는 채팅 인터페이스를 제공합니다. 기본 제공 MCP 및 A2A 서버, 프로그래밍 방식의 API, Elasticsearch 인덱스를 쿼리 및 탐색하고 자연어로부터 ES|QL 쿼리를 생성하기 위한 사전 구축된 시스템 도구 세트가 함께 제공됩니다. 에이전트 빌더를 사용하면 표현식 ES|QL 쿼리 구문을 통해 에이전트에게 반환되는 컨텍스트 데이터를 타겟팅하고 조각하는 사용자 지정 도구를 만들 수 있습니다.

ES|QL은 하이브리드 검색을 어떻게 수행하나요? 핵심 기능은 semantic_text 필드 유형과 FORK/FUSE 명령의 조합을 통해 수행됩니다(FUSE는 기본적으로 각 포크의 결과를 병합하는 데 RRF를 사용합니다). 다음은 가상의 제품 검색에 대한 간단한 예제입니다:

위의 예제에서 각 FORK 브랜치에 포함된 EVAL 절은 반드시 필요한 것은 아니며, 특정 검색 결과가 어떤 검색 방식에서 반환되었는지 추적하는 방법을 보여주기 위해 포함되었을 뿐입니다.

템플릿 검색

자체 외부 에이전트 도구를 Elastic 배포로 가리키고 싶다고 가정해 보겠습니다. 또한 ES|QL 대신 다단계 검색기를 사용하거나 개발한 기존 DSL 구문을 재사용하고 쿼리가 허용하는 입력, 검색 실행에 사용되는 구문 및 출력에 반환되는 필드를 제어할 수 있기를 원합니다. 검색 템플릿을 사용하면 일반적인 검색 패턴에 대해 미리 정의된 구조를 정의하여 데이터 검색의 효율성과 일관성을 개선할 수 있습니다. 이는 상용구 코드를 표준화하고 검색 로직의 빠른 반복을 가능하게 하므로 검색 API와 상호 작용하는 에이전트 도구에 특히 유용합니다. 이러한 요소 중 하나를 조정해야 하는 경우 검색 템플릿을 업데이트하기만 하면 변경 사항이 바로 적용됩니다. 에이전트 도구에서 작동하는 검색 템플릿의 예를 찾고 계신다면, 외부 MCP 서버에서 도구 호출 뒤에 검색 템플릿을 활용하는 Elasticsearch Labs 블로그 '지능형 검색을 위한 MCP'를 살펴보시기 바랍니다.

통합 워크플로(FTW!)

새로운 에이전트 AI 세계에서 가장 어려운 점 중 하나는 반자율적이고 자기 주도적인 '추론' 에이전트의 비결정적 특성입니다. 컨텍스트 엔지니어링은 에이전트 AI의 중요한 분야로, 에이전트가 생성할 수 있는 결론의 범위를 우리가 알고 있는 사실에 근거하여 좁히는 데 도움이 되는 기술입니다. 매우 정확하고 관련성이 높은 컨텍스트 창이 있더라도 (수치적 사실의 영역을 벗어나면) 상담원의 응답이 완전히 반복 가능하고 신뢰할 수 있다는 확신을 줄 수 있는 부분이 여전히 부족합니다.

상담원에게 동일한 요청을 여러 번 실행하면 응답에 약간의 차이가 있을 뿐 본질적으로 동일한 답변이 나올 수 있습니다. 이는 보통 눈에 띄지 않을 정도로 단순한 쿼리의 경우 괜찮으며 컨텍스트 엔지니어링 기법을 사용하여 결과물을 구체화할 수 있습니다. 하지만 상담원에게 요청하는 작업이 복잡해짐에 따라 하나 이상의 하위 작업으로 인해 최종 결과가 약간 달라질 수 있는 변수가 발생할 가능성이 커지고 있습니다. 상담원 간 커뮤니케이션에 더 많이 의존하기 시작하면 이러한 차이는 더욱 심해질 것이며, 이러한 차이는 누적될 것입니다. 이는 상담원이 상호작용하는 툴이 컨텍스트 데이터를 정확하게 타겟팅할 수 있도록 매우 유연하고 조정이 가능해야 하며, 예상 출력 형식으로 응답해야 한다는 점을 다시 한 번 강조합니다. 또한 많은 사용 사례에서 에이전트와 툴의 상호 작용을 지시해야 할 필요가 있음을 나타내며, 바로 여기에서 워크플로우가 등장합니다!

Elastic은 곧 플랫폼의 핵심에 완전히 사용자 정의 가능한 워크플로우를 내장할 예정입니다. 이러한 워크플로는 상담원 및 툴과 양방향으로 작동할 수 있으므로 워크플로는 상담원 및 툴을 호출할 수 있고, 상담원 및 툴은 워크플로를 호출할 수 있게 됩니다. 이러한 기능이 모든 데이터가 있는 동일한 검색 AI 플랫폼에 완전히 통합되어 워크플로우를 혁신적으로 변화시킬 수 있는 잠재력은 매우 흥미롭습니다! 곧 출시됩니다!

통합 메모리 뱅크로서의 Elastic

실시간에 가까운 검색을 위해 만들어진 분산 데이터 플랫폼이기 때문에, Elastic은 에이전트 AI 시스템을 위한 장기 메모리 기능을 자연스럽게 수행합니다. 기본 제공되는 상담원 빌더 채팅 환경을 통해 단기 기억 및 채팅 기록을 추적하고 관리할 수도 있습니다. 그리고 전체 플랫폼이 API 우선이기 때문에, 에이전트의 컨텍스트 창을 압도할 수 있는 도구의 컨텍스트 출력을 유지(그리고 나중에 참조할 수 있도록)하기 위한 플랫폼으로 Elastic을 매우 쉽게 활용할 수 있습니다. 이 기술은 컨텍스트 엔지니어링 업계에서 "메모 작성"이라고도 불립니다.

동일한 검색 플랫폼에서 단기 메모리와 장기 메모리를 모두 사용하면 많은 본질적인 이점을 얻을 수 있습니다. 채팅 기록과 지속적 문맥 반응을 향후 채팅 상호작용에 시맨틱 영향력의 일부로 사용하거나 위협 분석을 수행하거나 자주 반복되는 도구 호출에서 자동으로 생성되는 지속적 데이터 제품을 만들 수 있다고 상상해 보세요... 가능성은 무궁무진합니다!

결론

대규모 언어 모델의 등장으로 콘텐츠를 매칭하는 방식과 데이터를 조사하는 방법이 바뀌었습니다. 사람이 직접 조사하고, 맥락을 고려하고, 논리적 추론을 통해 질문에 답하는 현재의 세상에서 에이전트 AI를 통해 이러한 단계가 대부분 자동화되는 세상으로 빠르게 전환되고 있습니다. 생성된 답변을 신뢰할 수 있으려면 상담원이 답변을 생성할 때 가장 관련성이 높은 모든 정보(주관적 관련성 요소 포함)를 고려했다는 확신이 있어야 합니다. 에이전트 AI를 신뢰할 수 있게 만드는 기본 방법은 RAG 및 컨텍스트 엔지니어링 기술을 통해 추가 컨텍스트를 검색하는 도구를 기반으로 하는 것이지만, 이러한 도구가 초기 검색을 수행하는 방식은 응답의 정확성에 매우 중요할 수 있습니다.

Elastic Search AI 플랫폼은 정확성, 성능, 확장성 측면에서 에이전트 AI를 지원하는 여러 기본 제공 기능과 함께 하이브리드 검색의 유연성과 이점을 제공합니다. 즉, Elastic은 컨텍스트 엔지니어링의 여러 측면을 위한 환상적인 플랫폼입니다! 검색 플랫폼을 통해 컨텍스트 검색을 표준화함으로써 여러 측면에서 에이전트 도구 운영을 간소화하며, '느려야 빨리 간다'는 모순처럼 컨텍스트 생성 계층에서의 간소화는 더 빠르고 더 신뢰할 수 있는 에이전트 AI를 의미합니다.

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

제너레이티브(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부: 컨텍스트 엔지니어링에서 하이브리드 검색의 힘!

다른 많은 사람들과 마찬가지로 저도 AI 기능이 발전하는 속도에 아찔함과 놀라움을 동시에 느낍니다. 대규모 언어 모델(LLM)과 벡터 검색을 통해 우리는 더 이상 키워드를 찾아 헤매지 않아도 되는 시맨틱 혁명을 맞이하게 되었습니다. 그런 다음 LLM은 채팅 인터페이스를 사용하여 자연어 요청을 방대한 지식 기반을 쉽게 사용할 수 있는 요약으로 변환하는 응답으로 변환하는 새로운 데이터 상호 작용 방법을 보여주었습니다. 우리는 지금 (이미!) 수신 요청을 의미론적으로 이해하고, 수행해야 할 단계를 추론한 다음, 해당 목표를 달성하기 위해 반복적으로 작업을 실행할 수 있는 도구를 선택할 수 있는 '에이전트 AI' 워크플로우의 형태로 자동화된 LLM 기반 로직의 시작을 알 수 있습니다.

에이전트 AI의 잠재력으로 인해 우리는 주로 '프롬프트 엔지니어링'을 사용하여 생성형 AI 상호작용을 형성하는 것에서 벗어나 에이전트 도구가 응답을 생성할 때 고려해야 하는 가장 관련성이 높고 효율적인 추가 정보를 얻을 수 있도록 돕는 방법, 즉 '맥락 엔지니어링'이 다음 개척 분야로 진화해야 합니다. 하이브리드 검색은 관련 컨텍스트를 표시하는 가장 강력하고 유연한 수단이며, Elastic의 검색 AI 플랫폼은 서비스 중인 데이터를 컨텍스트 엔지니어링에 활용할 수 있는 완전히 새로운 방법을 열어줍니다. 이 글에서는 LLM이 정보 검색의 세계를 어떻게 변화시켰는지 두 가지 각도에서 살펴본 다음, 더 나은 결과를 위해 어떻게 협력할 수 있는지에 대해 논의해 보겠습니다. 다뤄야 할 내용이 꽤 많습니다...

1부: LLM이 검색을 바꾼 방법

LLM이 정보에 액세스하고 검색하는 방식을 어떻게 변화시켰는지에 대한 관점에서 시작하겠습니다.

어휘 유산

우리는 모두 오랫동안 다소 제한적인 어휘 검색의 세계에서 (최선을 다해) 살아왔습니다. 검색은 새로운 프로젝트를 조사하거나 시작할 때마다 가장 먼저 찾는 도구로, 최근까지만 해도 어휘 검색 엔진이 이해할 수 있는 방식으로 쿼리를 표현하는 것은 전적으로 사용자의 몫이었습니다. 어휘 검색은 콘텐츠가 비정형인지 정형인지에 관계없이 문서 말뭉치에서 찾은 키워드에 어떤 형태의 쿼리 용어를 일치시키는 데 의존합니다. 어휘 검색이 문서를 히트로 반환하려면 해당 키워드와 일치하거나 동의어 목록이나 사전과 같이 개념적 연결을 위해 제어된 어휘가 있어야 합니다.

어휘 다중 일치 쿼리예제

적어도 검색 엔진은 관련성 점수가 있는 히트를 반환하는 기능이 있습니다. 검색 엔진은 색인된 데이터를 효과적으로 타겟팅할 수 있는 다양한 쿼리 구문 옵션과 사용자의 쿼리 구문 의도에 따라 결과를 점수화하는 기본 제공 관련성 알고리즘을 제공합니다. 검색 엔진은 수십 년간 발전해 온 관련성 순위 알고리즘의 이점을 활용하여 검색어와의 관련성에 따라 점수를 매기고 정렬된 결과를 제공할 수 있는 효율적인 데이터 검색 플랫폼이 되었습니다. SQL을 데이터 검색의 주요 방법으로 사용하는 데이터베이스 및 기타 시스템은 여기서 불리한 점이 있습니다. 데이터베이스 쿼리에는 관련성 개념이 없기 때문에 결과를 알파벳순 또는 숫자순으로 정렬하는 것이 최선입니다. 좋은 소식은 이러한 키워드로 모든 히트(리콜)를 얻을 수 있지만, 검색한 이유 (정확도)에 비해 반드시 유용한 순서로 검색되는 것은 아니라는 점입니다. 이는 곧 살펴보겠지만 중요한 포인트입니다...

(시맨틱) 용을 입력합니다.

키워드 검색의 대안으로 정보를 벡터로 표현할 수 있는 가능성은 꽤 오래전부터 연구되어 왔습니다. 벡터는 용어와 가중치를 숫자로 표현하기 때문에 학습 도메인에서 용어가 서로 어떻게 연관되는지에 대한 언어 모델의 이해를 바탕으로 개념을 수학적으로 가깝게 만들 수 있기 때문에 키워드만 사용하는 콘텐츠 매칭 모드에서 벗어날 수 있다는 점에서 많은 가능성을 가지고 있습니다. 범용 벡터 검색이 오래 지연된 것은 모델이 대부분 특정 도메인에 국한되어 있고, 용어가 다양한 맥락에서 나타낼 수 있는 다양한 개념을 충분히 이해하기에 충분히 크지 않았기 때문이었습니다.

벡터 검색이 실용화되기 시작한 것은 몇 년 전, 훨씬 더 많은 양의 데이터를 학습할 수 있는 대규모 언어 모델(LLM)이 등장하면서( 트랜스포머와 주의력을 사용해) LLM의 크기와 깊이 덕분에 벡터가 의미론적 의미를 실제로 포착할 수 있는 충분한 뉘앙스를 저장할 수 있게 되었을 때였습니다. 이해의 깊이가 갑자기 증가함에 따라 LLM은 이전에는 잠겨 있던 수많은 자연어 처리(NLP) 기능을 제공할 수 있게 되었으며, 가장 영향력 있는 기능은 아마도 지금까지의 시퀀스 내용을 바탕으로 시퀀스에서 가장 가능성이 높은 다음 용어를 추론하는 기능일 것입니다. 추론은 제너레이티브 AI에 인간에 가까운 텍스트 생성 능력을 부여하는 과정입니다. AI가 생성한 텍스트는 학습 데이터 내에서 용어가 어떻게 연관되어 있는지에 대한 LLM의 이해를 기반으로 하며, 요청의 문구를 사용하여 용어가 나타날 수 있는 다양한 문맥을 명확히 구분합니다.

생성형 AI는 마법과도 같지만, 품질과 정확성에서 오류를 일으키는 LLM에는 흔히 환각이라고 불리는 한계가 있습니다. 환각은 LLM이 사실에 근거한 답변을 할 수 있는 정보에 접근할 수 없거나 올바른 맥락으로 안내되지 않을 때 발생하므로, 도움이 되는 대신 자신감 있고 그럴듯하게 들리는 답변을 지어내게 됩니다. 그 원인 중 하나는 LLM이 다양한 정보의 넓은 도메인 내에서 언어 사용법을 학습하지만, 특정 시점에 학습을 중단해야 하므로 이해에 적시성 요소가 있어 모델이 학습을 중단한 시점까지만 정확한 정보를 알 수 있다는 점입니다. 환각의 또 다른 요인은 모델이 일반적으로 비공개 데이터(공개 인터넷에서 사용할 수 없는 데이터)에 대해 알지 못한다는 점이며, 이러한 데이터에 특정 용어와 명명법이 포함되어 있는 경우 특히 중요합니다.

벡터 데이터베이스

LLM은 텍스트 임베딩이라는 기술을 사용하여 콘텐츠를 모델 공간에 벡터화하는데, 이는 학습을 기반으로 모델의 세계관 내에 콘텐츠의 의미적 의미를 임베딩하거나 매핑하는 것을 말합니다. 임베드할 콘텐츠를 준비하고 처리하는 데에는 청킹과 토큰화(및 하위 단어 토큰화) 등 몇 가지 단계가 있습니다. 그 결과 일반적으로 벡터 공간 내에서 해당 콘텐츠의 의미에 대한 모델의 이해를 나타내는 고밀도 벡터 집합이 생성됩니다. 청킹은 임베딩을 생성하기 위한 모델의 처리 제약 조건에 콘텐츠를 맞추는 동시에 문장 및 단락 표시기와 같은 의미적 구성을 사용하여 관련 텍스트를 청크로 그룹화하기 위한 정확하지 않은 프로세스입니다.

청킹이 필요하면 개별 청크가 같은 문서의 다른 청크와 완전히 연결되지 않기 때문에 임베디드 문서에서 약간의 의미 손실이 발생할 수 있습니다. 신경망의 고유한 불투명성은 이러한 손실을 더욱 악화시킬 수 있습니다. LLM은 학습 중에 만들어진 용어와 개념 간의 연결이 비결정적이며 인간이 해석할 수 없는 진정한 '블랙박스'입니다. 이는 설명 가능성, 반복성, 무의식적 편견, 잠재적으로 신뢰와 정확성 상실 등의 문제로 이어집니다. 하지만 쿼리할 때 특정 키워드에 얽매이지 않고 아이디어를 의미적으로 연결할 수 있는 기능은 매우 강력합니다:

시맨틱 쿼리 예시

벡터 데이터베이스는 검색 엔진이 아니라 데이터베이스라는 점에서 고려해야 할 문제가 하나 더 있습니다! 벡터 유사성 검색이 수행되면 쿼리 용어가 인코딩되어 모델의 벡터 공간 내에서 일련의 (임베딩) 좌표 집합을 찾습니다. 그런 다음 이러한 좌표를 과녁으로 사용하여 과녁에 '가장 가까운 이웃'인 문서를 찾습니다. 즉, 문서의 순위(또는 결과 내 배치)는 쿼리 좌표에서 해당 문서 좌표의 계산된 유사성 거리에 따라 결정됩니다. 어떤 방향으로 랭킹을 우선시해야 하며, 가능한 컨텍스트 중 사용자의 의도에 가장 가까운 컨텍스트는 무엇인가요? 제가 비유한 이미지는 영화 스타게이트의 한 장면으로, 교차하는 6개의 좌표점이 목적지(과녁)를 알려주지만 사용자의 주관적인 의도를 나타내는 출발점의 좌표인 '7번째 기호'를 모르면 목적지에 도달할 수 없는 상황입니다. 따라서 벡터의 상대적 순위가 계속 확장되고 차별화되지 않은 유사성 영역에 기반하는 대신, 표현 구문과 관련성 점수를 통해 쿼리의 주관적 의도를 고려하면 눈금이 매겨진 주관적 관련성의 원통형과 유사한 결과를 얻을 수 있습니다.

LLM의 추론 기능은 쿼리에 대해 가장 가능성이 높은 컨텍스트를 식별하는 데 도움이 될 수 있지만, 문제는 도움이 없으면 수신 쿼리의 좌표는 모델이 원래 학습된 방식에 의해서만 결정될 수 있다는 점입니다.

어떤 면에서 벡터 유사도는 엄격한 키워드 검색과는 정반대의 극단이라고 할 수 있는데, 용어 불일치 문제를 극복할 수 있다는 것이 강점이지만 거의 결함에 가깝다고 할 수 있습니다: LLM은 관련 개념을 구분하기보다는 통합하는 경향이 있습니다. 벡터 유사도는 콘텐츠를 의미론적으로 일치시키는 능력을 향상시키지만, 모델에서 충분히 명확하지 않은 정확한 키워드와 특정 세부 사항을 간과할 수 있기 때문에 정확성을 보장하지는 않습니다. 벡터 유사도 검색은 그 자체로도 강력하지만, 벡터 데이터베이스에서 검색한 결과를 다른 검색 방법의 결과와 연관시킬 수 있는 방법이 필요합니다.

순위 재조정 기술

이제 결과 집합의 점수를 다시 매기거나 통합된 순위 순서로 정규화하는 리랭킹이라는 일반적인 기법을 언급할 때입니다. 재랭크가 필요한 이유는 여러 소스의 결과 또는 순위/채점 메커니즘이 다른 검색 방법(또는 전혀 없는 SQL!) 때문일 수도 있고, 의미론적이지 않은 소스의 결과를 사용자의 쿼리에 의미론적으로 맞추기 위해 재랭크가 사용될 수도 있습니다. 재랭크는 2단계 작업으로, 어떤 초기 검색 방법(예를 들어 SQL, 어휘 검색, 벡터 검색)의 순서를 다른 채점 방법으로 다시 지정합니다.

학습을 통한 순위 지정(LTR) 및 상호 순위 융합(RRF ) 등 여러 가지 접근 방식을 사용할 수 있습니다. LTR은 검색 결과 기능(좋아요, 평점, 클릭 등)을 캡처하고 이를 사용하여 결과를 점수화하고 부스트 또는 편향시키는 데 유용합니다. RRF는 다양한 쿼리 양식에서 반환된 결과를 병합하는 데 적합합니다(예 어휘 및 벡터 데이터베이스 검색)을 하나의 결과 목록으로 통합합니다. Elastic은 또한 선형 재순위화 방법을 사용하여 점수를 조정할 수 있는 유연성도 제공합니다.

그러나 가장 효과적인 재순위 조정 기법 중 하나는 시맨틱 재순위 조정으로, LLM의 시맨틱 이해를 사용하여 쿼리와 결과의 벡터 임베딩을 함께 분석한 다음 관련성 점수/채점을 적용하여 최종 순위를 결정합니다. 물론 시맨틱 재랭크에는 재랭크 모델에 대한 연결이 필요하며, Elasticsearch는 기본 제공 모델(Elastic Rerank), 가져온 타사 모델 또는 Cohere나 Google Vertex AI 같은 외부 호스팅 서비스를 활용하는 재랭크 엔드포인트를 생성할 수 있는 추론 API를 제공합니다. 그런 다음 검색 쿼리 추상화 구문을 통해 다시 순위를 매길 수 있습니다:

다단계 리트리버 순위 재조정 작업 예시

멋지지 않나요? 서로 다른 소스의 결과에 대해 재랭킹을 수행하여 모든 유형의 콘텐츠에 대한 의미론적 이해에 근접할 수 있습니다... 의미론적 재랭킹은 처리 시간뿐만 아니라 계산 비용이 많이 들 수 있으므로 제한된 수의 결과에 대해서만 실현 가능하게 수행할 수 있으므로 초기 결과를 검색하는 방법이 중요합니다.

컨텍스트 검색 방법의 중요성

주관적 의도는 결과의 정확성을 결정하고 관련성을 점수화할 때 중요한 요소입니다. 쿼리 수행에 대한 사용자의 의도를 고려할 수 있는 기능(유연한 구문 또는 2단계 재랭킹을 통해 표현됨)이 없으면 모델 공간 내에 이미 인코딩된 기존 컨텍스트 중에서 선택할 수 밖에 없습니다. 일반적으로 이러한 컨텍스트 부족 문제를 해결하는 방법은 검색 증강 생성(RAG)과 같은 기술을 사용하는 것입니다. RAG가 작동하는 방식은 상황에 맞는 데이터에 대한 사전 쿼리에서 반환된 추가 관련 용어를 포함하여 쿼리의 좌표를 효과적으로 이동하는 것입니다. 따라서 추가 컨텍스트를 제공하는 엔진과 검색을 수행하는 초기 방법이 컨텍스트의 정확성에 더욱 중요해집니다!

다양한 컨텍스트 검색 방법과 이러한 방법이 RAG 작업에 어떤 도움이 되거나 해가 되는지 살펴보겠습니다:

• 검색 엔진이 없는 하이브리드 검색 검색은 여전히 주관적인 연관성이 부족합니다. RAG를 제공하는 플랫폼이 주로 SQL 기반인 경우(대부분의 '데이터 레이크' 플랫폼 포함), 초기 검색 단계에서 정확도 점수가 부족합니다. 많은 데이터 레이크 플랫폼이 자체 버전의 하이브리드 검색(검색이 아닌)을 제공하며, 일반적으로 SQL 기반 검색과 벡터 데이터베이스 결과에 시맨틱 리랭크 및 RRF와 같은 리랭크 기법을 결합합니다. 단순 정렬은 주관적 순위를 매기기에는 분명히 불충분하지만, 2단계 시맨틱 재랭크 작업의 기초로 사용하더라도 1단계 검색으로서의 SQL은 검색 시 결과를 점수화하는 방법 없이 '상위 k' 히트에 대해서만 시맨틱 재랭크가 수행될 때 문제가 됩니다 - 실제로 최상의 결과가 상위 결과라고 보장할 수 있는 방법은 무엇일까요?

• 벡터 유사성만으로는 RAG에 충분하지 않습니다. 이는 임베딩의 손실, 순진한 청킹 방법, 유사성 계산 방식, 주관적 의도라는 중요한 요소가 누락된 문제 등 복합적인 문제 때문이었습니다. RAG의 주요 목표 중 하나는 생성 AI의 상호작용을 객관적인 진실에 근거하여 환각을 방지하고 학습 중에 알지 못했던 개인 정보를 LLM에 알려주는 것입니다. RAG를 통해 제공되는 추가 컨텍스트를 사용하여 당면한 질문에 답하는 데 가장 중요한 연결과 세부 사항을 고려하도록 LLM을 제한하고 지시할 수 있습니다. 이를 위해서는 의미론적 접근 방식과 어휘적 접근 방식을 모두 사용해야 합니다.

• 파일 기반 grep/레거시 RAG. 에이전트 AI 세계에서는 외부 검색 플랫폼이 아닌 RAG용 grep 및 정규식을 통해 로컬 파일에 액세스하는 크게 확대된 컨텍스트 창을 사용하는 것을 지적하는 의견도 있습니다. 훨씬 더 큰 컨텍스트 창을 사용할 수 있게 되면 LLM은 관련 정보를 수집하기 위해 단편적인 정보와 여러 검색 방법/플랫폼에 의존하지 않고 자신의 사고 공간 내에서 개념을 연결할 수 있게 될 것입니다. 이론적으로는 전체 문서가 문서 세그먼트보다 더 완전한 그림을 제공하지만, 이는 소규모 데이터 도메인(예: 바이브코딩을 위해 파일을 제공할 때)에서만 작동할 수 있으며, 그 경우에도 초기 검색 방식은 키워드만 일치하는 모든 문서를 스캔하는 것입니다.

검색은 검색 그 이상입니다

검색 엔진은 가능한 한 빠르고 유연하게 쿼리를 수행하도록 특별히 설계되었습니다. 내부적으로는 다양한 종류의 데이터를 해당 데이터 유형에 맞는 방식으로 저장하고 검색하기 위해 특수 데이터 구조를 활용합니다. Elasticsearch는 비정형/전체 텍스트 어휘 검색(일치, 구문, 근접, 다중 일치), 빠른 키워드(정확히 일치) 검색 및 필터링, 숫자 범위, 날짜, IP 주소 등 거의 모든 유형의 데이터에 대해 최적화된 저장과 쿼리를 제공하며, 문서 구조를 저장하는 방식이 매우 유연합니다(예. 중첩되거나 평평해진 문서). Elasticsearch는 또한 희소 벡터 유형과 고밀도 벡터 유형을 모두 저장하고 쿼리할 수 있는 기본 벡터 데이터베이스이며, 검색 충실도를 유지하면서 벡터화된 콘텐츠와 관련된 속도, 확장성 및 비용을 개선하는 혁신적인 방법(예: Better Binary Quantization(BBQ) & DiskBBQ)을 계속 모색하고 있습니다. 또한 Elasticsearch 플랫폼은 기본으로 데이터 복원력과 고가용성을 제공하며, 검색 가능한 스냅샷과 같은 데이터 수명 주기 관리 기능을 통해 자주 액세스하지 않거나 장기 보존 데이터를 비용 효율적인 개체 스토리지에 보관하면서도 여전히 완벽하게 검색할 수 있습니다.

하이브리드 검색은 모든 면에서 최고입니다.

하이브리드 검색 (하이브리드 검색뿐만 아니라!) 는 기존 어휘 검색의 강점과 LLM의 의미론적 이해 및 벡터 유사도 검색을 결합합니다. 이러한 시너지를 통해 검색 엔진이 제공하는 유연한 쿼리 구문 옵션, 의도 중심 구문 옵션 및 관련성 점수, 멀티모달 데이터 검색, 필터링, 집계, 편향성 등 검색 엔진이 제공하는 모든 기능을 통해 검색 단계에서 관련성이 높은 결과를 타겟팅할 수 있습니다. ES|QL 및 다단계 검색기와 같은 검색 구문을 사용하면 기존 검색과 시맨틱 검색, 필터, 여러 순위 재조정 기술을 하나의 요청에 유연하게 결합할 수 있습니다.

하이브리드 검색의 가장 큰 장점 중 하나는 쿼리가 여러 가지 데이터 유형에 대해 동시에 특수 구문을 사용할 수 있다는 점입니다. 이러한 다양한 쿼리 구문은 결과를 찾는 데만 사용할 수 있을 뿐만 아니라 결과에 대한 필터나 집계로도 사용할 수 있습니다. 예를 들어, 다른 구문과 자주 결합되는 가장 일반적인 쿼리 유형 중 하나는 지리공간 분석입니다. 특정 지점에서 지정된 거리 내의 지리적 좌표가 있는 결과를 쿼리하거나, 지역별 결과 집계 또는 구역 내/외의 이동을 추적하고 경고하기 위한 집계를 요청하는 등의 작업을 수행할 수 있습니다. 하이브리드 검색을 사용하면 구문을 유연하게 조합하여 가장 정확한 방식으로 결과를 타겟팅하고 컨텍스트에 가장 가까운 콘텐츠를 검색할 수 있습니다.

인터미션

이 첫 번째 파트에서는 벡터 검색이 데이터를 검색하는 방식을 어떻게 변화시켰는지 이야기하고, 데이터와 상호 작용하는 데 사용하는 쿼리 메커니즘에 LLM이 가져온 변화의 무대를 마련합니다. LLM이 맥락을 잃지 않고 이해할 수 있도록 여러 부분으로 나눠서 설명해야 한다고 가정해 보겠습니다... ;-) 2부: 에이전트 AI와 컨텍스트 엔지니어링의 필요성에서 이것이 중요한 이유에 대해 자세히 알아보고, 3부에서는 하이브리드 검색에 대한 논의로 돌아가겠습니다.