벡터 데이터베이스에 모델 버전에 대한 외래 키가 부족하다

요약 — 벡터 데이터베이스는 서로 다른 모델 버전의 임베딩을 아무 문제 없이 같은 인덱스에 저장할 수 있습니다. 왜냐하면 해당 벡터들이 기하학적으로 의미가 없더라도 타입만 유효하기 때문입니다. 데이터 웨어하우스 규모에서 모델 업그레이드 후 수십억 개의 행을 재임베딩하는 것은 방대하고 느린 배치 작업이며, 이는 혼합 버전 인덱스가 예외적인 경우가 아니라 모든 마이그레이션 과정의 기본 상태임을 의미합니다. 해결책은 모델 식별자를 임베딩 컬럼의 스키마 제약 조건으로 취급하는 것이지, 기억나서 확인하는 메타데이터로 취급하는 것이 아닙니다.

벡터 컬럼은 웨어하우스가 실행할 수 있는 모든 검사를 통과합니다. 올바른 차원성(dimensionality)을 가지고 있고, 올바른 데이터 타입(dtype)이며, NULL이 아니고, 예상되는 노름 범위 내에 있습니다. 스키마 상으로는 실제로 중요한 단 한 가지—즉, 해당 컬럼의 모든 벡터가 동일한 모델에서 왔는지 여부—를 포착할 방법이 없습니다. 데이터 웨어하우스 규모에서는 보통 그렇지 않으며, 그 결과 발생하는 실패는 전체 AI 스택에서 가장 조용한 실패 중 하나입니다.

거짓말하는 스키마

임베딩은 데이터가 아닙니다. 그것들은 특정 모델이 정의한 기하학 공간의 좌표입니다. 두 벡터 간의 코사인 유사도(Cosine similarity)는 두 벡터 모두 동일한 함수에 의해 같은 공간에 배치되었을 때만 의미가 있습니다. 모델을 교체하면—새로운 체크포인트, 새로운 토크나이저, 심지어 변경된 정규화 단계라도—같은 모양을 가진 다른 공간을 얻게 됩니다. 한 모델 버전의 1536차원 float 배열은 다음 버전의 것과 구조적으로 동일하게 보입니다. 웨어하우스의 타입 시스템은 그것들을 구별할 방법이 없는데, 왜냐하면 애초에 그렇게 설계되지 않았기 때문입니다.

이것이 바로 간극입니다: 관계형 스키마는 구조적 제약(type, nullability, 테이블 간의 외래 키)을 강제합니다. 하지만 '모델 X가 체크포인트 Y에서 전처리 Z를 거쳐 생성했다'는 개념은 없습니다. 따라서 임베딩 열 중 일부만 재생성되어도 웨어하우스는 깨끗하고 유효한 벡터 열로 인식합니다. 그 위에 구축된 벡터 데이터베이스 역시 깨끗한 인덱스를 보게 됩니다. 근접 이웃 검색(Nearest-neighbor search)은 오류 없이 실행됩니다. 유일한 증상은 검색 품질이 모델 드리프트(model drift)나 데이터 품질 저하처럼 보이는 방식으로 서서히 떨어진다는 것인데, 실제로는 서로 호환되지 않는 두 개의 좌표 시스템을 마치 하나인 것처럼 비교하고 있기 때문입니다.

이것이 작은 규모의 문제가 아닌 이유

작은 규모에서는 이 문제가 거의 존재하지 않습니다. 1천만 개 행(row)을 새 모델로 재임베딩하여 테이블을 교체하면, 오후 안에 끝납니다. 전환 과정이 원자적(atomic)에 가깝기 때문에 아무도 그 경계선을 알아차리지 못합니다.

웨어하우스 규모, 즉 수년에 걸쳐 축적된 수십억 개의 행, 역사적 사실 테이블, 피처 테이블, 문서 아카이브에 연결된 임베딩 열을 생각해보세요. 재임베딩은 오후 일과가 아닙니다. 이는 며칠 동안 실행될 수 있는 지속적인 배치 워크로드이며, 처리량(throughput) 및 비용 제약에 따라 때로는 더 오래 걸리기도 합니다. 이 전체 기간 동안 프로덕션 인덱스는 혼합된 상태를 포함합니다: 새 모델로 재임베딩된 행 옆에 여전히 이전 벡터를 가지고 있는 행들이 공존하는 것입니다. 왜냐하면 백필(backfill)이 완료될 때까지 인덱스를 오프라인으로 전환할 여유가 없기 때문입니다.

이는 혼합 버전의 인덱스가 드문 마이그레이션 사고가 아니라는 것을 의미합니다. 이는 웨어하우스 규모 시스템이 임베딩 모델을 업그레이드할 때마다 기본 운영 조건인 것입니다. 웨어하우스가 클수록 이 창(window)은 더 오래 열려 있게 되고, 아무도 원인을 지적할 수 없기 때문에 검색 품질은 조용히 저하됩니다. 왜냐하면 인덱스 내의 모든 개별 벡터는 그 자체로는 완벽하게 유효하기 때문입니다.

재임베딩은 컴퓨팅 예산에서 숨겨진 항목이다

여기에는 대부분의 용량 계획(capacity planning)이 놓치는 비용 차원(cost dimension)이 있습니다. 추론 서비스(Inference serving cost) 비용은 쿼리 볼륨에 비례하여 증가합니다. 이는 예측하고, 상한선을 설정하며, 이에 맞춰 자동 확장(autoscale)할 수 있습니다. 재임베딩(Re-embedding) 비용은 전체 히스토리 데이터 볼륨에 비례하며, 이 볼륨은 계속해서 커집니다. 더 나은 임베딩 모델을 채택할 때마다, 새로운 데이터에 대한 한계 비용(marginal cost)만 지불하는 것이 아닙니다. 보존 정책이 허용하는 가장 먼 시점까지 모든 것을 재처리하는 데 드는 비용을 지불하게 됩니다.

수년간의 문서, 지원 티켓, 로그 또는 녹취록을 보유한 웨어하우스(warehouse)의 경우, 이러한 백필(backfill) 작업은 지속적인 추론 청구서(inference bill)를 압도할 수 있습니다. 재임베딩을 벡터 데이터베이스 소유자 중 누가 하느냐에 따라 실행하는 일회성 스크립트(one-off script)로 취급하는 팀들은, 보통 마이그레이션 도중에, 그리고 임베딩이 반복적이고 데이터 볼륨에 비례하는 컴퓨팅 약속(compute commitment)이라기보다는 해결된 저렴한 전처리 단계라고 가정하고 예산이 책정되었을 때, 이 비용을 힘든 방식으로 재발견하게 됩니다.

실질적인 결과는 재임베딩이 다른 모든 대규모 백필 작업처럼 예산을 책정하고 일정을 잡아야 한다는 것입니다. 즉, 자체 SLA(서비스 수준 협약), 자체 컴퓨팅 할당량, 그리고 자체 소유자를 가져야 하며, 어딘가 계획 문서에서 결정된 모델 업그레이드의 우발적인 부작용으로 취급되어서는 안 됩니다.

제약 조건으로서의 출처(Provenance)이지 메타데이터 필드가 아니다

해결책은 특이하지 않습니다. 이는 관계형 데이터베이스(relational databases)가 수십 년 전에 했던 것과 같은 움직임입니다. 즉, 참조 무결성(referential integrity)이 선택 사항이 되어서는 안 된다고 결정했을 때, 의존성을 신뢰하는 대신 명시적으로 만들고 구조적으로 강제한 것입니다.

구체적으로는, 모든 임베딩 컬럼이 벡터와 함께 복합 식별자(composite identity)를 가져야 합니다 — 모델 식별자, 체크포인트 또는 버전 해시, 그리고 전처리 해시입니다 — 그리고 이 식별자는 선택적 태그가 부속 테이블에 존재하는 것이 아니라, 벡터 인덱스가 분할되고 쿼리되는 방식의 일급 구성 요소여야 합니다. 두 개의 다른 식별자를 아우르는 유사도 검색은 조용히 성공해서는 안 됩니다. 시스템이 기본적으로 거부하거나, 마치 타입 불일치로 인한 조인(join)이 조용히 강제 변환되기보다 거부되는 것처럼 크게 경고해야 합니다.

운영적인 관점에서 보면, 이는 몇 가지 구체적인 습관을 의미합니다:

• 재임베딩(re-embedding)을 계보 추적(lineage), 모니터링 및 정의된 완료 상태를 갖춘 일급 ETL 파이프라인으로 취급해야 합니다 — 누군가 한 번 실행하고 잊어버리는 스크립트가 아닙니다.

• 전환(cutover) 전에 새로운 모델 식별자 하에 새 인덱스를 완전히 구축해야 합니다 — 벡터 인덱스에 대한 블루/그린 교체 방식이며, 이미 스키마 마이그레이션에서 표준으로 자리 잡은 규율입니다.

• 전환 기간 동안 모델 식별자를 사용하여 검색을 필터링하거나 파티셔닝하여, 백필(backfill) 작업이 진행 중일 때에도 쿼리가 두 개의 호환되지 않는 공간을 조용히 혼합하는 일이 없도록 해야 합니다.

• 모델 식별자를 모든 임베딩의 출처 기록(provenance record)의 일부로 로깅하여, 마치 컬럼 계보를 쿼리하듯이 쿼리할 수 있게 만들어야 합니다. 그리하면 품질 회귀(quality regression)가 며칠이 아닌 몇 분 안에 '어떤 모델이 이 벡터를 작성했는지'까지 추적할 수 있습니다.

이 모든 것은 새로운 인프라를 요구하지 않습니다. 이것은 모델 식별자가 스키마가 강제해야 하는 의존성이지, 사고 발생 시 아무도 읽지 않는 변경 로그에 존재하는 사실이 아니라고 결정하는 것을 요구합니다.

진짜 교훈

벡터 데이터베이스는 데이터 웨어하우스가 가진 '타입만 맞으면 데이터는 건전하다'라는 확신을 물려받았습니다. 그 확신은...