Dissecando a Recuperação Integrada da OpenAI: Revelando Restrições de Armazenamento, Lacunas de Desempenho e Preocupações de Custo
Após os anúncios mais recentes da OpenAI, comecei a questionar se os OpenAI Assistants são adequados para aplicações em nível de produção, com suas limitações, especificamente o limite de 20 arquivos e o preço de US$0,2 por GB por dia. Com isso em mente, escrevi um artigo focado em três tópicos.
US$0,2/GB/dia pela base de conhecimento dos OpenAI Assistants é caro?
Investigando as soluções internas da OpenAI com base nas informações divulgadas por eles.
Em que direção a infraestrutura da base de conhecimento dos AI Assistants deve evoluir?
Observação: O conteúdo a seguir contém alguns cálculos. Você pode percorrer esses cálculos detalhados, ou pode optar por se concentrar nas conclusões destacadas para uma visão geral rápida.
O Custo da Base de Conhecimento dos OpenAI Assistants
Vamos fazer algumas contas simples:
O Office 365 cobra US$6 por TB de dados por mês. O Google Workspace cobra US$8 por TB de dados por mês.
Para os OpenAI Assistants, o custo é 0,2 (US) x 30 (dias) x 1024 (GB) = US\6.144 por TB por mês.
Portanto, adicionar um assistente de IA aos meus documentos de escritório usando os OpenAI Assistants custaria três ordens de grandeza a mais do que um serviço de documentos tradicional (US$6 vs. US$6.144). Isso é caro? Eu digo: "Sim!" isso parece excessivamente alto.
| Serviços | Preços |
|---|---|
| Serviços de documentos tradicionais | $6 /TB |
| OpenAI Assistants | US$6.144/TB |
Vamos também calcular brevemente o custo operacional do lado da OpenAI. A análise a seguir é um pouco complexa, mas a conclusão é simples: Servir 1 GB de documentos exige gerar 1,5 GB de vetores, e o custo de servidor para servir esses vetores é de cerca de US$0,30 por dia. Caro? É uma pechincha comparado ao preço de US$0,20/GB. Interessante!
| Preços | |
|---|---|
| Custo da OpenAI | $0.3/GB por dia |
| Preço da OpenAI | US$0,2/GB por dia |
Aqui está a estimativa:
Considere 1 GB de texto usando o modelo text-embedding-ada-002 da OpenAI para gerar os vetores para recuperação. Para cada 1 KB de texto, esse modelo criará um embedding de 1536 dimensões. Cada dimensão do vetor corresponde a um float32 (portanto, 6KB por vetor), resultando em uma proporção de tamanho de texto de entrada para vetores de saída de 1:6, ou seja, 1 GB de texto corresponde a 6 GB de vetores. Comprimir os vetores por meio de quantização pode alcançar uma taxa de compressão de 4:1, significando que 1 GB de texto corresponde a 1,5 GB de vetores.
Vamos considerar o custo do servidor para servir 1,5 GB de vetores. Optar por uma instância econômica do AWS EC2 custa aproximadamente $0.30 por dia para cada 1,5 GB de memória. Esse cenário é mais do que justo, pois considera apenas o armazenamento e a busca de vetores. Ele não inclui outros elementos como metadados, monitoramento, logs, arquivos de índice e o custo de alta disponibilidade com múltiplas réplicas, todos necessários em ambientes de produção.
Conclusão da Análise de Custos
O novo recurso Assistants da OpenAI está custando à empresa mais dinheiro do que gera, devido ao alto custo de servidor de US$0,3/GB/dia, em comparação com o preço de US$0,2/GB/dia. No entanto, desenvolvedores que desejam usar os Assistants devem pagar mais de 1.000 vezes mais do que pagariam por serviços de documentos tradicionais. Portanto, eles devem gerar valor de negócio três ordens de grandeza maior do que os serviços de documentos convencionais para justificar o custo.
Esse modelo de precificação pode ser justificável para empresas B2C, já que alguns GBs de dados custando dezenas de dólares por mês provavelmente não serão um problema significativo para usuários individuais. No entanto, para empresas B2B que lidam com dados em larga escala, esse custo poderia corroer significativamente a receita do negócio ou até mesmo superar o valor do negócio. Por exemplo, criar um atendimento ao cliente personalizado ou um sistema de busca inteligente para patentes e documentos jurídicos poderia se tornar proibitivamente caro.
Aprofundando na solução da OpenAI
Vamos analisar o esquema atual do OpenAI Assistants. Aqui estão algumas informações publicamente disponíveis:
Um máximo de 20 arquivos por assistant
Um limite de 512MB por arquivo
Uma limitação oculta de 2 milhões de tokens por arquivo, descoberta durante nossos testes
Apenas texto é suportado.
O tráfego do servidor teve um aumento significativo após o OpenAI DevDay. O número de usuários em teste e dos respectivos assistants criados não foi divulgado, mas deve ter sido significativo.
Dissecando o serviço de recuperação da OpenAI
Vamos fazer algumas contas com base nas informações públicas acima.
- Os usuários são limitados a 20 arquivos, cada um com limite de 2 milhões de tokens. Assumindo 200 tokens por chunk (correspondente a um vetor), há um limite de 200.000 vetores por usuário.
| Limite de Arquivos Por Usuário | Número de Tokens | Número de Vetores |
|---|---|---|
| / | 200 | 1 |
| 1 arquivo | 2.000.000 (limite superior) | 10.000 |
| 20 arquivos | 40.000.000 (limite superior) | 200.000 |
- Como a maioria dos usuários não atingirá o limite de 2 milhões de tokens por arquivo, podemos estimar que cada arquivo do usuário conterá uma média de 400.000 tokens, o que se traduz em 2.000 vetores. Considerando o limite superior de 200.000 vetores por usuário e a média de 2.000 vetores por usuário, alcançar uma taxa de overselling de 1000:1 é viável.
| Limite de Arquivos Por Usuário | Número de Tokens | Número de Vetores |
|---|---|---|
| / | 200 | 1 |
| 20 arquivos | 400.000 (em média) | 2.000 |
Além disso, a OpenAI tem uma base substancial de usuários, o que exige que a empresa mantenha um sistema estável e gerencie efetivamente o impacto de quaisquer desastres. Portanto, durante as fases iniciais do desenvolvimento do OpenAI Assistants, é improvável que optem por uma solução de cluster supergrande. Em vez disso, a OpenAI provavelmente criaria um sistema (mostrado abaixo) em que cada grupo de usuários pode compartilhar uma pequena instância de banco de dados vetorial para maior estabilidade.
Uma Arquitetura Simplificada do Recurso de Recuperação do OpenAI Assistants
Vamos supor que cada nó físico tenha 32 GB de memória e seja dividido em quatro Pods. Cada Pod hospeda uma instância separada de banco de dados vetorial, em que um Pod recebe 8 GB de memória. 3 GB são dedicados ao sistema de banco de dados vetorial, e 5 GB são reservados para servir os dados vetoriais dos usuários.
Com um limite de 200.000 vetores por usuário, vetores quantizados e seus índices requerem aproximadamente 500 MB de memória. Portanto, cada Pod pode acomodar dez usuários sem overselling. No entanto, com uma taxa de overselling de 1000:1, um único Pod pode atender até 10.000 usuários (com pelo menos centenas de usuários ativos). Como resultado, um único servidor composto por quatro Pods pode acomodar 40.000 usuários.
Essa arquitetura parece adequada para oferecer suporte a usuários em teste. No entanto, cada nó físico tem o potencial de armazenar até 20 GB de vetores e índices para clientes pagantes, correspondendo a aproximadamente 8 GB de texto original. Em capacidade total, o potencial de receita diária é de modestos $1,6, o que é notavelmente baixo.
Nota: Em casos extremos em que vários usuários com arquivos grandes compartilham um único Pod, podemos mitigar os possíveis desafios por meio de agendamento. Por exemplo, implantar um novo Pod pode migrar eficientemente a carga desses usuários maiores.
Resumo rápido
A arquitetura do serviço de recuperação da OpenAI pode funcionar bem para usuários em teste, mas pode não escalar o suficiente para oferecer suporte a empresas maiores com requisitos de dados mais extensos.
A arquitetura atual impõe limites de armazenamento aos dados dos usuários, reduzindo os lucros potenciais e aumentando os custos.
Além disso, a arquitetura é inadequada para multitenancy na camada de aplicação, pois alguns clientes podem exigir um assistente separado para cada cliente. Veja mais discussões no fórum da OpenAI.
Por que a base de conhecimento dos OpenAI Assistants não é boa o suficiente
Discutimos anteriormente as limitações dos OpenAI Assistants e sua arquitetura. Então, como podemos enfrentar esse desafio e reduzir custos? A solução mais eficaz seria otimizar a arquitetura do serviço.
Antes de nos aprofundarmos na solução, considere fatores cruciais que abrem caminho para uma arquitetura de sistema otimizada.
Uma solução refinada de banco de dados vetorial: armazenamento vetorial híbrido em disco/memória
Bancos de dados vetoriais geralmente carregam vetores e índices na memória para acelerar as respostas às consultas. No entanto, aplicações de Assistant são um caso de uso típico de Retrieval Augmented Generation (RAG) , portanto o gargalo de desempenho está na inferência de grandes modelos de linguagem (LLMs), e não no processo de consulta ao banco de dados vetorial. Nesses casos, respostas ultrarrápidas de busca vetorial não são necessárias. Ao degradar intencionalmente o desempenho do banco de dados vetorial para alinhá-lo aos LLMs, podemos alcançar um equilíbrio entre custo-benefício e capacidades de armazenamento ampliadas. Um caminho promissor é explorar uma solução de banco de dados vetorial baseada em disco, em que apenas dados quentes são carregados na memória. Essa abordagem não apenas reduz substancialmente os custos de hardware, mas também aumenta a capacidade geral de armazenamento do sistema.
Simplificando a recuperação de desastres: agrupamento de dados do sistema
Atualmente, o OpenAI Assistant emprega uma abordagem um tanto quanto de força bruta para recuperação de desastres, atribuindo a cada Pod uma instância separada de banco de dados vetorial e alocando mais de 1/3 da memória em cada Pod para uso do sistema. No entanto, considerando que apenas os dados dos usuários exigem separação, uma estratégia mais sutil envolve agrupar componentes do sistema. Essa abordagem melhora a alta disponibilidade, permitindo que esses componentes funcionem de forma independente, desvinculados de Pods individuais.
Suporte a multi-tenancy para uma base de usuários diversa
O framework arquitetural deve atender perfeitamente tanto a numerosos usuários pequenos quanto a grandes empresas com dados em larga escala. O suporte a multi-tenancy na camada de aplicação é um requisito fundamental para aplicações de Agent, especialmente aquelas com bases de usuários substanciais.
Seguindo essa linha de pensamento, vamos esboçar um diagrama de arquitetura.
A arquitetura otimizada do recurso de recuperação dos OpenAI Assistants
Vamos destacar algumas modificações importantes:
Separação dos componentes de sistema e consulta. Anteriormente co-localizados em cada Pod, os componentes do sistema agora são agrupados de forma independente, reduzindo sua pegada de recursos de 1/3 para menos de 1/10 em comparação com o esquema anterior.
Maior flexibilidade para componentes de consulta: Os componentes de consulta agora podem ser alocados dinamicamente com base em diferentes números de Pods, desfrutando de isolamento físico para escalabilidade independente. O controle sobre o raio de impacto é gerenciado de forma refinada na granularidade dos componentes de consulta. Sua estrutura simplificada aumenta a confiabilidade em comparação com componentes de sistema mais complexos.
Arquitetura híbrida de memória/disco: A introdução de uma arquitetura híbrida de memória/disco, na qual a memória carrega exclusivamente dados quentes, é outra modificação crucial. Essa melhoria permite que a mesma quantidade de memória sirva de 5 a 10 vezes o texto original em comparação com a solução anterior.
Suporte a múltiplas partições para multi-tenancy: A adição de suporte a múltiplas partições atende à multi-tenancy na camada de aplicação. Cada usuário de nível superior agora pode receber uma partição de dados independente, oferecendo uma solução de baixo custo na camada de aplicação. O isolamento físico é obtido atribuindo um componente de consulta por grupo de usuários.
Recalculando o suporte a dados com essa arquitetura, um nó de consulta com 32 GB de memória, aumentado por espaço em disco, agora pode dar suporte de forma eficiente a 320 GB de vetores e índices, equivalentes a 128 GB do texto original do usuário. Os recursos agrupados de componentes do sistema alocados a esses nós de consulta somam 3 GB, fisicamente distintos dos nós de consulta. No total, 35 GB de memória podem acomodar 128 GB de dados do usuário, o que se traduz em aproximadamente 3,6 GB de dados do usuário por GB de memória. Em contraste, o design anterior permitia que 32 GB de memória suportassem 8 GB de dados do usuário, com média de 250 MB de dados do usuário por GB de memória. Isso reflete um notável aumento de 15 vezes na eficiência.
Uma visão geral de bancos de dados vetoriais populares: Milvus, Chroma e Qdrant
Bancos de dados vetoriais desempenham um papel fundamental na otimização da arquitetura dos OpenAI Assistants, tornando a escolha da opção mais robusta primordial. Aqui, analisamos três bancos de dados vetoriais de código aberto proeminentes—Milvus, Chroma e Qdrant—avaliando seus pontos fortes e limitações no aprimoramento da arquitetura dos OpenAI Assistants.
Milvus
Prós: Milvus é o banco de dados vetorial de código aberto mais maduro, amplamente adotado em sistemas distribuídos de grande escala. Recursos notáveis incluem a separação efetiva de componentes de sistema e de consulta, isolamento de componentes de consulta por meio do recurso Resource Group, uma arquitetura híbrida de memória/disco e multi-tenancy no nível da aplicação facilitada por recursos de RBAC e Partition.
Contras: Apesar de seus pontos fortes, o Milvus fica aquém de alcançar isolamento completo de anomalias por meio do isolamento de componentes de consulta baseado em Resource Group. Além disso, introduz algumas dependências de terceiros, como Etcd e MinIO, resultando em custos elevados de implantação e operação.
Chroma
Prós: Chroma surge como um projeto novo e fácil de usar, celebrado por sua simplicidade. Ele atende bem à prototipagem rápida e à iteração rápida de aplicações de IA, ganhando popularidade entre desenvolvedores individuais.
Contras: Chroma se destaca em cenários de menor escala, mas não foi projetado para aplicações empresariais de grande escala. Ele carece de recursos importantes, como implantação distribuída, separação de componentes, arquitetura híbrida de memória/disco e multi-tenancy no nível da aplicação.
Qdrant
Prós: Qdrant, como recém-chegado, oferece suporte para implantação distribuída em pequena escala com um processo de configuração simplificado. Ele também conta com uma arquitetura híbrida de memória/disco, alinhando-o aos requisitos de bancos de dados modernos.
Contras: Atualmente, Qdrant não oferece suporte a recursos cruciais como separação de componentes ou multi-tenancy no nível da aplicação, limitando sua aplicabilidade em certos casos de uso.
Ao avaliar esses bancos de dados vetoriais, torna-se evidente que cada solução traz seus pontos fortes e trade-offs únicos para a discussão, tornando a escolha dependente de requisitos e prioridades específicos no contexto da otimização da arquitetura dos OpenAI Assistants.
Resumo
Nesta publicação do blog, nos aprofundamos nas complexidades dos OpenAI Assistants, explorando sua precificação, arquitetura e possíveis otimizações para eficiência de custos e recursos de armazenamento aprimorados. Uma revelação importante surgiu, pois o custo da infraestrutura de bancos de dados vetoriais influencia significativamente a implantação de bases de conhecimento e aplicações de Agentes.
Ao analisar os custos e lucros da OpenAI relacionados aos Assistants, descobrimos um desequilíbrio notável, com despesas excedendo a receita potencial. Embora isso possa ser justificável durante a fase de teste, acomodando novos clientes e a expansão da comunidade, um equilíbrio mais sustentável é essencial.
A publicação do blog propõe uma solução para otimizar a arquitetura, apresentando a perspectiva de alcançar uma redução de dez vezes nos custos para esses tipos de aplicações em comparação com as soluções existentes. O papel fundamental dos bancos de dados vetoriais nesse processo de otimização é ressaltado, com Milvus surgindo como uma opção particularmente adequada entre as alternativas disponíveis.
No entanto, reconhecendo as limitações inerentes dos bancos de dados vetoriais existentes, esta publicação enfatiza que nenhuma solução única de banco de dados vetorial pode abordar de forma abrangente todos os desafios e atender a todos os requisitos de design para o desenvolvimento iminente da infraestrutura. A escolha dos bancos de dados vetoriais deve ser adaptada a requisitos específicos para navegar efetivamente pelas complexidades da otimização da arquitetura dos OpenAI Assistants.
Continue lendo
Expanding Our Global Reach: Zilliz Cloud Launches in Azure Central India
Zilliz Cloud expands to Azure Central India. This new region helps customers meet compliance, reduce latency, and optimize cloud costs when building AI applications.
Bringing AI to Legal Tech: The Role of Vector Databases in Enhancing LLM Guardrails
Discover how vector databases enhance AI reliability in legal tech, ensuring accurate, compliant, and trustworthy AI-powered legal solutions.
Milvus WebUI: A Visual Management Tool for Your Vector Database
Explore Milvus WebUI to monitor, manage, and optimize your vector database with real-time insights, performance tracking, and system health monitoring.