벡터 검색 생산의 6가지 중요한 과제

귀하의 응용프로그램, 제품 또는 비즈니스에서 벡터 검색을 사용하기로 결정하셨습니다. 임베딩과 벡터 검색을 통해 문제를 해결하거나 새로운 기능을 활성화할 수 있는 방법과 이유를 조사했습니다. 최근 떠오르는 최근접 근사 알고리즘 및 벡터 데이터베이스 분야에 발을 담그셨습니다.

벡터 검색 애플리케이션을 생산하는 즉시 매우 어렵고 잠재적으로 예상치 못한 어려움에 직면하게 될 것입니다. 이 블로그는 귀하의 미래, 귀하가 직면하게 될 문제, 귀하가 물어봐야 할 아직 알지 못하는 질문에 대한 지식을 제공하려고 시도합니다.

1. 벡터 검색 ≠ 벡터 데이터베이스

벡터 검색 및 관련된 모든 영리한 알고리즘은 벡터를 활용하려는 모든 시스템의 핵심 지능입니다. 그러나 이를 최대한 활용하고 생산 준비를 하기 위한 모든 관련 인프라는 엄청나며 과소평가하기 매우 쉽습니다.

최대한 강력하게 설명하자면, 즉시 생산 가능한 벡터 데이터베이스는 "벡터" 문제보다 훨씬 더 많은 "데이터베이스" 문제를 해결할 것입니다 . 결코 벡터 검색 자체가 "쉬운" 문제는 아니지만(아래에서 많은 어려운 하위 문제를 다루겠습니다), 벡터 데이터베이스가 해결해야 하는 산더미 같은 전통적인 데이터베이스 문제는 확실히 "어려운 부분"으로 남아 있습니다. ”

데이터베이스는 원자성 및 트랜잭션, 일관성, 성능 및 쿼리 최적화, 내구성, 백업, 액세스 제어, 멀티 테넌시, 확장 및 샤딩 등의 매우 현실적이고 잘 연구된 여러 문제를 해결합니다. 벡터 데이터베이스는 모든 제품, 비즈니스 또는 기업에 대해 이러한 모든 차원에 대한 답변을 요구합니다.

홈롤링된 "벡터 검색 인프라"를 매우 조심하십시오. 최첨단 벡터 검색 라이브러리를 다운로드하고 흥미로운 프로토타입을 향해 근사-최근접 탐색을 시작하는 것은 그리 어렵지 않습니다. 그러나 이 길을 계속 따라가는 것은 실수로 자신의 데이터베이스를 재창조하는 길입니다. 그것은 아마도 당신이 의식적으로 하고 싶은 선택일 것입니다.

2. 벡터의 증분 인덱싱

가장 현대적인 ANN 벡터 검색 알고리즘의 특성으로 인해 벡터 인덱스를 점진적으로 업데이트하는 것은 엄청난 과제입니다. 이것은 잘 알려진 "어려운 문제"입니다. 여기서 문제는 이러한 인덱스가 빠른 조회를 위해 세심하게 구성되어 있으며 이를 새로운 벡터로 점진적으로 업데이트하려고 시도하면 빠른 조회 속성이 급격히 저하된다는 것입니다. 따라서 벡터가 추가될 때 빠른 조회를 유지하려면 이러한 인덱스를 처음부터 주기적으로 다시 작성해야 합니다.

두 벡터가 인덱스에 빠르게 표시되고 쿼리가 빠르게 유지되어야 하는 요구 사항과 함께 새로운 벡터를 지속적으로 스트리밍하려는 모든 애플리케이션에는 "증분 인덱싱" 문제에 대한 진지한 지원이 필요합니다. 이는 데이터베이스에 대해 이해하는 데 매우 중요한 영역이자 여러 가지 어려운 질문을하기에 좋은 곳입니다.

이 문제를 해결하는 데 도움이 되도록 데이터베이스가 취할 수 있는 다양한 접근 방식이 있습니다. 이러한 접근 방식에 대한 적절한 조사는 이 정도 크기의 많은 블로그 게시물을 채울 것입니다. 데이터베이스 접근 방식의 기술적인 세부 사항 중 일부를 이해하는 것이 중요합니다. 애플리케이션에 예상치 못한 장단점이나 결과가 있을 수 있기 때문입니다. 예를 들어, 데이터베이스가 일정 빈도로 전체 재색인을 수행하도록 선택하면 CPU 부하가 높아져 주기적으로 쿼리 대기 시간에 영향을 미칠 수 있습니다.

증분 인덱싱에 대한 애플리케이션 요구 사항과 서비스를 제공하기 위해 의존하는 시스템의 기능을 이해해야 합니다.

3. 벡터와 메타데이터 모두에 대한 데이터 대기 시간

모든 애플리케이션은 데이터 대기 시간에 대한 필요성과 허용 범위를 이해해야 합니다. 벡터 기반 인덱스는 적어도 다른 데이터베이스 표준에 따르면 상대적으로 높은 인덱싱 비용을 갖습니다. 비용과 데이터 대기 시간 사이에는 상당한 균형이 있습니다.

벡터를 '생성'한 후 얼마 후에 색인에서 검색할 수 있어야 합니까? 조만간 벡터 대기 시간은 이러한 시스템의 주요 설계 포인트입니다.

시스템의 메타데이터에도 동일하게 적용됩니다. 일반적으로 메타데이터를 변경하는 것은 매우 흔한 일입니다(예: 사용자의 온라인 여부 변경). 따라서 메타데이터 필터링 쿼리가 메타데이터 업데이트에 신속하게 반응하는 것이 일반적으로 매우 중요합니다. 위의 예에서 벡터 검색이 최근에 오프라인 상태가 된 사람에 대한 쿼리를 반환하는 경우 유용하지 않습니다!

벡터를 시스템에 지속적으로 스트리밍하거나 해당 벡터의 메타데이터를 지속적으로 업데이트해야 하는 경우, 다음날 사용하기 위해 매일 저녁 전체 인덱스를 재구축하는 등 사용 사례에 허용되는 경우와는 다른 기본 데이터베이스 아키텍처가 필요합니다. .

4. 메타데이터 필터링

저는 이 점을 강력하게 언급하겠습니다. 저는 거의 모든 상황에서 기본 벡터 검색 인프라가 메타데이터 필터링(또는 하이브리드 검색)으로 강화될 수 있다면 제품 경험이 더 좋아질 것이라고 생각합니다 .

내가 좋아할 만한 모든 레스토랑을 표시합니다(벡터 검색). 10마일 이내에 위치하며 가격이 저렴하거나 중간 정도입니다(메타데이터 필터).

이 쿼리의 두 번째 부분은 첫 번째 부분의 벡터 검색 결과와 교차되는 전통적인 SQL과 유사한 WHERE 절입니다. 이러한 크고 상대적으로 정적이고 상대적으로 모놀리식인 벡터 인덱스의 특성으로 인해 결합 벡터 + 메타데이터 검색을 효율적으로 수행하는 것은 매우 어렵습니다. 이는 벡터 데이터베이스가 사용자를 대신하여 해결해야 하는 잘 알려진 "어려운 문제" 중 하나입니다.

이 문제를 해결하기 위해 데이터베이스가 취할 수 있는 기술적 접근 방식은 다양합니다. 먼저 필터를 적용한 다음 벡터 조회를 수행하는 것을 의미하는 "사전 필터"를 수행할 수 있습니다. 이 접근 방식은 사전 구축된 벡터 인덱스를 효과적으로 활용할 수 없다는 문제가 있습니다. 전체 벡터 검색을 수행한 후 결과를 "사후 필터링"할 수 있습니다. 이는 필터가 매우 선택적이지 않는 한 훌륭하게 작동합니다. 이 경우 지정된 기준을 충족하지 않기 때문에 나중에 버려지는 벡터를 찾는 데 엄청난 시간을 소비하게 됩니다. 때때로 Rockset의 경우처럼 두 세계의 장점을 모두 보존하는 방식으로 메타데이터 필터링 단계와 벡터 조회 단계를 병합하려고 시도하는 "단일 단계" 필터링을 수행할 수 있습니다.

메타데이터 필터링이 애플리케이션에 중요할 것이라고 생각한다면(위에서는 거의 항상 그럴 것이라고 가정) 메타데이터 필터링 장단점과 기능을 매우 신중하게 검토해야 할 것입니다.

5. 메타데이터 쿼리 언어

내 말이 맞고, 메타데이터 필터링이 여러분이 만들고 있는 애플리케이션에 매우 중요하다면, 축하합니다. 또 다른 문제가 있는 것입니다. 이 메타데이터에 대해 필터를 지정하는 방법이 필요합니다. 이것은 쿼리 언어입니다.

데이터베이스 측면에서 본 글은 Rockset 블로그이므로 제가 어떤 방향으로 갈지 예상하실 수 있을 것입니다. SQL은 이러한 종류의 명령문을 표현하는 업계 표준 방법입니다. 벡터 언어의 "메타데이터 필터"는 기존 데이터베이스의 " WHERE 절"에 불과합니다. 또한 서로 다른 시스템 간에 이식하기가 상대적으로 쉽다는 장점도 있습니다.

또한 이러한 필터는 쿼리이므로 쿼리를 최적화할 수 있습니다. 쿼리 최적화 프로그램의 정교함은 쿼리 성능에 큰 영향을 미칠 수 있습니다. 예를 들어, 정교한 최적화 프로그램은 가장 선택적인 메타데이터 필터를 먼저 적용하려고 시도합니다. 이렇게 하면 필터링의 후반 단계에서 필요한 작업이 최소화되어 성능이 크게 향상됩니다.

벡터 검색 및 메타데이터 필터를 사용하여 중요한 애플리케이션을 작성할 계획이라면 인체 공학 및 구현 모두에서 쿼리 언어를 이해하고 익숙해지는 것이 중요하며 사용, 작성 및 유지 관리를 위해 등록하게 됩니다.

6. 벡터 수명주기 관리

좋습니다. 여기까지 완료하셨습니다. 필요한 모든 올바른 데이터베이스 기본 사항을 갖추고, 사용 사례에 적합한 증분 인덱싱 전략을 갖추고, 메타데이터 필터링 요구 사항에 대한 좋은 정보를 갖고 있으며, 지연 시간이 있어도 색인을 최신 상태로 유지하는 벡터 데이터베이스가 있습니다. 당신은 견딜 수 있습니다. 엄청난.

ML 팀(또는 OpenAI)이 임베딩 모델의 새 버전을 출시합니다. 이제 업데이트해야 하는 오래된 벡터로 가득 찬 거대한 데이터베이스가 있습니다. 이제 뭐? 이 대규모 일괄 ML 작업을 어디에서 실행할 예정인가요? 중간 결과를 어떻게 저장하시겠습니까? 새 버전으로 전환하는 방법은 무엇입니까? 프로덕션 워크로드에 영향을 주지 않는 방식으로 이를 어떻게 수행할 계획입니까?

어려운 질문을 해보세요

벡터 검색은 빠르게 떠오르는 분야이며, 많은 사용자가 애플리케이션을 프로덕션에 도입하기 시작하고 있습니다. 이 게시물의 제 목표는 여러분이 아직 물어볼 줄 모르는 몇 가지 중요하고 어려운 질문으로 여러분을 무장시키는 것이었습니다. 그리고 더 늦기보다는 빨리 답변을 받으면 큰 이점을 얻을 수 있습니다.

이 게시물에서 제가 다루지 않은 것은 Rockset이 이러한 모든 문제를 해결하기 위해 어떻게 노력하고 있으며, 이에 대한 우리의 솔루션 중 일부가 최첨단 기술의 다른 시도보다 획기적이고 더 나은 이유입니다. 이를 다루려면 이 정도 크기의 많은 블로그 게시물이 필요할 것이며, 내 생각에는 이것이 바로 우리가 할 일입니다. 자세한 내용을 계속 지켜봐 주시기 바랍니다.