Cómo crear una empresa AI-Native

xguru · 2024-07-01T11:22:02+09:00

A principios de la década de 2020, gran parte de la atención se concentró en la IA generativa La discusión se centró principalmente en cómo las herramientas de IA generativa nos moldearían y qué impacto tendrían en la escritura, la programación, la animación y la forma en que consumimos información Sin embargo, casi no se habló de la forma de nuestras herramientas A finales de la década de 1960, los sistemas de información enfrentaron un problema: el proceso de encontrar información relevante se volvió cada vez más costoso debido al enorme volumen de datos En las décadas de 1980 y 1990, las bases de datos relacionales se convirtieron en la solución dominante Ofrecían indexación intuitiva y garantizaban la eficiencia de las consultas Las bases de datos relacionales permitieron representar los datos como un conjunto de tablas con relaciones estructuradas A través de lenguajes de consulta como SQL, hicieron posible una recuperación de datos más rápida A medida que la arquitectura de bases de datos fue evolucionando, ciertas empresas como IBM, Oracle, Sun Microsystems y MongoDB consolidaron su posición en cada mercado emergente Aunque Oracle lideró el mundo de las bases de datos relacionales, la forma en que las personas almacenan y acceden a la información ha seguido cambiando Cada vez que surgía una nueva tarea, las personas ideaban una nueva arquitectura para gestionarla La evolución reciente de las bases de datos surgió de la necesidad de manejar datos no estructurados Durante más de los últimos 50 años, los esquemas se han organizado principalmente en torno a relaciones de datos estructurados Pero cada vez más personas empezaron a necesitar herramientas capaces de manejar mucho mejor la ambigüedad de los datos Así aparecieron las bases de datos vectoriales Los modelos de lenguaje de gran tamaño (LLM) basados en transformadores, como GPT, pueden capturar dependencias de largo alcance en el texto Sin embargo, mantener la comprensión de textos largos puede ser costoso en términos computacionales Las bases de datos vectoriales pueden ampliar la ventana de contexto de estos modelos Aunque las bases de datos vectoriales pueden ser potentes en casos de uso de IA, siguen siendo una infraestructura tonta que opera a partir de entradas y salidas Carecen de la capacidad de comprender o interpretar los datos Solo funcionan como un repositorio que almacena y recupera datos según se le indique, sin inteligencia intrínseca ni conciencia del contexto Con el lanzamiento de GPT-3 en 2020, la IA pudo empezar a usarse cada vez más como núcleo, y no como un apéndice, de los productos empresariales La arquitectura de transformadores, el aumento del volumen de datos y las mejoras de rendimiento sentaron las bases para desarrollar productos impulsados por IA A medida que aumentan y escalan las empresas AI-Native, también crece la necesidad de herramientas que respalden casos de uso basados en IA La primera ola de empresas centradas en IA se enfocó principalmente en la inferencia usando modelos existentes Pero gracias a modelos con mejor rendimiento —en especial modelos de código abierto fácilmente accesibles—, las empresas ahora pueden desarrollar con mayor profundidad sus capacidades como negocios basados en IA Esta escalabilidad está abriendo un mundo de oportunidades sobre cómo podría verse un stack tecnológico basado en IA Las herramientas que nos moldean (The Tools that Shape Us) En 1967, John M. Culkin, amigo de Marshall McLuhan, dijo: "Nosotros creamos las herramientas y luego las herramientas nos crean a nosotros" Crear tecnología no es diferente La infraestructura que usamos para crear software ha evolucionado constantemente para ajustarse a nuestras necesidades de desarrollo y, después, lo que construimos queda moldeado por la infraestructura que establecimos A principios de la década de 2020, gran parte de la atención se concentró en la IA generativa En particular, el foco estuvo en los resultados: el texto o código generado, las imágenes renderizadas, los deepfakes producidos y la música sintetizada La discusión se centró principalmente en cómo estas herramientas nos moldearían y qué impacto tendrían en la escritura, la programación, la animación y la forma en que consumimos información La gente debatía el rendimiento comparado entre modelos de lenguaje de gran tamaño abiertos y propietarios, los riesgos de las alucinaciones, el debate de plataforma versus funcionalidad y el debate entre empresas establecidas y startups Sin embargo, casi no se habló de la forma de nuestras herramientas En el fondo, la manera en que construimos tecnología ha estado determinada por la infraestructura preparada para construirla La expansión del SaaS fue acelerada por internet, la universalización de los smartphones hizo posible el desarrollo móvil y la computación en la nube impulsó la escalabilidad de generaciones de aplicaciones La ubicuidad de la IA en las aplicaciones depende de la computación, de las capacidades de los modelos y de cómo esos modelos se orquestan dentro de los casos de uso empresariales Este artículo se centrará en el elemento de orquestación Uno de los elementos clave para orquestar cualquier caso de uso de IA es la base de datos de la empresa El lugar donde se almacenan, manipulan e invocan los datos es una pieza importante del rompecabezas Pero, como veremos, la historia de las bases de datos ha sido en gran medida la historia de una infraestructura tonta Para maximizar la utilidad de la IA, habrá que diseñar las bases de datos para que formen parte de la ecuación generativa Una base para los datos (A Base For Data) En mayo de 1959, se convocó por primera vez CODASYL (Conference on Data Systems Languages) con el objetivo de crear un "lenguaje de propósito general para construir aplicaciones de negocio" A finales de la década de 1960, los sistemas de información enfrentaban el problema de que, debido al enorme volumen de datos, el proceso de recuperar información relevante se volvía cada vez más costoso El uso de computadoras mainframe generalmente llevó a un aumento en el costo de MIPS (millones de instrucciones por segundo), ya que el mayor aprovechamiento del mainframe implicaba costos de actualización necesarios para el mantenimiento de aplicaciones, parches y conservación del rendimiento Debido a la complejidad de la administración de bases de datos, las jerarquías rígidas y el mapeo de estructuras de navegación complejas, las empresas a menudo necesitaban conocimientos técnicos especializados para acceder a la información seleccionada, e incluso algunos desarrolladores tenían que escribir programas completos para acceder a la información relevante En 1970, E.F. Codd publicó "A Relational Model of Data for Large Shared Data Banks", proponiendo un modelo en el que las tablas podían conectarse mediante atributos compartidos (es decir, claves primarias que identifican registros únicos y claves foráneas que establecen relaciones entre tablas) Esto permitió recuperar datos de tablas heterogéneas con una sola consulta La base de datos relacional de Codd, basada en las relaciones entre elementos de datos, permitió una mayor flexibilidad en la manipulación y uso de los datos En 1973, un grupo de programadores del IBM San Jose Research Laboratory inició el proyecto System R para demostrar que un sistema de base de datos relacional podía integrar todas las funciones necesarias para uso en producción y seguir ofreciendo un alto rendimiento Este equipo desarrolló un optimizador basado en costos para mejorar la eficiencia de la base de datos, y los avances derivados de System R llevaron después al lanzamiento de SQL/DS, el primer producto de base de datos relacional de IBM En las décadas de 1980 y 1990, las bases de datos relacionales se convirtieron en la solución dominante Ofrecían indexación intuitiva y garantizaban eficiencia en las consultas Las bases de datos relacionales permitían representar los datos como una colección de tablas con relaciones estructuradas Hacían posible una recuperación de datos más rápida mediante lenguajes de consulta como SQL Las bases de datos relacionales se construyeron bajo la premisa de ejecutarse en una sola máquina Sin embargo, con la adopción masiva de internet en los años 1990 y 2000, el volumen de datos creció enormemente, generando cargas de trabajo demasiado pesadas para una sola computadora Las bases de datos SQL tradicionales estaban diseñadas para ejecutarse en un único servidor, y los usuarios tenían que ampliar el hardware físico según la capacidad de almacenamiento, lo que resultó muy costoso para las empresas que operaban cargas de trabajo más grandes En la década de 2010, los datos y usuarios para OLTP (procesamiento de transacciones en línea) crecieron exponencialmente, lo que llevó a un aumento generalizado de bases de datos distribuidas, data warehouses y OLAP (procesamiento analítico en línea) Las bases de datos relacionales y SQL dejaron de ajustarse a la escala y complejidad requeridas por las aplicaciones, y las bases de datos NoSQL surgieron como una forma de mejorar el rendimiento, aunque sacrificando capacidades ACID Las bases de datos relacionales podían almacenar y manipular datos estructurados, pero mantener las relaciones entre datos era difícil al considerar la sobrecarga de los joins y el costo de las operaciones CRUD Las bases de datos relacionales eran adecuadas para tratar datos relacionales con requisitos lógicos o discretos, pero por lo general estaban alineadas con sistemas heredados construidos específicamente para estructuras relacionales NoSQL surgió como un medio para manejar big data no estructurado, ofreciendo persistencia de datos a los desarrolladores mediante un enfoque no relacional En lugar de usar SQL como lenguaje de consulta principal, NoSQL ofrece acceso a través de APIs, garantizando mayor escalabilidad, computación distribuida, reducción de costos y flexibilidad de esquema Las bases de datos NoSQL funcionan con arquitecturas eficientes que pueden escalar horizontalmente, por lo que para aumentar la capacidad de almacenamiento o cómputo solo se necesitan más servidores o instancias en la nube Para las empresas con cargas de trabajo orientadas al procesamiento o análisis más rápido de datos no estructurados, las bases de datos NoSQL fueron la opción preferida La guerra OG de las bases de datos A medida que evolucionó la arquitectura de bases de datos, ciertas empresas consolidaron su posición en cada mercado emergente Poco después de que IBM lanzara System R, Larry Ellison, de 33 años, leyó el mismo artículo de Codd sobre bases de datos relacionales Ellison y sus dos cofundadores intentaron crear una empresa compatible con System R, pero IBM lo hizo muy difícil Como resultado, el trío construyó su negocio alrededor de un nuevo producto principal de base de datos: Oracle Databases Desde entonces, la base de datos de Oracle se convirtió en el producto líder y, a mayo de 2024, tiene una cuota de mercado de aproximadamente 28.7% En los años previos al IPO de Oracle en 1986, otra empresa ingresó al espacio de las bases de datos Sun Microsystems comenzó en 1982 vendiendo diversos componentes de computadora, pero se hizo famosa por sus contribuciones como el lenguaje de programación Java, Network File System y más Lo importante es que en 2008 Sun Microsystems adquirió MySQL, un sistema de gestión de bases de datos de código abierto Apenas dos años después, Oracle adquirió Sun Microsystems, incluyendo MySQL Casi 15 años después, a mayo de 2024, las bases de datos líderes son Oracle (28.7% de cuota de mercado) y MySQL (aproximadamente 17.3%) Aunque Oracle lideró el mundo de las bases de datos relacionales, la forma en que la gente almacena y accede a la información siguió cambiando Cada vez que surgía un nuevo tipo de trabajo, las personas ideaban una nueva arquitectura para gestionarlo Desde document stores como MongoDB (2007) y Databricks (2013), hasta bases de datos de series temporales como InfluxDB (2013) y Prometheus (2012), y bases de datos de grafos como Neo4j (2007) y Cosmos (2017), la lista de bases de datos especializadas sigue creciendo A medida que la popularidad de las bases de datos relacionales fue disminuyendo de forma constante, surgieron diversas soluciones para estas nuevas necesidades de nicho La evolución más reciente de las bases de datos surgió de la necesidad de manejar datos no estructurados Durante más de 50 años, los esquemas se organizaron principalmente en torno a relaciones de datos estructurados Pero cada vez más personas comenzaron a necesitar herramientas capaces de manejar mucho mejor la ambigüedad de los datos Así surgieron las bases de datos vectoriales El auge de las bases de datos vectoriales Con la amplia expansión de los modelos de lenguaje grandes (LLM) y la IA generativa, las bases de datos vectoriales han surgido como una herramienta capaz de procesar datos multimodales no estructurados Mientras que las bases de datos relacionales tradicionales (Postgres, MySQL) son las más adecuadas para esquemas estructurados, las bases de datos vectoriales son apropiadas para almacenar y consultar embeddings vectoriales (representaciones numéricas de datos que contienen significado en relación con los pesos de un modelo de lenguaje) En lugar de las filas y columnas que se usan comúnmente en las bases de datos relacionales, las bases de datos vectoriales representan los datos como puntos en un espacio multidimensional y hacen coincidencias basadas en similitud, no en valores exactos Según el modelo de embedding, los datos pueden representarse en distintos espacios vectoriales y con diversas dimensiones Los embeddings vectoriales capturan el significado de los puntos de datos, lo que permite recuperar objetos similares buscando los objetos más cercanos en una base de datos vectorial Por ejemplo, Word2Vec mapea palabras a vectores, lo que ayuda a capturar significado, similitud semántica y relaciones contextuales con otros textos Este algoritmo usa una red neuronal poco profunda para derivar el significado de una palabra específica a partir de un corpus de texto más amplio e identificar sinónimos mediante regresión logística También existen métodos como la descomposición en valores singulares (SVD) y el análisis de componentes principales (PCA), que ayudan a extraer embeddings sin depender de redes neuronales profundas Las métricas de distancia ayudan a determinar la "distancia" relativa entre puntos en un espacio vectorial, y entre los métodos comunes están la distancia euclidiana, la distancia Manhattan, la distancia coseno y la similitud de Jaccard K-Nearest Neighbors (KNN) y Approximate Nearest Neighbors (ANN) ayudan a simplificar las búsquedas por similitud para imágenes, video u otras entradas multimodales, mejorando el tiempo de ejecución Las bases de datos especializadas en vectores como Weaviate, Chroma, Qdrant y Pinecone ayudan a los desarrolladores a manejar grandes volúmenes de datos, especialmente al facilitar la búsqueda sobre entradas no estructuradas A diferencia de las bases de datos relacionales tradicionales o las bases de datos NoSQL, las bases de datos vectoriales están diseñadas específicamente para manejar embeddings vectoriales Mientras que las bases de datos tradicionales almacenan los datos como escalares, las bases de datos vectoriales almacenan solo vectores y aprovechan técnicas de indexación como cuantización y clustering para optimizar las operaciones de búsqueda Los LLM basados en transformadores como GPT pueden capturar dependencias de largo alcance en el texto Sin embargo, mantener la comprensión de textos largos puede ser computacionalmente costoso Los LLM más recientes pueden capturar dependencias globales entre pares de tokens a lo largo de la entrada, pero la complejidad temporal y espacial genera problemas de recursos computacionales, lo que limita la longitud del texto de entrada durante el entrenamiento y la ventana de contexto efectiva durante la inferencia En casos multidimensionales, la codificación de posición relativa es difícil de implementar, y la mayoría de los enfoques para codificar posiciones relativas requieren mecanismos robustos de embeddings posicionales que contribuyen a la degradación del rendimiento durante la inferencia Incluso cuando la longitud del texto aumenta, las bases de datos vectoriales pueden ser importantes para actuar como la memoria de largo plazo del modelo El uso de bases de datos vectoriales puede simplificar tareas como la autocompletación de texto o el resumen, donde el contexto completo de la oración puede ser necesario para generar resultados precisos Las bases de datos vectoriales pueden respaldar la generación aumentada por recuperación (RAG), donde pueden usarse para mejorar el prompt que se envía al LLM al incluir contexto adicional junto con la consulta original Como los LLM a menudo dependen de modelos de aprendizaje autosupervisado, con frecuencia tienen dificultades en tareas específicas de dominio que requieren conocimiento especializado o umbrales más altos de precisión RAG puede ayudar a verificar, rastrear o explicar cómo se derivan las respuestas, al tiempo que mitiga las alucinaciones que pueden surgir por falta de contexto en la consulta del problema Los desarrolladores pueden combinar grafos de conocimiento y búsqueda vectorial para ampliar a los LLM más allá de los datos con los que fueron entrenados Herramientas como GraphRAG de Microsoft Research facilitan el aumento de prompts al realizar búsquedas sobre conjuntos de datos privados Como el RAG básico a menudo tiene dificultades para comprender de forma integral conceptos semánticos resumidos en grandes colecciones de datos, herramientas como LlamaIndex y GraphRAG construyen grafos de conocimiento basados en conjuntos de datos privados Según los requisitos o casos de uso específicos, puede ser recomendable que los desarrolladores usen grafos de conocimiento en lugar de RAG Mientras que las bases de datos vectoriales son adecuadas para búsquedas por similitud y funcionan mejor para recuperación de documentos o imágenes y generación de recomendaciones, los grafos de conocimiento son adecuados para el razonamiento (especialmente útiles al recopilar datos, extraer entidades junto con relaciones interconectadas y recorrer esas relaciones) Para aplicaciones que requieren procesamiento de datos en tiempo real o casi real, las bases de datos vectoriales pueden ser preferibles debido a sus consultas de menor latencia Al recopilar y almacenar embeddings, las bases de datos vectoriales facilitan una recuperación más rápida en búsquedas por similitud, haciendo coincidir el prompt de entrada con embeddings similares El ranking por similitud ayuda a respaldar una amplia variedad de tareas de machine learning, desde sistemas de recomendación, búsqueda semántica y reconocimiento de imágenes hasta otras aplicaciones de procesamiento de lenguaje natural Las bases de datos vectoriales cumplen un papel importante en mejorar el rendimiento de los LLM al permitir el almacenamiento y la recuperación eficientes de embeddings vectoriales Esto permite comprender automáticamente el lenguaje natural a gran escala Sin embargo, los embeddings vectoriales representan la innovación N+1 Son un formato de datos previo, como los datos relacionales o de series temporales Los proveedores de bases de datos legacy han comenzado a lanzar capacidades vectoriales, como Atlas Vector Search de MongoDB, la base de datos vectorial de SingleStore y los índices de búsqueda vectorial de Neo4J Aunque las bases de datos vectoriales pueden ser poderosas en casos de uso de IA, siguen siendo infraestructura tonta que opera a partir de entradas y salidas Carecen de la capacidad de comprender o interpretar los datos Simplemente funcionan como repositorios que almacenan y recuperan datos según se les indique, sin inteligencia intrínseca ni conciencia del contexto Para las aplicaciones modernas impulsadas por IA, esto por sí solo no será suficiente Las empresas están construyendo cada vez más con modelos de IA en el núcleo Por lo tanto, si las aplicaciones van a mostrar capacidades cada vez más inteligentes, la infraestructura también necesitará esas mismas capacidades inteligentes Empresas AI-Native de primera generación Desde que el mundo académico comenzó a investigar la inteligencia artificial por primera vez en Dartmouth College en 1956, los casos de uso prácticos han impulsado el avance de este campo Por ejemplo, a finales de la década de 1960, Joseph Weizenbaum creó un programa llamado ELIZA, en el que un enfoque simple de emparejamiento de patrones para simular conversaciones se utilizó para intercambios parecidos a una terapia básica (el primer chatbot) Durante la mayor parte de la historia del uso de IA en casos de negocio, las mejoras en la IA fueron graduales Antes de que el término IA se pusiera de moda, se usaba con más frecuencia el término aprendizaje automático para referirse a la misma tecnología Es decir, “algoritmos estadísticos que pueden aprender de los datos y generalizar a datos no vistos, pudiendo realizar tareas sin instrucciones explícitas” En términos de percepción pública, la IA llegó a un punto de inflexión el 30 de noviembre de 2022, cuando OpenAI lanzó ChatGPT, pero desde una perspectiva técnica el punto de giro había ocurrido mucho antes En noviembre de 2017, el organismo regulador internacional Financial Stability Board (FSB) elaboró un panorama general sobre el impacto del aprendizaje automático en los servicios financieros Las empresas de servicios financieros podían usar cada vez más el aprendizaje automático para realizar tareas como la “evaluación de la calidad crediticia” y así “contribuir a un sistema financiero más eficiente” En otras palabras, podía mejorar la eficiencia, pero no constituía una necesidad existencial Mientras tanto, el aprendizaje automático seguía mejorando, y en mayo de 2018 OpenAI publicó una investigación sobre la historia del cómputo necesario para entrenar modelos de gran escala, mostrando que desde 2012 se había duplicado cada 3.4 meses, lo que implicaba un aumento de 300 mil veces en cómputo Al mes siguiente, en junio de 2018, OpenAI publicó la primera presentación del modelo GPT Se estaba formando un debate entre dos bandos Por un lado, muchos creían que el crecimiento continuo de modelos cada vez más grandes tendría rendimientos decrecientes El otro bando, en el que estaba OpenAI, creía que el rendimiento seguiría mejorando a medida que aumentara la escala En enero de 2020, Jared Kaplan, investigador de OpenAI y profesor de Johns Hopkins University, junto con otros autores, publicó “Scaling Laws for Neural Language Models”, donde se afirmaba lo siguiente: “El desempeño del modelado de lenguaje mejora de forma fluida y predecible a medida que se escalan adecuadamente el tamaño del modelo, los datos y el cómputo. Esperamos que modelos de lenguaje más grandes funcionen mejor y tengan una mayor eficiencia de muestra que los modelos actuales.” En mayo de 2020, OpenAI publicó el paper sobre GPT-3 “Language Models are Few-Shot Learners”, que mostraba una expansión fluida del rendimiento a medida que aumentaba el cómputo OpenAI también descubrió que aumentar la escala mejoraba la capacidad de generalización, y sostuvo que “el escalamiento de modelos de lenguaje grandes mejora considerablemente el desempeño few-shot independiente de la tarea, hasta el punto de en algunos casos competir con enfoques anteriores de fine-tuning de última generación” El investigador independiente Gwern Branwen formuló la hipótesis del escalamiento en una entrada de blog, y dijo lo siguiente: “GPT-3, publicado por OpenAI en mayo de 2020, es la red neuronal más grande entrenada hasta ahora, por más de un orden de magnitud... Contrario a las expectativas de mucha gente (incluyéndome), este enorme aumento de escala siguió mostrando los beneficios del escalamiento tal como OpenAI había predicho, y no chocó con los rendimientos decrecientes o negativos que muchos esperaban.” La sorpresa que sintió Branwen reflejaba un cambio en el panorama La IA ya no tenía que usarse como un apéndice del producto de una empresa, sino que cada vez podía ocupar el núcleo La arquitectura transformer, el mayor volumen de datos y los niveles de rendimiento mejorados sentaron las bases para el desarrollo de productos impulsados por IA Justo después del lanzamiento de GPT-3, en mayo de 2020, empresas como Writer y Jasper crearon productos de copywriting con modelos de IA en el centro del negocio Empresas como Harvey y EvenUp construyeron tecnología legal con la IA en el centro Empresas como DeepScribe y Freed construyeron transcripción médica con la IA en el centro Sin embargo, así como en el pasado los nuevos casos de uso impulsaron la evolución de las bases de datos, el surgimiento de productos impulsados por IA implicó que la infraestructura detrás del stack tecnológico de cada empresa debía cambiar y adaptarse Base de datos AI-Native A medida que aumentan y escalan las empresas impulsadas por IA, también crece la necesidad de herramientas que respalden casos de uso impulsados por IA La primera ola de empresas con la IA en el núcleo se enfocó principalmente en la inferencia usando modelos existentes Contaban con herramientas de flujo de trabajo orientadas a aplicaciones, copywriting, transcripción médica y otros fines El núcleo del producto era el resultado, como texto generado o imágenes generadas por el modelo Después del DevDay de OpenAI en noviembre de 2023, comenzó a circular el meme de “OpenAI mató a mi startup” GPTs especializados o agentes de IA parecían asumir el papel de estas startups tempranas impulsadas por IA, porque se enfocaban en la inferencia sobre modelos existentes OpenAI terminó siendo, accidentalmente, proveedor tanto del modelo como de la aplicación La innovación centrada en las capacidades de los modelos avanzaba tan rápido que empezó a sentirse como una amenaza para las startups Pero, por el contrario, los modelos con mejor rendimiento —en particular los modelos open source de fácil acceso— también permitieron a las empresas desarrollar con más profundidad sus capacidades como negocios impulsados por IA Construir un stack tecnológico impulsado por IA es más que agregar componentes alrededor del modelo Por ejemplo, ¿cómo sería una base de datos construida específicamente para IA? Si la inferencia es el resultado importante, una base de datos AI-native no solo debe almacenar y recuperar datos, sino también ser capaz de tomar instrucciones contextuales sobre qué hacer con los datos que almacena Un ejemplo podría ser la personalización de descripciones de productos para ecommerce Una base de datos vectorial no solo puede almacenar embeddings vectoriales de SKU y descripciones de productos, sino también embeddings sobre personas usuarias Usando todos estos datos contextuales en la base de datos, la infraestructura podría hacer que una consulta sobre la descripción de un producto dispare también una consulta sobre la persona usuaria relevante, y luego aproveche un bucle de retroalimentación generativa para redactar la descripción del producto con base en esa persona usuaria relevante Del mismo modo, el idioma puede usarse como un bucle de retroalimentación generativa Por ejemplo, una persona usuaria podría querer generar descripciones de productos en varios idiomas Se podrían generar descripciones de producto no solo personalizadas para la persona usuaria, sino también traducidas al idioma que haya elegido Este tipo de instrucciones puede integrarse directamente en la base de datos, ya que casos de uso como la IA generativa se están convirtiendo cada vez más en la función central de las aplicaciones Hacer evolucionar la infraestructura para adaptarla a los casos de uso no es algo nuevo En un inicio, los desarrolladores construían aplicaciones en el navegador con JavaScript para hacer que los sitios web fueran interactivos y dinámicos Pero cuando se dieron cuenta de que podían llevar eso al backend, nació node.js Después, a medida que los desarrolladores empezaron a crear más aplicaciones móviles, apareció JSON (JavaScript Object Notation), que permitió aplicaciones más dinámicas, reactivas y basadas en datos MongoDB encajó perfectamente en esa ola como una empresa que surgió para responder a necesidades de infraestructura en evolución Con la IA, la historia se está repitiendo A medida que cambian los requisitos, la infraestructura debe evolucionar para satisfacerlos La mayor pregunta será qué tipo de empresas quieren construir las personas, y qué tipo de infraestructura es la más adecuada para esas empresas Como dijo Bob en una entrevista con Matthew Lynley: “Creo firmemente que todas las aplicaciones del futuro incluirán IA. En algunas aplicaciones, la IA estará espolvoreada; en otras, estará en el centro de la aplicación. Si la quitas, deja de existir. Si quieres construir una web app y espolvorearle IA encima, usa MongoDB, sobre todo si ya la estás usando... Si quieres construir una aplicación AI-native, donde la IA es el núcleo de la aplicación, es momento de considerar Weaviate.” En el futuro, las empresas decidirán si construirán productos con la IA como apéndice o, como dijo Bob, como un “sprinkle”, o si será el núcleo del producto Stack tecnológico AI-Native En el caso de las empresas que buscan construir la IA como componente central del producto, es muy probable que la infraestructura existente no sea adecuada Con herramientas legacy, el almacenamiento, la organización y la ejecución de datos se construyen en un silo, mientras que la automatización se construye en otro La desventaja de este enfoque es que se pierde contexto en cosas como los bucles de retroalimentación generativa, que pueden ayudar a informar y mejorar mejor el producto En el caso de las empresas que vienen de un stack «adyacente a la IA», la inferencia de un modelo específico suele estar limitada por la ventana de contexto Algunas creen que, si aumenta la capacidad de una ventana de contexto determinada, esta podría reemplazar a las bases de datos vectoriales Sin embargo, es más probable que sea cierta la situación opuesta: que las bases de datos vectoriales evolucionen para reemplazar a la ventana de contexto Los embeddings vectoriales son muy importantes para los modelos generativos, y la infraestructura para resultados generativos debe tratar a los embeddings vectoriales como ciudadanos de primera clase En lugar de simplemente aumentar el tamaño de la ventana de contexto, se puede integrar una base de datos vectorial en el modelo para aportar la comprensión contextual de la ventana de contexto junto con la confiabilidad y escalabilidad de la base de datos En particular, cuanto más general sea el modelo, menos probable es que esté hecho a la medida para una tarea específica Las bases de datos vectoriales impulsadas por IA permitirán capacidades más específicas Los modelos de propósito general como GPT-4 fueron construidos para generalizar deliberadamente el conocimiento Si el producto depende de un poco de fine-tuning simple, el modelo base no se convertirá en la parte singularmente valiosa de ese negocio Construir productos impulsados por IA implicará, además de aprovechar el modelo, construir el producto en torno a un stack más estrechamente conectado Este stack ofrecerá la escala de una base de datos y las capacidades de un modelo para crear productos más competentes

(research.contrary.com)

23 puntos por xguru 2024-07-01 | 1 comentarios | Compartir por WhatsApp

A principios de la década de 2020, gran parte de la atención se concentró en la IA generativa
- La discusión se centró principalmente en cómo las herramientas de IA generativa nos moldearían y qué impacto tendrían en la escritura, la programación, la animación y la forma en que consumimos información
- Sin embargo, casi no se habló de la forma de nuestras herramientas
A finales de la década de 1960, los sistemas de información enfrentaron un problema: el proceso de encontrar información relevante se volvió cada vez más costoso debido al enorme volumen de datos
En las décadas de 1980 y 1990, las bases de datos relacionales se convirtieron en la solución dominante
- Ofrecían indexación intuitiva y garantizaban la eficiencia de las consultas
- Las bases de datos relacionales permitieron representar los datos como un conjunto de tablas con relaciones estructuradas
- A través de lenguajes de consulta como SQL, hicieron posible una recuperación de datos más rápida
A medida que la arquitectura de bases de datos fue evolucionando, ciertas empresas como IBM, Oracle, Sun Microsystems y MongoDB consolidaron su posición en cada mercado emergente
Aunque Oracle lideró el mundo de las bases de datos relacionales, la forma en que las personas almacenan y acceden a la información ha seguido cambiando
- Cada vez que surgía una nueva tarea, las personas ideaban una nueva arquitectura para gestionarla
La evolución reciente de las bases de datos surgió de la necesidad de manejar datos no estructurados
- Durante más de los últimos 50 años, los esquemas se han organizado principalmente en torno a relaciones de datos estructurados
- Pero cada vez más personas empezaron a necesitar herramientas capaces de manejar mucho mejor la ambigüedad de los datos
- Así aparecieron las bases de datos vectoriales
Los modelos de lenguaje de gran tamaño (LLM) basados en transformadores, como GPT, pueden capturar dependencias de largo alcance en el texto
- Sin embargo, mantener la comprensión de textos largos puede ser costoso en términos computacionales
- Las bases de datos vectoriales pueden ampliar la ventana de contexto de estos modelos
Aunque las bases de datos vectoriales pueden ser potentes en casos de uso de IA, siguen siendo una infraestructura tonta que opera a partir de entradas y salidas
- Carecen de la capacidad de comprender o interpretar los datos
- Solo funcionan como un repositorio que almacena y recupera datos según se le indique, sin inteligencia intrínseca ni conciencia del contexto
Con el lanzamiento de GPT-3 en 2020, la IA pudo empezar a usarse cada vez más como núcleo, y no como un apéndice, de los productos empresariales
- La arquitectura de transformadores, el aumento del volumen de datos y las mejoras de rendimiento sentaron las bases para desarrollar productos impulsados por IA
A medida que aumentan y escalan las empresas AI-Native, también crece la necesidad de herramientas que respalden casos de uso basados en IA
- La primera ola de empresas centradas en IA se enfocó principalmente en la inferencia usando modelos existentes
Pero gracias a modelos con mejor rendimiento —en especial modelos de código abierto fácilmente accesibles—, las empresas ahora pueden desarrollar con mayor profundidad sus capacidades como negocios basados en IA
- Esta escalabilidad está abriendo un mundo de oportunidades sobre cómo podría verse un stack tecnológico basado en IA

Las herramientas que nos moldean (The Tools that Shape Us)

En 1967, John M. Culkin, amigo de Marshall McLuhan, dijo: "Nosotros creamos las herramientas y luego las herramientas nos crean a nosotros"
- Crear tecnología no es diferente
- La infraestructura que usamos para crear software ha evolucionado constantemente para ajustarse a nuestras necesidades de desarrollo y, después, lo que construimos queda moldeado por la infraestructura que establecimos
A principios de la década de 2020, gran parte de la atención se concentró en la IA generativa
- En particular, el foco estuvo en los resultados: el texto o código generado, las imágenes renderizadas, los deepfakes producidos y la música sintetizada
- La discusión se centró principalmente en cómo estas herramientas nos moldearían y qué impacto tendrían en la escritura, la programación, la animación y la forma en que consumimos información
- La gente debatía el rendimiento comparado entre modelos de lenguaje de gran tamaño abiertos y propietarios, los riesgos de las alucinaciones, el debate de plataforma versus funcionalidad y el debate entre empresas establecidas y startups
Sin embargo, casi no se habló de la forma de nuestras herramientas
- En el fondo, la manera en que construimos tecnología ha estado determinada por la infraestructura preparada para construirla
- La expansión del SaaS fue acelerada por internet, la universalización de los smartphones hizo posible el desarrollo móvil y la computación en la nube impulsó la escalabilidad de generaciones de aplicaciones
La ubicuidad de la IA en las aplicaciones depende de la computación, de las capacidades de los modelos y de cómo esos modelos se orquestan dentro de los casos de uso empresariales
- Este artículo se centrará en el elemento de orquestación
- Uno de los elementos clave para orquestar cualquier caso de uso de IA es la base de datos de la empresa
- El lugar donde se almacenan, manipulan e invocan los datos es una pieza importante del rompecabezas
- Pero, como veremos, la historia de las bases de datos ha sido en gran medida la historia de una infraestructura tonta
- Para maximizar la utilidad de la IA, habrá que diseñar las bases de datos para que formen parte de la ecuación generativa

Una base para los datos (A Base For Data)

En mayo de 1959, se convocó por primera vez CODASYL (Conference on Data Systems Languages) con el objetivo de crear un "lenguaje de propósito general para construir aplicaciones de negocio"
- A finales de la década de 1960, los sistemas de información enfrentaban el problema de que, debido al enorme volumen de datos, el proceso de recuperar información relevante se volvía cada vez más costoso
El uso de computadoras mainframe generalmente llevó a un aumento en el costo de MIPS (millones de instrucciones por segundo), ya que el mayor aprovechamiento del mainframe implicaba costos de actualización necesarios para el mantenimiento de aplicaciones, parches y conservación del rendimiento
- Debido a la complejidad de la administración de bases de datos, las jerarquías rígidas y el mapeo de estructuras de navegación complejas, las empresas a menudo necesitaban conocimientos técnicos especializados para acceder a la información seleccionada, e incluso algunos desarrolladores tenían que escribir programas completos para acceder a la información relevante
En 1970, E.F. Codd publicó "A Relational Model of Data for Large Shared Data Banks", proponiendo un modelo en el que las tablas podían conectarse mediante atributos compartidos (es decir, claves primarias que identifican registros únicos y claves foráneas que establecen relaciones entre tablas)
- Esto permitió recuperar datos de tablas heterogéneas con una sola consulta
- La base de datos relacional de Codd, basada en las relaciones entre elementos de datos, permitió una mayor flexibilidad en la manipulación y uso de los datos
En 1973, un grupo de programadores del IBM San Jose Research Laboratory inició el proyecto System R para demostrar que un sistema de base de datos relacional podía integrar todas las funciones necesarias para uso en producción y seguir ofreciendo un alto rendimiento
- Este equipo desarrolló un optimizador basado en costos para mejorar la eficiencia de la base de datos, y los avances derivados de System R llevaron después al lanzamiento de SQL/DS, el primer producto de base de datos relacional de IBM
En las décadas de 1980 y 1990, las bases de datos relacionales se convirtieron en la solución dominante
- Ofrecían indexación intuitiva y garantizaban eficiencia en las consultas
- Las bases de datos relacionales permitían representar los datos como una colección de tablas con relaciones estructuradas
- Hacían posible una recuperación de datos más rápida mediante lenguajes de consulta como SQL
Las bases de datos relacionales se construyeron bajo la premisa de ejecutarse en una sola máquina
- Sin embargo, con la adopción masiva de internet en los años 1990 y 2000, el volumen de datos creció enormemente, generando cargas de trabajo demasiado pesadas para una sola computadora
- Las bases de datos SQL tradicionales estaban diseñadas para ejecutarse en un único servidor, y los usuarios tenían que ampliar el hardware físico según la capacidad de almacenamiento, lo que resultó muy costoso para las empresas que operaban cargas de trabajo más grandes
En la década de 2010, los datos y usuarios para OLTP (procesamiento de transacciones en línea) crecieron exponencialmente, lo que llevó a un aumento generalizado de bases de datos distribuidas, data warehouses y OLAP (procesamiento analítico en línea)
Las bases de datos relacionales y SQL dejaron de ajustarse a la escala y complejidad requeridas por las aplicaciones, y las bases de datos NoSQL surgieron como una forma de mejorar el rendimiento, aunque sacrificando capacidades ACID
- Las bases de datos relacionales podían almacenar y manipular datos estructurados, pero mantener las relaciones entre datos era difícil al considerar la sobrecarga de los joins y el costo de las operaciones CRUD
- Las bases de datos relacionales eran adecuadas para tratar datos relacionales con requisitos lógicos o discretos, pero por lo general estaban alineadas con sistemas heredados construidos específicamente para estructuras relacionales
- NoSQL surgió como un medio para manejar big data no estructurado, ofreciendo persistencia de datos a los desarrolladores mediante un enfoque no relacional
- En lugar de usar SQL como lenguaje de consulta principal, NoSQL ofrece acceso a través de APIs, garantizando mayor escalabilidad, computación distribuida, reducción de costos y flexibilidad de esquema
- Las bases de datos NoSQL funcionan con arquitecturas eficientes que pueden escalar horizontalmente, por lo que para aumentar la capacidad de almacenamiento o cómputo solo se necesitan más servidores o instancias en la nube
- Para las empresas con cargas de trabajo orientadas al procesamiento o análisis más rápido de datos no estructurados, las bases de datos NoSQL fueron la opción preferida

La guerra OG de las bases de datos

A medida que evolucionó la arquitectura de bases de datos, ciertas empresas consolidaron su posición en cada mercado emergente
- Poco después de que IBM lanzara System R, Larry Ellison, de 33 años, leyó el mismo artículo de Codd sobre bases de datos relacionales
- Ellison y sus dos cofundadores intentaron crear una empresa compatible con System R, pero IBM lo hizo muy difícil
- Como resultado, el trío construyó su negocio alrededor de un nuevo producto principal de base de datos: Oracle Databases
- Desde entonces, la base de datos de Oracle se convirtió en el producto líder y, a mayo de 2024, tiene una cuota de mercado de aproximadamente 28.7%
En los años previos al IPO de Oracle en 1986, otra empresa ingresó al espacio de las bases de datos
- Sun Microsystems comenzó en 1982 vendiendo diversos componentes de computadora, pero se hizo famosa por sus contribuciones como el lenguaje de programación Java, Network File System y más
- Lo importante es que en 2008 Sun Microsystems adquirió MySQL, un sistema de gestión de bases de datos de código abierto
- Apenas dos años después, Oracle adquirió Sun Microsystems, incluyendo MySQL
- Casi 15 años después, a mayo de 2024, las bases de datos líderes son Oracle (28.7% de cuota de mercado) y MySQL (aproximadamente 17.3%)
Aunque Oracle lideró el mundo de las bases de datos relacionales, la forma en que la gente almacena y accede a la información siguió cambiando
- Cada vez que surgía un nuevo tipo de trabajo, las personas ideaban una nueva arquitectura para gestionarlo
- Desde document stores como MongoDB (2007) y Databricks (2013), hasta bases de datos de series temporales como InfluxDB (2013) y Prometheus (2012), y bases de datos de grafos como Neo4j (2007) y Cosmos (2017), la lista de bases de datos especializadas sigue creciendo
- A medida que la popularidad de las bases de datos relacionales fue disminuyendo de forma constante, surgieron diversas soluciones para estas nuevas necesidades de nicho
La evolución más reciente de las bases de datos surgió de la necesidad de manejar datos no estructurados
- Durante más de 50 años, los esquemas se organizaron principalmente en torno a relaciones de datos estructurados
- Pero cada vez más personas comenzaron a necesitar herramientas capaces de manejar mucho mejor la ambigüedad de los datos
- Así surgieron las bases de datos vectoriales

El auge de las bases de datos vectoriales

Con la amplia expansión de los modelos de lenguaje grandes (LLM) y la IA generativa, las bases de datos vectoriales han surgido como una herramienta capaz de procesar datos multimodales no estructurados
- Mientras que las bases de datos relacionales tradicionales (Postgres, MySQL) son las más adecuadas para esquemas estructurados, las bases de datos vectoriales son apropiadas para almacenar y consultar embeddings vectoriales (representaciones numéricas de datos que contienen significado en relación con los pesos de un modelo de lenguaje)
- En lugar de las filas y columnas que se usan comúnmente en las bases de datos relacionales, las bases de datos vectoriales representan los datos como puntos en un espacio multidimensional y hacen coincidencias basadas en similitud, no en valores exactos
Según el modelo de embedding, los datos pueden representarse en distintos espacios vectoriales y con diversas dimensiones
- Los embeddings vectoriales capturan el significado de los puntos de datos, lo que permite recuperar objetos similares buscando los objetos más cercanos en una base de datos vectorial
Por ejemplo, Word2Vec mapea palabras a vectores, lo que ayuda a capturar significado, similitud semántica y relaciones contextuales con otros textos
- Este algoritmo usa una red neuronal poco profunda para derivar el significado de una palabra específica a partir de un corpus de texto más amplio e identificar sinónimos mediante regresión logística
- También existen métodos como la descomposición en valores singulares (SVD) y el análisis de componentes principales (PCA), que ayudan a extraer embeddings sin depender de redes neuronales profundas
Las métricas de distancia ayudan a determinar la "distancia" relativa entre puntos en un espacio vectorial, y entre los métodos comunes están la distancia euclidiana, la distancia Manhattan, la distancia coseno y la similitud de Jaccard
- K-Nearest Neighbors (KNN) y Approximate Nearest Neighbors (ANN) ayudan a simplificar las búsquedas por similitud para imágenes, video u otras entradas multimodales, mejorando el tiempo de ejecución
Las bases de datos especializadas en vectores como Weaviate, Chroma, Qdrant y Pinecone ayudan a los desarrolladores a manejar grandes volúmenes de datos, especialmente al facilitar la búsqueda sobre entradas no estructuradas
- A diferencia de las bases de datos relacionales tradicionales o las bases de datos NoSQL, las bases de datos vectoriales están diseñadas específicamente para manejar embeddings vectoriales
- Mientras que las bases de datos tradicionales almacenan los datos como escalares, las bases de datos vectoriales almacenan solo vectores y aprovechan técnicas de indexación como cuantización y clustering para optimizar las operaciones de búsqueda
Los LLM basados en transformadores como GPT pueden capturar dependencias de largo alcance en el texto
- Sin embargo, mantener la comprensión de textos largos puede ser computacionalmente costoso
- Los LLM más recientes pueden capturar dependencias globales entre pares de tokens a lo largo de la entrada, pero la complejidad temporal y espacial genera problemas de recursos computacionales, lo que limita la longitud del texto de entrada durante el entrenamiento y la ventana de contexto efectiva durante la inferencia
En casos multidimensionales, la codificación de posición relativa es difícil de implementar, y la mayoría de los enfoques para codificar posiciones relativas requieren mecanismos robustos de embeddings posicionales que contribuyen a la degradación del rendimiento durante la inferencia
- Incluso cuando la longitud del texto aumenta, las bases de datos vectoriales pueden ser importantes para actuar como la memoria de largo plazo del modelo
- El uso de bases de datos vectoriales puede simplificar tareas como la autocompletación de texto o el resumen, donde el contexto completo de la oración puede ser necesario para generar resultados precisos
Las bases de datos vectoriales pueden respaldar la generación aumentada por recuperación (RAG), donde pueden usarse para mejorar el prompt que se envía al LLM al incluir contexto adicional junto con la consulta original
- Como los LLM a menudo dependen de modelos de aprendizaje autosupervisado, con frecuencia tienen dificultades en tareas específicas de dominio que requieren conocimiento especializado o umbrales más altos de precisión
- RAG puede ayudar a verificar, rastrear o explicar cómo se derivan las respuestas, al tiempo que mitiga las alucinaciones que pueden surgir por falta de contexto en la consulta del problema
Los desarrolladores pueden combinar grafos de conocimiento y búsqueda vectorial para ampliar a los LLM más allá de los datos con los que fueron entrenados
- Herramientas como GraphRAG de Microsoft Research facilitan el aumento de prompts al realizar búsquedas sobre conjuntos de datos privados
- Como el RAG básico a menudo tiene dificultades para comprender de forma integral conceptos semánticos resumidos en grandes colecciones de datos, herramientas como LlamaIndex y GraphRAG construyen grafos de conocimiento basados en conjuntos de datos privados
Según los requisitos o casos de uso específicos, puede ser recomendable que los desarrolladores usen grafos de conocimiento en lugar de RAG
- Mientras que las bases de datos vectoriales son adecuadas para búsquedas por similitud y funcionan mejor para recuperación de documentos o imágenes y generación de recomendaciones, los grafos de conocimiento son adecuados para el razonamiento (especialmente útiles al recopilar datos, extraer entidades junto con relaciones interconectadas y recorrer esas relaciones)
Para aplicaciones que requieren procesamiento de datos en tiempo real o casi real, las bases de datos vectoriales pueden ser preferibles debido a sus consultas de menor latencia
Al recopilar y almacenar embeddings, las bases de datos vectoriales facilitan una recuperación más rápida en búsquedas por similitud, haciendo coincidir el prompt de entrada con embeddings similares
El ranking por similitud ayuda a respaldar una amplia variedad de tareas de machine learning, desde sistemas de recomendación, búsqueda semántica y reconocimiento de imágenes hasta otras aplicaciones de procesamiento de lenguaje natural
Las bases de datos vectoriales cumplen un papel importante en mejorar el rendimiento de los LLM al permitir el almacenamiento y la recuperación eficientes de embeddings vectoriales
- Esto permite comprender automáticamente el lenguaje natural a gran escala
Sin embargo, los embeddings vectoriales representan la innovación N+1
- Son un formato de datos previo, como los datos relacionales o de series temporales
Los proveedores de bases de datos legacy han comenzado a lanzar capacidades vectoriales, como Atlas Vector Search de MongoDB, la base de datos vectorial de SingleStore y los índices de búsqueda vectorial de Neo4J
Aunque las bases de datos vectoriales pueden ser poderosas en casos de uso de IA, siguen siendo infraestructura tonta que opera a partir de entradas y salidas
- Carecen de la capacidad de comprender o interpretar los datos
- Simplemente funcionan como repositorios que almacenan y recuperan datos según se les indique, sin inteligencia intrínseca ni conciencia del contexto
Para las aplicaciones modernas impulsadas por IA, esto por sí solo no será suficiente
- Las empresas están construyendo cada vez más con modelos de IA en el núcleo
- Por lo tanto, si las aplicaciones van a mostrar capacidades cada vez más inteligentes, la infraestructura también necesitará esas mismas capacidades inteligentes

Empresas AI-Native de primera generación

Desde que el mundo académico comenzó a investigar la inteligencia artificial por primera vez en Dartmouth College en 1956, los casos de uso prácticos han impulsado el avance de este campo
- Por ejemplo, a finales de la década de 1960, Joseph Weizenbaum creó un programa llamado ELIZA, en el que un enfoque simple de emparejamiento de patrones para simular conversaciones se utilizó para intercambios parecidos a una terapia básica (el primer chatbot)
Durante la mayor parte de la historia del uso de IA en casos de negocio, las mejoras en la IA fueron graduales
Antes de que el término IA se pusiera de moda, se usaba con más frecuencia el término aprendizaje automático para referirse a la misma tecnología
- Es decir, “algoritmos estadísticos que pueden aprender de los datos y generalizar a datos no vistos, pudiendo realizar tareas sin instrucciones explícitas”
En términos de percepción pública, la IA llegó a un punto de inflexión el 30 de noviembre de 2022, cuando OpenAI lanzó ChatGPT, pero desde una perspectiva técnica el punto de giro había ocurrido mucho antes
En noviembre de 2017, el organismo regulador internacional Financial Stability Board (FSB) elaboró un panorama general sobre el impacto del aprendizaje automático en los servicios financieros
- Las empresas de servicios financieros podían usar cada vez más el aprendizaje automático para realizar tareas como la “evaluación de la calidad crediticia” y así “contribuir a un sistema financiero más eficiente”
- En otras palabras, podía mejorar la eficiencia, pero no constituía una necesidad existencial
Mientras tanto, el aprendizaje automático seguía mejorando, y en mayo de 2018 OpenAI publicó una investigación sobre la historia del cómputo necesario para entrenar modelos de gran escala, mostrando que desde 2012 se había duplicado cada 3.4 meses, lo que implicaba un aumento de 300 mil veces en cómputo
Al mes siguiente, en junio de 2018, OpenAI publicó la primera presentación del modelo GPT
Se estaba formando un debate entre dos bandos
- Por un lado, muchos creían que el crecimiento continuo de modelos cada vez más grandes tendría rendimientos decrecientes
- El otro bando, en el que estaba OpenAI, creía que el rendimiento seguiría mejorando a medida que aumentara la escala
En enero de 2020, Jared Kaplan, investigador de OpenAI y profesor de Johns Hopkins University, junto con otros autores, publicó “Scaling Laws for Neural Language Models”, donde se afirmaba lo siguiente:
- “El desempeño del modelado de lenguaje mejora de forma fluida y predecible a medida que se escalan adecuadamente el tamaño del modelo, los datos y el cómputo. Esperamos que modelos de lenguaje más grandes funcionen mejor y tengan una mayor eficiencia de muestra que los modelos actuales.”
En mayo de 2020, OpenAI publicó el paper sobre GPT-3 “Language Models are Few-Shot Learners”, que mostraba una expansión fluida del rendimiento a medida que aumentaba el cómputo
OpenAI también descubrió que aumentar la escala mejoraba la capacidad de generalización, y sostuvo que “el escalamiento de modelos de lenguaje grandes mejora considerablemente el desempeño few-shot independiente de la tarea, hasta el punto de en algunos casos competir con enfoques anteriores de fine-tuning de última generación”
El investigador independiente Gwern Branwen formuló la hipótesis del escalamiento en una entrada de blog, y dijo lo siguiente:
- “GPT-3, publicado por OpenAI en mayo de 2020, es la red neuronal más grande entrenada hasta ahora, por más de un orden de magnitud... Contrario a las expectativas de mucha gente (incluyéndome), este enorme aumento de escala siguió mostrando los beneficios del escalamiento tal como OpenAI había predicho, y no chocó con los rendimientos decrecientes o negativos que muchos esperaban.”
La sorpresa que sintió Branwen reflejaba un cambio en el panorama
La IA ya no tenía que usarse como un apéndice del producto de una empresa, sino que cada vez podía ocupar el núcleo
La arquitectura transformer, el mayor volumen de datos y los niveles de rendimiento mejorados sentaron las bases para el desarrollo de productos impulsados por IA
Justo después del lanzamiento de GPT-3, en mayo de 2020, empresas como Writer y Jasper crearon productos de copywriting con modelos de IA en el centro del negocio
Empresas como Harvey y EvenUp construyeron tecnología legal con la IA en el centro
Empresas como DeepScribe y Freed construyeron transcripción médica con la IA en el centro
Sin embargo, así como en el pasado los nuevos casos de uso impulsaron la evolución de las bases de datos, el surgimiento de productos impulsados por IA implicó que la infraestructura detrás del stack tecnológico de cada empresa debía cambiar y adaptarse

Base de datos AI-Native

A medida que aumentan y escalan las empresas impulsadas por IA, también crece la necesidad de herramientas que respalden casos de uso impulsados por IA
La primera ola de empresas con la IA en el núcleo se enfocó principalmente en la inferencia usando modelos existentes
- Contaban con herramientas de flujo de trabajo orientadas a aplicaciones, copywriting, transcripción médica y otros fines
- El núcleo del producto era el resultado, como texto generado o imágenes generadas por el modelo
Después del DevDay de OpenAI en noviembre de 2023, comenzó a circular el meme de “OpenAI mató a mi startup”
- GPTs especializados o agentes de IA parecían asumir el papel de estas startups tempranas impulsadas por IA, porque se enfocaban en la inferencia sobre modelos existentes
- OpenAI terminó siendo, accidentalmente, proveedor tanto del modelo como de la aplicación
La innovación centrada en las capacidades de los modelos avanzaba tan rápido que empezó a sentirse como una amenaza para las startups
Pero, por el contrario, los modelos con mejor rendimiento —en particular los modelos open source de fácil acceso— también permitieron a las empresas desarrollar con más profundidad sus capacidades como negocios impulsados por IA
Construir un stack tecnológico impulsado por IA es más que agregar componentes alrededor del modelo
- Por ejemplo, ¿cómo sería una base de datos construida específicamente para IA?
- Si la inferencia es el resultado importante, una base de datos AI-native no solo debe almacenar y recuperar datos, sino también ser capaz de tomar instrucciones contextuales sobre qué hacer con los datos que almacena
Un ejemplo podría ser la personalización de descripciones de productos para ecommerce
- Una base de datos vectorial no solo puede almacenar embeddings vectoriales de SKU y descripciones de productos, sino también embeddings sobre personas usuarias
- Usando todos estos datos contextuales en la base de datos, la infraestructura podría hacer que una consulta sobre la descripción de un producto dispare también una consulta sobre la persona usuaria relevante, y luego aproveche un bucle de retroalimentación generativa para redactar la descripción del producto con base en esa persona usuaria relevante
Del mismo modo, el idioma puede usarse como un bucle de retroalimentación generativa
- Por ejemplo, una persona usuaria podría querer generar descripciones de productos en varios idiomas
- Se podrían generar descripciones de producto no solo personalizadas para la persona usuaria, sino también traducidas al idioma que haya elegido
- Este tipo de instrucciones puede integrarse directamente en la base de datos, ya que casos de uso como la IA generativa se están convirtiendo cada vez más en la función central de las aplicaciones
Hacer evolucionar la infraestructura para adaptarla a los casos de uso no es algo nuevo
- En un inicio, los desarrolladores construían aplicaciones en el navegador con JavaScript para hacer que los sitios web fueran interactivos y dinámicos
- Pero cuando se dieron cuenta de que podían llevar eso al backend, nació node.js
- Después, a medida que los desarrolladores empezaron a crear más aplicaciones móviles, apareció JSON (JavaScript Object Notation), que permitió aplicaciones más dinámicas, reactivas y basadas en datos
- MongoDB encajó perfectamente en esa ola como una empresa que surgió para responder a necesidades de infraestructura en evolución
Con la IA, la historia se está repitiendo
- A medida que cambian los requisitos, la infraestructura debe evolucionar para satisfacerlos
- La mayor pregunta será qué tipo de empresas quieren construir las personas, y qué tipo de infraestructura es la más adecuada para esas empresas
- Como dijo Bob en una entrevista con Matthew Lynley:
  - “Creo firmemente que todas las aplicaciones del futuro incluirán IA. En algunas aplicaciones, la IA estará espolvoreada; en otras, estará en el centro de la aplicación. Si la quitas, deja de existir. Si quieres construir una web app y espolvorearle IA encima, usa MongoDB, sobre todo si ya la estás usando... Si quieres construir una aplicación AI-native, donde la IA es el núcleo de la aplicación, es momento de considerar Weaviate.”
En el futuro, las empresas decidirán si construirán productos con la IA como apéndice o, como dijo Bob, como un “sprinkle”, o si será el núcleo del producto

Stack tecnológico AI-Native

En el caso de las empresas que buscan construir la IA como componente central del producto, es muy probable que la infraestructura existente no sea adecuada
- Con herramientas legacy, el almacenamiento, la organización y la ejecución de datos se construyen en un silo, mientras que la automatización se construye en otro
- La desventaja de este enfoque es que se pierde contexto en cosas como los bucles de retroalimentación generativa, que pueden ayudar a informar y mejorar mejor el producto
En el caso de las empresas que vienen de un stack «adyacente a la IA», la inferencia de un modelo específico suele estar limitada por la ventana de contexto
- Algunas creen que, si aumenta la capacidad de una ventana de contexto determinada, esta podría reemplazar a las bases de datos vectoriales
- Sin embargo, es más probable que sea cierta la situación opuesta: que las bases de datos vectoriales evolucionen para reemplazar a la ventana de contexto
- Los embeddings vectoriales son muy importantes para los modelos generativos, y la infraestructura para resultados generativos debe tratar a los embeddings vectoriales como ciudadanos de primera clase
En lugar de simplemente aumentar el tamaño de la ventana de contexto, se puede integrar una base de datos vectorial en el modelo para aportar la comprensión contextual de la ventana de contexto junto con la confiabilidad y escalabilidad de la base de datos
- En particular, cuanto más general sea el modelo, menos probable es que esté hecho a la medida para una tarea específica
- Las bases de datos vectoriales impulsadas por IA permitirán capacidades más específicas
Los modelos de propósito general como GPT-4 fueron construidos para generalizar deliberadamente el conocimiento
- Si el producto depende de un poco de fine-tuning simple, el modelo base no se convertirá en la parte singularmente valiosa de ese negocio
- Construir productos impulsados por IA implicará, además de aprovechar el modelo, construir el producto en torno a un stack más estrechamente conectado
- Este stack ofrecerá la escala de una base de datos y las capacidades de un modelo para crear productos más competentes

1 comentarios

savvykang 2024-07-01

Espero que aparezcan más casos de uso para la generación de embeddings vectoriales y el uso de bases de datos vectoriales, para que surja un flujo de trabajo estándar. ¿Habrá que esperar como un año?