Test A/B de LLM: probar prompts y modelos en producción
Test A/B de LLM: cómo probar prompts y modelos con usuarios reales, medir aceptación, coste y latencia, y evitar los errores del juez LLM.
📚 Este artículo es parte de la guía Personalización con IA y Test A/B: cómo funcionan juntos.
Un test A/B de LLM es un experimento controlado en el que usuarios reales son sorteados entre dos versiones del comportamiento de IA dentro del producto (otro prompt, otro modelo, otra temperatura, con o sin RAG) para medir el efecto causal de eso en lo que hacen. La evaluación offline, con conjunto de preguntas y LLM como juez, filtra candidatos; solo el test online dice si el cambio mejora la tarea del usuario, y trae tres trampas propias: salida no determinista, métricas por mensaje con sorteo por usuario y coste por petición que cambia entre las variantes. Esta guía forma parte de la guía de personalización con IA y test A/B y cubre el reparto de trabajo entre offline y online, los sesgos medidos del juez LLM, la tabla de métricas y guardrails, la simulación que muestra por qué el intervalo ingenuo falla, un ejemplo trabajado de prompt actual contra prompt nuevo con las dos calculadoras integradas, y la cuenta de coste que decide si el ganador se paga.
Qué cambia cuando la variante es un comportamiento de IA
La estadística es la misma de cualquier test A/B: dos grupos equivalentes por sorteo, una métrica primaria declarada antes, un tamaño de muestra calculado para un efecto mínimo y una lectura con intervalo de confianza. Lo que cambia es la naturaleza de la variante y el tipo de daño que puede causar.
En una página, la variante es un texto o un diseño fijo, igual para todos los que caen en el grupo. En una funcionalidad de LLM, la variante es una configuración que genera salidas diferentes en cada llamada. Eso tiene cuatro consecuencias prácticas:
- La misma entrada produce salidas diferentes. La documentación de la API de mensajes de Anthropic, consultada en septiembre de 2026, dice que incluso con temperatura 0,0 los resultados no serán totalmente deterministas (la misma página marca el parámetro como descontinuado: los modelos lanzados después de Claude Opus 4.6 solo aceptan el valor 1,0). La varianza de la métrica tiene una fuente más, que no existe en un botón.
- La variante tiene coste variable. Un prompt con más instrucciones o con fragmentos recuperados de una base consume más tokens de entrada, y cada petición pasa a costar más. Eso nunca ocurre cuando cambias el color de un CTA.
- La variante puede fallar de formas nuevas. Rechazar una tarea legítima, inventar un hecho, tardar demasiado en empezar a responder, superar el límite de peticiones del proveedor.
- La variante puede cambiar sin que tú la toques. Un alias de modelo que apunta a la versión más reciente, o un cambio en la infraestructura de servicio, puede alterar el comportamiento en medio del test.
La diferencia con la pieza sobre variantes generadas por IA es importante: allí la IA escribe variaciones de una página y el test es un test de página común. Aquí la IA es la propia funcionalidad probada, y la variación es su comportamiento.
Evaluación offline frente a experimento online: quién decide qué
La evaluación offline ejecuta la configuración candidata sobre un conjunto fijo de entradas y mide la calidad de las salidas, con etiqueta humana o con otro modelo juzgando. El experimento online expone usuarios reales y mide lo que hacen. Las dos son necesarias, y cada una responde una pregunta diferente.
El texto de Widad Machmouchi y Somit Gupta, de la plataforma de experimentación de Microsoft, publicado en septiembre de 2023, pone la frontera de forma directa: la evaluación offline es adecuada para el inicio del desarrollo de una funcionalidad, pero no consigue evaluar cómo los cambios de modelo benefician o degradan la experiencia del usuario en producción. El mismo texto describe los diseños de experimento que recomienda en el lanzamiento de la funcionalidad y después de él.
| Pregunta | Offline (conjunto + juez) | Sombra | Test A/B online |
|---|---|---|---|
| ¿La respuesta es correcta y tiene el tono adecuado? | Sí, sobre las preguntas del conjunto | Parcialmente, sin reacción del usuario | Indirectamente, por el comportamiento |
| ¿Cuánto cuesta y cuánto tarda? | Estimación en entorno de prueba | Sí, con tráfico real | Sí, con tráfico real |
| ¿El usuario acepta, aplica o regenera? | No | No | Sí |
| ¿El usuario vuelve a usar la función? | No | No | Sí |
| ¿El cambio causa el efecto observado? | No | No | Sí, gracias al sorteo |
| Coste de equivocarse | Bajo | Bajo | Alto, usuarios expuestos |
El conjunto de evaluación tiene un límite estructural que ningún juez resuelve: es fijo, y los usuarios no lo son. Las preguntas que llegan en producción cambian con la época, el público y el propio producto, y el conjunto envejece en silencio. Por eso el flujo sano usa el offline para recortar de diez candidatos a dos y deja que el test online decida entre los dos.
El juez LLM y los sesgos que ya fueron medidos
Usar otro modelo para puntuar las respuestas es barato y escala, y existe evidencia de que coincide bastante con las personas. El trabajo de Zheng y coautores, “Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena” (2023), relata que jueces fuertes como GPT-4 alcanzaron más del 80 por ciento de concordancia con preferencias humanas, el mismo nivel de concordancia que hay entre humanos. El mismo artículo mide tres sesgos que hacen que el juez sea peligroso como métrica primaria sin calibración:
- Sesgo de posición. Los autores generaron pares de respuestas parecidas e invirtieron el orden. Con el prompt estándar, GPT-4 mantuvo el veredicto en el 65,0 por ciento de los casos, GPT-3.5 en el 46,2 por ciento y Claude-v1 en el 23,8 por ciento; Claude-v1 favoreció la primera posición en el 75,0 por ciento de los casos.
- Sesgo de verbosidad. En un ataque de “lista repetitiva”, en el que una respuesta fue alargada con ítems reescritos sin información nueva, el juez prefirió la versión inflada en el 91,3 por ciento de los 23 casos con Claude-v1 y con GPT-3.5, y en el 8,7 por ciento con GPT-4.
- Sesgo de autopromoción. Comparado con humanos, GPT-4 se dio a sí mismo una tasa de victoria un 10 por ciento mayor y Claude-v1, un 25 por ciento mayor. Los autores advierten que, con pocos datos y diferencias pequeñas, el estudio no consigue determinar si el sesgo existe de hecho.
El propio artículo sugiere mitigaciones simples: llamar al juez dos veces con el orden invertido y declarar victoria solo cuando la misma respuesta gana en las dos, y proporcionar una respuesta de referencia en preguntas de matemáticas, lo que redujo los fallos de GPT-4 de 14 de 20 a 3 de 20 en la prueba de los autores. La regla operativa que sale de ahí es: el juez LLM es un instrumento de medición, y un instrumento se calibra. Separa una muestra de respuestas, etiquétala con personas, mide la concordancia del juez en esa muestra y solo entonces usa su nota, y aun así como filtro o métrica secundaria. Tratar la nota del juez como métrica sustituta del valor para el usuario exige la misma validación que cualquier sustituta.
Métricas de un test A/B de LLM: éxito, uso y guardrails propios
La métrica primaria debe estar ligada al valor de la tarea y medirse por usuario, la unidad sorteada. El texto de Microsoft describe, entre las métricas de una funcionalidad de LLM, un embudo que va de la oportunidad de sugerir hasta la respuesta aceptada y mantenida por el usuario, y añade familias que no existen en un test de página: consumo de tokens, respuestas truncadas, errores 429 de sobrecarga, tiempo hasta el primer token medido en varios percentiles, respuestas filtradas por contenido y retención.
| Métrica | Tipo | Unidad natural | Trampa |
|---|---|---|---|
| Éxito de la tarea (completó lo que iba a hacer) | Primaria | Usuario | Definir “éxito” después de ver el dato |
| El usuario aceptó una respuesta sin regenerar | Primaria o secundaria | Usuario | Cambiar la ventana de medición en medio del test |
| Tasa de aceptación por respuesta (copió, aplicó) | Secundaria | Mensaje | Es métrica de ratio: exige método delta |
| Tasa de “regenerar” y de reformulación | Secundaria, señal de insatisfacción | Mensaje | Una variante más lenta reduce la regeneración por cansancio, no por calidad |
| Pulgar arriba o abajo | Secundaria | Mensaje | Solo una fracción responde y no es sorteada; quien responde es distinto de quien no responde |
| Retención en la función (volvió a la semana siguiente) | Primaria de largo plazo | Usuario | Necesita ventana larga; el efecto novedad infla las primeras semanas |
| Tokens y coste por petición | Guardrail | Petición | Comparar medias por petición cuando una variante genera más peticiones por usuario |
| Latencia (p95 del tiempo hasta el primer token) | Guardrail | Petición | Mirar la media esconde la cola; usa métricas de cuantil |
| Tasa de error, timeout y 429 | Guardrail | Petición | Una cuota compartida entre variantes crea interferencia |
| Tasa de rechazo de tarea legítima | Guardrail | Mensaje | Necesita clasificación consistente en las dos variantes |
| Incidentes de seguridad (contenido filtrado, fuga) | Guardrail con límite cero o casi | Evento | Evento raro: el test rara vez tiene potencia, así que exige revisión fuera de la estadística |
Tres observaciones sobre esta tabla. La primera es que aceptación sin regenerar es una buena primaria por usuario porque junta dos señales (el usuario usó la respuesta y no necesitó pedir otra) sin depender de que nadie haga clic en un pulgar. La segunda es que el pulgar no es métrica primaria: quien responde se autoselecciona, y una variante puede cambiar quién responde sin cambiar la calidad. La tercera es que los guardrails de LLM tienen límite declarado antes, como cualquier métrica de guardrail, y el coste es guardrail, no detalle de facturación.
De dónde viene la varianza extra en un test de LLM
La varianza de un test de LLM tiene cuatro fuentes que un test de página no tiene o tiene a escala mucho menor. Dos afectan al diseño del sorteo, dos afectan a la lectura.
Sortear por usuario, no por petición
La primera decisión de diseño es la unidad de sorteo. Sortear cada petición de forma independiente parece aumentar la muestra, y es justamente esa la trampa: el mismo usuario recibe la variante A en el primer mensaje, la B en el segundo y la A de nuevo en el tercero, dentro de la misma conversación.
Sortear por usuario resuelve la contaminación y crea un coste estadístico: todos los mensajes de un usuario están correlacionados (un usuario al que le gusta la función acepta muchas respuestas, uno al que no le gusta acepta pocas). La asignación tiene que ser determinista por identificador de usuario, exactamente como en un test A/B en servidor, para que el mismo usuario caiga siempre en el mismo brazo en cualquier servidor.
Métrica por mensaje con sorteo por usuario: el intervalo ingenuo falla
Cuando la métrica es “tasa de aceptación por respuesta” y la unidad sorteada es el usuario, la métrica se convierte en un ratio de dos sumas por usuario (respuestas aceptadas sobre respuestas generadas). Tratar cada mensaje como observación independiente subestima el error estándar, y el tamaño del error crece con el número de mensajes por usuario. La corrección es el método delta, explicado en métricas de ratio.
Para medir el tamaño del problema en funcionalidades de LLM, ejecutamos una simulación hecha para esta guía (generador pseudoaleatorio con semilla fija): 2.000 tests A/A, sin ninguna diferencia real entre los brazos, con 2.000 usuarios por brazo, número de peticiones por usuario variando de forma asimétrica y propensión a aceptar variando entre usuarios. En cada test, la diferencia en la tasa de aceptación por mensaje fue evaluada al 95 por ciento de dos formas.
| Escenario simulado | Peticiones por usuario (media) | Error estándar del método delta dividido por el ingenuo | Falso positivo con intervalo ingenuo | Falso positivo con método delta |
|---|---|---|---|---|
| Función de uso ocasional | cerca de 3,7 | 1,28 | 12,10% | 4,55% |
| Chat de uso intenso | cerca de 20 | 2,83 | 49,15% | 4,50% |
El nivel nominal es el 5 por ciento. Con el método delta, las dos simulaciones quedan cerca de eso. Con el intervalo ingenuo, la función de uso ocasional ya más que duplica la tasa de falsa alarma, y el chat de uso intenso declara ganador en casi la mitad de los tests en los que nada cambió. Por eso un panel de LLM que muestra “aceptación por mensaje con significancia” sin decir cómo calculó el error estándar merece desconfianza inmediata.
Novedad, caché compartida y versiones que cambian solas
Efecto novedad. Un comportamiento de IA nuevo puede atraer curiosidad: el usuario prueba más, regenera para ver qué pasa, acepta por entusiasmo. El efecto novedad hace que las primeras semanas exageren la ganancia o la pérdida. Ejecuta semanas completas, mira el efecto por semana de exposición y desconfía de una ganancia que solo existe en la primera.
Interferencia por recurso compartido. Si las dos variantes usan la misma caché de respuestas, un usuario del brazo B puede recibir una respuesta generada por el prompt A y almacenada. Si usan la misma cuota de peticiones del proveedor, una variante que consume más puede provocar errores 429 en la otra. Las dos situaciones violan la premisa de que el tratamiento de un usuario no afecta el resultado de otro, tema de interferencia entre variantes. La solución es incluir la variante en la clave de la caché y monitorear errores por brazo.
Versión del modelo que cambia en medio del test. La página de identificadores de modelo de Anthropic, consultada en septiembre de 2026, explica que en los modelos anteriores a la generación 4.6 los alias sin fecha de la API apuntan al snapshot fechado más reciente de esa versión, mientras que cada identificador es una versión fijada. La misma página advierte que, incluso con identificador y pesos inalterados, cambios en la infraestructura de servicio (enrutamiento, clasificadores de seguridad, lógica de muestreo) pueden producir pequeñas diferencias de comportamiento observable. La regla práctica vale para cualquier proveedor: fija la versión del modelo en las dos variantes, registra esa versión en la configuración del experimento y anota cualquier cambio conocido del proveedor durante la ventana.
Ejemplo trabajado: prompt actual frente a prompt nuevo
Un SaaS de comercio electrónico tiene una función que escribe la descripción de un producto a partir de atributos registrados. El vendedor puede aceptar el texto, editarlo o regenerarlo. El equipo escribió un prompt nuevo con más instrucciones de estilo y ejemplos recuperados de las descripciones que más aprobaron los vendedores. El prompt nuevo pasó la evaluación offline y un experimento sombra, sin aumento de error. La pregunta que queda es la del test online.
Declaración antes de ejecutar:
- Unidad de sorteo: vendedor (usuario), asignación determinista por identificador.
- Métrica primaria: proporción de usuarios que aceptaron al menos una descripción sin regenerar durante el test.
- Tasa base histórica: 30 por ciento.
- Efecto mínimo que justifica el coste del prompt nuevo: más 5 por ciento relativo.
- Guardrails: coste por mil peticiones, p95 del tiempo hasta el primer token, tasa de error y tasa de rechazo, con límites escritos.
- Versión del modelo: fijada e idéntica en los dos brazos.
Cuántos usuarios y cuántos días
Pon en la calculadora de abajo una tasa actual de 30, efecto mínimo de 5 relativo, confianza 95, potencia 80, 10.000 visitantes por semana (aquí, usuarios nuevos que entran en el test por semana) y test bilateral:
Cálculo por aproximación normal de dos proporciones, 2 variaciones (50/50). Cambia los campos y mira el impacto en vivo.
Devuelve 14.856 usuarios por variación, 29.712 en total y 21 días. Tres semanas completas es una buena noticia en este caso, porque la ventana da espacio para ver si un eventual efecto novedad de la primera semana se sostiene en las siguientes.
El resultado
Después de 21 días, los números de la simulación hecha para esta guía (generador con semilla fija, con un efecto verdadero pequeño incorporado en el prompt nuevo) fueron:
- Control (prompt actual): 14.962 usuarios, 4.371 aceptaron una descripción sin regenerar.
- Variante (prompt nuevo): 15.038 usuarios, 4.584 aceptaron.
Antes de leer el efecto, comprueba el reparto: 14.962 contra 15.038 en un reparto configurado de 50 a 50 da chi cuadrado de 0,1925 y valor p de 0,6608 en la prueba de reparto desigual de tráfico (SRM), es decir, sin señal de problema en el sorteo. Ahora pega los números en la calculadora de significancia:
Test z bilateral de dos proporciones. "Sin significancia" casi siempre significa que falta muestra, no que las versiones sean iguales.
La pantalla muestra una tasa del 29,21% en el control y del 30,48% en la variante, mejora relativa de +4,3%, valor p de 0,0163, IC 95% de la diferencia de +0,2% a +2,3% (pp) y el veredicto “Ganadora con significancia”, con B ganando. Los valores exactos detrás de la pantalla son una diferencia de 1,2688 puntos porcentuales, intervalo de 0,2333 a 2,3043 puntos y z de 2,4012.
La métrica por mensaje cuenta otra historia
En el mismo test, la tasa de aceptación por mensaje fue del 11,84 por ciento en el control (6.587 aceptadas en 55.643 peticiones) y del 12,07 por ciento en la variante (6.834 en 56.638), diferencia de +0,23 puntos. Con el método delta, el intervalo va de −0,26 a +0,72 puntos y el valor p es 0,3623: sin conclusión. El cálculo ingenuo daría un intervalo de −0,15 a +0,61 puntos, cerca de un 23 por ciento más estrecho de lo que debería. La lectura correcta es que la métrica secundaria por mensaje no tiene potencia para confirmar ni para desmentir la primaria, y que la decisión sigue anclada en la métrica por usuario declarada antes.
El coste entra en la decisión: cuánto cuesta cada usuario adicional
El prompt nuevo usa más tokens. Los valores de abajo son ilustrativos, elegidos para que la cuenta quede clara, y no corresponden al precio de ningún proveedor específico: 3,00 dólares por millón de tokens de entrada y 15,00 dólares por millón de tokens de salida.
| Ítem | Prompt actual | Prompt nuevo | Diferencia |
|---|---|---|---|
| Tokens de entrada por petición | 1.200 | 2.000 | +66,7% |
| Tokens de salida por petición | 300 | 320 | +6,7% |
| Coste por mil peticiones | US$ 8,10 | US$ 10,80 | +US$ 2,70 (+33,3%) |
| Peticiones por usuario en el test | 3,72 | 3,77 | n/d |
| Coste extra por 10.000 usuarios | n/d | US$ 101,69 | n/d |
El coste extra por 10.000 usuarios es 3,7663 peticiones por usuario del brazo nuevo por US$ 0,0027 de diferencia por petición por 10.000. La ganancia, sobre la misma base de 10.000 usuarios, es la diferencia en la métrica primaria: 126,9 usuarios adicionales que aceptan una descripción sin regenerar, por la estimación central. Dividiendo uno por el otro, y haciendo lo mismo en los dos límites del intervalo:
| Lectura del efecto | Usuarios adicionales por 10.000 | Coste por usuario adicional |
|---|---|---|
| Límite inferior del IC (+0,23 pp) | 23,3 | US$ 4,36 |
| Estimación central (+1,27 pp) | 126,9 | US$ 0,80 |
| Límite superior del IC (+2,30 pp) | 230,4 | US$ 0,44 |
La decisión ahora es de negocio, y tiene forma clara. Si un vendedor adicional que adopta la función vale más que US$ 4,36 (por ejemplo, por el efecto en la retención del plan), el prompt nuevo se paga incluso en el peor escenario plausible. Si vale entre US$ 0,80 y US$ 4,36, se paga en la estimación central, pero con riesgo real. Si vale menos que US$ 0,80, no se paga ni en la estimación central. La misma cuenta vale, con números mayores, para cambiar de modelo: un modelo mayor suele cambiar la columna de coste mucho más que un prompt.
Checklist de lanzamiento de un test A/B de LLM
- Filtrar offline antes. Conjunto de evaluación actualizado, juez con concordancia medida contra etiqueta humana, evaluación con orden invertido cuando el juez compara pares.
- Ejecutar modo oscuro o sombra cuando el cambio afecta a la capacidad. Cambiar de modelo y prompts mucho más largos cambian coste, latencia y tasa de error antes de cambiar cualquier comportamiento.
- Sortear por usuario, con asignación determinista. El mismo usuario recibe siempre la misma variante, en cualquier servidor y en cualquier conversación.
- Declarar la métrica primaria por usuario y la ventana. Por escrito, en un plan de análisis preregistrado, antes del primer dato.
- Declarar guardrails con límite. Coste por mil peticiones, p95 del tiempo hasta el primer token, error y 429 por brazo, rechazo, incidentes de seguridad.
- Fijar la versión del modelo y registrar la configuración entera. Identificador del modelo, prompt versionado, temperatura, parámetros de recuperación y clave de caché por variante.
- Calcular muestra y duración en semanas completas. Usa la calculadora de tamaño de muestra y redondea hacia arriba en semanas.
- Comprobar SRM antes de leer el efecto. La verificación de SRM se ejecuta en segundos.
- Leer las métricas por mensaje con el método delta. Nunca con el intervalo binomial por mensaje.
- Cerrar la decisión con la cuenta de coste sobre el intervalo entero. Y, si la función es central en el producto, mantener un holdout de largo plazo para medir retención después del lanzamiento.
Errores comunes
| Error | Por qué engaña | Corrección |
|---|---|---|
| Usar la nota del juez LLM como métrica primaria sin calibración humana | El juez tiene sesgo de posición y de verbosidad medidos, y puede premiar la respuesta más larga en vez de la más útil | Juez como filtro offline; primaria basada en el comportamiento del usuario |
| Sortear por petición | Mezcla variantes en la misma conversación e infla la muestra aparente | Sorteo determinista por usuario |
| Mirar solo el pulgar | Quien responde se autoselecciona y es raro | Aceptación, regeneración y éxito de la tarea como señales principales |
| Olvidar coste y latencia | Un ganador de aceptación puede ser más caro y más lento de lo que la ganancia vale | Guardrails declarados y cuenta de coste sobre el IC |
| No fijar la versión del modelo | El alias apunta a una versión nueva en medio de la ventana | Identificador fijo y registrado en la configuración |
| Ignorar cambios del proveedor durante el test | La infraestructura de servicio puede cambiar el comportamiento sin cambiar el identificador | Anotar la ventana, comparar efecto por semana, repetir si es necesario |
| Leer aceptación por mensaje con intervalo ingenuo | En la simulación de esta guía, hasta un 49,15% de falsos positivos | Método delta |
| Declarar victoria en la primera semana | La novedad puede inflar el uso inicial | Semanas completas y efecto por semana de exposición |
| Compartir caché entre las variantes | El brazo B recibe respuestas del prompt A | La clave de caché incluye la variante |
Hazlo automático en Donnu
El punto en el que un test A/B de LLM suele romperse no es la estadística, es el registro. Tres semanas después, nadie recuerda qué versión del modelo estaba fijada, cuál era la métrica primaria declarada y si el límite de coste fue escrito antes o después de ver el resultado. Sin ese registro, la cuenta de coste sobre el intervalo se vuelve discusión de opiniones.
Siendo directos sobre lo que Donnu A/B es hoy: una herramienta de test A/B client-side para páginas web. El sorteo de un prompt o de un modelo ocurre en tu backend, así que la asignación de la variante de IA en sí es trabajo de tu servidor o de una plataforma de feature flags de servidor, como se explica en feature flags frente a test A/B. Lo que Donnu hace en ese flujo es lo que hace en cualquier experimento: registra la configuración del experimento en el momento en que se crea, con la métrica primaria declarada, y mantiene el historial por experimento. Y los tests de la capa visible de la función (dónde aparece el botón de IA, cómo se presenta la sugerencia, qué llamada invita a usarla) son exactamente el caso de uso del snippet.
Para la parte numérica, las calculadoras de esta guía son gratuitas: la calculadora de tamaño de muestra para planificar la ventana y la calculadora de significancia para leer la métrica primaria por usuario. Si quieres ver Donnu en tests de página, empieza una prueba gratis de 14 días.
Referencias
- Machmouchi, W. y Gupta, S. How to Evaluate LLMs: A Complete Metric Framework. Microsoft Research, plataforma de experimentación (ExP), 27 de septiembre de 2023. Leído en esta sesión. Sustenta la afirmación de que la evaluación offline es adecuada al inicio del desarrollo pero no consigue evaluar cómo los cambios de modelo benefician o degradan la experiencia en producción; el embudo de métricas que va de la oportunidad de sugerir hasta la respuesta aceptada y mantenida; las métricas de tokens, errores 429, respuestas truncadas y filtradas por contenido, tiempo hasta el primer token en varios percentiles, pulgar y retención; y los diseños de modo oscuro y experimento 0-1 (en el lanzamiento), experimento sombra (después del lanzamiento, en el que las métricas que dependen de la reacción del usuario no pueden medirse) y experimento 1-N. microsoft.com.
- Zheng, L., Chiang, W.-L., Sheng, Y. y coautores. Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. arXiv 2306.05685, 9 de junio de 2023. PDF leído en esta sesión. Sustenta la concordancia por encima del 80 por ciento entre jueces fuertes y preferencias humanas, al mismo nivel que la concordancia entre humanos; la tabla 2 de sesgo de posición (consistencia de 65,0, 46,2 y 23,8 por ciento para GPT-4, GPT-3.5 y Claude-v1 con el prompt estándar, y 75,0 por ciento de preferencia por la primera posición en Claude-v1); la tabla 3 del ataque de lista repetitiva (91,3, 91,3 y 8,7 por ciento de fallo en 23 respuestas); la observación sobre autopromoción (10 y 25 por ciento más de tasa de victoria, con la advertencia de que el estudio no consigue determinar el sesgo); y las mitigaciones de invertir el orden y usar respuesta de referencia (fallos de 14 de 20 a 3 de 20). arxiv.org.
- Anthropic. Model IDs and versioning. Documentación de la plataforma Claude, consultada el 13 de septiembre de 2026. Sustenta que cada identificador de modelo es una versión fijada, que los alias de modelos anteriores a la generación 4.6 apuntan al snapshot fechado más reciente de esa versión, y que cambios de infraestructura de servicio pueden producir pequeñas diferencias de comportamiento incluso sin cambio de identificador y pesos. platform.claude.com.
- Anthropic. Create a Message, parámetro temperature. Referencia de la API de Claude, consultada el 13 de septiembre de 2026. Sustenta que incluso con temperatura 0,0 los resultados no son totalmente deterministas, y que el parámetro está descontinuado: los modelos lanzados después de Claude Opus 4.6 solo aceptan el valor 1,0. platform.claude.com.
- LaunchDarkly. AgentControl. Documentación (la dirección antigua /docs/home/ai-configs redirige a esta página), consultada el 13 de septiembre de 2026. Ejemplo de plataforma de experimentación que trata prompts, instrucciones y parámetros de modelo como variaciones de configuración y compara variaciones por coste, latencia, satisfacción y otras métricas; citado como ilustración del diseño, no como recomendación. launchdarkly.com.
Lee también: Personalización con IA y test A/B · Variantes de test A/B generadas por IA · Copilotos de IA en herramientas de test A/B · Métricas de ratio y método delta · Unidad de aleatorización · Métricas de guardrail · Efecto novedad · Calculadora de significancia · Leia em português · Read in English
Preguntas frecuentes
- ¿Qué es un test A/B de LLM?
- Es un experimento controlado en el que usuarios reales son sorteados entre dos configuraciones de una funcionalidad construida con un modelo de lenguaje, por ejemplo dos prompts, dos modelos, dos temperaturas o la misma respuesta con y sin búsqueda en una base de conocimiento (RAG). La diferencia con una evaluación offline es que el test mide el efecto causal en el comportamiento del usuario, como aceptar la respuesta, completar la tarea o volver a usar la función, y no una nota dada por un evaluador sobre un conjunto fijo de preguntas.
- ¿La evaluación offline con LLM como juez sustituye al test A/B?
- No. Sirve para filtrar candidatos antes de exponer usuarios. El artículo de Microsoft Research sobre evaluación de funcionalidades de LLM afirma que la evaluación offline es adecuada al inicio del desarrollo, pero no consigue medir si un cambio de modelo mejora o empeora la experiencia en producción. Y el juez tiene sesgos documentados: en el estudio de Zheng y coautores (2023), el más consistente de los tres jueces evaluados mantuvo el mismo veredicto al invertir el orden de las respuestas, con el prompt estándar, en solo el 65,0 por ciento de los casos.
- ¿Cuál debe ser la unidad de sorteo en un test de prompt o modelo?
- El usuario, casi siempre. Sortear por petición hace que la misma conversación mezcle dos comportamientos, contamina la métrica por usuario e impide medir retención. La consecuencia estadística es que las métricas por mensaje, como la tasa de aceptación, pasan a ser métricas de ratio y exigen el método delta. En la simulación hecha para esta guía, el intervalo ingenuo por mensaje produjo falso positivo en el 49,15 por ciento de 2.000 tests A/A en un escenario de chat intenso, frente al 4,50 por ciento con el método delta.
- ¿Qué métricas usar en un test A/B de LLM?
- Una métrica primaria por usuario ligada al valor de la tarea, como la proporción de usuarios que aceptaron una respuesta sin regenerar, más señales de uso (copió, aplicó, regeneró, reformuló) y guardrails específicos de LLM: tokens y coste por petición, latencia en percentil alto, tasa de error y de rechazo, e incidentes de seguridad. La valoración explícita por pulgar sirve como señal secundaria, porque solo una fracción de los usuarios responde y no es sorteada.
- ¿Cuánto tiempo lleva un test A/B de prompt?
- Depende de la tasa base y del efecto que quieras detectar. En el ejemplo de esta guía, con un 30 por ciento de usuarios que aceptan una respuesta sin regenerar y un efecto mínimo de más 5 por ciento relativo, al 95 por ciento de confianza y 80 por ciento de potencia, son 14.856 usuarios por variación. Con 10.000 usuarios nuevos elegibles por semana, eso da 21 días, tres semanas completas, lo que además ayuda a atravesar el efecto novedad.
- ¿Cómo decidir si un prompt que convierte más pero cuesta más vale la pena?
- Convierte la ganancia y el coste a la misma unidad y usa el intervalo, no solo la estimación central. En el ejemplo ilustrativo de esta guía, el prompt nuevo cuesta 101,69 dólares más por cada 10.000 usuarios y genera 126,9 usuarios adicionales que aceptan una respuesta, cerca de 0,80 dólares por usuario adicional. En el límite inferior del intervalo de confianza, el mismo coste compra solo 23,3 usuarios adicionales, cerca de 4,36 dólares cada uno. Si un usuario adicional vale menos que eso para tu negocio, la decisión depende de cuánto riesgo aceptas.