Lo que aprendí al construir con LLM durante un año

 (eugeneyan.com)
75 puntos por xguru 2024-06-10 | 9 comentarios | Compartir por WhatsApp
  • El desarrollo con modelos de lenguaje grandes (LLM) está en un momento fascinante
    • Durante el último año, los LLM han alcanzado un nivel "suficientemente bueno" para aplicaciones reales, y cada año mejoran y se abaratan más
    • Junto con las demos en redes sociales, se estima que para 2025 se habrán invertido alrededor de 200 mil millones de dólares en IA
    • Las API de los proveedores han hecho que los LLM sean más accesibles, permitiendo que no solo ingenieros y científicos de ML, sino cualquiera, pueda incorporar inteligencia en sus productos
  • Aunque la barrera de entrada para crear con IA ha bajado, sigue siendo difícil construir productos y sistemas eficaces que vayan más allá de una demo
  • Hemos estado construyendo durante el último año y, en el proceso, descubrimos muchas dificultades
    • Queremos compartir lo que aprendimos para que otros eviten nuestros errores y puedan iterar más rápido
  • Este artículo se compone de tres partes:
    1. Táctica: algunas prácticas para prompting, RAG, ingeniería de workflows, evaluación y monitoreo
      • Escrito para quienes construyen con LLM o trabajan en proyectos de fin de semana
    2. Operativa: las preocupaciones organizacionales y cotidianas del lanzamiento de productos y cómo formar equipos efectivos
      • Para líderes de producto/tecnología que buscan desplegar de forma sostenible y confiable
    3. Estratégica: perspectivas de largo plazo y de visión general, y cómo iterar, con opiniones como "nada de GPU antes del PMF" y "enfócate en el sistema, no en el modelo"
      • Pensado para fundadores y ejecutivos
  • Esta guía busca ser un manual práctico para construir productos exitosos usando LLM
    • Surge de nuestra propia experiencia y presenta ejemplos de toda la industria

[Táctica: lo esencial del uso de LLM]

  • En esta sección compartimos buenas prácticas sobre los componentes centrales del stack emergente de LLM
    • Incluye consejos de prompting para mejorar calidad y confiabilidad, estrategias para evaluar resultados e ideas de generación aumentada por recuperación para mejorar el grounding
    • También exploraremos cómo diseñar workflows con human-in-the-loop

Táctica 1. Prompting

  • Recomendamos comenzar con prompting al desarrollar una nueva aplicación
    • Es fácil subestimar o sobreestimar la importancia del prompting
    • Suele subestimarse porque, si se usan bien las técnicas correctas de prompting, se puede llegar muy lejos
    • Suele sobreestimarse porque incluso las aplicaciones basadas en prompts requieren bastante ingeniería alrededor del prompt para funcionar bien

Enfócate en aprovechar al máximo las técnicas básicas de prompting

  • Hay algunas técnicas de prompting que ayudan de forma consistente a mejorar el rendimiento en distintos modelos y tareas
    • Entre ellas están los prompts N-shot + aprendizaje en contexto, chain-of-thought y la provisión de recursos relevantes
  • Prompts N-shot y aprendizaje en contexto
    • La idea del aprendizaje en contexto mediante prompts N-shot es mostrarle al LLM cómo hacer la tarea y darle algunos ejemplos para alinear su salida con lo esperado
    • Si N es demasiado bajo, el modelo puede fijarse en exceso en esos ejemplos específicos y perder capacidad de generalización
    • Empíricamente, conviene apuntar a N ≥ 5 y no tener miedo de usar varias decenas
    • Los ejemplos deben representar la distribución esperada de entradas
    • No es necesario proporcionar pares completos de entrada y salida; en muchos casos, basta con ejemplos de la salida deseada
    • Si usas un LLM que admite uso de herramientas, en los ejemplos N-shot también debes usar las herramientas que quieres que el agente utilice
  • Prompting con chain-of-thought (CoT)
    • En el prompting CoT, se alienta al LLM a explicar su proceso de pensamiento antes de devolver la respuesta final
    • Puede verse como darle al LLM una libreta de apuntes para que no tenga que hacerlo todo desde la memoria
    • El enfoque original consistía simplemente en agregar una frase como "pensemos paso a paso" como parte de la instrucción, pero hemos visto que ayuda hacer el CoT más específico
    • Agregar especificidad en 1 o 2 oraciones suele reducir de forma significativa la tasa de alucinaciones
    • Últimamente, se ha cuestionado si esta técnica es tan poderosa como se cree
    • También hay bastante debate sobre qué ocurre exactamente durante el razonamiento cuando se usa CoT
    • Aun así, es una técnica que vale la pena probar cuando sea posible
  • Proveer recursos relevantes
    • Proveer recursos relevantes es un mecanismo poderoso para ampliar la base de conocimiento del modelo, reducir alucinaciones y aumentar la confianza del usuario
    • A menudo se hace mediante generación aumentada por recuperación (Retrieval Augmented Generation, RAG)
    • Darle al modelo fragmentos de texto que pueda usar directamente en su respuesta es una técnica esencial
    • Al proveer recursos relevantes, no basta con simplemente incluirlos
      • No hay que olvidar indicarle al modelo que priorice el uso de esos recursos, los cite directamente y, a veces, que mencione cuando los recursos no son suficientes
    • Estas prácticas ayudan a hacer "ground" las respuestas del agente en el corpus de recursos

Estructura las entradas y salidas

  • Las entradas y salidas estructuradas ayudan al modelo a entender mejor la entrada y a devolver resultados que puedan integrarse de forma confiable con sistemas downstream
    • Agregar un formato de serialización a la entrada puede ayudar con las relaciones entre tokens del contexto, con metadatos adicionales sobre ciertos tokens (como tipos) o a vincular la solicitud con ejemplos similares en los datos de entrenamiento del modelo
    • Por ejemplo, muchas preguntas en internet sobre cómo escribir SQL comienzan especificando el esquema SQL
      • Por lo tanto, un prompting efectivo para Text-to-SQL debe incluir definiciones estructuradas del esquema
  • Las salidas estructuradas cumplen un propósito similar, pero simplifican la integración con los componentes downstream del sistema
    • Instructor y Outlines funcionan bien para salidas estructuradas
      • (usa Instructor si importas el SDK de la API de un LLM, y Outlines si importas Huggingface para un modelo autoalojado)
    • Las entradas estructuradas expresan la tarea con mayor claridad y se parecen al formato de los datos de entrenamiento, lo que aumenta la probabilidad de obtener mejores resultados
  • Al usar entradas estructuradas, hay que tener en cuenta que cada familia de LLM tiene su forma preferida
    • Claude prefiere <xml>, mientras que GPT prefiere Markdown y JSON
    • Si usas XML, incluso puedes precargar la respuesta de Claude proporcionando una etiqueta <response>

Crea prompts pequeños que hagan bien una sola cosa

  • Un anti-pattern/code smell común en software es el "God Object", una sola clase o función que lo hace todo
    • Lo mismo aplica a los prompts
  • Los prompts suelen empezar siendo simples
    • Puedes comenzar con unas cuantas oraciones de instrucciones y algunos ejemplos
    • Pero a medida que intentas mejorar el rendimiento y cubrir más edge cases, la complejidad aumenta
      • Se agregan más instrucciones, razonamiento de múltiples pasos, decenas de ejemplos, etc.
    • Al final, ese prompt que al principio era simple termina convertido en un Frankenstein de 2,000 tokens
      • Peor aún, el rendimiento para entradas más generales e intuitivas incluso empeora
      • GoDaddy considera este problema como la lección número uno aprendida al construir con LLM
  • Así como intentas mantener simples el sistema y el código, lo mismo debería aplicar a los prompts
    • En lugar de usar un único prompt todoterreno para un resumidor de transcripciones de reuniones, puedes dividirlo en pasos como estos
      • extraer las decisiones clave, los ítems de acción y los responsables en un formato estructurado
      • verificar la consistencia comparando los detalles extraídos con la transcripción original
      • generar un resumen conciso a partir de los detalles estructurados
  • Como resultado, divides un solo prompt en varios prompts simples, enfocados y fáciles de entender
    • Al hacerlo, ahora puedes iterar y evaluar cada prompt por separado

Crear tokens de contexto

  • Hay que reconsiderar y cuestionar las suposiciones sobre cuánta cantidad de contexto realmente se debe enviar al agente
    • En lugar de esculpir una estatua de contexto como Miguel Ángel, hay que ir quitando el material innecesario para revelar la estatua
    • RAG es un método ampliamente usado para reunir todos los bloques de mármol potencialmente relevantes, pero ¿qué se está haciendo para extraer lo que realmente se necesita?
  • Se ha visto que, para replantear el contexto, ayuda tomar el prompt final que se le envía al modelo, colocarlo en una página en blanco junto con toda la construcción de contexto, el meta prompting y los resultados de RAG, y leerlo
    • Con este método se pueden detectar redundancias, lenguaje que se contradice a sí mismo y partes mal formateadas
  • Otra optimización clave es la estructura del contexto
    • Como una representación tipo bag-of-docs no ayuda a los humanos, no se debe asumir que será buena para un agente
    • Hay que pensar con cuidado cómo organizar el contexto para resaltar las relaciones entre cada parte y hacer que la extracción sea lo más simple posible

Táctica 2. Recuperación de información / RAG

  • Además del prompting, otra forma efectiva de ajustar un LLM es proporcionarle conocimiento como parte del prompt
    • Esto ancla al LLM al contexto proporcionado, lo cual se usa para el aprendizaje en contexto
    • A esto se le llama generación aumentada por recuperación (Retrieval-Augmented Generation, RAG)
    • Los profesionales han encontrado que RAG es eficaz para aportar conocimiento y mejorar la salida, y que requiere mucho menos esfuerzo y costo que el fine-tuning
    • RAG solo es tan bueno como la relevancia, densidad y nivel de detalle de los documentos recuperados

La calidad de la salida de RAG depende de la calidad de los documentos recuperados, y hay varios factores a considerar

  • El primer y más obvio criterio es la "relevancia"
    • Normalmente esto se cuantifica con métricas de ranking como Mean Reciprocal Rank (MRR) o Normalized Discounted Cumulative Gain (NDCG)
    • MRR evalúa qué tan bien el sistema coloca el primer resultado relevante en una lista ordenada, mientras que NDCG considera la relevancia y la posición de todos los resultados
    • Estas métricas miden qué tan bien el sistema clasifica más arriba los documentos relevantes y más abajo los irrelevantes
    • Por ejemplo, si se recuperan resúmenes de usuarios para generar un resumen de reseñas de una película, conviene clasificar más arriba las reseñas de esa película específica y excluir las de otras películas
    • Al igual que en los sistemas de recomendación tradicionales, el ranking de los elementos recuperados tiene un impacto considerable en cómo el LLM realiza la tarea downstream
    • Para medir ese impacto, conviene ejecutar la tarea basada en RAG con los elementos recuperados mezclados y ver cómo cambia el desempeño de la salida de RAG
  • El segundo factor es la "densidad de información"
    • Si dos documentos son igual de relevantes, se debe preferir el más conciso y con menos detalles irrelevantes
    • Volviendo al ejemplo de películas, tanto el guion de la película como todas las reseñas de usuarios podrían considerarse relevantes en un sentido amplio
    • Aun así, es probable que las reseñas mejor valoradas y las reseñas editoriales tengan una mayor densidad de información
  • Por último, hay que considerar el "nivel de detalle" proporcionado en el documento
    • Imaginemos que se construye un sistema RAG para generar consultas SQL a partir de lenguaje natural
      • Puede que baste con proporcionar como contexto el esquema de la tabla con los nombres de las columnas
      • Pero ¿qué pasa si además se incluyen descripciones de las columnas y algunos valores representativos?
    • Ese detalle adicional puede ayudar al LLM a entender mejor el significado de la tabla y a generar SQL más preciso

No olvides la búsqueda por palabras clave, y úsala para la línea base y la búsqueda híbrida

  • Como los demos de RAG basado en embeddings están tan difundidos, es fácil olvidar o pasar por alto décadas de investigación y soluciones en recuperación de información
    • Aun así, aunque los embeddings son sin duda una herramienta poderosa, no sirven para todo
  • Ventajas de la búsqueda basada en palabras clave
    • Primero, los embeddings son excelentes para capturar similitud semántica de alto nivel, pero pueden tener dificultades con consultas más específicas y basadas en palabras clave, como cuando un usuario busca un nombre (por ejemplo, Ilya), una sigla (por ejemplo, RAG) o un ID (por ejemplo, claude-3-sonnet)
      • La búsqueda basada en palabras clave, como BM25, está diseñada explícitamente para eso
      • Como los usuarios llevan mucho tiempo usando búsqueda por palabras clave, probablemente la dan por sentada, y si no se devuelve el documento que quieren encontrar, pueden frustrarse
    • Segundo, es más intuitivo entender por qué un documento fue recuperado con búsqueda por palabras clave
      • Porque se pueden ver las palabras clave que coinciden con la consulta
      • En cambio, la búsqueda basada en embeddings es menos interpretable
    • Tercero, gracias a sistemas como Lucene u OpenSearch, optimizados y probados en producción durante décadas, la búsqueda por palabras clave suele ser más eficiente computacionalmente
  • En la mayoría de los casos, el enfoque híbrido es el más efectivo
    • Usar coincidencia por palabras clave para matches obvios, y embeddings para sinónimos, hiperónimos, errores ortográficos y multimodalidad (por ejemplo, imágenes y texto)
    • Shortwave compartió cómo construyó su pipeline de RAG, incluyendo reescritura de consultas, búsqueda por palabras clave + embeddings y ranking

Para conocimiento nuevo, prefiere RAG sobre fine-tuning

  • Tanto RAG como el fine-tuning pueden usarse para incorporar nueva información en un LLM y mejorar el desempeño en tareas específicas
    • Entonces, ¿cuál conviene probar primero?
  • Ventajas de RAG
    • Investigaciones recientes sugieren que RAG puede ser superior
    • Un estudio comparó RAG con el fine-tuning no supervisado (también llamado preentrenamiento continuo) evaluándolos en MMLU y en un subconjunto de preguntas de actualidad
      • RAG mostró de forma consistente un mejor rendimiento que el fine-tuning tanto para conocimiento visto durante el entrenamiento como para conocimiento completamente nuevo
    • Otro artículo comparó RAG con fine-tuning supervisado en un conjunto de datos agrícolas
      • Del mismo modo, la mejora de rendimiento de RAG fue mayor que la del fine-tuning, especialmente en GPT-4 (ver la tabla 20 del artículo)
    • Además de la mejora de rendimiento, RAG tiene varias ventajas prácticas
      • Primero, mantener actualizado un índice de búsqueda es más fácil y más barato que hacer preentrenamiento continuo o fine-tuning
      • Segundo, si en el índice de búsqueda hay documentos problemáticos con contenido dañino o sesgado, esos documentos se pueden eliminar o corregir fácilmente
    • Además, la R de RAG ofrece un control más detallado sobre cómo se recuperan los documentos
      • Por ejemplo, si se aloja un sistema RAG para varias organizaciones, se puede particionar el índice de búsqueda para que cada organización solo pueda recuperar documentos de su propio índice
      • Así se puede evitar exponer por error información de una organización a otra

Los modelos de contexto largo no volverán inútil a RAG

  • A medida que Gemini 1.5 ofrece una ventana de contexto de hasta 10 millones de tokens, algunos han empezado a cuestionar el futuro de RAG
    • Una ventana de contexto de 10 millones de tokens vuelve innecesarios la mayoría de los frameworks RAG existentes
      • Basta con poner los datos en el contexto y hablar con el modelo como siempre
    • Imagina qué impacto tendría esto en startups, agentes y proyectos de langchain donde la mayor parte del esfuerzo de ingeniería se invierte en RAG
      • Resumido en una frase: un contexto de 10 millones mata a RAG
  • La necesidad continua de RAG
    • Aunque es cierto que el contexto largo será un game changer para casos de uso como analizar múltiples documentos o chatear con PDFs, los rumores sobre la muerte de RAG están muy exagerados
      • Primero, incluso con una ventana de contexto de 10 millones de tokens, sigue haciendo falta una forma de seleccionar qué información darle al modelo
      • Segundo, más allá de evaluaciones de aguja en un pajar, todavía no he visto datos convincentes de que un modelo pueda razonar de forma efectiva sobre un contexto tan grande
      • Por lo tanto, sin una buena búsqueda (y ranking), existe el riesgo de abrumar al modelo con información distractora o incluso de llenar por completo la ventana de contexto con información totalmente irrelevante
  • Por último, está el problema del costo
    • El costo de inferencia de los Transformer aumenta cuadráticamente con la longitud del contexto (o linealmente tanto en espacio como en tiempo)
    • Que exista un modelo capaz de leer todo el contenido de Google Drive de una organización no significa que sea buena idea hacerlo antes de responder cada pregunta
    • Considera una analogía con la forma en que se usa la RAM
      • Existen instancias de cómputo con decenas de terabytes de RAM, pero aun así seguimos leyendo y escribiendo en disco
  • Así que todavía no tires RAG a la basura
    • Este patrón seguirá siendo útil incluso a medida que crezca el tamaño de las ventanas de contexto

Táctica 3. Ajuste y optimización del flujo de trabajo

  • Darle prompts a un LLM es apenas el comienzo
    • Para sacarle el máximo provecho a un LLM, hay que ir más allá de un solo prompt y adoptar flujos de trabajo
    • Por ejemplo, ¿cómo se puede dividir una tarea compleja en varias tareas más simples?
    • ¿Cuándo ayudan el fine-tuning o el caching a mejorar el rendimiento y a reducir la latencia/el costo?
  • En esta sección se comparten estrategias probadas y casos reales para ayudar a optimizar y construir flujos de trabajo con LLM

Los "Flow" paso a paso y de múltiples turnos pueden ofrecer grandes mejoras de rendimiento

  • Ya sabemos que se pueden obtener mejores resultados descomponiendo un gran prompt en varios prompts pequeños
    • AlphaCodium es un ejemplo de ello
      • Al pasar de un solo prompt a un flujo de trabajo de múltiples etapas, elevó la precisión de GPT-4 (pass@5) en CodeContests de 19% a 44%
    • El flujo de trabajo incluye
      • reflexión sobre el problema
      • razonamiento sobre las pruebas públicas
      • generación de posibles soluciones
      • clasificación de posibles soluciones
      • generación de pruebas sintéticas
      • iteración de las soluciones sobre pruebas públicas y sintéticas
  • Las tareas pequeñas con objetivos claros producen los mejores prompts de agentes o de flujo
    • No todos los prompts de agentes necesitan pedir salida estructurada, pero la salida estructurada ayuda mucho en la interfaz con el sistema que coordina la interacción del agente con su entorno
  • Cosas que vale la pena probar
    • una etapa explícita de planificación especificada de la forma más estricta posible
      • considera elegir entre planes predefinidos
    • reescribir el prompt original del usuario como un prompt de agente
      • ten cuidado, porque en este proceso se pierde información
    • comportamiento del agente como cadena lineal, DAG y máquina de estados
      • distintas dependencias y relaciones lógicas pueden adaptarse mejor o peor a diferentes escalas
      • ¿se puede impulsar la optimización del rendimiento con distintas arquitecturas de tareas?
    • validación del plan
      • el plan puede incluir instrucciones sobre cómo evaluar las respuestas de otros agentes para que el resultado final funcione bien
    • prompt engineering con un estado upstream fijo
      • asegúrate de que los prompts del agente se evalúen frente a las distintas variaciones que pueden ocurrir antes

Por ahora, conviene priorizar los flujos de trabajo deterministas

  • Los agentes de IA pueden reaccionar dinámicamente a las solicitudes del usuario y al entorno, pero su naturaleza no determinista dificulta el despliegue
    • Cada paso que ejecuta un agente puede fallar, y la probabilidad de recuperarse de un error es baja
    • Por eso, la probabilidad de que un agente complete con éxito una tarea de múltiples pasos disminuye geométricamente a medida que aumenta la cantidad de pasos
    • Como resultado, los equipos que construyen agentes tienen dificultades para desplegar agentes confiables
  • Un enfoque prometedor es contar con un sistema de agentes que genere un plan determinista y lo ejecute de forma estructurada y reproducible
    • En la primera etapa, dado un objetivo de alto nivel o un prompt, el agente genera un plan
    • Luego, el plan se ejecuta de forma determinista
    • Esto permite que cada paso sea más predecible y confiable
    • Ventajas
      • El plan generado puede usarse como muestra few-shot para dar prompts al agente o para hacer fine-tuning
      • La ejecución determinista vuelve al sistema más confiable, facilitando las pruebas y la depuración. Además, los fallos pueden rastrearse hasta una etapa específica del plan
      • El plan generado puede representarse como un grafo acíclico dirigido (DAG), lo que lo hace más fácil de entender y de adaptar a nuevas situaciones que un prompt estático
  • Los constructores de agentes más exitosos podrían ser personas con gran experiencia gestionando ingenieros junior
    • Porque el proceso de generación de planes se parece a la forma de dirigir y gestionar a un junior
    • Igual que a un junior se le dan objetivos claros y planes concretos en lugar de indicaciones ambiguas y abiertas, con los agentes hay que hacer lo mismo
  • Al final, la clave para tener agentes confiables y que realmente funcionen probablemente esté en
    • adoptar un enfoque más estructurado y determinista, y
    • recopilar datos para mejorar los prompts y hacer fine-tuning del modelo
  • Sin esto, terminarás construyendo agentes que a veces pueden funcionar muy bien, pero que en promedio decepcionarán a los usuarios y reducirán la retención

Obtener salidas diversas más allá del parámetro de temperatura

  • Supongamos que tienes una tarea que necesita diversidad en la salida del LLM
    • Podrías estar escribiendo un pipeline con LLM para sugerir productos de un catálogo considerando la lista de productos que el usuario compró anteriormente
    • Puede que notes que, al ejecutar el prompt varias veces, las recomendaciones resultantes son demasiado parecidas
    • Entonces podrías subir el parámetro Temperature (temperatura) de la solicitud al LLM
  • Aumentar el parámetro de temperatura hace que las respuestas del LLM sean más diversas
    • Durante el muestreo, la distribución de probabilidad del siguiente token se aplana, por lo que se eligen con más frecuencia tokens que normalmente tendrían menos probabilidad de ser seleccionados
  • Sin embargo, al aumentar la temperatura pueden aparecer algunos modos de fallo relacionados con la diversidad de salida
    • Por ejemplo, algunos productos del catálogo podrían ser adecuados, pero el LLM podría no incluirlos en la salida
    • Si es más probable que el LLM siga lo que aprendió durante el entrenamiento en lugar del prompt, el mismo pequeño conjunto de productos puede quedar sobrerrepresentado en la salida
    • Si la temperatura es demasiado alta, puede generar salidas que hagan referencia a productos inexistentes (o contenido sin sentido)
  • Subir la temperatura no garantiza que el LLM muestree salidas desde la distribución de probabilidad que esperas (por ejemplo, uniforme aleatoria)
  • Aun así, hay otros trucos para aumentar la diversidad de salida
    • La forma más simple es ajustar elementos dentro del prompt
      • Por ejemplo, si la plantilla del prompt incluye una lista de elementos como compras pasadas, mezclar el orden cada vez que se insertan en el prompt puede marcar una diferencia considerable
    • También ayuda mantener una lista corta de salidas recientes para evitar repeticiones
      • En el ejemplo de productos recomendados, puedes indicarle al LLM que evite sugerir elementos de esa lista reciente o diversificar aún más la respuesta rechazando salidas similares a las sugerencias recientes y volviendo a muestrear
    • Otra estrategia efectiva es variar la redacción utilizada en el prompt
      • Por ejemplo, incorporar frases como "selecciona artículos que al usuario le gustaría usar regularmente" o "selecciona productos que probablemente el usuario recomendaría a un amigo" puede mover el enfoque e influir en la diversidad de los productos recomendados

El caching está subestimado

  • El caché reduce costos y elimina la latencia de generación al evitar la necesidad de recalcular respuestas para la misma entrada
    • Además, si la respuesta ya pasó por guardrails previamente, se puede entregar esa respuesta validada y así reducir el riesgo de ofrecer contenido dañino o inapropiado
  • Un enfoque simple para el caché es usar un ID único para el elemento que se está procesando, como al resumir un artículo nuevo o una reseña de producto
    • Cuando llega una solicitud, se puede verificar si ya existe un resumen en el caché
      • Si existe, se puede devolver de inmediato; si no, se puede generar, aplicar guardrails y servirlo, y luego almacenarlo en el caché para futuras solicitudes
  • Para consultas más abiertas, se pueden tomar prestadas técnicas del campo de búsqueda para aprovechar el caché incluso con entradas abiertas
    • Funciones como autocompletado y corrección ortográfica ayudan a normalizar la entrada del usuario para aumentar la tasa de aciertos del caché

Cuándo se necesita finetune (ajuste fino)

  • Puede haber tareas para las que incluso el prompt mejor diseñado se quede corto
    • Por ejemplo, aun después de un trabajo considerable de prompt engineering, el sistema puede seguir estando lejos de devolver resultados confiables y de alta calidad
    • En ese caso, puede ser necesario hacer ajuste fino del modelo para una tarea específica
  • Casos exitosos de ajuste fino
    • Natural Language Query Assistant de Honeycomb
      • Al principio, se proporcionó un “manual de programación” dentro del prompt junto con ejemplos n-shot para aprendizaje en contexto
      • Esto funcionó bien, pero al hacer ajuste fino del modelo se pueden obtener mejores resultados respecto a la sintaxis y las reglas del lenguaje específico del dominio
    • Lucy de Rechat
      • El LLM tenía que generar respuestas en un formato muy específico que combinaba datos estructurados y no estructurados para que el frontend pudiera renderizarlos correctamente
      • El ajuste fino fue esencial para que esto funcionara de forma consistente
  • El ajuste fino puede ser efectivo, pero conlleva un costo considerable
    • Hay que anotar los datos de ajuste fino, ajustar y evaluar el modelo, y al final incluso alojarlo por cuenta propia
    • Por eso, vale la pena considerar si el mayor costo inicial realmente compensa
  • Si con prompting se puede llegar al 90%, quizá no valga la pena invertir en ajuste fino
    • Sin embargo, si se decide hacer ajuste fino, se puede generar y ajustar con datos sintéticos o aprovechar datos open source como punto de partida para reducir el costo de recolectar datos anotados por humanos

Táctica 4. Evaluación y monitoreo

  • La evaluación de LLM puede ser un campo minado
    • Las entradas y salidas de los LLM son texto arbitrario, y las tareas que se les asignan también son diversas
    • Aun así, una evaluación rigurosa y cuidadosa es importante
      • No es casualidad que los líderes técnicos de OpenAI participen en las evaluaciones y den retroalimentación sobre evaluaciones individuales
  • La evaluación de aplicaciones con LLM requiere varias definiciones y reducciones
    • Puede ser simplemente pruebas unitarias, algo más parecido a observabilidad, o simplemente ciencia de datos
    • Descubrimos que todas estas perspectivas son útiles
  • En esta sección se comparten lecciones aprendidas sobre puntos importantes al construir un pipeline de evaluación y monitoreo

Generar algunas pruebas unitarias basadas en assertions a partir de muestras reales de entrada y salida

  • Crear pruebas unitarias (es decir, assertions) compuestas por muestras de entradas y salidas de producción, y establecer expectativas sobre la salida según al menos 3 criterios
    • Tres criterios pueden parecer arbitrarios, pero es una cantidad práctica para empezar
      • Si son menos, puede que la tarea no esté lo suficientemente definida o que sea demasiado abierta, como un chatbot de propósito general
    • Estas pruebas unitarias o assertions deberían activarse por cambios en el pipeline, como editar el prompt, agregar nuevo contexto mediante RAG u otras modificaciones
  • Considera empezar con assertions que especifiquen frases o ideas que deban incluirse o excluirse de todas las respuestas
    • También considera verificaciones para confirmar que la cantidad de palabras, elementos o frases esté dentro de un rango
    • Para otros tipos de generación, las assertions pueden verse distintas
      • Por ejemplo, en la evaluación por ejecución, un método sólido para evaluar generación de código, se ejecuta el código generado y se verifica si el estado en runtime satisface suficientemente la solicitud del usuario
  • Por ejemplo, si el usuario solicita una nueva función llamada foo, después de ejecutar el código generado por el agente debería ser posible llamar a foo
  • Un desafío de la evaluación por ejecución es que el código del agente a menudo deja el runtime en una forma ligeramente distinta del código objetivo
    • Puede ser efectivo “relajar” la assertion hasta la suposición más débil que pueda satisfacer cualquier respuesta válida
  • Usar el producto tal como está pensado para los clientes (es decir, “dogfooding”) puede dar información sobre modos de falla en datos reales
    • Este enfoque no solo ayuda a identificar debilidades potenciales, sino que también proporciona una fuente útil de muestras de producción que pueden convertirse en evaluaciones

LLM-as-Judge puede funcionar (hasta cierto punto), pero no es una solución universal

  • LLM-as-Judge es un enfoque que usa un LLM potente para evaluar la salida de otro LLM, y algunas personas lo ven con escepticismo
  • Aun así, si se implementa bien, LLM-as-Judge puede lograr una correlación considerable con el juicio humano y, al menos, ayudar a construir información preliminar sobre cómo podría desempeñarse un nuevo prompt o técnica
    • En particular, al hacer comparaciones por pares (por ejemplo, grupo de control vs grupo tratado), LLM-as-Judge generalmente acierta en la dirección, aunque la magnitud de la victoria o derrota puede tener ruido
  • Sugerencias para aprovechar al máximo LLM-as-Judge
    • Usar comparaciones por pares
      • En lugar de pedirle al LLM que evalúe una sola salida con una escala de Likert, preséntale dos opciones y pídele que elija la mejor
      • Esto tiende a producir resultados más estables
    • Controlar el sesgo de posición
      • El orden de las opciones presentadas puede sesgar la decisión del LLM
      • Para mitigarlo, realiza cada comparación por pares dos veces y cambia el orden del par en cada ocasión
      • Después del intercambio, hay que atribuir la victoria a la opción correcta
    • Permitir empates
      • En algunos casos, ambas opciones pueden ser igual de buenas
      • Por lo tanto, conviene permitir que el LLM declare un empate para que no tenga que elegir un ganador de forma arbitraria
    • Usar Chain-of-Thought
      • Pedirle al LLM que explique su decisión antes de dar la preferencia final puede mejorar la confiabilidad de la evaluación
      • Como beneficio adicional, esto puede permitir usar un LLM más débil pero más rápido y aun así obtener resultados similares
      • Dado que esta parte del pipeline suele ejecutarse en modo batch, la latencia adicional causada por CoT no representa un problema
    • Controlar la longitud de las respuestas
      • Los LLM tienden a inclinarse por respuestas más largas
      • Para mitigar esto, asegúrate de que las longitudes de cada par de respuestas sean similares
  • Una aplicación especialmente potente de LLM-as-Judge es verificar regresiones en nuevas estrategias de prompting
    • Si se ha llevado seguimiento de un conjunto de resultados de producción, a veces se pueden volver a ejecutar esos ejemplos de producción con una nueva estrategia de prompting y usar LLM-as-Judge para evaluar rápidamente en qué casos la nueva estrategia podría tener dificultades
  • Ejemplo de un enfoque simple pero efectivo para LLM-as-Judge
    • Simplemente registrar la respuesta del LLM, la crítica del juez (es decir, CoT) y el resultado final
    • Luego revisarlo con las partes interesadas para identificar áreas de mejora
    • A lo largo de 3 iteraciones, la coincidencia entre humanos y LLM mejoró de 68% a 94%
  • Sin embargo, LLM-as-Judge no es una solución universal
    • Incluso los modelos más potentes tienen aspectos lingüísticos sutiles que no pueden evaluar de forma confiable
  • También descubrimos que los clasificadores tradicionales y los modelos de recompensa pueden lograr mayor precisión que LLM-as-Judge, con menor costo y latencia
    • En generación de código, LLM-as-Judge puede ser más débil que estrategias de evaluación más directas, como la evaluación por ejecución

“Prueba del becario” para evaluar resultados generados

  • Al evaluar los resultados generados, conviene usar una especie de "prueba del becario"
    • Si tomas la entrada exacta para el modelo de lenguaje, incluyendo el contexto, y se la das como tarea a un estudiante universitario promedio de una carrera relacionada, ¿podría resolverla con éxito?
    • ¿Cuánto tiempo le tomaría?
  • Si la respuesta es no
    • Si se debe a que al LLM le falta el conocimiento necesario, considera formas de enriquecer el contexto
    • Si ni siquiera mejorando el contexto se resuelve, puede ser una tarea demasiado difícil para los LLM modernos
  • Si la respuesta es sí, pero toma tiempo
    • Puedes intentar reducir la complejidad de la tarea
      • ¿Se puede descomponer?
      • ¿Qué aspectos de la tarea se pueden volver más plantillables?
  • Si la respuesta es sí y puede hacerlo rápido
    • Al profundizar en los datos
      • ¿En qué se está equivocando el modelo?
      • ¿Puedes encontrar patrones de falla?
    • Prueba pedirle al modelo que se explique a sí mismo antes o después de responder

Enfocarse demasiado en una evaluación específica puede empeorar el rendimiento general

"Cuando una métrica se convierte en objetivo, deja de ser una buena métrica." - Ley de Goodhart

  • Un ejemplo de esto es la evaluación Needle-in-a-Haystack (NIAH)
    • La evaluación original ayudaba a cuantificar el recall del modelo a medida que crecía el tamaño del contexto y a verificar cómo la posición de la aguja afectaba ese recall
    • Pero se sobredimensionó tanto que apareció como la Figure 1 del informe de Gemini 1.5
    • Esta evaluación consiste en insertar una frase específica ("The special magic {city} number is: {number}") en un documento largo que repite ensayos de Paul Graham, y luego pedirle al modelo que recuerde el número mágico
  • Algunos modelos logran un recall casi perfecto, pero sigue siendo cuestionable si NIAH realmente refleja la capacidad de razonamiento y recuperación que requieren las aplicaciones reales
  • Considera un escenario más práctico
    • Si se le da la transcripción de una reunión de una hora, ¿puede el LLM resumir las decisiones clave y los siguientes pasos, y atribuir correctamente cada punto a la persona responsable?
    • Esta tarea es más realista porque va más allá de la memorización simple y también considera la capacidad de entender discusiones complejas, identificar información relevante y sintetizar un resumen
  • Ejemplo de una evaluación NIAH más práctica
    • Usar la transcripción de una videollamada médico-paciente y preguntarle al LLM sobre los medicamentos del paciente
    • También incluir NIAH más desafiantes, como insertar frases sobre ingredientes aleatorios necesarios para toppings de pizza, como dátiles remojados en espresso, limón y queso de cabra
    • En la tarea de medicamentos, el recall fue de alrededor del 80%, y en la tarea de pizza fue del 30%
  • Enfatizar demasiado la evaluación NIAH puede reducir el rendimiento en tareas de extracción y resumen
    • Como estos LLM se ajustan finamente para prestar atención a todas las oraciones, pueden empezar a tratar detalles irrelevantes y distracciones como si fueran importantes
    • Entonces eso puede terminar incluido en la salida final (¡aunque no debería!)
  • Esto también puede aplicarse a otras evaluaciones y casos de uso
    • Por ejemplo, el resumen
      • Si se enfatiza la consistencia factual, pueden generarse resúmenes menos específicos (y por lo tanto con menor probabilidad de contradecir los hechos) pero también menos relevantes
      • En cambio, si se enfatizan el estilo de escritura y la elocuencia, puede producirse un lenguaje más vistoso, tipo marketing, que termine causando inconsistencias fácticas

Simplificar la anotación como tarea binaria o comparación por pares

  • Dar retroalimentación abierta sobre la salida del modelo o calificarla con una escala Likert es cognitivamente exigente
    • Como resultado, los datos recopilados tienden a tener más ruido debido a la variabilidad entre evaluadores humanos y, por lo tanto, son menos útiles
  • Un enfoque más efectivo es simplificar la tarea y reducir la carga cognitiva de quienes anotan
    • Dos tareas que funcionan bien son la clasificación binaria y la comparación por pares
  • En la clasificación binaria, se le pide al anotador que emita un juicio simple de sí/no sobre la salida del modelo
    • Se puede preguntar si el resumen generado es factualmente consistente con el documento fuente, si la respuesta propuesta es relevante, si contiene contenido dañino, etc.
    • En comparación con una escala Likert, las decisiones binarias son más precisas, tienen mayor consistencia entre evaluadores y permiten mayor rendimiento
    • Así es como DoorDash configuró una cola de etiquetado para poner etiquetas a elementos del menú mediante una serie de preguntas de sí/no
  • En la comparación por pares (Pairwise Comparison), el anotador recibe un par de respuestas del modelo y se le pregunta cuál es mejor
    • Como para las personas es más fácil decir "A es mejor que B" que asignar puntajes individuales a A o B, esto produce anotaciones más rápidas y confiables (que con una escala Likert)
  • En un meetup de Llama2, Thomas Scialom, uno de los autores del paper de Llama2, confirmó que la comparación por pares es más rápida y más barata que recopilar datos de ajuste fino supervisado como respuestas redactadas
    • La primera cuesta $3.5 por unidad y la segunda $25 por unidad

Las evaluaciones (reference-free) sin referencia y los guardrails pueden usarse de forma intercambiable

  • Los guardrails ayudan a detectar contenido inapropiado o dañino, mientras que las evaluaciones ayudan a medir la calidad y exactitud de la salida del modelo
    • En el caso de las evaluaciones sin referencia, pueden verse como dos caras de la misma moneda
      • Una evaluación sin referencia es una evaluación que puede medir la calidad de la salida usando solo el prompt de entrada y la respuesta del modelo, sin depender de una referencia "golden" como una respuesta escrita por humanos
  • Ejemplo de evaluación sin referencia: evaluación de resúmenes
    • Solo hace falta considerar el documento de entrada para evaluar la consistencia factual y la relevancia del resumen
    • Si el resumen obtiene una puntuación baja en estas métricas, se puede optar por no mostrárselo al usuario, usando así la evaluación de forma efectiva como guardrail
  • Evaluación de "traducción" sin referencia:
    • También se puede evaluar la calidad de una traducción sin una referencia traducida por humanos, y nuevamente usarla como guardrail

Los LLM devuelven salidas incluso cuando no deberían

  • Un reto principal al trabajar con LLM es que muchas veces generan una salida incluso cuando no deberían
    • Esto puede llevar a respuestas inofensivas pero sin sentido, o a fallas más graves como contenido dañino o riesgoso
    • Por ejemplo, si se les pide extraer ciertos atributos o metadatos de un documento, el LLM puede devolver un valor con confianza aunque ese valor en realidad no exista
    • O puede responder en un idioma distinto del inglés porque se le dio contexto con documentos en otro idioma
  • Se puede usar prompting para que el LLM devuelva respuestas como "no aplica" o "no lo sé", pero no es perfecto
    • Incluso si se puede usar log probabilities, siguen siendo un mal indicador de la calidad de la salida
      • Las log probabilities indican la probabilidad de que aparezcan tokens en la salida, pero no reflejan la exactitud del texto generado
    • Más bien, en modelos instruction-tuned entrenados para responder consultas y generar respuestas coherentes, las log probabilities pueden no estar bien calibradas
      • Por tanto, una log probability alta puede indicar que la salida es fluida y coherente, pero no que sea correcta o relevante
  • Una ingeniería de prompts cuidadosa puede ayudar hasta cierto punto, pero debe complementarse con guardrails robustos para detectar y filtrar/regenerar salidas no deseadas
    • Por ejemplo, OpenAI ofrece una API de moderación de contenido capaz de identificar respuestas inseguras como discurso de odio, autolesiones o salidas sexuales
    • De forma similar, existen numerosos paquetes para detectar información personal identificable (PII)
  • Una ventaja de los guardrails es que son en gran medida agnósticos al caso de uso, por lo que pueden aplicarse ampliamente a cualquier salida en un idioma determinado
    • Además, con una recuperación precisa, si no hay documentos relevantes el sistema puede responder de forma concluyente "no lo sé"
  • Los LLM también pueden no generar salida cuando sí se espera una
    • Esto puede deberse a distintos motivos, desde problemas simples como la alta latencia del proveedor de API hasta problemas más complejos como que la salida sea bloqueada por filtros de moderación de contenido
  • Por eso, para depuración y monitoreo, es importante registrar de forma consistente las entradas y (potencialmente la falta de salida)

Las alucinaciones (Hallucination) son un problema persistente

  • Mientras que los problemas de seguridad de contenido o defectos de PII reciben mucha atención y por eso casi no ocurren, las inconsistencias fácticas persisten de forma tenaz y son más difíciles de detectar
    • Ocurren con más frecuencia, con una tasa base de 5–10%, y, según lo aprendido de proveedores de LLM, puede ser difícil bajarlas a menos de 2% incluso en tareas simples como el resumen
  • Para resolver esto, se puede combinar ingeniería de prompts (aguas arriba de la generación) con guardrails contra inconsistencias fácticas (aguas abajo de la generación)
    • En el caso de la ingeniería de prompts, técnicas como CoT ayudan a reducir las alucinaciones al hacer que el LLM explique su razonamiento antes de devolver la salida final
    • Después se pueden aplicar guardrails contra inconsistencias fácticas para evaluar la veracidad del resumen y filtrar o regenerar alucinaciones
  • En algunos casos, las alucinaciones pueden detectarse de manera determinista
    • Al usar recursos de recuperación RAG, si la salida está estructurada y se puede identificar cuáles son los recursos, debería ser posible verificar manualmente si proviene del contexto de entrada

[Operaciones: problemas cotidianos (Day-to-Day) y organizacionales ]

Operaciones 1. Datos

  • Así como la calidad de los ingredientes determina el sabor de una comida, la calidad de los datos de entrada limita el rendimiento de un sistema de aprendizaje automático
  • Además, los datos de salida son la única forma de saber si el producto funciona o no
  • Todos los autores dedican varias horas cada semana a revisar de cerca entradas y salidas para entender mejor la distribución de los datos (modos, casos límite, limitaciones del modelo)

Verificar el sesgo entre desarrollo y producción

  • En los pipelines tradicionales de aprendizaje automático, una causa común de errores es el sesgo entrenamiento-servicio
    • Esto ocurre cuando los datos usados para entrenar son distintos de los datos que el modelo encuentra en producción
  • Como es posible usar LLM sin entrenamiento ni ajuste fino, no hay un conjunto de entrenamiento, pero aparece un problema similar: el sesgo de datos entre desarrollo y producción
    • En esencia, los datos con los que se prueba el sistema durante el desarrollo deben reflejar los datos que el sistema enfrentará en producción
      • De lo contrario, la precisión en producción puede degradarse
  • El sesgo entre desarrollo y producción en LLM puede dividirse en dos tipos: sesgo estructural y sesgo basado en contenido
    • El sesgo estructural incluye problemas como desajustes de formato, por ejemplo la diferencia entre un diccionario JSON con valores tipo lista y una lista JSON, uso inconsistente de mayúsculas y minúsculas, y errores como typos o fragmentos de oración
      • Estos errores pueden llevar a un rendimiento impredecible del modelo porque distintos LLM fueron entrenados con ciertos formatos de datos y los prompts pueden ser muy sensibles a cambios triviales
    • El sesgo basado en contenido o “semántico” se refiere a diferencias en el significado o el contexto de los datos
  • Igual que en ML tradicional, es útil medir periódicamente el sesgo entre pares de entrada/salida de LLM
    • Métricas simples como la longitud de entrada y salida o requisitos de formato específicos (por ejemplo, JSON o XML) son una forma sencilla de seguir cambios
  • Para una detección de sesgo más “avanzada”, considera agrupar embeddings de pares de entrada/salida para detectar sesgo semántico, como cambios en los temas que discuten los usuarios, que podrían indicar que están explorando áreas a las que el modelo no había sido expuesto antes
  • Al probar cambios como la ingeniería de prompts, asegúrate de que el conjunto holdout esté actualizado y refleje los tipos más recientes de interacción de los usuarios
    • Por ejemplo, si los typos son comunes en las entradas de producción, también deberían estar en los datos holdout
  • Más allá de medir el sesgo solo con números, es beneficioso hacer evaluaciones cualitativas de las salidas
    • Revisar regularmente las salidas del modelo (una práctica conocida coloquialmente como “vibe check”) ayuda a confirmar que los resultados cumplen las expectativas y siguen siendo relevantes para las necesidades de los usuarios
  • También es útil incorporar no determinismo en la verificación de sesgo
    • Al ejecutar el pipeline varias veces para cada entrada del conjunto de prueba y analizar todas las salidas, aumenta la probabilidad de capturar anomalías que quizá solo ocurren ocasionalmente

Revisar muestras de entrada/salida de LLM todos los días

  • Los LLM son dinámicos y están en evolución constante
    • A pesar de sus impresionantes capacidades zero-shot y de salidas que a menudo resultan agradables, los modos de falla de los LLM son muy poco predecibles
  • Para tareas personalizadas, es esencial revisar muestras de datos con regularidad para desarrollar una comprensión intuitiva del rendimiento del LLM
    • Los pares de entrada/salida en producción son el “objeto real, lugar real” (genchi genbutsu) de las aplicaciones con LLM y no tienen sustituto
  • Investigaciones recientes destacan que, cuanto más interactúan los desarrolladores con los datos, más cambia su percepción de lo que es una salida “buena” y una “mala” (es decir, sesgo de criterio)
    • Los desarrolladores pueden definir por adelantado algunos criterios para evaluar las salidas del LLM, pero esos criterios predefinidos suelen ser incompletos
  • Por ejemplo, durante el desarrollo se puede actualizar el prompt para aumentar la probabilidad de buenas respuestas y reducir la de respuestas malas
    • Este proceso iterativo de evaluación, reevaluación y actualización de criterios es necesario porque es difícil predecir el comportamiento del LLM o las preferencias humanas sin observar directamente las salidas
  • Para gestionar esto de forma efectiva, se deben registrar las entradas y salidas del LLM
    • Inspeccionar a diario muestras de esos logs permite identificar y adaptarse rápidamente a nuevos patrones o modos de falla
    • Cuando descubras un problema nuevo, puedes escribir de inmediato una assertion o una eval para él
  • De la misma manera, cualquier actualización en la definición de modos de falla debe reflejarse en los criterios de evaluación
    • Estos “vibe checks” son una señal de salidas incorrectas, y el código y las assertions lo operacionalizan
  • Por último, esta actitud debe socializarse
    • Por ejemplo, agregando la revisión o anotación de entradas y salidas a la rotación de guardias

Operaciones 2. Trabajar con modelos

  • Usar APIs de LLM permite depender de la inteligencia de unos pocos proveedores
    • Eso es algo bueno, pero esta dependencia implica trade-offs en rendimiento, latencia, throughput y costo
  • Además, dado que en el último año se lanzaron modelos más nuevos y mejores casi cada mes, hay que estar preparado para actualizar el producto al retirar modelos antiguos y migrar a otros nuevos
    • Esta sección comparte lecciones aprendidas al usar una tecnología que no puede controlarse por completo; es decir, una tecnología cuyos modelos no se pueden autohospedar ni administrar directamente
  • En la mayoría de los casos de uso reales, la salida del LLM será consumida por aplicaciones downstream mediante algún tipo de formato legible por máquina
    • Por ejemplo, ReChat, un CRM inmobiliario, necesita respuestas estructuradas para renderizar widgets en el frontend
    • De manera similar, Boba, una herramienta para generar ideas de estrategia de producto, necesita salidas estructuradas con campos de título, resumen, puntaje de viabilidad y rango de tiempo
    • Por último, LinkedIn compartió cómo restringió un LLM para generar YAML, que se usa para decidir qué técnica utilizar y proporcionar los parámetros para invocarla
  • Este patrón de aplicación es una versión extrema de la ley de Postel
    • Hay que ser liberal en lo que se acepta (lenguaje natural arbitrario) y conservador en lo que se envía (objetos tipados y legibles por máquina)
    • Por lo tanto, se espera que esto sea muy duradero
  • Actualmente, Instructor y Outlines son los estándares de facto para obtener salidas estructuradas de un LLM
    • Si usas APIs de LLM (por ejemplo, Anthropic, OpenAI), usa Instructor; si usas modelos autohospedados (por ejemplo, Huggingface), usa Outlines

Migrar prompts entre modelos es doloroso

  • A veces, un prompt cuidadosamente elaborado puede funcionar de maravilla en un modelo, pero no funcionar bien en otro.
    • Esto puede ocurrir no solo al cambiar entre distintos proveedores de modelos, sino también al actualizar entre versiones del mismo modelo.
  • Por ejemplo, Voiceflow descubrió que migrar de gpt-3.5-turbo-0301 a gpt-3.5-turbo-1106 provocaba una caída del 10% en el rendimiento de la tarea de clasificación de intenciones.
    • (Por suerte, ¡tenían evaluaciones!)
  • De forma similar, GoDaddy observó una tendencia positiva en la que, al actualizar a la versión 1106, se reducía la brecha de rendimiento entre gpt-3.5-turbo y gpt-4.
    • (O, si eres de los que ve el vaso medio lleno, tal vez podrías sentirte decepcionado de que la ventaja de gpt-4 se redujera con la nueva actualización).
  • Por lo tanto, si necesitas migrar prompts entre modelos, debes esperar que tome más tiempo que simplemente cambiar el endpoint de la API.
    • No asumas que conectar el mismo prompt producirá resultados similares o mejores.
  • Además, contar con evaluaciones confiables y automatizadas ayuda a medir el rendimiento de la tarea antes y después de la migración, y reduce el esfuerzo necesario para la validación manual.

Gestión y fijación de versiones del modelo

  • En cualquier pipeline de aprendizaje automático, "si cambias cualquier cosa, cambia todo".
    • Esto es especialmente relevante cuando dependemos de componentes como los modelos de lenguaje grandes (LLM), que no entrenamos nosotros mismos y que pueden cambiar sin que lo sepamos.
  • Afortunadamente, muchos proveedores de modelos ofrecen la opción de "fijar" una versión específica del modelo (por ejemplo, gpt-4-turbo-1106).
    • Esto te permite usar una versión específica de los pesos del modelo para que no cambie.
  • Fijar la versión del modelo en producción puede evitar cambios inesperados en el comportamiento del modelo.
    • Esto puede ayudar a evitar quejas de clientes por problemas como salidas demasiado verbosas u otros modos de fallo imprevistos que pueden aparecer cuando se sustituye el modelo.
  • También conviene considerar mantener un "pipeline sombra" que replique la configuración de producción, pero use la versión más reciente del modelo.
    • Esto permite experimentar y probar con seguridad las nuevas versiones.
  • Después de validar la estabilidad y calidad de las salidas en estos nuevos modelos, puedes actualizar con confianza la versión del modelo en el entorno de producción.

Elegir el modelo más pequeño que pueda completar la tarea

  • Al trabajar en una nueva aplicación, es tentador usar el modelo más grande y potente disponible.
    • Sin embargo, una vez confirmado que la tarea es técnicamente posible, vale la pena experimentar para ver si un modelo más pequeño puede lograr resultados similares.
  • Las ventajas de los modelos pequeños son una menor latencia y menor costo.
    • Aunque pueden ser menos capaces, técnicas como Chain-of-Thought, prompts n-shot y aprendizaje en contexto pueden ayudar a que un modelo pequeño rinda por encima de sus capacidades.
  • Más allá de las API de LLM, el ajuste fino para tareas específicas también puede ayudar a mejorar el rendimiento.
  • En conjunto, un workflow cuidadosamente diseñado con modelos pequeños puede ser más rápido y barato, y aun así igualar o incluso superar la calidad de salida de un único modelo grande.
    • Por ejemplo, este tuit comparte una anécdota sobre cómo Haiku + un prompt de 10 shots supera a Opus en zero-shot y a GPT-4.
  • A largo plazo, es de esperarse que aparezcan más casos de ingeniería de flujos con modelos pequeños que logren el mejor equilibrio entre calidad de salida, latencia y costo.
  • Otro ejemplo es la humilde tarea de clasificación.
    • Modelos ligeros como DistilBERT (67 millones de parámetros) son una línea base sorprendentemente sólida.
    • DistilBART, con 400 millones de parámetros, es otra excelente opción.
      • Cuando se ajusta finamente con datos open source, puede identificar alucinaciones con un ROC-AUC de 0.84, superando a la mayoría de los LLM con menos del 5% de la latencia y el costo.
  • La idea clave es que no debemos pasar por alto los modelos pequeños.
    • Es fácil aplicar modelos enormes a todos los problemas, pero con un poco de creatividad y experimentación, a menudo podemos encontrar soluciones más eficientes.

Operaciones 3. Producto

  • La nueva tecnología ofrece nuevas posibilidades, pero los principios para construir grandes productos son eternos.
    • Por eso, incluso si estás resolviendo un problema nuevo por primera vez, no hace falta reinventar la rueda en el diseño de producto.
  • Hay mucho por ganar al basar el desarrollo de aplicaciones con LLM en fundamentos sólidos de producto.
    • Eso nos permite ofrecer valor real a las personas a las que servimos.

Involucrar diseño desde el inicio

  • Tener diseñadores nos obliga a entender y reflexionar profundamente sobre cómo podemos construir el producto y presentarlo a los usuarios.
    • A veces se cae en el estereotipo de ver a los diseñadores como personas que hacen que las cosas se vean bonitas.
    • Pero también reconsideran cómo mejorar la experiencia de usuario, incluso si eso implica romper reglas y paradigmas existentes, no solo la interfaz de usuario.
  • Los diseñadores tienen un talento especial para reformular las necesidades de los usuarios en distintas formas.
    • Algunas de esas formas son más fáciles de resolver que otras, por lo que pueden ofrecer más o menos oportunidades para soluciones con IA.
  • Como ocurre con muchos otros productos, construir productos de IA debe girar en torno al trabajo que se quiere realizar, no a la tecnología que impulsa el producto.
  • Conviene enfocarse en hacerse preguntas como las siguientes:
    • "¿Qué tarea le pide el usuario a este producto? ¿Es una tarea en la que un chatbot podría destacar? ¿Y el autocompletado? ¡Tal vez sea otra cosa!"
  • Considera los patrones de diseño existentes y cómo se relacionan con el trabajo que se quiere realizar.
    • Estos son activos valiosos que los diseñadores aportan a las capacidades del equipo.

Diseñar la UX para el humano en el circuito

  • Una forma de obtener anotaciones de buena calidad es integrar Human-in-the-Loop (HITL) en la experiencia de usuario (UX)
    • Si se facilita que el usuario proporcione retroalimentación y correcciones, se puede mejorar la salida inmediata y recopilar datos útiles para mejorar el modelo
  • Imaginemos una plataforma de comercio electrónico donde los usuarios suben y clasifican productos
    • Hay varias formas de diseñar la UX
      1. El usuario selecciona manualmente la categoría correcta del producto, y el LLM revisa periódicamente los productos nuevos y corrige en el backend las clasificaciones incorrectas
      2. El usuario no selecciona ninguna categoría, y el LLM clasifica periódicamente los productos en el backend (con posibles errores)
      3. El LLM sugiere la categoría del producto en tiempo real, y el usuario puede validarla y actualizarla según sea necesario
  • Los tres enfoques incluyen un LLM, pero ofrecen UX muy diferentes
    • El primer enfoque pone la carga inicial sobre el usuario y el LLM actúa como una verificación posterior
    • El segundo enfoque no requiere ningún esfuerzo del usuario, pero no ofrece transparencia ni control
    • El tercer enfoque mantiene un equilibrio adecuado
      • Al sugerir categorías de antemano, el LLM reduce la carga cognitiva del usuario y evita que tenga que aprender nuestra taxonomía para clasificar productos
      • Al mismo tiempo, al permitir que el usuario revise y edite las sugerencias, deja firmemente en manos del usuario la decisión final sobre cómo se clasifica el producto
    • Como bono, el tercer enfoque crea un ciclo natural de retroalimentación para mejorar el modelo
      • Las buenas sugerencias se aceptan (etiqueta positiva) y las malas se actualizan (etiqueta negativa seguida de positiva)
  • Este patrón de sugerencias, validación por parte del usuario y recopilación de datos se ve comúnmente en muchas aplicaciones
    • Asistentes de programación: el usuario puede aceptar una sugerencia (positivo fuerte), aceptarla y ajustarla (positivo) o ignorarla (negativo)
    • Midjourney: el usuario puede escalar y descargar una imagen (positivo fuerte), modificar la imagen (positivo) o generar un nuevo conjunto de imágenes (negativo)
    • Chatbots: el usuario puede dar me gusta (positivo) o no me gusta (negativo) a una respuesta, o elegir regenerarla si la respuesta es realmente mala (negativo fuerte)
  • La retroalimentación puede ser explícita o implícita
    • La retroalimentación explícita es información que el usuario proporciona en respuesta a una solicitud del producto
    • La retroalimentación implícita es información que se aprende de la interacción del usuario sin que este tenga que dar feedback de forma intencional
  • Los asistentes de programación y Midjourney son ejemplos de retroalimentación implícita, y los me gusta y no me gusta son retroalimentación explícita
    • Si se diseña bien la UX, como en los asistentes de programación y Midjourney, se puede recopilar mucha retroalimentación implícita para mejorar el producto y el modelo

Priorizar sin piedad la jerarquía de requisitos

  • Al pensar en llevar un demo a producción, hay que considerar requisitos sobre lo siguiente
    • Confiabilidad: 99.9% de uptime, cumplimiento de salidas estructuradas
    • Inocuidad: no generar contenido ofensivo, NSFW u otro contenido dañino
    • Consistencia factual: mantenerse fiel al contexto proporcionado y no distorsionar los hechos
    • Utilidad: ser relevante para las necesidades y solicitudes del usuario
    • Escalabilidad: SLA de latencia, throughput soportado
    • Costo: porque el presupuesto no es ilimitado
    • Otros: seguridad, privacidad, equidad, GDPR, DMA, etc.
  • Si intentas resolver todos estos requisitos al mismo tiempo, no podrás lanzar nada
    • Por eso hay que priorizar. Sin piedad.
  • Esto significa dejar claro cuáles son los puntos no negociables sin los cuales el producto no funcionará o no será viable (por ejemplo, confiabilidad e inocuidad)
    • Es importante identificar el producto MVP (Minimum Lovable Product)
  • Hay que aceptar que la primera versión no será perfecta, lanzarla e iterarla

Ajustar el nivel de tolerancia al riesgo según el caso de uso

  • Al decidir el nivel de revisión de los modelos de lenguaje y las aplicaciones, hay que considerar el caso de uso y el público objetivo
    • En el caso de un chatbot de cara al cliente que ofrece asesoría médica o financiera, se necesita un estándar muy alto de seguridad y precisión
      • Los errores o salidas incorrectas pueden causar daños reales y hacer que se pierda la confianza
    • Pero en aplicaciones menos críticas, como un sistema de recomendaciones, o en aplicaciones internas como clasificación o resumen de contenido, unos requisitos excesivamente estrictos solo frenan el avance sin aportar mucho valor
  • Esto coincide con un informe reciente de a16z que señala que muchas empresas se están moviendo más rápido con aplicaciones internas de LLM que con aplicaciones externas
    • Al experimentar con IA para la productividad interna, las organizaciones pueden empezar a capturar valor mientras aprenden a gestionar el riesgo en un entorno más controlado
    • Luego, cuando ganen confianza, pueden expandirse a casos de uso de cara al cliente

Operaciones 4. Equipo y roles

  • Ningún puesto es fácil de definir, pero redactar una descripción de puesto para el trabajo en esta nueva área es más difícil que en otras
    • Omitiré diagramas de Venn sobre puestos superpuestos o sugerencias de descripciones de puesto
    • Sin embargo, reconoceré la existencia de un nuevo rol, el ingeniero de IA, y hablaré sobre ese rol
  • Lo importante es cómo deberían asignarse el resto del equipo y las responsabilidades

Enfocarse en el proceso, no en las herramientas

  • Cuando se enfrentan a un nuevo paradigma como los LLM, los ingenieros de software tienden a favorecer las herramientas
    • Como resultado, pasan por alto los problemas y procesos que esas herramientas intentaban resolver
    • Al hacerlo, muchos ingenieros terminan asumiendo complejidad accidental, lo que trae consecuencias negativas para la productividad a largo plazo del equipo
  • Por ejemplo, este artículo explica cómo cierta herramienta puede generar automáticamente prompts para modelos de lenguaje grandes
    • Sostiene (y en mi opinión, con razón) que los ingenieros que usan estas herramientas sin entender primero la metodología o el proceso de resolución del problema terminan cargando con deuda técnica innecesaria
  • Además de la complejidad accidental, las herramientas muchas veces están insuficientemente especificadas
    • Por ejemplo, está creciendo una industria de herramientas de evaluación de LLM que ofrece una “caja de herramientas de evaluación de LLM” con evaluadores generales para toxicidad, concisión, tono, etc.
    • He visto a muchos equipos adoptar estas herramientas sin pensar críticamente en los modos de falla específicos de su dominio
  • En contraste, EvalGen se enfoca en enseñarle al usuario el proceso de crear evaluaciones específicas por dominio, involucrándolo profundamente en cada etapa, como especificar criterios, etiquetar datos y revisar evaluaciones
    • El software guía al usuario a través de un flujo de trabajo como el siguiente
  • Mejores prácticas para crear evaluaciones de LLM guiadas por EvalGen
    1. Definir pruebas específicas por dominio (inicializadas automáticamente a partir de prompts)
      • Definidas como aserciones en código o con LLM-as-a-Judge
    2. La importancia de alinear las pruebas con el juicio humano para que el usuario pueda verificar si las pruebas capturan los criterios especificados
    3. Iterar sobre las pruebas a medida que el sistema (prompts, etc.) cambia
  • EvalGen proporciona a los desarrolladores un modelo mental del proceso de construcción de evaluaciones, pero no los ata a una herramienta específica
    • Descubrimos que, después de dar este contexto a los ingenieros de IA, a menudo deciden elegir herramientas más simples o construir las suyas propias
  • Además de la escritura de prompts y la evaluación, hay tantos componentes en los LLM que no es posible enumerarlos todos aquí
    • Sin embargo, es importante que los ingenieros de IA intenten entender el proceso antes de adoptar herramientas

Experimentar siempre

  • Los productos de ML están profundamente vinculados a la experimentación
    • Esto no solo significa pruebas A/B y ensayos controlados aleatorios, sino también intentos frecuentes de modificar el componente más pequeño posible del sistema y realizar evaluaciones offline
    • La razón por la que todos están tan entusiasmados con la evaluación no tiene que ver realmente con la confiabilidad ni con la confianza, sino con hacer posible la experimentación.
      • Cuanto mejor sea la evaluación, más rápido se pueden iterar los experimentos y, por lo tanto, más rápido se puede converger a la mejor versión del sistema
  • Como experimentar se ha vuelto muy barato, es común probar distintos enfoques para resolver el mismo problema
    • Los altos costos de recopilar datos y entrenar modelos se han minimizado
      • El costo de la ingeniería de prompts es apenas un poco más que tiempo humano
    • Vale la pena organizar al equipo para que todos puedan aprender los fundamentos de la ingeniería de prompts
      • Esto anima a todos a experimentar y genera ideas diversas en toda la organización
  • No experimentes solo para explorar; usa los experimentos también para explotar lo aprendido.
    • ¿Ya existe una versión funcional de una tarea nueva?
      • Vale la pena considerar que otra persona del equipo la aborde de una manera diferente
    • Inténtalo de otra forma que pueda ser más rápida
    • Investiga técnicas de prompting como Chain-of-Thought o Few-Shot para mejorar la calidad
    • Asegúrate de que las herramientas no obstaculicen la experimentación
      • Si lo hacen, compra algo que puedas reconstruir o mejorar
  • Durante la planificación de productos/proyectos, reserva tiempo específicamente para construir evaluaciones y ejecutar múltiples experimentos
    • Piensa en la especificación del producto como si fuera una especificación para un producto de ingeniería, y añade criterios claros para la evaluación
  • Al crear la hoja de ruta, no subestimes el tiempo necesario para experimentar
    • Anticipa múltiples iteraciones de desarrollo y evaluación antes de obtener la aprobación para producción

Empoderar a todos para que usen nuevas tecnologías de IA

  • A medida que aumenta la adopción de la IA generativa, queremos que no solo los especialistas, sino todo el equipo, sienta que puede entender y usar esta nueva tecnología
    • No hay mejor forma de desarrollar intuición sobre cómo funcionan los LLM (por ejemplo, latencia, modos de falla, UX)
    • Los LLM son relativamente accesibles
      • No hace falta saber programar para mejorar el rendimiento de un pipeline, y cualquiera puede contribuir mediante ingeniería de prompts y evaluación
  • Una gran parte de esto es la capacitación
    • Se puede empezar por los fundamentos de la ingeniería de prompts, como técnicas que ayudan a condicionar el modelo hacia la salida deseada, por ejemplo el prompting n-shot y CoT
  • Quienes ya tienen conocimientos también pueden enseñar aspectos más técnicos, como que los LLM son inherentemente autorregresivos
    • Es decir, los tokens de entrada se procesan en paralelo, pero los tokens de salida se generan de manera secuencial
    • Por eso, la latencia depende más de la longitud de la salida que de la longitud de la entrada
      • Esto es una consideración clave al diseñar la UX y al establecer expectativas de rendimiento
  • También se pueden ofrecer oportunidades prácticas para experimentar y explorar
    • ¿Qué tal un hackathon?
      • Puede parecer caro que todo el equipo dedique varios días a desarrollar proyectos especulativos, pero los resultados pueden sorprenderte
    • Hubo un equipo que, mediante un hackathon, casi completó una hoja de ruta de 3 años en 1 año
      • Otro equipo llegó, a través de un hackathon, a una UX que cambió el paradigma y que ahora es posible gracias a los LLM, y eso se convirtió en una prioridad para este año y los siguientes

No caigas en la trampa de pensar que “la ingeniería de IA lo es todo”

  • Cuando surge un nuevo puesto, al principio suele haber una tendencia a sobreestimar las capacidades asociadas con ese rol
    • Esto a menudo conduce a correcciones dolorosas cuando el alcance real de ese trabajo se vuelve más claro
    • Quienes son nuevos en este campo y los responsables de contratación pueden hacer afirmaciones exageradas o tener expectativas excesivas
  • Algunos ejemplos notables de los últimos 10 años son los siguientes
    • Científico de datos: “alguien que sabe más estadística que cualquier ingeniero de software y más ingeniería de software que cualquier estadístico”
    • Ingeniero de machine learning (MLE): una perspectiva centrada en la ingeniería de software aplicada al machine learning
  • Al principio, muchas personas asumían que para los proyectos basados en datos bastaba con científicos de datos
    • Pero quedó claro que los científicos de datos deben colaborar con ingenieros de software y de datos para desarrollar y desplegar productos de datos de forma efectiva
  • Este malentendido volvió a aparecer con el nuevo rol de ingeniero de IA, y algunos equipos creen que los ingenieros de IA son todo lo que necesitan
    • En realidad, construir productos de machine learning o IA requiere una amplia variedad de roles especializados
  • Hemos asesorado a más de 12 empresas sobre productos de IA y observamos de manera consistente que caen en la trampa de creer que “la ingeniería de IA es todo lo que hace falta”
    • Como resultado, a menudo los productos tienen dificultades para escalar más allá de una demo, mientras se pasan por alto aspectos críticos necesarios para construir el producto
  • Por ejemplo, la evaluación y la medición son esenciales para escalar un producto más allá de una simple revisión subjetiva
    • Las habilidades necesarias para una evaluación eficaz coinciden con algunas de las fortalezas que tradicionalmente se ven en los ingenieros de machine learning
      • Es probable que un equipo compuesto solo por ingenieros de IA carezca de estas habilidades
  • El coautor Hamel Husain explica la importancia de estas habilidades en trabajos recientes relacionados con la detección de sesgos en datos y el diseño de evaluaciones específicas por dominio
  • Los tipos de roles necesarios y el momento en que se necesitan en el recorrido de creación de un producto de IA
    1. Primero, enfócate en construir el producto
    • Puede incluir ingenieros de IA, pero no son necesariamente indispensables
    • Los ingenieros de IA son útiles para prototipar el producto (UX, plumbing, etc.) e iterar rápidamente
    1. Luego, instrumenta el sistema y recopila datos para construir la base correcta
    • Dependiendo del tipo y la escala de los datos, puede que necesites ingenieros de plataforma y/o de datos
    • También debe existir un sistema para consultar y analizar esos datos con el fin de depurar problemas
    1. Después, optimiza el sistema de IA
    • Esto no necesariamente implica entrenar modelos
    • Los fundamentos incluyen pasos como diseñar métricas, construir sistemas de evaluación, ejecutar experimentos, optimizar la recuperación en RAG y depurar sistemas probabilísticos
    • Los MLE son muy competentes en esta área (aunque los ingenieros de IA también pueden adquirir estas habilidades)
    • Si no se han completado los pasos previos, normalmente no tiene sentido contratar a un MLE
  • Además de esto, siempre se necesitan expertos del dominio
    • En una empresa pequeña, idealmente el equipo fundador debería cumplir ese papel, y en una empresa grande puede asumirlo el gerente de producto
  • Es importante reconocer la progresión y el momento adecuado de los roles
    • Contratar a las personas en el momento equivocado (por ejemplo, contratar a un MLE demasiado pronto) o construir en el orden incorrecto desperdicia tiempo y dinero, y provoca rotación
  • Además, consultar regularmente con un MLE en las etapas 1 y 2 (sin contratarlo de tiempo completo) puede ayudar a la empresa a construir la base correcta

[Estrategia: cómo no quedarse atrás al construir con LLM]

  • Para desarrollar productos exitosos se necesita planificación cuidadosa y priorización, en lugar de crear prototipos sin rumbo o perseguir el modelo o la tendencia más reciente
  • Al desarrollar productos de IA, hay que revisar trade-offs clave, como desarrollar internamente o comprar
  • Se presenta un “playbook” para el desarrollo inicial de aplicaciones con LLM

Estrategia 1: sin GPU antes del PMF

  • Para convertirse en un gran producto, tiene que ser algo más que un simple envoltorio ligero sobre la API de otra persona
  • Pero equivocarse en la dirección opuesta puede costar aún más
    • El año pasado se gastó una enorme cantidad de capital de riesgo en entrenamiento y personalización de modelos sin una visión clara del producto ni un mercado objetivo definido
    • Una empresa incluso llegó a recibir una inversión Serie A de nada menos que 6 mil millones de dólares
  • En esta sección se explicará por qué es un error empezar de inmediato a entrenar tu propio modelo y se considerará el papel del self-hosting

Reentrenar (casi) desde cero desde el principio no tiene sentido

  • Para la mayoría de las organizaciones, preentrenar un LLM desde cero es algo poco realista y fuera del foco del desarrollo de producto
    • Desarrollar y mantener infraestructura de machine learning requiere muchos recursos
      • Incluye recolección de datos, entrenamiento y evaluación del modelo, despliegue, etc.
    • Si estás en la etapa de validar el product-market fit, este esfuerzo dispersa recursos del desarrollo del producto principal
    • Incluso si tienes recursos de cómputo, datos y capacidad técnica, un LLM preentrenado puede quedar obsoleto en cuestión de meses
  • El caso de BloombergGPT
    • BloombergGPT, un LLM especializado en tareas financieras, fue preentrenado con 363B tokens
    • Se requirió un enorme esfuerzo de 9 empleados de tiempo completo, incluidos 4 de AI engineering y 5 de producto e investigación de ML
    • Aun así, en menos de un año quedó por detrás de gpt-3.5-turbo y gpt-4 en esas tareas
  • Estos casos sugieren que, en la mayoría de las aplicaciones reales, preentrenar un LLM desde cero no es el mejor uso de los recursos
    • En su lugar, es mejor que el equipo haga fine-tuning del modelo open source más potente disponible según sus necesidades específicas
  • Claro que hay excepciones
    • El modelo de código de Replit es un gran ejemplo de preentrenamiento especializado en generación y comprensión de código
    • Mediante preentrenamiento mostró un rendimiento superior al de modelos más grandes como CodeLlama7b
    • Sin embargo, conforme salieron modelos más potentes, fue necesaria una inversión continua para mantener su utilidad

No hacer fine-tuning hasta confirmar que realmente hace falta

  • En la mayoría de las organizaciones, el fine-tuning está impulsado por FOMO (Fear Of Missing Out, miedo a quedarse fuera) más que por pensamiento estratégico
    • Las organizaciones invierten en fine-tuning demasiado pronto para evitar críticas de ser un “wrapper simple”
    • En realidad, el fine-tuning es como artillería pesada que solo debería desplegarse después de reunir suficientes casos que demuestren que otros enfoques no bastan
  • Hace un año muchos equipos expresaban entusiasmo por el fine-tuning, pero pocos encontraron product-market fit y la mayoría terminó arrepintiéndose de la decisión
    • Si vas a hacer fine-tuning, debes estar preparado para repetirlo conforme mejore el modelo base
      • Consulta abajo “El modelo no es el producto” y “Construir LLMOps”
  • Casos en los que el fine-tuning sí puede ser la elección correcta
    • Cuando necesitas datos que no están disponibles en la mayoría de los datasets abiertos a escala web usados para entrenar modelos existentes
    • Cuando ya construiste un MVP que demuestra que los modelos existentes no son suficientes
    • Pero cuidado: si ni los creadores del modelo pueden conseguir fácilmente buenos datos de entrenamiento, ¿de dónde los vas a sacar tú?
  • Las aplicaciones basadas en LLM no son proyectos de feria de ciencias
    • La inversión debe estar a la altura de su contribución a los objetivos estratégicos y a la diferenciación competitiva

Empezar con APIs de inferencia, pero no tener miedo al self-hosting

  • Usar APIs de LLM permite que las startups adopten e integren capacidades de modelado de lenguaje fácilmente sin entrenar sus propios modelos desde cero
    • Proveedores como Anthropic y OpenAI ofrecen APIs generales que pueden darle inteligencia a un producto con solo unas líneas de código
    • Usar estos servicios reduce el esfuerzo y permite enfocarse en crear valor para el cliente, validando ideas e iterando hacia el product-market fit más rápido
  • Pero, igual que con las bases de datos, los servicios administrados no sirven para todos los casos de uso conforme crecen la escala y los requisitos
    • De hecho, el self-hosting puede ser la única forma de usar modelos sin enviar datos confidenciales o personales fuera de la red, como exigen industrias reguladas como salud y finanzas, o por obligaciones contractuales y requisitos de confidencialidad
  • Además, el self-hosting evita restricciones impuestas por los proveedores de inferencia, como rate limits, discontinuación de modelos o límites de uso
    • El self-hosting da control total sobre el modelo, lo que facilita construir sistemas diferenciados y de alta calidad
  • Por último, el self-hosting, especialmente con fine-tuning, puede reducir costos a gran escala
    • Por ejemplo, Buzzfeed compartió un caso en el que redujo costos en 80% al hacer fine-tuning de un LLM open source

Estrategia 2: iterar hacia algo mejor

  • Para mantener una ventaja competitiva a largo plazo, hay que pensar en cómo diferenciar el producto más allá del modelo
  • La velocidad de ejecución importa, pero no debería ser la única ventaja

El modelo no es el producto; el producto es el sistema alrededor del modelo

  • Para los equipos que no construyen modelos, el rápido ritmo de innovación es una bendición
    • Porque pueden migrar al modelo más reciente en busca de mejoras en tamaño de contexto, capacidad de razonamiento y relación valor-precio para crear un mejor producto
    • Estos avances son emocionantes de una manera casi predecible
    • En conjunto, es probable que el modelo sea el componente menos duradero del sistema
  • En cambio, hay que concentrar el esfuerzo en las partes que sí pueden ofrecer valor sostenido
    • Evals: para medir de forma confiable el rendimiento de la tarea entre distintos modelos
    • Guardrails: para evitar salidas no deseadas sin importar el modelo
    • Caching: para reducir latencia y costo evitando por completo el modelo
    • Data flywheel: para impulsar la mejora iterativa de todo lo anterior
    • Estos componentes crean un foso de calidad de producto más profundo que las capacidades crudas del modelo
  • Pero eso no significa que construir en la capa de aplicación esté libre de riesgos
    • Si OpenAI u otro proveedor de modelos va a ofrecer software empresarial viable, no recortes en donde ellos terminarán recortando
  • Por ejemplo, algunos equipos invirtieron en construir herramientas personalizadas para validar salidas estructuradas de modelos propietarios
    • Una inversión mínima aquí sí importa, pero invertir a fondo no es un buen uso del tiempo
    • OpenAI debe garantizar que, al solicitar function calling, recibas llamadas válidas, porque eso es algo que todos los clientes quieren
    • Aplica aquí la “postergación estratégica”: construye solo lo absolutamente necesario y espera a que el proveedor amplíe sus capacidades

Empezar en pequeño y ganarse la confianza

  • Construir un producto que quiera ser todo para todos es una receta para la mediocridad
  • Para crear un producto convincente, las empresas deben especializarse en construir experiencias pegajosas que hagan que los usuarios vuelvan
  • Consideremos un sistema RAG genérico que busca responder cualquier pregunta del usuario
    • La falta de especialización significa que el sistema no puede priorizar información reciente, analizar formatos específicos del dominio ni entender los matices de tareas concretas
    • Como resultado, el usuario tiene una experiencia superficial y poco confiable, que no cumple sus necesidades y termina abandonando
  • Para resolverlo, hay que enfocarse en dominios y casos de uso específicos
    • Hay que reducir el alcance y agregar profundidad en lugar de amplitud
    • Esto permite crear herramientas especializadas por dominio que conecten con el usuario
  • La especialización también permite comunicar con honestidad las capacidades y limitaciones del sistema
    • Ser transparente sobre lo que el sistema puede y no puede hacer demuestra autoconciencia, ayuda a entender dónde puede aportar más valor al usuario y, en consecuencia, construye confianza en los resultados

Construir LLMOps, pero con la razón correcta: iteración rápida

  • DevOps no se trata fundamentalmente de flujos de trabajo reproducibles, de hacer shift-left ni de empoderar a equipos de dos pizzas. Mucho menos de escribir archivos YAML
  • DevOps consiste en acortar el ciclo de retroalimentación entre el trabajo y sus resultados para que se acumulen mejoras en lugar de errores
    • Sus raíces se remontan, a través del movimiento lean startup, a la manufactura lean y al Sistema de Producción de Toyota, con énfasis en el cambio de troquel en un solo dígito de minutos y el kaizen
  • MLOps aplicó la forma de DevOps al ML
    • Existen suites de herramientas todo en uno para experimentos reproducibles y para empoderar a quienes construyen modelos a desplegarlos. También hay muchos archivos YAML
  • Pero como industria, MLOps no adoptó la función de DevOps. No redujo la brecha de retroalimentación entre los modelos y la inferencia e interacción en producción
  • Por suerte, el campo de LLMOps ha ido más allá de problemas triviales como la gestión de prompts y ha virado hacia la mejora continua conectada con problemas difíciles que bloquean la iteración, como el monitoreo y la evaluación en producción
  • Ya existen arenas conversacionales para evaluaciones neutrales y crowdsourced de modelos de chat y de código. Son el bucle externo de mejora colectiva e iterativa
    • Herramientas como LangSmith, Log10, LangFuse, W&B Weave y HoneyHive prometen no solo recopilar y organizar datos sobre los resultados del sistema en producción, sino también integrarse profundamente con el desarrollo para usarlos en la mejora de ese sistema. Adóptalas o constrúyelas por tu cuenta

No construyas capacidades de LLM que puedas comprar

  • La mayoría de los negocios exitosos no son negocios de LLM. Al mismo tiempo, la mayoría de los negocios tienen oportunidades de mejora con LLM
  • Estas dos observaciones a menudo confunden a los líderes y los llevan a reacondicionar apresuradamente sistemas con LLM, aumentando costos y reduciendo calidad, para lanzarlos con funciones de "AI" artificiales y vanidosas. El temido ícono brillante de turno ya quedó listo
  • Hay una mejor manera: enfocarse en aplicaciones de LLM que realmente se alineen con los objetivos del producto y fortalezcan la operación central
  • Consideremos algunos intentos equivocados que desperdician el tiempo del equipo
    • Construir una función personalizada de text-to-SQL para el negocio
    • Construir un chatbot con el que se pueda conversar sobre documentos
    • Integrar la base de conocimiento de la empresa con un chatbot de soporte al cliente
  • Aunque lo anterior sea el hello world de las aplicaciones con LLM, no tiene mucho sentido que una empresa de producto lo construya por sí misma
    • Son problemas genéricos comunes a muchos negocios, con una gran brecha entre demos prometedoras y componentes confiables, y pertenecen al territorio habitual de las empresas de software
    • Es un desperdicio invertir recursos valiosos de R&D en problemas genéricos que la camada actual de Y Combinator ya está resolviendo a escala
  • Si esto suena a consejo empresarial trillado, es porque en medio de la emoción desbordada de la ola actual de hype es fácil confundir algo "LLM" con algo de punta y diferenciado, y pasar por alto aplicaciones que ya están muy gastadas

Pon a la AI dentro del loop y al ser humano en el centro

  • Las aplicaciones actuales basadas en LLM son frágiles. Requieren enormes cantidades de guardrails e ingeniería defensiva, y aun así siguen siendo difíciles de predecir. Además, cuando se acotan rigurosamente, estas aplicaciones pueden ser increíblemente útiles. Eso significa que los LLM son excelentes herramientas para acelerar los flujos de trabajo de los usuarios
  • Puede ser tentador imaginar aplicaciones basadas en LLM que reemplacen por completo un flujo de trabajo o sustituyan una función laboral, pero hoy el paradigma más efectivo es el centauro humano-computadora (Centaur chess)
    • Un ser humano competente, combinado con capacidades de LLM ajustadas para su uso rápido, puede mejorar enormemente la productividad y la satisfacción al realizar el trabajo
    • GitHub CoPilot, una de las aplicaciones emblemáticas de los LLM, ha demostrado el poder de este tipo de flujo de trabajo
      • "En general, los desarrolladores dijeron que, al usar GitHub Copilot y GitHub Copilot Chat, sentían que programar era más fácil y que el resultado tenía menos errores, era más legible, más reutilizable, más conciso, más fácil de mantener y más resiliente." - Mario Rodriguez, GitHub
  • Quienes llevan mucho tiempo trabajando en ML pueden llegar rápidamente a la idea de "human-in-the-loop", pero no te apresures tanto
    • El machine learning HITL es un paradigma basado en expertos humanos que garantizan que los modelos de ML se comporten como se espera
    • Lo que se propone aquí está relacionado, pero es más matizado. Los sistemas basados en LLM no deberían ser hoy el motor principal de la mayoría de los flujos de trabajo; simplemente deberían ser un recurso
  • Poner al ser humano en el centro y preguntarse cómo los LLM pueden apoyar el flujo de trabajo tiene implicaciones bastante distintas para las decisiones de producto y diseño
    • En última instancia, terminarás construyendo un producto distinto al de los competidores que quieren subcontratarle rápidamente toda la responsabilidad al LLM: un producto mejor, más útil y menos riesgoso

Estrategia 3. Empezar con prompting, evals y recolección de datos

  • En la sección anterior se lanzó una gran cantidad de técnicas y consejos. Es mucho para asimilar. Consideremos el conjunto mínimo de consejos útiles
    • Si un equipo quiere crear un producto con LLM, ¿por dónde debería empezar?
  • En el último año hemos visto lo suficiente como para estar convencidos de que las aplicaciones exitosas con LLM siguen una trayectoria consistente. En esta sección veremos este playbook básico para "empezar"
  • La idea central es comenzar de forma simple y agregar complejidad según sea necesario
    • Rule of Thumb: cada nivel de sofisticación normalmente requiere al menos un orden de magnitud más de esfuerzo que la etapa anterior. Teniendo eso en mente...

La ingeniería de prompts es la prioridad número uno

  • Empieza con ingeniería de prompts
    • Usa todas las técnicas discutidas antes en la sección de tácticas
    • Chain-of-thought, ejemplos n-shot y entradas/salidas estructuradas casi siempre son una buena idea
    • Haz prototipos con el modelo de mayor rendimiento antes de intentar exprimir desempeño de un modelo más débil
  • Solo deberías considerar fine-tuning si no puedes alcanzar el nivel de desempeño deseado con ingeniería de prompts
    • Esto ocurrirá con más frecuencia si tienes requisitos no funcionales que bloquean el uso de modelos propietarios y exigen self-hosting, como privacidad de datos, control total o costos
    • Asegúrate de que esos mismos requisitos de privacidad no impidan usar datos de usuarios para el fine-tuning

Construye evaluaciones e inicia el data flywheel

  • Incluso los equipos que apenas comienzan necesitan evals. De lo contrario, no sabrán si la ingeniería de prompts es suficiente ni si un modelo fine-tuned está listo para reemplazar al modelo base
  • Las evaluaciones efectivas están especializadas en la tarea y reflejan el caso de uso previsto
    • El primer nivel de evaluación que recomendamos son las pruebas unitarias
    • Estas aserciones simples ayudan a detectar modos de falla conocidos o hipotéticos y a tomar decisiones iniciales de diseño
    • Consulta también otras evaluaciones específicas por tarea para clasificación, resumen, etc.
  • Las pruebas unitarias y las evaluaciones basadas en modelos son útiles, pero no reemplazan la necesidad de evaluación humana
    • Haz que las personas usen el modelo/producto y den retroalimentación
    • Esto cumple un doble propósito: medir el desempeño real y la tasa de defectos, al mismo tiempo que recopila datos anotados de alta calidad que pueden usarse para hacer fine-tuning de modelos futuros
    • Esto crea un bucle de retroalimentación positivo, o data flywheel, que genera interés compuesto con el tiempo
      • Evaluación humana para medir el desempeño del modelo o encontrar defectos
      • Usar datos anotados para hacer fine-tuning del modelo o actualizar los prompts
      • Repetir
  • Por ejemplo, al auditar defectos en resúmenes generados por LLM, puedes asignar etiquetas de retroalimentación granulares a cada oración para identificar inconsistencias fácticas, irrelevancia o mal estilo
    • Luego puedes usar esas anotaciones de inconsistencias fácticas para entrenar un clasificador de alucinaciones, o las anotaciones de relevancia para entrenar un modelo de recompensa de relevancia
  • LinkedIn compartió casos de éxito usando evaluadores basados en modelos para estimar alucinaciones, violaciones de AI responsable, coherencia y más
  • Al crear un activo cuyo valor aumenta con el tiempo, construir evals deja de ser un simple costo operativo y se convierte en una inversión estratégica, mientras en el proceso se construye el data flywheel

Estrategia 4. La tendencia de alto nivel de la cognición de bajo costo (The high-level trend of low-cost cognition)

  • En 1971, los investigadores de Xerox PARC predijeron el mundo de computadoras personales conectadas en red en el que vivimos hoy
    • Contribuyeron a hacer nacer ese futuro al desempeñar un papel clave en la invención de las tecnologías que lo hicieron posible (Ethernet, renderizado gráfico, mouse, ventanas, etc.)
  • También realizaron un ejercicio simple
    • Examinaron aplicaciones muy útiles (por ejemplo, pantallas de video) que todavía no eran económicamente viables (la RAM suficiente para manejar una pantalla de video costaba miles de dólares)
    • Luego observaron las tendencias históricas de precios de esa tecnología (similares a la ley de Moore) y predijeron cuándo se volvería económicamente viable
  • Se puede hacer lo mismo con la tecnología de los LLM, aunque no sea tan limpio como contar transistores por dólar
    • Elegir un benchmark popular usado durante mucho tiempo (por ejemplo, el dataset Massively-Multitask Language Understanding) y un enfoque de entrada consistente (5-shot prompting)
    • Luego comparar a lo largo del tiempo el costo de ejecutar modelos de lenguaje con distintos niveles de desempeño en ese benchmark
  • La capacidad está aumentando rápidamente para un costo fijo. Para un nivel de capacidad fijo, el costo está cayendo rápidamente
    • En los cuatro años desde que el modelo davinci de OpenAI se lanzó como API, el costo de ejecutar un modelo con un desempeño comparable para esa tarea a escala de 1 millón de tokens (alrededor de 100 copias de este documento) cayó de $20 a menos de 10 centavos. La vida media es de apenas 6 meses
    • De manera similar, a mayo de 2024, el costo de ejecutar Meta LLaMA 3 8B, ya sea por medio de un proveedor de API o por cuenta propia, es de solo 20 centavos por millón de tokens y muestra un desempeño similar al de text-davinci-003 de OpenAI, el modelo que hizo posible ChatGPT
    • Ese modelo también costaba alrededor de $20 por millón de tokens cuando se lanzó a fines de noviembre de 2023. En solo 18 meses ya hay una diferencia de dos dígitos. Es el mismo período en el que la ley de Moore predeciría un simple aumento al doble
  • Ahora consideremos aplicaciones de LLM muy útiles pero todavía no económicamente viables (como impulsar personajes generativos de videojuegos, al estilo de Park et al.) (se estima un costo de $625 por hora)
    • Desde que ese artículo se publicó en agosto de 2023, el costo ha bajado aproximadamente un orden de magnitud, a unos $62.50 por hora
    • Nueve meses después, podríamos esperar que baje a $6.25 por hora
  • Mientras tanto, cuando Pac-Man se lanzó en 1980, con el equivalente a $1 de hoy se podían comprar créditos para jugar durante varios minutos o algunas decenas de minutos. Llamémosle 6 partidas por hora o $6 por hora
    • Este cálculo rápido sugiere que una experiencia de juego atractiva potenciada por LLM será económicamente viable hacia 2025
  • Estas tendencias son nuevas y solo tienen unos pocos años. Pero hay pocas razones para esperar que este proceso se desacelere en los próximos años
    • Incluso si se agotan las oportunidades más obvias en algoritmos y datasets, como escalar más allá de la “proporción Chinchilla” de ~20 tokens por parámetro, una innovación e inversión más profundas dentro de los centros de datos y en la capa de silicio cerrarán esa brecha
  • Y este probablemente sea el hecho estratégico más importante
    • Las demos de laboratorio o los artículos de investigación que hoy son completamente inviables se convertirán en funciones premium en unos años, y poco después en commodities
    • Hay que construir sistemas y organizaciones teniendo eso en mente

[Las demos de 0 a 1 ya son suficientes. Ahora toca crear productos que vayan de 1 a N]

  • Crear demos con LLM es realmente divertido. Con unas pocas líneas de código, una base de datos vectorial y prompts escritos con cuidado se produce “magia”
  • Durante el último año, esta magia se ha comparado con internet, los smartphones e incluso la imprenta
  • Lamentablemente, como sabe cualquiera que haya trabajado en lanzar software real, hay una enorme diferencia entre una demo que funciona en un entorno controlado y un producto que funciona de forma confiable a gran escala
  • Hay muchos problemas que son fáciles de imaginar y de mostrar en una demo, pero muy difíciles de convertir en producto
    • Por ejemplo, la conducción autónoma: es fácil demostrar que un auto se conduzca solo por una cuadra, pero convertir eso en un producto toma 10 años — Andrej Karpathy
  • Tomemos como ejemplo los autos autónomos
    • En 1988 apareció el primer auto conducido por una red neuronal
    • Veinticinco años después, Andrej Karpathy hizo su primer viaje de demostración en Waymo
    • Diez años después de eso, la empresa obtuvo permiso para conducir sin conductor
    • Pasaron 35 años de ingeniería rigurosa, pruebas, mejoras y navegación regulatoria para ir del prototipo al producto comercial
  • He observado los altibajos del último año en toda la industria y la academia: el primer año de N para las aplicaciones de LLM (Year 1 of N for LLM applications)
    • Espero que las lecciones que aprendimos —desde tácticas como evaluación, prompt engineering y guardrails hasta perspectivas estratégicas como habilidades operativas, construcción de equipos y la elección de qué capacidades desarrollar internamente— ayuden en el segundo año y los que sigan
    • Espero con entusiasmo que sigamos haciendo avanzar juntos esta emocionante nueva tecnología

Lecturas relacionadas

9 comentarios

 
inthelife 2024-06-17

El contenido es tan bueno que hice un mindmap para guardarlo y revisarlo una y otra vez ^^;

https://drive.google.com/file/d/…
 
hheungsu 2024-06-15

¡¡Es un artículo excelente!! De principio a fin hay muchas ideas útiles para reflexionar. ¡¡Gracias por traducir y compartir un texto tan valioso!!
 
nutella 2024-06-12

En este momento, realmente me está ayudando muchísimo.
 
komanabi 2024-06-11

Se acabó MegaStudy, ¡¡¡ya viene Omega 3!!!
 
ssifood 2024-06-11

Ahora se acabó Skynet, llega MegaStudy.
 
my0075425 2024-06-11

Ahora sí, la humanidad está acabada, ¡¡¡llega Skynet!!!
 
zihado 2024-06-10

La carrera del autor original también me pareció interesante.
https://es.news.hada.io/topic?id=1626
 
eungook 2024-06-11

Guau... esto sí que inspira muchísimo... gracias por compartirlo
 
humblebee 2024-06-10

¡Es un excelente texto en el que se sienten muy vivas la perspectiva y la experiencia! Creo que será de gran ayuda para mi equipo y para mí. Lo leí con muchísimo gusto. Gracias ☺️