Elegir el modelo adecuado para una tarea específica no es una decisión sencilla. Cada modelo puede tener ventajas en un área, pero no necesariamente en otra. La clave está en alinear las capacidades del modelo con los objetivos reales del proyecto, considerando tres factores principales: la calidad de la salida, el coste por tarea y la latencia, es decir, el tiempo que tarda en responder.
La idea, paso a paso
La calidad no se mide solo por cómo suena la respuesta, sino por si cumple con la tarea definida. Por ejemplo, si el objetivo es extraer información de un documento, una respuesta que suene bien pero no capture los datos clave no es útil. Por otro lado, en una tarea creativa, la originalidad puede ser relevante, pero no siempre. La forma de evaluar la calidad debe estar basada en criterios claros que reflejen los requisitos del proyecto.
Un ejemplo para entenderlo
Prepara dos tareas: extraer campos de documentos ficticios y proponer títulos para un artículo. En la primera, define qué campos deben coincidir con el original. En la segunda, define qué hace que un título resulte útil. Compara los candidatos con los mismos casos y registra reintentos y tiempo total; una única respuesta vistosa no permite elegir.
Qué conviene comprobar
El coste no siempre se reduce a un precio por token, sino que también incluye el número de reintentos necesarios. Un modelo barato puede requerir más intentos para obtener una salida válida, lo que eleva el coste total. Por eso, es importante comparar modelos con la misma información de entrada y bajo los mismos criterios, sin depender exclusivamente del precio anunciado.
La latencia, o tiempo de respuesta, es otro factor clave. Un modelo rápido puede ser más eficiente en entornos interactivos, pero si la tarea no requiere una respuesta inmediata, puede no ser un factor determinante. La latencia debe medirse desde el inicio hasta el final del proceso, incluyendo cualquier paso adicional que se necesite para procesar la salida.
Al elegir un modelo, es común cometer errores como comparar con criterios diferentes o depender de una sola métrica. Por ejemplo, centrarse solo en el coste sin considerar la calidad o la latencia puede llevar a una solución que, aunque económica, no cumple con los requisitos del proyecto. Otro error es usar el propio modelo para evaluar su rendimiento, lo que puede introducir sesgos.
Para evitar estos problemas, es útil diseñar una serie de casos de prueba y una rúbrica sencilla antes de evaluar modelos. Por ejemplo, se pueden definir cinco escenarios distintos que representen las tareas que el modelo debe realizar. Cada caso debe incluir una entrada clara y una salida esperada, junto con criterios de evaluación específicos. La rúbrica puede incluir aspectos como la precisión, la completitud de la respuesta, la coherencia y el tiempo de respuesta.
Compara la tarea completa, incluyendo recuperación, herramientas y reintentos cuando existan. Los precios y las capacidades cambian; este artículo no establece un ranking vigente de proveedores. Un conjunto pequeño de pruebas es un punto de partida que debe ampliarse si aparecen fallos o casos nuevos.
Pruébalo con un caso pequeño
Diseña cinco casos de prueba y una rúbrica sencilla antes de elegir proveedor.
Para revisar tu ejercicio, distingue qué dato entra, qué resultado esperas y con qué evidencia lo comprobarías. Si aparece una duda, anótala como tal en lugar de completar el dato. El propósito es detectar una decisión concreta que puedas justificar, no obtener una respuesta que solo suene convincente.
Cómo leer el esquema
La ilustración organiza los conceptos explicados en el artículo. Es un esquema educativo, no una medición de un sistema real.
Fuentes
Documentación original utilizada para los conceptos de este artículo.