sy/dev
Concept
19 min read

AI Search는 Vector DB만으로 끝나지 않는다

AI Search Technology Meetup in Seoul에서 소개된 논문들을 바탕으로, 현대 AI Search stack을 index, retrieval, reranking, data, agentic search, evaluation 관점에서 정리하는 시리즈를 시작한다.

AI Search라고 하면 요즘은 거의 자동으로 vector DB나 embedding search를 떠올린다. 질문을 embedding으로 만들고, 문서 embedding과 가까운 것을 찾고, 그 결과를 LLM에 넣으면 된다는 그림이다.

이 그림은 틀린 것은 아니지만, 검색 시스템 전체를 설명하기에는 너무 얇다. 실제 검색 시스템을 만들다 보면 vector search는 stack의 한 층일 뿐이다. 그 아래에는 filtering index가 있고, 옆에는 sparse retrieval이 있으며, 위에는 reranker와 context selection이 있다. 다국어 검색에서는 언어 식별과 데이터 큐레이션이 중요하고, agentic search로 가면 검색은 단순히 문서를 찾는 일을 넘어 환경을 탐색하고 수정하고 검증하는 루프가 된다.

이 글은 AI Search Technology Meetup in Seoul에서 소개된 논문들을 바탕으로, 앞으로 정리할 개인 블로그 시리즈의 출발점이다. 논문 하나하나를 따로 읽되, 단순 요약보다는 “이 논문이 AI Search stack의 어느 층을 설명하는가”에 초점을 맞춰보려고 한다.

왜 AI Search를 stack으로 봐야 하나

LLM 이전의 검색은 주로 inverted index, BM25, faceted search, ranking model의 조합으로 설명됐다. LLM 이후에는 embedding 기반 semantic search와 RAG가 빠르게 기본값이 됐다.

하지만 RAG를 실제 제품이나 내부 시스템에 붙여보면 금방 알게 된다. 검색 품질은 embedding 모델 하나로 결정되지 않는다.

예를 들어 이런 질문들이 계속 나온다.

  • 검색 대상 문서 중 사용자가 볼 수 없는 문서는 어떻게 제외할 것인가?
  • 문서가 너무 많을 때 candidate를 어떻게 빠르게 줄일 것인가?
  • 하나의 벡터로 문서 전체를 표현해도 충분한가?
  • 정답 근거가 문서 중간이나 끝에 있으면 retriever가 잘 찾는가?
  • 긴 context에 다 넣으면 정말 좋아지는가?
  • reranking에 항상 같은 계산량을 써야 하는가?
  • 다국어 문서의 언어와 품질은 어떻게 관리할 것인가?
  • 검색 결과를 LLM이나 judge가 어떻게 검증할 것인가?
  • Agent가 검색하고, 수정하고, 테스트하는 경우에는 무엇을 평가해야 하는가?

이 질문들은 모두 검색 문제다. 다만 전통적인 query -> documents 형태보다 훨씬 넓어진 검색 문제다.

그래서 이 시리즈에서는 AI Search를 하나의 stack으로 본다.

Data / Corpus
  -> Language ID, deduplication, filtering, quality control
 
Index / Filter
  -> bitmap index, metadata filter, permission filter
 
Retrieval
  -> sparse retrieval, dense retrieval, multi-vector retrieval, late interaction
 
Reranking / Context Selection
  -> listwise reranking, adaptive computation, distraction-aware retrieval
 
Generation / Agentic Loop
  -> tool use, repository navigation, test execution, self-improvement
 
Evaluation / Oversight
  -> judge, critic, debate, verification

이렇게 보면 AI Search는 vector DB 하나로 끝나는 문제가 아니라, 여러 계층이 맞물린 시스템 문제가 된다.

1. Index: vector search 이전에도 필터링은 중요하다

첫 번째로 볼 논문은 Roaring Bitmap이다.

Roaring Bitmap은 AI 논문은 아니다. compressed bitmap index에 관한 논문이다. 그런데 AI Search stack에서는 매우 아래쪽의 중요한 부품이다.

Vector search가 아무리 좋아도, 모든 문서를 semantic similarity로만 처리하면 안 된다. 실제 검색에서는 먼저 deterministic하게 걸러야 하는 조건이 많다.

  • 권한
  • tenant
  • 날짜
  • 언어
  • 문서 타입
  • 제품군
  • 공개 여부
  • deprecated 여부

이런 조건은 LLM에게 맡길 일이 아니다. 검색 전에 index layer에서 빠르고 정확하게 처리해야 한다. Roaring Bitmap은 이런 filtering과 set operation을 빠르게 처리하는 인프라 기술로 볼 수 있다.

시리즈 첫 번째 논문으로 Roaring Bitmap을 넣는 이유도 여기에 있다. AI Search는 embedding에서 시작하는 것처럼 보이지만, 실제 시스템은 훨씬 낮은 층의 index와 filter에서 이미 품질이 갈린다.

2. Retrieval: 문서를 하나의 벡터로 뭉개도 될까

다음 묶음은 neural retrieval이다.

요즘 많은 RAG 시스템은 문서 chunk 하나를 하나의 dense vector로 만든다. 간단하고 빠르지만, 이 방식에는 분명한 손실이 있다. 문서 안의 token-level detail이 하나의 벡터에 압축되기 때문이다.

ColBERT는 이 문제에 대한 중요한 대안이다. query와 document를 독립적으로 인코딩하되, 마지막 scoring 단계에서 token-level late interaction을 수행한다. 문서를 하나의 벡터로 뭉개지 않고, 질의 token과 문서 token 사이의 세밀한 matching을 유지한다.

PLAID는 ColBERT 계열 late interaction retrieval을 더 빠르게 만드는 엔진이다. 좋은 검색 방법이 있어도 production latency 안에 들어오지 않으면 쓰기 어렵다. PLAID는 centroid interaction과 pruning을 통해 late interaction을 대규모 검색에서 더 현실적인 선택지로 만든다.

SPLATE는 sparse retrieval과 late interaction을 연결한다. ColBERTv2의 표현을 sparse vocabulary space로 매핑해 candidate generation을 sparse retrieval 방식으로 처리한다. 이 흐름은 “neural retrieval = vector DB”라는 단순한 등식을 깨준다.

그리고 LIMIT 논문은 single-vector embedding retrieval의 이론적 한계를 정면으로 다룬다. 더 큰 embedding model과 더 많은 학습 데이터가 항상 답은 아닐 수 있다. 어떤 실패는 모델이 약해서가 아니라, 하나의 벡터로 검색 대상을 표현하는 구조 자체에서 올 수 있다.

이 네 편은 함께 읽으면 좋다. 질문은 하나다.

AI Search에서 하나의 vector representation은 어디까지 충분한가?

다음은 Gemini Embedding 2다.

검색 대상은 더 이상 텍스트 문서만이 아니다. 회의 녹음, 이미지, 슬라이드, 제품 화면, 데모 영상, 코드, 로그가 모두 검색 대상이 된다.

Gemini Embedding 2는 video, audio, image, text를 unified representation space로 다루는 native multimodal embedding model을 제안한다. 이런 흐름은 AI Search가 text retrieval에서 multimodal retrieval로 확장되고 있음을 보여준다.

흥미로운 지점은 “검색 결과를 어떻게 보여줄 것인가”보다 “근거를 어떻게 인용하고 검증할 것인가”다. 텍스트 문서는 문장 단위 citation이 가능하지만, 영상이나 오디오는 timestamp가 필요하고, 이미지는 영역이나 caption이 필요하다. Multimodal search는 retrieval 문제이면서 동시에 evidence representation 문제다.

4. Retrieval evaluation: 어디에 있는 근거를 잘 찾는가

이미 별도 글로 정리한 Position Bias in Dense Retrievers도 이 시리즈에 포함된다.

이 논문은 dense retriever가 문서 앞부분의 근거를 더 잘 찾는 위치 편향을 다룬다. 중요한 것은 이 편향이 모델 구조만의 문제가 아니라, fine-tuning 데이터에서 정답 근거가 어디에 있었는지에 크게 좌우된다는 점이다.

검색 모델을 평가할 때 단순히 recall이나 NDCG만 보는 것은 부족하다. 정답 근거가 문서 앞, 중간, 뒤 어디에 있을 때 잘 찾는지도 봐야 한다.

실제 문서는 중요한 정보가 항상 앞에 있지 않다. 계약서의 예외 조항, release note의 breaking change, issue thread의 핵심 코멘트는 중간이나 끝에 있을 수 있다. 따라서 AI Search 평가셋도 evidence position을 균형 있게 설계해야 한다.

5. Reranking: 모든 query에 같은 계산량을 쓸 필요는 없다

다음은 AcuRank다.

Reranking은 AI Search에서 점점 중요해지고 있다. first-stage retrieval이 후보를 가져오고, reranker가 최종 순서를 정한다. 특히 LLM 기반 listwise reranking은 강력하지만 비싸다.

AcuRank의 핵심은 모든 query와 모든 후보에 같은 계산량을 쓰지 않는 것이다. 쉬운 query는 빠르게 끝내고, ranking이 불확실한 경우에만 추가 계산을 쓴다. 논문은 Bayesian TrueSkill 기반으로 relevance uncertainty를 추정하고, accuracy와 efficiency 사이의 trade-off를 개선하려 한다.

이 아이디어는 실무적으로도 자연스럽다. 검색 시스템은 모든 요청을 같은 깊이로 검토할 필요가 없다. 애매한 query, 후보 간 점수가 비슷한 query, high-risk query에 더 많은 compute를 쓰는 편이 합리적이다.

6. Long Context vs RAG: 많이 넣는 것이 답은 아니다

다음은 LDAR다.

긴 context window가 등장하면서 “그냥 다 넣으면 retrieval이 필요 없는 것 아닌가”라는 이야기가 자주 나온다. LDAR는 이 관점에 반론을 제기한다.

Long-context 접근은 token 비효율, lost in the middle, distracting passages 문제를 가진다. 문서를 많이 넣는다고 항상 답변이 좋아지는 것은 아니다. 오히려 방해 문서가 늘어나면 모델 출력이 나빠질 수 있다.

이 논문이 던지는 질문은 중요하다.

검색의 목표는 많은 문서를 넣는 것인가, 아니면 필요한 근거를 넣고 방해 정보를 줄이는 것인가?

AI Search에서 context selection은 단순한 후처리가 아니라 핵심 ranking 문제다.

7. Data와 Language: 검색 품질은 corpus에서 시작된다

검색 모델을 논하기 전에, 검색 대상 corpus가 좋은지도 봐야 한다. 여기서는 세 편을 다룰 예정이다.

GlotLID는 low-resource language identification을 다룬다. 다국어 검색에서 language identification은 단순 전처리가 아니다. 잘못된 언어 식별은 tokenizer, embedding model routing, filtering, evaluation 전체를 흔든다.

FineWeb2는 multilingual web-scale data curation pipeline이다. filtering, deduplication, rebalancing은 pretraining corpus뿐 아니라 RAG corpus에도 그대로 중요한 문제다. 검색 모델이 아무리 좋아도 corpus가 중복, 오염, 불균형 상태라면 검색 품질은 한계가 있다.

GLiNER는 generalist NER 모델이다. 검색 시스템에서 entity extraction은 query understanding과 document enrichment를 연결하는 구조화 계층이다. 사람, 조직, 제품, 날짜, 법령, 함수명 같은 entity를 잘 뽑아낼수록 검색과 ranking에 더 많은 구조적 signal을 줄 수 있다.

이 세 편은 AI Search의 data layer를 설명한다. 좋은 검색은 좋은 corpus와 좋은 annotation에서 시작된다.

8. Agentic Search: 검색은 행동으로 확장된다

마지막 묶음은 agentic search와 evaluation이다.

SWE-agent는 Agent-Computer Interface, 즉 ACI의 중요성을 보여준다. Software engineering agent는 단순히 문서를 검색하지 않는다. repository를 탐색하고, 파일을 수정하고, 테스트를 실행하고, 실패 로그를 읽는다. 이때 검색은 action loop의 일부가 된다.

Darwin Gödel Machine은 self-improving agent를 다룬다. 여기서는 검색의 대상이 문서가 아니라 더 나은 agent design과 code change가 된다. generated agent archive를 유지하고, benchmark로 변경을 검증하며, open-ended하게 개선을 시도한다.

Debate Helps Weak Judges는 evaluation과 oversight 문제로 이어진다. 검색 시스템이 답변을 생성하고 agent가 행동까지 하게 되면, 결과를 누가 어떻게 평가할 것인가가 중요해진다. 약한 judge 하나에 모든 평가를 맡기기보다, critic이 검증 가능한 claim을 만들고 judge가 이를 확인하는 구조가 필요해진다.

이 묶음은 AI Search가 단순 retrieval system에서 agentic system으로 확장되는 지점을 보여준다.

앞으로의 글 순서

이 시리즈는 대략 다음 순서로 정리할 예정이다.

  1. Roaring Bitmap — 빠른 filtering index
  2. ColBERT — late interaction retrieval
  3. PLAID — efficient ColBERT engine
  4. SPLATE — sparse late interaction retrieval
  5. LIMIT — embedding retrieval의 이론적 한계
  6. Gemini Embedding 2 — multimodal embedding
  7. Position Bias — dense retriever의 위치 편향
  8. AcuRank — adaptive reranking
  9. LDAR — distraction-aware retrieval
  10. GlotLID — language identification
  11. FineWeb2 — multilingual data curation
  12. GLiNER — generalist NER
  13. SWE-agent — agent-computer interface
  14. Darwin Gödel Machine — self-improving agents
  15. Debate Helps Weak Judges — judge와 critic 기반 평가

순서는 논문 발표 연도순이 아니라, AI Search stack을 이해하기 좋은 흐름으로 잡았다. index에서 시작해 retrieval, reranking, data, agent, evaluation으로 올라가는 구조다.

정리

이번 시리즈의 출발점은 단순하다.

AI Search는 vector DB 하나로 끝나지 않는다.

Embedding search는 중요한 층이지만, 전체 검색 시스템은 그보다 넓다. 빠른 filter, sparse/dense/multi-vector retrieval, reranking, context selection, data curation, language identification, entity extraction, agent interface, evaluation까지 함께 봐야 한다.

앞으로 각 글에서는 논문 하나를 잡고, 그 논문이 AI Search stack의 어느 문제를 해결하려는지 정리해볼 생각이다. 논문 요약 그 자체보다, 실제 시스템을 만든다면 어디에 꽂히는 기술인지에 초점을 맞추겠다.

참고 논문

Comments