#opg $OPG
Solía evaluar la IA verificable con una regla perezosa:
La prueba más fuerte debe ser la mejor prueba.
Luego miré cómo @OpenGradient gestiona diferentes cargas de trabajo y me di cuenta de que esa regla haría que la IA fuera casi inutilizable.
Una conversación normal en chat.opengradient.ai necesita privacidad, una prueba de que el código aprobado manejó la solicitud, y una respuesta lo bastante rápida como para sentirse como chat. Un TEE encaja en ese trabajo porque proporciona una atestación respaldada por hardware sin obligar al usuario a esperar la generación de pruebas pesadas.
ZKML resuelve un problema más difícil.
Puede demostrar matemáticamente que un modelo en particular produjo un resultado en particular. Ese nivel de certeza tiene sentido cuando una salida de ML podría desencadenar una liquidación, mover fondos o alterar una decisión en cadena.
Pero generar esa prueba puede costar miles de veces más cómputo.
Poner ZKML detrás de cada frase de un LLM y el “asistente” seguro se convierte en una sala de espera costosa.
Luego están las firmas. Pueden mostrar qué nodo devolvió una salida y si se alteró, pero no prueban que la ejecución en sí fuera correcta. Tal vez eso todavía sea suficiente para experimentos o tareas de bajo riesgo.
Lo que me hizo clic es que no son versiones más fuertes o más débiles de la misma herramienta.
Protegen contra fallos diferentes.
El punto fuerte de OpenGradient es permitir que la verificación se ajuste a la consecuencia de la respuesta, incluso mezclando métodos cuando un flujo de trabajo contiene distintos niveles de riesgo.
La pregunta no es, “¿Por qué no usa todo la prueba más fuerte?”
Es, “¿Qué se perdería realmente si esta respuesta en particular estuviera equivocada?”
Eso se siente como una base mucho más práctica para $OPG .
Solía evaluar la IA verificable con una regla perezosa:
La prueba más fuerte debe ser la mejor prueba.
Luego miré cómo @OpenGradient gestiona diferentes cargas de trabajo y me di cuenta de que esa regla haría que la IA fuera casi inutilizable.
Una conversación normal en chat.opengradient.ai necesita privacidad, una prueba de que el código aprobado manejó la solicitud, y una respuesta lo bastante rápida como para sentirse como chat. Un TEE encaja en ese trabajo porque proporciona una atestación respaldada por hardware sin obligar al usuario a esperar la generación de pruebas pesadas.
ZKML resuelve un problema más difícil.
Puede demostrar matemáticamente que un modelo en particular produjo un resultado en particular. Ese nivel de certeza tiene sentido cuando una salida de ML podría desencadenar una liquidación, mover fondos o alterar una decisión en cadena.
Pero generar esa prueba puede costar miles de veces más cómputo.
Poner ZKML detrás de cada frase de un LLM y el “asistente” seguro se convierte en una sala de espera costosa.
Luego están las firmas. Pueden mostrar qué nodo devolvió una salida y si se alteró, pero no prueban que la ejecución en sí fuera correcta. Tal vez eso todavía sea suficiente para experimentos o tareas de bajo riesgo.
Lo que me hizo clic es que no son versiones más fuertes o más débiles de la misma herramienta.
Protegen contra fallos diferentes.
El punto fuerte de OpenGradient es permitir que la verificación se ajuste a la consecuencia de la respuesta, incluso mezclando métodos cuando un flujo de trabajo contiene distintos niveles de riesgo.
La pregunta no es, “¿Por qué no usa todo la prueba más fuerte?”
Es, “¿Qué se perdería realmente si esta respuesta en particular estuviera equivocada?”
Eso se siente como una base mucho más práctica para $OPG .