Modelo abierto y modelo cerrado: la diferencia

Una distribuidora de recambios de Zaragoza quiere preparar respuestas con su catálogo público. Los ejemplos de Zaragoza y Valladolid son ilustrativos: no son casos de cliente ni tienen resultados medidos. El comercial aporta una consulta anonimizada, de la que ha retirado los datos personales, y un extracto del catálogo. Pide un borrador con las referencias que lo sostienen.

Puede estudiar un modelo descargable instalado por su proveedor técnico o un servicio gestionado, donde otra empresa administra el alojamiento. El encargo es el mismo en ambos caminos. En esta prueba de redacción, el sistema no consulta el programa de gestión ni acepta pedidos: el comercial comprueba compatibilidad, precio y existencias, y envía la respuesta validada.

Los pesos son los archivos que contienen lo aprendido por el modelo durante su entrenamiento. Recibirlos permite ejecutar una copia, dentro de las condiciones de su licencia. Si necesitas situar el concepto, empieza por qué es un modelo de IA. Una API es la conexión que permite a un programa utilizar otro servicio; no implica recibir sus archivos.

Pesos abiertos y código abierto no son equivalentes. La definición de IA de código abierto de la Open Source Initiative exige también código e información suficiente sobre los datos de entrenamiento para reconstruir un sistema sustancialmente equivalente. No exige publicar indiscriminadamente todos los datos originales. Por eso conviene leer qué se entrega y bajo qué permiso, en lugar de decidir por la palabra «abierto».

Antes de elegir un modelo por su nombre, pide una comprobación del equipo. Los requisitos de memoria se refieren a variantes concretas, no a cualquier descarga de esa familia. Confirma qué instalará tu técnico y qué máquina necesita. Que el archivo se pueda descargar no demuestra que funcione en tu ordenador ni cuánto tardará en responder a una consulta de tu empresa.

En Llama, la indicación 70B expresa el número de parámetros, los valores que el modelo ha aprendido; no son gigabytes necesarios para ejecutarlo. Pide al proveedor técnico que pruebe la variante elegida con una tarea representativa. Una pequeña ingeniería de Valladolid, por ejemplo, podría evaluar un resumen de instrucciones públicas de un proveedor antes de aportar documentación interna.

Separa licencia, operación y revisión al pedir presupuesto. Incluye equipo o alojamiento, consumo del modelo, puesta en marcha, mantenimiento y el tiempo de comprobar los resultados. Una suscripción al asistente y el consumo de una API no cubren necesariamente el mismo trabajo. No hay un punto de equilibrio universal entre comprar equipo y pagar por uso.

Al probar cómo redacta una respuesta con tu catálogo, conserva el documento de entrada y el borrador. Anota el tiempo de preparación, corrección y revisión. Valora el resultado completo frente a hacer esa misma tarea a mano: que la licencia permita utilizar el modelo no demuestra que su respuesta sea adecuada. Antes de contratar, pide una prueba con tu encargo y tus criterios de aceptación. Si necesitas ordenar los conceptos antes de contratar, empieza por la formación gratuita de Ciade y lleva un documento representativo de tu negocio como base para preparar esa prueba.