Después de que se restringe el modelo de código abierto de China, lo primero que se bifurca es la versión y el calibre de evaluación.

Una vez que se levantan tales restricciones, lo primero que se descompone generalmente no es “¿todavía se puede descargar?”. pero “¿puede seguir basándose en el mismo conjunto de puntuaciones?”

El modelo en sí sigue ahí y la duplicación se puede sincronizar, pero el problema comienza a trasladarse de la entrada a la comparación. Una versión que funciona bien hoy tendrá ligeras diferencias en otra máquina debido a la división de peso, la versión del tokenizador, los parámetros de inferencia o los retrasos en la duplicación. Con solo mirar cada salida, parece que todavía funciona; una vez que se vuelve a colocar en el conjunto de regresión, la curva comienza a extenderse. Solía ​​ser que solo necesitaba mirar un puntaje total para decidir si actualizar, pero ahora primero debe analizar “si este cambio proviene del modelo o de la pila de servicios”.

El verdadero problema causado por las restricciones no está en la acción de descarga en sí, sino en la destrucción de las relaciones de comparación. En el pasado, solo necesitaba centrarse en una versión ascendente, pero ahora a menudo hay fuentes oficiales, fuentes espejo, cachés internos, versiones cuantificadas y versiones de reversión temporal al mismo tiempo. Se pueden ejecutar todas las líneas, pero los resultados ya no comparten la misma línea base. Una vez que se bifurca el conjunto de evaluación, el equipo perderá rápidamente un lenguaje común: I+D dice que esta versión se ha mejorado y el producto dice que la experiencia en línea no ha cambiado. Los solucionadores de problemas primero deben confirmar si el modelo ha cambiado o si el entorno de inferencia ha cambiado.

Lo más problemático de este tipo de bifurcación es que no se manifiesta inmediatamente como un mal funcionamiento. El primer día, sólo había una diferencia de 0,3 puntos entre los dos entornos. Al segundo día, cierta muestra de texto largo comenzó a desviarse. Después de retroceder al tercer día, descubrí que los resultados anteriores no se podían reproducir. En esta etapa, la discusión ya no gira en torno a “¿podemos conseguir el modelo?”. sino “si lo que obtenemos es lo mismo”.

Lo que realmente debería cerrarse primero no es la entrada de descarga, sino la línea de base. Es necesario concretar al menos las siguientes cosas:

• El hash, la versión del tokenizador, el método de cuantificación y los parámetros de inferencia del archivo del modelo.
• Conjunto de evaluación, palabras clave, parámetros de muestreo y lógica de posprocesamiento.
• Encapsulación de inferencia compartida por servicios en línea y regresión fuera de línea para evitar que los dos conjuntos de implementaciones se desvíen.
• Conserve la imagen anterior y la línea de base al retroceder, sin depender de la reconstrucción de la memoria.

Estas cosas pueden parecer triviales, pero una vez que el acceso al modelo comienza a restringirse, es esta capa de trivialidad la que es realmente valiosa. Sin ellos, el equipo sólo puede apostar en la próxima actualización con “esta vez se ve bien”; con ellos, al menos pueden confirmar si el problema radica en el modelo, la pila de inferencias o el conjunto de datos en sí.

Entonces, cuando este asunto finalmente recaiga en el proyecto, el juicio será muy simple: si se puede obtener el modelo es solo el comienzo; si el mismo conjunto de entradas, el mismo conjunto de parámetros y el mismo conjunto de muestras se pueden ejecutar continuamente en la misma línea determina si aún se puede utilizar de manera estable. Mientras se mantenga el calibre comparativo, todavía hay margen de maniobra en el modelo; una vez que el calibre diverge primero, el reemplazo, la reversión y la resolución de problemas posteriores serán más costosos.