VectorDB 아저씨, Tavily의 신선도에 패배하다

안녕하세요, VectorDB 아저씨입니다.

문서를 수집한다.

chunk로 나눈다.

embedding을 계산한다.

인덱스(Index)에 쌓는다.

유사도(Similarity)로 검색한다.

모든 검색 기반을 내 손안에 가지고 있다.

크으~, 정말 참을 수 없군.

……라고 생각하던 시기가 있었습니다.

정신을 차려보니, RAG를 만들고 있어야 하는데 인덱스 뒷바라지를 하고 있었습니다.

우와, 최신 정보가 필요할 뿐인데 재-embedding(re-embedding) 상담이 시작되었다.

예전의 감각으로는 검색 기반을 직접 소유할 수 있다는 것이 강점이었습니다.

외부 API에 의존하지 않는다.

쿼리(Query)당 과금을 신경 쓰지 않는다.

어떤 문서를 넣을지 스스로 결정할 수 있다.

유사도 계산을 직접 제어할 수 있다.

오프라인에서도 검색할 수 있다.

그것이 제대로 된 구성이라고 생각했습니다.

물론, 지금도 이것이 틀린 것은 아닙니다.

사내 문서와 같이 외부로 내보낼 수 없는 자체 코퍼스(Corpus).

같은 자료를 반복해서 검색하는 안정적인 지식 베이스(Knowledge Base).

쿼리마다 외부로 던지고 싶지 않은 용도.

특정 코퍼스에 고정하고 싶은 기반.

그런 곳에서는 지금도 VectorDB가 강력합니다.

다만, 트렌드처럼 신선도가 생명인 대상에 똑같은 무게감을 가져가면 이야기가 조금 달라집니다.

실제로, trend-to-rule에서도 처음에는 수집한 기사를 VectorDB에 쌓아서 검색하는 구성을 생각하고 있었습니다.

패션 트렌드 기사를 수집한다.

embedding하여 인덱스에 넣는다.

그 후에는 유사도로 검색하면 된다.

가벼운 검색이니 자체적으로 보유해도 충분할 것이라 생각했다.

코퍼스를 키우면 검색 성능도 좋아질 것이라고도 생각했다.

하지만 진행하다 보니, 보고 있는 지점이 어긋나 있다는 것을 깨달았습니다.

인덱스를 키운다.

재-embedding을 돌린다.

chunk 사이즈를 확인한다.

유사도 임계값(Threshold)을 확인한다.

업데이트 배치(Batch)를 확인한다.

봐야 할 것이 늘어난다.

하지만 정말로 원했던 것은 잘 정돈된 인덱스가 아니었습니다.

「요즘 느낌」을 판정하기 위한, 지금의 기사였습니다.

우와, 트렌드를 보고 싶은데 보고 있는 건 지난주에 쌓아둔 오래된 인덱스였다.

VectorDB에 코퍼스를 쌓으면 검색 자체는 안정됩니다.

하지만 트렌드에서 가장 원했던 「신선도」는 생각만큼 따라오지 않았습니다.

인덱스는 쌓는 순간부터 오래됩니다.

지난주에 embedding한 기사는 지난주의 트렌드입니다.

이번 주에 무엇이 뜨고 있는지는 들어있지 않습니다.

신선도를 유지하려고 하면 결국 이렇게 됩니다.

기사를 다시 수집한다.

재-embedding한다.

인덱스를 업데이트한다.

오래된 것을 지울지 말지 고민한다.

업데이트 빈도를 결정한다.

그리고 트렌드를 보고 싶었을 뿐인데, 인덱스 업데이트 운영을 하고 있다.

곤란했던 것은 검색 정밀도가 아니었습니다.

품고 있는 인덱스가 시간이 흐름에 따라 부패해가는 것이었습니다.

필요했던 것은 더 똑똑한 VectorDB가 아니라, 원할 때 지금의 정보를 가져올 수 있는 상태였습니다.

그래서 Tavily로 기울였습니다.

지금은 트렌드 기사 취득을 Tavily 검색에 맡기고 있습니다.

쿼리를 던져서 지금의 검색 결과를 받는다.

인덱스는 보유하지 않는다.

예전의 나라면 아마 이렇게 생각했을 것입니다.

아니, 그건 자신의 코퍼스로 보유해야지.

쿼리 과금이 무섭지 않아?

매번 외부로 던진다고?

자체적으로 재현할 수 없으면 불안하지 않아?

하지만 직접 사용해 보며 알게 된 것이 있습니다.

신선도가 운영의 문제가 아니라, 쿼리 타이밍의 문제가 되었다는 것입니다.

인덱스를 계속 업데이트하며 신선도를 유지하는 것이 아니라, 원하는 순간에 가져온다.

지난주 인덱스와 상담할 필요가 없다.

재-embedding을 돌릴 필요가 없다.

오래된 것을 지울지 판단할 필요가 없다.

업데이트 배치의 빈도로 고민할 필요가 없다.

그만큼 추출한 결과를 어떻게 규칙(Rule)으로 바꿀 것인가라는 본질로 돌아올 수 있었습니다.

Tavily를 선택한 것은 VectorDB를 부정하고 싶어서가 아닙니다.

자체 코퍼스를 보유하는 지식은 지금도 필요합니다.

오히려 무엇을 매번 외부 취득으로 넘기고 있는지를 파악하지 못하면, 외부 검색은 그저 블랙박스가 됩니다.

그래서 이해는 필요합니다.

하지만 이해하고 있는 것과, 매번 인덱스의 신선도와 상담하는 것은 별개의 문제였습니다.

여기에는 명확한 구분점이 있습니다.

안정적인 코퍼스(변하지 않는 자료를 반복해서 검색)는 VectorDB로 보유하는 것이 강력하다.

신선도가 생명인 대상(트렌드처럼 지금의 정보가 필요한 경우)은 보유하면 부패한다. 그때그때 가져오는 편이 좋다.

trend-to-rule은 후자였습니다. 트렌드는 보유하는 순간 오래됩니다.

필요했던 것은 최강의 자체 검색 기반이 아니었습니다.

대상(target)의 신선도에 맞춰, 보유할지 가져올지를 선택할 수 있는 상태였습니다.

인덱스(index)를 버린 것이 아니라, 신선도를 관리하는 시간을 버린 것입니다.

정확히는, 신선도를 관리하는 시간을 규칙 추출을 보는 시간으로 옮긴 것입니다.

임베딩 (embedding).

청크 (chunk) 분할.

유사도 (similarity).

재임베딩 (re-embedding).

인덱스 (index) 업데이트.

신선도와의 상담.

대결해 주셔서 감사합니다.

VectorDB 아저씨, Tavily에게 신선도로 패배했습니다.

하지만 아마 이것은 나쁜 패배는 아닐 것입니다.

RAG를 만들고 있었을 텐데, 인덱스의 신선도를 관리하고 있었습니다.

그로부터 드디어 신선도를 "가져오는 타이밍"으로서 다룰 수 있는 상태로 옮겨갔을 뿐입니다.

그리고 보유할지 가져올지를 대상마다 선택할 수 있게 되면, 재미있는 사실을 깨닫게 됩니다.

VectorDB가 필요한 상황과 필요하지 않은 상황이 명확하게 나뉩니다.

그것은 VectorDB가 약해서가 아니라, 대상의 신선도라는 축으로 보유/가져오기를 나누지 않았을 뿐일지도 모릅니다.

RAG 설계에 관한 이야기로서 제대로 쓴 것이 이 책입니다.

VectorDB를 추가하기 전에, 애초에 무엇을 검색해야 했는지, 검색 (retrieval)을 증거 (evidence)로서 다루는 관점에서 쓰고 있습니다.

『검색 결과를 늘리기 전에 봐야 할 RAG 설계』

인덱스를 키우기 전에, 봐야 할 곳이 있었다는 이야기입니다.