Del prompt al producto: convertir los LLM en aplicaciones reales

Un prompt que funciona en un playground es una demo, no un producto. La distancia entre ambos es donde la mayoría de los proyectos de IA mueren en silencio. Construir aplicaciones con LLM que sobrevivan a usuarios reales tiene menos que ver con el prompting ingenioso de lo que sugieren las demos, y mucho más con la disciplina ordinaria del software. Hemos lanzado suficientes de estas — Youp, MadaiOps y ahora Linea — como para tener opiniones sobre qué cierra de verdad esa distancia. Nada de ello es glamuroso.

La trampa es que la primera versión parece terminada. Pegas un prompt ingenioso, el modelo devuelve algo impresionante y resulta tentador envolverlo en una interfaz y llamarlo lanzamiento. Entonces llegan los usuarios reales con entradas que jamás imaginaste, el modelo hace algo equivocado con total seguridad y descubres que no tienes forma de saber si tu arreglo mejoró o empeoró las cosas. Este texto trata sobre el andamiaje que convierte esa demo impresionante en algo que puedes poner en producción y con lo que puedes dormir tranquilo toda la noche.

Empieza por las evaluaciones, no por los prompts

Lo de mayor apalancamiento que puedes construir al principio es un conjunto de evaluación. No un benchmark, ni una tabla de clasificación, sino una carpeta de entradas reales emparejadas con cómo se ve una buena salida. Veinte ejemplos superan a cero, y cincuenta curados superan a mil recolectados sin criterio.

La razón es sencilla. En cuanto tienes evaluaciones, la ingeniería de prompts deja de ser cuestión de intuiciones. Cambias una línea, ejecutas el conjunto, observas cómo se mueve el número. Sin ellas, cada ajuste es una superstición. Hemos visto equipos pasar una semana mejorando un prompt solo para retroceder en casos que ya habían resuelto meses antes, porque nada medía los casos que no estaban mirando.

Algunas opiniones que sostenemos con firmeza:

• Califica por resultados, no por redacción. Para cualquier cosa estructurada — extracción, clasificación, enrutamiento — verifica sobre el resultado parseado, no sobre la similitud de cadenas. Para texto abierto, un LLM como juez con una rúbrica ajustada está bien, pero valida al juez contra un puñado de etiquetas humanas primero, o solo estarás midiendo el gusto de un modelo.
• Mantén un archivo de regresiones. Cada fallo en producción se convierte en un caso de prueba permanente. Así es como tu conjunto de evaluación se mantiene honesto: crece exactamente en las direcciones hacia las que la realidad lo empuja.
• Versiona tus evaluaciones junto con tus prompts. Un prompt sin su conjunto de evaluación es un cambio de código sin probar.

Si construyes una sola cosa a partir de este artículo, construye esto. Todo lo que viene después depende de poder responder: ¿eso lo mejoró?

Los guardarraíles son más baratos que las disculpas

Los modelos fallan de formas en que el software ordinario no lo hace. Inventarán una API que no existe, estarán de acuerdo con la premisa falsa de un usuario o emitirán un JSON de apariencia válida con un campo alucinado. Los guardarraíles son la capa que atrapa esto antes de que llegue a un usuario o, peor, a un paso de ejecución.

Piensa en tres posiciones.

• Los guardarraíles de entrada rechazan o sanean antes de que el modelo se ejecute: filtrado de inyección de prompts, redacción de datos personales, filtrado de temas ajenos.
• Los guardarraíles de salida validan lo que regresa: validación de esquema, comprobaciones de fundamento en las citas, filtros de políticas.
• Los guardarraíles de acción se sitúan entre el modelo y cualquier cosa con efectos secundarios.

Ese tercero es donde vive el riesgo real. En Linea, nuestros agentes de automatización de flujos de trabajo, el modelo puede proponer acciones: llamar a una API, mover un registro, enviar un mensaje. La propuesta y la ejecución son pasos deliberadamente separados. Cada acción consecuente pasa por un contrato tipado y una comprobación de políticas antes de que algo se ejecute, y las acciones destructivas o irreversibles requieren una puerta de confirmación explícita. Un agente que sugiere lo equivocado es un problema de experiencia de usuario sobre el que puedes iterar. Un agente que hace lo equivocado es un incidente. Mantén esos dos modos de fallo en lados opuestos de una frontera dura.

La versión con opinión: valida la salida estructurada contra un esquema y reintenta ante el fallo en lugar de confiar en que el modelo sea consistente. Y nunca dejes que la salida en bruto de un modelo sea lo que dispara una acción irreversible. Pon una comprobación determinista en medio, siempre.

Presupuesta la latencia y el coste como funciones

La latencia y el coste no son cosas que mides al final. Son restricciones frente a las que diseñas desde el principio, porque cambian la arquitectura, no solo la factura.

Establece presupuestos explícitos por cada acción de cara al usuario: un objetivo de latencia p95 y un techo de coste por llamada. Una vez que están escritos, las decisiones de diseño se vuelven más fáciles. Algunos patrones a los que recurrimos una y otra vez:

• Dimensiona el modelo por paso. La mayoría de los pipelines tienen uno o dos pasos que realmente necesitan el modelo de frontera y varios que uno más pequeño y rápido maneja perfectamente. Enrutar la clasificación simple a un modelo barato y reservar el caro para el paso de razonamiento difícil es la optimización de mayor retorno disponible, y suele mejorar también la latencia.
• Transmite el primer token. Para cualquier cosa conversacional, la latencia percibida está dominada por el tiempo hasta el primer token. Una respuesta transmitida que tarda cuatro segundos se siente mejor que una bloqueante que tarda dos.
• Cachea con agresividad. Caché de prompts sobre el contexto de sistema estable, caché de resultados ordinaria sobre entradas repetidas. Una fracción significativa del tráfico en producción es casi duplicada.

El compromiso que debes tener presente: los modelos más grandes reducen tu esfuerzo de ingeniería pero elevan tu coste marginal y tu latencia para siempre. Los modelos más baratos te trasladan el trabajo a ti — más cuidado con los prompts, más guardarraíles, más evaluaciones — pero ese trabajo es un coste único frente a un ahorro permanente. Para cualquier cosa con volumen, invierte la ingeniería.

Mantén humanos en el circuito, a propósito

"Humano en el circuito" se dice tan a menudo que ha dejado de significar algo. Bien hecho, no es un plan B para cuando la IA falla: es una división del trabajo diseñada. La pregunta no es si incluir a un humano, sino dónde el juicio del humano vale más que la latencia que añade.

El patrón que mejor nos ha servido es la escalada condicionada por confianza. El sistema maneja automáticamente la mayoría confiable y enruta la minoría incierta a una persona, con el razonamiento del modelo adjunto para que el humano decida en segundos, no en minutos. En MadaiOps, las operaciones de órdenes dentro de parámetros normales fluyen sin interrupción; cualquier cosa anómala se le presenta a un operador con contexto en lugar de ejecutarse en silencio. El revisor no está haciendo de niñera de la máquina. Está gastando su atención solo donde es escasa y valiosa.

Una regla más: instrumenta las correcciones del humano y reincorpóralas a tu conjunto de evaluación y a tus prompts. Un sistema con humano en el circuito que no aprende de sus humanos simplemente paga dos veces por el mismo trabajo.

Saber qué no automatizar

El juicio más difícil en esta disciplina es la contención. No toda tarea debe entregarse a un modelo, y la madurez consiste en saber cuáles dejar en paz.

Nuestra prueba aproximada: automatiza donde el coste de un error es bajo, o el error es fácil de detectar y revertir. Redactar, resumir, extraer, clasificar, enrutar: buenos candidatos. Un borrador equivocado se edita; un resumen equivocado se detecta al leerlo. Sé mucho más cauto donde los errores son costosos, difíciles de detectar o irreversibles: cualquier cosa que mueva dinero, envíe una comunicación irrevocable o tome una decisión legal o médica. Ahí el modelo pertenece a un rol asistivo — presentando opciones, redactando para revisión — no al asiento del conductor.

La línea que mantenemos: si no puedes describir cómo detectarías que el modelo se equivoca, no estás listo para automatizar ese paso. La capacidad de detectar el fallo es el verdadero prerrequisito, más que la exactitud. Un paso con 95% de exactitud que puedes verificar por completo es más seguro de lanzar que uno con 99% de exactitud que no puedes.

La forma del trabajo

Convertir un prompt en un producto es sobre todo la parte poco glamurosa: evaluaciones para poder medir, guardarraíles para que los fallos queden contenidos, presupuestos para que se mantenga rápido y asequible, humanos ubicados donde el juicio importa y la disciplina de dejar algunas cosas sin automatizar. El modelo es quizá el veinte por ciento del sistema. El otro ochenta por ciento es la ingeniería que hace que su brillantez ocasional sea segura de la que depender.

La buena noticia es que este es un trabajo familiar. Recompensa los mismos instintos que hacen bueno cualquier tipo de software: mide antes de cambiar, contén tu radio de impacto, respeta el tiempo de tus usuarios. El modelo es nuevo. El oficio no lo es.