Prueba de aceptación de visión local para LFM2.5-VL-3B: cómo calificar VLMs en el dispositivo para pantallas, documentos y flujos de trabajo privados

La prueba de aceptación de visión local de Liquid AI para LFM2.5-VL-3B debe juzgarse como un ejercicio de calificación de ruta, no como un titular de ficha de modelo. La pregunta práctica es más precisa: ¿puede un modelo pequeño local de visión y lenguaje gestionar una tarea privada de pantalla, documento o anclaje con calidad suficiente para que el producto acepte el resultado sin enviar la imagen a un VLM en la nube?

Esa pregunta es fácil de formular y difícil de demostrar. Una captura de demostración pulida solo muestra que el modelo puede leer cierto contenido visual. Una ruta de producción tiene que resistir un dispositivo más caliente, memoria ajustada, deriva del estado de pantalla entre la captura y la acción, escaneos torcidos, tablas densas y reglas de privacidad que prohíben la carga.

Este artículo usa como material fuente la publicación de lanzamiento de Liquid AI, la ficha del modelo en Hugging Face, la documentación de Liquid, notas de capacidad de visión, guía de evaluación de hardware, documentación de despliegue ONNX, artefactos ONNX y artefactos GGUF. Trata las cifras de benchmark, velocidad y capacidad de esas páginas como medidas del proveedor o específicas de la fuente hasta que tu equipo las reproduzca en sus propios dispositivos. El objetivo no es demostrar que la visión local supera a la visión en la nube en todas partes. El objetivo es decidir dónde se acepta lo local, dónde la nube sigue siendo necesaria y dónde el respaldo híbrido es el modelo operativo más honesto.

Para patrones de aceptación relacionados, consulta el trabajo de Optijara sobre reproducibilidad de la visibilidad del feed, pruebas de rutas de captura seleccionadas por IA, pruebas de límites de memoria del contexto de trabajo y pruebas de aceptación de rutas de inferencia.

Por qué LFM2.5-VL-3B necesita una prueba de aceptación, no un resumen de lanzamiento

Un VLM local no debe adoptarse porque sea nuevo, compacto o prometedor en benchmarks. Gana un lugar solo cuando una ruta definida supera la aceptación. Una ruta podría extraer campos de encabezado de facturas desde una foto de teléfono sin conexión. Otra podría identificar el botón activo en una pantalla de aplicación controlada. Otra podría resumir una captura redactada sin mover la imagen fuera del dispositivo. Cada ruta necesita su propio umbral de precisión, latencia, privacidad y respaldo.

Las fuentes de Liquid AI establecen lo que el editor pone a disposición: la página del modelo LFM2.5-VL-3B, artefactos públicos del modelo, documentación de tiempo de ejecución y guía de despliegue. No demuestran que tu flujo de cámara, elección de cuantización, runtime móvil, presupuesto de memoria o diseño de interfaz se comporten bajo uso sostenido. Esa prueba faltante es la prueba de aceptación.

Los flujos de pantalla y documento son menos indulgentes que un chat abierto. Una coordenada incorrecta puede hacer clic en el control equivocado. Un campo omitido puede corromper un formulario. Una fila de tabla alucinada puede entrar en un registro de negocio. Un respaldo en la nube que se activa en silencio puede debilitar la expectativa de privacidad que los usuarios creían tener. La visión local gana confianza solo cuando esos fallos se miden directamente.

Qué verificar antes de probar: artefactos, licencia, runtime y ajuste al dispositivo

Empieza fijando los pesos del modelo, la configuración del procesador, el tokenizador, los ejemplos de runtime y cualquier variante cuantizada. Usa revisiones inmutables cuando sea posible. Registra el nombre del artefacto, la URL de origen, el commit o la revisión, los hashes de archivo, el script de conversión y el código de preprocesamiento. Un resultado de prueba vinculado solo a la frase LFM2.5-VL-3B es demasiado laxo para la aceptación en producción.

La disponibilidad de pesos no es permiso para todos los usos de producto. Revisa la ficha del modelo y el texto de licencia antes de redistribuir, integrar comercialmente, enviar dispositivos, ajustar el modelo o prestar un servicio API. Mantén la revisión legal en el mismo paquete de aceptación que los resultados de precisión y runtime. Separar la revisión legal de la técnica es una forma habitual de perder el hilo.

La elección del runtime también importa. Una ruta Hugging Face de precisión completa puede no comportarse como una ruta ONNX móvil. Una compilación cuantizada GGUF puede cambiar la presión de memoria, la latencia, la estabilidad de salida o el manejo de imágenes. Prueba cada ruta por separado. No permitas que un buen resultado en un runtime avale por asociación un runtime distinto.

Construye una matriz de dispositivos antes de reportar la primera puntuación. Incluye versión del sistema operativo, CPU, disponibilidad de GPU o NPU, RAM, almacenamiento, perfil térmico, estado de batería, estado de red y runtime. Añade al menos un dispositivo de gama baja que se parezca a la base real de usuarios. Si una ruta solo pasa en un dispositivo de laboratorio conectado a la corriente que empezó frío, no ha superado la ruta de producto.

El marco LVAT de Optijara: Prueba de Aceptación de Visión Local

LVAT es un marco de aceptación de cuatro partes para decidir cuándo LFM2.5-VL-3B puede gestionar localmente una tarea visual. El marco es específico de la tarea por diseño. Una ruta puede pasar para triaje de documentos y fallar para automatización precisa de interfaz, y eso no es una contradicción. Es el objetivo de la prueba.

Prueba del límite local y la privacidad. Desactiva la red y ejecuta la ruta. Inspecciona registros, informes de fallos, analítica, buffers de telemetría, cargas de respaldo y comprobaciones de actualización. Confirma que prompts, imágenes, salidas OCR y coordenadas permanecen dentro del límite previsto salvo que se active y comunique una política explícita de respaldo.

Fidelidad visual en pantallas y documentos. Incluye fuentes pequeñas, posiciones de desplazamiento, ventanas emergentes, modales, bajo contraste, desenfoque, compresión, capturas rotadas, tablas densas, formularios, escaneos y páginas multilingües. Puntúa campos exactos, estructura de tabla normalizada, preservación de diseño y omisiones de texto. Registra qué se degrada cuando las imágenes se redimensionan, teselan o recortan.

Accionabilidad mediante anclaje y esquemas de herramientas. Prueba las salidas de coordenadas frente a ventanas de tolerancia, solapamiento de regiones y seguridad de objetivos de clic. Para llamadas a herramientas, valida cada salida contra esquemas JSON estrictos. Cuenta esquemas inválidos, intentos de acción inseguros, referencias de objetivo incorrectas y casos en los que el modelo debería abstenerse.

Tolerancia bajo estrés del dispositivo, entradas malformadas y respaldo. Ejecuta la ruta bajo presión de memoria, bucles sostenidos, dispositivos calientes y batería baja. Añade imágenes rotas, capturas parciales, capturas interrumpidas y estados de pantalla cambiantes. El respaldo debe ser visible, razonado y auditable. Si el usuario no puede saber cuándo se usó la nube, el producto está ocultando una decisión arquitectónica.

Matriz de decisión de rutas LVAT: local, nube o híbrida

La opción local debe ser la predeterminada cuando la tarea es sensible para la privacidad, el tamaño de imagen es manejable, el dispositivo supera pruebas sostenidas de latencia y memoria, la precisión de anclaje queda dentro de la tolerancia y la ruta funciona sin conexión. Los ejemplos incluyen triaje estrecho de documentos, resumen local de capturas de pantalla o detección de regiones de interfaz controladas tras superar un conjunto de pruebas dorado.

La nube sigue siendo más segura cuando la tarea necesita razonamiento más amplio, contexto mayor, comprensión multilingüe más compleja, umbrales de precisión que lo local no alcanza, lotes pesados de documentos o políticas de auditoría que exigen controles centralizados del modelo. La privacidad local tiene valor real. No compensa la falta de capacidad cuando la capacidad es la restricción vinculante.

El enrutamiento híbrido suele ser la mejor ruta de primer lanzamiento. Ejecuta lo local primero para clases de entrada aceptadas. Escala cuando la confianza sea baja, la entrada esté malformada, el dispositivo esté caliente, la presión de memoria sea alta, el idioma o tipo de documento esté fuera del conjunto aceptado o el usuario haya optado por el respaldo en la nube.

Mide el coste por tarea aceptada, no el precio bruto por token ni la velocidad de demostración. Incluye uso de recursos del dispositivo, manejo de fallos, volumen de respaldo, monitorización, mantenimiento, pruebas de regresión y riesgo de actualización. La ruta más barata en una diapositiva puede volverse cara cuando la lógica de reintento y los tickets de soporte entran en el cálculo.

Lista de implementación para pantallas, documentos y anclaje de objetos

Define temporización de captura de pantalla, orientación, reglas de recorte, límites de redimensionado, estrategia de teselado y redacción antes de medir el modelo. Incluye pruebas de deriva del estado de pantalla donde el objetivo se mueve después de la captura. Prueba superposiciones, estados de teclado, ventanas emergentes y posiciones de desplazamiento. Suenan a detalles de producto, pero a menudo explican más fallos que el propio modelo.

Construye un conjunto representativo de formularios, facturas, tablas, escaneos, imágenes de bajo contraste y páginas multilingües. Usa muestras sensibles redactadas cuando sea posible. Puntúa exactitud de campos, comportamiento ante campos ausentes, alineación de filas y columnas, normalización de tablas y rechazo cuando la imagen sea ilegible.

Evalúa coordenadas con ventanas de tolerancia y solapamiento de regiones, no con corrección narrativa. Un modelo que dice botón superior derecho no equivale a un modelo que devuelve una región segura para hacer clic. Añade pruebas negativas donde el objeto esté ausente o solo parcialmente visible.

Cada salida de herramienta debe validarse contra un esquema antes de usarse. Exige campos tipados, valores de coordenadas acotados, campos de confianza o abstención, motivo de ruta y banderas de acción segura. Rechaza JSON malformado en vez de repararlo silenciosamente en producción. Reparar una mala estructura puede convertir un error del modelo en un error de aplicación.

Versiona prompts, umbrales, código de preprocesamiento, artefactos del modelo y conjuntos de pruebas dorados. Ejecuta pruebas de regresión antes de cambiar cuantización, runtime, revisión del modelo o preprocesamiento de cámara. Define criterios de reversión antes del despliegue, mientras nadie discute bajo presión de incidente.

{
  "framework": "Optijara LVAT",
  "accepted_route": "local only after task-level pass",
  "rejected_route": "local when grounding, schema, privacy or sustained-device tests fail",
  "fallback_triggers": ["low confidence", "malformed image", "thermal pressure", "unsupported language", "schema failure"],
  "required_evidence": ["pinned artifacts", "device matrix", "golden tests", "privacy audit", "rollback plan"]
}

Plan de medición: de la velocidad de demostración a la fiabilidad sostenida del dispositivo

Mide arranque en frío, latencia en caliente y latencia sostenida por categoría de tarea. No copies un umbral universal desde una página de modelo. Una acción rápida de asistente personal, un lote de documentos y un lector de pantalla de accesibilidad tienen tolerancias distintas. Reporta p50 y p95 para cada ruta y dispositivo.

Ejecuta bucles lo bastante largos para exponer limitación térmica, fallos, crecimiento de memoria e impacto en batería. Rastrea si la ruta se abstiene o escala cuando el dispositivo cruza un umbral de recursos. La fiabilidad sostenida importa más que una demostración atractiva.

Usa coincidencia exacta de campos, precisión de tablas normalizadas, consistencia de regiones de diseño, tasa de acierto de anclaje, evitación de clics inseguros, tasa de esquema válido, precisión de abstención y calidad del respaldo. La métrica correcta es la vinculada al valor de usuario aceptado. Para una ruta de facturas, puede ser precisión de campos y calidad de rechazo. Para una acción de interfaz, la evitación de clics inseguros puede importar más que una descripción fluida.

Prueba la operación sin conexión con la red desactivada. Inspecciona registros de runtime, analítica de aplicación, informes de fallos y colas de respaldo. La inferencia local no significa automáticamente privacidad si las imágenes sensibles aparecen en telemetría o cargas de escalado a la nube.

Errores comunes que cometen los equipos al calificar VLMs locales

Los benchmarks son señales útiles, no prueba de despliegue. Un modelo puede puntuar bien en un benchmark y aun así fallar una acción estrecha de pantalla porque el recorte, la resolución, el idioma de la interfaz o el esquema de coordenadas difieren de la tarea del benchmark.

Las imágenes limpias ocultan riesgo de producción. Añade desenfoque, compresión, reflejos, capturas parciales, modales, desplazamiento, texto diminuto y documentos malformados. La aceptación debe reflejar las entradas desordenadas que los usuarios realmente crean.

No asumas que las rutas ONNX, GGUF, cuantizadas y de precisión completa son intercambiables. Trata cada combinación de modelo, runtime y dispositivo como una ruta candidata separada. Esa regla parece tediosa hasta que una actualización cambia la estabilidad de salida en una clase de dispositivo y nadie puede reproducir el resultado anterior.

El respaldo es útil cuando es visible y controlado. Es peligroso cuando oculta que la ruta local falla demasiado a menudo. Rastrea motivo de respaldo, clase de entrada, estado de recursos y resultado final. Una tasa alta de respaldo no es una historia de éxito de visión local.

La inferencia en el dispositivo aún puede filtrar datos mediante registros, volcados de fallo, analítica, monitorización, sistemas de actualización o respaldo en la nube. La aceptación de privacidad exige inspección, no supuestos.

Salvedades, limitaciones y recomendaciones para operadores

LVAT no puede demostrar el comportamiento futuro del modelo, cada variante de dispositivo, cada tipo de documento, cada idioma o cada estado de interfaz. Es un proceso de aceptación para rutas conocidas. Vuelve a ejecutarlo cuando cambien artefactos, runtimes, prompts, preprocesamiento, dispositivos o políticas de respaldo.

Las rutas locales traen tamaño de empaquetado, gestión de actualizaciones, impacto en batería, comportamiento térmico, variación de aceleradores y complejidad de soporte. Las rutas en la nube traen dependencia de red, revisión de privacidad, variación de proveedor y costes recurrentes de inferencia. Las rutas híbridas traen requisitos de política de enrutamiento, aviso y observabilidad. Ninguna es universalmente mejor.

Un sprint LVAT práctico empieza con revisión de artefactos y licencia, luego construye una matriz de dispositivo y runtime, conjunto de pruebas dorado, canalización de preprocesamiento, ejecutor de puntuación, auditoría de privacidad y política de respaldo. La salida es una decisión de ruta: local aceptada, nube requerida o híbrida con disparadores explícitos. Si un equipo evalúa LFM2.5-VL-3B para flujos de trabajo visuales privados, este es el nivel de calificación que mantiene la decisión anclada.

La regla es simple: acepta la visión local solo donde la evidencia la respalde. Fija los artefactos, prueba la ruta, mide el comportamiento sostenido del dispositivo, audita el límite de privacidad y mantén el respaldo honesto.