View a markdown version of this page

벡터 인덱스 모범 사례 - Amazon DynamoDB

벡터 인덱스 모범 사례

다음 권장 사항은 정확하고 성능이 뛰어나며 비용 효율적인 벡터 인덱스를 설계하는 데 도움이 됩니다.

먼저 임베딩 모델 및 차원을 선택합니다.

사용하는 임베딩 모델은 벡터의 차원 수를 결정합니다. Dimensions는 인덱스를 생성할 때 설정합니다. 생성 후에는 차원 수를 변경할 수 없습니다. 인덱스를 생성하기 전에 임베딩 모델을 결정하고 동일한 모델을 사용하여 저장된 벡터와 쿼리 벡터를 모두 생성합니다. 차원이 적을수록 검색, 쓰기 및 스토리지 비용이 절감되지만 고차원 모델은 더 많은 의미론적 세부 정보를 캡처할 수 있습니다. 관련성 요구 사항을 충족하는 가장 작은 차원 수를 선택합니다. 벡터 임베딩 생성을(를) 참조하세요.

거리 함수를 임베딩과 일치

임베딩 모델이 유사성을 표현하는 방식과 일치하는 거리 함수를 선택합니다. COSINE은 방향을 비교하고 크기를 무시하며, 대부분의 텍스트 임베딩 모델에 적합합니다. EUCLIDEAN은 절대 거리를 측정하고 크기에 민감합니다. DOT_PRODUCT도 크기에 민감합니다. 이를 사용하는 경우 점수가 벡터 길이가 아닌 방향을 반영하도록 임베딩을 단위 길이로 정규화합니다. 인덱스를 생성한 후에는 거리 함수를 변경할 수 없으므로 먼저 대표 데이터세트에 대해 선택 사항을 검증합니다. 거리 함수가 결과의 순위를 매기는 방법을(를) 참조하세요.

쿼리 패턴과 일치하는 파티션 키 선택

파티션 키는 각 SearchVectors 호출을 단일 파티션 키 값에 속하는 벡터 인덱스 부분으로 제한합니다. 호출은 전체 인덱스를 검색하지 않습니다. 데이터를 적게 검색하면 비용이 감소하고 지연 시간 및 재현율을 개선할 수 있으며, 파티션 키 값 전반에서 처리량을 수평 확장할 수 있습니다.

모든 검색에서 SearchConditionExpression에 파티션 키 값을 제공해야 합니다. 각 검색의 범위는 정확히 하나의 파티션 키 값으로 지정됩니다. 애플리케이션이 지원하는 쿼리 패턴과 일치하는 파티션 키를 선택합니다.

예를 들어 미국 주를 기준으로 위치 기반 데이터를 저장하는 경우 약 50개의 파티션 키 값이 있습니다. 각 주에는 양호한 재현율을 위해 의미 있는 수의 벡터가 있습니다. 50개의 파티션은 최대 약 50배의 수평 처리량 스케일링을 제공합니다. 이는 모든 검색이 단일 상태를 대상으로 할 때 유효합니다.

어느 방향이든 극단적인 카디널리티는 피합니다.

  • 너무 높음(예: 고유 항목 ID) - 각 파티션에는 비교할 이웃이 없는 단일 항목이 포함되어 있어 재현율이 낮습니다.

  • 너무 낮음(예: 부울) - 대부분의 항목이 하나의 파티션에 있으므로 처리량 스케일링이 제한되고 지연 시간 및 비용 이점이 줄어듭니다.

파티션 내에서 추가로 필터링하려면 인라인 필터 속성을 사용합니다.

처리량 예제. 비 벡터 항목 데이터가 1KB인 768차원 임베딩 모델(예: Cohere Embed v3)을 고려해 보면, 총 항목 크기는 약 4KB(768차원 × 4바이트 + 1KB)입니다. 이 항목 크기에서 파티션 키당 한도는 다음과 같이 적용됩니다.

  • 검색: 1GBps ÷ 4KB ≈ 파티션 키 값당 초당 250,000개 벡터 검사. 파티션의 벡터 수가 증가하면 각 검색에서 더 많은 데이터를 검사하게 되어 이 한도에 더 빨리 도달하게 됩니다.

  • 쓰기: 10MBps ÷ 4KB ≈ 파티션 키 값당 초당 2,500개 벡터 쓰기

데이터를 더 많은 파티션 키 값에 분산하면 이러한 한도가 배가됩니다. 예를 들어 파티션 키 값 50개는 집계 검색 및 쓰기 처리량을 최대 50배까지 높일 수 있습니다. 워크로드가 파티션 키당 한도를 초과하는 경우 AWS Support에 문의하세요.

임베딩을 소스 콘텐츠와 동기화된 상태로 유지

DynamoDB는 임베딩을 다시 계산하지 않습니다. 임베딩이 나타내는 소스 콘텐츠를 변경할 때마다 동일한 임베딩 모델로 벡터를 재생성하고 항목에 다시 씁니다. 그렇지 않으면 인덱스는 계속해서 오래된 벡터를 기반으로 결과를 반환합니다. DynamoDB Streams를 사용하여 콘텐츠 변경 사항을 캡처하고 다운스트림 프로세스를 사용하여 영향을 받는 임베딩을 재생성하고 다시 쓰는 것이 좋습니다.

필요한 속성만 프로젝션

SearchVectors는 벡터 인덱스로 프로젝션되지 않은 속성을 반환할 수 없습니다. 더 많은 속성을 프로젝션할수록 인덱스 스토리지 및 쓰기 비용이 증가합니다. 애플리케이션이 검색 결과에서 직접 읽는 속성을 프로젝션하고 필요한 경우 기본 테이블에서 후속 GetItem 또는 BatchGetItem을 사용하여 나머지 속성을 검색합니다.

여러 인덱스를 사용하여 임베딩 모델 비교

단일 테이블에 최대 5개의 벡터 인덱스를 생성할 수 있습니다. 별도의 인덱스를 사용하여 다양한 임베딩 모델 또는 모델 버전을 나란히 평가합니다. 각 모델의 임베딩을 다른 벡터 속성에 저장하고 각각에 대한 벡터 인덱스를 생성합니다. 이를 통해 프로덕션 인덱스를 마이그레이션하지 않고도 동일한 기본 데이터를 기준으로 모델 간 검색 품질을 비교할 수 있습니다.

예를 들어 한 모델 버전에서 다른 모델 버전으로 업그레이드할 때 새 모델의 차원 및 거리 함수를 사용하여 두 번째 인덱스를 생성합니다. 두 번째 인덱스를 새 모델의 임베딩으로 백필하고 두 인덱스에 대해 테스트 쿼리를 실행하여 관련성을 비교합니다. 만족스러우면 애플리케이션을 새 인덱스로 마이그레이션하고 이전 인덱스를 삭제합니다.