O Azure AI Search não dimensiona pela quantidade de vetores que você tem. Ele dimensiona por tier: o vector index é limitado pela memória reservada para vector search no seu SKU, e no modelo Serverless por um teto rígido de 300 MB por índice que faz o indexing job falhar de imediato quando excedido. Essa única propriedade, não uma comparação de features, decide se a camada de retrieval da empresa pertence ao Azure AI Search ou a um vector database dedicado. A Parte 6 tornou as perguntas repetidas baratas. Esta parte trata do caso muito mais comum, em que o modelo precisa de fatos que nunca viu, e a busca de conhecimento de varejo da Parte 1 finalmente é construída.

Onde o retrieval fica em relação ao gateway

Um ponto que vale resolver antes de qualquer comparação, porque é ele que mantém a premissa da série intacta: retrieval não é tráfego de gateway. A aplicação consulta o search index diretamente, monta um prompt com o que volta e envia esse prompt pelo gateway como qualquer outra completion. O gateway mede os tokens que o contexto recuperado adiciona, que é exatamente a visibilidade que você quer, já que o retrieval costuma ser onde o tamanho do prompt triplica em silêncio.

A única parte que toca o gateway é o embedding. Gerar embeddings de query e de documento é uma chamada de modelo, então passa pela mesma porta que todo o resto, com a mesma quota e a mesma atribuição. Isso também significa que o deployment de embeddings que a Parte 6 criou para o semantic caching provavelmente é o mesmo deployment que o retrieval quer, e sua capacidade agora serve a dois senhores.

Os limites que realmente decidem

Checklists de features fazem o Azure AI Search e um vector store dedicado parecerem intercambiáveis. Os limites de serviço, não.

  • O tamanho do vector index é função do SKU, não dos seus dados. No modelo de preço Dedicated ele é limitado pela memória reservada para vector search no tier; no Serverless são 300 MB por índice, cerca de 30 por cento do armazenamento total do índice, e um limite rígido que faz a indexação falhar em vez de degradar.
  • Os limites de vetores dependem de quando o serviço foi criado. Quotas de vetores mais altas valem para serviços criados a partir de abril de 2024 em regiões com a capacidade extra. Um serviço mais antigo em uma região suportada pode precisar de um upgrade explícito para obtê-las, o que é uma questão de migração, não um toggle de configuração.
  • Capacidade é replicas multiplicadas por partitions. O Basic suporta três partitions e três replicas, nove search units, em serviços criados depois de 3 de abril de 2024; serviços Basic mais antigos ficam limitados a uma partition. Do S1 ao S3, o teto sobe para doze de cada.
  • O SLA é uma contagem de replicas. Duas ou mais replicas para workloads de query, três ou mais para query e indexação. A contagem de partitions não entra no SLA de forma alguma, o que surpreende quem escalou por armazenamento e assumiu que a disponibilidade vinha junto.
  • A contagem de índices tem teto por tier. Cinco ou quinze no Basic, cinquenta no S1, duzentos no S2 e S3. Uma plataforma que dá a cada tenant seu próprio índice bate nesse teto muito antes de bater no armazenamento, e índice por tenant é o instinto default.
  • Máximo de 4096 dimensões por campo de vetor, em todos os tiers, o que é generoso mas vale saber antes que alguém padronize um embedding model maior.

Lidos em conjunto, esses limites dizem algo específico: o Azure AI Search é precificado e escalado como um serviço de busca que também faz vetores. Se o corpus de vetores é o principal driver de custo e cresce independentemente do volume de queries, você está pagando search units para segurar memória. Essa é a condição sob a qual um vector database dedicado vence, e é uma condição quantitativa que dá para verificar, não uma preferência arquitetural.

O que o Azure AI Search oferece que um vector store não oferece

O contrapeso é real e muitas vezes decisivo para uma base de conhecimento corporativa.

Hybrid search em uma única requisição. Uma mesma query carrega tanto um parâmetro search quanto vectorQueries, roda retrieval full-text e vetorial em paralelo e mescla os dois com Reciprocal Rank Fusion em um único result set ranqueado. O ranking de texto usa BM25; o ranking vetorial usa HNSW ou exhaustive KNN. Isso importa porque documentação de produto é cheia de tokens exatos, números de modelo, códigos de erro, números de peça, que a busca lexical encontra de forma confiável e os embeddings borram.

{
  "search": "device not connecting after the firmware update",
  "vectorQueries": [
    { "kind": "vector", "vector": [ ... ], "k": 50,
      "fields": "contentVector", "exhaustive": false, "oversampling": 10 }
  ],
  "queryType": "semantic",
  "semanticConfiguration": "kb-semantic",
  "top": 10
}

Filtros, facetas, ordenação e scoring profiles se aplicam à mesma requisição, então a autorização em nível de documento (este tenant, esta linha de produto, este idioma) é um filtro, não um índice separado. Integrated vectorization via indexers puxa de Blob Storage, Cosmos DB, Azure SQL ou OneLake e gera embeddings na ingestão, o que remove um pipeline inteiro que o time de plataforma teria de manter. E o índice pode ser anexado como knowledge source para cenários de agentes no Microsoft Foundry.

Um detalhe de capacidade se esconde dentro da história de qualidade de ranking. O semantic ranker é limitado por uma fila, com um máximo de requisições concorrentes por search unit que é 2 no Basic, 3 no S1 e 4 do S2 para cima, mais uma fila de tamanho limitado atrás dele. Exceda a fila e as requisições são rejeitadas e precisam ser repetidas. O jeito de aumentar isso é mais search units, ou um support request. Uma camada de retrieval que liga o semantic ranking para toda query acabou de tornar seu teto de concorrência uma função do tier de busca, e esse teto é pequeno no Basic.

A decisão, formulada como um teste

Não é preferência. Três verificações, em ordem:

  • O corpus precisa de retrieval lexical e vetorial juntos? Se identificadores exatos importam, e para documentação de produto eles sempre importam, hybrid mais semantic ranking em um único serviço vale muito, e reimplementar isso sobre um vector store puro significa rodar também um índice invertido.
  • O footprint de vetores cresce independentemente do volume de queries? Se sim, modele as search units necessárias para segurá-lo e compare com um vector database dimensionado por armazenamento. Isso é aritmética, e costuma ser onde a resposta vira.
  • Quantos corpora lógicos existem? Um índice por tenant bate rápido no teto de índices do tier. A alternativa é um índice único com um tenant filter, que é um controle de segurança que precisa ser aplicado na camada de query, não no cliente.

Para esta plataforma a resposta é Azure AI Search, porque a base de conhecimento de varejo são algumas dezenas de gigabytes de documentação de produto onde números de modelo exatos importam, e porque o custo operacional de mais um serviço gerenciado é menor que o custo de um vector store autogerido no mesmo cluster AKS. A resposta para um memory store de agentes com centenas de milhões de vetores e nenhum requisito lexical seria a oposta, e a série estaria errada em fingir o contrário.

Tenancy, e o filtro que é um controle de segurança

Um índice único com um tenant filter é o default certo sob o teto de contagem de índices, e ele coloca uma decisão de autorização dentro da query. A regra é a mesma do vary-by na Parte 6: o valor do filtro vem do token validado, nunca de um parâmetro de requisição. Uma aplicação que passa o próprio tenant ID está a um bug de distância de passar o de outra pessoa.

Como o retrieval não passa pelo API Management, o ponto de enforcement é a aplicação ou o control plane, não uma policy de gateway. Isso é uma lacuna genuína no modelo de uma porta só, e é melhor nomeá-la do que disfarçá-la: o gateway governa o acesso aos modelos, o serviço de busca governa o acesso aos documentos, e são dois control planes diferentes que precisam concordar sobre quem é o tenant. Derivar os dois do mesmo claim do Entra ID é o que os impede de divergir.

Modos de falha para observar

  • Indexação que falha em um limite de tamanho em vez de degradar. Exceder o teto de vetores por índice no Serverless faz a operação falhar. Capacidade para o vector index é um insumo de planejamento, não algo para descobrir durante um bulk load.
  • Um search service antigo com quotas de vetores antigas. Criado antes de abril de 2024, em uma região que agora oferece mais, e silenciosamente limitado até alguém fazer o upgrade.
  • Escalar partitions esperando disponibilidade. Partitions são armazenamento. O SLA conta replicas, duas para queries e três quando a indexação roda junto.
  • Semantic ranker estrangulando sob carga. A concorrência é por search unit e pequena nos tiers mais baixos. O sintoma são queries rejeitadas no pico, não queries lentas.
  • Índice por tenant contra um teto de tier. Funciona lindamente para a primeira dúzia de tenants e depois para, e nesse ponto a migração para um índice filtrado é um projeto de dados.
  • Contexto recuperado explodindo o tamanho do prompt. O gateway o mede, então ele aparece nos números da Parte 5 como um aumento de tokens sem nenhuma mudança de código que o explique. Alerte sobre tokens por requisição por tenant, não só sobre o gasto total.

O que a Parte 8 herda

Uma camada de retrieval que as aplicações chamam diretamente, um deployment de embeddings compartilhado com o cache e prompts que agora são consideravelmente maiores do que eram. O que levanta a pergunta de que trata a próxima parte: quando uma aplicação precisa de retrieval, tool calling e múltiplos saltos de modelo, um framework de orquestração pertence em cima deste gateway, ou o framework começa a brigar com ele.

Leia isso a seguir

Para o lado de infraestrutura e plataforma de rodar isso em escala, as notas de campo estão em ercan.cloud, e o hub fica em ercanermis.com.

Referências