벡터만으로는 부족하다: 하이브리드 검색과 검색 증강

URL: https://www.youtube.com/watch?v=ksjwtQop4os 날짜: 2026-10-11 채널: aiDotEngineer 원문 제목: Vector Isn't Enough: Hybrid Search & Retrieval — Jeff Vestal & James Williams, Elastic 영상 ID: ksjwtQop4os 발표자: Jeff Vestal(Elastic AI Architect), James Williams(Elastic Solutions Architect, Search) 재생 시간: 1시간 16분 19초

📌 핵심 질문 / 벡터 검색만으로 에이전트의 검색 문제를 해결할 수 있는가

==의미가 비슷한 문장을 찾는 dense vector 검색과 정확한 용어·식별자를 찾는 lexical 검색을 함께 운영하고, 실제 판단 데이터로 결과를 측정해야 에이전트에 전달되는 근거의 품질을 보장할 수 있다.==

• 벡터 검색은 표현이 달라도 같은 뜻을 찾지만 제품 ID·오류 코드·고유명사 같은 정확한 식별자에 약하다.
• BM25 기반 lexical 검색은 키워드와 구문을 정확하게 잡지만 동의어·바꿔 말하기·의미적 유사성을 놓친다.
• Reciprocal Rank Fusion(RRF)은 점수 체계가 다른 두 검색 결과를 순위로 합치는 실용적인 출발점이고, Linear Combination은 점수를 0~1로 정규화한 뒤 가중치를 조정하는 방법이다.
• 필터링, judgment set, search template, reranker를 추가할 때마다 품질과 지연 시간을 함께 검증해야 한다.
• Agent Builder와 ESQL은 검색 도구·스킬·워크플로를 에이전트가 반복 호출하면서 결과의 출처를 남기도록 만든다.

에이전트가 아무리 똑똑해도 검색 계층이 잘못된 문서를 전달하면 그 잘못된 근거를 자신 있게 정답처럼 재구성한다. 따라서 모델을 더 큰 것으로 교체하기 전에 어떤 문서를 어떤 순서로 후보군에 넣었는지, 그 결과가 업무의 relevance 목표를 달성하는지부터 확인해야 한다. Elastic의 접근은 기존 검색을 버리고 벡터로 갈아타는 것이 아니라, lexical·semantic·reranking을 같은 데이터 플랫폼 안에서 목적에 따라 조합하는 것이다.

1. 워크숍의 장면과 실습 설계

검색 품질을 코드 한 줄의 문제가 아니라 ingest부터 최종 답변까지 이어지는 시스템 문제로 다루는 실습형 세션이다.

1.1. Jeff, James와 실습 환경

1. 발표자와 역할

   1. Jeff Vestal은 Elastic의 AI Architect로 소개하며, 올해 직함을 새로 정했으니 관련 있어 보이게 만들었다고 농담한다.
   2. James Williams는 검색에 집중하는 Solutions Architect로서 고객이 곧 실행할 기술 작업을 지원한다고 소개한다.
   3. Jeff는 최근 이동 중 말을 많이 했으므로 이번에는 말을 줄이고 참석자가 직접 실습하게 하겠다고 말한다.

2. 참석자와 환경 준비

   1. 주최 측이 참석자 수를 알려주지 않아 75명을 예상했지만 실제로는 그보다 많았고, 약 75명은 빠르게 시작하며 나머지는 몇 분 더 기다릴 수 있다고 안내한다.
   2. 화면 오른쪽 위의 짧은 URL을 통해 Instruqt 실습 환경에 들어가면 개인 Elastic Serverless 인스턴스가 생성된다.
   3. 각 참가자는 Start를 눌러 환경을 띄운 뒤 Dev Tools 콘솔과 Python 노트북에서 같은 검색 개념을 서로 다른 깊이로 실행한다.
   4. 실습자는 막히면 손을 들 수 있고, Jeff는 화면을 확인해 사소한 설정 문제를 풀어주는 역할을 맡는다.

1.2. 실습의 구성과 진행 방식

1. 네 개의 본 실습과 보너스

   1. 첫 실습은 vector·semantic search의 작동 방식과 유용한 범위를 다룬다.
   2. 둘째 실습은 수십 년간 사용해 온 BM25 기반 lexical·keyword search와 그 한계를 다룬다.
   3. 셋째 실습은 두 검색을 hybrid search로 묶고 RRF와 더 정교한 선형 결합을 비교한다.
   4. 넷째 실습은 검색 결과를 Agent Builder에 넣어 에이전트 답변과 출처 인용이 어떻게 달라지는지 확인한다.
   5. 마지막 보너스 실습은 후보 문서를 2단계에서 다시 정렬하는 reranker의 필요성과 비용을 다룬다.

2. 콘솔과 노트북의 차이

   1. 각 실습의 앞부분은 Elasticsearch API 명령을 Dev Tools 콘솔에서 실행하는 짧은 버전이다.
   2. 뒷부분은 Python Jupyter notebook에서 문서가 왜 특정 순서로 나오는지, 설정을 어떻게 바꾸는지, 튜닝이 왜 필요한지 더 깊게 확인하는 버전이다.
   3. Run All만 누르면 약 10분 안에 끝낼 수 있지만, 노트북의 설명까지 읽으면 워크숍 시간보다 오래 걸리도록 설계됐다.
   4. 발표자는 20~25분마다 참가자 진행 상황을 확인하고 해당 챕터의 핵심을 요약하겠다고 안내한다.

3. 재사용 가능한 자료

   1. 실습 환경은 일주일 동안 열어두며, Instruqt 없이도 공개 GitHub 저장소의 노트북을 자신의 Elasticsearch 클러스터에 연결해 실행할 수 있다.
   2. 오른쪽 위 링크는 실습 콘텐츠, James가 제공한 파란색 링크는 노트북과 코드 저장소라는 식으로 두 링크의 용도를 구분한다.
   3. Elastic은 스트림 처리, lexical·vector search, RAG, Observability, OpenTelemetry, 근본 원인 분석, 보안 탐지와 공격 발견을 주제로 한 무료 추가 워크숍도 제공한다.

2. 에이전트 시대에도 retrieval이 핵심인 이유

RAG라는 용어가 유행의 전면에서 물러났을 뿐, 모델 바깥의 최신·사내·변동 데이터를 공급하는 retrieval 계층은 사라지지 않았다.

2.1. RAG에서 에이전트로의 이동

1. RAG의 위치 변화

   1. 참석자에게 Elastic으로 retrieval-augmented generation 애플리케이션을 만들어 본 사람과 지난 2~3년 동안 RAG라는 말을 너무 많이 들어 지친 사람을 각각 묻는다.
   2. RAG는 없어지지 않았고, 더 유능해진 에이전트가 데이터 검색과 분석의 운영을 관리하게 되면서 배경으로 물러났다는 관점을 제시한다.
   3. 모델이 학습하지 않은 최신 가격, 시간에 따라 바뀌는 정보, proprietary data를 계속 넣어야 하므로 외부 검색 계층은 여전히 필요하다.

2. 검색이 틀리면 모델도 틀린다

   1. 모델에 garbage data를 넣고 그것이 정답이라고 확신 있게 지시하면, 모델은 그 근거를 믿고 답을 만든다.
   2. 모델의 능력을 높이는 것만으로는 잘못된 후보 문서가 만들어내는 오류를 해결할 수 없다.
   3. 검색 계층은 에이전트가 정확한 근거를 보고 분석하도록 만드는 안전장치이며, 이 워크숍의 중심 주제다.

2.2. 검색 전략의 선택 기준

1. 세 가지 기본 층

   1. 우선 BM25 같은 전통 검색으로 정확한 단어와 구문을 찾는다.
   2. 그 위에 dense vector 기반 semantic search를 더해 표현이 달라도 뜻이 같은 문서를 회수한다.
   3. 두 결과로도 첫 번째·두 번째·세 번째 후보의 순서가 중요한 업무를 만족하지 못하면 reranker를 2단계로 추가한다.

2. Elastic이 겨냥하는 환경

   1. 단순한 데이터 규모와 느슨한 지연 시간에서는 여러 제품이 비슷해 보일 수 있다.
   2. 데이터가 커지고 SLA가 빡빡해지면 메모리·스토리지·추론·정확도·튜닝을 한 플랫폼에서 제어하는 능력이 차이를 만든다.
   3. Elastic은 ingest chunking, query-time embedding, 검색, 필터, 재순위화를 데이터 플랫폼과 inference service에 통합해 호출 수와 운영 조정을 줄이는 방향을 취한다.

3. Semantic text와 벡터 검색의 구조

의미 검색은 문장을 수치 벡터로 바꿔 가까운 이웃을 찾지만, ingest와 query 시점에 같은 모델을 써야 하며 후보군의 의미적 유사성이 곧 정확한 일치라는 뜻은 아니다.

3.1. semantic text 필드와 chunking

1. 자동 chunking의 기본값

   1. Elasticsearch의 semantic_text 필드는 텍스트를 임베딩 가능한 조각으로 만들고 검색 시 같은 필드를 활용하도록 돕는다.
   2. 기본적으로 문장 경계에서 나누며 약 250토큰 chunk와 한 문장 overlap을 사용한다.
   3. 설정에 따라 word boundary, paragraph, page 단위 등으로 바꿀 수 있고, 필요한 고객은 자체 chunking과 자체 vector도 SDK로 넣을 수 있다.

2. 큰 context와 late chunking

   1. Jina 모델은 큰 context window를 지원하지만 매번 그 창을 가득 채우는 것이 좋은 것은 아니므로 chunk 크기를 목적에 맞게 줄일 수 있다.
   2. Elastic은 대규모 context를 다루는 late chunking 기법도 언급하지만, 당시 Elastic Inference Service에 완전히 노출된 기능은 아니라고 선을 긋는다.
   3. 실무적으로는 복잡한 semantic chunking을 먼저 도입하기보다 전통적인 chunking과 hybrid search로 같은 문제를 해결하는 경로를 권한다.

3.2. 임베딩 모델과 색인·질의 일관성

1. 동일 모델 사용

   1. 문서 ingest 시 만든 embedding과 query 시 만든 embedding은 동일한 모델에서 나와야 한다.
   2. 서로 다른 모델을 쓰는 것은 발표자의 비유처럼 영어로 만든 좌표를 포르투갈어 좌표로 찾으려는 것과 비슷해 결과가 제대로 맞지 않는다.
   3. 예전에는 개발자가 inference ID와 모델 버전을 따로 추적해야 했지만, semantic field에 모델 설정을 묶으면 한 번 설정한 필드를 여러 팀이 그대로 ingest·query에 사용할 수 있다.

2. Elastic Inference Service

   1. Elastic Inference Service가 워크숍에서 사용하는 모델을 제공하고, Elastic이 인수한 Jina 계열 모델과 자체 개발 중인 dense vector·reranking 모델을 활용한다.
   2. 기본 서비스를 사용해 빠르게 시작할 수 있지만 다른 inference service나 자체 모델을 연결하는 선택지도 남겨둔다.
   3. 텍스트는 필요하면 chunking을 거쳐 inference service로 가고, query 텍스트도 같은 과정을 거쳐 query vector가 된다.

3.3. HNSW와 벡터 효율화

1. 근접 이웃 탐색

   1. 생성된 vector는 HNSW(Hierarchical Navigable Small Worlds) 그래프를 통해 가까운 문서·chunk를 빠르게 찾는다.
   2. 기본 흐름은 query vector를 만들고 HNSW를 탐색해 top-k, 예를 들어 5개나 10개의 후보를 돌려주는 것이다.
   3. “TLS 보안을 어떻게 설정하는가”처럼 질문 표현이 달라도 의미가 같으면 비슷한 문서를 찾아주는 것이 semantic search의 강점이다.

2. 양자화와 메모리

   1. Elastic은 약 2년 전부터 float32 vector를 int8로 양자화해 저장하는 방식을 기본값으로 사용하며, 원래 vector는 보존하면서 메모리에는 양자화된 형태를 둔다.
   2. BBQ(Better Binary Quantization)는 HNSW graph와 vector를 더 압축해 bit 수준까지 줄이면서 recall을 유지하려는 방식이다.
   3. DiskBBQ는 vector 검색의 메모리 부담을 거의 없애는 방향의 최신 형태로 소개된다.
   4. DiskANN 계열도 선택지로 언급되지만, 기본 HNSW와 여러 디스크 기반 알고리즘을 데이터 규모와 지연 요구에 맞춰 선택할 수 있다.

4. 벡터 검색이 깨지는 지점과 BM25의 역할

뜻을 찾는 검색과 문자열을 확인하는 검색은 서로 대체 관계가 아니라 실패 영역이 다른 도구다.

4.1. 벡터가 고유 식별자를 놓치는 이유

1. 의미가 없는 문자열

   1. 제품 ID, 티켓 번호, 오류 코드, 버전 문자열처럼 사람에게도 의미가 거의 없는 고유 토큰은 임베딩 공간에서 안정적인 의미 이웃을 만들기 어렵다.
   2. 특정 키워드나 아주 구체적인 표현을 요구할 때 semantic search는 관련 있어 보이지만 정확히 그 값을 포함하지 않은 문서를 반환할 수 있다.
   3. 이 지점이 둘째 실습에서 BM25, lexical filtering, 전통적인 검색 기법을 다시 가져오는 이유다.

2. pagination과 요약 필드

   1. 100개 결과를 10개씩 계속 받으려면 검색을 매번 다시 실행하지 않고 point in time을 사용해 동일한 검색 시점의 checkpoint ID로 이어받을 수 있다.
   2. 워크숍의 summary 필드는 문서 전체 body를 화면에 출력하면 너무 길어져 실습을 보기 어렵기 때문에 LLM으로 미리 만든 편의용 필드다.
   3. 실제 시스템에서는 ingest pipeline에서 inference 호출을 통해 요약이나 가능한 질의 목록을 생성할 수 있지만, 워크숍에서 검색하는 vector field는 title을 사용한다.

4.2. BM25의 정확성과 한계

1. 잘 맞는 질의

   1. BM25는 오래 검증된 lexical 검색으로 단어와 구문이 실제 문서에 있는지 직접 활용한다.
   2. 정확한 오류 코드, 제품명, ID, 날짜, 특정 phrase처럼 문자열 일치가 중요한 질의에서 강하다.
   3. 추론 호출이 없으므로 대부분의 환경에서 semantic 검색보다 latency profile이 낮다.

2. 무너지는 질의

   1. “비용을 줄이는 방법”과 “지출을 낮추는 전략”처럼 의미는 같지만 단어가 다른 질문은 단순 lexical search가 놓칠 수 있다.
   2. Elastic은 오랜 기간 lexical search만 제공했기 때문에 검색 API에 매우 많은 튜닝·동의어·분석기 기능이 쌓였다고 설명한다.
   3. 지금은 semantic search가 많은 복잡한 lexical 튜닝을 대신할 수 있지만, 구체적 키워드와 낮은 지연 시간이 중요한 경우에는 BM25를 버릴 이유가 없다.

4.3. graph retrieval에 대한 질의응답

1. 그래프 데이터베이스의 위치

   1. 참석자는 graph retrieval 또는 Graph RAG가 필요한지 질문한다.
   2. 발표자는 Elastic이 graph database가 아니며, 그래프는 관계가 명확한 문제에서 역할이 있지만 유지·운영 overhead가 크다고 답한다.
   3. 다중 에이전트 질의에서는 첫 검색으로 표본 문서를 얻고 공통 tag를 확인한 뒤 두 번째 검색에서 filtering하는 방식이 그래프 traversal의 일부 효과를 줄 수 있다.

2. 대규모 확장과 대안

   1. Neo4j 같은 제품이 있지만 multi-billion vector dataset까지 일관되게 확장하는 사례와 필요성을 신중하게 본다.
   2. 분류 모델을 실시간으로 실행해 graph traversal과 비슷한 grouping을 얻거나, NER(Named Entity Recognition) 모델로 사람·위치·회사·제품명을 추출한 뒤 질의를 조정하는 대안을 제시한다.
   3. NER는 작은 모델이라 빠르게 실행되며, 에이전트가 추출한 entity를 이용해 복잡한 스크립트 대신 더 정밀한 검색을 만들 수 있다.
   4. Elastic ML node에 분류 모델을 올리거나 외부 inference를 사용할 수 있지만, 이 세션에서 graph 분야의 새로운 발표를 확정한 것은 아니다.

5. Hybrid search로 두 검색을 결합하기

두 결과의 수치 범위가 다르므로 raw score를 바로 더하면 안 된다. 순위만 이용하는 RRF부터 시작하고, 실제 판단 데이터가 있을 때 점수 정규화와 가중치 튜닝으로 넘어간다.

5.1. RRF(Reciprocal Rank Fusion)의 직관

1. 왜 점수를 바로 합치지 않는가

   1. BM25 점수는 0에서 시작해 데이터와 질의에 따라 사실상 제한 없이 커질 수 있다.
   2. vector similarity는 보통 0~1 범위이므로, lexical 검색의 낮은 품질 결과도 숫자만 보면 좋은 semantic 결과를 압도할 수 있다.
   3. 서로 다른 점수 척도를 억지로 더하지 않고 각 결과의 순위와 rank constant를 사용하는 방식이 RRF다.

2. RRF의 계산 개념

   1. lexical과 semantic 검색을 병렬로 실행한다.
   2. 각 문서가 두 목록에서 몇 등인지 확인하고, rank constant를 포함한 reciprocal rank 기여도를 합친다.
   3. 두 목록 모두 상위에 있는 문서는 최종 순위에서도 올라가며, 한 목록에서만 높고 다른 목록에는 없는 문서는 상대적으로 덜 유리해진다.
   4. 최종 결과는 원래의 raw score 목록이라기보다 결합된 rank order로 이해해야 한다.

3. RRF의 장단점

   1. 데이터의 분포와 가중치를 깊이 알지 못해도 작동하는 out-of-the-box 출발점이다.
   2. rank constant는 조정 가능한 knob이지만, 모든 데이터셋에 보편적인 최적값이 있다는 뜻은 아니다.
   3. “대체로 잘 작동하지만 항상 그렇지는 않다”는 한계를 인정하고, 품질 목표를 넘지 못하면 더 세밀한 방법으로 이동해야 한다.

5.2. 필터링으로 후보군을 줄이기

1. 검색 전 제약

   1. keyword, 지역, 날짜, 상태, 제품군처럼 확실한 조건으로 corpus를 먼저 줄이면 검색이 모든 문서에 넓은 그물을 던지지 않게 된다.
   2. “오늘 피자”를 찾을 때 food 전체를 검색한 뒤 피자를 고르는 것보다, 음식이라는 큰 범주 안에서 pizza 필터를 적용하는 식의 직관이다.
   3. 후보군이 작아지면 정확도뿐 아니라 계산량과 지연 시간도 줄어드는 경우가 많다.

2. 필터의 한계와 장점

   1. 필터는 의미 유사성을 계산하는 기능을 대체하지 않고, 잘못된 영역을 미리 제거하는 보조 장치다.
   2. Elastic은 keyword·geo·date 등 다양한 필터를 빠르게 실행할 수 있으므로 hybrid search 앞단에 배치하기 좋다.
   3. 검색 질의 유형을 파악할 수 있다면 고정된 하나의 전략보다 적절한 필터와 템플릿을 선택하는 편이 낫다.

5.3. Linear Combination과 점수 튜닝

1. 정규화

   1. Linear Combination은 BM25와 vector의 점수를 같은 범위로 만들기 위해 min-max 같은 정규화를 적용한다.
   2. 정규화된 두 점수를 0~1 범위에서 합치면 raw score의 규모 차이가 결과를 지배하지 않는다.
   3. semantic과 lexical에 다른 weight를 주어 특정 질의 유형에서 어느 신호를 더 중시할지 조정할 수 있다.

2. 판단 세트와 실험

   1. judgment set은 특정 query에 대해 사람이 원하는 정확한 문서 목록을 미리 정한 평가 기준이다.
   2. 사람이 직접 만들 수도 있고 LLM의 도움을 받을 수도 있지만, 최종 relevance 기준은 업무 목표에 맞춰 검증해야 한다.
   3. 서로 다른 weight를 실험하고 judgment set에 원하는 문서가 얼마나 정확히, 얼마나 높은 순서로 나오는지 비교한다.
   4. 데이터의 모양이나 예상 query 분포만으로 weight를 자동 결정하는 권위 있는 정답은 아직 제공하기 어렵다.

3. 자동 튜닝에 대한 전망

   1. 이상적인 relevance tuning은 query, 클릭률, thumbs up/down, 사용자 행동 telemetry, 비즈니스 지표를 함께 보고 weight와 전략을 조정한다.
   2. query 유형에 따라 RRF·Linear·reranker의 조합을 바꾸거나, 필요한 filter set을 선택하는 방법이 가능하다.
   3. 발표자는 이런 autotuned relevance를 설정 하나로 켤 수 있으면 개발자 생산성이 크게 올라갈 것이라고 말하지만, Elastic이 그런 기술을 이미 출시했다고 주장하지는 않는다.
   4. Jeff가 CTO에게 다시 제안해 보겠다고 하자, 자동 튜닝을 또 거절하라는 말을 듣게 만들겠다는 농담으로 마무리한다.

5.4. Search template을 이용한 질의 라우팅

1. 전략별 템플릿

   1. RRF용 search template, Linear용 search template, reranker를 포함한 변형을 각각 만들어 둘 수 있다.
   2. query를 검사하는 상위 계층이 “이 유형은 이 템플릿, 저 유형은 저 템플릿”으로 라우팅하면 하나의 검색 전략이 모든 질의를 책임질 필요가 없다.

2. 가벼운 자동 튜닝 계층

   1. LLM이 질의를 읽고 템플릿을 선택한다면, 이는 완전한 수치 자동 튜닝은 아니지만 일종의 “poor man’s autotuning”으로 볼 수 있다.
   2. LLM이 아니어도 분류기나 규칙 엔진이 query 유형을 판별할 수 있다.
   3. 여러 질의 유형을 가진 고급 시스템은 결국 이처럼 검색 전략을 선택하는 계층을 갖게 되며, Elastic search template은 반복적인 애플리케이션 boilerplate를 줄여준다.

6. Agent Builder에서 retrieval을 답변과 행동으로 연결하기

좋은 검색 결과는 답변 품질뿐 아니라 출처의 검증 가능성, 도구 호출의 반복성, 외부 시스템과의 실행 가능성까지 결정한다.

6.1. 잘못된 근거가 만드는 자신감 있는 오답

1. 모델의 설득력과 위험

   1. LLM은 학습 지식 밖의 데이터를 입력받으면 실제로 정답을 찾는 것이 아니라 제공된 근거를 토대로 다음 토큰을 생성한다.
   2. “하늘은 주황색이다”라는 잘못된 자료를 주면 그 자료에 맞춰 하늘이 주황색이라고 답할 수 있다.
   3. 관련된 두 사실 사이의 얇은 차이를 모르면 매우 그럴듯하지만 틀린 답을 만들며, 전문가가 아니면 쉽게 속을 수 있다.

2. 출처 인용의 필요성

   1. 대부분의 기본 모델은 데이터베이스에서 실제 행을 조회하는 방식이 아니므로 스스로 원본 출처를 정확히 인용하지 못한다.
   2. 검색 결과 원문을 모델에 전달하고 모델이 사람이 읽을 답변과 citation을 함께 구성하게 하면 근거를 검증할 수 있다.
   3. 법률 영역에서 존재하지 않는 판례를 만들어 내거나 실제 판례의 의미를 비틀어 인용하는 문제가 보도되는 만큼, 출처 인용은 신뢰와 책임성의 핵심이다.

6.2. Agent Builder의 에이전트·스킬·도구·워크플로

1. 스킬과 도구의 구분

   1. Skill은 특정 작업을 어떤 방식으로 수행할지, 언제 도구를 쓸지, 어떤 결과 형식을 만들지 에이전트에 알려주는 지침이다.
   2. Tool은 검색 실행, workflow 목록 조회, 외부 서비스 호출처럼 실제 행동을 수행하는 기능이다.
   3. 기본 제공 skill에는 검색, 그래프, 시각화 등 목적별 지침이 있고, 사용자는 자체 skill과 tool을 추가할 수 있다.

2. Agent Builder의 연결성

   1. Elastic Agent Builder는 여러 LLM, Elastic Inference Service, 자체 LLM을 연결해 Elastic 내부 데이터에 도구를 실행할 수 있다.
   2. 워크플로는 순서가 있는 작업과 decision tree를 표현하며, 에이전트는 다른 시스템·API·MCP tool을 호출할 수 있다.
   3. 예를 들어 관측 데이터에서 자원 부족을 감지한 뒤 Kubernetes 환경을 자동 확장하는 workflow를 호출할 수 있다.
   4. 이 자동 실행 사례는 실습의 핵심 범위 밖이지만, retrieval이 단순 답변을 넘어 실제 행동을 시작하는 기반임을 보여준다.

3. API 우선과 잠금 회피

   1. Kibana UI에서 보이는 Agent Builder의 기능은 API로도 프로그래밍할 수 있다.
   2. UI에서 만든 prototype을 버리고 애플리케이션을 처음부터 다시 만들 필요 없이 같은 endpoint를 custom UX에서 재사용할 수 있다.
   3. 나중에 다른 framework나 자체 API로 교체해도 연결할 수 있도록 turnkey 경험은 주되 vendor lock-in은 피하려는 방향이다.
   4. 유연성이 큰 만큼 어떤 질문에 대한 답이 “it depends”로 시작하는 경우가 많다는 농담도 덧붙인다.

6.3. ES|QL, Index Search와 MCP

1. ES|QL의 기본 개념

   1. ES|QL은 SQL과 비슷한 문법에 pipe를 연결해 한 단계의 결과를 다음 단계로 넘기는 Elastic의 새로운 query language다.
   2. ES|QL tool은 정해진 query와 필드를 사용해 문서를 조회하고, Index Search는 인덱스 목적·mapping·field·여러 인덱스의 결합 방식을 에이전트에 알려준다.
   3. 에이전트가 아무 정보 없이 여러 index를 탐색하면 mapping을 계속 추측하느라 round trip과 token을 낭비할 수 있는데, index search가 그 탐색을 크게 줄인다.

2. 에이전트 검색에서의 장점

   1. ES|QL은 query를 단계별로 실행하고, 필요한 곳에서 두 검색 흐름을 fork한 뒤 fuse할 수 있다.
   2. MCP와 Agent Builder에 parameterization이 잘 연결돼 agentic search의 반복 query를 만들기 쉽다.
   3. 발표자는 Splunk query language가 추구했던 로그·비정형 데이터 검색의 장점과 SQL의 검증된 개념을 ES|QL이 결합한다고 설명한다.
   4. Search·Security·Observability 전 영역에서 앞으로 혁신의 주요 통로가 될 것이며, 외부 Parquet 같은 데이터와 Elastic 데이터를 한 query에서 결합하는 federated search도 개발 중인 방향으로 언급된다.

3. MCP로 확장되는 도구

   1. Agent Builder의 기본 도구와 custom tool은 MCP로 노출되므로 외부 에이전트가 MCP 연결로 사용할 수 있다.
   2. Kibana가 MCP server 역할을 하며, 외부 MCP server를 호출하는 도구도 구성할 수 있다.
   3. 이 구조는 Elastic 내부 검색과 외부 API·workflow를 하나의 에이전트 실행 흐름에 배치한다.

6.4. Exit code 137 진단 실습

1. 질문의 두 부분

   1. 실습 에이전트는 “exit code 137로 클러스터가 죽는 이유”와 “재발을 막기 위해 어떤 설정을 바꿀지”를 동시에 해결해야 한다.
   2. 먼저 skill을 읽고, 검색 도구를 여러 번 호출해 Elastic 문서에서 원인을 찾는다.

2. 검색과 실행 결과

   1. 137은 out-of-memory 상황에서 OOM killer가 프로세스를 종료한 결과로 설명된다.
   2. 에이전트는 JVM 옵션을 조정하는 방법을 찾아 재발 방지 설정까지 답한다.
   3. 이 흐름은 agentic retrieval이 단순히 문서를 한 번 찾는 것이 아니라 skill 적용, 반복 검색, 원인 진단, 조치 제안으로 이어지는 모습을 보여준다.
   4. 개발자는 같은 Agent Builder 흐름을 검색 logic과 query language를 시험하는 prototype·debugging 도구로 사용할 수 있다.

6.5. 결과 화면과 감사 추적

1. 답변의 근거 확인

   1. Agent Builder 결과에는 hybrid search query가 사용한 흐름과 결과의 citation이 표시된다.
   2. 사용자는 citation을 클릭해 원문 문서와 URL을 확인할 수 있고, 검색 결과가 다섯 개로 제한됐다면 다섯 개가 반환됐다는 사실도 화면에서 확인한다.

2. Discover와 원문 링크

   1. Kibana Discover로 이동하면 반환된 다섯 문서를 직접 볼 수 있고, body와 URL 필드를 확인할 수 있다.
   2. URL이 문서에 실제로 들어 있으므로, 답변이 임의의 링크를 추측하는 것이 아니라 원문으로 연결된다.
   3. 검색 과정, 문서, citation을 함께 남기는 것이 에이전트의 답변을 검증하고 디버깅하는 감사 추적이 된다.

7. Reranking을 언제 추가할 것인가

Reranker는 전체 corpus를 다시 읽는 단계가 아니라 1차 검색의 작은 후보군을 query와 문서의 공동 점수로 재정렬하는 2차 추론 단계다.

7.1. 2단계 검색의 구조

1. 1차 회수

   1. BM25, vector, hybrid search로 큰 후보 집합을 빠르게 가져온다.
   2. 1차 단계에서는 query와 문서를 각각 미리 embedding했기 때문에 HNSW나 Disk 기반 알고리즘으로 빠르게 처리할 수 있다.

2. 2차 재정렬

   1. Reranker는 query와 문서를 scoring 시점에 함께 보고 관련도를 다시 계산한다.
   2. query와 document를 함께 처리하므로 query 시 inference를 실행해야 하며, 전체 corpus에 적용하면 latency가 지나치게 커진다.
   3. 먼저 20개·50개처럼 작은 후보군을 가져온 뒤 그 안에서 rerank해야 비용과 품질의 균형을 맞출 수 있다.

7.2. pointwise와 listwise

1. Pointwise reranker

   1. Jina Reranker V2로 대표되는 pointwise 방식은 각 query-document 쌍을 독립적으로 보고 점수를 준다.
   2. 후보 문서끼리 매우 다르고 각 문서의 관련도를 따로 판단해도 충분한 데이터에서는 빠르고 단순하다.

2. Listwise reranker

   1. Jina V3로 소개된 listwise 방식은 후보 목록 전체를 함께 보고 문서 사이의 미세한 차이를 비교한다.
   2. 최대 64개 후보처럼 한 번에 묶인 문서가 모두 비슷한 내용을 다룰 때 어느 문서가 더 정확한지 구분하는 데 유리하다.
   3. 후보를 모두 메모리에 두고 한꺼번에 평가하므로 pointwise보다 memory와 시간이 더 필요하다.
   4. 후보가 서로 뚜렷하게 다르면 pointwise로 충분할 수 있고, 비슷한 후보가 경쟁하면 listwise가 더 나은 선택이 될 수 있다.

7.3. 품질과 latency의 의사결정

1. 추가 비용을 정당화하는 경우

   1. 첫 번째, 두 번째, 세 번째 chunk 순서가 평가 점수와 최종 답변을 좌우하는 agentic search에서는 reranking이 큰 차이를 만들 수 있다.
   2. 비슷하게 맞는 문서를 여러 개 넣으면 LLM이 어느 것을 골라야 할지 혼란스러워 잘못된 하나를 선택할 수 있다.
   3. 이때 reranker가 더 정확한 문서를 앞에 배치하면 적은 context로도 정답을 만들 가능성이 높아진다.

2. 추가하지 않아도 되는 경우

   1. 1차 hybrid search가 이미 필요한 recall·precision 목표를 달성하고 모델이 충분히 좋은 후보를 고르면 reranker를 추가하지 않는다.
   2. 새로운 inference 단계는 반드시 latency와 운영비를 늘리므로 품질 개선이 실제로 측정될 때만 도입한다.
   3. “BM25+semantic으로 충분하면 멈추고, 부족할 때만 reranker를 검증한다”는 것이 실용적인 happy path다.

3. 하나의 호출로 두 단계 실행

   1. Elastic retriever에 reranker와 모델, query를 지정하면 1차 회수와 2차 정렬을 한 API 호출로 실행할 수 있다.
   2. ES|QL에서도 rerank를 구성할 수 있어 inference API 호출, 검색, 재정렬을 애플리케이션이 각각 관리하지 않아도 된다.
   3. 지연 시간을 감당할 수 있고 순위 정밀도가 중요할 때만 이 통합 2단계를 사용한다.

8. 시간순 진행과 실무 체크리스트

8.1. 주요 타임라인

1. 00:00~06:35: Jeff와 James 소개, Instruqt 환경·공개 repo 안내, semantic·lexical·hybrid 실습의 전체 구성 설명.
2. 06:35~12:02: Elastic Inference Service, Jina 모델, semantic text, 250토큰 chunk와 overlap, late chunking 논의.
3. 12:02~17:08: hybrid search가 Elastic의 핵심 주장이라는 확인, 동일 embedding 모델, HNSW와 top-k semantic retrieval 설명.
4. 17:08~21:23: 제품 ID 등 exact identifier의 벡터 검색 실패, point in time pagination, summary field, int8·BBQ·DiskBBQ 설명.
5. 21:23~26:07: graph retrieval·Neo4j 질문, classification·NER 모델과 multi-billion scale에 대한 답변.
6. 26:07~33:52: RRF rank constant, latency·relevance trade-off, BM25의 강점과 추론 지연 문제.
7. 33:52~41:52: autotuning 전망, RRF·filter·min-max 정규화·Linear Combination·judgment set·search template.
8. 41:52~50:16: 잘못된 근거가 만드는 오답, Agent Builder와 workflow, API 재사용 및 vendor lock-in 회피.
9. 50:16~57:57: citation, skill과 tool, ESQL·Index Search·MCP·federated search 방향.
10. 57:57~65:28: exit code 137 OOM 진단, ES|QL query 흐름, 결과 문서·URL·citation 감사 추적.
11. 65:28~73:06: 2단계 reranking, latency 예산, pointwise·listwise 비교, 한 번의 retriever 호출, 자료와 마무리.

8.2. 구현 전 점검

1. 데이터와 모델

   1. 문서와 query에 동일한 embedding model과 inference ID를 사용한다.
   2. 문서 길이와 업무의 검색 단위를 보고 chunk 크기, overlap, page·paragraph boundary를 정한다.
   3. 제품 ID, 오류 코드, 날짜, 지역 같은 구조화 조건은 vector에 맡기지 말고 filter나 BM25로 보완한다.

2. 검색 결합

   1. 알 수 없는 query 분포에서는 RRF로 시작한다.
   2. 품질 목표가 명확하고 judgement set이 있으면 score normalization과 weight 실험으로 Linear Combination을 튜닝한다.
   3. query 유형이 여러 개면 search template을 전략별로 나누고 라우팅 계층을 둔다.

3. 평가와 운영

   1. click, thumbs up/down, business metric, latency, token 비용을 함께 기록한다.
   2. 후보 수를 늘리는 것과 상위 순위를 정밀하게 만드는 것을 구분한다.
   3. 1차 hybrid 결과가 부족할 때만 reranker를 도입하고, pointwise와 listwise를 후보의 유사도·메모리·지연 시간으로 비교한다.
   4. 최종 답변에는 원문 URL과 citation을 남겨 사용자가 근거를 직접 확인하게 한다.

주요 발언 모음

“If you feed these models garbage data and you confidently tell them this is the answer, pretty much they're going to believe you.”

“The core thesis right now is that BM25-based search and dense vector semantic search need to be put together to form hybrid search.”

“Anytime you add anything on top of BM25 and semantic search, you're going to be taking on an additional latency hit. Only do that if you need to.”

“A poor result in a lexical BM25 search is almost always going to beat out, from a pure number perspective, a good semantic search.”

“We have not released any technology that does autotuned relevance yet.”

“Most models do not have the ability to cite their sources because it's not a database.”

“The goal is to provide as much turnkey experience as possible, but not lock you in.”

“If your data is pretty diverse, pointwise usually works out; if the candidates are extremely similar, listwise is probably going to help.”

핵심 데이터 & 수치

• 영상 길이: 1시간 16분 19초이며, 검색·에이전트·reranking을 실습의 흐름에 맞춰 다룬다.
• chunk 기본값: 문장 경계에서 약 250토큰으로 나누고 한 문장 overlap을 둔다.
• 실습 환경: 약 75명을 예상했지만 더 많은 사람이 참석했고, Instruqt 환경은 일주일 동안 접근 가능하다고 안내했다.
• 검색 결과: 예시는 top-k 5개 또는 10개 후보를 반환하며, Agent Builder 시연에서는 5개 결과를 제한해 보여준다.
• pagination: 100개 결과를 10개씩 읽을 때 point in time checkpoint를 사용해 검색을 다시 실행하지 않는다.
• 양자화: float32 vector를 int8로 메모리에 저장하는 기본 양자화, bit 수준으로 압축하는 BBQ, 메모리 부담을 줄이는 DiskBBQ를 언급한다.
• listwise 후보: Jina V3 예시에서 최대 64개 후보를 함께 비교하는 방식으로 설명한다.
• 진행 간격: 발표자는 20~25분마다 실습 상황을 확인하고 챕터 요약을 제공한다.
• latency 원인: semantic search는 inference endpoint 호출을 추가하므로 vector DB 자체가 빨라도 inference가 병목이면 전체 검색이 느려진다.
• exit code 137: OOM killer가 프로세스를 종료한 흔적으로, JVM 설정과 메모리 정책을 점검해야 한다.

결론 및 시사점

1. 검색 시스템의 출발점은 “어떤 모델이 더 똑똑한가”가 아니라 “에이전트가 어떤 근거를 받는가”다.
2. 의미적 유사성이 필요한 질의에는 dense vector를 사용하고, 정확한 토큰·식별자에는 BM25와 필터를 사용한다.
3. 두 신호를 결합할 때 raw score를 바로 더하지 말고, RRF로 순위를 합치거나 정규화한 Linear Combination을 사용한다.
4. 판단 세트와 사용자 telemetry 없이 최적 weight를 추측하지 말고, query 유형과 업무 relevance 목표를 기준으로 실험한다.
5. 여러 검색 전략을 search template으로 만들고 query를 적절한 전략으로 라우팅하면 하나의 만능 검색기를 강요하지 않아도 된다.
6. 검색 결과가 충분하면 reranker를 추가하지 않으며, 상위 후보 순서가 중요한 업무에서만 추가 추론 비용을 품질 개선과 비교한다.
7. pointwise는 서로 다른 후보를 빠르게 비교하고, listwise는 비슷한 후보들의 미세한 차이를 비교할 때 유리하다.
8. Agent Builder는 검색을 skill·tool·workflow·MCP로 연결하고, API로 동일한 흐름을 애플리케이션에 재사용하게 한다.
9. ES|QL과 Index Search는 에이전트가 인덱스 구조를 추측하느라 token과 round trip을 낭비하지 않게 하는 검색 인터페이스다.
10. 원문 URL과 citation을 남기면 답변을 검증하고 잘못된 retrieval을 역추적할 수 있다.

20줄 핵심 요약

1. 벡터 검색은 표현이 달라도 같은 의미를 찾지만 고유 식별자와 정확한 문자열에는 약하다.
2. BM25는 제품 ID와 오류 코드처럼 정확히 일치해야 하는 토큰을 빠르게 찾아낸다.
3. lexical 검색은 동의어와 바꿔 말한 문장을 놓치므로 의미 검색의 보완이 필요하다.
4. 에이전트가 아무리 유능해도 잘못된 문서를 근거로 주면 자신 있게 오답을 만든다.
5. semantic text는 문서를 기본 약 250토큰 chunk와 문장 overlap으로 나눠 임베딩한다.
6. ingest와 query 시점에는 동일한 embedding model을 사용해야 의미 공간이 일치한다.
7. HNSW는 query vector와 가까운 문서 chunk를 찾아 top-k 후보를 반환한다.
8. int8 양자화와 BBQ·DiskBBQ는 recall을 유지하면서 벡터 메모리 부담을 낮춘다.
9. RRF는 점수 범위가 다른 BM25와 vector 결과를 순위 기반으로 합치는 실용적인 시작점이다.
10. Linear Combination은 점수를 정규화하고 lexical·semantic 신호의 weight를 조정한다.
11. keyword·지역·날짜 필터는 검색 후보군을 줄여 품질과 지연 시간을 함께 개선할 수 있다.
12. judgment set은 특정 질의에 원하는 문서를 정해 검색 튜닝 결과를 객관적으로 비교하게 한다.
13. search template은 질의 유형에 따라 RRF·선형 결합·reranker 전략을 선택하게 한다.
14. 클릭률과 thumbs up/down 같은 telemetry를 활용한 relevance 자동 튜닝은 아직 해결되지 않은 과제다.
15. Agent Builder는 에이전트가 skill과 tool을 사용해 검색하고 workflow와 외부 API까지 호출하게 한다.
16. ES|QL과 Index Search는 에이전트가 인덱스 구조를 탐색하는 반복 호출을 줄여준다.
17. 검색 문서의 실제 URL과 citation은 모델 답변을 원문까지 검증할 수 있게 만든다.
18. Reranker는 전체 corpus가 아니라 1차 검색의 작은 후보군을 query-document 공동 점수로 재정렬한다.
19. Pointwise는 독립 후보에 효율적이고 listwise는 서로 비슷한 후보의 미세한 차이를 비교하는 데 유리하다.
20. retrieval 품질을 측정한 뒤 필요한 경우에만 reranking과 추가 inference latency를 감수해야 한다.