Cómo elegir un modelo de IA local con tus propias tareas

La pregunta útil no es cuál modelo es mejor en general

Si tienes varios modelos locales candidatos, una puntuación publicada o una demostración convincente no basta para saber cuál te servirá en tu flujo de trabajo. La decisión relevante es más concreta: ¿cuál de estos modelos resuelve de forma aceptable la tarea que realmente quieres hacer, con el equipo y la configuración que vas a utilizar?

Una prueba de aceptación responde esa pregunta mediante un conjunto reducido de tareas reales o representativas, criterios definidos antes de ver las respuestas y condiciones de ejecución comparables. Por ejemplo, un equipo que quiere clasificar solicitudes podría comprobar si cada modelo asigna correctamente una categoría y devuelve una salida que su sistema pueda procesar. La evaluación no consiste en elegir la respuesta que suena mejor, sino en comprobar requisitos observables.

Este método no convierte una muestra pequeña en una clasificación general de modelos. Puede revelar incompatibilidades prácticas —como un formato que no se respeta o errores en un tipo frecuente de entrada—, pero no demuestra que el candidato sea fiable en tareas distintas, con otros usuarios o en otro hardware. La conclusión debe mantenerse dentro de los límites de lo que se probó.

El objetivo también es distinto al de comparar cuantizaciones: durante esta prueba conviene mantener fija la configuración pertinente, en lugar de decidir entre 4, 6 u 8 bits. Tampoco es una prueba de concurrencia, que examina solicitudes simultáneas, ni una auditoría de privacidad, que investiga el tráfico de red. Si una de esas cuestiones es decisiva, requiere una evaluación aparte.

Empieza por definir la tarea y el umbral de aceptación

Antes de descargar candidatos, describe el trabajo que quieres delegar. Evita objetivos vagos como «responder bien» o «ser inteligente». Especifica qué recibe el modelo, qué resultado esperas y qué errores impedirían usarlo. Cuanto más se parezca la descripción a una tarea del flujo de trabajo, más fácil será diseñar ejemplos que discriminen entre candidatos.

Define también qué significa «aceptable». Un borrador puede ser útil aunque necesite revisión; una extracción de datos que se incorpora automáticamente a una base quizá requiera campos completos y formato válido en cada caso crítico. Son decisiones del equipo, no propiedades universales de un modelo. Escríbelas antes de comparar las respuestas para reducir el riesgo de cambiar la vara de medir a favor de un candidato.

Separa los criterios que describen resultados distintos. Corrección del contenido, seguimiento de instrucciones y validez del formato no son intercambiables. Una respuesta puede ser correcta pero incumplir el esquema requerido; otra puede tener el formato perfecto y contener un dato erróneo. Si se combinan sin explicación en una sola nota, se pierde información que puede cambiar la decisión.

Cuando haya más de una persona evaluando, acuerden de antemano cómo resolverán los desacuerdos. En tareas subjetivas, es útil que dos evaluadores valoren al menos una parte de los ejemplos por separado y comparen sus razones. Si discrepan, anoten qué regla quedó ambigua y ajústenla antes de interpretar diferencias pequeñas entre modelos. No es necesario fingir que una preferencia estilística tiene una respuesta objetiva.

Selecciona candidatos y fija las condiciones

Compara candidatos que tengan sentido para el mismo uso. Registra el identificador exacto y la versión disponible de cada modelo, junto con el runtime, el equipo, el sistema de ejecución y los parámetros relevantes. Si no conservas esos datos, una diferencia observada puede deberse al entorno y no al modelo, y otra persona tendrá dificultades para repetir la prueba.

Mantén iguales las condiciones que puedas controlar: hardware, runtime y su versión, texto de instrucciones, ejemplos de entrada, límite de contexto, parámetros de generación y tratamiento de la salida. Si un modelo necesita una configuración distinta para arrancar, documenta la excepción y considera si la comparación sigue respondiendo a la misma pregunta. No cambies parámetros a mitad de la prueba para mejorar las respuestas de un favorito sin volver a ejecutar los demás en condiciones equivalentes.

En generadores con variación entre ejecuciones, registra también los parámetros que influyen en la generación y repite casos seleccionados. Una repetición no elimina toda la incertidumbre, pero puede mostrar que el resultado depende de una salida afortunada. La documentación de Ollama, por ejemplo, describe parámetros de generación configurables en su formato Modelfile; la configuración concreta disponible y su significado deben verificarse en la documentación vigente del runtime que se use.

El registro de memoria y latencia debe describir el método, no solo el número. Anota qué operación mediste, qué herramienta usaste, cuántas repeticiones hiciste y si el sistema estaba realizando otras tareas. Una medición local puede ser útil para decidir en ese equipo, pero no se traslada automáticamente a otro dispositivo.

Construye un conjunto pequeño que represente el trabajo

No elijas únicamente ejemplos fáciles ni casos que recuerdes porque un candidato los resolvió bien. Reúne entradas típicas del uso previsto y añade situaciones que suelen causar problemas. Una muestra inicial puede ser pequeña si cada caso tiene un propósito explícito; lo importante es que no se presente como representación estadística de todo el trabajo.

Incluye al menos tres clases de entrada: casos comunes, casos límite y casos en los que el modelo debería reconocer que la información disponible no basta. Si la tarea depende de instrucciones de formato, añade ejemplos que permitan comprobarlas. Si depende de contenido proporcionado por el usuario, comprueba si el modelo se ciñe a ese contenido en lugar de completar vacíos con suposiciones.

Prepara una respuesta esperada o una guía de evaluación para cada ejemplo antes de ejecutar los modelos. No siempre es necesario fijar una única frase como respuesta correcta: para un resumen, puede ser más adecuado listar hechos que deben aparecer y afirmaciones que no deberían añadirse. Para una extracción estructurada, en cambio, puede haber valores concretos y un formato esperado.

Protege la calidad del conjunto. Evita incluir información confidencial si no es necesaria, elimina identificadores personales que no formen parte del caso y conserva las entradas de manera que los evaluadores sepan qué datos estaban disponibles. Si cambias un ejemplo después de ver los resultados, márcalo como una nueva versión; no mezcles silenciosamente la prueba original con una revisada.

Evalúa dimensiones separadas y registra los fallos

Una rúbrica práctica distingue, como mínimo, corrección para la tarea, seguimiento de instrucciones, utilidad del formato y errores críticos. Define qué cuenta como error crítico para el uso previsto: por ejemplo, una extracción incorrecta que se procesaría sin revisión puede tener un coste distinto de una frase poco elegante en un borrador. No uses una lista genérica de riesgos como sustituto de la definición del equipo.

Además de la calidad de tarea, mide latencia y memoria observada por separado. Estas dimensiones responden a preguntas diferentes: si el resultado sirve, cuánto tarda bajo el método elegido y qué recursos mostró consumir el sistema durante esa ejecución. Evita mezclarlas en una nota única salvo que expliques cómo se ponderaron y por qué esos pesos representan una necesidad real. A menudo resulta más útil presentar una tabla de resultados por dimensión y discutir los compromisos.

Registra cada fallo con el caso, la respuesta, el criterio incumplido y la gravedad asignada. Agrupa los fallos por tipo, como omisión, dato inventado, formato inválido o instrucción ignorada, siempre que esas categorías correspondan a la tarea. Así podrás distinguir un patrón repetido de un desacierto aislado. No ocultes una falla crítica detrás de un promedio alto en casos sencillos.

Las mediciones de rendimiento requieren una nota metodológica. La herramienta llama-bench de llama.cpp documenta repeticiones y estadísticas como promedio y desviación estándar, además de medidas distintas para el procesamiento del prompt y la generación. También señala límites de lo que incluye su medición. Esto ilustra por qué conviene describir exactamente qué se midió, en vez de tratar cualquier cifra como una medida universal de rapidez.

Ejecuta, revisa y toma una decisión acotada

Ejecuta cada caso con el mismo prompt y las condiciones registradas. Conserva las salidas originales, incluidos los resultados defectuosos; editar o descartar una respuesta antes de evaluarla hace que la prueba sea menos reproducible. Si hay variabilidad, repite los casos elegidos con un procedimiento definido y guarda cada salida, no solo la que parezca más representativa.

Para reducir sesgos, evalúa las respuestas sin mostrar el nombre del modelo cuando sea factible. Si no es posible ocultarlo, al menos aplica la misma rúbrica a todos los candidatos y registra los desacuerdos. En una revisión humana, criterios explícitos y evaluadores adicionales cuando sea posible ayudan a identificar decisiones subjetivas; si informas el acuerdo entre evaluadores, explica qué se comparó y cómo se resolvieron las diferencias.

Al terminar, decide si cada candidato se adopta para un uso limitado, se ajusta y vuelve a probar, o se descarta. Un ajuste cambia las condiciones de la prueba: guarda la versión anterior y repite de forma comparable. La elección puede depender de un requisito excluyente —por ejemplo, que todos los campos obligatorios sean válidos— y no de quién obtuvo la mejor puntuación global.

Una decisión responsable también puede ser «ninguno cumple». Si los fallos afectan a requisitos esenciales, no hace falta elegir el menos malo para cerrar la comparación. Si un candidato parece adecuado, la conclusión sigue siendo provisional y circunscrita a los ejemplos, la configuración y el equipo probados.

Límites, mantenimiento y recursos relacionados

Una prueba pequeña está expuesta al sesgo de selección: los ejemplos pueden favorecer una forma de redactar, un dominio o un tipo de entrada. También depende del prompt y de la configuración. Publica qué casos usaste, qué criterios aplicaste y las condiciones de ejecución; no extrapoles el resultado a otras tareas, versiones, equipos o poblaciones de usuarios sin evidencia adicional.

Si el uso cambia, revisa la prueba. Añadir una nueva fuente de datos, cambiar el formato de entrada o automatizar una respuesta que antes revisaba una persona puede alterar qué fallos importan. Conserva versiones del conjunto y de la rúbrica para poder interpretar una comparación posterior. Una puntuación antigua no garantiza que el comportamiento siga siendo aceptable después de modificar el sistema.

Las herramientas de evaluación pueden ayudar a organizar tareas y métricas, pero no deciden qué significa el éxito en tu caso. El proyecto lm-evaluation-harness documenta tareas, métricas, prompts personalizados y evaluación local. Puede servir como referencia o herramienta cuando se ajuste a la necesidad, pero una puntuación producida por una tarea estándar no reemplaza ejemplos propios ni demuestra que el modelo cumpla tus requisitos.

Esta guía se centra en aceptar o descartar candidatos para una tarea concreta. Para ampliar la investigación, consulta la guía de modelos locales, el comparador y el área de descubrimiento. Si tu siguiente pregunta es sobre cuantización, concurrencia o privacidad, trátala como una decisión separada: cambiar el foco sin cambiar también el protocolo puede hacer que la comparación ya no responda a la pregunta inicial.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.