Jeff Vestal - Elasticsearch Labs

빠른 속도 대 정확도: 양자화된 벡터 검색의 리콜 측정하기

Jeff Vestal — Fri, 20 Mar 2026 00:00:00 GMT

모두가 벡터 검색이 즉각적으로 이루어지기를 원합니다. 하지만 고차원 벡터는 무겁습니다. 단일 1,024차원 float-32 벡터는 상당한 메모리를 차지하며, 이를 수백만 개의 다른 벡터와 비교하는 것은 계산상 비용이 많이 듭니다.

이를 해결하기 위해 Elasticsearch와 같은 검색 엔진은 두 가지 주요 최적화 전략을 사용합니다.

근사 검색(계층적 탐색 가능 스몰 월드 [HNSW]): 모든 문서를 스캔하는 대신, 답이 있을 가능성이 높은 근처로 빠르게 이동할 수 있는 탐색 그래프를 구축합니다.
양자화: 메모리 사용량을 줄이고 계산 속도를 높이기 위해 벡터를 압축합니다(예: 32비트 부동소수점에서 8비트 정수 또는 1비트 이진 값으로).

하지만 최적화에는 정확성이라는 대가가 따르는 경우가 많습니다.

"만약 데이터를 압축하고 검색 중에 지름길을 택한다면 최상의 결과를 놓치게 될까요?" 혹은 "이러한 최적화가 검색 엔진의 관련성을 저하시킬까요?"라는 두려움이 당연히 생길 수 있습니다.

Elastic의 정량화가 결과를 저하시키지 않는다는 것을 증명하기 위해, DBPedia-14 데이터 세트를 사용해 반복 가능한 테스트 하네스를 구축하여 Elasticsearch에서 기본 최적화를 사용할 때 속도와 얼마나 많은 정확도(특히, 리콜)를 교환하는지 정확히 계산했습니다.

tldr: 생각보다 훨씬 적을 가능성이 높습니다. 여기에서 노트북을 확인하고 직접 사용해 보세요.

정의(비전문가를 위한)

코드를 살펴보기 전에 먼저 몇 가지 용어를 정리해 보겠습니다.

정확도 대 리콜: 정확도는 주관적입니다(좋은 것을 찾았는가?). 리콜은 수학적입니다. 데이터베이스에 검색어와 수학적으로 완벽하게 일치하는 문서가 10개 있고 검색 엔진이 그 중 9개를 찾았다면 리콜 확률은 90%(또는 0.9)입니다.
정확한 검색(평면 검색): 때때로 "무차별 대입" 방법이라고도 합니다. 검색 엔진은 색인에 있는 모든 문서를 스캔하여 거리를 계산합니다.
- 장점: 리콜이 100% 완벽합니다.
- 단점: 계산 비용이 높고 규모가 커질수록 느려집니다.
근사 검색(HNSW): "지름길" 방식입니다. 검색 엔진이 HNSW 그래프를 구축합니다. 그래프를 탐색하여 최근접 이웃을 찾습니다.
- 장점: 매우 빠르고 확장 가능합니다.
- 단점: 그래프 탐색이 너무 일찍 중단되면 이웃을 놓칠 가능성이 있습니다.

실험: 정확한 값과 근사치 비교

리콜을 테스트하기 위해 텍스트 분류 모델을 학습하고 평가하는 데 일반적으로 사용되는 14개 온톨로지 클래스에 걸친 제목과 초록으로 구성된 대규모 데이터 세트인 DBPedia-14 데이터 세트를 사용했습니다. 특히 "영화" 카테고리에 초점을 맞출 것입니다. 최적화된 프로덕션 설정을 수학적으로 완벽한 기준 데이터와 비교하고 싶었습니다.

이 실험에서는 jina-embeddings-v5-text-small 모델을 사용하고 있습니다. 이 모델은 텍스트 표현에 대한 업계 벤치마크를 선도하는 최첨단 다국어 모델입니다. 이 모델이 고성능 임베딩의 현재 표준을 정의하기 때문에 이 모델을 선택했습니다. Jina v5의 탁월한 정확도와 Elasticsearch의 네이티브 양자화 기능을 결합함으로써, 계산 효율성이 뛰어나면서도 검색 품질을 저하시키지 않는 검색 아키텍처를 구현할 수 있음을 보여줍니다.

이중 매핑으로 색인을 설정했습니다. 동일한 텍스트를 두 개의 서로 다른 필드에 동시에 수집했습니다.

content.raw유형: flat. 이로 인해 Elasticsearch는 전체 Float32 벡터에 대해 무차별 대입 스캔을 수행하게 됩니다. 이렇게 하면 정확한 일치 결과가 반환되며 기준선으로 사용됩니다.
content유형 semantic_text. 기본값으로 HNSW + 더 나은 이진 양자화(BBQ)를 사용합니다. 이것이 근사 일치를 위한 표준적이고 최적화된 생산 설정입니다.

Recall@10 테스트

메트릭으로는 Recall@10을 사용했습니다.

무작위로 영화 50편을 골라 두 필드에 대해 동일한 쿼리를 실행했습니다.

정확한 (평면) 검색에서 상위 10개 이웃의 ID가 [1, 2, 3... 10]인 경우.
그리고 대략적인 (HNSW) 검색은 ID [1, 2, 3... 9, 99]를 반환합니다.
상위 10개 중 9개를 정확히 찾아냈습니다. 점수는 0.9점입니다.

다음은 사용한 매핑입니다.

# The "Control Group": Forces exact brute-force scan "raw": { "type": "semantic_text", "inference_id": ".jina-embeddings-v5-text-small", "index_options": { "dense_vector": { "type": "flat" } } }

결과: 성공의 "플랫 라인"

전체 데이터 세트를 다시 로드하고 1,000~40,000개의 문서 색인 크기에 대해 테스트하는 확장성 테스트를 실행했습니다.

리콜 점수에 대한 자세한 내용은 다음과 같습니다.

문서

Recall@10 점수

1,000

1.000(100%)

5,000

0.998 (100%)

10,000

0.992 (99.4%)

20,000

0.999 (99.0%)

40,000

0.992 (98.8%)

결과는 놀라울 정도로 안정적이었습니다. 규모를 확장했음에도 불구하고, 근사 검색은 무차별 대입 방식의 정확한 검색과 99%를 넘는 일치율을 보였습니다.

왜 그렇게 잘 작동했을까요?

벡터를 이진 값으로 압축하면 정확도가 더 많이 저하될 것으로 예상할 수 있습니다. 그렇게 되지 않는 이유는 Elasticsearch가 데이터 검색을 처리하는 방식에 있습니다.

오늘날 대부분의 임베딩 모델은 크기가 큰 Float32 벡터를 출력합니다. 검색 효율성을 높이기 위해 Elasticsearch는 고차원 벡터에 양자화를 사용합니다. 특히, 9.2 이후로는 기본적으로 BBQ를 사용합니다.

BBQ는 리스코어 메커니즘을 사용합니다.

트래버설: 검색 엔진은 압축(양자화된) 벡터를 사용하여 HNSW 그래프를 빠르게 탐색합니다. 벡터가 작기 때문에 성능 저하 없이 효율적으로 오버샘플링하여 더 많은 후보 목록(예: 거의 비슷한 상위 100개 문서)을 수집할 수 있습니다.
리스코어: 후보 문서가 있으면 해당 문서에 대한 전체 정밀도 값을 검색하여 최종적이고 정확한 순위를 계산합니다.

이는 무거운 작업을 위한 양자화의 속도와 최종 정렬을 위한 부동 소수점의 정밀도, 이 두 가지 장점을 모두 제공합니다.

더 나은 성과를 낼 수 있을까요?

여기에 표시된 결과는 기본 설정과 무작위 데이터 샘플링을 사용한 결과라는 점에 주목할 필요가 있습니다. 이걸 고성능 출발점이라고 생각해 보세요. Jina v5는 강력한 성능을 자랑하지만, 이러한 리콜 점수가 모든 데이터 세트에 대해 "만능 해결책"을 보장하는 것은 아닙니다. 모든 데이터 수집에는 고유한 특성이 있으며, 더 많은 성능을 끌어내기 위해 더 조정할 수는 있지만, 항상 자신의 특정 데이터와 벤치마킹하여 한계가 어디인지 확인해야 합니다.

결론

이것은 매우 작은 규모의 테스트입니다. 하지만 이 연습의 요점은 임베딩 모델이나 BBQ를 구체적으로 측정하는 것이 아니라, 최소한의 설정으로 데이터 세트의 리콜을 쉽게 측정하는 방법을 보여주기 위한 것입니다.

자신의 데이터로 이 테스트를 실행하려면 여기에서 노트북을 확인하여 직접 시도해 보세요.

첫 번째 Elastic 에이전트: 단일 쿼리에서 AI 기반 채팅까지

Jeff Vestal — Thu, 25 Sep 2025 00:00:00 GMT

Elastic의 새로운 에이전트 빌더를 사용하면 특정 비즈니스 도메인의 전문가 역할을 하는 전문화된 AI 에이전트를 생성할 수 있습니다. 이 기능은 단순한 대시보드와 검색창을 넘어 데이터를 수동적인 리소스에서 능동적인 대화 파트너로 탈바꿈시킵니다.

고객과의 미팅 전에 정보를 빠르게 파악해야 하는 재무 관리자가 있다고 상상해 보세요. 이제 수동으로 뉴스 피드를 검색하고 포트폴리오 대시보드를 상호 참조하는 대신 맞춤형 상담원에게 직접 질문할 수 있습니다. 이것이 바로 "채팅 우선" 접근 방식의 장점입니다. 관리자는 데이터에 직접 대화할 수 있는 라인을 통해 "ACME Corp의 최신 뉴스는 무엇이며 고객의 보유 자산에 어떤 영향을 미칩니까?" 같은 질문을 할 수 있습니다. 검색하면 몇 초 만에 종합적인 전문가 답변을 얻을 수 있습니다.

오늘날 금융 전문가를 구축하는 과정에서 데이터만큼이나 응용 분야도 다양합니다. 동일한 권한으로 위협을 찾아내는 사이버 보안 분석가, 장애를 진단하는 사이트 안정성 엔지니어, 캠페인을 최적화하는 마케팅 관리자를 만들 수 있습니다. 도메인에 관계없이 핵심 미션은 동일합니다. 데이터를 전문가와 대화할 수 있는 데이터로 전환하는 것입니다.

0단계: 데이터 세트

현재 저희 데이터 세트는 금융 계좌, 자산 현황, 뉴스 및 재무 보고서로 구성된 합성 금융 기반 데이터 세트입니다. 합성 데이터 세트이긴 하지만, 실제 금융 데이터 세트를 단순화한 버전을 재현한 것입니다.

financial_accounts: 위험 프로필이 있는 고객 포트폴리오

financial_holdings: 매수 내역이 있는 주식/ETF/채권 포지션

financial_asset_details: 주식/ETF/채권에 대한 세부 정보

financial_news: 감정 분석을 통해 AI가 생성한 시장 기사

financial_reports: 기업 실적 및 애널리스트 노트

이 데이터 세트는 여기에 있는 첨부된 노트북을 따라 직접 로드할 수 있습니다.

1단계: 기초 - ES|QL로서의 비즈니스 로직

모든 AI 기술은 탄탄한 로직에서 시작됩니다. 재무 관리자 상담원에게 일반적인 질문에 답하는 방법을 가르쳐야 합니다: "시장 심리가 걱정됩니다. 어떤 고객이 나쁜 소식으로 가장 위험에 처해 있는지 보여 주시겠습니까?" 이 질문은 단순한 검색을 넘어서는 질문입니다. 이를 위해서는 시장 심리와 고객 포트폴리오의 상관관계를 파악해야 합니다.

부정적인 기사에 언급된 자산을 찾고, 해당 자산을 보유한 모든 고객을 식별하고, 해당 자산의 현재 시장 가치를 계산한 다음, 그 결과를 순위화하여 위험도가 가장 높은 자산의 우선순위를 정해야 합니다. 이러한 복잡한 다중 조인 분석은 고급 ES|QL 도구에 완벽한 작업입니다.

다음은 우리가 사용할 전체 쿼리입니다. 인상적으로 보이지만 개념은 간단합니다.

분석: 조인 및 가드레일

이 쿼리에는 상담원 빌더를 만드는 두 가지 중요한 개념이 작용하고 있습니다.

1. 조회 조인

수년 동안 Elasticsearch에서 가장 많이 요청된 기능 중 하나는 공통 키를 기반으로 서로 다른 인덱스의 데이터를 조인하는 기능이었습니다. 이제 ES|QL을 사용하면 LOOKUP JOIN 에서 가능합니다.

새 쿼리에서는 먼저 부정적인 뉴스를 자산 세부 정보에 연결한 다음, 해당 자산을 고객 보유 자산에 연결하고 마지막으로 고객의 계정 정보에 연결하는 세 개의 LOOKUP JOIN 연쇄를 수행합니다. 이렇게 하면 하나의 효율적인 쿼리에서 4개의 서로 다른 인덱스로부터 놀랍도록 풍부한 결과를 얻을 수 있습니다. 즉, 모든 데이터를 미리 하나의 거대한 인덱스로 비정규화할 필요 없이 서로 다른 데이터 집합을 결합하여 통찰력 있는 단일 답변을 만들 수 있습니다.

2. LLM 가드레일로서의 매개변수

쿼리가 ?time_duration 을 사용하는 것을 알 수 있습니다. 이는 단순한 변수가 아니라 AI를 위한 보호 장치입니다. LLM(대규모 언어 모델)은 쿼리 생성에 탁월하지만, 데이터를 자유롭게 사용할 수 있도록 허용하면 비효율적이거나 심지어 잘못된 쿼리가 발생할 수도 있습니다.

매개변수화된 쿼리를 생성하여 전문가가 이미 정의한 테스트되고 효율적이며 올바른 비즈니스 로직 내에서 LLM이 작동하도록 강제합니다. 이는 개발자들이 수년 동안 검색 템플릿을 사용하여 애플리케이션에 쿼리 기능을 안전하게 노출해 온 방식과 유사합니다. 에이전트는 이번 주 "이번 주" 같은 사용자의 요청을 해석하여 time_duration 매개 변수를 채울 수 있지만, 반드시 쿼리 구조를 사용하여 답변을 얻어야 합니다. 이를 통해 유연성과 제어의 완벽한 균형을 이룰 수 있습니다.

궁극적으로 이 쿼리를 통해 데이터를 이해하는 전문가가 자신의 지식을 도구로 캡슐화할 수 있습니다. 그러면 다른 사람, 즉 AI 에이전트는 이 도구를 사용하여 근본적인 복잡성에 대해 아무것도 모른 채 단일 매개변수만 제공하면 상관관계가 있는 결과를 얻을 수 있습니다.

2단계: 기술 - 쿼리를 재사용 가능한 도구로 전환하기

ES|QL 쿼리는 도구로 등록하기 전까지는 텍스트에 불과합니다. 상담원 빌더에서 도구는 단순히 저장된 쿼리 그 이상의 의미로, AI 상담원이 이해하고 사용할 수 있는 "스킬(" )을 의미합니다. 마법 같은 것은 저희가 제공하는 자연어 설명에 있습니다. 이 설명은 사용자의 질문을 기본 쿼리 로직에 연결하는 다리 역할을 합니다. 방금 작성한 쿼리를 등록해 보겠습니다.

UI 경로

Kibana에서 도구를 만드는 것은 간단한 과정입니다.

1. 상담원으로이동합니다.

도구 또는 도구 관리를 클릭하고 새 도구 버튼을 클릭합니다.

2. 다음 세부 정보를 입력하여 양식을 작성합니다:

도구 ID: find_client_exposure_to_negative_news

i. 도구의 고유 ID입니다.

설명: "부정적인 뉴스에 노출된 고객 포트폴리오를 찾습니다. 이 도구는 최근 뉴스와 보고서에서 부정적인 감정을 검색하고 관련 자산을 식별한 후 해당 자산을 보유한 모든 고객을 찾아냅니다. 포지션의 현재 시장가 기준으로 정렬된 목록을 반환하여 잠재적 위험이 가장 높은 포지션을 강조 표시합니다."

i. LLM은 이를 읽고 이 도구가 작업에 적합한지 여부를 결정합니다.

레이블: retrieval 및 risk-analysis

레이블은 여러 도구를 그룹화하는 데 사용됩니다.

구성으로 이동합니다: 1단계의 전체 ES|QL 쿼리 붙여넣기

i. 상담원이 사용할 검색은 다음과 같습니다.

3. 쿼리에서 매개변수 유추를 클릭합니다. UI에서 ?time_duration 을 자동으로 찾을 수 있습니다. 상담원(및 다른 사용자)이 목적을 이해하는 데 도움이 되도록 각각에 대한 간단한 설명을 추가하세요.

time_duration: 부정적인 뉴스를 다시 검색할 수 있는 기간입니다. 형식은 "X 시간" 기본값은 8760시간입니다.

4. 테스트해 보세요!

저장 & 테스트를 클릭합니다.

쿼리가 예상대로 작동하는지 테스트할 수 있는 새로운 플라이아웃이 표시됩니다.

i. time_duration 에서 원하는 범위를 입력합니다. 여기서는 "8760 시간"을 사용하고 있습니다.

'제출'을 클릭하고 모든 것이 정상적으로 진행되면 JSON 응답이 표시됩니다. 예상대로 작동하는지 확인하려면 아래로 스크롤하여 values 개체를 확인합니다. 여기에서 실제 일치하는 문서가 반환됩니다.

5. 오른쪽 상단의 'X'를 클릭하여 테스트 플라이아웃을 닫습니다. 이제 새 도구가 목록에 표시되며 상담원에게 배정할 준비가 되었습니다.

API 경로

자동화를 선호하거나 프로그래밍 방식으로 도구를 관리해야 하는 개발자의 경우, 한 번의 API 호출로 동일한 결과를 얻을 수 있습니다. POST 요청을 /api/agent_builder/tools 엔드포인트에 도구의 정의와 함께 보내면 됩니다.

POST kbn://api/agent_builder/tools { "id": "find_client_exposure_to_negative_news", "type": "esql", "description": "Finds client portfolio exposure to negative news. This tool scans recent news and reports for negative sentiment, identifies the associated asset, and finds all clients holding that asset. It returns a list sorted by the current market value of the position to highlight the highest potential risk.", "configuration": { "query": """ FROM financial_news, financial_reports METADATA _index | WHERE sentiment == "negative" | WHERE coalesce(published_date, report_date) >= NOW() - TO_TIMEDURATION(?time_duration) | RENAME primary_symbol AS symbol | LOOKUP JOIN financial_asset_details ON symbol | LOOKUP JOIN financial_holdings ON symbol | LOOKUP JOIN financial_accounts ON account_id | WHERE account_holder_name IS NOT NULL | EVAL position_current_value = quantity * current_price.price | RENAME title AS news_title | KEEP account_holder_name, symbol, asset_name, news_title, sentiment, position_current_value, quantity, current_price.price, published_date, report_date | SORT position_current_value DESC | LIMIT 50 """, "params": { "time_duration": { "type": "keyword", "description": """The timeframe to search back for negative news. Format is "X hours" DEFAULT TO 8760 hours """ } } }, "tags": [ "retrieval", "risk-analysis" ] }

3단계: 두뇌 - 사용자 지정 상담원 만들기

재사용 가능한 스킬(도구)을 만들었습니다. 이제 실제로 사용할 페르소나, 즉 에이전트를 만들어야 합니다. 에이전트는 LLM, 액세스 권한을 부여한 특정 도구 세트, 그리고 가장 중요한 것은 에이전트의 성격, 규칙 및 목적을 정의하는 구성 요소 역할을 하는 사용자 지정 지침 세트의 조합입니다.

프롬프트의 기술

신뢰할 수 있는 전문 상담원을 만드는 데 있어 가장 중요한 부분은 바로 프롬프트입니다. 잘 만들어진 지침 세트는 일반 챗봇과 집중력 있는 전문 비서의 차이점입니다. 여기에서 가드레일을 설정하고, 출력을 정의하고, 에이전트에게 임무를 부여할 수 있습니다.

Financial Manager 에이전트의 경우 다음 프롬프트를 사용합니다.

You are a specialized Data Intelligence Assistant for financial managers, designed to provide precise, data-driven insights from information stored in Elasticsearch. **Your Core Mission:** - Respond accurately and concisely to natural language queries from financial managers. - Provide precise, objective, and actionable information derived solely from the Elasticsearch data at your disposal. - Summarize key data points and trends based on user requests. **Reasoning Framework:** 1. **Understand:** Deconstruct the user's query to understand their core intent. 2. **Plan:** Formulate a step-by-step plan to answer the question. If you are unsure about the data structure, use the available tools to explore the indices first. 3. **Execute:** Use the available tools to execute your plan. 4. **Synthesize:** Combine the information from all tool calls into a single, comprehensive, and easy-to-read answer. **Key Directives and Constraints:** - **If a user's request is ambiguous, ask clarifying questions before proceeding.** - **DO NOT provide financial advice, recommendations, or predictions.** Your role is strictly informational and analytical. - Stay strictly on topic with financial data queries. - If you cannot answer a query, state that clearly and offer alternative ways you might help *within your data scope*. - All numerical values should be formatted appropriately (e.g., currency, percentages). **Output Format:** - All responses must be formatted using **Markdown** for clarity. - When presenting structured data, use Markdown tables, lists, or bolding. **Start by greeting the financial manager and offering assistance.**

이 프롬프트가 효과적인 이유를 자세히 알아보세요:

이는 정교한 페르소나를 정의합니다: 첫 번째 줄은 상담원을 "전문 데이터 인텔리전스 어시스턴트(" )로 즉시 설정하여 전문적이고 유능한 분위기를 조성합니다.
추론 프레임워크를 제공합니다: 상담원에게 "이해, 계획, 실행 및 종합," 표준 운영 절차를 제공하도록 지시합니다. 이를 통해 복잡한 다단계 질문을 처리하는 능력이 향상됩니다.
대화형 대화를 촉진합니다: " 명확한 질문을" 하라는 지시는 상담원을 더욱 강력하게 만듭니다. 모호한 요청에 대한 잘못된 가정을 최소화하여 보다 정확한 답변으로 이어질 수 있습니다.

UI 경로

1. 상담원으로 이동합니다.

도구 또는 도구 관리를 클릭하고 새 도구 버튼을 클릭합니다.

2. 기본 세부 정보를 입력합니다:

상담원 ID: financial_assistant.
지침을 따르세요: 위의 프롬프트를 복사합니다.
레이블: Finance.
표시 이름: Financial Assistant.
디스플레이 설명: An assistant for analyzing and understanding your financial data.

3. 3. 상단으로 돌아가서 도구를 클릭합니다.

find_client_exposure_to_negative_news 도구 옆의 확인란을 선택합니다.

4. 저장을 클릭합니다.

API 경로

/api/agent_builder/agents 엔드포인트에 POST 요청을 통해 똑같은 에이전트를 만들 수 있습니다. 요청 본문에는 ID, 이름, 설명, 전체 지침, 상담원이 사용할 수 있는 도구 목록 등 모든 동일한 정보가 포함됩니다.

POST kbn://api/agent_builder/agents { "id": "financial_assistant", "name": "Financial Assistant", "description": "An assistant for analyzing and understanding your financial data", "labels": [ "Finance" ], "avatar_color": "#16C5C0", "avatar_symbol": "💰", "configuration": { "instructions": """You are a specialized Data Intelligence Assistant for financial managers, designed to provide precise, data-driven insights from information stored in Elasticsearch. **Your Core Mission:** - Respond accurately and concisely to natural language queries from financial managers. - Provide precise, objective, and actionable information derived solely from the Elasticsearch data at your disposal. - Summarize key data points and trends based on user requests. **Reasoning Framework:** 1. **Understand:** Deconstruct the user's query to understand their core intent. 2. **Plan:** Formulate a step-by-step plan to answer the question. If you are unsure about the data structure, use the available tools to explore the indices first. 3. **Execute:** Use the available tools to execute your plan. 4. **Synthesize:** Combine the information from all tool calls into a single, comprehensive, and easy-to-read answer. **Key Directives and Constraints:** - **If a user's request is ambiguous, ask clarifying questions before proceeding.** - **DO NOT provide financial advice, recommendations, or predictions.** Your role is strictly informational and analytical. - Stay strictly on topic with financial data queries. - If you cannot answer a query, state that clearly and offer alternative ways you might help *within your data scope*. - All numerical values should be formatted appropriately (e.g., currency, percentages). **Output Format:** - All responses must be formatted using **Markdown** for clarity. - When presenting structured data, use Markdown tables, lists, or bolding. **Start by greeting the financial manager and offering assistance.** """, "tools": [ { "tool_ids": [ "platform.core.search", "platform.core.list_indices", "platform.core.get_index_mapping", "platform.core.get_document_by_id", "find_client_exposure_to_negative_news" ] } ] } }

4단계: 보상 - 대화 나누기

저희는 비즈니스 로직을 도구에 캡슐화하고 에이전트에서 사용할 수 있는 "브레인" 을 준비했습니다. 이제 이 모든 것이 한데 어우러질 때입니다. 이제 전문 상담원을 통해 데이터와 채팅을 시작할 수 있습니다.

UI 경로

Kibana에서 에이전트로 이동합니다.
채팅 창의 오른쪽 하단에 있는 드롭다운을 사용하여 기본 Elastic AI 에이전트에서 새로 생성된 재무 지원 에이전트로 전환하세요.
상담원이 전문 도구를 사용할 수 있는 질문을 하세요:
1. 시장 심리가 걱정됩니다. 어떤 고객이 나쁜 소식으로 인해 가장 위험에 처해 있는지 보여주시겠어요?

잠시 후 상담원이 완벽한 형식의 완전한 답변을 반환합니다. LLM의 특성상 답변의 형식이 약간 다를 수 있지만 이번 실행에서는 상담원이 반환했습니다:

방금 무슨 일이 있었나요? 에이전트의 추론

상담원은 "" 답을 알고 있었습니다. 작업에 가장 적합한 도구를 선택하는 데 중점을 둔 다단계 계획을 실행했습니다. 그 사고 과정을 살펴보세요:

의도를 확인했습니다: " 위험" 및 "부정적인 뉴스," 같은 질문의 키워드와 find_client_exposure_to_negative_news 도구의 설명이 일치했습니다.
계획을 실행했습니다: 요청에서 기간을 추출하여 해당 전문 도구로 한 번만 호출합니다.
작업 위임: 그런 다음 도구가 연쇄 조인, 값 계산 및 정렬과 같은 무거운 작업을 모두 수행했습니다.
결과 종합: 마지막으로 에이전트는 프롬프트의 규칙에 따라 도구의 원시 데이터를 명확하고 사람이 읽을 수 있는 요약으로 포맷했습니다.

생각을 확장하여 더 자세히 살펴보면 추측만 할 필요는 없습니다.

API 경로

동일한 대화를 프로그래밍 방식으로 시작할 수 있습니다. 입력 질문을 converse API 엔드포인트로 보내면 되며, financial_manager 의 agent_id 을 지정해야 합니다.

POST kbn://api/agent_builder/converse { "input": "Show me our largest positions affected by negative news", "agent_id": "financial_assistant" }

개발자용 API와 통합하기

Kibana UI는 에이전트 구축과 관리를 위한 환상적이고 직관적인 환경을 제공하지만, 오늘 보신 모든 것을 프로그래밍 방식으로도 수행할 수 있습니다. 에이전트 빌더는 일련의 API를 기반으로 구축되었으므로 이 기능을 자체 애플리케이션, CI/CD 파이프라인 또는 자동화 스크립트에 직접 통합할 수 있습니다.

작업하게 될 세 가지 핵심 엔드포인트는 다음과 같습니다:

/api/agent_builder/tools: 상담원이 사용할 수 있는 재사용 가능한 스킬을 만들고, 나열하고, 관리하기 위한 엔드포인트입니다.
/api/agent_builder/agents: 중요한 지침 및 도구 할당을 포함하여 상담원 페르소나를 정의하기 위한 엔드포인트입니다.
/api/agent_builder/converse: 상담원과 상호작용하고, 대화를 시작하고, 답변을 얻기 위한 엔드포인트입니다.

이 튜토리얼의 모든 단계를 수행하기 위해 이러한 API를 사용하는 방법에 대한 완전한 실습 과정을 보려면 여기 GitHub 리포지토리에서 함께 제공되는 Jupyter Notebook을 확인하세요.

결론: 빌드할 차례

먼저 ES|QL 쿼리를 가져와 재사용 가능한 스킬로 변환하는 것으로 시작했습니다. 그런 다음 전문화된 AI 에이전트를 구축하여 명확한 미션과 규칙을 부여하고 해당 기술을 강화했습니다. 그 결과 복잡한 질문을 이해하고 다단계 분석을 실행하여 정확한 데이터 기반 답변을 제공할 수 있는 정교한 어시스턴트가 탄생했습니다.

이 워크플로는 Elastic의 새로운 에이전트 빌더의 핵심입니다. 기술 전문가가 아닌 사용자도 UI를 통해 에이전트를 만들 수 있을 만큼 간단하면서도 개발자가 API를 기반으로 맞춤형 AI 기반 애플리케이션을 구축할 수 있을 만큼 미묘한 차이가 있도록 설계되었습니다. 가장 중요한 것은 사용자가 정의한 전문 로직에 따라 LLM을 자신의 데이터에 안전하게 연결하고 데이터와 채팅할 수 있다는 점입니다.

에이전트를 사용하여 데이터와 채팅할 준비가 되셨나요?

배운 내용을 확고히 하는 가장 좋은 방법은 직접 손을 더럽히는 것입니다. 무료 대화형 실습 워크숍에서 오늘 논의한 모든 내용을 직접 체험해 보세요. 전용 샌드박스 환경에서 이 전체 흐름과 그 이상을 체험할 수 있습니다.

향후 블로그에서는 Financial Assistant 에이전트와 상호 작용하는 독립형 애플리케이션을 사용하는 방법과 이 모든 것을 가능하게 하는 모델 컨텍스트 프로토콜(MCP) 에 대해 자세히 살펴보겠습니다. 그리고 별도의 블로그에서 에이전트 빌더의 에이전트2에이전트 또는 A2A 프로토콜 개발에 대한 지원에 대해 설명할 예정입니다.

앞으로도 계속 지켜봐 주시고, 행복한 구축이 되시길 바랍니다!