에이전트(Agent) 시대, 검색 패러다임의 변화

한 번 검색하고 답하던 시스템에서, 탐색하고 다음 행동을 결정하는 시스템으로.

검색은 어떻게 흘러가고 있을까?

#Agentic Search #Agentic RAG #Search #Retrieval #Open Source

에이전트(Agent)의 시대

LLM은 이제 도구를 호출하고 그 결과를 바탕으로 다음 행동을 결정하는 Agent로 확장되었다.

Agent는 한 번의 ‘생성’으로 끝나지 않는다. 정보 탐색 → 판단 → 행동 → 재탐색을 반복하며 주어진 목표를 수행한다.

이 과정에서 검색의 역할도 달라지고 있다. Agent에게 검색은 단순히 정보를 가져오는 기능이 아니라, 다음 판단과 행동을 위해 정보를 확보하는 핵심 도구가 되었다.

검색 한 번으로 답할 수 없는 질문

그래서 이제 검색은 한 번으로 충분하지 않을 수 있다. ‘검색’을 수행하는 최종 목적이 ‘정보 찾기’에서 ‘지시 수행’으로 바뀌었기 때문이다.

다음과 같은 질문을 생각해보자.

“2024년과 2025년의 특정 제품 판매량을 비교하고, 변화의 원인을 분석해줘.”

사람에게는 하나의 질문이지만, 답해야하는 에이전트 입장에서는 여러 단계의 탐색이 필요하다. 2024년 판매량과 2025년 판매량을 각각 찾아야 한다. 그리고 두 값을 비교하고, 변화가 발생했다면, 그 원인을 다시 찾아야 한다.

필요한 과정은 다음과 같이 바뀐다.

여기서 재밌는 점은 초기 검색 결과가 다음 검색의 방향을 바꾼다는 것이다. 즉, 검색 결과가 다음에 무엇을 해야 할지를 결정하도록 참조되는 ‘상태값(State)’이 된다.

2024년 판매량과 2025년 판매량에 따라, 증감 여부가 결정되고 이에 따라 ‘감소’에 대한 이유를 찾아야 할 것인지 ‘증가’에 대한 이유를 찾아야 할 것인지가 결정된다.

다시 말해, 검색이 단순히 ‘관련 문서를 찾는 작업(또는 관련성을 계산하는 작업)’ 에서 ‘다음 행동을 결정’하는 작업으로 확장된 셈이다.

무엇을 먼저 찾을지 ‘계획’하고, ‘검색’하고, 결과를 ‘평가’하고, 필요하면 ‘재검색’하는 과정이 있는, 바로 이 지점에서 Agentic Search라는 개념이 등장한다.

RAG가 LLM에게 외부 지식을 연결했다면, Agentic Search는 한 단계 더 나아가 그 지식을 얻기 위한 ‘검색 과정 자체’를 동적으로 조정한다.

Agentic Search란?

그렇다면 Agentic Search는 무엇이며, 기존의 검색이나 일반적인 RAG와 무엇이 다를까?

단순하게 말하자면, 검색의 결과에 따라 다음 검색과 탐색 전략을 동적으로 결정하는 검색 시스템이다.

기존의 검색 시스템은 대체로 다음과 같은 구조를 갖는다.

사용자가 질의를 입력하면 검색 시스템은 관련성이 높은 문서를 찾아 반환한다. 전형적인 RAG 역시 기본적인 흐름에서는 크게 다르지 않다.

위 구조에서는 검색 결과가 최종 답변을 위한 입력으로 사용된다. 검색이 끝나면 그 역할도 사실상 끝난다.

하지만 Agentic Search에서는 검색 결과가 최종 답변의 재료인 동시에, 다음 검색을 결정하기 위한 새로운 입력이 된다. 이러한 Agentic Search의 검색 루프를 RAG에 적용한 형태가 Agentic RAG라고 볼 수 있다.

따라서 검색은 하나의 독립적인 기능이 아니라 하나의 탐색 루프를 구성하는 요소이자 과정이 된다.

아래 그림은 구글 리서치에서 발표한 Agentic RAG에 대한 자료로, 탐색 루프가 잘 표현되어 있다.

(출처 : https://research.google/blog/unlocking-dependable-responses-with-gemini-enterprise-agent-platforms-agentic-rag/)

사용자 질의가 입력되면 Root Agent가 검색 과정을 조정하고, Planner & Query Rewriter가 필요한 정보를 정의해 여러 Docs/DB, MCP 등의 검색 소스를 탐색한다. 수집된 정보는 Sufficient Context Agent가 평가하여 정보가 충분하면 Synthesis Agent가 최종 답변을 생성한다. 정보가 부족하다면 검색 계획과 질의를 다시 조정해 추가 탐색을 수행한다.

이를 조금 더 일반화하면 Agentic Search는 다음과 같은 루프를 갖는다고 볼 수 있다.

먼저 현재 목표를 해결하기 위해 무엇을 찾아야 하는지 계획한다. 이후 검색을 수행하고, 검색 결과를 관찰하고 평가한다. 결과가 충분하지 않다면 기존 계획을 수정하거나 새로운 검색을 생성한다. 필요한 정보가 확보될 때까지 이 과정을 반복한다.

이 때문에 Agentic Search의 핵심은 단순히 “검색을 여러 번 한다”는 데 있지 않다. 검색 횟수가 여러 번이라고 해서 모두 Agentic Search가 되는 것은 아니다.

위와 같이 미리 정해진 순서대로를 실행하는 고정된 파이프라인도 여러 번 검색할 수 있다.

Agentic Search에서 중요한 차이는 이전 결과가 이후 검색의 전략과 경로에 영향을 준다는 것이다.

이 차이는 검색 시스템의 설계 방식에도 영향을 준다.

기존 검색 시스템에서는 ‘어떤 문서를 얼마나 정확하게 찾아오는가’가 핵심 문제였다면, Agentic Search에서는 여기에 더해 ‘무엇을 검색할 것인지’, ‘어떤 검색 방법을 사용할 것인지’, ‘언제 검색을 멈출 것인지’까지 중요한 문제가 된다.

검색 대상과 검색 방법도 하나로 고정되지 않을 수 있다. 어떤 질의에서는 BM25와 같은 lexical search가 적합할 수 있고, 다른 질의에서는 dense retrieval이나 reranker가 필요할 수 있다. 외부 웹 검색이나 API, 정형화 DB, 사내 문서 검색 등의 서로 다른 검색과 도구를 조합할 수도 있다. 

단순히 “다시 검색할 것인가”만 결정하는 것이 아니라, 무엇을, 어떤 방법으로, 어떤 도구를 사용해 검색할 것인지까지가 상황(또는 현재 상태)에 따라 달라져야하는 것이다.

결국 Agentic Search는 검색 모델 하나의 문제가 아니라,

“주어진 목표를 해결하기 위해 검색을 어떻게 계획하고, 실행하고, 평가하고, 다시 조정할 것인가”

라는 검색 시스템 전체의 문제로 확장된다. 

이러한 요구에 대한 반응은 오픈소스 프레임워크와 엔터프라이즈 플랫폼에서 다르게 나타난다. LangGraph, Haystack, LlamaIndex와 같은 오픈소스 생태계에서는 Agent의 workflow와 검색 도구를 개발자가 직접 조합하고 제어하는 방향이 두드러진다. 반면 Google, Microsoft, AWS와 같은 엔터프라이즈 플랫폼에서는 Query Planning, 다양한 검색 소스의 통합, 검색 결과의 평가와 재검색 같은 과정을 플랫폼 수준에서 제공하는 방향으로 발전하고 있다.

따라서, Agentic Search에서 중요한 것은 특정한 검색 모델 하나를 선택하는 것이 아니다. 주어진 상황에 맞는 검색 방식을 선택하고, 필요한 만큼 탐색하고, 그 과정을 빠르고 효율적으로 수행할 수 있는 검색 시스템을 만드는 것이다.

이때 검색이 한 번의 호출로 끝나지 않고 여러 차례 반복된다면, 개별 검색의 성능과 비용은 전체 탐색 과정에 누적된다. 따라서 검색 자체를 얼마나 빠르고 저렴하게 수행할 수 있는가 역시 Agentic Search의 중요한 시스템 요구사항이 된다.

더 빠르게, 더 싸게, 그리고 효율적으로

검색이 반복될수록 더 빠른 검색과 낮은 비용이 필요하고, 동시에 충분한 검색 품질도 유지해야한다.

Agentic Search를 이해하기 위한 비유로 OODA Loop를 생각해볼 수 있다. 전투에서 한 번의 판단을 ‘완벽’하게 만드는 것보다 상황을 관찰하고, 결정하고, 행동하는 과정을 얼마나 ‘빠르게’ 반복할 수 있는지도 중요하다. MiG-15와 F-86의 공중전 사례는 이러한 관점을 설명할 때 자주 언급된다.

(참고 문서 : 느린 비행기가 이겼다 - https://inkmoat.com/ooda-loop-boyd-speed/)

물론, Agentic Search를 OODA Loop와 동일하다는 의미는 아니다. 다만 검색 결과를 빠르게 관찰하고, 판단하고, 행동한 뒤 다시 관찰하는 반복 구조라는 점에서 유사한 관점으로 이해할 수 있다.

Agentic Search에서도 중요한 것은 하나의 검색 모델이 모든 문제를 해결하는 것이 아니다. 현재 상황에 맞는 검색 방식을 선택하고, 필요한 정보를 효율적으로 확보하며, 그 결과에 따라 다음 행동을 빠르게 결정하는 것이다.

이러한 관점에서 검색 기술의 변화를 살펴보면 크게 세 가지 방향으로 정리할 수 있다.

- 작고 빠른 검색 모델

- 다시 중요해진 Lexical 계열 검색

- 검색 비용과 지연 시간을 줄이는 효율화

1. 작고 빠른 검색 모델

Agentic Search에서는 하나의 사용자 질의가 여러 차례의 검색 호출로 확장될 수 있다. 따라서 검색 모델은 개별 호출의 정확도뿐 아니라, 전체 탐색 과정에서 반복적으로 감당할 수 있는 latency와 연산 비용까지 함께 고려해야 한다.

이에 따라 작고 빠른 검색 모델의 중요성이 커지고 있다.

작은 모델에 대한 개발은 오픈 소스에서도 뚜렷하게 나타나는데, 아래는 허깅페이스에 업로드된 모델 가운데 한국어를 포함한 다국어를 지원하는 1B 내외 이하의 dense 계열 모델을 중심으로 정리한 것이다.

이 표의 목적은 특정 모델의 성능 순위나 우열을 비교하는 것이 아니라, 최근 embedding 모델이 성능뿐 아니라 모델 크기와 추론 효율을 함께 고려하는 방향으로 세분화되고 있다는 점을 보여주는 데 의미가 있다.

예를 들어 EmbeddingGemma-300과 jina-embedding-v5-text-small의 경우, 비교적 작은 모델 크기에서도 높은 성능을 제시하고 있다.

또한 Qwen3(Alibaba), Nemotron(Nvidia)의 경우, 4B/8B 급의 큰 모델로 높은 점수로써 상위 Rank를 홍보하면서도 1B 이하 급의 compact 모델도 같이 제공하는 사례가 나타나고있다. 특히, Nemotron-3-Embed-1B-BF16의 경우, 타 모델의 4B 급 이상의 성능을 나타내고 있어 큰 성능 향상을 보여줬다.

(※다만, MTEB은 일반적인 수준의 벤치마크일뿐, 주어진 Task에 필요한 평가 데이터는 직접 구축하여 모델을 선정하는 것이 바람직하다) 

재밌는 점은 이전과 달리, 평가 지표가 ‘정확도’와 ‘파라미터’의 2차원으로 표현되는 경우가 많아졌다는 것이다.

(출처 : https://huggingface.co/jinaai/jina-embeddings-v5-text-small)

(출처 : https://huggingface.co/BidirLM/BidirLM-270M-Embedding)

이러한 소형화 흐름은 검색 후보를 생성하는 Dense Retrieval에만 나타나는 것은 아니다. 검색 결과를 다시 정렬하는 Reranker에서도 유사한 경향이 보인다.

아래 표는 허깅페이스에 업로드된 모델 가운데 한국어를 포함한 다국어를 지원하는 2B 내외 이하의 Reranker 모델을 정리한 것이다.

마찬가지로 Reranker에서도 대형 모델 하나로 모든 검색 요청을 처리하기보다, 충분한 검색 품질을 유지하면서 더 빠르게 실행할 수 있는 소형 모델을 활용하려는 흐름이 나타나고 있다. 또한 모든 질의에 동일한 Reranker를 적용하기보다는 질의의 특성이나 검색 상황에 따라 Reranker의 사용 여부와 모델을 선택하는 방식도 중요해지고 있다.

2. 다시 중요해진 Lexical 계열 검색

Agentic Search의 등장과 함께 Lexical 검색의 역할도 다시 주목받고 있다. 그 이유는 모든 검색 질의가 ‘의미적으로 비슷한 문서’를 찾는 문제가 아니기 때문이다.

다음과 같은 질의를 생각해보자.

이 질의에서 ‘PX-7812’는 일반적인 의미를 갖는 문장이 아니라 특정한 제품 코드다. 이 경우 검색 시스템은 ‘PX-7812’라는 문자열이 실제 문서에 존재하는지를 정확하게 찾는 것이 중요하다. 도메인 특화 고유명사나 제품 코드, 숫자, 문서 번호, 명령어 등을 찾는 경우에서도 마찬가지다.

또한, Lexical 검색이 갖는 단순함은 장점이 된다. BM25와 같은 전통적인 검색 방식은 문서와 질의를 역색인 기반으로 처리하기 때문에 별도의 모델 추론이 없이, CPU 환경에서도 빠르게 검색할수 있다. 

특히 대규모 문서 집합에서는 전체 문서 가운데 질의와 관련된 후보를 빠르게 좁혀주는 ‘전역 후보 선별(Global Candidate Ranking)’ 자체가 중요한 역할을 하게 된다.

‘BM25 Wins at Scale: A Scaling Study of Retrieval-Augmented Generation Paradigms’ 논문에서는 1,144개부터 511,959개까지 문서 수를 단계적으로 증가시키면서 BM25, Dense Retrieval, Graph-based RAG, File-System 기반 Agent의 검색 방식을 동일한 평가 환경에서 비교했다. 

그 결과 작은 corpus에서는 File-System 기반의 Agent가 BM25와 비슷하거나 앞서는 경우가 있었지만, corpus가 약 1,000만 token 규모에 이르면서 BM25가 이를 추월했고 이후 더 큰 규모에서는 BM25가 지속적으로 앞섰다. 전체 511,959개 문서에서는 BM25의 점수가 50.5, File-System Agent는 30.7로 약 20점의 차이가 나타났다.

(출처 : 「BM25 Wins at Scale: A Scaling Study of Retrieval-Augmented Generation Paradigms」, arXiv, arXiv:2607.26497)

해당 실험은 corpus 규모가 커질수록 파일 시스템을 직접 탐색하는 Agent보다 BM25의 상대적인 경쟁력이 높아졌으며, Dense Retrieval보다도 높은 accuracy를 보였다. 

Agent가 직접 파일을 탐색하는 방식은 작은 검색 공간에서는 여러 차례의 탐색과 추론을 통해 유연하게 관련 정보를 찾아낼 수 있다. 하지만 검색 공간이 커지면 Agent가 ‘어디를 탐색해야 하는가’를 결정하기 위한 탐색 비용이 증가한다. 

반면 BM25는 역색인을 이용해 전체 corpus를 모든 문서와 직접 비교하지 않고, 질의와 일치하는 후보를 효율적으로 탐색할 수 있다. 즉, 다양한 소스와 큰 Corpus를 갖는 Agent 환경에서는 전역적인 후보 검색의 가치가 커질 수 있다는 것이다.

그렇다고 해서 Dense Retrieval의 역할이 사라진다거나, BM25가 항상 더 우수하다는 것은 아니다. 사용자의 표현과 문서의 표현이 서로 다르지만 의미적으로 관련된 내용을 찾아야 하는 경우에는 Dense Retrieval이 여전히 유용하다. 이러한 관점에서 검색 시스템에는 데이터 소스/특성에 따라 검색 모델을 달리하거나, 장점을 결합한 하이브리드 검색이 자주 활용되어왔다.

하이브리드 검색에서는 BM25와 Dense Retrieval을 함께 사용하는 것뿐 아니라, 서로 다른 척도로 산출된 검색 점수를 어떻게 비교하고 결합할 것인지도 중요한 문제가 되는데, 최근에는 Bayesian BM25(이하, BBM25)와 같은 접근 방식도 등장하고 있다. 

BBM25는 BM25 점수를 확률적 값으로 보정해 lexical relevance와 vector similarity와 같은 서로 다른 검색 신호를 하나의 프레임워크 안에서 결합하려는 방식이다. Cognica는 BM25의 순위를 보존하면서 점수를 [0,1] 범위의 확률 형태로 변환하고, WAND/BMW와 같은 가지치기 기법을 함께 활용할 수 있다고 설명한다. 이는 단순히 검색 성능 향상을 위한 것만이 아니라, ‘서로 다른 검색 신호를 어떻게 결합할 것인가’에 대한 고민을 담고 있다.

(참고 : https://github.com/cognica-io/bayesian-bm25)

또 다른 방향으로는 SPLADE와 같은 Sparse Neural Retrieval이 있다. 21년에 소개된 SPLADE는 Transformer를 이용해 질의와 문서를 sparse lexical representation으로 변환하고, 이를 inverted index를 통해 검색하는 방식이다. 전통적인 Lexical Search의 정확한 term matching과 inverted index의 효율성을 유지하면서도, Transformer가 생성한 표현을 활용해 관련된 단어를 확장(Lexical Expansion)할 수 있다는 점이 특징이다.

즉 Lexical Search와 Dense Retrieval 사이의 장점을 결합할 수 있는 방식으로 볼 수 있어, 최근에는 SPLADE를 conversational search나 RAG의 hybrid retrieval에 적용하거나, query decomposition과 결합하는 연구가 이어지고 있다.

결국 검색 모델의 경쟁 구도는 ‘어떤 검색 모델이 가장 좋은가’에서 ‘현재 상황에서 어떤 절차로 어떤 검색 방식들을 사용하는 것이 가장 효율적인가’라는 문제로 확장되고 있다.

3. 검색 비용과 지연 시간을 줄이는 효율화

Agentic Search에서는 하나의 질의를 해결하기 위해 검색이 반복될 수 있다. 따라서 개별 검색의 지연 시간과 연산 비용을 줄이는 것은 전체 탐색 과정의 효율성을 높이는 데 직접적으로 연결된다.

첫번째는 양자화다. 

임베딩을 낮은 정밀도(precision)으로 표현하는 방식은 잘 알려져 있다. embedding을 int8이나 binary 형태로 양자화하면 저장 공간과 메모리 사용량을 크게 줄일 수 있고, 하드웨어에 따라 검색 속도 역시 높일 수 있다. 다만 정밀도를 낮추는 만큼 검색 품질이 저하될 수 있다.

그래서 양자화한 벡터로 먼저 많은 후보를 찾고, 최종 후보만 높은 정밀도로 다시 평가하는 방식이 활용될 수 있다.

예를 들어, binary retrieval 후 원본 또는 더 높은 정밀도의 표현으로 rescoring하면 검색 비용을 크게 줄이면서 검색 품질을 상당 부분 회복할 수 있다. Hugging Face의 실험에서는 binary embedding이 rescoring을 적용했을 때, MTEB Retrieval 성능이 mxbai-embed-large-v1 모델 기준으로 fp32대비 92.53% 수준에서 96.45% 수준으로 회복되었다.

(출처 : https://huggingface.co/blog/embedding-quantization)

Qdrant 역시 양자화 전략의 보완책으로 oversampling + rescoring을 지원한다. 먼저 최종 Top-K보다 많은 후보를 양자화 벡터로 찾은 뒤, 그 후보만 원본 벡터로 다시 계산하는 방식이다.

(출처 : https://qdrant.tech/course/essentials/day-4/rescoring-oversampling-indexing/)

양자화처럼 벡터의 표현을 줄이는 것과 별개로, 쿼리 임베딩을 생성하는 모델 자체를 작게 만드는 방법도 있다. ‘LEAF’는 큰 teacher embedding과 정렬된 작은 embedding 모델을 학습해, 문서는 큰 모델로 미리 인코딩하고 질의는 작은 모델로 처리하는 비대칭 구조를 제안했다. 공개된 leaf-ir 모델은 23M 파라미터러, 실시간 query encoding 비용 자체를 줄이는 접근이다.

(출처 : https://huggingface.co/MongoDB/mdbr-leaf-ir)

이러한 흐름은 검색 모델의 평가 방식에도 영향을 주고 있다. MTEB는 v2.11에서 Matryoshka embedding의 차원 축소 평가를, v2.12에서는 int8로 압축된 embedding의 성능 평가를 지원하기 시작했다. 이제 embedding의 원래 성능뿐 아니라, 차원이나 정밀도를 줄였을 때 얼마나 성능을 유지하는지도 하나의 평가 대상이 된 것이다.

(출처 : https://docs.mteb.org/whats_new/#support-for-embedding-compression)

두번째로는 데이터를 효율적으로 ‘읽도록 구조화’하는 움직임이다.

Qdrant에서는 1.16 버전부터 inline storage를 적용했다. 디스크 기반 HNSW에서는 그래프를 따라 노드를 탐색할 때 여러 random read가 발생할 수 있는데, Qdrant는 벡터값을 HNSW node 내부에 함께 저장해 인접 노드의 ID와 벡터를 연속적인 page read로 가져올 수 있도록 했다. 또한 원본 벡터를 같은 node에 넣어 검색 중 rescoring까지 수행할 수 있다. 쉽게 말해, HNSW의 탐색 과정에서 필요한 벡터를 graph node에 함께 배치해 disk random read를 줄인 것이다. 저장 공간은 오히려 증가하지만, disk random read를 줄여 검색 성능을 높이는 trade-off이다.

Qdrant가 공개한 자료에 따르면, 이를 통해 100만 개 벡터 검색에 대해 저메모리 환경에서 inline storage를 적용했을 때 211 QPS, 적용하지 않았을 때 20 QPS를 기록했다고 한다.

(출처 : https://qdrant.tech/blog/qdrant-1.16.x/)

또한, 효율적으로 읽도록 구조화하는 움직임은 단순히 벡터 DB라는 하나의 ‘개별 인덱스’의 최적화를 넘어 데이터 저장 구조 자체를 다시 설계하는 방향으로 이어지고 있다.

turbopuffer는 초기에 ANN vector index를 primary index로 두고, 다른 검색 기능들이 이 구조를 중심으로 동작하도록 설계했다. 하지만 이후 aggregation, regex, fuzzy matching, sparse vector search 등 다양한 query plan을 추가하면서 ANN 중심 구조 자체가 다른 검색 방식의 제약이 되기 시작했다. 그래서 turbopuffer v3에서는 ANN을 primary index에서 내려 하나의 secondary index로 취급하는 방향으로 구조를 개편 중에 있다.

(출처 : https://turbopuffer.com/blog/rip-vector-database)

핵심은 각 검색 방식이 서로 다른 인덱싱을 가질 수 있다는 점이다.

즉, 저장 구조를 특정 검색 인덱스에 종속시키기는 대신, 하나의 데이터를 여러 검색 기술이 자신의 연산 특성에 맞는 인덱스와 저장구조를 갖도록 만드려는 의의가 보인다. turbopuffer의 이러한 변화는 단순한 ‘Vector DB 아키텍처 개선’이라기보다, Vector Search를 포함한 여러 검색 primitive를 하나의 검색 시스템에서 조합하는 방향을 보여주는 사례라고 볼 수 있다.

turbopuffer 스스로도 현재를 “generalized database for search”로 설명하고 있으며, v3 역시 이러한 다양한 query plan을 더 효율적으로 지원하기 위한 기반으로 설명한다. 따라서 앞으로의 검색 시스템은 단순히 “어떤 Vector DB를 사용할 것인가”보다는, “어떤 검색 primitive들을 어떤 구조로 조합할 것인가”라는 문제에 가까워지고 지고 있다.

물론 이런 방향이 완전히 새로운 것은 아니다. Elasticsearch와 같은 전통적인 Search Engine은 이미 full-text search, vector search, filtering, aggregation 등을 하나의 검색 엔진에서 지원하고 있다.

이 밖에도 검색 모델의 실행 과정 자체를 최적화하는 노력 등이 존재한다.

예를 들어 SPLADE와 같은 learned sparse retrieval에서는 vocabulary 차원까지 확장된 큰 차원의 중간 tensor가 생성될 수 있다. Sparton은 이러한 메모리 병목을 해결하기 위해 SPLADE의 연산 순서를 재구성했다. ReLU와 log1p가 단조 증가 함수라는 성질을 이용해, 기존에는 마지막에 수행하던 max 연산을 앞당겨 logit을 계산한 이후 vocabulary별 최대값을 구하는 방식으로 바꾼 것이다. 이를 통해 추론 시의 메모리 점유율이 극적으로 줄였다. 즉, 모델 자체를 바꾸지 않고도 GPU에서 연산이 이루어지는 방식을 최적화하는 것이다.

(출처 : https://github.com/thongnt99/sparton)

결국 검색 효율화는 단순히 더 작은 검색 모델을 사용하는 것에서 끝나지 않는다.

벡터를 더 작게 표현하고,

필요한 데이터만 효율적으로 읽고,

각 검색 방식에 맞는 저장 구조를 사용하고,

동일한 모델도 더 효율적으로 실행하는 것.

검색은 더 이상 한 번의 호출로 정답을 반환하는 독립적인 기능이 아니다. Agent가 탐색하고, 판단하고, 행동하는 과정에서 검색은 다음 행동을 결정하기 위한 핵심 primitive가 되고 있다.

따라서 앞으로 검색 시스템에서 중요한 질문은 “어떤 검색 모델이 가장 좋은가?”가 아니라 “현재 상황에서 무엇을, 어떤 도구로, 얼마나 빠르게 검색해야 하는가?”가 될 것이다.

검색은 정답을 찾는 시스템에서, 탐색하고 다음 행동을 결정하는 시스템으로 변화하고 있다.