Intercambiar modelos de LLM de forma segura: etiquetas humanas, métricas por paso, configuraciones de esfuerzo

Cambiar el nombre de un modelo en un archivo de configuración parece ser una tarea que se puede completar en cinco minutos. Sin embargo, en un pipeline de LLM con múltiples pasos rara vez es así, y la razón suele no estar en el nuevo modelo, sino en las métricas que se utilizan para evaluarlo. Al aplicar una migración realista de un pipeline de filtrado desde una familia de modelos más antigua, verá cómo crear datos de referencia fiables, atribuir las pérdidas a cada paso individualmente, distinguir una solicitud obsoleta proveniente de un modelo más débil y tratar el esfuerzo de razonamiento como una configuración específica para cada tarea en lugar de un ajuste global.

El desencadenante concreto en este escenario es la obsolescencia. OpenAI ha anunciado el 11 de diciembre de 2026 como fecha de retiro para cuatro modelos: gpt-5, sus variantes mini y nano, y gpt-5-pro. Ese es el calendario al momento de redactar este texto, por lo que debe confirmarse en la página oficial sobre obsolescencias. El proceso en cuestión dependía de los dos modelos más pequeños, por lo que el cambio era obligatorio. Había dos opciones de reemplazo: gpt-5.4 en sus diferentes tamaños, y gpt-5.6-luna. Los nombres de los modelos, las configuraciones predeterminadas y los planes de precios cambian con rapidez, así que considere los detalles aquí presentados como un estado momentáneo y el método como la parte permanente.

El proceso que se está migrando

El sistema procesa aproximadamente 2,600 artículos al mes y los reduce a unos 120 candidatos, que luego una persona revisa manualmente. Esa reducción no se logra con una sola instrucción; es el resultado de un agente desarrollado con LangGraph, que cuenta con una docena de nodos en el grafo, diez de los cuales corresponden a llamadas al modelo distintas. Tres de esas llamadas contienen la mayor parte de la información: una puerta de relevancia en la entrada, seguida de dos clasificadores, uno para el tipo de contenido y otro para el tema. Después de ellos se encuentran una verificación de novedad, un paso de puntuación y un paso de resumen.

Una característica del diseño influye en cada decisión posterior. El primer nodo existe para eliminar ruido y no para evaluar la calidad, y sus dos tipos de errores tienen costos muy diferentes:

• Un error de inclusión errónea tiene un costo bajo; un modelo más potente posteriormente, o el revisor humano al final, lo detectará.

Una eliminación falsa es permanente. El artículo se marca como visto y nunca vuelve a entrar en el proceso.

Cualquier evaluación que trate esos dos errores de manera simétrica le dará una idea errónea sobre el funcionamiento del proceso.

La configuración que se envió

El estado final se diseñó intencionalmente de forma desequilibrada. Nueve de las diez llamadas se transfirieron a gpt-5.6-luna, que hasta ahora ha funcionado bien. La barrera de relevancia permaneció en gpt-5.4-nano; justificar esa excepción ocupó la mayor parte de la investigación. Además, ahora cada llamada establece explícitamente el esfuerzo de razonamiento que requiere en lugar de heredar la configuración predeterminada del modelo, y esa elección resultó ser más importante que la selección del propio modelo.

Cost redujo la lista preliminar antes incluso de evaluar la calidad, pero no basándose en los precios de lista. Casi todo el tráfico se factura bajo el programa de intercambio de datos de OpenAI, y luna utiliza la misma cuota diaria más alta que los modelos más económicos ya en uso. Por lo tanto, la factura mensual se mantiene en unos pocos centavos en cualquier caso. Los modelos más potentes de la misma generación pertenecen a una cuota mucho menor que se agotaría para el mediodía con esta carga de trabajo, lo que los descartó independientemente de su calidad.

A continuación se presentan cuatro sorpresas, en el orden en que surgieron. Ese mismo orden resulta ser también una lista de verificación útil para su propia migración.

Lección 1: no utilice el modelo antiguo como punto de referencia

La primera evaluación comparó cada configuración candidata con los resultados del modelo obsoleto: ¿qué parte del resultado anterior reproduce la nueva configuración? Esa comparación mostró una regresión de 31 artículos y desencadenó la búsqueda de un defecto en el modelo que en realidad no existía.

En retrospectiva, el problema es obvio. La primera fase del proceso genera candidatos, y entre el 40 y el 60 por ciento de ellos son eliminados posteriormente por el revisor humano. Medir la concordancia con esos resultados equivale a medirla con un filtro cuya calidad ya se sabe que es mediocre. Se recompensa a los candidatos por copiar los errores del modelo antiguo y se les penaliza por corregirlos.

Las decisiones humanas ya constituyen la verdad de referencia registrada

Había un conjunto de etiquetas mucho mejor almacenado en el control de versiones. El paso de revisión manual elimina entradas de la lista de candidatos, y cada eliminación se registra como un commit. En el mes utilizado para las pruebas, la primera revisión redujo 122 candidatos a 72, y las revisiones posteriores eliminaron aún más. Al comparar ese commit con su padre se obtienen dos grupos etiquetados: los artículos que una persona mantuvo y los artículos que rechazó.

Reevaluar los 31 artículos “perdidos” según esas etiquetas cambió por completo la situación. El 43 por ciento de ellos eran artículos que el revisor ya había descartado de todos modos. Según el juicio humano, la pérdida real fue de 15 artículos buenos, aproximadamente la mitad de la regresión aparente. Lo que es aún mejor, dado que las etiquetas pueden asociarse a decisiones paso a paso, indican qué nodo eliminó cada uno de esos 15 artículos. (Estas cifras etiquetadas provienen de la configuración con gpt-5.4-mini, no de la configuración de Luna que se envió, ya que la ejecución con Luna se detuvo temprano.) Un único nodo fue responsable de ese cambio; ningún otro paso modificó más de un artículo. Un problema localizado de 15 artículos en una sola solicitud es mucho más fácil de resolver que una disminución inexplicable de 31 artículos.

La lección general: cada vez que una persona realiza la llamada final en su sistema, su llamada constituye la verdad absoluta, y por lo general ya existe un registro de ella. Observe las colas de aprobación, las anulaciones de moderación, los tickets de soporte reclasificados o las ediciones que realizan las personas en los borradores generados. El artículo existente sobre evaluar los sistemas RAG según la etapa de fallo plantea un caso similar para atribuir los errores al componente que los causó.

La medición paso a paso también revela errores no relacionados con la migración. En este caso, se descubrió que la función de verificación de novedad inventa nombres de temas que no aparecen en ninguna parte de la lista que recibe, asignando un nombre fabricado diferente para cada una de sus 24 rechazos, y lo hace tanto con los modelos antiguos como con los nuevos.

Lección 2: un modelo más estricto podría estar interpretando correctamente su prompt

Una vez que la pérdida se atribuyó al filtro de temas, la opción tentadora era ajustar su prompt hasta que el nuevo modelo se comportara adecuadamente. En este caso, eso habría causado daños reales, ya que un modelo más potente en etapas posteriores carga precisamente esos archivos de prompt. Relajar una regla para que un modelo de primera etapa procese más artículos sin problemas debilita la etapa encargada del juicio riguroso, y nada de lo medido en la primera etapa podría revelarlo.

Por lo tanto, en lugar de editar el prompt, la investigación pidió al modelo que se justificara. Para cada artículo rechazado por el filtro de temas, se registró la razón indicada por GPT-5.4-mini; en total, unas veinte llamadas.

Las explicaciones fueron coherentes. Mencionaron reglas específicas y citaron fielmente la instrucción inicial. En un caso, el modelo repitió, casi palabra por palabra, una regla que excluía la optimización de costos en IA “incluso cuando se implementa en una pasarela API”, y la utilizó para descartar un artículo que el revisor en realidad había conservado.

El antiguo gpt-5-mini simplemente nunca aplicó esa regla. Al examinarlo, se comprobó que dos de las reglas que había ignorado estaban realmente obsoletas. Una carecía de una excepción para los patrones de mensajería creados dentro de una aplicación; la otra fue redactada antes de que las pasarelas de IA se convirtieran en una infraestructura digna de consideración. Esas dos fueron corregidas, las demás se dejaron intactas, y la corrección se incluyó en su propio commit, separado del cambio en el modelo, para poder medir cada uno de forma independiente.

Una prueba económica que distingue dos diagnósticos opuestos

Este es el chequeo que debe realizarse primero en cualquier migración. Cuando un modelo más reciente rechaza más elementos en la fase de evaluación, la causa suele ser una mejor adherencia a las instrucciones en conflicto con un prompt que ya no es relevante tras un año. Lea una muestra de las razones indicadas:

• Cuando las explicaciones citan correctamente sus reglas reales, el prompt se ha vuelto obsoleto, y corregirlo ayuda en todas las etapas que lo utilizan.
• Cuando el modelo aplica reglas que claramente no corresponden al elemento, su prompt está bien formulado y el modelo es el culpable.

Esas conclusiones apuntan en direcciones opuestas, y un simple recuento de rechazos no puede distinguirlas.

Lección 3: un veredicto más estricto no es necesariamente peor

La puerta de relevancia contó una historia similar desde un ángulo diferente. En ese nodo, Luna descartó el doble de artículos que GPT-5.4-Nano. La interpretación obvia era que Luna es simplemente peor en esta tarea, y eso casi se convirtió en la decisión final.

No obstante, esa puerta está respondiendo en realidad a tres preguntas separadas: ¿es lo suficientemente reciente?, ¿el idioma es inglés? y, ¿el tema está dentro del alcance? Solo se había examinado el veredicto combinado.

Separar los veredictos resultó revelador. En cuanto a la pregunta del idioma, los modelos coincidieron perfectamente, marcando los mismos cuatro artículos. La diferencia total radicaba en la pregunta sobre el tema: Luna rechazó 64 artículos mientras que GPT-5.4-Nano rechazó 32.

Al analizar las razones de Luna se observaron juicios coherentes y, en su mayoría, defendibles: entre sus rechazos se encontraban una biblioteca para grupos de trabajo en Go, una plataforma para crear agentes de voz y un documento sobre la migración de bases de datos a la nube. Nada estaba defectuoso. Luna interpreta el término “enfoque principal” de manera más restrictiva de lo que pretendía el autor de la instrucción.

Eso exige una solución diferente. Un error debe corregirse. Es mejor evitar una interpretación defendible pero más estricta de una instrucción vaga, aplicada en la única etapa que procesa todo lo posterior, donde los errores son permanentes. Por eso esta solicitud específica se mantuvo en gpt-5.4-nano. En general, una puntuación total solo indica que algo ha cambiado. Si un paso responde a varias preguntas, registre cada respuesta por separado antes de formular cualquier teoría sobre el modelo.

Lección 4: el esfuerzo de razonamiento no se transfiere entre modelos o tareas

Una vez que se eligió gpt-5.4-nano para la puerta de control, la pregunta restante era cuánto debía pensar. Los modelos de razonamiento presentan un parámetro de esfuerzo que controla aproximadamente cuánta deliberación interna ocurre antes de dar la respuesta. La suposición inicial era que el esfuerzo funcionaba como un dial de calidad que siempre se ajusta de la misma manera, con cada modelo respondiendo a su propio estilo característico.

Las mediciones mostraron dos patrones bastante diferentes:

• En la puerta de relevancia, aumentar el esfuerzo casi duplicó las rechazos por parte de gpt-5.4-nano, mientras que luna no reaccionó en absoluto a ese ajuste.
• En el filtro de tema, el mismo modelo luna varió entre 49 artículos en el rango de esfuerzo y siguió rechazando contenido incluso con el ajuste más alto.
• El ya retirado gpt-5-nano fue la configuración más permisiva de todas.

Por lo tanto, una afirmación como “luna necesita un alto esfuerzo” no constituye un hecho reutilizable. Era válida para luna en una tarea, pero no significaba nada para ella en otra. El esfuerzo es una propiedad de un modelo específico en una tarea concreta, y cada combinación de este tipo requiere su propia medición.

Un modelo más grande no sustituye a esa medición. Una prueba separada con 80 artículos para evaluar la puerta de relevancia, utilizando cada modelo con un esfuerzo medio, arrojó 31 rechazos por parte de gpt-5.4-mini, 34 de luna y 30 de gpt-5.4-nano. Un modelo más grande apenas modificó los resultados; desactivar por completo el razonamiento de gpt-5.4-nano provocó cambios significativos.

El esfuerzo también tiene un perfil de costos distinto al de cualquier otro factor, ya que puede aumentar sin un techo fijo. Elevar el filtro de tema en un nivel de esfuerzo evitó 10 rechazos, pero con aproximadamente tres veces más uso de tokens, una opción que fue rechazada.

Qué no se midió

Ser explícito sobre las deficiencias forma parte del método.

• La configuración de luna enviada nunca se evaluó en comparación con las etiquetas definidas por humanos; esa prueba se interrumpió temprano. Ha funcionado en producción sin ni un solo fallo en las llamadas al modelo, lo cual no indica pérdida de calidad alguna.
• Un único punto de datos sugiere que luna rinde peor que gpt-5.4-mini en la clasificación de tipo de contenido, ya que descartó 9 artículos buenos mientras que gpt-5.4-mini solo descartó 5, con un nivel de esfuerzo que no se registró. Si disminuye el volumen de salida, ese es el primer elemento que hay que revisar.

Las cifras del filtro de temas se generaron mediante un mecanismo que envía el conjunto completo de artículos directamente a ese nodo. En la pipeline real, los pasos anteriores ya han eliminado la mayor parte de las entradas, por lo que los números absolutos están inflados. La puerta de relevancia es inmune a esto, ya que también recibe el flujo completo en producción. El control de calibración para el filtro de temas nunca se ejecutó, por lo que la forma de su curva es fiable, pero sus valores absolutos no lo son.

El ruido afecta en ambos sentidos. Una conclusión anterior de que un modelo era “verdaderamente mejor”, basada en una diferencia de 10 puntos, tuvo que retirarse cuando una tercera ejecución con la misma configuración arrojó resultados del otro lado. La solución es procedimental: cuantificar la desviación entre dos ejecuciones con el mismo setup antes de considerar cualquier diferencia entre dos configuraciones. Solo la pérdida de 15 artículos supera ese umbral, y se limita a un nodo.

Detalles de la medición

Se utilizaron dos conjuntos de muestras. En los experimentos de esfuerzo, se enviaron directamente todos los 198 artículos almacenados en caché a un único nodo, por lo que nada en la fase previa podía variar. En los experimentos de extremo a extremo, se procesó una muestra de 200 filas a través de cada nodo; esta incluía 72 artículos aprobados por humanos y 49 rechazados por ellos.

Se evaluó según esas etiquetas humanas:

• Configuración antigua (gpt-5-mini más gpt-5-nano): se conservaron 48 artículos buenos de los 72; 27 de los 49 artículos malos pasaron sin problemas.
• gpt-5.4-mini manejando los nodos de evaluación, con las correcciones en el prompt aplicadas: se conservaron 33 de los 72; 18 de los 49 pasaron sin problemas.
• Configuración actual (luna en nueve de cada diez llamadas): aún no se ha evaluado con ninguno de los conjuntos.

Esa última entrada permanecerá vacía hasta que se realice la revisión mensual, ya que las etiquetas solo existen una vez que se aplica el commit de eliminación, y en septiembre aún no se había realizado dicha eliminación al momento del análisis.

Signal de producción temprana

Los datos de producción ofrecen un sustituto parcial. Luna se puso en funcionamiento el 30 de agosto. Las tasas de inclusión para períodos comparables son las siguientes:

• Modelos anteriores del 1 al 29 de agosto: 4.55 por ciento (121 incluidos de 2,658).
• Modelos anteriores en los últimos ocho días antes del cambio: 4.86 por ciento (32 de 658).
• Luna desde el 30 de agosto hasta el 6 de septiembre: 4.08 por ciento (26 de 638).

Al comparar las dos ventanas de ocho días coincidentes con una prueba z de dos proporciones se obtiene un valor de 0.69, que está claramente dentro del rango de variabilidad normal. Para ponerlo en perspectiva, la configuración anterior presentó un porcentaje de 3.98 durante los primeros ocho días de agosto, una variación mayor dentro de su propia historia que el cambio introducido por luna. Una semana y un día es un período corto, y la tasa de inclusión no mide la calidad; sin embargo, el resultado más temido, que luna agote silenciosamente la cadena de procesamiento, no ha ocurrido.

El período en que Luna estuvo en producción también permitió obtener el primer desglose por nodo de las rechazos. En ese intervalo, Luna excluyó 603 artículos. La barrera de relevancia fue responsable del 42 por ciento de ellos, el filtro de tipo de contenido del 38 por ciento, el filtro temático del 16 por ciento y la verificación de novedad del 3 por ciento. En contraste, la configuración anterior excluyó 2,526 artículos entre el 1 y el 29 de agosto sin registrar ni una sola razón; por lo tanto, reconstruir esa fecha significaba volver a procesar los artículos en lugar de simplemente consultar los datos de producción. Si su pipeline actual no registra la razón del rechazo para cada paso, agregarla es la mejora más económica que puede realizar antes de una migración.

Límites de la verdad objetiva y de una sola ejecución

Los etiquetadores humanos tienen dos limitaciones inherentes. Solo cubren los artículos que el proceso anterior permitió pasar, por lo que una nueva configuración nunca podrá atribuirse el mérito de salvar algo que la anterior descartó erróneamente. Además, aproximadamente 79 filas de la muestra de 200 no cuentan con ningún veredicto humano en absoluto.

La varianza entre ejecuciones es alta. Tres ejecuciones repetidas con la misma configuración en los mismos 200 registros generaron tasas de rechazo del 37%, 48% y 55% en un único nodo, una diferencia mucho mayor de la que podría explicarse por el ruido de muestreo. Al repetir una ejecución completa de principio a fin con esa misma configuración, se crearon cuatro nuevos artículos y se perdieron otros cuatro. Al volver a ejecutar la configuración obsoleta contra los productos que había generado previamente en producción, solo se recuperaron 75 de sus 121 artículos etiquetados, por lo que solo coincidía con su propia historia en aproximadamente el 62% de los casos. En la práctica, una sola ejecución solo puede distinguir diferencias de unos 20 puntos en un nodo, o alrededor de ocho artículos en todo el proceso.

Un enfoque mejor para validar los cambios individuales: verificar cada cambio únicamente en los elementos que se supone deben corregirse, junto con un pequeño conjunto fijo que no debe modificarse, y confiar en la ejecución completa solo como una alarma aproximada ante daños colaterales significativos. Una corrección inmediata ilustró por qué. Hizo que cuatro artículos objetivo superaran el nodo que había reparado, pero apenas afectó el resultado final, ya que tres de esos cuatro fueron rechazados posteriormente por razones no relacionadas.

A dónde van realmente los tokens

El razonamiento consume tokens de salida, pero la salida no es lo que agota el límite asignado. La salida representó el 13 por ciento de todos los tokens con los modelos anteriores y menos del 3 por ciento con los nuevos; como las instrucciones son largas, la entrada domina.

En el momento de redactar este texto, el programa de intercambio de datos ofrece dos lotes diarios. El más grande, de 2,5 millones de tokens al día, se aplica a Luna y a las versiones nano y mini de GPT-5.4. El más pequeño, de 250 mil tokens al día, se aplica a los modelos de tamaño medio y grande. En un día laborable normal, el sistema consumió aproximadamente 1,95 millones de tokens con los modelos anteriores y unos 1,15 millones con la nueva gama. El mes exportado, compuesto en su mayor parte por la configuración antigua más ocho días de la nueva, habría costado unos 4 dólares según las tarifas flexibles, sin ningún descuento.

Por cada mil solicitudes, los costos de los modelos difieren significativamente:

• GPT-5-nano: 0,32 dólares
• GPT-5.4-nano: 0,52 dólares
• GPT-5.6-Luna: 0,65 dólares
• GPT-5-mini: 1,49 dólares
• GPT-5.4-mini: 3,29 dólares (muestra pequeña)

Luna no gana en precio por solicitud, y eso es aceptable. Cuesta mucho menos por solicitud que los modelos mini y utiliza el mismo recurso que los modelos nano.

Recargo por escritura en caché

La lista de precios oculta un detalle que merece ser leído con atención. Entre los modelos considerados, solo Luna cobra por escrituras en caché, a un precio un 25 por ciento más alto que su entrada normal sin caché. Dado que las solicitudes llegan de forma dispersa a lo largo del día en lugar de concentrarse, los registros del caché caducan entre solicitudes: el 57 por ciento de las entradas de Luna se facturaron como escrituras en caché y solo el 41 por ciento como lecturas en caché. El uso del caché sigue siendo beneficioso, ya que reduce la factura por entrada en un 23 por ciento en comparación con no usar caché, pero eso está lejos del 90 por ciento que implica el descuento por lecturas. Si su carga de trabajo es intermitente, obtendrá un mayor descuento; si es constante, debe presupuestar el recargo por escrituras.

Trampas de la API que hacen fallar cada solicitud

Ciertos comportamientos de los parámetros convierten un simple cambio de nombre en una interrupción del servicio. Según lo informado al momento de redactar este texto (verifique con la documentación actual):

• El esfuerzo de razonamiento por defecto no es consistente entre las diferentes versiones: medio en gpt-5, nulo en la familia 5.4, y nuevamente medio en 5.6. Por lo tanto, un simple cambio de nombre del modelo modifica silenciosamente el grado de razonamiento en cada llamada.
• El nivel máximo de esfuerzo solo está disponible en los modelos 5.6; solicitarlo en un modelo 5.4 hace que fallen todas las solicitudes.
• En el endpoint de completación de chat, cualquier nivel de esfuerzo superior a nulo combinado con herramientas funcionales es rechazado; dichas llamadas deben dirigirse al endpoint de respuestas. Dado que el valor por defecto de luna es medio, es imposible utilizar herramientas con luna en el endpoint de completación de chat a menos que se reduzca explícitamente el nivel de esfuerzo.

Ninguno de estos puede recuperarse en tiempo de ejecución. La lógica típica de intentos múltiples maneja errores del servidor, tiempos de espera y límites de frecuencia, pero no solicitudes inválidas; por lo tanto, una combinación inadecuada de modelo y esfuerzo falla en cada fila del proceso en lugar de solo una vez. Verifique la combinación de modelo y esfuerzo cuando se inicie el proceso, antes de procesar la primera fila. Para más información sobre estos dos puntos finales, consulte el artículo existente sobre items versus messages in OpenAI's Responses API.

Puntos clave

• Nunca evalúe a un modelo de reemplazo según su grado de acuerdo con el modelo que sustituye; utilice decisiones humanas registradas como valor de referencia real.
• Atribuya cada pérdida a un paso del proceso y divida los pasos con múltiples preguntas en veredictos separados que se registren.

Antes de volver a ajustar una instrucción, lea las razones indicadas por el nuevo modelo. Citaciones precisas de sus reglas significan que la instrucción está desactualizada, no el modelo.

Un modelo más estricto pero justificable en un punto donde las descartes son permanentes podría ser mejor gestionado de forma flexible que siendo fijo.

El esfuerzo de razonamiento corresponde a la combinación modelo-tarea. Establezcalo explícitamente en todas partes, mézcalo paso a paso y recuerde que es el único costo sin límite máximo.

Cuantifique primero la deriva de una ejecución a otra; solo confíe en las diferencias que superen ese valor.

El artefacto más útil para solicitar antes de aprobar una migración no es la cantidad de rechazos, sino un par de explicaciones del propio modelo sobre por qué descartó algo.

Lecturas relacionadas

• Dimensionamiento adecuado de LLMs: enrutamiento, recuperación y evaluación basadas en el tamaño bruto del modelo — Aprenda cómo elegir entre modelos de lenguaje pequeños y grandes según la carga de trabajo, medir el costo por tarea completada con éxito, y utilizar primero enrutamiento, RAG, caché y validación.
• Un evaluador de LLM sin dependencias con un juez en el que realmente se puede confiar — Cree una evaluación sencilla de LLMs a partir de registros reales, verificaciones de código y un juez basado en un único criterio, luego calibre a ese juez con etiquetas humanas para que sus puntuaciones tengan sentido.

Reverse Prompting: Convertir una buena sesión de LLM en un prompt reutilizable — Aprenda cómo extraer un prompt de uso único a partir de una conversación exitosa de múltiples turnos con un LLM, y cómo la inversión de prompts permite recuperarlos cuando solo se dispone de las salidas.

¿Afinar o llamar a la API? Costos de un pipeline de extracción de documentos — Un modelo de costos aplicado a un pipeline para documentos de auditoría muestra por qué la redirección al modelo es más económica que su afinación, y cuándo la precisión del esquema o la residencia de datos en la UE justifican poseer un modelo propio.

Herramientas de evaluación para aplicaciones de LLM: conjuntos de datos, escalado y barreras de regresión — Aprenda qué es una herramienta de evaluación para LLM, sus cuatro componentes principales y cómo detecta regresiones en los prompts y compara los modelos de manera justa antes de que lleguen a los usuarios.