Aquí va un fallo que es puro prompt, sin ninguna ruta de código de por medio.
Cuando un comerciante aporta su propia lista de servicios, cada uno recibe una descripción generada. La instrucción original era, razonablemente: describe este servicio con beneficios concretos para el cliente.
Las peluquerías recibieron descripciones sobre cuidado de la piel.
El modelo tenía el nombre del servicio en la estructura JSON que estaba rellenando, unas líneas más arriba, y una instrucción genérica en el campo que rellenaba. Dada una instrucción general y un valor cercano pero no adyacente, derivó hacia la media del sector en lugar de hacia el elemento concreto —y «salón de belleza» promedia algo más amplio que «corte de pelo».
El arreglo fue meter el valor dentro de la instrucción:
'description_provided' =>
'Describe "{service}" specifically — this description must be about "{service}"
and nothing else (max 450 characters, benefit-focused, explain the value/outcome).
Do not describe a different service.',
Interpolado en tiempo de construcción, de modo que el modelo lee Describe «Balayage» específicamente — esta descripción debe ser sobre «Balayage» y nada más.
La regla general: una instrucción que dice «esto» es más débil que una instrucción que nombra la cosa. Si el valor de un campo está disponible cuando construyes el prompt, mételo en la instrucción en vez de confiar en que el modelo mire dos líneas más arriba. Una repetición que a un lector humano le sobraría aquí sostiene el peso.
Escribe reglas que un modelo pueda seguir
La mayoría de las reglas que fallan lo hacen porque están poco especificadas de un modo que su autor no puede ver, porque nunca ha tenido esa duda.
Las reglas que aguantan comparten una forma. Mira lo que pasa cuando una regla se ocupa de lo que la gente escribe de verdad:
- Ordinals map to 0-based index: first=0, second=1, third=2,
primero=0, segundo=1, tercero=2.
- remove_item num is 1-based: first/primero=1, second/segundo=2.
Eso no es una regla sobre tener cuidado. Es una tabla de equivalencias, en los dos idiomas que soporta el producto, para la confusión exacta que de otro modo ocurrirá —porque una parte de la carga útil empieza en cero y otra en uno, y «borra el segundo» tiene que acertar en ambas.
Tres propiedades hacen que una regla se sostenga:
Di qué hacer, no qué evitar. Lo vimos en el capítulo anterior con los precios inventados: una prohibición sin alternativa es una regla que el modelo tiene que romper para terminar. Todo «nunca hagas X» debería llevar un «haz Y en su lugar».
Resuelve la ambigüedad hacia un resultado definido, no hacia el criterio del modelo. «Si el número de elemento es realmente ambiguo (sin ordinal, sin número) → responde con la acción nula y pregunta, con un ejemplo en el idioma del usuario.» No se le pide al modelo que adivine bien. Se le dice exactamente qué emitir cuando no puede saberlo.
Fija lo que parece obvio. «El idioma del mensaje del usuario es la ÚNICA fuente para el idioma de la respuesta. Ignora el idioma del contenido de contexto.» Sin eso, alguien que escribe en español editando un sitio en inglés recibe respuestas en inglés, porque el contexto que lo rodea pesa más que el único mensaje que importa. Nadie escribe esa regla hasta que la ha visto fallar.