La situación típica de la guía es exacta: alguien cambia el prompt el viernes, los usuarios se quejan el lunes, y el desarrollador no recuerda qué cambió ni puede revertirlo sin bucear en el historial de Git. Hay dos costes distintos ahí, y conviene separarlos.
prompt_obj = langfuse.get_prompt("chiste-bot")
mensajes = prompt_obj.compile(tema=tema)
resp = client.chat.completions.create(
model=prompt_obj.config["model"],
messages=[{"role": "user", "content": mensajes}],
temperature=prompt_obj.config["temperature"],
langfuse_prompt=prompt_obj, # <- el eslabón que cierra el círculo
)langfuse_prompt=prompt_obj todo funciona igual y la traza queda
huérfana: sabrás qué se respondió, no con qué
versión. Y ése era el punto.
Dos detalles que la guía pasa por encima. Ese argumento solo lo entiende el
cliente instrumentado (langfuse.openai); con el cliente estándar es
un argumento desconocido. Y compile() de un prompt de texto devuelve una
cadena, no una lista de mensajes, aunque en el código de la
guía la variable se llame mensajes_compilados.
langfuse.create_prompt(
name="chiste-bot",
prompt="Cuenta un chiste muy corto sobre {{tema}}.",
config={"model": "gpt-3.5-turbo", "temperature": 1},
)Con eso, cambiar de modelo o bajar la temperatura es una edición en la web. El código define cuándo se llama al modelo; el registro define qué se le dice y con qué parámetros.
El límite razonable: lógica fuera del template. Un if/else
dentro del prompt convierte el registro en una segunda base de código sin tests.
La lógica en Python, el texto en el registro.
| Mecanismo | Qué hace | Para qué sirve |
|---|---|---|
| Versión | Cada create_prompt con el mismo nombre crea una nueva | Historial y reversión |
Etiqueta (production, staging) | Apunta a una versión concreta | Desplegar sin tocar código ni número de versión |
| Caché | El SDK guarda el prompt localmente un rato | Que get_prompt no sea una llamada de red por petición |
La caché es la que sorprende en desarrollo: cambias el prompt en la web, reejecutas y sale el viejo. No está roto, está cacheado. En producción eso es exactamente lo que quieres.
La caché. Un comentario del código de la guía dice "en prod el TTL es 60s", y la pista 4 del ejercicio de prompts lo repite como "TTL de 60s por defecto". Es un número concreto sin fuente. Compruébalo en la documentación y, mejor, mídelo: se mide en dos minutos. Mientras no lo midas, no lo cites.
La contradicción con las etiquetas. Otro comentario dice que
"get_prompt busca la última versión si no se especifica". Si
eso es cierto, etiquetar como production no protege nada: cualquier
borrador nuevo pasa a ser el último y entra en producción solo. O el
comportamiento por defecto es "la última etiquetada como production"
y el comentario está mal, o el consejo de "etiqueta para despliegues seguros"
está incompleto y falta decir que hay que pedir la etiqueta explícitamente
al recuperar. ¿Cuál de las dos? Averigúalo antes de montar un
despliegue encima: la diferencia entre las dos lecturas es que alguien publique sin
querer un borrador en producción.
Crea un prompt de usar y tirar, recupéralo desde un script en bucle e imprime
prompt_obj.version en cada vuelta. Con el script corriendo, edita el prompt
en la web.
Cronometra cuántos segundos tardan en cambiar el número de versión que imprime tu bucle. Ese número es tu TTL real, medido por ti. Apúntalo junto a lo que afirma la guía: es la diferencia entre una cifra repetida y una cifra comprobada.