Arquitecturas emergentes para aplicaciones LLM
Los modelos de lenguaje grande son nuevas y poderosas primitivas para construir software. Pero debido a que son tan nuevos y se comportan de forma tan diferente a los recursos informáticos regulares, no siempre es obvio cómo usarlos.
En este documento, compartimos una arquitectura de referencia para pilas de aplicaciones emergentes de modelos de lenguaje a gran escala. Muestra los sistemas, las herramientas y los patrones de diseño más comunes que vemos en las nuevas empresas de inteligencia artificial y en las empresas de tecnología avanzada . Esta pila aún se encuentra en una etapa muy temprana y puede cambiar significativamente a medida que avanza la tecnología subyacente, pero esperamos que sea una referencia útil para los desarrolladores que trabajan con modelos de lenguaje grandes en la actualidad.
Pila de aplicaciones LLM
Aquí está la vista actual de la pila de aplicaciones LLM:
A continuación hay una lista de enlaces a cada proyecto para una referencia rápida:
| Canalizaciones de datos | Modelos de incrustación | Base de datos vectorial | Patio de juegos | Orquestación | API/complementos | caché LLM |
|---|---|---|---|---|---|---|
| Ladrillos de datos | IA abierta | Piña | IA abierta | cadena larga | serpiente | redis |
| Flujo de aire | Adherirse | tejido | nat.dev | LlamaIndex | wolframio | SQLite |
| no estructurado | cara de abrazo | ChromaDB | Bucle humano | ChatGPT | Zapier | GPTCache |
| pgvector |
| Registro/LLMops | Validación | Alojamiento de aplicaciones | API de LLM (propietarias) | API de LLM (abierto) | Proveedores de la nube | Nubes de opinión |
|---|---|---|---|---|---|---|
| Pesos y sesgos | barandillas | Vercel | IA abierta | cara de abrazo | AWS | Ladrillos de datos |
| MLflow | Rechazo | Buque de vapor | antrópico | Reproducir exactamente | PCG | Cualquierescala |
| PromptLayer | Orientación de Microsoft | Streamlit | Azur | Mosaico | ||
| Helicón | LMQL | Modal | CoreWeave | Modal | ||
| RunPod |
Hay muchas maneras diferentes de construir con LLM, incluida la capacitación de un modelo desde cero , el ajuste fino de un modelo de código abierto o el uso de una API administrada . La pila de tecnología que presentamos aquí se basa en el aprendizaje contextual , que es el patrón de diseño con el que vemos que comienzan la mayoría de los desarrolladores (ahora solo es posible con el modelo base).
Este patrón se explica brevemente en la siguiente sección; los desarrolladores de LLM experimentados pueden omitir esta sección.
Patrones de diseño: aprendizaje en contexto
La idea central del aprendizaje contextual es usar LLM listos para usar (es decir, sin ningún ajuste fino) y luego controlar su comportamiento a través de señales inteligentes y condicionamiento en datos de "contexto" privados .
Por ejemplo, suponga que está creando un chatbot para responder preguntas sobre un conjunto de documentos legales. Adopte un enfoque nativo en el que pegue todos sus documentos en un aviso de ChatGPT o GPT-4 y haga preguntas sobre ellos al final. Esto podría funcionar para conjuntos de datos muy pequeños, pero no escala. El modelo GPT-4 más grande solo puede manejar alrededor de 50 páginas de texto de entrada, y el rendimiento (medido en tiempo de inferencia y precisión) se degrada severamente a medida que se acerca a este límite (llamado ventana de contexto).
Context Learning resuelve este problema con un truco inteligente: en lugar de enviar todos los documentos en cada solicitud de LLM, envía solo los más relevantes. **Los archivos más relevantes fueron identificados con la ayuda de... Lo has adivinado, es LLM.
A un alto nivel, el flujo de trabajo se puede dividir en tres fases:
- Preprocesamiento/incrustación de datos : esta fase implica almacenar datos privados (en nuestro ejemplo, documentos legales) para recuperarlos más tarde. Por lo general, los documentos se dividen en fragmentos, se pasan a través de un modelo de incrustación y luego se almacenan en una
向量数据库base de datos especializada llamada . - 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 para enviar al modelo de lenguaje. Las sugerencias compiladas generalmente combinan una plantilla de sugerencia codificada por el desarrollador, un ejemplo de salida válida llamada ejemplo de pocos programas, cualquier información necesaria recuperada de una API externa y un conjunto de documentos relacionados recuperados de una base de datos vectorial.
- Inferencia/ejecución de solicitud : una vez que se compila una solicitud, se envía a un LLM previamente entrenado para la inferencia, incluidas las API de modelos patentados y los modelos de código abierto o autoentrenados. Algunos desarrolladores también agregan sistemas operativos como registro, almacenamiento en caché y validación en esta etapa.
Esto puede parecer mucho trabajo, pero generalmente es más fácil que las otras opciones: capacitación o ajuste del LLM en sí . No hay necesidad de un equipo dedicado de ingenieros de ML para realizar aprendizaje contextual. Tampoco es necesario alojar su propia infraestructura o 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 empresas emergentes y 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 una pieza particular de información debe aparecer al menos ~ 10 veces en el conjunto de entrenamiento para que el LLM lo recuerde a través del ajuste fino y puede incorporar nuevos datos casi en la realidad. tiempo.
Una de las preguntas más importantes en el aprendizaje contextual es: ¿ qué sucede si simplemente cambiamos el modelo subyacente para aumentar la ventana de contexto ? De hecho, esto es posible y es un área activa de investigación (ver, por ejemplo, el artículo de Hyena o esta publicación reciente ). Pero esto viene con algunas ventajas y desventajas, principalmente que el costo y el tiempo de inferencia escalan cuadráticamente con la longitud de la pista . Hoy en día, incluso el escalado lineal (el mejor resultado teórico) tiene un costo prohibitivo para muchas aplicaciones. Con los precios actuales de la API, una consulta GPT-4 de más de 10 000 páginas costaría cientos de dólares. Por lo tanto, no se esperan cambios a gran escala en la pila basados en una ventana de contexto ampliada , pero hablaremos de esto con más detalle en el cuerpo principal del artículo.
Si desea profundizar en el aprendizaje contextual, hay muchos recursos excelentes en el canon de IA (especialmente la sección " Una guía práctica para la construcción de LLM "). En el resto de este artículo, recorreremos la pila de referencia utilizando el flujo de trabajo anterior como guía.
Preprocesamiento/incrustación de datos
Los datos contextuales para aplicaciones LLM incluyen documentos de texto, PDF e incluso formatos estructurados como CSV o tablas SQL. Las soluciones de carga y transformación de datos para estos datos variaron ampliamente entre los desarrolladores que entrevistamos. La mayoría usa herramientas ETL tradicionales como Databricks o Airflow. Algunos también usan cargadores de documentos integrados en marcos de orquestación, como LangChain (con tecnología de Unstructured) y LlamaIndex (con tecnología de Llama Hub). Sin embargo, creemos que este segmento es relativamente inmaduro y existen oportunidades para crear soluciones de replicación de datos específicamente para aplicaciones LLM .
Para las incrustaciones , la mayoría de los desarrolladores usan la API de OpenAI, especialmente text-embedding-ada-002los modelos. Es fácil de usar (especialmente si ya está usando otras API de OpenAI), funciona razonablemente bien y es cada vez más barato. Algunas empresas más grandes también están explorando Cohere, que tiene un enfoque de producto en la integración y un mejor rendimiento en ciertos escenarios. Para los desarrolladores que prefieren el código abierto, la biblioteca de conversión de oraciones de Hugging Face es un estándar. También es posible crear diferentes tipos de incrustaciones de acuerdo con diferentes casos de uso ; esta es una práctica de nicho hoy en día, 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 . Es responsable de almacenar, comparar y recuperar de manera eficiente hasta miles de millones de incrustaciones (es decir, 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 (por ejemplo, buen rendimiento a escala, SSO y SLA de tiempo de actividad).
Sin embargo, hay un gran número de bases de datos vectoriales disponibles. Cabe resaltar que:
- Sistemas de código abierto como Weaviate, Vespa y Qdrant: a menudo tienen 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 a quienes les gusta construir plataformas personalizadas.
- Bibliotecas nativas de gestión de vectores como Chroma y Faiss: tienen muchos desarrolladores experimentados y son fáciles de desarrollar en pequeñas aplicaciones y experimentos de desarrollo. Pero no reemplazan necesariamente las bases de datos completas a escala.
- Extensiones OLTP como pgvector: una excelente solución de compatibilidad con vectores para desarrolladores que ven cada agujero en forma de base de datos e intentan conectarse a Postgres o comprar la mayor parte de su infraestructura de datos de un único proveedor de nube. No está claro si el acoplamiento estrecho de las cargas de trabajo vectoriales y escalares tiene 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. La 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 OLTP y OLAP .
Otra pregunta abierta es cómo evolucionarán las bases de datos vectoriales y de incrustación a medida que crezca la ventana de contexto disponible para la mayoría de los modelos . Es fácil argumentar que las incrustaciones se volverán menos relevantes, ya que los datos contextuales se pueden colocar directamente en el aviso. Sin embargo, los comentarios de los expertos sobre este tema sugieren que la incorporación de canalizaciones puede volverse más importante con el tiempo. Las ventanas de contexto grandes son una herramienta poderosa, pero también requieren un costo computacional significativo. Por lo tanto, es imperativo utilizarlos de manera efectiva. Es posible que comencemos a ver diferentes tipos de modelos integrados que se vuelven populares, entrenados directamente en la relevancia del modelo y bases de datos vectoriales diseñadas para habilitar y explotar esto.
Rápida construcción/recuperación
Las estrategias para facilitar LLM e integrar datos contextuales como fuente de diferenciación de productos son cada vez más sofisticadas e importantes. La mayoría de los desarrolladores inician nuevos proyectos experimentando con sugerencias simples , ya sean instrucciones directas (sugerencias de cero intentos) o posiblemente algún resultado de muestra (sugerencias de pocos intentos). Estas sugerencias generalmente brindan buenos resultados, pero no el nivel de precisión requerido para las implementaciones de producción .
El siguiente nivel de insinuación, jiu jitsu, tiene como objetivo basar las respuestas del modelo en alguna fuente de verdad y proporcionar el entorno externo en el que el modelo no fue entrenado . La Guía para la ingeniería rápida enumera no menos de 12 estrategias de impulso más avanzadas, que incluyen cadenas de pensamiento , autoconsistencia , conocimiento generado , árboles de pensamiento , estímulos direccionales y más. Estas estrategias también se pueden usar para admitir diferentes casos de uso de LLM, como preguntas y respuestas de documentos, chatbots, etc.
Aquí es donde brillan los marcos de orquestación como LangChain y LlamaIndex . Abstraen muchos detalles de la vinculación de sugerencias, la interfaz con API externas (incluida la determinación de cuándo se requiere una llamada API), la recuperación de datos de contexto de la base de datos vectorial y el mantenimiento de la memoria en múltiples llamadas LLM. También proporcionan plantillas para muchas de las aplicaciones comunes mencionadas anteriormente . Su salida es una sugerencia o secuencia de sugerencias enviadas al modelo de lenguaje. Estos marcos son ampliamente utilizados entre los aficionados y las nuevas empresas que buscan lanzar una aplicación, de las cuales LangChain es 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 creadas 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 bricolaje disminuya con el tiempo en la mayoría de los casos de uso, de manera similar a las pilas de aplicaciones web tradicionales.
Los lectores con ojo de águila notarán una entrada aparentemente extraña en el cuadro de orquestación: ChatGPT. En su encarnación normal, ChatGPT es una aplicación, no una herramienta de desarrollo. 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 y 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 que podría terminar siendo una alternativa viable y fácil a las compilaciones instantáneas.
Inferencia/Ejecución Rápida
Hoy, OpenAI lidera el camino en modelos de lenguaje. Casi todos los desarrolladores que entrevistamos usan la API de OpenAI para iniciar una nueva aplicación LLM, generalmente usando un modelo gpt-4o . gpt-4-32kEsto proporciona un punto óptimo para el rendimiento de la aplicación y es fácil de usar porque opera en una amplia gama de dominios de entrada y, por lo general, no requiere ajustes ni alojamiento propio.
Cuando un proyecto entra en producción y comienza a escalar , entra en juego un conjunto más amplio de opciones. Algunas preguntas comunes que escuchamos incluyen:
- Cambie a gpt-3.5-turbo : es aproximadamente 50 veces más barato y significativamente más rápido que GPT-4. Muchas aplicaciones no requieren precisión de nivel GPT-4, pero sí requieren inferencia de baja latencia y soporte rentable para usuarios gratuitos.
- Experimente con otros proveedores propietarios (en particular, el modelo Claude de Anthropic): Claude ofrece inferencia rápida, precisión de nivel GPT-3.5, opciones personalizadas más grandes y ventanas de contexto de hasta 100k (aunque descubrimos que la precisión se escala con la entrada y disminuye con el aumento de la longitud).
- Descargue algunas solicitudes al modelo de código abierto: esto es especialmente efectivo en casos de uso B2C de alto volumen como búsqueda o chat, donde la complejidad de la consulta varía ampliamente y los usuarios gratuitos deben recibir un servicio económico.
- Esto a menudo tiene más sentido junto con el ajuste fino del modelo base de código abierto. En este artículo, no profundizamos en la pila de herramientas, pero cada vez más equipos de ingeniería usan plataformas como Databricks, Anyscale, Mosaic, Modal y RunPod.
- Hay una variedad de opciones de inferencia para modelos de código abierto, incluidas interfaces API simples para Hugging Face y Replicate; recursos informáticos sin procesar de los principales proveedores de nube; y ofertas de nube más obstinadas como las enumeradas anteriormente.
El modelo de código abierto actualmente va a la zaga de las ofertas propietarias, pero la brecha está comenzando a cerrarse . El modelo LLaMa de Meta estableció un nuevo estándar para la precisión de código abierto y provocó una serie de variantes. Dado que LLaMa tiene licencia solo para uso de investigación, muchos proveedores nuevos han intervenido para entrenar modelos base alternativos (por ejemplo, Together, Mosaic, Falcon, Mistral). Meta también está discutiendo una verdadera versión de código abierto de LLaMa 2.
Cuando (no si) los LLM de código abierto alcanzan niveles de precisión comparables a GPT-3.5, esperamos ver un momento similar de difusión constante de texto, incluida la experimentación a gran escala, el intercambio y la producción de modelos ajustados. Empresas de hospedaje como Replicate ya están agregando 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 en casos de uso limitados .
La mayoría de los desarrolladores que entrevistamos aún no han profundizado en las herramientas operativas de LLM . El almacenamiento en caché es relativamente común, generalmente basado en Redis, porque mejora el tiempo de respuesta y el costo de la aplicación. Las herramientas como Weights & Biases y MLflow (portadas del aprendizaje automático tradicional) o PromptLayer y Helicone (creadas específicamente para LLM) también se usan con bastante frecuencia. Pueden registrar, rastrear y evaluar la salida de LLM y, a menudo, se usan para mejorar las compilaciones sobre la marcha, ajustar las canalizaciones 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 instantánea (p. ej., Rebuff). La mayoría de estas herramientas operativas fomentan el uso de sus propios clientes de Python para llamadas LLM, por lo que será interesante ver cómo coexisten estas soluciones a lo largo del tiempo.
Finalmente, la parte estática de la aplicación LLM (es decir, todo lo que no sea los modelos) 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 un importante proveedor de nube. Sin embargo, están surgiendo dos nuevas categorías. Las empresas emergentes como Steamship brindan alojamiento integral 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 agentes?
Los componentes más importantes que faltan en esta arquitectura de referencia son los marcos de agentes de IA . Descrito como un "intento experimental de código abierto para hacer que GPT-4 sea completamente autónomo", AutoGPT fue el repositorio de Github de más rápido crecimiento en la historia esta primavera , y casi todos los proyectos o inicios de IA en la actualidad incluyen algún tipo de proxy.
La mayoría de los desarrolladores están entusiasmados con el potencial de los agentes. El modelo de aprendizaje contextual descrito en este documento es efectivo para abordar las alucinaciones y los problemas de actualización de datos para respaldar mejor las tareas de generación de contenido. Los agentes , por otro lado, brindan a las aplicaciones de IA un conjunto completamente nuevo de capacidades: resolver problemas complejos, actuar en el mundo externo y aprender de la experiencia después de la implementación . Lo hacen a través de una combinación de razonamiento/planificación avanzados, uso de herramientas y memoria/recurrencia/autorreflexión.
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 si cree en la autosuperación recursiva). Los marcos existentes como LangChain ya incluyen algunos conceptos de proxy. Solo hay un problema: el proxy aún no funciona. Hoy en día, la mayoría de los frameworks de agentes se encuentran en la etapa de prueba de concepto, capaces de realizar demostraciones increíbles, pero aún no son capaces de hacer las cosas de manera confiable y reproducible. **Estamos observando de cerca cómo se desarrollan en un futuro próximo.
panorama
Los modelos de IA preentrenados representan el cambio de arquitectura más significativo en el software desde Internet. Hacen posible que los desarrolladores individuales creen increíbles aplicaciones de IA en días, superando los proyectos de aprendizaje automático supervisados que los equipos grandes pueden tardar meses en desarrollar.
Las herramientas y patrones enumerados aquí pueden ser el punto de partida para un LLM integrado, no el final. Actualizaremos esto cuando haya cambios importantes (por ejemplo, el cambio a la capacitación de modelos) y publicaremos nuevas arquitecturas de referencia donde tenga sentido.