Producción de extremo a extremo: verificación, seguimiento y ética

Ganancias:

Puede diseñar la arquitectura de un extremo a otro que lleva una función de LLM desde la idea hasta la producción.
Establece capas de cumplimiento de verificación, aprobación humana y seguimiento (registro/métricas)
Los límites traducen los principios de ética y privacidad en decisiones de producción

En las diez unidades anteriores, aprendimos las partes una por una: estructura de solicitudes, economía de tokens, flujo, aviso del sistema, selección de modelo, caché, lotes, gestión de errores, clave segura y automatización. En esta última unidad, combinamos las partes y establecemos la arquitectura holística que lleva una característica LLM desde la idea hasta la producción. La producción es diferente de una “demostración de trabajo”: la verificación es obligatoria, la producción debe ser monitoreada, los límites y los principios éticos deben estar incorporados en las decisiones. Esta unidad es la columna portadora del módulo; Todos los anteriores se juntan aquí.

Capas de arquitectura de producción

Una calificación sólida de LLM consta de aproximadamente cinco capas:

Capa de entrada: Recopile datos, límpielos, enmascare áreas sensibles, transmita solo lo necesario.
Capa de modelo: seleccione el modelo correcto (unidad 5), configure el indicador y los parámetros del sistema (unidad 4), caché (unidad 6).
Capa de validación: verifique la salida con el esquema/regla, la fuente y la aprobación humana si es necesario.
Capa de acción: realizar acciones con resultados validados; Captar acciones de alto impacto.
Capa de monitoreo: Registre y mida cada llamada, costo, error y calidad.

Estas capas son una tubería; cada uno comprueba la salida del anterior.

¿Por qué se requiere verificación?

Los LLM pueden producir resultados fluidos pero a veces inexactos. A esto se le llama alucinación: el modelo puede fabricar información que parece cierta pero no lo es. En un juego de chat esto es tolerable; no puede tolerarse en un sistema de producción (factura, salud, legal, finanzas). Así resultó ser, ciegamente poco confiable; está confirmado.

Capas de verificación (aumentando por impacto):

Validación de formato/esquema: ¿La salida se ajusta al esquema JSON esperado? (La producción estructurada lo garantiza en gran medida).
Verificación de reglas/lógica: ¿Son razonables los valores? (¿El monto es negativo, la fecha es futura, la categoría es válida?)
Verificación de fuente: ¿El reclamo se basa en la documentación proporcionada? ¿El modelo dice algo que no está en el documento?
Aprobación humana: un experto revisa decisiones ambiguas o de alto impacto.

Precaución: "El modelo es tan bueno que no se necesita más verificación" es la falacia de producción más peligrosa. No importa cuán bueno sea el modelo, la capa de verificación es una red de seguridad en decisiones de alto impacto. Incluso una decisión automática equivocada puede quitarnos todo el tiempo ahorrado.

Humano en el circuito

No todas las decisiones tienen que ser completamente automáticas. En el enfoque humano-in-the-loop, el modelo acelera el trabajo y el humano lo aprueba. El equilibrio adecuado depende del impacto de la decisión y de la confiabilidad del modelo en esa tarea.

Impacto de la decisión

Enfoque

Bajo (sugerencia de etiqueta, borrador)

Automatización total; El error es barato y reversible.

Medio (enrutamiento, priorización)

Automatización + control de muestreo

Alto (dinero, contrato, salud, eliminación)

El consentimiento humano es obligatorio; el modelo solo sugiere

Monitoreo: no puedes gestionar lo que no ves

En producción, debes monitorear cada llamada. Sin seguimiento, no es posible mejorar los costos, la calidad ni detectar un problema a tiempo. Métricas clave a registrar:

Uso/costo: por solicitud y tokens totales, distribución del modelo, gasto diario.
Latencia: tiempo de respuesta promedio y en el peor de los casos.
Tasa de error: tasas 429/500, reintentos, abandonos.
Calidad: tasa de salida rechazada en la capa de verificación, tasa de corrección en la aprobación humana, comentarios de los usuarios.

Consejo: No escriba datos confidenciales (información personal, claves) en los registros de seguimiento. Considere los registros dentro del alcance de la confidencialidad; registrar mediante enmascaramiento si es necesario (unidad 9).

Ética y límites

La responsabilidad ética forma parte tanto de la decisión de producción como la precisión técnica:

Transparencia: El usuario debe saber si está hablando con una inteligencia artificial o con un humano.
Equidad y sesgo: el modelo puede tener sesgos debido a los datos con los que se entrena; Monitorear las consecuencias discriminatorias en decisiones de alto impacto (contratación, crédito).
Responsabilidad: Si una decisión automatizada causa daño, usted es responsable; “El modelo lo dijo” no es una defensa.
Aceptación de límites: el modelo no puede realizar algunas tareas de manera confiable; no automatizarlos también es una decisión de diseño.

Plantillas copiables

# Lista de verificación de validación (después de la generación de resultados) 1) ¿Es válido el esquema? (validación de salida estructurada)2) ¿Tienen sentido los valores? (verificación de reglas: rango, fecha, enumeración) 3) ¿El reclamo se basa en la fuente? (rechazar si no está en el documento)4) ¿El impacto es alto? → enviar para aprobación humana5) Si todo pasó → permitir acción, guardar

# Mensaje del sistema que obliga a confiar en la fuente. Depender únicamente de la información del documento proporcionado. No agregue nada que no esté en el documento. Si una información no está en el documento, escriba "No encontrado en el documento". Nunca adivines ni inventes cosas.

# Umbral de aprobación humana (regla de decisión)SI tipo_decisión en [dinero, contrato, eliminar, salud] → aprobación humana obligatoriaSI modelo_confianza <umbral O validación "incierta" → enviar a aprobación humanaOTRO → aplicación automática + control de muestreo

# Plantilla de registro de seguimiento (escribiendo datos confidenciales){ "time":"...", "model":"...", "input_token":..., "output_token":..., "delay_ms":..., "stop_reason":"...", "authentication":"passed|rejected|human", "cost_usd":... } // los datos personales y la clave NUNCA se escriben

Aviso débil / Aviso fuerte (fiabilidad de producción)

# DÉBIL (sin verificación, sin fuente, se aplica automáticamente) Evalúe esta solicitud, tome una decisión de reembolso y presente la solicitud.

# FUERTE (basado en la fuente, genera recomendación, deja la aprobación humana) Evalúe esta solicitud de devolución basándose únicamente en el documento de política de devolución. Recomendar decisión con justificación pero no implementar: {"recomendación":"aprobar|rechazar","reason":"...","policy_clause":"..."}. Si no hay una base clara en el documento de política, indique "poco claro". Un representante aprobará la decisión final.

Versión potente; Atribuye la decisión a la fuente, posiciona al modelo como un “sugerente” en lugar de un “hacedor” y coloca el paso de alto impacto detrás de la aprobación humana. Ésta es la esencia de la fiabilidad de la producción.

Tres mini estuches

Caso 1: el día en que se guardó la capa de verificación. Una fintech estaba haciendo que el modelo clasificara descripciones de transacciones y creara registros contables automáticos. Agregaron validación de reglas: una vez que el modelo generó la cantidad incorrectamente (12,500 en lugar de 1,250 en el documento), la regla "la cantidad no coincide con el documento" rechazó la salida y el registro recayó en el ser humano. Si no hubiera verificación, el registro incorrecto ingresaría silenciosamente al sistema.

Caso 2: Fugitivo capturado por vigilancia. Un equipo de SaaS había creado un panel de seguimiento; Una mañana el coste diario se triplicó. En los registros se vio que un cliente entró en un bucle y envió la misma solicitud miles de veces. Agregaron cuota y deduplicación; El problema se resolvió en unas horas. Sin seguimiento, la factura sería una sorpresa a final de mes.

Caso 3: Aceptar el límite. Una startup sanitaria planeaba hacer una recomendación de diagnóstico de forma totalmente automática y mostrársela al paciente. En una revisión de ética y responsabilidad, decidieron que esto estaba prohibido: el modelo sólo proporciona un resumen y posibles puntos al médico, el médico hace el diagnóstico. No automatizar un trabajo también es una decisión de diseño madura.

Errores comunes

Saltar la validación: aplicar ciegamente el resultado y decir "el modelo es bueno".
Automatización de decisiones de alto impacto: la aprobación humana es esencial en dinero/salud/ley.
No seguimiento: Los problemas de costes y calidad se descubren tarde.
Escribir datos confidenciales en registros: violación de la privacidad; Guárdalo enmascarándolo.
No intentar confiar en la fuente: El modelo puede inventar lo que no está en el documento.
Ignorar los límites: No automatizar algunas tareas es la decisión correcta; La transparencia y la responsabilidad son tuyas.

Más profundo: gestión de versiones, reversión e implementación incremental

Poner en producción una función de LLM no se trata de configurarla y olvidarse de ella; es modificar de forma segura un sistema activo a lo largo del tiempo. Tiene tres pilares.

Versionado. Las reglas de verificación, selección de modelo y avisos de su sistema cambian con el tiempo. Versione cada cambio significativo y registre qué versión está activa. Si un día la calidad baja, "¿qué cambiamos?" Debería poder responder la pregunta en cuestión de minutos. En un sistema sin versión, encontrar la causa raíz de una regresión lleva días.

Revertir. Si un nuevo mensaje o modelo se comporta peor de lo esperado en vivo, debería poder volver rápidamente a la versión anterior conocida. Un cambio sin un plan de reversión es aceptar ciegamente un riesgo real. "Cambié algo, se puso malo, no puedo volver atrás" es el escenario de producción más caro.

Despliegue gradual. En lugar de aplicar un cambio a todo el tráfico a la vez, primero lo implementa en un pequeño porcentaje (por ejemplo, 5%) y monitorea las métricas (calidad, costo, errores). Si es bueno, aumentas el porcentaje; Si es malo, lo recuperarás con solo una pequeña sección afectada. Esto limita enormemente el riesgo.

Estas tres prácticas combinan técnicas de todas las unidades anteriores: evaluación (unidad 5) mide los cambios por adelantado, monitoreo (esta unidad) brinda alerta temprana durante la propagación, la capa de verificación detecta resultados erróneos antes de que se vuelvan procesables. La producción no es una única configuración correcta; Es una disciplina continua que mide, monitorea y puede cambiar con confianza. El módulo completo es para que establezcas esta disciplina.

En resumen

La producción es más que una demostración funcional: es un canal de capas de entrada, modelo, verificación, acción y monitoreo. El resultado no es fiable sin verificación; las decisiones de alto impacto están ligadas a la aprobación humana; Cada llamada es monitoreada en busca de costos, errores y calidad. La ética, la transparencia, el control de prejuicios, la rendición de cuentas y la aceptación de límites son parte integral de las decisiones técnicas. Cada pieza aprendida en este módulo se combina en este diseño holístico.

Tarea de aplicación

Diseñe una función LLM de un extremo a otro. (1) Complete las cinco capas (entrada, modelo, verificación, acción, seguimiento) para su tarea específica. (2) Marcar por impacto qué decisiones requerirán aprobación humana. (3) Escriba al menos tres comprobaciones de validación (esquema, regla, fuente). (4) Determine las métricas clave que rastreará y las que no registrará. (5) Escribe un límite y un principio ético que aceptes en este artículo.

lista de verificación

[] Puedo diseñar cinco capas del proceso de producción.
[] Puedo validar el resultado según el esquema, la regla y la fuente.
[] Puedo establecer un umbral de aprobación humana basado en el impacto de la decisión.
[] Superviso los costos, los errores y la calidad y practico no escribir datos confidenciales en los registros.
[ ] Puedo transformar la ética, la responsabilidad y los límites en decisiones de producción.

Examen del módulo

1. ¿Qué hace la función de "sistema" en una API de chat de LLM?

A) Da al modelo instrucciones permanentes y reglas de comportamiento que se aplican durante toda la conversación ✔
B) Mantiene la última pregunta escrita por el usuario
C) Almacena la respuesta producida por el modelo.
D) Cifra la clave API

Descripción: El rol del sistema le da al modelo instrucciones persistentes, personalidad y reglas que se aplican a lo largo de toda la conversación; Es una redirección de alto nivel, independiente de los mensajes de los usuarios.

2. ¿Por qué se vuelve a enviar el historial de conversaciones (mensajes anteriores) cada vez que se realiza una solicitud de API?

A) Es necesario realizar una copia de seguridad ya que el servidor elimina el historial.
B) Las llamadas API no tienen estado; ✔ El contexto se resiente en cada solicitud porque el modelo no recuerda el historial
C) Requerido sólo para facturación, no tiene efecto en el modelo
D) El envío del historial es obligatorio para no ralentizar la respuesta

Explicación: Las llamadas a la API de LLM no tienen estado; El modelo no recuerda rondas anteriores, por lo que todo el historial relevante se reenvía en cada solicitud para preservar el contexto.

3. ¿Qué es un 'token' en el precio de LLM?

A) Contraseña de un solo uso utilizada para iniciar sesión en la API
B) Una tarifa fija pagada en cada solicitud.
C) La unidad más pequeña en la que el modelo procesa el texto; generalmente corresponde a la parte de la palabra ✔
D) Una unidad que mide sólo la longitud de la salida.

Descripción: Token es la unidad más pequeña en la que el modelo procesa texto; Por lo general, corresponde a un fragmento de una palabra, y tanto la entrada como la salida se cobran en función del número de tokens.

4. ¿Por qué los tokens de salida son más caros que los tokens de entrada en la mayoría de los proveedores de LLM?

A) Los tokens de salida siempre son más largos que los de entrada
B) Los tokens de entrada son gratuitos
C) Los tokens de salida se envían dos veces a través de Internet.
D) El costo unitario es mayor porque la generación de producción requiere cálculos adicionales para cada token ✔

Descripción: Cada uno de los tokens de salida requiere que el modelo realice una generación (cálculo) paso a paso; Este costo de producción es mayor que el de procesar todos los insumos de una sola vez, por lo que el precio unitario del producto suele ser mayor.

5. ¿En qué situación es más beneficioso utilizar el streaming?

A) En respuestas largas; Reduce el retraso percibido y evita el tiempo de espera ✔
B) Sólo en respuestas muy breves de una sola palabra.
C) Reducir el coste a cero
D) Para ocultar la clave API

Descripción: en respuestas largas, la transmisión reduce la latencia percibida al hacer que las primeras palabras aparezcan inmediatamente y evita tiempos de espera de HTTP en valores max_tokens grandes.

6. ¿A qué afecta generalmente el aumento del parámetro "esfuerzo" en los modelos modernos?

A) Siempre acorta la respuesta.
B) Gira automáticamente la clave API
C) Solo reduce el precio del token de entrada.
D) Aumenta la profundidad del pensamiento y el gasto simbólico; Puede mejorar la calidad, pero también aumenta la latencia y el costo ✔

Descripción: El parámetro de esfuerzo ajusta qué tan profundamente pensará el modelo en una tarea y cuántos tokens gastará; La actualización puede mejorar la calidad, pero también aumenta la latencia y el costo. Para tareas sencillas, basta con un esfuerzo reducido.

7. ¿Cuál es generalmente el enfoque más rentable para una tarea de clasificación simple y de gran volumen?

A) Utilice siempre el modelo más caro y potente
B) Llamar a todos los modelos al mismo tiempo para cada solicitud.
C) Seleccionar el modelo más ligero/barato que cumpla la tarea verificándolo con una pequeña evaluación ✔
D) mantener el valor max_tokens innecesariamente demasiado alto

Explicación: Si la tarea no es compleja, elegir un modelo más rápido y económico que realice la tarea fácilmente (por ejemplo, la clase Haiku) en lugar de utilizar el modelo más caro y potente reducirá significativamente el costo.

8. ¿En qué escenario el almacenamiento en caché rápido reduce más el costo?

A) Cuando un contexto grande y fijo se usa repetidamente en muchas solicitudes ✔
B) Cuando en cada solicitud se envía un texto completamente diferente
C) Cuando se realiza una única solicitud
D) Reducir los tokens de salida

Descripción: el almacenamiento en caché es una coincidencia de prefijo; En los casos en los que se reutiliza un contexto grande e inmutable (indicador del sistema, documentos) en muchas solicitudes, la lectura del caché es una pequeña fracción (~0,1x) del precio total.

9. ¿Cómo debo editar el mensaje para que llegue el caché del mensaje?

A) Poner contenido variable al principio y contenido fijo al final
B) Incrustar la fecha y hora actuales en el mensaje del sistema para cada solicitud
C) Poner contenido fijo (mensaje del sistema, documentos) al principio y contenido variable al final ✔
D) Cambiar el orden de la lista de herramientas con cada solicitud

Explicación: Dado que el caché es una coincidencia de prefijo, se inicializa el contenido fijo/invariable (mensaje del sistema, documentos); El contenido variable (fecha, pregunta del usuario, ID de solicitud) se coloca al final. Incluso un solo byte cambiado al principio invalidará el caché.

10. ¿Para qué tipo de carga de trabajo es más adecuado el procesamiento por lotes?

A) Chat en vivo donde el usuario espera una respuesta instantánea en la pantalla
B) Sólo una breve pregunta
C) Generación de clave API
D) Trabajos que toleran retrasos, son de gran volumen y no requieren resultados inmediatos ✔

Descripción: El procesamiento por lotes es adecuado para grandes volúmenes de trabajos que no requieren una respuesta inmediata y toleran retrasos; Los resultados se obtienen después de algún tiempo, pero el costo unitario suele ser menor.

11. ¿Qué se utiliza para hacer coincidir con seguridad a qué solicitud pertenecen los resultados en un lote?

A) Orden de envío (posición) de solicitudes
B) Longitud de las respuestas
C) Últimos 4 dígitos de la clave API
D) Un custom_id único asignado a cada solicitud ✔

Observación: Los resultados masivos pueden devolverse en un orden diferente al orden de envío; por lo que es necesario hacer coincidir los resultados por ID, no por ubicación, con un custom_id único asignado a cada solicitud.

12. ¿Cuál es el comportamiento recomendado cuando recibe un error 429 (límite de velocidad) de la API?

A) Forzar enviando muchas más solicitudes al mismo tiempo
B) Intentar de nuevo con retroceso exponencial, siguiendo el encabezado de reintento después ✔
C) Cancelar la solicitud por completo y mostrar el error como un bloqueo al usuario
D) Cambiar la clave API

Explicación: 429 es un error que se puede volver a intentar; El enfoque correcto es volver a intentarlo con un retroceso exponencial, respetando el encabezado de reintento posterior. La mayoría de los SDK oficiales hacen esto automáticamente.

13. ¿Cuáles de los siguientes códigos de error HTTP se consideran generalmente reintentables?

A) 400 (solicitud no válida)
B) 401 (error de autenticación)
C) 529 (servidor sobrecargado) ✔
D) 404 (no encontrado)

Explicación: 429 (límite de velocidad), 500 (error del servidor) y 529 (sobrecarga) son errores temporales y se pueden volver a intentar retrocediendo. Errores como 400 y 401 son problemas de solicitud/identidad; Intentarlo de nuevo no lo solucionará.

14. ¿Cuál de las siguientes es la forma segura de administrar claves API?

A) Almacenar en la variable de entorno/administrador oculto, no incrustarlo en el código y rotarlo regularmente ✔
B) Escriba la clave directamente en el código fuente y envíela al repositorio
C) Poner la clave en JavaScript del lado del cliente (navegador)
D) Compartir una única clave con todo el equipo vía correo electrónico

Descripción: Las claves nunca se escriben en el código fuente o en el repositorio; Se almacena en una variable de entorno o herramienta de administración oculta, se le otorgan privilegios mínimos y se rota periódicamente.

15. ¿Cuál es el mejor enfoque para la integración de LLM con una herramienta de automatización (n8n, Zapier, Make) en términos de privacidad?

A) Enviar todos los datos sin procesar al modelo, incluso si no es necesario
B) Escribir la clave API en texto sin formato dentro del paso de flujo
C) Minimizar y enmascarar datos confidenciales y almacenar la clave como credenciales secretas ✔
D) Mantener los datos personales de forma permanente en el historial de flujos

Descripción: A medida que los datos que ingresan a la automatización pasan a través de sistemas y modelos de terceros, los datos confidenciales/personales deben minimizarse, enmascararse y enviarse solo los campos obligatorios; La clave API también se almacena como credenciales secretas dentro de la herramienta.

16. ¿Por qué es obligatoria la validación del resultado en una función de producción basada en LLM?

A) Sólo se requiere formatear porque el modelo nunca comete errores
B) Porque el modelo puede producir de forma fluida pero a veces de forma incorrecta; El esquema/regla debe ser auditado con aprobación humana y de recursos ✔
C) Se debe evitar la validación porque solo aumenta el costo.
D) La verificación es solo para reducir la cantidad de tokens.

Descripción: Los LLM pueden producir resultados fluidos pero a veces inexactos (alucinatorios); así salió a relucir en decisiones de alto impacto; Debe ser auditado mediante verificación de esquemas/reglas, validación de fuentes y aprobación humana cuando sea necesario.