Por qué no hay un punto de acceso
El modelo, el entorno de ejecución y el análisis se descargan en el navegador y se ejecutan allí. Eso no es una opción de implementación que se pueda revertir con un indicador; es toda la arquitectura, y es la razón por la cual una imagen nunca abandona el dispositivo en el que se comprueba.
Una API invierte eso. Alguien envía una imagen a un servidor, el servidor la evalúa y devuelve un número, y la imagen pasa a existir en una infraestructura que controla otra persona, por muy brevemente que sea y por muy buenas que sean sus intenciones.
Para una herramienta cuya única propuesta es que no se sube nada, ofrecer un punto de acceso de subida significaría que el producto se contradice a sí mismo. Por lo tanto, esta página no describe una hoja de ruta; describe un límite y qué hacer al respecto.
Vale la pena decirlo claramente porque la alternativa es peor. Una página que sugiera un punto de acceso que no existe hace perder una tarde a un ingeniero, y la página de precios de este sitio ya indica que no hay ningún nivel de pago ni API.
Para qué sirve realmente la automatización
Antes de recurrir a un punto de acceso, conviene ser preciso sobre la tarea, porque una buena parte de la automatización prevista se resuelve mejor de otra manera.
| Necesita un servicio | La herramienta de navegador funciona | Un paso humano es mejor | |
|---|---|---|---|
| Filtrar subidas de usuarios a escala | Yes Volumen y latencia | No | No |
| Comprobar la entrega de un proveedor | No | Yes Un lote de 25 es suficiente | Partly |
| Revisar un conjunto de reclamaciones | No | Yes Un lote por presentación | Yes El criterio es el trabajo |
| Auditar su propio sitio | Partly Solo si es enorme | Yes Extraer y procesar por lotes | No |
Tres de esas cuatro filas se satisfacen con una persona que ejecuta lotes, lo cual conviene establecer antes de que nadie escriba código. La primera fila es genuinamente diferente y es la que necesita un servicio alojado.
Si realmente necesita automatización
Hay tres caminos honestos, y cada uno sacrifica algo diferente. Pretender lo contrario no ayuda a nadie.
| Opción | Compromiso | Ideal para |
|---|---|---|
| Una API comercial | Las imágenes abandonan su infraestructura | Alto volumen, baja sensibilidad |
| Autohospedar un modelo abierto | Tiempo de ingeniería y hardware | Datos sensibles, capacidad interna |
| Ejecutarlo en un navegador que usted controle | Incómodo pero privado | Volumen moderado, privacidad estricta |
| Muestrear en lugar de filtrar | La cobertura es parcial | La mayoría de cargas de trabajo reales |
| Un paso de revisión humana | Juicio más lento y mejor | Cualquier cosa que afecte a una persona |
La tercera fila merece una explicación porque está infrautilizada. Un navegador sin interfaz gráfica (headless) ejecutándose en tu propia máquina, controlando una página que hace el análisis localmente, es una forma legítima de automatizar sin enviar imágenes a ninguna parte. No tiene glamour y funciona.
La cuarta fila es la que la mayoría de los equipos debería elegir y rara vez considera. Filtrar cada imagen es caro y por lo general innecesario; muestrear un diez por ciento, más todo lo que provenga de una fuente que haya dado problemas antes, detecta la mayor parte de lo que importa a una fracción del coste.
Si te alojas tú mismo
Esto es más viable de lo que se asume, porque los modelos de investigación en este campo son en gran medida públicos. Un punto de control (checkpoint) publicado con una licencia permisiva, un motor de inferencia (runtime) y un servidor modesto reproducirán la mayor parte de lo que vende un servicio comercial.
Lo que asumes es todo lo que rodea al modelo. Mantenerlo actualizado a medida que cambian los generadores, calibrar un umbral para tu propio material, medir tu propia tasa de falsos positivos y contar con alguien que pueda explicar un resultado cuando se cuestione.
Ese último punto es el coste oculto. Una capacidad de detección que nadie en la organización entiende lo suficiente como para defender es un riesgo la primera vez que se cuestiona una decisión basada en ella, y esa pregunta siempre llega tarde o temprano.
Construyas lo que construyas, integra esto
Dos decisiones de diseño importan más que el modelo que utilices, y ambas tienen que ver con lo que ocurre después de la puntuación.
Nunca dejes que una puntuación decida nada sobre una persona de forma automática. Deriva las alertas a un humano, registra lo que decidió el humano en lugar de lo que dijo el modelo, y asegúrate de que se le pueda explicar a la persona afectada por qué se ha cuestionado algo.
Y almacena resultados, no puntuaciones. Un historial searchable de números asociados a usuarios o proveedores con nombre es un registro de perfiles que necesitará su propia justificación, no aporta valor operativo y se convierte en un problema en el momento en que alguien solicita sus datos.
Un punto de partida realista
Para la mayoría de los equipos que llegan aquí buscando automatización, la primera versión sensata no implica ingeniería alguna. Una persona, un lote por cada envío entrante, y una nota en el archivo sobre lo que encontraron.
Eso produce algo valioso en una semana: una idea de las puntuaciones que obtiene tu propio material. Casi nadie tiene eso cuando empieza, y sin ello cualquier umbral que establezcas en el código es una conjetura sobre una distribución que nunca has medido.
Una vez que sepas dónde se sitúan tus imágenes, el argumento a favor de la automatización se vuelve concreto en lugar de teórico. Sabrás cuántos envíos a la semana realmente merecen una revisión, y a menudo la respuesta hace que la ingeniería sea innecesaria.
Donde no sea así, al menos estarás automatizando frente a una línea base medida en lugar de una publicada, lo cual marca la diferencia entre un control que funciona con tus datos y uno que funciona con el punto de referencia de otra persona.
Qué medir antes de construir nada
Tres números convierten una intención vaga en una especificación, y los tres provienen de ejecutar lotes manualmente durante quince días.
La distribución de tu propio material: dónde aterrizan realmente las imágenes genuinas de tus fuentes habituales. Casi todos los equipos se llevan una sorpresa, por lo general porque sus entradas están más procesadas de lo que creían.
Tu propia tasa de falsos positivos: con qué frecuencia una alerta resulta ser un procesamiento ordinario cuando alguien investiga. Este es el número que decide si un control se puede utilizar con personas reales, y nunca es el número que figura en la página de un proveedor.
El volumen que realmente se marcaría: a cuántos elementos por semana tendría que echar un vistazo un humano. Si ese número es pequeño, la automatización que planeabas es una hoja de cálculo y un hábito.