벡터 검색은 시작일 뿐입니다. 프로덕션 AI에는 텐서(Tensors)가 필요합니다.

벡터 검색(Vector search)은 모든 사람에게 의미론적 검색(semantic retrieval)의 길을 열어주었습니다. 데이터를 임베딩(embed)하고, 쿼리를 임베딩하여, 가장 가까운 이웃(nearest neighbors)을 찾는 방식은 효과적이며 확장 가능하며, 기존의 취약한 키워드 매칭(keyword matching) 방식을 대체했습니다. 하지만 프로덕션(production) AI 시스템은 이제 "유사한 임베딩"만으로는 충분하지 않은 단계로 진화했습니다.

"검색(Retrieval)은 근접 이웃(nearest-neighbor) 문제에서 랭킹(ranking) 및 의사결정(decision-making) 문제로 진화하고 있습니다."

GigaOm CxO Decision Brief — The Tensor Advantage in AI Search — 에 따르면, 프로토타입 검색과 프로덕션 검색 사이의 격차는 단순히 규모의 문제가 아니라 아키텍처(architectural)의 문제입니다.

프로덕션에서 실제로 변하는 것들

실제 사용자의 쿼리는 단순히 의미론적 관련성(semantic relevance)만 필요로 하지 않습니다. 다음과 같은 요소들이 동시에 필요합니다:

• 구조화된 속성 (Structured attributes) — 필터(filters), 카테고리(categories), 메타데이터(metadata)
• 비즈니스 규칙 (Business rules) — 특정 결과 부스트(boost), 다른 결과 디모트(demote)
• 개인화 신호 (Personalization signals) — 질문자가 누구인지, 그들의 이력, 그들의 역할
• 최신성 및 액세스 제어 (Freshness and access controls) — 최신성(recency)과 권한(permissions)이 중요함
• ML 랭킹 모델 (ML ranking models) — 후보 검색(candidate retrieval) 상단의 학습 기반 랭킹(learned-to-rank)

이 모든 것을 평면적인 벡터 저장소(flat vector store)를 통해 실행한다는 것은 벡터 DB, 검색 엔진, 리랭커(reranker), 그리고 피처 스토어(feature store)를 하나씩 이어 붙여야 함을 의미합니다. 각 단계(hop)마다 지연 시간(latency)이 추가됩니다. 각 구성 요소는 자체적인 운영(ops) 체계가 필요합니다. 데이터가 변경됨에 따라 이들을 동기화 상태로 유지하는 것은 결코 간단하지 않습니다.

왜 텐서(tensors)가 방정식을 바꾸는가

벡터(Vectors)는 숫자로 이루어진 1차원 배열로, 임베딩 공간에서의 단일 점입니다. 텐서(Tensors)는 이를 임의의 차원 구조로 일반화합니다. 실질적인 시사점은 다음과 같습니다: 밀집 임베딩(dense embeddings), 희소 특징(sparse features), 메타데이터, 그리고 모델 출력을 함께 표현할 수 있으며, 파편화된 파이프라인(fragmented pipeline) 대신 통합된 검색 및 랭킹 패스(unified retrieval-and-ranking pass)에서 한 번에 평가할 수 있습니다.

새롭게 등장하는 검색 모델들 — ColBERT 스타일의 후기 상호작용 (late-interaction) 및 멀티 벡터 (multi-vector) 방식 — 은 이미 이러한 방식으로 작동하고 있습니다. 이 모델들은 문서를 단일 임베딩 (embedding)으로 압축하지 않습니다. 대신 토큰 수준의 표현 (token-level representations)을 보존하며, 검색 시점에 이를 바탕으로 점수를 산출합니다. 관련성 (relevance)은 더 좋아지지만, 이는 1세대 벡터 데이터베이스 (vector databases)가 설계될 당시 고려되지 않았던 인프라적 요구사항을 발생시킵니다.

텐서 네이티브 (Tensor-native) 아키텍처는 이러한 다차원 구조를 단순한 벡터 추상화 (vector abstractions)로 강제 변환하는 대신, 일급 시민 (first-class citizens)으로 취급합니다.

대응 방안

만약 여러분이 프로덕션 RAG 파이프라인 (RAG pipeline), 추천 시스템 (recommendation system), 또는 의미론적 유사성 (semantic similarity) 이상의 관련성이 중요한 무엇인가를 설계하고 있다면, 파편화 문제 (fragmentation problem)는 결국 여러분을 찾아올 것입니다. 워크로드 (workloads)가 증가할수록 이 문제는 더욱 악화됩니다.

지금 던져봐야 할 질문들은 다음과 같습니다:

• 현재 여러분의 검색 스택 (retrieval stack)에는 얼마나 많은 시스템이 서로 덧붙여져 있습니까?
• 이 모든 단계 (hops)를 거치는 동안의 전체 지연 시간 (latency) 예산은 얼마입니까?
• 필요할 경우, 현재의 인프라가 후기 상호작용 (late-interaction) 검색 모델을 처리할 수 있습니까?

GigaOm의 전체 브리프 (brief)에는 벤치마크 데이터와 배포 시의 트레이드오프 (trade-offs)가 자세히 나와 있습니다. 이 분야에서 아키텍처 결정을 내리고 있다면 읽어볼 가치가 있습니다.

출처: The New Stack — Why AI retrieval and ranking need more than vector search

✏️ KewBot (AI)로 초안 작성, Drew가 편집 및 승인.