Nueva arquitectura para aplicaciones LLM
(a16z.com)- a16z presentó una "arquitectura de referencia para el stack de aplicaciones LLM"
Emerging LLM App Stack
Datos contextuales
- Data Pipelines: Databricks, Airflow, Unstructured,..
- Embedding Model: OpenAI, Cohere, Hugging Face
- Vector Database: Pinecone, Weaviate, Chroma, pgvector
Ejemplos de prompts few-shot
- Playground: OpenAI, nat.dev, Humanloop
- Orchestration: Pytion/DIY, LangChain, LlamaIndex, ChatGPT
- APIs/Plugins: Serp, Wolfram, Zapier,...
Consulta y salida
- App Hosting: Vercel, Steamship, Streamlit, Modal
- LLM Cache: Redis, SQLite, GPTCache
- Logging/LLMops: Weights & Biases, MLflow, PromptLayer, Helicone
- Validation: Guardrails, Rebuff, Guidance, LMQL
APIs y hosting de LLM
- Proprietary API: OpenAI, Anthropic
- Open API: Hugging Face, Replicate
- Cloud Provider: AWS, GCP, Azure, Coreweave
- Opinionated Cloud: Databricks, Anyscale, Mosaic, Modal, Runpod,...
Patrón de diseño: aprendizaje en contexto
- In-Context Learning: usar el LLM tal cual, sin fine-tuning, aprovechando prompting inteligente y condiciones basadas en algunos datos "contextuales"
- Ej.) Al crear un chatbot que responda sobre documentos legales, una forma ingenua sería meter todos los documentos en ChatGPT y luego hacer preguntas, pero eso solo sirve para datasets pequeños. Incluso el modelo más grande de ChatGPT solo puede procesar unas 50 páginas
En el aprendizaje en contexto, se envían solo los documentos relevantes y se obtiene la respuesta a partir de ellos - Por eso se compone del siguiente flujo de trabajo de 3 pasos
- Paso 1. Preprocesamiento de datos / embeddings
- Paso 2. Generación del prompt / retrieval de documentos relevantes desde la base de datos vectorial
- Paso 3. Ejecución del prompt / inferencia
- Puede parecer que requiere mucho trabajo, pero es mucho más fácil que entrenar y hacer fine-tuning del propio LLM
Paso 1. [Data preprocessing / embedding]
→ Los datos contextuales pasan por un Data Pipeline, luego por un Embedding Model y se almacenan en una Vector Database
Datos contextuales
- Documentos de texto, PDF, CSV y tablas SQL
- En la mayoría de los casos, la carga y transformación de datos se hace usando las herramientas ETL existentes (Databricks, Airflow)
- En algunos casos, se usan cargadores de documentos integrados en frameworks de orquestación como LangChain y LlamaIndex
- Se considera que esta parte del stack sigue relativamente menos desarrollada, y hay oportunidades para soluciones de replicación de datos hechas específicamente para aplicaciones LLM
Embeddings
- La mayoría de los desarrolladores usa la API de OpenAI (
text-embedding-ada-002)- Es fácil de usar, da resultados razonablemente buenos y además cada vez es más barata
- Algunas empresas grandes están explorando Cohere, que ofrece mejor desempeño en ciertos escenarios
- Los desarrolladores que prefieren open source suelen tomar como estándar la librería Sentence Transformers de Hugging Face
- También es posible generar distintos tipos de embeddings según el caso de uso
- Es un caso nicho, pero es un área de investigación prometedora
Base de datos vectorial
- La parte más importante del pipeline de preprocesamiento es la base de datos vectorial
- Su función es almacenar, comparar y buscar eficientemente hasta decenas de miles de millones de embeddings (vectores)
- La opción más común en el mercado es Pinecone
- Está completamente alojada en la nube, así que es fácil empezar
- Tiene muchas funciones que las grandes empresas necesitan en producción (buen desempeño, SSO, SLA de uptime, etc.)
- Pero hay muchísimas bases de datos vectoriales disponibles. En particular:
- Open source como Weaviate, Vespa y Qdrant
- Ofrecen excelente desempeño en un solo nodo y se pueden ajustar a aplicaciones específicas
- Son muy populares entre equipos de IA con experiencia que prefieren construir plataformas personalizadas
- Librerías locales de gestión vectorial como Chroma y Faiss
- Ofrecen una gran experiencia para desarrolladores
- Se pueden operar fácilmente para apps pequeñas y experimentos de desarrollo
- No están pensadas para reemplazar una base de datos completa a gran escala
- Extensiones OLTP como pgvector
- Son una buena solución de soporte vectorial para desarrolladores que quieren encajar Postgres en todas sus necesidades de base de datos o para empresas que compran la mayor parte de su infraestructura de datos a un solo proveedor cloud
- A largo plazo, no está claro si tiene sentido acoplar tan estrechamente cargas vectoriales y escalares
- Open source como Weaviate, Vespa y Qdrant
- Mirando hacia adelante, la mayoría de las empresas de bases de datos vectoriales open source están desarrollando productos cloud
- Según nuestra investigación, lograr gran desempeño en la nube para distintos casos de uso es muy difícil
- Por eso, esta elección quizá no cambie en el corto plazo, pero sí es probable que cambie a largo plazo
- La pregunta clave es si las bases de datos vectoriales terminarán consolidándose en uno o dos sistemas conocidos, como ocurrió con los casos OLTP y OLAP
- Otra pregunta es cómo evolucionarán los embeddings y las bases de datos vectoriales a medida que aumente la ventana de contexto disponible en la mayoría de los modelos
- Puede ser tentador decir que los embeddings dejarán de ser necesarios porque todos los datos contextuales cabrán en el prompt,
- pero el feedback de expertos dice que los pipelines de embeddings podrían volverse todavía más importantes
- Las ventanas de contexto grandes son una herramienta poderosa, pero implican un costo computacional considerable. Por eso, la prioridad es usarlas de forma eficiente
- Ahora será posible ver distintos tipos de modelos de embeddings volverse masivos, entrenados directamente con relevancia del modelo, y bases de datos vectoriales capaces de activarlos y aprovecharlos eficientemente
Paso 2. [Prompt construction / retrieval]
- Las estrategias para integrar prompting de LLM con datos adecuados al contexto se están volviendo cada vez más complejas y más importantes como fuente de diferenciación del producto
- La mayoría de los desarrolladores empieza un proyecto nuevo con prompts simples compuestos por instrucciones directas (zero-shot prompting) o por algunos ejemplos (few-shot prompting)
- Estos prompts a veces dan buenos resultados, pero no alcanzan el nivel de precisión necesario para desplegar en producción
- El siguiente nivel del prompting consiste en diseñar respuestas del modelo ancladas en alguna fuente de verdad y en proporcionar contexto externo sobre el cual el modelo no fue entrenado
- Prompt Engineering Guide resume 12 estrategias avanzadas de prompting
- Aquí es donde brillan frameworks de orquestación como LangChain y LlamaIndex
- Abstraen muchos de los detalles del prompt chaining
- Integración con APIs externas, recuperación de datos contextuales desde bases de datos vectoriales, mantenimiento de memoria entre múltiples llamadas al LLM, etc.
- También ofrecen plantillas para muchos programas comunes
- Su salida es un prompt o varios prompts para enviar al modelo de lenguaje
- Entre startups y desarrolladores hobby, LangChain es el más usado
- LangChain sigue siendo un proyecto nuevo (versión actual 0.0.220)
- Pero ya se empieza a ver que algunas aplicaciones construidas con él llegan a producción
- Algunos desarrolladores, en especial los early adopters de LLM, prefieren migrar a Python puro en producción para eliminar dependencias
- Pero creemos que este enfoque DIY irá disminuyendo gradualmente, igual que pasó en el stack de aplicaciones web
- Los lectores con buen ojo habrán notado que ChatGPT aparece en el cuadro de orquestación
- En general, ChatGPT no es una herramienta para desarrolladores sino una app, pero se puede acceder vía API
- En cierto sentido, hace algo parecido a estos frameworks de orquestación (abstracción de prompts, mantenimiento de estado, recuperación de datos contextuales vía plugins, etc.)
- No es un competidor directo de las herramientas mencionadas aquí, pero sí puede considerarse una solución alternativa. Puede ser una alternativa simple para configurar y usar rápidamente
Paso 3. [Prompt execution / inference]
- Actualmente OpenAI es el líder entre los modelos de lenguaje
- Casi todos los desarrolladores empiezan a construir aplicaciones LLM con GPT-4 y GPT-4-32k
- Son fáciles de usar, aplicables a varios dominios y no requieren fine-tuning ni self-hosting
- Cuando entran en producción y escalan, aparecen varias opciones
- Cambiar a
gpt-3.5-turbo:- Es más de 50 veces más barato y mucho más rápido que GPT-4
- Se elige cuando no se necesita precisión al nivel de GPT-4, se requieren tiempos de respuesta rápidos o soporte eficiente para usuarios gratuitos
- Experimentar con modelos de otros vendors (especialmente Claude de Anthropic)
- Claude ofrece inferencia rápida, precisión al nivel de GPT-3.5, más opciones de personalización y una ventana de contexto de hasta 100k (aunque la precisión cae cuando se alarga demasiado)
- Derivar algunas solicitudes a modelos open source
- Puede ser eficiente en casos de uso B2C a gran escala, como búsqueda o chat, donde hay distintas complejidades de consulta o se necesita atender usuarios gratuitos a bajo costo
- Cambiar a
- Los modelos open source todavía van detrás de los productos propietarios, pero la brecha empieza a cerrarse
- Los modelos LLaMA de Meta establecieron un nuevo punto de referencia para la precisión open source y dieron lugar a muchas variantes
- LLaMA solo fue autorizado para investigación, pero muchos proveedores participaron para entrenar modelos base alternativos (Together, Mosaic, Falcon, Mistral)
- Meta está en conversaciones para lanzar un verdadero modelo open source, LLaMa 2
- Si los LLM open source alcanzan un nivel de precisión parecido a GPT-3.5, podemos esperar para texto algo similar al Stable Diffusion Moment
- Experimentación a gran escala, compartición y puesta en producción de modelos fine-tuned, etc.
- Empresas de hosting como Replicate ya están agregando herramientas para que los desarrolladores usen estos modelos más fácilmente
- Está creciendo la creencia entre desarrolladores de que modelos más pequeños pero fine-tuned pueden alcanzar la precisión de modelos de punta
- La mayoría de los desarrolladores con los que hablamos no profundizó demasiado en herramientas operativas para LLM
- El caching es común, normalmente con Redis (porque mejora el tiempo de respuesta y reduce costos)
- También se usan mucho herramientas como Weights & Biases, MLFlow, PromptLayer y Helicone
- Permiten registrar, rastrear y evaluar salidas de LLM para crear prompts rápidamente, ajustar pipelines y elegir modelos
- También están apareciendo muchas herramientas para validar salidas de LLM (Guardrails) o detectar prompt injection (Rebuff)
- Como la mayoría de estas herramientas operativas recomienda hacer las llamadas al LLM usando su propio cliente de Python, también será interesante ver cómo coexistirán más adelante
- Por último, la parte estática del LLM (todo lo que no es el modelo) también tiene que alojarse en algún lado
- La solución más común es Vercel o los principales proveedores cloud
- Pero están surgiendo dos categorías nuevas
- Steamship ofrece hosting end-to-end para aplicaciones LLM, con funciones como orquestación (LangChain), contexto de datos multi-tenant, tareas asíncronas, almacén vectorial y gestión de claves
- Anyscale y Modal permiten a los desarrolladores alojar al mismo tiempo modelos y código Python
¿Y los agentes?
- El elemento más importante que falta en esta arquitectura de referencia es el framework de agentes de IA
- AutoGPT fue el repositorio de GitHub de crecimiento más rápido de la historia esta primavera como un "experimento open source para hacer que GPT-4 sea completamente autónomo"
- Hoy prácticamente todos los proyectos de IA incluyen agentes de alguna forma
- La mayoría de los desarrolladores con quienes hablamos está muy entusiasmada con el potencial de los agentes
- El patrón de aprendizaje en contexto descrito en este texto sirve mejor para tareas de generación de contenido y para resolver problemas de alucinación y frescura de datos
- En cambio, los agentes aportan capacidades fundamentalmente nuevas a las aplicaciones de IA
- Resolver problemas complejos, actuar sobre el mundo exterior o aprender de la experiencia incluso después del despliegue
- Lo logran mediante una combinación de razonamiento/planificación avanzados, uso de herramientas, memoria/recursión/self-reflection, etc.
- Los agentes podrían convertirse en una parte central de la arquitectura de las aplicaciones LLM (y si uno cree en la mejora recursiva, incluso podrían ocupar todo el stack)
- Frameworks como LangChain ya integraron el concepto de agentes
- El único problema es que los agentes todavía no funcionan bien
- Actualmente la mayoría de los frameworks de agentes está en etapa de PoC: permiten demos sorprendentes, pero no son estables ni reproducibles
- Estamos atentos a cómo evolucionarán
Mirando hacia adelante
- Los modelos de IA preentrenados son el cambio arquitectónico más importante en software desde internet
- Gracias a esto, cada desarrollador puede construir en pocos días una app de IA que supere proyectos de machine learning supervisado que antes requerían meses y equipos grandes
- Las herramientas y patrones presentados aquí probablemente no sean el estado final, sino apenas un punto de partida para la integración de LLM
6 comentarios
Parece un artículo con criterio y experiencia real.
Creo que será de gran ayuda para diseñar la arquitectura de una app con LLM basándose en este contenido.
Como en el ecosistema todavía no hay ganadores claramente definidos por área, hay muchas soluciones mezcladas,
lo que genera más dilemas de elección, y da la impresión de que estamos llegando a un punto en el que la capacidad clave es encontrar la combinación adecuada según tus requisitos.
Este es un artículo muy sustancioso. Lo estoy leyendo con calma.
Si se entrena al LLM con GN, ¿también le facilitará las cosas al gurú? ^^;
Gracias.
Ah, así que hicieron GN+ :-o
Parece que sí será más cómodo, pero creo que voy a seguir leyendo este tipo de textos como parte del estudio. Jaja
¡Si GN⁺ procesa todas las demás noticias, hasta podría hacer que aumenten este tipo de artículos!
Gracias por el buen artículo y el resumen.