Si no puedes reproducir el modelo, entonces no es de código abierto
Si los modelos de IA deberían llamarse “código abierto” es un tema discutido, y muchos argumentan que publicar solo los pesos del modelo —sin conjuntos de datos, canalizaciones de recopilación de datos ni recetas completas de entrenamiento— se queda corto frente a la transparencia y reproducibilidad que tradicionalmente se esperan del software de código abierto. Otros replican que lo que más importa a la mayoría de usuarios es poder descargar, ejecutar y ajustar los modelos, y que publicar todos los datos suele ser impracticable por razones de costo, legalidad y privacidad. El intercambio pone de relieve una división emergente entre “open weights” y modelos realmente reproducibles, así como los esfuerzos en curso de grupos como la Open Source Initiative y Debian para aclarar qué debería significar “abierto” en la era de la IA.
Qué significa “código abierto” para los modelos de IA
- Muchos sostienen que, si un modelo no puede reproducirse a partir de los datos + el código + la receta de entrenamiento, no debería llamarse “código abierto”, sino solo “open weights” o “modelo disponible”.
- Otros responden que el código abierto clásico nunca garantizó reproducibilidad ni asequibilidad; el acceso al código (o a los pesos + el ejecutor) es suficiente, aunque la mayoría no tenga capacidad de cómputo.
- Hay debate sobre qué cuenta como “fuente” en ML: los pesos, los conjuntos de datos, los scripts de entrenamiento o toda la canalización. Con frecuencia se invocan las definiciones de GPL/OSI sobre la “forma preferida para hacer modificaciones”, pero se aplican de manera inconsistente.
Papel de los datos, el código y la reproducibilidad
- Algunos consideran que los conjuntos de datos y los scripts de recopilación/filtrado son las piezas cruciales que faltan; sin ellos no puedes reentrenar, auditar sesgos ni verificar afirmaciones.
- Otros sostienen que los pesos entrenados son la “fuente” práctica, porque la mayor parte del trabajo útil se hace mediante fine-tuning o añadiendo capas, no reentrenando desde cero.
- La reproducibilidad se complica aún más por el entrenamiento no determinista, los enormes costos de cómputo y las fuentes de datos que desaparecen o son privadas.
Valor práctico frente a pureza filosófica
- Un grupo se centra en las libertades del usuario: descargar, ejecutar localmente, modificar (mediante fine-tuning) y compartir derivados. Ven los LLM “abiertos” actuales como una ganancia enorme frente a los servicios solo por API.
- Otro grupo destaca la autonomía a largo plazo: sin datos ni recetas, la comunidad no puede realmente bifurcar ni շարունակimar modelos si los patrocinadores originales dejan de publicar versiones.
- Se hacen comparaciones con blobs de firmware en Linux: mejor que nada, pero no completamente abiertos.
Preocupaciones legales y éticas sobre los datos
- Muchos creen que los conjuntos de datos siguen siendo cerrados para evitar demandas por copyright y reacciones públicas negativas por fuentes controvertidas (p. ej., libros, redes sociales, contenido pirateado).
- Existe la preocupación de que los usuarios de modelos opacos puedan depender sin saberlo de datos infringidos o sesgados.
Cómputo, viabilidad e iniciativas emergentes
- Varios señalan que entrenar modelos de última generación está fuera del alcance de la mayoría de las personas, pero los modelos más pequeños y útiles sí son viables para organizaciones sin ánimo de lucro y laboratorios.
- Se citan algunos proyectos (p. ej., Pythia, StableLM, esfuerzos tipo RedPajama) como intentos de entrenamiento totalmente documentado o con datos públicos, aunque la verdadera reproducibilidad de extremo a extremo sigue siendo rara.
- Se mencionan trabajos de estandarización (p. ej., el “deep dive” de OSI, la política de ML de Debian) e ideas como “Dockerfiles para modelos” o pruebas de conocimiento cero del entrenamiento como posibles caminos a seguir.