Como a Zilliz anteviu o futuro dos bancos de dados vetoriais—e os preparou para produção
Este post é uma recapitulação do podcast com Innovator Coffee e James Luan, VP de Engenharia da Zilliz.
Antes de a IA generativa se tornar popular, bancos de dados vetoriais raramente eram discutidos por si só. A maior parte da atenção ainda estava em bancos de dados relacionais, mecanismos de busca ou frameworks de big data. A busca vetorial, se chegava a ser mencionada, geralmente ficava em artigos de pesquisa ou dentro de bibliotecas de algoritmos — não em conversas sobre sistemas de produção.
Mas os bancos de dados vetoriais não surgiram do nada. Eles cresceram a partir de uma mudança mais profunda em como os dados são criados e usados. Por volta de 2017–2018, as equipes da Zilliz começaram a ver o mesmo problema aparecendo: as empresas queriam trabalhar com muito mais dados não estruturados — texto, imagens, áudio, logs, comportamento do usuário —, mas suas ferramentas existentes não tinham sido criadas para isso. Bancos de dados tradicionais e busca por palavras-chave conseguiam armazenar esses dados, mas não eram bons em entendê-los. Eles lidavam bem com correspondências exatas. Significado e similaridade eram outra história.
Os vetores ofereceram uma forma prática de fechar essa lacuna. Ao transformar texto, imagens e outros conteúdos em embeddings, a similaridade se tornou algo que os sistemas podiam calcular diretamente. Uma vez que os dados eram representados dessa forma, os bancos de dados deixavam de apenas armazenar registros. Eles podiam recuperar informações com base no significado, não apenas em palavras-chave.
Portanto, os bancos de dados vetoriais ficam entre modelos poderosos e dados confusos do mundo real, tornando informações não estruturadas pesquisáveis, comparáveis e utilizáveis em escala.
Então, como a busca vetorial deu o salto da pesquisa para a produção — e para onde os bancos de dados vetoriais estão indo em seguida? Em um episódio recente do podcast em inglês Innovator Coffee, James Luan, VP de Engenharia da Zilliz, compartilhou sua perspectiva, com base na história de fundação da empresa, no pensamento por trás do Milvus, o banco de dados vetorial de código aberto da Zilliz, e nos princípios de design que moldaram o sistema.
De Algoritmos à Produção: A Evolução dos Bancos de Dados Vetoriais
Olhando para os primeiros dias antes de a busca vetorial estar pronta para produção, James Luan observa que a maior parte do progresso inicial aconteceu dentro de grandes empresas de tecnologia. Projetos como o FAISS da Meta estabeleceram a base técnica, mas eram bibliotecas — não bancos de dados. Sistemas semelhantes de busca vetorial existiam em empresas como Microsoft e Spotify, normalmente criados para uso interno e adaptados a cargas de trabalho específicas. Essas ferramentas eram eficazes, mas nunca foram projetadas para funcionar como sistemas generalistas e duradouros.
O ponto de virada veio quando a busca vetorial passou da pesquisa para produtos reais. Quando as equipes tentaram implantá-la em produção, os desafios em nível de sistema se tornaram impossíveis de ignorar. Escalabilidade, confiabilidade e operações do dia a dia importavam tanto quanto a qualidade da busca. Caminhos diferentes surgiram. Algumas equipes criaram serviços gerenciados otimizados para inferência online e integração estreita com grandes modelos de linguagem. Outras adotaram uma abordagem de infraestrutura mais ampla, integrando a busca vetorial a data lakes e bancos de dados tradicionais para dar suporte a casos de uso em escala empresarial. Na visão de James, essa divergência é uma etapa natural no surgimento de qualquer nova camada de infraestrutura.
À medida que os grandes modelos de linguagem amadureceram e as aplicações chegaram à produção, o papel dos bancos de dados vetoriais se expandiu rapidamente. Os primeiros casos de uso focavam em recuperação baseada em similaridade — sistemas de recomendação, busca de imagens e correspondência de conteúdo. Nos últimos dois a três anos, Geração Aumentada por Recuperação (RAG) tornou-se o padrão dominante. Em sistemas RAG, os bancos de dados vetoriais fornecem aos modelos contexto relevante e fundamentado, permitindo a recuperação de fatos e ajudando a reduzir alucinações.
Esse papel se torna ainda mais importante em sistemas baseados em agentes. Aqui, bancos de dados vetoriais atuam como memória de longo prazo ou near-line, apoiando raciocínio em múltiplas etapas, compressão de contexto e recuperação multimodal. James resume essa mudança com um princípio simples: menos estrutura, mais inteligência. À medida que as capacidades dos modelos melhoram, pipelines rígidos e rotulagem inicial pesada podem limitar os sistemas. Agentes têm melhor desempenho quando operam em um espaço semântico flexível e decidem dinamicamente como recuperar e combinar informações.
Ao mesmo tempo, James enfatiza que bancos de dados vetoriais não são mágicos. A qualidade da recuperação depende tanto da governança de dados quanto dos algoritmos. Dados bem selecionados e relevantes para o domínio — e avaliação contínua — são essenciais. Modelos de embedding, rerankers e estratégias de recuperação evoluem rapidamente, e equipes que passam tempo demais sem reavaliar sua stack frequentemente ficam para trás.
Olhando além da inferência, James vê bancos de dados vetoriais desempenhando um papel crescente no treinamento e na preparação de dados. À medida que modelos multimodais se tornam mais comuns, a busca vetorial é cada vez mais usada para limpar, deduplicar e curar grandes conjuntos de dados em texto, imagens, vídeo e PDFs. Com o tempo, isso pode convergir com data lakes em uma arquitetura de “vector lake”, conectando o processamento de dados em lote com a inferência online.
Nessa visão de longo prazo, bancos de dados vetoriais deixam de ser apenas mecanismos de recuperação. Eles se tornam uma camada semântica que abrange treinamento, inferência e governança de dados de longo prazo — apoiando todo o ciclo de vida dos sistemas de IA.
Como a Zilliz encontrou sua direção antes de bancos de dados vetoriais se tornarem mainstream
James descreve os primeiros dias da Zilliz como um período de exploração, em vez de clareza imediata. Tanto ele quanto o CEO da empresa vinham de backgrounds em bancos de dados tradicionais, tendo passado anos construindo sistemas transacionais na Oracle. Desde o início, eles sabiam que não queriam construir outro banco de dados convencional — mas qual deveria ser essa alternativa ainda era uma pergunta em aberto.
A primeira tentativa deles foi um banco de dados acelerado por GPU voltado a acelerar o processamento de dados em larga escala por meio de hardware especializado. Tecnicamente, funcionou. Comercialmente, não. GPUs entregavam forte desempenho, mas eram caras, e para a maioria das cargas de trabalho do mundo real a relação custo–desempenho era difícil de justificar. Ao mesmo tempo, sistemas baseados em CPU como ClickHouse estavam melhorando rapidamente, fechando grande parte da lacuna de desempenho por uma fração do custo.
Essa experiência forçou uma reflexão mais profunda. Em vez de perguntar como tornar bancos de dados mais rápidos, a equipe começou a fazer uma pergunta diferente: quais tipos de dados ainda eram mal atendidos? Cargas de trabalho analíticas e transacionais tradicionais já tinham soluções maduras. O que se destacava eram dados não estruturados — texto, imagens e outros conteúdos que os usuários queriam cada vez mais pesquisar e compreender, não apenas armazenar.
O ponto de virada veio por meio do feedback dos usuários. Alguns usuários iniciais perguntaram se o sistema poderia ser usado para acelerar a busca de imagens. Essa pergunta apontou para uma oportunidade mais ampla: similaridade semântica em escala, viabilizada por representações vetoriais. A equipe percebeu que vetores — não GPUs — eram a abstração mais fundamental. A partir desse insight, Milvus nasceu como um projeto open-source focado em busca vetorial em larga escala.
James enfatiza que esse pivot não foi impulsionado por hype. Na época, “bancos de dados vetoriais” não eram uma categoria reconhecida, e até o próprio termo não tinha uma definição clara. O que guiou a decisão foi uma convicção enraizada nos fundamentos de bancos de dados: se a busca semântica fosse realmente importante, ela eventualmente precisaria das mesmas qualidades de qualquer sistema de dados crítico — escalabilidade, estabilidade e confiabilidade.
Essa escolha definiu a direção de tudo o que veio depois. Ao se comprometer cedo com vetores como dados de primeira classe e com bancos de dados como sistemas de longa duração, a Zilliz se posicionou à frente da mudança da indústria em direção a aplicações orientadas por IA — muito antes de essa mudança se tornar amplamente visível.
À medida que os modelos passaram posteriormente da pesquisa para a produção, os bancos de dados vetoriais se tornaram uma parte central das arquiteturas de IA corporativa, dando suporte a pipelines de RAG, sistemas de agentes, recuperação multimodal e deduplicação de dados de treinamento em larga escala. Com essa expansão vieram novas expectativas. Velocidade por si só já não era suficiente. Precisão, escalabilidade, eficiência de custos, governança de dados e segurança passaram a ser preocupações de primeira ordem.
A conclusão de James é que construir sistemas que equilibrem essas demandas não é um problema de otimização de curto prazo. Isso exige paciência, investimento contínuo em engenharia e um compromisso de longo prazo com os fundamentos de infraestrutura — muito além do entusiasmo inicial de uma nova categoria.
Desafios técnicos e soluções: executando bancos de dados vetoriais em produção
À medida que os bancos de dados vetoriais passaram para sistemas reais de IA em produção, James argumenta que o sucesso deixou de estar relacionado ao desempenho bruto. Nas primeiras implantações, a velocidade importava acima de tudo. Mas, quando os grandes modelos de linguagem entraram em cena, o verdadeiro desafio passou a ser construir sistemas capazes de escalar de forma sustentável — equilibrando custo, precisão, confiabilidade e requisitos empresariais ao mesmo tempo.
Custo: indo além da busca apenas em memória
James aponta que os primeiros sistemas de busca vetorial dependiam fortemente de índices em memória. Essa abordagem funcionava quando os conjuntos de dados eram pequenos, mas tornou-se economicamente insustentável à medida que aplicações impulsionadas por LLMs levaram os volumes de dados a níveis muito mais altos. Nessa escala, reduzir a latência em alguns milissegundos importa muito menos do que controlar os custos de armazenamento.
A solução é uma abordagem em camadas para armazenamento e indexação. Ao combinar índices em memória, baseados em disco e em armazenamento de objetos, os bancos de dados vetoriais podem reduzir os custos de armazenamento em até 100 vezes. Essa mudança não apenas otimiza cargas de trabalho existentes — ela torna a recuperação em larga escala viável desde o início.
Escalabilidade e estabilidade em escala real
As pressões de custo rapidamente expõem limites de escalabilidade. James observa que muitas equipes começam com configurações simples, de nó único, porque são fáceis de implantar. Os problemas surgem depois, quando os dados crescem 10 vezes, 50 vezes ou até 100 vezes em pouco tempo.
Essa realidade levou a Zilliz a reconstruir o Milvus como um sistema distribuído e nativo da nuvem. Para James, a escalabilidade é inseparável da estabilidade. Um sistema que consegue escalar, mas falha de forma imprevisível sob cargas de trabalho reais, não é uma infraestrutura utilizável.
Ele enfatiza que a estabilidade costuma ser a parte mais difícil de transformar a busca vetorial em um sistema de produção. Com as ferramentas de código aberto existentes, muitas equipes conseguem criar um protótipo funcional em seis a doze meses. O difícil é fazer esse sistema se comportar de maneira confiável por longos períodos à medida que o volume de dados, os padrões de consulta e a complexidade operacional mudam.
Diferentemente da otimização de desempenho, a estabilidade não vem de uma única inovação. Os ganhos de desempenho são visíveis — benchmarks podem mostrar uma melhoria de 20% ou 30% em poucos meses. A estabilidade é construída de outra forma. Cada correção pode melhorar o SLA em apenas uma fração de ponto percentual, quase imperceptível isoladamente. Mas, por meio de centenas de pequenas melhorias cumulativas, um sistema gradualmente se torna confiável o suficiente para operar como infraestrutura de longo prazo.
Precisão: a recuperação define o teto
Em sistemas de RAG e de agentes, a qualidade da recuperação determina diretamente o desempenho do modelo. Se o sistema não consegue recuperar as informações corretas, o modelo não tem como compensar.
James enfatiza que a precisão não é apenas uma preocupação do banco de dados. Ela depende de toda a pilha de recuperação, incluindo modelos de embedding, estratégias de reranking e qualidade dos dados. Como esses componentes evoluem rapidamente, as equipes precisam reavaliar suas configurações com frequência — muitas vezes a cada poucos meses — para manter a precisão ao longo do tempo.
Como a Zilliz equilibra código aberto e negócios
Nos últimos um ou dois anos, James passou muito tempo pensando sobre um desafio que surge repetidamente para empresas de código aberto: como construir e sustentar uma comunidade ativa de código aberto enquanto também se administra um negócio em crescimento.
Os objetivos de código aberto e comerciais nem sempre se alinham perfeitamente. Projetos de código aberto dependem de abertura, participação de longo prazo e confiança da comunidade, enquanto uma empresa tem metas de receita e restrições de crescimento a gerenciar. Nos últimos anos, esse descompasso tornou-se mais visível em todo o setor. James viu várias equipes colocarem seus projetos de código aberto em modo de manutenção — não porque a tecnologia deixou de funcionar, mas porque o modelo de código aberto tornou-se difícil de sustentar à medida que o negócio escalava.
Mas, para a Zilliz, código aberto não é apenas uma escolha técnica — é também uma decisão de go-to-market. Na prática, funciona de forma muito semelhante a um teste gratuito altamente técnico — uma maneira de desenvolvedores descobrirem, avaliarem e ganharem confiança em um produto por meio do uso real. Isso é especialmente importante para startups, onde conquistar os primeiros usuários é difícil. Para uma equipe orientada por engenharia como a Zilliz, isso se mostrou muito mais eficaz do que abordagens tradicionais de marketing ou lideradas por vendas.
Ao tornar o Milvus open source, a equipe concentrou-se no GitHub como principal ponto de entrada. Desenvolvedores usaram o Milvus em cargas de trabalho reais, compartilharam feedback e contribuíram com melhorias de volta ao projeto. Com o tempo, isso criou um ciclo de feedback estreito entre usuários, a comunidade e o desenvolvimento do produto.
Os resultados foram tangíveis. James observa que cerca de 80% dos clientes do Zilliz Cloud começaram como usuários do projeto de código aberto Milvus. O código aberto também serviu como um poderoso mecanismo de confiança — equipes que haviam executado o Milvus por conta própria sentiam-se muito mais confortáveis em adotar uma oferta comercial posteriormente.
Essa transição, no entanto, nunca foi automática. James deixa claro que código aberto por si só não cria um negócio. Um produto comercial precisa fazer mais do que empacotar código aberto — ele precisa resolver problemas que a versão de código aberto não resolve. Para a Zilliz, esse valor está em operar o Milvus de forma confiável em escala — gerenciando upgrades, lidando com falhas e otimizando continuamente desempenho e custo.
Um resultado importante dessa abordagem é que muitos usuários veem seus custos gerais diminuírem após migrar para a oferta gerenciada. Bancos de dados vetoriais evoluem rapidamente, impulsionados por avanços em indexação, quantização e armazenamento. Com o Zilliz Cloud, os usuários se beneficiam dessas melhorias continuamente, sem assumir por conta própria o ônus de upgrades ou da gestão de infraestrutura.
Na perspectiva de James, esse equilíbrio é o que torna o modelo sustentável. O código aberto cria acesso e confiança. A oferta comercial transforma o progresso de infraestrutura de longo prazo em valor prático — sem minar a abertura que atraiu os usuários desde o início.
Como a Zilliz Se Destaca em um Mercado Saturado
Quando perguntado sobre como está o mercado de bancos de dados vetoriais hoje, James reconhece que a rápida adoção da IA rapidamente tornou o espaço saturado. Ele agora inclui serviços gerenciados, plugins leves e um número crescente de novos entrantes oferecendo recursos de busca vetorial. À primeira vista, muitas dessas soluções parecem semelhantes.
Na visão de James, a verdadeira distinção não é definida por listas de recursos, mas pela profundidade e maturidade dos sistemas subjacentes. Criar uma função básica de busca vetorial é relativamente simples. Construir um sistema que possa operar de forma confiável em escala, por longos períodos de tempo, não é.
Maturidade dos Sistemas
A vantagem da Zilliz começa com a maturidade dos sistemas — especificamente escalabilidade, estabilidade e controle de custos. Desde o início, o Milvus foi projetado como um banco de dados distribuído e nativo de Kubernetes, construído para permanecer estável à medida que os volumes de dados crescem dezenas de vezes. Isso importa porque cargas de trabalho vetoriais raramente escalam de forma suave. Sistemas que funcionam bem em pequena escala muitas vezes têm dificuldades quando o uso se torna contínuo, com picos e imprevisível.
O custo também faz parte dessa maturidade. A Zilliz investiu cedo em indexação multicamadas, combinando memória, disco e armazenamento de objetos. Isso dá aos usuários flexibilidade prática para equilibrar desempenho e custo à medida que as cargas de trabalho evoluem, em vez de prendê-los a um único modo operacional caro.
Prontidão Empresarial
A prontidão empresarial é outro diferencial importante. James contrasta a Zilliz com equipes que vêm principalmente de origens centradas em modelos ou em IA. As raízes da Zilliz na engenharia tradicional de bancos de dados levaram a investimentos iniciais em recursos como controle de acesso, isolamento de dados, implantações BYOC, criptografia e conformidade.
Esses recursos não são opcionais em escala empresarial. São eles que permitem que bancos de dados vetoriais avancem além da experimentação de desenvolvedores e entrem em ambientes regulamentados, como finanças, saúde e grandes organizações com requisitos rigorosos de segurança e governança.
Confiabilidade Operacional
James observa que muitas equipes subestimam a complexidade operacional de longo prazo dos bancos de dados vetoriais. Sistemas iniciais podem funcionar bem em configurações controladas, mas os verdadeiros desafios aparecem quando os dados crescem rapidamente, a concorrência aumenta e as aplicações de IA passam para a produção contínua.
A maioria das empresas não quer investir seu tempo e recursos na operação de infraestrutura complexa, especialmente em áreas altamente especializadas como busca vetorial. É aqui que James vê o papel da Zilliz: assumir o ônus operacional de executar bancos de dados vetoriais em escala, para que as equipes possam se concentrar em criar aplicações em vez de manter infraestrutura. À medida que o mercado amadurece, essa divisão de trabalho se torna cada vez mais importante.
Olhando para o Futuro: A Próxima Fase dos Bancos de Dados Vetoriais
Olhando de três a cinco anos à frente, James adota uma visão pragmática sobre para onde a indústria está caminhando. O crescimento continuará, mas a questão central não será mais se sistemas de bancos de dados vetoriais podem ser construídos — será se eles podem ser operados de forma sustentável. À medida que os modelos crescem e as aplicações de IA avançam mais profundamente para a produção, os volumes de dados se expandirão rapidamente, elevando o patamar para controle de custos, confiabilidade, precisão e segurança.
Nesse ambiente, a capacidade de reduzir custos em uma ordem de magnitude sem comprometer a qualidade da recuperação torna-se um marco definidor. James acredita que é aí que vantagens duradouras são formadas. Os líderes de longo prazo no espaço de bancos de dados vetoriais não serão decididos por recursos ou hype, mas pela disciplina de infraestrutura — a capacidade de operar sistemas em grande escala de forma eficiente, confiável e ao longo do tempo.
Para ouvir a discussão completa, você pode encontrar o episódio no Spotify, Apple Podcasts e YouTube.
Continue lendo
Top 10 Context Engineering Techniques You Should Know for Production RAG
A practical guide to context engineering for production LLM systems, covering RAG, context processing, memory, agents, and multimodal context.
Legal Document Analysis: Harnessing Zilliz Cloud's Semantic Search and RAG for Legal Insights
Enhance legal document analysis with Zilliz Cloud’s Semantic Search and RAG. Improve accuracy, efficiency, and scalability for contracts, case law, and compliance.
Selecting the Right ETL Tools for Unstructured Data to Prepare for AI
Learn the right ETL tools for unstructured data to power AI. Explore key challenges, tool comparisons, and integrations with Milvus for vector search.