Diseño de esquemas: cómo evitar que Claude invente datos con nullable, unclear y other

Bienvenidos y bienvenidas a la cápsula cuatro del Módulo uno. Hoy vemos la segunda parte del task statement cuatro punto tres: diseñar esquemas de extracción que no obliguen al modelo a inventar.

El esquema le dice al modelo qué está obligado a entregar. Si un campo es requerido y el documento no trae ese dato, el modelo queda presionado a poner algo para cumplir, y pone un valor razonable y falso. La guía lo dice directo: diseña los campos como opcionales o nullable cuando el documento fuente puede no contener la información. Nullable significa que el campo acepta el valor nulo.

Esto importa porque un valor inventado es peor que un valor ausente. El nulo le avisa al sistema que falta el dato y que alguien debe buscarlo. Un número inventado pasa todas las validaciones de tipo y entra en silencio a la base de datos.

Un enum es un campo que solo acepta valores de una lista cerrada. Por ejemplo, el tipo de documento solo puede ser factura o contrato, y el modelo no puede escribir ningún otro valor. Los enums tienen dos recursos. Si el documento habla del tema pero no permite decidir, entonces el enum lleva el valor unclear. Por su parte, si aparece una categoría que no estaba prevista, entonces el modelo marca other y escribe en un campo de detalle cuál era. Así no fuerzas una etiqueta equivocada, y juntas evidencia para ampliar la lista después.

Hay una pieza más: las reglas de normalización. El esquema asegura que la fecha sea un texto, y una regla en el prompt asegura que venga como año, mes y día aunque el documento diga tres de marzo.

El ejemplo de la guía es un esquema de contratos con la fecha de término como campo requerido. En los contratos indefinidos, el modelo pone la fecha de firma más un año. La arquitecta cambia el campo a texto o nulo, agrega un enum de tipo de plazo con los valores fijo, indefinido, other y unclear, más un campo de detalle. Los contratos indefinidos salen con fecha nula y tipo indefinido.

Cuando el extractor devuelve valores plausibles pero falsos para documentos que no traen cierto dato, la respuesta es el campo nullable y, si hace falta, un ejemplo donde el valor correcto sea nulo. Dos respuestas fallan en el examen: reforzar en el prompt que no invente mientras el campo sigue siendo obligatorio, y reintentar la extracción. El dato no está, y ningún reintento lo va a crear.

Una pregunta. ¿Qué pasa cuando un campo obligatorio no tiene dato en el documento?

El modelo queda forzado a inventar un valor, y por eso el campo debe aceptar nulo.

Pregunta uno. Una salmonera usa un esquema de informes de cosecha que exige la fecha de término. En las cosechas abiertas, que aún no terminan, el modelo inventa una fecha razonable pero falsa. ¿Qué cambio conviene? Opción A: subir la temperatura del modelo. Opción B: mantener la fecha obligatoria y pedir en el prompt que no invente. Opción C: descartar las cosechas abiertas del proceso. Opción D: hacer ese campo nullable y agregar un campo de tipo de cosecha, con los valores fija y abierta.

La correcta es D. Si el campo acepta nulo, el modelo puede decir que el dato no existe, y el tipo de cosecha explica por qué. La A agrega aleatoriedad, no datos. La B deja al modelo presionado a rellenar un campo obligatorio. La C pierde información.

Pregunta dos, de respuesta múltiple. Elige dos. Una juguetería clasifica el motivo de cada devolución con un enum cerrado, y los casos nuevos quedan forzados a una categoría equivocada. ¿Qué dos cambios ayudan? Opción A: agregar un valor other al enum. Opción B: quitar el campo de motivo del esquema. Opción C: sumar un campo de detalle en texto, para describir los casos que no calzan. Opción D: ampliar el enum con una categoría nueva cada semana. Opción E: pedirle al modelo que elija siempre la categoría más cercana. ¿Cuáles dos?

Las correctas son A y C. La A evita forzar una etiqueta equivocada, y la C guarda qué pasó, lo que sirve para ampliar el enum con evidencia. La B pierde el dato. La D es mantenimiento sin fin. La E es justo lo que produce la categoría equivocada.

Resumen: si el documento puede no traer el dato, el campo acepta nulo. Los enums llevan other con un campo de detalle, y unclear para lo ambiguo. Si te sirvió, sigue el podcast, dale cinco estrellas y activa las notificaciones. En la próxima cápsula vemos validación y reintento, y por qué reintentar no sirve cuando el dato no existe. Nos escuchamos en la próxima cápsula de EvoAcademy.