Guías: escribir prompts, contar tokens y lo que cuestan

Qué es un token y por qué ocupa sitio

Un modelo de lenguaje no lee letras ni palabras: lee tokens, fragmentos de texto de unos cuatro caracteres de media en español. «Optimizador» son varios tokens; «de» es uno solo. Todo lo que le envías se convierte en esa unidad antes de que el modelo empiece a pensar.

Eso importa por dos motivos distintos, y conviene no confundirlos. Si pagas por API, cada token de entrada se factura en todas y cada una de las llamadas: un prompt de sistema inflado multiplica su desperdicio por el volumen de tu producto. Si usas un plan gratuito, no pagas nada, pero cada token consume ventana de contexto y acerca el momento en que la conversación se corta o el modelo empieza a olvidar el principio.

En los dos casos el token es presupuesto. Se paga en euros o se paga en espacio.

Cuidado: los caracteres no son tokens

Es el error más común al recortar a mano. Sustituir «ya que» por «porque» no ahorra ni un carácter (las dos tienen seis) y sin embargo sí ahorra un token: «ya que» son dos palabras y «porque» una sola. Al revés también pasa: acortar una palabra larga puede no cambiar nada si el tokenizador ya la partía por ahí.

Por eso una cuenta de caracteres es una aproximación y no una medida. La única cifra fiable es la que da el propio tokenizador del modelo que vas a usar, y varía entre proveedores: el mismo texto no cuesta lo mismo en tokens según a quién se lo mandes.

Lo que no se debe tocar nunca

Recortar un prompt tiene un límite claro, y cruzarlo no ahorra dinero: rompe la llamada. Hay cuatro clases de contenido que deben salir intactas de cualquier optimización, porque su valor está en ser exactamente lo que son:

• ·Bloques de código y código en línea. Un comentario dentro de una función no es una cortesía: es parte de lo que le estás pidiendo interpretar.
• ·URLs. Quitar una palabra de una dirección la convierte en otra dirección, o en ninguna.
• ·Variables de plantilla como {{nombre_usuario}}. Si tu sistema las sustituye después, alterarlas rompe el reemplazo en silencio.
• ·Etiquetas estructurales tipo XML. Muchos modelos se apoyan en ellas para delimitar secciones; cerrarlas mal cambia cómo se interpreta el resto.

¿A mano o automatizado?

A mano funciona una vez. Si tienes un prompt de sistema fijo, lo repasas, lo acortas y lo dejas escrito: no necesitas ninguna herramienta para eso, y de hecho es lo que recomendamos.

El problema aparece cuando el texto cambia en cada llamada: lo que escribe el usuario, los documentos que recuperas de una base, el historial que arrastras. Ahí no puedes anticipar qué va a llegar, así que la única opción es aplicar las reglas en el momento.

Y hay un tercer caso: cuando somos varios. Una persona acorta a su manera y otra a la suya, y a los tres meses cada prompt del equipo tiene un estilo distinto. Un diccionario compartido convierte el criterio en algo que no depende de quién escriba.

Cuándo compensa pasar el prompt por un modelo

Recortar a mano lo que sobra no cuesta nada y siempre sale a cuenta: si la única meta es que el prompt ocupe menos, un modelo no hace falta.

La cuenta cambia cuando el problema no es el tamaño sino la ambigüedad. Ahí no hay regla que valga: decidir que «resume esto» necesita saber para quién, con qué extensión y qué hacer con los datos que faltan es exactamente el tipo de juicio que solo hace un modelo. Gastar una décima de céntimo en eso compensa si evita tres mensajes corrigiendo la respuesta.

Lo que hay que exigirle a ese modelo es que no rellene los huecos por su cuenta. Si el original no decía la extensión y el resultado trae «máximo 200 palabras», la herramienta ha decidido por ti y ni te has enterado. Lo correcto es que deje el hueco marcado y lo rellenes tú.

Y conviene tenerlo presente: un modelo da una versión distinta cada vez. Para algo que corre desatendido en producción, eso es un inconveniente real, y merece la pena fijar el prompt una vez y reutilizarlo en lugar de reoptimizarlo en cada ejecución.