JetBrains presenta un experimento práctico para probar tres modelos modernos de detección de objetos: YOLO12, YOLO26 y RF-DETR, no solo con datos de referencia, sino también con imágenes que representan casos más cercanos al uso real: daños en cables, fracturas óseas en radiografías y botellas de bebidas apiladas. La conclusión principal es clara: un modelo preentrenado no es necesariamente un modelo listo para desplegar.
Los modelos se basaban principalmente en los datos de COCO, que incluyen unas 118.000 imágenes de entrenamiento y 80 categorías comunes, como personas, coches, perros y sillas. Sin embargo, algunos objetivos prácticos, como una fractura ósea, ni siquiera pertenecen al vocabulario de esas categorías, mientras que las radiografías, las imágenes industriales y las escenas visualmente abarrotadas difieren de las imágenes naturales a las que los modelos están acostumbrados.
Verificar la línea base antes del entrenamiento
Antes de pasar al ajuste fino, JetBrains evaluó seis puntos de control, dos tamaños por cada una de las tres familias, en el conjunto de validación de COCO val2017, compuesto por 5.000 imágenes. RF-DETR Base obtuvo la puntuación mAP50-95 más alta, con 0.5325, mientras que los dos modelos medianos de YOLO se acercaron a ese resultado, con 0.5259 y 0.5181, y unos 10 millones menos de parámetros.
La comparación también mostró diferencias prácticas en velocidad. YOLO26-N registró un tiempo de 12.3 milisegundos, con una puntuación mAP50-95 cercana a la de YOLOv12-N, que registró 23.9 milisegundos pese a ser el más pequeño del experimento. En cuanto a RF-DETR Nano, su tiempo fue de 12.4 milisegundos, aunque su número de parámetros se aproxima a los 30 millones, superando al de YOLO26-M.
Estas cifras no coinciden necesariamente con las publicadas en los artículos de los modelos, porque el experimento utilizó hardware distinto de la unidad NVIDIA T4 habitual en las comparaciones y ejecutó los modelos dentro de sus marcos originales, sin convertirlos a TensorRT. JetBrains explica que TensorRT puede reducir el tiempo de inferencia fusionando capas y seleccionando kernels optimizados para el hardware, pero requiere un paso de compilación adicional y genera un motor vinculado a una unidad de procesamiento gráfico específica. Por ello, las cifras del experimento reflejan un rendimiento más cercano a la ejecución directa, no el máximo rendimiento posible tras la optimización.
La prueba fuera del alcance del entrenamiento
El experimento utilizó tres conjuntos de RF100-VL, un conjunto que incluye 100 conjuntos de datos multimodales diseñados para abarcar objetivos poco frecuentes en los datos de entrenamiento habituales. Los conjuntos seleccionados fueron bone-fracture-7fylg, cable-damage y soda-bottles.
Al ejecutar directamente sobre estos datos los puntos de control entrenados con COCO, el resultado fue prácticamente nulo. JetBrains explica que esto se debe a que los modelos utilizados son detectores de vocabulario cerrado: disponen de un número limitado de categorías y no pueden producir una categoría como fracture si no está presente en la cabeza del modelo, compuesta por 80 categorías. Por lo tanto, que un modelo obtenga un mAP50 de 0.72 en COCO no significa que vaya a reconocer automáticamente fracturas óseas.
¿Qué cambia con el ajuste fino?
JetBrains ajustó los tres modelos en cada conjunto de datos durante 10 épocas de entrenamiento utilizando una única unidad A100, basándose en las rutas de entrenamiento habituales de Ultralytics y RF-DETR. Tras el entrenamiento, los resultados mejoraron claramente en las tareas de daños en cables y botellas de bebidas, mientras que la tarea de fracturas óseas siguió siendo la más difícil.
Las botellas de bebidas fueron el caso más sencillo: la puntuación mAP50 de todos los modelos osciló entre 0.91 y 0.97, y YOLOv12-M obtuvo el mejor mAP50-95, con 0.6422. JetBrains considera que la razón es la cercanía de las imágenes de productos a algunas categorías presentes en COCO, lo que hace que el problema se parezca más a añadir un vocabulario nuevo que a pasar completamente de un dominio visual a otro.
En la tarea de daños en cables, el mAP50 alcanzó 0.93, pero el mAP50-95 más alto no superó 0.446. Esto significa que los modelos pueden localizar los daños con bastante precisión, pero tienen dificultades para dibujar cuadros delimitadores precisos alrededor de defectos delgados y alargados. En las imágenes de fracturas óseas, el mejor mAP50, registrado por RF-DETR Base, fue de solo 0.447, con grandes variaciones entre los modelos. La inspección visual también mostró que en algunos resultados se detectó una fractura en menos de la mitad de las imágenes.
¿Qué debería revisar el equipo de desarrollo?
- Comienza con una línea base reproducible: verifica el rendimiento de los puntos de control en tu entorno y con tu hardware antes de comparar los resultados con las cifras publicadas.
- Separa los entornos de software: JetBrains utilizó tres entornos uv aislados dentro de un único proyecto de PyCharm, porque las versiones de la biblioteca ultralytics requeridas por las generaciones de YOLO no son compatibles. El uso del intérprete remoto en PyCharm requiere la edición Professional, mientras que Community Edition solo admite entornos locales.
- No te limites a una sola métrica: la diferencia entre mAP50 y mAP50-95 en los daños de cables revela un problema de posicionamiento preciso que podría no aparecer al observar únicamente el mAP50.
- Relaciona la elección del modelo con la tarea: RF-DETR Base mostró una mayor consistencia y ganó en dos de los tres conjuntos de datos, pero eso no lo convierte en el mejor para todos los casos.
- Planifica los datos cuando el cambio sea grande: los resultados de las radiografías indican que el ajuste fino por sí solo podría no ser suficiente, y que podrían ser necesarios más datos, un entrenamiento más prolongado o un preentrenamiento especializado en el dominio. El material plantea estas opciones, pero no demuestra que ninguna de ellas sea superior en este experimento.
El experimento confirma que las expresiones «avanzado» o «preentrenado» no resumen la idoneidad de un modelo de detección de objetos para un entorno de despliegue. La decisión práctica debe equilibrar la precisión, el tiempo de inferencia, el tamaño del modelo, los requisitos de licencia y, sobre todo, el grado de similitud entre los datos de entrenamiento y el dominio objetivo. Asimismo, los resultados de JetBrains siguen estando vinculados a los tres conjuntos de datos y a las configuraciones de entrenamiento utilizadas, por lo que no deben generalizarse como una clasificación definitiva para todas las tareas de detección.