O que os utilizadores do Milvus nos ensinaram em 2024

Visão geral

À medida que o Milvus florescia em 2024 com grandes lançamentos e um ecossistema de código aberto próspero, um tesouro escondido de ideias dos utilizadores estava a formar-se discretamente na nossa comunidade no Discord. Esta compilação de discussões da comunidade representou uma oportunidade única para compreender os desafios dos nossos utilizadores em primeira mão. Intrigado com este recurso inexplorado, iniciei uma análise exaustiva de todos os tópicos de discussão do ano, procurando padrões que nos pudessem ajudar a compilar um recurso de perguntas frequentes para os utilizadores do Milvus.

A minha análise revelou três áreas principais onde os utilizadores procuravam consistentemente orientação: Otimização do desempenho, estratégias de implementação e gestão de dados. Os utilizadores discutiam frequentemente como afinar o Milvus para ambientes de produção e acompanhar eficazmente as métricas de desempenho. Quando se tratava de implantação, a comunidade lutava para selecionar implantações apropriadas, escolher índices de pesquisa ideais e resolver problemas em configurações distribuídas. As conversas sobre gestão de dados centraram-se em estratégias de migração de dados de serviço para serviço e na seleção de modelos de incorporação.

Vamos examinar cada uma dessas áreas com mais detalhes.

Implantação

Milvus oferece modos de implantação flexíveis para atender a vários casos de uso. No entanto, alguns utilizadores têm dificuldade em encontrar a escolha certa e querem ter a certeza de que o estão a fazer "corretamente".

Que tipo de implementação devo escolher?

Uma pergunta muito frequente é qual a implementação a escolher entre Milvus Lite, Standalone e Distributed. A resposta depende principalmente do tamanho da sua base de dados vetorial e da quantidade de tráfego que irá servir:

Milvus Lite

Ao criar protótipos no seu sistema local com até alguns milhões de vectores, ou ao procurar uma base de dados de vectores incorporada para testes unitários e CI/CD, pode utilizar o Milvus Lite. Note que algumas funcionalidades mais avançadas, como a pesquisa de texto completo, ainda não estão disponíveis no Milvus Lite, mas estarão disponíveis em breve.

Milvus Autónomo

Se o seu sistema precisa de servir o tráfego de produção e/ou precisa de armazenar entre alguns milhões e uma centena de milhões de vectores, deve usar o Milvus Standalone, que empacota todos os componentes do Milvus numa única imagem Docker. Existe uma variação que apenas retira suas dependências de armazenamento persistente (minio) e armazenamento de metadados (etcd) como imagens separadas.

Milvus Distribuído

Para qualquer implantação em grande escala que sirva tráfego de produção, como servir bilhões de vetores a milhares de QPS, você deve usar o Milvus Distributed. Alguns utilizadores podem querer realizar processamento offline em lote em escala, por exemplo, para deduplicação de dados ou ligação de registos, e a futura versão do Milvus 3.0 irá fornecer uma forma mais eficiente de o fazer através do que chamamos de lago de vectores.

Serviço totalmente gerido

Para os programadores que pretendem concentrar-se no desenvolvimento da aplicação sem se preocuparem com o DevOps, o Zilliz Cloud é o Milvus totalmente gerido que oferece um nível gratuito.

Consulte "Visão geral das implementações do Milvus" para obter mais informações.

De quanta memória, armazenamento e computação vou precisar?

Esta questão surge com frequência, não só para os actuais utilizadores do Milvus, mas também para aqueles que estão a considerar se o Milvus é adequado para a sua aplicação. A combinação exacta da quantidade de memória, armazenamento e computação que uma implementação irá necessitar depende de uma interação complexa de factores.

Os embeddings vectoriais diferem em dimensionalidade devido ao modelo utilizado. E alguns índices de pesquisa vetorial são armazenados inteiramente na memória, enquanto outros armazenam dados no disco. Além disso, muitos índices de pesquisa são capazes de armazenar uma cópia comprimida (quantizada) dos embeddings e requerem memória adicional para estruturas de dados de grafos. Estes são apenas alguns dos factores que afectam a memória e o armazenamento.

Ferramenta de dimensionamento de recursos Milvus

Felizmente, Zilliz (a equipa que mantém o Milvus) construiu uma ferramenta de dimensionamento de recursos que faz um trabalho fantástico ao responder a esta questão. Introduza a dimensionalidade do vetor, o tipo de índice, as opções de implementação, etc. e a ferramenta estima a CPU, a memória e o armazenamento necessários para os vários tipos de nós Milvus e as suas dependências. A sua quilometragem pode variar, pelo que um teste de carga real com os seus dados e amostras de tráfego é sempre uma boa ideia.

Que índice vetorial ou métrica de distância devo escolher?

Muitos utilizadores não sabem ao certo qual o índice que devem escolher e como definir os hiperparâmetros. Em primeiro lugar, é sempre possível adiar a escolha do tipo de índice para o Milvus, selecionando AUTOINDEX. No entanto, se pretender selecionar um tipo de índice específico, algumas regras de ouro fornecem um ponto de partida.

Índices na memória

Gostaria de pagar o custo para colocar o seu índice inteiramente na memória? Um índice na memória é normalmente o mais rápido, mas também é caro. Veja "Índices na memória" para uma lista dos que são suportados pelo Milvus e as compensações que eles fazem em termos de latência, memória e recuperação.

Tenha em mente que o tamanho do seu índice não é simplesmente o número de vectores vezes a sua dimensionalidade e tamanho em ponto flutuante. A maioria dos índices quantiza os vectores para reduzir a utilização de memória, mas requer memória para estruturas de dados adicionais. Outros dados não vectoriais (escalares) e o respetivo índice também ocupam espaço de memória.

Índices no disco

Quando o seu índice não cabe na memória, pode utilizar um dos "On-disk indexes" fornecidos pelo Milvus. Duas opções com diferentes relações entre latência e recursos são DiskANN e MMap.

O DiskANN armazena uma cópia altamente comprimida dos vectores em memória, e os vectores não comprimidos e as estruturas de pesquisa de grafos no disco. Ele usa algumas ideias inteligentes para pesquisar o espaço vetorial, minimizando as leituras em disco e aproveitando a velocidade de acesso aleatório dos SSDs. Para obter uma latência mínima, o SSD deve ser conectado via NVMe em vez de SATA para obter o melhor desempenho de E/S.

Tecnicamente falando, MMap não é um tipo de índice, mas refere-se ao uso de memória virtual com um índice na memória. Com a memória virtual, as páginas podem ser trocadas entre o disco e a RAM conforme necessário, o que permite que um índice muito maior seja usado com eficiência se os padrões de acesso forem tais que apenas uma pequena parte dos dados seja usada de cada vez.

O DiskANN tem uma latência excelente e consistente. O MMap tem uma latência ainda melhor quando está a aceder a uma página na memória, mas a troca frequente de páginas causará picos de latência. Assim, o MMap pode ter uma maior variabilidade na latência, dependendo dos padrões de acesso à memória.

Índices GPU

Uma terceira opção é construir um índice usando memória GPU e computação. O suporte GPU do Milvus é contribuído pela equipa Nvidia RAPIDS. A pesquisa vetorial em GPU pode ter uma latência mais baixa do que uma pesquisa correspondente em CPU, embora normalmente sejam necessárias centenas ou milhares de QPS de pesquisa para explorar totalmente o paralelismo da GPU. Além disso, as GPUs têm normalmente menos memória do que a RAM da CPU e a sua execução é mais dispendiosa.

Métricas de distância

Uma questão mais fácil de responder é qual a métrica de distância que deve ser escolhida para medir a semelhança entre vectores. Recomenda-se escolher a mesma métrica de distância com a qual o modelo de incorporação foi treinado, que normalmente é COSINE (ou IP quando as entradas são normalizadas). A fonte do seu modelo (por exemplo, a página do modelo no HuggingFace) fornecerá esclarecimentos sobre qual métrica de distância foi usada. O Zilliz também elaborou uma tabela conveniente para procurar isso.

Para resumir, acho que grande parte da incerteza em torno da escolha do índice gira em torno da incerteza sobre como essas escolhas afetam a troca de latência/uso de recursos/recall da sua implantação. Recomendo usar as regras de ouro acima para decidir entre índices na memória, no disco ou na GPU e, em seguida, usar as diretrizes de troca fornecidas na documentação do Milvus para escolher um índice específico.

Podem reparar a minha implementação Milvus Distributed avariada?

Muitas perguntas giram em torno de problemas para colocar uma implantação do Milvus Distributed em funcionamento, com questões relacionadas à configuração, ferramentas e logs de depuração. É difícil dar uma única solução, uma vez que cada questão parece diferente da anterior, embora felizmente o Milvus tenha um Discord vibrante onde pode procurar ajuda, e também oferecemos horas de expediente 1-on-1 com um especialista.

Como faço para implantar o Milvus no Windows?

Uma questão que tem surgido várias vezes é como implementar o Milvus em máquinas Windows. Com base no seu feedback, reescrevemos a documentação para isso: veja Executar Milvus no Docker (Windows) para saber como fazer isso, usando o Windows Subsystem for Linux 2 (WSL2).

Desempenho e análise de perfil

Depois de escolher um tipo de implantação e colocá-lo em execução, os usuários querem se sentir confortáveis de que tomaram as melhores decisões e gostariam de criar um perfil do desempenho e do estado de sua implantação. Muitas perguntas estão relacionadas a como traçar o perfil de desempenho, observar o estado e obter uma visão do que e por quê.

Como é que meço o desempenho?

Os utilizadores pretendem verificar as métricas relacionadas com o desempenho da sua implementação para que possam compreender e resolver os estrangulamentos. As métricas mencionadas incluem a latência média das consultas, a distribuição das latências, o volume das consultas, a utilização da memória, o armazenamento em disco, etc. Estas métricas podem ser observadas a partir do sistema de monitorização. Além disso, o Milvus 2.5 introduz uma nova ferramenta chamada WebUI (feedback bem-vindo!), que permite aceder a mais informações internas do sistema, como o estado da compactação de segmentos, a partir de uma interface web de fácil utilização.

O que está a acontecer no Milvus neste momento (i.e. observar o estado)?

De forma relacionada, os utilizadores querem observar o estado interno da sua implementação. As questões levantadas incluem compreender porque é que um índice de pesquisa está a demorar tanto tempo a ser construído, como determinar se o cluster está saudável e compreender como é que uma consulta é executada nos nós. Muitas destas questões podem ser respondidas com a nova WebUI que dá transparência ao que o sistema está a fazer internamente.

Como funciona algum aspeto (complexo) da parte interna?

Os utilizadores avançados querem muitas vezes ter alguma compreensão dos aspectos internos do Milvus, por exemplo, ter uma compreensão da selagem de segmentos ou da gestão de memória. O objetivo subjacente é tipicamente melhorar o desempenho e por vezes depurar problemas. A documentação, particularmente nas secções "Conceitos" e "Guia de Administração" é útil neste caso, por exemplo, veja as páginas "Visão Geral da Arquitetura Milvus" e "Compactação de Clusters". Continuaremos a melhorar a documentação sobre a parte interna do Milvus, tornando-a mais fácil de compreender, e agradecemos qualquer feedback ou pedido através do Discord.

Que modelo de incorporação devo escolher?

Uma questão relacionada com o desempenho que tem surgido várias vezes em encontros, horas de expediente e no Discord é como escolher um modelo de incorporação. Esta é uma pergunta difícil de dar uma resposta definitiva, embora recomendemos começar com modelos padrão como all-MiniLM-L6-v2.

Semelhante à escolha do índice de pesquisa, existem compensações entre computação, armazenamento e recuperação. Um modelo de incorporação com uma dimensão de saída maior exigirá mais armazenamento, se tudo o resto se mantiver igual, embora provavelmente resulte numa maior recuperação de itens relevantes. Os modelos de incorporação maiores, para uma dimensão fixa, normalmente superam os modelos mais pequenos em termos de recuperação, embora à custa de mais computação e tempo. As tabelas de classificação que classificam o desempenho do modelo de incorporação, como o MTEB, baseiam-se em referências que podem não estar alinhadas com os seus dados e tarefas específicos.

Por isso, não faz sentido pensar num "melhor" modelo de incorporação. Comece com um que tenha uma recuperação aceitável e que corresponda ao seu orçamento de computação e tempo para calcular as incorporações. Outras optimizações, como o ajuste fino dos seus dados ou a exploração empírica da relação computação/recuperação, podem ser adiadas para depois de ter um sistema funcional em produção.

Gestão de dados

Como mover dados para dentro e para fora de uma implantação Milvus é outro tema principal nas discussões do Discord, o que não é nenhuma surpresa, dado o quão central esta tarefa é para colocar uma aplicação em produção.

Como é que eu migro dados do X para o Milvus? Como é que migro dados de Standalone para Distributed? Como é que migro da versão 2.4.x para a 2.5.x?

Um novo utilizador pretende normalmente introduzir dados existentes no Milvus a partir de outra plataforma, incluindo motores de busca tradicionais como o Elasticsearch e outras bases de dados vectoriais como o Pinecone ou o Qdrant. Os utilizadores existentes também podem querer migrar os seus dados de uma implementação do Milvus para outra, ou do Milvus auto-hospedado para o Zilliz Cloud totalmente gerido.

O Vetor Transport Service (VTS) e o serviço de Migração gerido no Zilliz Cloud foram concebidos para este fim.

Como é que guardo e carrego cópias de segurança de dados? Como é que exporto dados do Milvus?

O Milvus tem uma ferramenta dedicada, milvus-backup, para tirar instantâneos em armazenamento permanente e restaurá-los.

Próximos passos

Espero que isto lhe tenha dado algumas indicações sobre como enfrentar os desafios comuns que se colocam quando se constrói com uma base de dados vetorial. Isso definitivamente nos ajudou a olhar novamente para a nossa documentação e roteiro de recursos para continuar trabalhando em coisas que podem ajudar a nossa comunidade a ter sucesso com o Milvus. Uma conclusão importante que eu gostaria de enfatizar é que as suas escolhas o colocam em diferentes pontos de um espaço de troca entre computação, armazenamento, latência e recuperação. Não é possível maximizar todos estes critérios de desempenho em simultâneo - não existe uma implementação "óptima". No entanto, ao compreender melhor o funcionamento da pesquisa vetorial e dos sistemas de bases de dados distribuídas, pode tomar uma decisão informada.

Depois de percorrer o grande número de publicações de 2024, fiquei a pensar: porque é que um humano deveria fazer isto? A IA generativa não prometeu resolver esta tarefa de analisar grandes quantidades de texto e extrair informações? Junte-se a mim na segunda parte desta publicação do blogue (em breve), onde investigarei a conceção e a implementação de um sistema multiagente para extrair informações de fóruns de discussão.

Mais uma vez, obrigado e espero vê-lo no Discord da comunidade e nos nossos próximos encontros de dados não estruturados. Para uma assistência mais prática, convidamo-lo a marcar uma hora de trabalho individual. O seu feedback é essencial para melhorar o Milvus!