Análisis de la recuperación integrada de OpenAI: revelando restricciones de almacenamiento, brechas de rendimiento y preocupaciones de costo
Después de los últimos anuncios de OpenAI, empecé a cuestionar si OpenAI Assistants son adecuados para aplicaciones de nivel de producción, con sus limitaciones, específicamente el límite de 20 archivos y el precio de $0.2 por GB al día. Con esto en mente, escribí un artículo centrado en tres temas.
¿Es caro $0.2/GB/día para la base de conocimiento de OpenAI Assistants?
Profundizando en las soluciones internas de OpenAI basadas en la información que han publicado.
¿En qué dirección debería evolucionar la infraestructura de la base de conocimiento de los AI Assistants?
Nota: El siguiente contenido contiene algunos cálculos. Te invitamos a revisar estos cálculos detallados, o puedes optar por centrarte en las conclusiones destacadas para obtener una visión general rápida.
El costo de la base de conocimiento de OpenAI Assistants
Hagamos algunos cálculos simples:
Office 365 cobra $6 por TB de datos al mes. Google Workspace cobra $8 por TB de datos al mes.
Para OpenAI Assistants, el costo es 0.2 ($) x 30 (días) x 1024 (GB) = $6,144 por TB al mes.
Por lo tanto, agregar un asistente de IA a mis documentos de oficina usando OpenAI Assistants costaría tres órdenes de magnitud más que un servicio de documentos tradicional ($6 frente a $6,144). ¿Es caro? Yo digo: "¡Sí!" esto parece excesivamente alto.
| Servicios | Precios |
|---|---|
| Servicios de documentos tradicionales | $6 /TB |
| OpenAI Assistants | $6,144/TB |
Calculemos también brevemente el costo operativo desde el lado de OpenAI. El siguiente análisis es un poco complejo, pero la conclusión es simple: servir 1 GB de documentos requiere generar 1.5 GB de vectores, y el costo del servidor para servir estos vectores es de aproximadamente $0.30 al día. ¿Caro? Es una ganga comparado con el precio de $0.20/GB. ¡Interesante!
| Precios | |
|---|---|
| Costo de OpenAI | $0.3/GB al día |
| Precio de OpenAI | $0.2/GB al día |
Aquí está la estimación:
Considera 1 GB de texto usando el modelo text-embedding-ada-002 de OpenAI para generar los vectores para la recuperación. Por cada 1 KB de texto, este modelo creará un embedding de 1536 dimensiones. Cada dimensión del vector corresponde a un float32 (por lo tanto, 6KB por vector), lo que da como resultado que la proporción de tamaño entre el texto de entrada y los vectores de salida sea de 1:6, es decir, 1 GB de texto corresponde a 6 GB de vectores. Comprimir los vectores mediante cuantización puede lograr una relación de compresión de 4:1, lo que significa que 1 GB de texto corresponde a 1.5 GB de vectores.
Consideremos el costo del servidor para servir 1.5 GB de vectores. Optar por una instancia económica de AWS EC2 cuesta aproximadamente $0.30 diarios por cada 1.5 GB de memoria. Este escenario es más que justo, ya que solo supone el almacenamiento y la búsqueda de vectores. No incluye otros elementos como metadatos, monitoreo, logs, archivos de índice y el costo de alta disponibilidad con múltiples réplicas, todos necesarios en entornos de producción.
Conclusión del análisis de costos
La nueva función Assistants de OpenAI le está costando a la empresa más dinero del que gana debido al alto costo del servidor de $0.3/GB/día, comparado con el precio de $0.2/GB/día. Sin embargo, los desarrolladores que quieran usar los Assistants deben pagar más de 1,000 veces más que por los servicios de documentos tradicionales. Por lo tanto, deben generar un valor de negocio que sea tres órdenes de magnitud superior al de los servicios de documentos convencionales para justificar el costo.
Este modelo de precios puede ser justificable para empresas B2C, ya que es poco probable que unos pocos GB de datos que cuestan decenas de dólares al mes representen un problema significativo para usuarios individuales. Sin embargo, para empresas B2B que trabajan con datos a gran escala, este coste podría erosionar significativamente los ingresos del negocio o incluso superar el valor del negocio. Por ejemplo, crear un servicio de atención al cliente personalizado o un sistema de búsqueda inteligente para patentes y documentos legales podría volverse prohibitivamente caro.
Profundizando en la solución de OpenAI
Analicemos el esquema actual de OpenAI Assistants. Aquí hay información disponible públicamente:
Un máximo de 20 archivos por asistente
Un límite de 512MB por archivo
Una limitación oculta de 2 millones de tokens por archivo, descubierta durante nuestras pruebas
Solo se admite texto.
El tráfico del servidor experimentó un aumento significativo tras OpenAI DevDay. No se ha divulgado el número de usuarios de prueba ni los asistentes correspondientes que se están creando, pero debería haber sido significativo.
Diseccionando el servicio de recuperación de OpenAI
Hagamos algunos cálculos basados en la información pública anterior.
- Los usuarios están limitados a 20 archivos, cada uno con un límite de 2 millones de tokens. Suponiendo 200 tokens por fragmento (correspondiente a un vector), hay un límite de 200,000 vectores por usuario.
| Límite de archivos por usuario | Número de tokens | Número de vectores |
|---|---|---|
| / | 200 | 1 |
| 1 archivo | 2,000,000 (límite superior) | 10,000 |
| 20 archivos | 40,000,000 (límite superior) | 200,000 |
- Dado que la mayoría de los usuarios no alcanzarán el límite de 2 millones de tokens por archivo, podemos estimar que el archivo de cada usuario contendrá una media de 400,000 tokens, lo que se traduce en 2,000 vectores. Considerando el límite superior de 200,000 vectores por usuario y la media de 2,000 vectores por usuario, lograr una proporción de sobreventa de 1000:1 es factible.
| Límite de archivos por usuario | Número de tokens | Número de vectores |
|---|---|---|
| / | 200 | 1 |
| 20 archivos | 400,000 (en promedio) | 2,000 |
Además, OpenAI cuenta con una base de usuarios considerable, lo que exige que la empresa mantenga un sistema estable y gestione eficazmente el impacto de cualquier desastre. Por lo tanto, durante las fases iniciales del desarrollo de OpenAI Assistants, es poco probable que opten por una solución de clúster supergrande. En su lugar, OpenAI probablemente crearía un sistema (mostrado a continuación) en el que cada grupo de usuarios pueda compartir una instancia menor de base de datos vectorial para una mayor estabilidad.
Una arquitectura simplificada de la función de recuperación de OpenAI Assistants
Supongamos que cada nodo físico tiene 32 GB de memoria y está dividido en cuatro Pods. Cada Pod aloja una instancia separada de base de datos vectorial, donde a un Pod se le asignan 8 GB de memoria. 3 GB se dedican al sistema de base de datos vectorial, y 5 GB se reservan para servir datos vectoriales de usuarios.
Con un límite de 200,000 vectores por usuario, los vectores cuantizados y sus índices requieren aproximadamente 500 MB de memoria. Por lo tanto, cada Pod puede alojar a diez usuarios sin sobreventa. Sin embargo, con una proporción de sobreventa de 1000:1, un solo Pod puede servir hasta 10,000 usuarios (con al menos cientos de usuarios activos). Como resultado, un solo servidor compuesto por cuatro Pods puede alojar a 40,000 usuarios.
Esta arquitectura parece adecuada para admitir usuarios de prueba. Sin embargo, cada nodo físico tiene el potencial de almacenar hasta 20 GB de vectores e índices para clientes de pago, lo que corresponde aproximadamente a 8 GB de texto original. A capacidad total, el potencial de ingresos diarios es de unos modestos $1.6, lo cual es notablemente bajo.
Nota: En casos extremos en los que varios usuarios con archivos grandes comparten un solo Pod, podemos mitigar los posibles desafíos mediante la programación. Por ejemplo, desplegar un nuevo Pod puede migrar eficientemente la carga de estos usuarios más grandes.
Resumen rápido
La arquitectura del servicio de recuperación de OpenAI puede funcionar bien para usuarios de prueba, pero puede no escalar lo suficiente como para admitir empresas más grandes con requisitos de datos más extensos.
La arquitectura actual impone límites de almacenamiento a los datos de los usuarios, reduciendo las ganancias potenciales y aumentando los costos.
Además, la arquitectura es inadecuada para la multitenencia en la capa de aplicación, ya que algunos clientes pueden requerir un asistente separado para cada cliente. Consulta más discusiones en el foro de OpenAI.
Por qué la base de conocimiento de OpenAI Assistants no es lo suficientemente buena
Anteriormente discutimos las limitaciones de OpenAI Assistants y su arquitectura. Entonces, ¿cómo podemos abordar este desafío y reducir costos? La solución más efectiva sería optimizar la arquitectura del servicio.
Antes de profundizar en la solución, considera factores cruciales que allanan el camino para una arquitectura de sistema optimizada.
Una solución de base de datos vectorial refinada: almacenamiento vectorial híbrido en disco/memoria
Las bases de datos vectoriales suelen cargar vectores e índices en memoria para agilizar las respuestas a las consultas. Sin embargo, las aplicaciones de Assistant son un caso de uso típico de Generación aumentada por recuperación (RAG) , por lo que el cuello de botella del rendimiento se encuentra en la inferencia de los modelos de lenguaje grandes (LLMs) en lugar de en el proceso de consulta de la base de datos vectorial. En tales casos, no se requieren respuestas de búsqueda vectorial ultrarrápidas. Al degradar intencionalmente el rendimiento de la base de datos vectorial para alinearlo con los LLMs, podemos lograr un equilibrio entre rentabilidad y capacidades de almacenamiento ampliadas. Una vía prometedora es explorar una solución de base de datos vectorial basada en disco, donde solo los datos calientes se cargan en memoria. Este enfoque no solo reduce sustancialmente los costos de hardware, sino que también aumenta la capacidad de almacenamiento general del sistema.
Simplificación de la recuperación ante desastres: agrupación de datos del sistema
Actualmente, OpenAI Assistant emplea un enfoque algo de fuerza bruta para la recuperación ante desastres, asignando a cada Pod una instancia separada de base de datos vectorial y destinando más de 1/3 de la memoria en cada Pod para uso del sistema. Sin embargo, considerando que solo los datos de usuario requieren separación, una estrategia más matizada implica agrupar los componentes del sistema. Este enfoque mejora la alta disponibilidad, permitiendo que estos componentes funcionen de manera independiente, sin estar atados a Pods individuales.
Soporte de multitenencia para una base de usuarios diversa
El marco arquitectónico debe atender sin problemas tanto a numerosos usuarios pequeños como a grandes empresas con datos a gran escala. El soporte de multitenencia en la capa de aplicación es un requisito fundamental para las aplicaciones de agentes, especialmente aquellas con bases de usuarios sustanciales.
Siguiendo esta línea de pensamiento, esbocemos un diagrama de arquitectura.
La arquitectura optimizada de la función de recuperación de OpenAI Assistants
Destaquemos algunas modificaciones clave:
Separación de componentes del sistema y de consulta. Anteriormente coubicados dentro de cada Pod, los componentes del sistema ahora se agrupan de forma independiente, reduciendo su huella de recursos de 1/3 a menos de 1/10 en comparación con el esquema anterior.
Flexibilidad mejorada para los componentes de consulta: Los componentes de consulta ahora pueden asignarse dinámicamente en función de diferentes números de Pods, disfrutando de aislamiento físico para una escalabilidad independiente. El control sobre el radio de impacto se gestiona finamente a nivel de granularidad de los componentes de consulta. Su estructura simplificada mejora la fiabilidad en comparación con componentes de sistema más complejos.
Arquitectura híbrida de memoria/disco: La introducción de una arquitectura híbrida de memoria/disco, donde la memoria carga exclusivamente datos calientes, es otra modificación crucial. Esta mejora permite que la misma cantidad de memoria sirva de 5 a 10 veces el texto original en comparación con la solución anterior.
Soporte de múltiples particiones para multiinquilinato: Añadir soporte de múltiples particiones responde al multiinquilinato en la capa de aplicación. A cada usuario de nivel superior ahora se le puede asignar una partición de datos independiente, proporcionando una solución de bajo costo en la capa de aplicación. El aislamiento físico se logra asignando un componente de consulta por grupo de usuarios.
Al recalcular el soporte de datos con esta arquitectura, un nodo de consulta con 32 GB de memoria, aumentado con espacio en disco, ahora puede soportar eficientemente 320 GB de vectores e índices, equivalentes a 128 GB del texto original del usuario. Los recursos agrupados de los componentes del sistema asignados a estos nodos de consulta ascienden a 3 GB, físicamente distintos de los nodos de consulta. En total, 35 GB de memoria pueden alojar 128 GB de datos de usuario, lo que equivale a aproximadamente 3,6 GB de datos de usuario por GB de memoria. En contraste, el diseño anterior permitía que 32 GB de memoria soportaran 8 GB de datos de usuario, con un promedio de 250 MB de datos de usuario por GB de memoria. Esto refleja un notable aumento de 15 veces en eficiencia.
Una visión general de bases de datos vectoriales populares: Milvus, Chroma y Qdrant
Las bases de datos vectoriales desempeñan un papel fundamental en la optimización de la arquitectura de OpenAI Assistants, por lo que la elección de la opción más robusta es primordial. Aquí profundizamos en tres destacadas bases de datos vectoriales de código abierto—Milvus, Chroma y Qdrant—evaluando sus fortalezas y limitaciones para mejorar la arquitectura de OpenAI Assistants.
Milvus
Ventajas: Milvus es la base de datos vectorial de código abierto más madura, ampliamente adoptada en sistemas distribuidos a gran escala. Entre sus características destacadas se incluyen la separación efectiva de los componentes del sistema y de consulta, el aislamiento de los componentes de consulta mediante la función Resource Group, una arquitectura híbrida de memoria/disco y el multiinquilinato a nivel de aplicación facilitado por las funciones RBAC y Partition.
Desventajas: A pesar de sus fortalezas, Milvus se queda corto a la hora de lograr un aislamiento completo de anomalías mediante el aislamiento de componentes de consulta basado en Resource Group. Además, introduce algunas dependencias de terceros, como Etcd y MinIO, lo que resulta en costos de implementación y operación más elevados.
Chroma
Ventajas: Chroma surge como un proyecto nuevo y fácil de usar, celebrado por su simplicidad. Se adapta bien a la creación rápida de prototipos y a la iteración rápida de aplicaciones de IA, ganando popularidad entre desarrolladores individuales.
Desventajas: Chroma destaca en escenarios de menor escala, pero no está diseñado para aplicaciones empresariales a gran escala. Carece de características clave como despliegue distribuido, separación de componentes, arquitectura híbrida de memoria/disco y multiinquilinato a nivel de aplicación.
Qdrant
Ventajas: Qdrant, como recién llegado, ofrece soporte para despliegue distribuido a pequeña escala con un proceso de configuración simplificado. También cuenta con una arquitectura híbrida de memoria/disco, alineándose con los requisitos de las bases de datos modernas.
Desventajas: Actualmente, Qdrant no admite características cruciales como la separación de componentes o el multiinquilinato a nivel de aplicación, lo que limita su aplicabilidad en ciertos casos de uso.
Al evaluar estas bases de datos vectoriales, resulta evidente que cada solución aporta sus fortalezas y compromisos únicos, lo que hace que la elección dependa de requisitos y prioridades específicos en el contexto de la optimización de la arquitectura de OpenAI Assistants.
Resumen
En esta publicación del blog, profundizamos en las complejidades de OpenAI Assistants, explorando sus precios, arquitectura y posibles optimizaciones para lograr eficiencia de costos y capacidades de almacenamiento mejoradas. Surgió una revelación clave: el costo de la infraestructura de bases de datos vectoriales influye significativamente en el despliegue de bases de conocimiento y aplicaciones de Agent.
Al analizar los costos y beneficios de OpenAI relacionados con Assistants, descubrimos un desequilibrio notable, con gastos que superan los ingresos potenciales. Si bien esto puede ser justificable durante la fase de prueba, para dar cabida a nuevos clientes y a la expansión de la comunidad, es esencial lograr un equilibrio más sostenible.
La publicación del blog propone una solución para optimizar la arquitectura, presentando la perspectiva de lograr una reducción de diez veces en los costos para estos tipos de aplicaciones en comparación con las soluciones existentes. Se subraya el papel fundamental de las bases de datos vectoriales en este proceso de optimización, con Milvus emergiendo como una opción especialmente adecuada entre las alternativas disponibles.
No obstante, reconociendo las limitaciones inherentes de las bases de datos vectoriales existentes, esta publicación enfatiza que ninguna solución única de base de datos vectorial puede abordar de manera integral todos los desafíos y satisfacer todos los requisitos de diseño para el desarrollo inminente de infraestructura. La elección de bases de datos vectoriales debe adaptarse a requisitos específicos para navegar eficazmente las complejidades de la optimización de la arquitectura de OpenAI Assistants.
Sigue leyendo
Why Teams Are Migrating from Weaviate to Zilliz Cloud — and How to Do It Seamlessly
Explore how Milvus scales for large datasets and complex queries with advanced features, and discover how to migrate from Weaviate to Zilliz Cloud.
Context Engineering Strategies for AI Agents: A Developer’s Guide
Learn practical context engineering strategies for AI agents. Explore frameworks, tools, and techniques to improve reliability, efficiency, and cost.
Optimizing Embedding Model Selection with TDA Clustering: A Strategic Guide for Vector Databases
Discover how Topological Data Analysis (TDA) reveals hidden embedding model weaknesses and helps optimize vector database performance.