DSLs para usar LLMs con más confiabilidad

Si hoy usas un LLM para algo más que una demo, ya te topaste con el mismo problema: a veces responde bien, a veces inventa, a veces cambia el formato y rompe tu flujo. Eso está bien para una prueba interna. Para producción, no tanto.

La salida no es pedirle al modelo que “sea más cuidadoso”. La salida es reducir el espacio de error. Y una de las formas más prácticas de hacerlo es usar DSLs, es decir, lenguajes específicos de dominio, para que el LLM trabaje sobre estructuras más claras, más verificables y más fáciles de integrar en sistemas reales.

El problema real no es el prompt, es la variabilidad

Cuando una empresa dice que quiere “meter IA” en su operación, casi siempre imagina una interfaz tipo chat. Pero en el día a día, lo que realmente necesita es otra cosa: extraer datos de facturas, clasificar tickets, redactar respuestas comerciales, resumir reuniones, generar órdenes, validar campos y mover información entre sistemas. Ahí es donde el LLM deja de ser una curiosidad y se convierte en una pieza de infraestructura.

El problema es que los LLMs son buenos generando texto plausible, no necesariamente salidas confiables. Si le pides “extrae el nombre, RUC y total”, puede funcionar 9 de 10 veces. Ese décimo caso, el que cambia una coma o devuelve un campo extra, te puede romper una automatización, disparar una mala decisión o hacer que un humano tenga que revisar todo de nuevo.

Por eso el enfoque correcto no es confiar ciegamente en el lenguaje natural. Es ponerle una estructura alrededor. Una DSL hace justamente eso: limita el formato, define reglas y deja menos margen para interpretaciones ambiguas. Si el modelo tiene que producir una salida que se parezca a una plantilla, un esquema o una mini sintaxis, tú puedes validarla antes de usarla.

Qué es una DSL y por qué ayuda con LLMs

Una DSL es un lenguaje diseñado para un problema concreto. No pretende servir para todo como Python o JavaScript. Sirve para una tarea específica: consultas, reglas de negocio, transformaciones, workflows, filtros, validaciones o configuraciones. Ejemplos clásicos son SQL para consultas, regex para patrones o Terraform para infraestructura.

Con LLMs, la idea es parecida: en vez de pedirle al modelo una respuesta libre, le pides que produzca algo dentro de una sintaxis más cerrada. Esa sintaxis puede ser JSON estricto, una mini gramática propia, una lista de comandos, o incluso una DSL de negocio que luego tu sistema interpreta.

Qué ganas al restringir la salida

Ganas varias cosas concretas:

• Menos ambigüedad: el modelo no decide el formato a su antojo.
• Más validación: puedes chequear si la salida cumple reglas antes de ejecutarla.
• Mejor integración: tu backend no depende de texto libre para tomar decisiones.
• Más observabilidad: puedes registrar fallos por tipo, campo o regla.

En otras palabras, pasas de “el modelo dijo algo” a “el modelo produjo una estructura que mi sistema puede aceptar o rechazar”. Esa diferencia es enorme cuando tienes un flujo con dinero, clientes o automatización operativa.

No toda estructura sirve igual

Aquí conviene ser precisos. JSON ayuda, pero no siempre resuelve el problema completo. JSON te da forma, no semántica. Puedes tener un objeto válido con datos incorrectos, campos fuera de rango o una combinación que tu negocio no acepta.

Una DSL bien pensada puede expresar reglas como estas:

• priority = high solo si el ticket viene de un cliente enterprise.
• amount > 1000 requiere revisión humana.
• country in [EC, CO, PE] activa una plantilla específica.
• status = approved solo si existen tres campos obligatorios.

Eso ya no es solo formato. Es lógica de negocio explícita.

Cómo se ve una DSL útil para un flujo con IA

La mejor forma de entenderlo es con un caso realista. Imagina un equipo de ventas que recibe leads por correo, WhatsApp y formularios. Quieren que un LLM lea mensajes, clasifique intención, detecte urgencia y proponga el siguiente paso.

Si le das un prompt abierto, el modelo puede responder algo como: “Parece un cliente interesado, conviene responder pronto”. Útil para un humano. Inútil para un sistema.

En cambio, si le pides que produzca una salida en una DSL simple, puedes obtener algo así:

lead {
  intent: "pricing"
  urgency: "high"
  next_action: "send_quote"
  confidence: 0.86
  reasons: ["asked for cost", "mentioned timeline"]
}

Ahora tu backend puede hacer cosas concretas: si urgency es high, crea una tarea; si confidence baja de 0.7, manda a revisión; si next_action es send_quote, dispara una plantilla aprobada.

Un ejemplo más cercano a operaciones

Pensemos en soporte. En vez de pedirle al LLM que redacte libremente una respuesta final, le puedes pedir que genere un plan estructurado:

response_plan {
  category: "billing"
  action: "request_more_info"
  customer_tone: "calm"
  required_fields: ["invoice_number", "date"]
}

Luego tu sistema usa ese plan para llenar una plantilla controlada. Así reduces el riesgo de que el modelo improvise políticas, prometa cosas que no existen o cambie el tono de forma inconsistente.

La DSL como contrato entre el modelo y tu sistema

La clave es pensar la DSL como un contrato. El LLM propone, pero tu sistema dispone. Si la salida no cumple la gramática, se rechaza. Si cumple, se procesa. Si cumple parcialmente, puedes pedir una segunda pasada o activar una ruta de fallback.

Ese enfoque funciona mejor que confiar en un prompt largo lleno de instrucciones. Los prompts ayudan, sí, pero son frágiles. Una DSL te da un límite claro: esto sí, esto no.

Dónde usar DSLs en productos reales

No necesitas convertir todo tu producto en una DSL. Eso sería exagerado. Lo útil es identificar los puntos donde el LLM toma decisiones que afectan procesos y donde un error cuesta tiempo o dinero.

Casos que sí se benefician

Algunos casos donde una DSL aporta bastante valor:

1. Extracción de datos de documentos: facturas, contratos, formularios, órdenes de compra.
2. Clasificación de tickets: prioridad, categoría, intención, idioma, riesgo.
3. Enrutamiento de tareas: asignar a ventas, soporte, legal o finanzas.
4. Generación de acciones: crear tareas, enviar emails, abrir incidencias.
5. Resúmenes operativos: convertir texto largo en campos estructurados.
6. Reglas de cumplimiento: bloquear salidas que no cumplan políticas internas.

En estos casos, el objetivo no es que el LLM escriba bonito. El objetivo es que produzca algo que tu sistema pueda ejecutar sin sorpresas.

Casos donde no hace falta complicarse

También hay escenarios donde una DSL puede ser demasiado. Si solo quieres brainstorming, ideas de contenido o borradores internos, probablemente no necesitas una sintaxis rígida. Ahí basta con un buen prompt y un flujo humano encima.

La regla práctica es simple: si la salida va a ser consumida por una persona, puedes tolerar más variación. Si la salida va a ser consumida por una máquina, necesitas más estructura.

Cómo diseñar una DSL para que funcione con LLMs

Diseñar una DSL para LLMs no es inventar un lenguaje raro. Es diseñar una interfaz legible para el modelo y útil para tu sistema. Si te pasas de complejo, el modelo falla más. Si te pasas de simple, no expresas lo que necesitas.

1. Empieza por los campos que de verdad usas

No diseñes la DSL desde la teoría. Hazlo desde el flujo real. Pregúntate qué decisiones toma tu sistema después de la salida del modelo. Si solo usas tres campos, no agregues diez por estética.

Por ejemplo, en un clasificador de leads, tal vez solo necesitas:

• intent
• priority
• next_action
• confidence

Con eso ya puedes automatizar bastante. Si luego necesitas más detalle, lo agregas.

2. Usa valores cerrados cuando puedas

Los modelos se comportan mejor cuando el espacio de opciones es pequeño. En vez de pedir “describe el nivel de urgencia”, define valores como low, medium, high. En vez de “sugiere una acción”, usa una lista cerrada: reply, escalate, request_info, close.

Eso reduce errores y facilita validación. También hace más fácil medir calidad, porque ya no comparas texto libre sino categorías concretas.

3. Haz que el formato sea fácil de validar

Si tu DSL se parece a YAML, JSON o una sintaxis simple con llaves y pares clave-valor, puedes validarla con herramientas estándar. Eso te permite detectar errores de estructura antes de tocar sistemas críticos.

Por ejemplo, en Node puedes combinar parseo y validación de esquema. La documentación oficial de JSON Schema es un buen punto de partida: https://json-schema.org/

4. Diseña para fallback

No asumas que el modelo siempre va a acertar. Diseña una ruta de fallback desde el principio. Si la salida no valida, puedes:

• volver a pedir la generación con un prompt más estricto,
• enviar el caso a revisión humana,
• usar una regla determinista,
• o devolver un error controlado.

La confiabilidad no viene de eliminar todos los fallos. Viene de manejar bien los fallos.

Patrón práctico: prompt + DSL + validador

La combinación más útil no es solo DSL, sino este triángulo: prompt, DSL y validador. El prompt orienta, la DSL estructura y el validador decide si la salida pasa o no.

Flujo recomendado

1. Le explicas al modelo la tarea con instrucciones claras.
2. Le muestras la DSL esperada con uno o dos ejemplos.
3. Le pides que responda solo en ese formato.
4. Parseas la salida en tu backend.
5. Validás tipos, rangos y campos obligatorios.
6. Si falla, activas fallback o reintento.

Ese flujo es mucho más robusto que dejar que el modelo escriba una respuesta libre y luego intentar “limpiarla” con regex. Regex puede servir para casos puntuales, pero no debería ser tu estrategia principal.

Ejemplo de validación en TypeScript

import { z } from "zod";

const LeadActionSchema = z.object({
  intent: z.enum(["pricing", "support", "demo", "other"]),
  urgency: z.enum(["low", "medium", "high"]),
  next_action: z.enum(["send_quote", "ask_clarification", "book_call", "route_human"]),
  confidence: z.number().min(0).max(1),
});

const result = LeadActionSchema.safeParse(JSON.parse(modelOutput));

if (!result.success) {
  // fallback: retry, human review o regla determinista
}

La idea no es que el LLM nunca falle. La idea es que tu sistema no se rompa cuando falle.

Métricas que sí te dicen si la DSL está ayudando

Si implementas una DSL, no la midas por intuición. Mídela por impacto operativo. Si no, corres el riesgo de agregar complejidad sin ganar confiabilidad real.

Métricas útiles

Estas métricas te ayudan a ver si vas por buen camino:

• tasa de salidas válidas al primer intento,
• porcentaje de reintentos,
• porcentaje de casos enviados a revisión humana,
• tiempo medio de resolución,
• errores por campo,
• porcentaje de automatización sin intervención.

Una tabla simple puede ayudarte a comparar antes y después:

No necesitas números perfectos para empezar. Pero sí necesitas una línea base. Si no comparas, no sabes si la DSL ayudó o solo hizo el sistema más elegante.

Qué mirar en equipos de LatAm

En equipos de Latinoamérica suele haber una presión doble: automatizar rápido y cuidar el costo. Por eso conviene medir también cuántas intervenciones humanas ahorras y cuántos casos evitas escalar. Si tu equipo en Ecuador, México o Colombia atiende alto volumen, una reducción pequeña por caso se multiplica rápido.

Riesgos y límites de este enfoque

Las DSLs ayudan, pero no son magia. Si diseñas mal el lenguaje, el modelo va a fallar más. Si pides demasiadas reglas, la tasa de error sube. Si mezclas demasiadas responsabilidades en una sola salida, el sistema se vuelve difícil de mantener.

Riesgo 1: sobreingeniería

El error típico es crear una DSL enorme para anticipar todos los casos futuros. Eso termina siendo difícil de usar para el modelo y difícil de mantener para tu equipo. Mejor empieza pequeño, con el mínimo que resuelva el flujo actual.

Riesgo 2: falsa sensación de seguridad

Que una salida valide no significa que sea correcta. El modelo puede producir algo sintácticamente válido pero semánticamente incorrecto. Por eso necesitas reglas de negocio, tests y revisiones de muestra.

Riesgo 3: prompts frágiles

Si tu DSL depende de un prompt larguísimo y delicado, cualquier cambio menor puede degradar resultados. Conviene versionar prompts y DSLs juntos, hacer pruebas de regresión y tener ejemplos de referencia.

Riesgo 4: costo operativo oculto

A veces una DSL reduce errores, pero aumenta el trabajo de mantenimiento. Si cada cambio en negocio obliga a editar reglas, validadores y plantillas, el costo puede subir. La pregunta no es si la DSL es elegante. La pregunta es si te ahorra más de lo que te cuesta.

Tabla resumen

Si quieres profundizar en el enfoque de lenguajes específicos de dominio aplicado a LLMs, la idea original de Martin Fowler es una buena referencia: https://martinfowler.com/articles/llm-and-dsls.html. Para la parte de validación estructural, también vale la pena revisar la documentación oficial de JSON Schema y, si trabajas en TypeScript, la de Zod.

La lección práctica es bastante simple: no le pidas al LLM que haga de sistema completo. Dale una tarea acotada, una sintaxis clara y un validador que ponga límites. Así conviertes una salida probabilística en una pieza más confiable de tu flujo.