Solx
Lab

El borde decide, la red supervisa

6 min de lectura

Toda decisión crítica para el takt pertenece a la máquina. El modo de falla debe ser más lento, nunca más ciego.

Las fuentes citadas están en inglés; las citas textuales se reproducen en su idioma original.

Las discusiones sobre borde frente a nube suelen plantearse como una cuestión de infraestructura — dónde reside el cómputo, cuánto cuesta el viaje de ida y vuelta, cuánto ancho de banda consume una cámara. Creemos que ese planteamiento oculta la decisión que de verdad importa, que no es dónde ocurre un cómputo sino quién es responsable de la respuesta cuando el resto del sistema no está disponible.

Una manera útil de clasificar esto es preguntar, de cada decisión de un sistema de inspección: ¿cuál es su presupuesto de tiempo y qué le pasa a la línea si la respuesta llega tarde? Esa pregunta separa las decisiones con mucha más claridad que cualquier diagrama de cajas y enlaces, y tiene la ventaja de tratar sobre responsabilidad y no sobre topología.

Qué decisiones se toman en la máquina y cuáles se supervisan de forma centralizadaDos paneles. El primero cubre las decisiones que se toman en la máquina con un presupuesto de milisegundos, crítico para el takt: aceptar o rechazar una unidad, disparar y medir, detener la estación y almacenar el registro localmente. Si la red está a oscuras, estas no cambian. El segundo cubre el trabajo supervisado de forma centralizada con un presupuesto de segundos a horas, que no es crítico para el takt: el reconocimiento de patrones de toda la línea, la adjudicación de dictámenes inciertos, el despacho del trabajo de reparación y la supervisión y promoción de modelos. Si la red está a oscuras, ese trabajo se encola y se reanuda después. La línea sigue corriendo en cualquiera de los dos casos; pierde la supervisión, no la capacidad de decidir.En la máquinamilisegundos · crítico para el taktAceptar o rechazar esta unidadDisparar, exponer, medirDetener la estaciónAlmacenar el registro localmenteRed a oscuras → sin cambiosSupervisado centralmentesegundos a horas · no crítico para el taktReconocimiento de patrones de toda la líneaAdjudicar dictámenes inciertosDespachar trabajo de reparaciónSupervisar y promover modelosRed a oscuras → encola, reanudael modo de falla es más lento, nunca más ciego
Figura 1Clasificación de las decisiones según quién responde por ellas y qué le ocurre a cada una cuando la capa central no está disponible.

Qué pertenece a la máquina

Algunas decisiones tienen un presupuesto medido contra el takt. Llega una unidad, se requiere un juicio y la línea sigue avanzando haya llegado o no ese juicio. Aceptar o rechazar esta unidad. Disparar, exponer, medir. Detener la estación. Registrar lo que se vio.

Nuestra posición es que toda decisión de esa clase pertenece a la máquina — no porque la red sea lenta, sino porque una decisión que se puede aplazar es una decisión que puede bloquear la línea. En cuanto algo crítico para el takt depende de una respuesta remota, la disponibilidad de toda la línea de producción pasa a ser una función de la disponibilidad de algo que no es la línea de producción. Es una cosa extraña de aceptar, y por lo general se acepta de manera implícita, por arquitectura y no por decisión.

Si el hecho de que un servicio central sea inalcanzable puede detener la línea, entonces el servicio central es parte de la línea, diga lo que diga el diagrama de arquitectura.

El corolario es que la máquina tiene que poder mantener un registro completo de manera local. Si una estación puede decidir pero no puede recordar, la interrupción simplemente se desplaza: se siguen fabricando módulos y se pierde la evidencia de por qué cada uno recibió su disposición. Almacenar localmente, y reconciliar después, es lo que hace que la decisión sea genuinamente independiente en lugar de nominalmente independiente.

Qué se beneficia de verdad de ser central

El argumento a favor de la centralización es real, pero es un argumento distinto del que se suele hacer. No es que el cómputo central sea más grande. Es que algunas preguntas no tienen respuesta posible en una estación, porque son preguntas sobre la relación entre estaciones, o entre el ahora y la semana pasada.

El reconocimiento de patrones de toda la línea es el ejemplo más claro. Una estación individual ve sus propias unidades. No puede ver que una firma de defecto en una operación se correlaciona con un cambio de parámetro en una anterior, porque no tiene acceso a ninguna de las dos. Adjudicar los dictámenes inciertos es otro: llevar los casos genuinamente ambiguos a una sola cola donde una persona pueda trabajarlos es un problema de coordinación, no un problema de latencia. Despachar el trabajo de reparación es igual. También lo es supervisar modelos — decidir si un candidato es apto para promoverse es una pregunta sobre el comportamiento agregado a lo largo del tiempo, que es exactamente lo que una estación no puede ver.

Nótese que ninguna de estas es crítica para el takt. Cada una de ellas puede retrasarse segundos, minutos o, en algunos casos, horas sin que un módulo se fabrique de manera incorrecta. Eso no es una coincidencia; es el criterio de clasificación.

El modo de falla es la especificación

La mayor parte del valor de trazar la línea de esta manera aparece el día en que algo está roto. Si la capa central está a oscuras, las estaciones siguen decidiendo, siguen registrando y mantienen la línea corriendo. Lo que se pierde es la supervisión: nadie está mirando a través de las estaciones, la cola de adjudicación no se está trabajando, ningún modelo está siendo supervisado. El trabajo se acumula y se reconcilia cuando la capa vuelve.

Creemos que esa es la forma correcta de la degradación, y vale la pena enunciarla como un requisito en lugar de descubrirla como un comportamiento. El sistema debe volverse más lento, nunca más ciego. Un diseño en el que una interrupción hace que los módulos pasen sin ser examinados es peor que uno en el que una interrupción produce una acumulación de trabajo, aunque la acumulación sea más visiblemente molesta. La falla molesta es la falla segura.

Esto también establece correctamente la relación de supervisión. El trabajo de factores humanos sobre automatización distingue entre los sistemas que recomiendan un curso de acción y los sistemas que lo ejecutan[2], y la misma distinción es útil entre capas de un sistema de máquinas: la autoridad de la capa central se ejerce sobre modelos, umbrales y asignación de trabajo, no sobre la disposición de la unidad que está en este momento frente a una cámara.

Por qué no centralizaríamos la decisión aunque la latencia fuera gratis

Supongamos que la red fuera perfecta. Aun así pondríamos la decisión en la máquina, porque centralizarla crea un acoplamiento que no tiene nada que ver con la velocidad. Los sistemas de machine learning “interact directly with the external world”, y “the external world is rarely stable”[1]. Un servicio central de decisión es un único lugar donde un cambio — un modelo nuevo, la edición de un umbral, un cambio de esquema — llega a todas las estaciones a la vez. Eso es eficiente justo hasta el momento en que es una falla, momento en el cual es eficiente siendo una falla.

Mantener la decisión local significa que un cambio tiene que desplegarse, lo que significa que se puede desplegar de manera gradual y revertir estación por estación. Ese es el mismo argumento que se hace para la infraestructura de servicio en general: subir los modelos de manera gradual, correr el viejo y el nuevo de forma concurrente y poder revertir con rapidez[3]. Es mucho más fácil hacerlo cuando la unidad de despliegue es una estación que cuando es el único servicio del que todo depende.

Para qué sirve realmente la capa central

Planteada de esta manera, la capa central deja de ser el cerebro y pasa a ser algo más útil: el lugar donde se entiende la línea en lugar del lugar desde donde se opera. Observa, correlaciona, encola, supervisa, y guarda la memoria larga que ninguna estación individual tiene. El monitoreo continuo del comportamiento en vivo es el control que las pruebas no pueden reemplazar[1], y es una función genuinamente central — solo que no es una función crítica para el takt.

Estamos en una etapa temprana de esta construcción, y la clasificación se volverá más difícil a medida que existan más decisiones que clasificar. Pero la pregunta que pretendemos seguir haciendo sobre cada una es la misma: si esta respuesta nunca llega, ¿se detiene la línea o se alarga una cola? El primer tipo pertenece a la máquina. El segundo tipo es para lo que sirve la red.

Referencias

  1. 1.Sculley, D., et al.. Hidden Technical Debt in Machine Learning Systems. Advances in Neural Information Processing Systems 28, 2503–2511, 2015.
  2. 2.Parasuraman, R., Sheridan, T. B., & Wickens, C. D.. A Model for Types and Levels of Human Interaction with Automation. IEEE Transactions on Systems, Man, and Cybernetics — Part A, 30(3), 286–297, 2000.
  3. 3.Breck, E., Cai, S., Nielsen, E., Salib, M., & Sculley, D.. The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction. IEEE International Conference on Big Data, 1123–1132, 2017.
Todos los documentos