A16Z: una arquitectura emergente para aplicaciones de modelos grandes

Nota del editor: la explosión de la inteligencia artificial generativa tiene el potencial de perturbar muchas industrias, una de las cuales es la industria del software. El auge del modelo de lenguaje grande (LLM) ha dado paso a la explosión de aplicaciones relacionadas. Los gigantes tecnológicos y las empresas emergentes han lanzado varias aplicaciones LLM. Entonces, ¿qué tipo de herramientas y patrones de diseño utilizan estas aplicaciones? Este artículo resume. El artículo es de compilación.

Fuente de la imagen: Generada por Unbounded AI

Los modelos de lenguaje grande (LLM) son primitivas nuevas y poderosas para desarrollar software. Pero debido a que LLM es tan nuevo y se comporta de manera tan diferente a los recursos informáticos normales, no siempre es obvio cómo usar LLM.

En este artículo, compartiremos una arquitectura de referencia para la pila de aplicaciones LLM emergente. La arquitectura mostrará los sistemas, herramientas y patrones de diseño más comunes que hemos visto utilizados por las nuevas empresas de inteligencia artificial y las principales empresas de tecnología. Esta pila de tecnología aún es relativamente primitiva y puede sufrir cambios importantes a medida que avanza la tecnología subyacente, pero esperamos que pueda proporcionar una referencia útil para los desarrolladores que trabajan en el desarrollo de LLM en la actualidad.

Este trabajo se basa en conversaciones con fundadores e ingenieros de nuevas empresas de IA. En particular, confiamos en los aportes de personas como Ted Benson, Harrison Chase, Ben Firshman, Ali Ghodsi, Raza Habib, Andrej Karpathy, Greg Kogan, Jerry Liu, Moin Nadeem, Diego Oppenheimer, Shreya Rajpal, Ion Stoica, Dennis Xu, Matei Zaharia y Jared Zoneraich. ¡Gracias por tu ayuda!

Pila de tecnología LLM

La versión actual de la pila de aplicaciones LLM se ve así:

Los cuadros grises son los componentes clave, y los que tienen flechas representan diferentes flujos de datos: la línea punteada negra son los datos de contexto proporcionados por el desarrollador de la aplicación para limitar la salida, la línea continua negra es el aviso y algunos ejemplos de muestra pasados a LLM , y la línea continua azul es la consulta del usuario, la línea continua roja es el resultado devuelto al usuario

A continuación se muestra una lista de enlaces a cada elemento para una referencia rápida:

, herramientas/sistemas comunes para cada componente clave de la pila de aplicaciones

Hay muchas formas de desarrollar con LLM, incluidos modelos de capacitación desde cero, el ajuste fino de modelos de código abierto o el aprovechamiento de las API administradas. La pila de tecnología que presentamos aquí se basa en el aprendizaje en contexto, un patrón de diseño que observamos que la mayoría de los desarrolladores están comenzando a aprovechar (y actualmente solo es posible con modelos base).

La siguiente sección explica brevemente este patrón de diseño.

Patrón de diseño: aprendizaje contextual

La idea central del aprendizaje contextual es aprovechar los LLM listos para usar (es decir, sin ningún tipo de ajuste) y luego controlar su comportamiento a través de sugerencias inteligentes y condicionamiento en datos de "contexto" privados.

Por ejemplo, supongamos que está desarrollando un chatbot para responder preguntas sobre una serie de documentos legales. De la forma más sencilla, puede pegar todos los documentos en el aviso de ChatGPT o GPT-4 y luego hacer preguntas relacionadas. Esto podría funcionar para conjuntos de datos muy pequeños, pero no escala. Los modelos GPT-4 más grandes solo pueden manejar alrededor de 50 páginas de texto de entrada, y el rendimiento (medido por el tiempo de inferencia y la precisión) se degrada severamente cuando se acerca a este llamado límite de ventana de contexto.

El aprendizaje contextual resuelve este problema con un buen truco: en lugar de enviar todos los documentos cada vez que se ingresa un mensaje de LLM, envía solo los más relevantes. ¿Quién ayudará a decidir cuáles son los documentos más relevantes? Lo has adivinado...LLM.

A un nivel muy alto, este flujo de trabajo se puede dividir en tres fases:

• Preprocesamiento/incrustación de datos: esta fase almacena datos privados (documentos legales en este caso) para su posterior recuperación. En general, los documentos se dividen en fragmentos, se pasan al modelo de incrustación y se almacenan en una base de datos especial denominada base de datos vectorial.
• Construcción/recuperación de avisos: cuando un usuario envía una consulta (en este caso, una pregunta legal), la aplicación construye una serie de avisos, que luego se envían al modelo de lenguaje. Las sugerencias compiladas a menudo se combinan con plantillas de sugerencias codificadas por el desarrollador; los ejemplos de resultados válidos se denominan ejemplos de pocas tomas; cualquier información necesaria se recupera a través de una API externa; y un conjunto de documentos relacionados se recupera de una base de datos vectorial.
• Ejecución/inferencia de sugerencias: una vez que se compilan las sugerencias, se envían a LLM previamente capacitados para la inferencia, incluidas las API de modelos patentados, así como modelos de código abierto o autoentrenados. Durante esta fase, algunos desarrolladores también agregan sistemas operativos como registro, almacenamiento en caché y validación.

Estos pueden parecer mucho trabajo, pero por lo general son más fáciles de implementar que las alternativas: entrenar el LLM o ajustar el LLM en sí es realmente más difícil. No necesita un equipo dedicado de ingenieros de aprendizaje automático para realizar el aprendizaje contextual. Tampoco necesita alojar su propia infraestructura ni comprar costosas instancias dedicadas de OpenAI. Este modelo reduce efectivamente los problemas de IA a problemas de ingeniería de datos que la mayoría de las nuevas empresas, así como las grandes corporaciones, ya saben cómo resolver. También tiende a superar el ajuste fino para conjuntos de datos relativamente pequeños, ya que la información específica debe haber ocurrido al menos unas 10 veces en el conjunto de entrenamiento antes de que el LLM pueda ajustarse para recordar información específica, y el aprendizaje contextual también puede incorporar nueva información. casi en tiempo real.

Una de las preguntas más importantes en el aprendizaje contextual es: ¿qué sucede si solo cambiamos el modelo subyacente para aumentar la ventana de contexto? De hecho, es posible, y es un área activa de investigación. Pero esto viene con algunas ventajas y desventajas, principalmente el costo y el tiempo de la inferencia escala cuadráticamente con la longitud de la pista. Hoy en día, incluso el escalado lineal (el mejor resultado teórico) es demasiado costoso para muchas aplicaciones. Con las tarifas actuales de la API, una sola consulta GPT-4 en 10 000 páginas costaría cientos de dólares. Por lo tanto, no prevemos cambios a gran escala en la pila basados en ventanas de contexto extendidas, pero lo explicaremos más adelante.

En el resto de este artículo, recorreremos esta pila de tecnología utilizando el flujo de trabajo anterior como guía.

Procesamiento/incrustación de datos

Procesamiento de datos/parte de incrustación: pase los datos al modelo incrustado a través de la canalización de datos para la vectorización y luego guárdelos en la base de datos de vectores

Los datos de contexto para las aplicaciones LLM incluyen documentos de texto, PDF e incluso formatos estructurados como tablas CSV o SQL. Las soluciones de carga y transformación de datos (ETL) empleadas por los desarrolladores que entrevistamos variaban ampliamente. La mayoría usa herramientas ETL tradicionales, como Databricks o Airflow. Algunos también aprovechan los cargadores de documentos integrados en el marco de orquestación, como LangChain (con tecnología de Unstructed) y LlamaIndex (con tecnología de Llama Hub). Sin embargo, creemos que esta parte de la pila de tecnología está relativamente poco desarrollada y existe la oportunidad de desarrollar una solución de replicación de datos específicamente para aplicaciones LLM.

En cuanto a la incrustación, la mayoría de los desarrolladores usan la API de OpenAI, especialmente el modelo text-incrustación-ada-002. Este modelo es fácil de usar (especialmente si ya está usando otras API de OpenAI), brinda resultados razonablemente buenos y es cada vez más económico. Algunas empresas más grandes también están explorando Cohere, cuyo trabajo de producto se centra más en la integración y tiene un mejor rendimiento en algunos escenarios. Para los desarrolladores que prefieren el código abierto, la biblioteca Sentence Transformers de Hugging Face es el estándar. También es posible crear diferentes tipos de incrustaciones según el caso de uso; esta es una práctica relativamente específica en la actualidad, pero un área de investigación prometedora.

Desde el punto de vista del sistema, la parte más importante de la canalización de preprocesamiento es la base de datos vectorial. Una base de datos de vectores es responsable de almacenar, comparar y recuperar de manera eficiente hasta miles de millones de incrustaciones (también conocidas como vectores). La opción más común que vemos en el mercado es Pinecone. Es el predeterminado, es fácil comenzar porque está completamente alojado en la nube y tiene muchas de las funciones que las grandes empresas necesitan en producción (p. ej., buen rendimiento a escala, inicio de sesión único y SLA de tiempo de actividad).

Sin embargo, también hay una gran cantidad de bases de datos vectoriales disponibles. Los notables incluyen:

• Sistemas de código abierto como Weaviate, Vespa y Qdrant: estos sistemas suelen tener un excelente rendimiento de un solo nodo y se pueden personalizar para aplicaciones específicas, lo que los hace populares entre los equipos de IA experimentados que les gusta desarrollar plataformas personalizadas.
• Faiss et al Bibliotecas de gestión de vectores nativos: estas bibliotecas tienen una amplia experiencia de desarrollador y son fáciles de iniciar para pequeñas aplicaciones y experimentos de desarrollo. Pero es posible que estos no reemplacen necesariamente las bases de datos completas a gran escala.
• Extensiones OLTP como pgvector: ideal para desarrolladores que ven agujeros en cada forma de base de datos e intentan conectarse a Postgres, o empresas que compran la mayor parte de su infraestructura de datos de un único proveedor de nube Buena solución de soporte vectorial. No está claro que el acoplamiento estricto de cargas de trabajo vectoriales versus escalares tenga sentido a largo plazo.

En el futuro, la mayoría de las empresas de bases de datos vectoriales de código abierto están desarrollando productos en la nube. Nuestra investigación muestra que lograr un rendimiento sólido en la nube es un problema muy difícil en el amplio espacio de diseño de posibles casos de uso. Por lo tanto, es posible que el conjunto de opciones no cambie drásticamente a corto plazo, pero sí a largo plazo. La pregunta clave es si las bases de datos vectoriales se consolidarán en torno a uno o dos sistemas populares similares a las bases de datos OLTP y OLAP.

También está la cuestión abierta de cómo evolucionarán las bases de datos de incrustación y de vectores a medida que se expanda la ventana de contexto disponible para la mayoría de los modelos. Fácilmente podría argumentar que la incrustación se vuelve menos importante porque los datos contextuales se pueden poner directamente en el aviso. Sin embargo, los comentarios de expertos en el tema sugieren que ocurre lo contrario: que las canalizaciones integradas pueden volverse más importantes con el tiempo. Las ventanas de contexto grandes son, de hecho, herramientas poderosas, pero también requieren un costo computacional significativo. Por lo tanto, es imperativo hacer un uso efectivo de esta ventana. Es posible que comencemos a ver diferentes tipos de modelos de incrustación que se vuelven populares, entrenando directamente en la relevancia del modelo y surgiendo bases de datos vectoriales diseñadas para habilitar y aprovechar esto.

Compilación rápida y obtención

Pronta creación y obtención

Las estrategias que impulsan LLM e incorporan datos contextuales se están volviendo más sofisticadas y también se utilizan como fuente de diferenciación de productos, y su papel está creciendo en importancia. La mayoría de los desarrolladores inician nuevos proyectos experimentando con sugerencias simples que incluyen instrucciones directas (sugerencias de cero intentos) o resultados que pueden contener algunos ejemplos (sugerencias de pocos intentos). Estas sugerencias generalmente producen buenos resultados, pero no el nivel de precisión requerido para las implementaciones de producción.

El siguiente nivel de trucos de insinuación es basar las respuestas del modelo en alguna fuente de verdad y proporcionar un contexto externo en el que el modelo no fue entrenado. La Guía de ingeniería de señales enumera no menos de una docena (!) de estrategias de señales más avanzadas, incluidas cadenas de pensamiento, conocimiento generativo autoconsistente, árboles de pensamiento, estímulos direccionales y más. Estas estrategias se pueden combinar para admitir diferentes casos de uso de LLM, como preguntas y respuestas de documentos, chatbots, etc.

Aquí es donde entran los marcos de orquestación como LangChain y LlamaIndex. Estos marcos de trabajo abstraen muchos de los detalles del encadenamiento de sugerencias, la interacción con las API externas (incluida la determinación de cuándo se requiere una llamada a la API), la recuperación de datos de contexto de una base de datos vectorial y el mantenimiento de la memoria entre llamadas en varios LLM. También proporcionan plantillas para muchas de las aplicaciones comunes mencionadas anteriormente. Su salida es una sugerencia o una serie de sugerencias enviadas al modelo de lenguaje. Estos marcos son ampliamente utilizados por aficionados y nuevas empresas que buscan desarrollar aplicaciones, siendo LangChain el líder.

LangChain es todavía un proyecto relativamente nuevo (actualmente en la versión 0.0.201), pero ya estamos empezando a ver aplicaciones desarrolladas con él que entran en producción. Algunos desarrolladores, especialmente los primeros en adoptar LLM, prefieren cambiar a Python sin procesar en producción para eliminar dependencias adicionales. Pero esperamos que este enfoque de "hágalo usted mismo" disminuya en la mayoría de los casos de uso, como ha ocurrido con las pilas de aplicaciones web tradicionales.

Los lectores con ojo de águila notarán una entrada de aspecto extraño en el cuadro de diseño: ChatGPT. En circunstancias normales, ChatGPT es una aplicación, no una herramienta para desarrolladores. Pero también se puede acceder como una API. Y, si observa detenidamente, realiza algunas de las mismas funciones que otros marcos de orquestación, como abstraerse de la necesidad de sugerencias personalizadas, mantener el estado, recuperar datos contextuales a través de complementos, API u otras fuentes. Si bien ChatGPT no es un competidor directo de las otras herramientas enumeradas aquí, puede considerarse una solución alternativa y podría terminar siendo una alternativa viable y fácil para la creación rápida.

Sugerencia de ejecución/razonamiento

Sugerencia de ejecución/razonamiento

Hoy, OpenAI es líder en el campo de los modelos de lenguaje. Casi todos los desarrolladores que entrevistamos lanzaron una nueva aplicación LLM utilizando la API de OpenAI, generalmente usan el modelo gpt-4 o gpt-4-32k. Esto proporciona el mejor escenario de caso de uso para el rendimiento de la aplicación y es fácil de usar porque puede usar una amplia gama de dominios de entrada y, a menudo, no requiere ajustes ni alojamiento propio.

Una vez que un proyecto está en producción y comienza a escalar, puede entrar en juego una gama más amplia de opciones. Algunas preguntas comunes que escuchamos incluyen:

• Cambie a gpt-3.5-turbo: esto es aproximadamente 50 veces más barato que GPT-4 y significativamente más rápido. Muchas aplicaciones no necesitan una precisión de nivel GPT-4, pero sí la necesitan para la inferencia de baja latencia y el soporte rentable para usuarios gratuitos. *Experimentado con otros proveedores propietarios (especialmente el modelo Claude de Anthropic): Claude ofrece inferencia rápida, precisión de nivel GPT-3.5, más opciones de personalización para clientes grandes y ventanas de contexto de hasta 100k (aunque descubrimos que la precisión disminuye con el aumento de la longitud de entrada) .
• Clasificar solicitudes parciales para modelos de código abierto: esto es especialmente efectivo para casos de uso B2C de alto volumen como búsqueda o chat, donde las complejidades de las consultas varían ampliamente y los usuarios gratuitos deben recibir un servicio económico:

1. Por lo general, esto tiene más sentido en combinación con el ajuste fino del modelo base de código abierto. No profundizaremos en esta pila de herramientas en este artículo, pero los equipos de ingeniería utilizan cada vez más plataformas como Databricks, Anyscale, Mosaic, Modal y RunPod.

2. Los modelos de código abierto pueden usar múltiples opciones de inferencia, incluida la interfaz API simple de Hugging Face y Replicate; recursos informáticos sin procesar de los principales proveedores de nube; y productos de nube (nube de opinión) con preferencias más claras como las enumeradas anteriormente.

Actualmente, el modelo de código abierto va a la zaga de los productos patentados, pero la brecha está comenzando a cerrarse. El modelo LLaMa de Meta estableció nuevos estándares para la precisión de código abierto y generó una gama de variantes. Dado que LLaMa solo tiene licencia para uso en investigación, muchos proveedores nuevos han comenzado a entrenar modelos base alternativos (por ejemplo, Together, Mosaic, Falcon, Mistral). Meta todavía está discutiendo si lanzar una verdadera versión de código abierto de LLaMa 2.

Cuando (no si) el LLM de código abierto alcanza niveles de precisión comparables a GPT-3.5, esperamos ver que el texto también tenga su propio momento de Difusión estable, con modelos de experimentación, intercambio y ajuste fino a gran escala que entran en producción. Empresas de hospedaje como Replicate han comenzado a agregar herramientas para que estos modelos sean más accesibles para los desarrolladores de software. Los desarrolladores creen cada vez más que los modelos más pequeños y ajustados pueden lograr una precisión de vanguardia para una gama limitada de casos de uso.

La mayoría de los desarrolladores que entrevistamos no tenían un conocimiento profundo de las herramientas operativas de LLM. El almacenamiento en caché es relativamente común (a menudo basado en Redis), ya que mejora el tiempo de respuesta de la aplicación y reduce los costos. Herramientas como Pesos y sesgos con MLflow (portado del aprendizaje automático tradicional) o Capa con Helicone (construido para LLM) también se usan bastante. Estas herramientas pueden registrar, rastrear y evaluar la salida del LLM, a menudo con el fin de mejorar la construcción de puntas, ajustar tuberías o seleccionar modelos. También se están desarrollando muchas herramientas nuevas para validar la salida de LLM (p. ej., Guardrails) o detectar ataques de inyección de pistas (p. ej., Rebuff). La mayoría de estas herramientas operativas alientan a sus propios clientes de Python a realizar llamadas LLM, por lo que será interesante ver cómo estas soluciones coexisten con el tiempo.

Finalmente, la parte estática de la aplicación LLM (es decir, todo lo que no sea el modelo) también debe estar alojado en algún lugar. Con mucho, las soluciones más comunes que hemos visto son opciones estándar como Vercel o los principales proveedores de nube. Sin embargo, están surgiendo dos nuevas categorías. Las empresas emergentes como Steamship brindan alojamiento de extremo a extremo para aplicaciones LLM, incluida la orquestación (LangChain), contexto de datos de múltiples inquilinos, tareas asincrónicas, almacenamiento de vectores y administración de claves. Empresas como Anyscale y Modal permiten a los desarrolladores alojar modelos y código Python en un solo lugar.

¿Qué pasa con los servidores proxy?

Uno de los componentes más importantes que faltan en esta arquitectura de referencia es el marco del agente de inteligencia artificial. AutoGPT se ha descrito como "un intento experimental de código abierto para automatizar completamente GPT-4", y esta primavera se convirtió en el repositorio de Github de más rápido crecimiento en la historia, y casi todos los proyectos o empresas emergentes de IA hoy en día incorporan alguna forma de El agente entra .

La mayoría de los desarrolladores con los que hablamos estaban muy entusiasmados con el potencial de los proxies. El modelo de aprendizaje contextual que describimos en este documento puede abordar de manera efectiva las alucinaciones y los problemas de actualización de datos, lo que respalda mejor las tareas de generación de contenido. Los agentes, por otro lado, brindan un conjunto completamente nuevo de capacidades para las aplicaciones de IA: resuelven problemas complejos, actúan en el mundo externo y aprenden de la experiencia posterior a la implementación. Esto se logra a través de una combinación de razonamiento/planificación avanzados, uso de herramientas y memoria/recurrencia/pensamiento autorreflexivo.

Como tal, los agentes tienen el potencial de convertirse en una parte central de la arquitectura de la aplicación LLM (o incluso hacerse cargo de toda la pila de tecnología, si cree en la autosuperación recursiva). Los marcos existentes como LangChain ya incorporan parte del concepto de proxy. Solo hay un problema: los proxies aún no funcionan. La mayoría de los frameworks de agentes en la actualidad todavía se encuentran en la etapa de prueba de concepto y ofrecen demostraciones increíbles pero no realizan tareas de manera confiable y repetible. Estamos observando de cerca cómo se desarrolla el proxy en el futuro cercano.

Mirando hacia el futuro

Los modelos de IA preentrenados representan el cambio más significativo en la arquitectura de software desde Internet. Permiten a los desarrolladores individuales crear increíbles aplicaciones de IA en días, superando incluso los proyectos de aprendizaje automático supervisados que solían tardar meses en ser desarrollados por grandes equipos.

Las herramientas y patrones que enumeramos aquí pueden ser un punto de partida para integrar LLM, no un estado final. También actualizamos cuando hay cambios importantes (por ejemplo, el cambio a la capacitación de modelos) y publicamos nuevas arquitecturas de referencia donde tiene sentido.