Los LLM filtran razonamiento en la salida estructurada a pesar de instrucciones explícitas

El problema: las pasadas de validación de LLM filtran razonamiento

Un desarrollador que construía una herramienta que realiza llamadas paralelas a la API de Claude y analiza la salida estructurada por llamada encontró un problema intermitente. Cada llamada devuelve contenido dentro de marcadores específicos como [COVER], [SLIDE 1], [CAPTION], etc. Una segunda pasada de LLM valida la salida contra reglas y reescribe cualquier cosa que falle.

El prompt de validación establece explícitamente: "devuelve SOLO el texto corregido en el mismo formato exacto. Sin comentarios. Sin razonamiento. Sin listas de violaciones".

A pesar de esto, el modelo de validación ocasionalmente genera su razonamiento antes del contenido corregido. Los ejemplos incluyen: "Necesito verificar este texto en busca de violaciones... Estas oraciones forman un par dramático apilado usado puramente para efecto. Aquí está la reescritura:" seguido del texto corregido real.

Consecuencias posteriores

Este texto de razonamiento pasa directamente al analizador. El analizador espera contenido que comience en [COVER] pero en su lugar recibe meta-comentarios. Esto causa desalineación de campos posteriormente. En un caso, el texto de razonamiento del validador terminó dentro de un campo de prompt de imagen porque el analizador consumió el razonamiento como contenido del cuerpo, desplazando todo unas pocas líneas hacia abajo.

El ajuste del prompt por sí solo no solucionó el problema. Hacer las instrucciones más explícitas, agregar "tu salida DEBE comenzar con el primer marcador de contenido" y agregar "nunca incluyas razonamiento" redujo la frecuencia pero no lo eliminó. El modelo ocasionalmente ignora instrucciones, especialmente cuando encuentra violaciones que corregir—quiere mostrar su trabajo.

La solución: defensa de dos capas

La solución que funcionó involucró dos capas:

• Capa 1: Ajuste del prompt. Todavía vale la pena hacerlo porque reduce la frecuencia con la que ocurre el problema.
• Capa 2: Una función defensiva de limpieza que se ejecuta en cada salida de validación antes de que ocurra cualquier análisis. Para formatos estructurados, se ancla al primer marcador reconocido y descarta todo lo anterior. Para formatos de texto plano, elimina líneas que coincidan con patrones conocidos de comentarios del validador (cosas como "Déjame verificar este texto" o "Esto viola la restricción").

El orden de limpieza-antes-del-análisis es clave. Cada analizador posterior opera en una salida ya saneada. Esto evita mantener lógica de limpieza por campo o jugar al juego de golpear topos con nuevos formatos de razonamiento.

Consideraciones de implementación

Para patrones de limpieza de texto plano, se necesita un diseño cuidadoso. Una expresión regular que capture "Esta es una violación" también podría capturar "Este es un error común" en contenido legítimo. Los patrones deben ajustarse para que coincidan solo con lenguaje específico del validador, como "Esto viola la/una regla/restricción" en lugar de coincidencias amplias en "Esto es" o "Esto usa". Cada patrón necesita auditoría contra contenido real antes de la implementación.

Si estás analizando salida estructurada de un LLM, trata las instrucciones del prompt como una primera pasada de mejor esfuerzo y siempre ten una defensa a nivel de código antes del analizador. El modelo cumplirá el 95% del tiempo, pero el 5% en que no lo haga romperá la lógica posterior de maneras difíciles de reproducir porque son intermitentes.