Ganancias:
- Determina para qué cargas de trabajo el procesamiento por lotes es adecuado
- Entiende la relación costo/latencia entre el procesamiento sincrónico, asíncrono y por lotes.
- Diseña un flujo de trabajo por lotes sólido que hace coincidir custom_id con los resultados.
La mayoría de las integraciones de LLM se centran en escenarios "en vivo" en los que un usuario espera una respuesta frente a una pantalla. Pero la mayoría de las cargas de trabajo profesionales no están realmente activas: etiquetar miles de documentos de la noche a la mañana, resumir un conjunto de datos completo, clasificar grabaciones de llamadas completas en el archivo. En estos asuntos nadie espera una respuesta instantánea; Lo importante es realizar el trabajo de forma económica y fiable. El lote es exactamente para estas cargas de trabajo. En esta unidad, aprenderá la diferencia entre el procesamiento sincrónico, asincrónico y por lotes, cuando el lote es la opción correcta, y un flujo sólido que coincide con confianza con el custom_id y los resultados.
Tres modos de trabajo
modo
¿Cómo funciona?
retraso
Costo típico
trabajo adecuado
sincrónico
Haces una solicitud y esperas la respuesta.
segundos
Estándar
Chat en vivo, asistente instantáneo
asincrónico
Pones el trabajo en cola y recibes una notificación cuando finaliza.
Segundos-minutos
Estándar
Tareas en segundo plano, pasos de automatización.
lote
Envía miles de solicitudes en un paquete y luego obtiene los resultados
Minutos-horas
Generalmente con descuento
Trabajos de gran volumen y tolerantes a retrasos
El procesamiento por lotes es el siguiente: envía cientos o miles de solicitudes como un único "trabajo" al proveedor; El proveedor los procesa a su propio ritmo y devuelve todos los resultados de forma masiva una vez completados. A cambio, obtienes dos cosas: (1) un costo unitario generalmente más bajo, (2) la capacidad de mover un gran volumen sin tener que lidiar con límites de velocidad. El precio es que los resultados no llegan instantáneamente, sino después de un tiempo.
¿Cuándo realizar lotes y cuándo no?
La decisión se reduce a una pregunta: ¿el usuario está esperando el resultado ahora?
- No, puedo retenerlo → candidato por lotes. Etiquetado nocturno, resumen de lotes, clasificación de archivos, enriquecimiento de datos, ejecución de evaluación (evaluación).
- Sí, esperando en la pantalla → sincronizar. Chat en vivo, asesoramiento instantáneo, ayuda al completar formularios.
Consejo: Pueden coexistir dos modos en un mismo producto. El usuario trabaja sincrónicamente en el chat en vivo; Por la noche, entregas todas las conversaciones de ese día al lote para análisis de calidad. Separar la "necesidad viva" de la "necesidad colectiva" es la primera decisión de la arquitectura.
Anatomía de un flujo por lotes robusto
La regla técnica más importante del procesamiento por lotes es la comparación de resultados.
- Asigne a cada solicitud un "custom_id" único. Este es su ID generado que identifica la solicitud (por ejemplo, factura-2026-07-18-000431).
- Envíe el trabajo. Todas las solicitudes van en un solo paquete; cada uno con su propio custom_id.
- Encuesta la situación. Solicita el estado a intervalos hasta que el trabajo esté "terminado".
- Haga coincidir los resultados con `custom_id`. Los resultados pueden devolverse en un orden diferente al orden de envío; así que nunca haga coincidir por posición sino por el custom_id que lleva cada resultado.
- Consulta el tipo de cada resultado. Una solicitud puede tener éxito, otra puede fallar y otra puede caducar. Proceso basado en éxito/fracaso.
{ "solicitudes": [ { "custom_id": "invoice-000431", "params": { "model": "claude-haiku-4-5", "max_tokens": 128, "system": "Clasificar factura. Devolver solo JSON.", "messages": [{ "role": "user", "content": "{{invoice_text}}" }] } }, { "custom_id": "invoice-000432", "params": { "model": "claude-haiku-4-5", "max_tokens": 128, "system": "Clasificar factura. Devolver solo JSON.", "messages": [{ "role": "user", "content": "{{invoice_text_2}}" }] } } ]}
Precaución: Hacer coincidir resultados según el orden de envío es el error número uno en el procesamiento por lotes. La cola no se conserva. Sin custom_id no se puede saber con seguridad qué resultado pertenece a qué documento: las coincidencias incorrectas conducen silenciosamente a datos incorrectos.
Plantillas copiables
# Regla de generación de custom_id (única y rastreable) Formato: <isture>-<fecha>-<secuencia>. Ejemplo: request-20260718-000431Regla: nunca repetir en el trabajo; Incruste el ID del registro de recursos en él.
# Tarjeta de trabajo por lotes (plantilla de programación) Nombre del trabajo: .............Número de registros: .............Modelo: ............. (trabajo simple → modelo rápido)Max_tokens por solicitud: .................Tolerancia del tiempo de entrega esperado: ......... horas Clave de coincidencia de resultados: custom_idEn caso de error: reintento/cola/informe
# Solicitud única por lotes (breve y esquemática) Clasifique este documento. Simplemente devuelva este JSON, comentando:{"category":"...","urgency":"low|medium|high"}Documento: """{{document}}"""
# Pseudocódigo de procesamiento de resultados para cada resultado: if result.status == "success": record = find(custom_id) save(record, result.output) en caso contrario: add_to_fail(custom_id, result.error) # luego inténtalo de nuevo
Aviso débil / Aviso fuerte (diseño de trabajo por lotes)
# DÉBIL (diseño frágil) Envíe 10,000 documentos en orden con el modelo fuerte, guarde los resultados devueltos en el orden en que llegan.
# FUERTE (diseño duradero) Envíe 10,000 documentos en un lote con un modelo rápido. Asigne a cada documento un custom_id único que contenga el ID del registro de origen. Haga coincidir los resultados con custom_id; ponga en cola los que fallaron e inténtelo nuevamente. Ejecute en la ventana nocturna; Tolerancia de entrega 6 horas.
Versión potente; Predefine la selección del modelo, la clave coincidente, el manejo de errores y el tiempo. Ésta es la diferencia a la hora de procesar de forma segura decenas de miles de registros.
Tres mini estuches
Caso 1: etiquetado nocturno. Un equipo de comercio electrónico clasificaría 200.000 reseñas de productos en etiquetas de opinión. La transmisión en vivo sincrónica estaba sujeta a límites de velocidad y era costosa. Llevaron el trabajo hasta la noche como un lote con un modelo rápido; El coste unitario bajó, todo el decorado estuvo listo por la mañana y no hubo problemas de límites de velocidad.
Caso 2: Confusión de pedidos. Un equipo de investigación resumió 5.000 artículos, pero escribió los resultados en archivos en el orden en que llegaron. Debido a que los resultados se obtuvieron en un orden diferente, aproximadamente 900 de los 5.000 resúmenes estaban vinculados al artículo incorrecto. Lo reasignaron a custom_id; El problema se resolvió y esta experiencia se convirtió en una regla permanente: "Siempre custom_id en lote".
Caso 3: Modo de espera en vivo en modo incorrecto. Un equipo de soporte intentó brindar por lotes las respuestas en vivo que el usuario esperaba en la pantalla; Los usuarios abandonaron porque los resultados llegaron minutos después. Regresaron el trabajo en vivo a la sincronización, dejando solo el análisis de calidad nocturno en el lote. Lección: el lote no es para espera en vivo.
Errores comunes
- Coincidencia de resultados por posición: No se conserva el orden; Utilice id_personalizado.
- Transferencia de trabajo en vivo a lote: el usuario no puede esperar minutos; El lote es para trabajos tolerantes a retrasos.
- No manejar casos de error: algunas solicitudes pueden regresar fallidas o caducadas; Ponlo en una cola separada y vuelve a intentarlo.
- Fuerte reflejo de uso del modelo en lotes: modelo rápido + lote es la combinación más barata en trabajos simples.
- No hacer que custom_id sea rastreable: si no hay ningún registro de origen incrustado en el ID, resulta difícil vincular el resultado.
- Olvidarse de examinar la situación: Esperar resultados antes de terminar el trabajo; Verifique el estado de finalización.
Más profundo: monitoreo de lotes y gestión de fallas parciales
El aspecto más maduro del procesamiento por lotes es que requiere una mentalidad diferente a la de las llamadas individuales: un trabajo por lotes es un "proceso", no un "evento". Suponer que decenas de miles de solicitudes tendrán éxito es frágil; El diseño realista acepta el fracaso parcial desde el principio. El estado de cada resultado puede ser diferente: exitoso, fallido (por ejemplo, entrada no válida), cancelado o caducado. Un flujo sólido procesa el estado de cada resultado por separado a medida que lo recorre, coloca los errores en una "cola de reintento" separada y ejecuta esa cola por separado.
La segunda práctica es diseñar para la idempotencia (que ejecutar el mismo trabajo dos veces no causa ningún daño). Si se interrumpe un lote y lo reinicia, no debe reprocesar y escribir dos veces los registros ya procesados. Vincular el custom_id a su registro de origen también funciona aquí: "¿este registro ya ha sido procesado?" antes de guardar el resultado. La verificación evita la escritura doble.
El tercer punto es escalonar las transmisiones en vivo por lotes. Algunos trabajos tienen dimensiones tanto en vivo como por lotes: cuando el usuario carga un documento, se le proporciona un resumen preliminar rápido (sincrónico) y se reprocesa el mismo documento para un análisis más profundo por la noche (por lotes). Separar conscientemente los dos modos optimiza tanto la experiencia del usuario como el costo.
Finalmente, el procesamiento por lotes también es una forma de abordar los límites de velocidad (unidad 8). Enviar un gran volumen en un flujo sincrónico en vivo produce 429 constante, mientras que enviar el mismo volumen a transferencias por lotes limita la presión sobre la programación del propio proveedor y hace que el trabajo sea más predecible.
En resumen
El procesamiento por lotes es generalmente un modo más económico y robusto para cargas de trabajo de gran volumen y tolerantes a la latencia. Su decisión fue "¿el usuario está esperando el resultado ahora?" determina la pregunta. La regla técnica más importante es dar a cada solicitud un custom_id único, hacer coincidir los resultados por ID en lugar de por ubicación y tratar el éxito o el fracaso de cada resultado por separado.
Tarea de aplicación
Elija un trabajo de gran volumen (por ejemplo, clasificación de archivos). (1) Decidir si este trabajo es en vivo o colectivo y justificarlo. (2) Diseñe un formato custom_id (incluya el registro de recursos). (3) Complete la tarjeta de trabajo por lotes (modelo, max_tokens, tolerancia, política de errores). (4) Escriba el pseudocódigo de procesamiento de resultados para incluir solicitudes fallidas.
lista de verificación
- [] Puedo distinguir los modos sincrónico, asincrónico y por lotes en el eje costo/retraso.
- [ ] Puedo decidir si un trabajo es adecuado para lotes o no haciendo la pregunta correcta.
- [] Le doy a cada solicitud un custom_id único y hago coincidir los resultados por ID.
- [] Puedo manejar los resultados fallidos/caducados por separado.
- [] Conozco los beneficios de elegir un modelo rápido en trabajos por lotes simples.