Caso de integración

Mesa de ayuda: qué pasa cuando la respuesta del modelo sale mal

Una aplicación de soporte le pide a un LLM que convierta diez mensajes de clientes en tickets. Cambia una sola cosa: cómo se lee la respuesta. Corre en tu navegador con js/mini.js, el mismo motor del playground, con respuestas grabadas o —si pones tu propia clave— llamando a DeepSeek o Groq de verdad.

Cómo lee la respuesta
Modelo
Qué respondió el modelo

Respuesta del modelo .mini


    

Tickets registrados 0

Lo único que cambia: la instrucción que recibe el modelo

Los diez mensajes que entran

Con .mini — bloque de prompt del contrato


      

Con JSON — el JSON Schema del ticket


      

El contrato tk no se escribió a mano: sale del mismo JSON Schema con mini from-schema. La aplicación no cambia de dominio ni de base de datos.

Con un modelo real

En modo Grabado la simulación de arriba reproduce respuestas guardadas, para que el resultado sea siempre el mismo; eligiendo DeepSeek o Groq con tu clave, esas mismas llamadas salen de verdad. Estas cifras son de la aplicación de escritorio equivalente, con los mismos diez mensajes y temperatura 0.

Cómo se integra

Tres pasos, sin tocar el dominio de la aplicación: el contrato sale del esquema que ya tenías, el prompt sale del contrato y la lectura valida y repara.

  1. 1

    Genera el contrato desde tu JSON Schema.

    mini from-schema ticket.schema.json -p tk --out contrato_tk.json
  2. 2

    Pide la respuesta con el bloque de prompt del contrato.

    spec_block(contrato, "es")
  3. 3

    Lee en modo tolerante y repara solo lo que falló.

    parse(texto, contrato, strict=False) · repair_request · merge_repair

Paso a paso completo en el inicio rápido · índice de errores en /docs/errors/ · prueba tus propios documentos en el playground.