VLMs con LoRA para detección de fraude en tiempo real

Los VLMs (Vision-Language Models) son modelos de inteligencia artificial que procesan simultáneamente imágenes y texto para análisis visual y lingüístico.

Cuando se combinan con LoRA (Low-Rank Adaptation), permiten detectar fraudes en documentos con alta precisión en pipelines de baja latencia, sin necesidad de reentrenar completamente el modelo base.

Qué es LoRA y cómo funciona para VLMs

LoRA (Low-Rank Adaptation) es una técnica de fine-tuning que inserta matrices de adaptación de bajo rango en capas específicas de un modelo pre-entrenado. En lugar de actualizar todos los parámetros del modelo — lo que puede requerir miles de millones de operaciones — LoRA ajusta solo el 0.1% al 1% de los parámetros totales, concentrando la adaptación en los componentes más críticos para el dominio objetivo.

Para VLMs como Qwen-VL, el proceso ocurre en tres pasos:

1. Selección de módulos objetivo — identificar las capas de atención relevantes para el análisis visual de documentos
2. Descomposición de bajo rango — agregar pequeñas matrices de adaptación sin modificar los pesos originales
3. Entrenamiento específico del dominio — ajustar solo los adaptadores con datos de fraude

from peft import get_peft_model, LoraConfig

lora_config = LoraConfig(
    target_modules=["c_attn", "attn.c_proj", "visual_attn"],
    r=8,
    lora_alpha=16,
    lora_dropout=0.05,
    bias="none"
)

financial_fraud_vlm = get_peft_model(qwen_vl_model, lora_config)

Cómo la arquitectura distribuida amplifica los VLMs

Los modelos VLM con fine-tuning LoRA requieren una capa de ejecución que entregue inferencia en tiempo real. Las arquitecturas centralizadas introducen latencia de red por round-trip que hace inviable la detección durante una transacción. La ejecución en arquitectura distribuida elimina ese round-trip al procesar la inferencia en puntos de presencia globales, cerca del origen de la solicitud.

Comparación: enfoques de detección de fraude

Pipeline de detección de fraude

El workflow adapta la profundidad del análisis según el nivel de sospecha identificado en el triaje inicial:

Etapa 1 — Triaje inicial

• Modelo ligero evalúa señales básicas de fraude
• Resultado: puntuación de sospecha (0–1)

Etapa 2 — Análisis profundo (condicional)

• Se activa cuando la puntuación > 0.3
• El VLM analiza anomalías visuales específicas del documento
• Búsqueda vectorial de patrones similares en casos anteriores confirmados

Etapa 3 — Verificación contextual

• Historial de cuenta y patrones de comportamiento
• Escalada de autenticación basada en riesgo

Esta estructura aplica análisis intensivo solo donde es necesario, manteniendo el procesamiento rápido para documentos que no presentan señales de fraude.

Implementación con Azion AI Inference

startTime se declara antes del bloque try para garantizar su disponibilidad durante toda la ejecución:

import { VectorRetriever } from './vectorRetriever'
import { FRAUD_DETECTION_PROMPT } from './config'

export async function handleRequest(request) {
  const startTime = Date.now()

  try {
    const formData = await request.formData()
    const documentFile = formData.get('document')
    const documentUrl = formData.get('documentUrl')

    const imageUrl = documentUrl || (await uploadToStorage(documentFile))

    const modelResponse = await Azion.AI.run('qwen-qwen25-vl-7b-instruct-awq', {
      stream: false,
      messages: [
        {
          role: 'system',
          content: FRAUD_DETECTION_PROMPT
        },
        {
          role: 'user',
          content: [
            {
              type: 'text',
              text: 'Analiza este documento para identificar posibles señales de fraude. Devuelve un JSON con fraudProbability (0-1), detectedAnomalies (array) y confidence (0-1).'
            },
            {
              type: 'image_url',
              image_url: { url: imageUrl }
            }
          ]
        }
      ]
    })

    const analysisResult = JSON.parse(modelResponse.choices[0].message.content)

    let similarCases = []
    if (analysisResult.fraudProbability > 0.3) {
      const retriever = new VectorRetriever({
        dbName: process.env.VECTOR_STORE_DB_NAME || 'fraud_patterns',
        threshold: 0.8
      })
      similarCases = await retriever.search({
        query: analysisResult.detectedAnomalies.join(' '),
        limit: 5
      })
    }

    return new Response(
      JSON.stringify({
        fraudProbability: analysisResult.fraudProbability,
        anomalies: analysisResult.detectedAnomalies,
        confidence: analysisResult.confidence,
        similarCases,
        processingTimeMs: Date.now() - startTime
      }),
      { headers: { 'Content-Type': 'application/json' }, status: 200 }
    )
  } catch (error) {
    return new Response(
      JSON.stringify({ error: 'Error al procesar el documento', details: error.message }),
      { headers: { 'Content-Type': 'application/json' }, status: 500 }
    )
  }
}

async function uploadToStorage(file) {
  return `https://storage.example.com/temp/${Date.now()}_${file.name}`
}

Cuándo usar VLMs con LoRA para detección de fraude

Usa este enfoque cuando necesites:

• Detección durante la transacción, no después de su conclusión
• Análisis de imágenes de documentos: cheques, facturas, identificaciones, contratos
• Adaptación rápida a nuevos patrones de fraude sin reentrenar el modelo completo
• Procesamiento que no puede enviar datos sensibles a data centers externos
• Decisiones de baja latencia en pipelines de aprobación de crédito o onboarding

No uses este enfoque cuando:

• El análisis sea puramente textual, sin componente visual
• El volumen de transacciones sea lo suficientemente bajo para análisis retrospectivo por lotes
• La infraestructura distribuida no esté disponible en el entorno

Métricas y benchmarks

• Reducción de parámetros en fine-tuning: 99–99.9% menos parámetros ajustados con LoRA vs. fine-tuning completo (Hu et al., ICLR 2022)
• Umbral de sospecha recomendado: 0.3 como punto de partida; calibrar según la tasa de falsos positivos observada en producción
• Similitud vectorial para patrones conocidos: umbral de 0.8 para correspondencia con casos anteriores confirmados
• Latencia de red: eliminada la necesidad de round-trip al data center central al procesar en los puntos de presencia globales de Azion Web Platform

Errores comunes y cómo corregirlos

Error: Usar el modelo genérico sin fine-tuning para tipos específicos de documentos
Corrección: Aplicar LoRA con datos etiquetados del tipo de documento objetivo (cheques, facturas, identificaciones)

Error: Definir el umbral de sospecha demasiado bajo (< 0.1), generando exceso de análisis profundos innecesarios
Corrección: Calibrar el umbral según la tasa de falsos positivos aceptable; 0.3 es un punto de partida, no un valor universal

Error: No alimentar el vector store con casos de fraude confirmados
Corrección: Poblar la base de datos fraud_patterns con vectores de anomalías de fraudes confirmados para habilitar la búsqueda por similitud

Error: Ejecutar todo el análisis en una sola etapa, independientemente del nivel de sospecha Corrección: Implementar un pipeline adaptativo con triaje ligero antes de activar el VLM completo

Error: Declarar startTime dentro del bloque try, haciéndolo inaccesible para el cálculo de processingTimeMs
Corrección: Declarar startTime antes de try, como se muestra en el ejemplo de código anterior

Casos de uso por sector

Servicios financieros

• Validación de cheques y recibos de pago al momento de compensación
• Análisis de documentos de comprobación de ingresos en aprobación de crédito
• Detección de facturas alteradas en procesos de reembolso

Onboarding digital

• Verificación de documentos de identidad (INE, pasaporte, licencia de conducir)
• Detección de documentos generados por IA o editados digitalmente
• Validación de selfie con documento en flujos KYC

Seguros

• Análisis de fotos de siniestros para detectar alteraciones
• Verificación de facturas en reembolsos

E-commerce y marketplace

• Validación de comprobantes de pago
• Detección de facturas falsas en disputas de contracargo

Cómo implementar en Azion

1. Selecciona el modelo: Usa qwen-qwen25-vl-7b-instruct-awq en AI Inference de Azion Web Platform
2. Configura el vector store: Crea la base de datos fraud_patterns con vectores de patrones de fraude confirmados
3. Implementa la edge function: Usa el ejemplo de código anterior como base
4. Define el system prompt: Configura FRAUD_DETECTION_PROMPT con instrucciones específicas para el tipo de documento
5. Calibra los thresholds: Ajusta fraudProbability > 0.3 y threshold: 0.8 con datos reales de producción
6. Configura la observabilidad: Agrega logging de processingTimeMs y scores para monitoreo continuo

Consulta la documentación de Azion AI Inference para detalles de configuración.

Preguntas frecuentes

¿Qué es un VLM (Vision-Language Model)? Un VLM es un modelo de inteligencia artificial que procesa simultáneamente entradas visuales (imágenes) y textuales. Modelos como Qwen-VL pueden analizar el contenido visual de un documento y responder preguntas sobre él en lenguaje natural.

¿Qué es LoRA (Low-Rank Adaptation)? LoRA es una técnica de fine-tuning que agrega matrices de adaptación de bajo rango a capas específicas de un modelo pre-entrenado. Permite especializar el modelo para un dominio ajustando solo el 0.1% al 1% de los parámetros totales, reduciendo drásticamente el costo computacional de adaptación.

¿Cuál es la diferencia entre fine-tuning completo y LoRA? El fine-tuning completo actualiza todos los parámetros del modelo, requiriendo grandes volúmenes de datos y poder computacional. LoRA inserta adaptadores ligeros en capas seleccionadas, manteniendo los pesos originales congelados. Los resultados en tareas específicas del dominio son comparables con una fracción del costo.

¿Por qué procesar la detección de fraude en arquitectura distribuida en lugar de centralizada? Las arquitecturas centralizadas introducen latencia de red por round-trip que puede hacer inviable la detección durante una transacción. Procesar en puntos de presencia globales — cerca del origen de la solicitud — elimina ese round-trip y permite decisiones en tiempo real.

¿Puede Qwen-VL analizar cualquier tipo de documento? El Qwen-VL base tiene capacidad general de análisis visual. Para tipos específicos de documento (cheques bancarios, identificaciones, facturas), la precisión mejora significativamente con fine-tuning vía LoRA usando datos representativos de ese tipo de documento.

¿Cómo funciona la búsqueda vectorial de patrones de fraude? Los documentos con puntuación de sospecha superior a 0.3 tienen sus anomalías detectadas convertidas en vectores y comparadas contra la base de patrones conocidos. Una similitud superior a 0.8 indica correspondencia con fraudes anteriores confirmados.

¿Cuánto tiempo tarda en adaptar un VLM con LoRA a un nuevo tipo de fraude? El entrenamiento de adaptadores LoRA tarda horas, no días, dependiendo del volumen de datos y el hardware disponible. Esto permite responder a nuevos patrones de fraude sin esperar el reentrenamiento completo del modelo.

¿Es posible usar este enfoque sin GPU? Los modelos cuantizados como Qwen-VL AWQ reducen los requisitos de hardware. La inferencia puede ejecutarse en hardware menos especializado, aunque la GPU acelera significativamente el throughput en volúmenes altos.

¿Cómo calibrar el umbral de fraudProbability? Empieza con 0.3 y ajusta según la tasa de falsos positivos observada en producción. Umbrales demasiado bajos aumentan el volumen de revisiones manuales; demasiado altos permiten que el fraude pase sin análisis profundo. El umbral adecuado depende del costo relativo entre falso positivo y falso negativo para el negocio.

¿Qué ocurre si el modelo devuelve un JSON malformado? El bloque try/catch captura errores de parsing y devuelve HTTP 500 con el mensaje de error. En producción, implementa un fallback para revisión manual y logging de la respuesta sin procesar del modelo para depuración.

¿Cómo garantizar la privacidad de documentos sensibles en este pipeline? El procesamiento en puntos de presencia globales mantiene los datos cerca de su origen, reduciendo el tráfico de documentos sensibles hacia data centers centrales. Para requisitos más estrictos, combina con políticas de retención cero y procesamiento efímero.

Recursos relacionados

• Documentación de Azion AI Inference

• Caso de estudio: Axur y detección de amenazas con Azion