S4 Embed
Gateway FinOps para vector search
Uma camada FinOps que torna seu banco vetorial existente mais barato enquanto mantém o recall no alvo. Ela quantiza embeddings (binary + int8) e executa uma busca em duas etapas (etapa grossa 1-bit Hamming + rescore exato) à frente de OpenSearch, pgvector, Qdrant ou Milvus, reduzindo o grafo ANN em RAM em até 32×. Roda como uma Amazon Linux 2023 AMI na sua própria VPC, cobrada por unidade de uso (textos embedados, documentos indexados, buscas servidas).
S4 Embed ajuda você a encontrar e operar uma configuração de vector search de baixo custo que atende ao seu alvo de recall. Em um benchmark de 30k vetores, binary Hamming + float rescore atingiu recall@10 de 0.976–1.000 dependendo do store e do over-fetch — você escolhe o ponto operacional. As ferramentas FinOps são o produto: s4embed prove (estima a fronteira de recall/custo/latência), compare (mede recall ao vivo entre stores), tune (emite uma configuração implantável que atende a um orçamento de recall + latência + RAM), modo shadow do gateway (dual-write e shadow-compare antes do cutover) e drift (monitora drift de embeddings). Agnóstico a store em OpenSearch, pgvector, Qdrant e Milvus.
O problema
A busca vetorial mantém seu grafo ANN na RAM, portanto, à medida que seu corpus cresce, o uso de memória — e o custo — do seu banco de dados vetorial cresce junto, tornando esse gasto difícil de prever. Você não quer abrir mão do recall para economizar, o que o deixa preso em uma escolha entre custo e qualidade. E raramente existe uma boa maneira de descobrir qual provedor e qual configuração entre OpenSearch, pgvector, Qdrant ou Milvus é mais eficiente em termos de custo antes de colocá-lo em produção.
Como funciona
- 1
Quantize os embeddings
O S4 Embed quantiza seus embeddings para binário (um grafo ANN na RAM até 32x menor) e um resíduo int8 (vetores em disco cerca de 4x menores), reduzindo a RAM que o seu banco de dados vetorial precisa manter.
- 2
Busca em duas etapas para manter o recall
Um estágio preliminar de Hamming de 1 bit monta uma lista curta de candidatos e, em seguida, um rescore exato a reordena. Ao ajustar o ponto de operação de over-fetch e rescore, você mantém a sua meta de recall enquanto reduz o consumo de RAM.
- 3
Valide com dados antes da transição
O s4embed prove, compare e tune medem a fronteira de recall/custo/latência em seus próprios vetores e geram uma configuração pronta para implantação. O modo shadow do gateway realiza gravação dupla e comparação shadow das leituras em tempo real, permitindo que você veja o caminho compactado reproduzir o primário antes da transição.
Destaques
A quantização binary reduz o grafo ANN em RAM em até 32×; recall@10 de 0.976–1.000 em um benchmark de 30k vetores (por store / over-fetch) — escolha o ponto operacional para seu alvo de recall.
Agnóstico a store (OpenSearch / pgvector / Qdrant / Milvus); o modo shadow valida o caminho comprimido contra o primário antes de qualquer cutover.
FinOps CLI — prove / compare / tune / drift — mede custo, recall e latência e emite uma configuração implantável.
O que está incluído
- AMI do Amazon Linux 2023 (x86_64) — um gateway FinOps de busca vetorial que é executado atrás do seu próprio load balancer, dentro da sua própria VPC
- Quantização binária + int8 com um pipeline de busca em duas etapas (etapa aproximada Hamming de 1 bit mais reavaliação exata), reduzindo o grafo ANN na RAM em até 32x
- Um pipeline agnóstico de armazenamento entre OpenSearch, pgvector, Qdrant e Milvus, sem lock-in
- Uma CLI FinOps — s4embed prove (estima a fronteira de recall/custo/latência), compare (mede o recall de ANN em tempo real entre os armazenamentos), tune (gera uma configuração que atende a um orçamento de recall + latência + RAM) e drift (monitora o desvio de embeddings e o recall, recomendando o reajuste)
- Um modo shadow de gateway que realiza escrita dupla e compara em shadow as leituras em tempo real, para que você possa confirmar se o caminho comprimido reproduz o primário antes de qualquer transição
- Um quick-start do CloudFormation que provisiona os caminhos do OpenSearch e pgvector (o Qdrant e o Milvus se conectam apontando o gateway para o seu endpoint existente)
- Recursos operacionais — autenticação por chave de API (quando configurada), limites de tamanho de requisição e concorrência, uma readiness probe que falha no modo fechado (fail-closed) em caso de problemas de cobrança ou armazenamento, métricas do Prometheus e cobrança tarifada por uso (por texto incorporado, documento indexado e busca atendida)
Casos de uso
Workloads de busca e RAG em larga escala nos quais o custo de RAM do banco de dados vetorial cresce com o corpus
Equipes que desejam reduzir o custo da busca vetorial enquanto mantêm sua meta de recall
Medição de qual armazenamento e configuração entre OpenSearch, pgvector, Qdrant e Milvus é mais eficiente em custo antes da transição para a produção
Execução de busca vetorial com cobrança baseada no uso, mantendo seus dados e o banco de dados vetorial dentro da sua própria conta
FAQ
A compressão não prejudica o recall?
Você escolhe o ponto de operação. Em um benchmark de 30k vetores, Hamming binário + reavaliação float atingiu recall@10 de 0.976 a 1.000 (OpenSearch 0.995, pgvector 0.996, Qdrant 1.000, Milvus 0.976) — tudo isso com a redução de 32x na RAM. O recall aumenta com o over-fetch, então você ajusta o ponto de operação de acordo com sua meta de recall. O recall escala com o over-fetch, e o melhor ponto é escolhido por workload.
Quanta RAM ele economiza?
A quantização binária torna o grafo ANN na RAM até 32x menor, e o residual int8 torna os vetores em disco cerca de 4x menores. A redução exata depende do seu corpus, do armazenamento e do ponto de operação escolhido, de modo que a forma mais confiável de dimensioná-la é estimar a partir dos seus próprios dados com s4embed prove e tune.
Quais armazenamentos vetoriais são suportados?
O pipeline é agnóstico de armazenamento entre OpenSearch, pgvector, Qdrant e Milvus. Os caminhos do OpenSearch e pgvector podem ser provisionados com o quick-start do CloudFormation incluso, e o Qdrant e o Milvus funcionam apontando o gateway para o seu endpoint existente. O s4embed compare permite medir o recall de ANN em tempo real nos armazenamentos.
Posso validar antes da transição para a produção?
Sim. O s4embed prove e o tune estimam uma configuração com seus próprios vetores, e o compare mede o recall de ANN em tempo real nos armazenamentos. O modo shadow do gateway realiza escrita dupla e compara em shadow as leituras em tempo real para que você possa confirmar se o caminho comprimido reproduz o primário antes da transição, e o s4embed drift então monitora o desvio de embeddings e o recall, recomendando o reajuste.
Onde meus dados ficam e como são cobrados?
O S4 Embed roda como uma AMI padrão do Amazon Linux 2023 atrás do seu próprio load balancer, dentro da sua própria VPC. Seus dados e seu banco de dados vetorial nunca saem da sua conta, e não há lock-in. A cobrança é medida por uso através da sua fatura da AWS — por texto incorporado, documento indexado e busca atendida — enviada de hora em hora via AWS Marketplace Metering Service.
Modelo de precificação
Cobrança por uso (textos embedados, documentos indexados, buscas servidas) + EC2 na sua própria VPC (Amazon Linux 2023 AMI).
Outros produtos S4
S4 — Squished S3
Gateway transparente de compressão S3 com GPU
S4 Logs
Arquive CloudWatch Logs em S3 com zstd
S4 Metrics
Controle a cardinalidade de métricas do CloudWatch