Cómo escribir un prompt de sistema que no se infle

Qué hace exactamente

El prompt de sistema fija el comportamiento por defecto: quién es el modelo, qué debe hacer, con qué formato responde y qué no debe hacer nunca. Va aparte del mensaje del usuario porque tiene otra vida útil: el mensaje cambia en cada llamada y el sistema, no.

Esa asimetría es la que decide todo lo demás. Una palabra en el mensaje del usuario se paga una vez. Una palabra en el prompt de sistema se paga en cada llamada que haga tu producto mientras exista, y multiplicada por todos tus usuarios.

Qué va dentro y qué sobra

Lo que de verdad cambia la respuesta es poco: el rol, el formato de salida, las restricciones duras y los ejemplos cuando el formato es difícil de describir con palabras.

• ·El rol, en una línea. «Eres un analista financiero» basta; «Quiero que actúes como si fueras un experimentado analista financiero con muchos años de experiencia» dice lo mismo con cuatro veces más tokens.
• ·El formato de salida, en concreto. «Responde en JSON con las claves nombre, importe y fecha» funciona; «responde de forma estructurada» no dice nada accionable.
• ·Las restricciones duras, en imperativo. «No inventes datos que no estén en el documento» es una instrucción; «es muy importante que tengas mucho cuidado de no inventar» es la misma con relleno.
• ·Ejemplos, solo si el formato no se puede describir. Un ejemplo bien elegido ahorra párrafos de explicación; tres ejemplos casi idénticos son tres veces el mismo coste.

Por qué siempre acaba engordando

El patrón es siempre el mismo. El modelo falla en un caso, alguien añade una frase para taparlo, funciona, y la frase se queda. Seis meses después el prompt tiene cuarenta líneas y nadie recuerda cuáles siguen haciendo falta.

El problema no es solo el coste. Un prompt largo diluye las instrucciones importantes entre las accesorias, y hay un punto a partir del cual añadir reglas empeora la obediencia en vez de mejorarla.

La disciplina que funciona es sencilla y casi nadie la aplica: cuando añadas una frase por un fallo concreto, apunta al lado qué fallo era. Dentro de tres meses eso es lo único que permite saber si se puede quitar.

Cómo recortarlo sin romperlo

Recortar un prompt de sistema tiene un límite claro, y cruzarlo no ahorra dinero: rompe el comportamiento. El orden seguro va de lo que no cambia nada a lo que sí.

• ·Cortesías y envoltorios de deseo. «Por favor», «me gustaría que», «si no es molestia». El modelo no obedece mejor por educación.
• ·Muletillas y refuerzos. «Es muy importante que», «recuerda siempre», «bajo ningún concepto». Si la instrucción está en imperativo, el refuerzo no añade obediencia.
• ·Perífrasis. «Con el fin de» por «para», «en el caso de que» por «si». Cambia la longitud, no el significado.
• ·Repeticiones. La misma regla dicha dos veces con otras palabras es el resto más común de meses de parches, y el que más ocupa.

Medir antes y después

Recortar a ojo es cómo se rompen los prompts. Antes de tocar nada conviene tener dos cifras: cuántos tokens ocupa hoy y cuántas llamadas al día lo envían. La segunda convierte el ahorro por llamada en una cifra mensual, que es la que decide si merece la pena.

Y después, comprobar el resultado: un diff palabra a palabra deja ver exactamente qué desapareció, que es lo único que distingue un recorte de una mutilación.