La ingeniería de prompts es prueba y error para la mayoría de los equipos. Usted ajusta un prompt del sistema, lo ejecuta unas veces, decide que “se siente mejor” y sigue adelante. No hay historial de versiones. No hay forma de comparar la iteración 14 contra la iteración 11. No hay ciclo de retroalimentación sistemático que conecte la calidad en producción con los cambios de prompts.
Construimos el Prompt Engineering Studio para solucionar esto. Es un panel colapsable integrado directamente en el editor de recetas — no una página separada, no una herramienta diferente. Cinco pestañas se sientan justo al lado del área de texto del prompt: Presupuesto de tokens, Variables, Versiones, Few-Shot y Optimizador. La iteración ocurre en contexto, no en un flujo de trabajo desconectado.
Rastreo de versiones y comparación de diferencias
Cada cambio de prompt crea una versión en una subcolección de Firestore. Cada versión almacena:
| Campo | Descripción |
|---|---|
| Número de versión | Entero auto-incrementado |
| Texto de plantilla | El texto completo de la plantilla de prompt en ese momento |
| Puntuación de similitud | 0-100 vía distancia de Levenshtein normalizada contra la versión anterior |
| Autor | Quién hizo el cambio |
| Registro de cambios | Descripción libre de qué cambió y por qué |
Las métricas de calidad se rastrean por versión: ejecuciones totales, conteo de éxitos, conteo de pulgar arriba, conteo de pulgar abajo, ratio de retroalimentación y uso promedio de tokens. Estas métricas se cachean en Redis con un TTL de 5 minutos para mantener la UI responsiva sin bombardear Firestore cada vez que se abre el panel.
El visor de diferencias muestra comparaciones línea por línea entre dos versiones cualesquiera. Las adiciones se renderizan en verde, las eliminaciones en rojo, con estadísticas que resumen cuántas líneas cambiaron. Las puntuaciones de similitud están codificadas por color: verde para >= 90% de similitud (ajustes menores), ámbar para >= 50% (reescrituras moderadas) y rojo para < 50% (cambios sustanciales).
La reversión no es destructiva. Restaurar una versión anterior crea una nueva versión con el contenido antiguo — nunca sobrescribe el historial. La versión 15 podría ser idéntica a la versión 8, y eso está bien. La cadena completa de cambios siempre se preserva.
Visualización en vivo del presupuesto de tokens
La pestaña Presupuesto de tokens renderiza un gráfico de barras en tiempo real mostrando la utilización de la ventana de contexto mientras escribe. Cinco secciones etiquetadas desglosan a dónde van sus tokens:
| Sección | Presupuesto |
|---|---|
| Sistema | Sobrecarga de 200 tokens (encuadre del prompt del sistema) |
| Glosario | Tope de 500 tokens |
| Few-Shot | Tope de 2,000 tokens |
| Contexto RAG | Tope de 4,000 tokens |
| Prompt del usuario | Estimado a partir de longitud de texto / 4 |
La visualización es consciente del modelo. Seleccione Claude y la barra escala a 200K tokens. Cambie a GPT-4o y se reescala a 128K. Cambie a Gemini y se extiende a 1M. Las proporciones cambian en consecuencia, haciendo inmediatamente obvio cuando un prompt que cabe cómodamente en la ventana de contexto de un modelo está peligrosamente ajustado en otro.
Tres niveles de advertencia se activan automáticamente:
- >80% de utilización — advertencia ámbar, sugiriendo recortar contexto o ejemplos few-shot
- >90% de utilización — advertencia roja, indicando alto riesgo de truncamiento
- <1,000 tokens restantes para salida — alerta explícita de que el modelo no tendrá suficiente espacio para generar una respuesta útil
Las actualizaciones tienen un debounce de 500ms por pulsación de tecla, así que el gráfico se mantiene responsivo sin recalcular en cada carácter.
Inspector de variables
La pestaña Variables detecta referencias {{variable}} y {{fragment:name}} en tiempo real mientras edita la plantilla del prompt. Cada variable detectada se cruza contra el inputSchema de la receta y se le asigna uno de cuatro estados:
- Coincidente (verde) — La variable existe tanto en la plantilla como en el esquema. Todo está conectado correctamente.
- Huérfana (ámbar) — La variable aparece en la plantilla pero no está definida en el esquema. El prompt referencia algo que no tendrá un valor en tiempo de ejecución.
- Sin usar (rojo) — La variable está definida en el esquema pero nunca se referencia en la plantilla. Está recolectando entrada que no va a ningún lado.
- Fragmento (azul) — Una referencia
{{fragment:name}}a un fragmento de prompt reutilizable.
Para variables coincidentes, el inspector obtiene valores de ejemplo de datos históricos de ejecución, para que pueda ver cómo se ven las entradas reales sin salir del editor. Esto detecta una clase común de bugs: el esquema define un campo como companyName pero la plantilla referencia {{company_name}}.
Gestión de ejemplos Few-Shot
La pestaña Few-Shot le permite fijar ejecuciones exitosas como ejemplos curados. Cada ejemplo fijado tiene un campo de salida editable — puede corregir o refinar la respuesta original del modelo para crear una demostración de estándar de oro.
La puntuación de calidad determina qué ejemplos aparecen en tiempo de ejecución. Cada ejemplo comienza con una puntuación base de 50. Un pulgar arriba agrega 40 puntos. Un pulgar abajo resta 30 puntos. Las puntuaciones de jueces de evaluaciones bakeoff también se ponderan.
En tiempo de ejecución, el sistema soporta tres estrategias de recuperación:
| Estrategia | Cómo funciona |
|---|---|
| Basada en retroalimentación | Selecciona ejecuciones con pulgar arriba, diversificadas para evitar ejemplos repetitivos |
| Recientes | Selecciona las ejecuciones exitosas más recientes |
| Similares | Usa similitud coseno vía embeddings para encontrar ejecuciones más cercanas a la entrada actual |
Los ejemplos curados fijados siempre tienen prioridad sobre los recuperados dinámicamente. Se inyectan primero, y el presupuesto restante se llena con ejemplos seleccionados por estrategia.
Todos los ejemplos few-shot se inyectan en el prompt como bloques XML <few_shot_examples>, restringidos a un presupuesto de 2,000 tokens. Si sus ejemplos curados exceden el presupuesto, el sistema trunca desde los ejemplos de menor puntuación primero.
Optimizador potenciado por IA
La pestaña Optimizador proporciona tres niveles de mejora de prompts, escalando de manual a completamente automatizado.
Nivel 1: Análisis activado por el usuario
Haga clic en “Analizar” y el optimizador obtiene las últimas 50 ejecuciones exitosas de la receta, las particiona en cubetas de pulgar arriba y pulgar abajo, y envía la distribución a Claude Sonnet 4.6 para análisis estructurado. El modelo devuelve una lista de sugerencias, cada una conteniendo:
| Campo | Descripción |
|---|---|
| Sección | Qué parte del prompt cambiar |
| Texto original | El texto actual del prompt en esa sección |
| Texto sugerido | El reemplazo propuesto |
| Justificación | Por qué este cambio debería mejorar la calidad de salida |
| Confianza | Puntuación 0-100 indicando la certeza del modelo |
Usted revisa cada sugerencia y elige Aplicar (reemplazo en línea en el editor) o Prueba A/B (crea un bakeoff comparando el prompt actual contra la sugerencia en producción).
Nivel 2: Sugerencias auto-activadas
Cuando una receta acumula 5 o más calificaciones de pulgar abajo, el optimizador genera automáticamente 1-3 sugerencias de mejora sin intervención del usuario. Estas aparecen como una insignia de notificación en la pestaña Optimizador.
Este nivel está limitado a una vez por hora por receta para prevenir fatiga de sugerencias. La intención es un empujón suave — “sus usuarios no están contentos con la salida de esta receta, aquí hay algunas ideas” — no una avalancha de cambios.
Nivel 3: Refinamiento por deriva de calidad
Este nivel es activado por el sistema Quality Guard cuando detecta deriva en la calidad de salida de una receta a lo largo del tiempo. El optimizador analiza las 5 mejores y 5 peores ejecuciones de la ventana de deriva, identifica patrones en lo que se está degradando y genera cambios de prompt dirigidos.
El Nivel 3 también puede auto-activar mini-bakeoffs — creando una comparación A/B estructurada entre el prompt actual y la revisión sugerida, enrutada a tráfico de producción en vivo. Esto cierra el ciclo completamente: la calidad cae, el sistema propone una corrección, la prueba contra entradas reales y reporta los resultados.
Los límites mantienen esto conservador: las sugerencias de refinamiento están limitadas a una vez cada 24 horas, y los bakeoffs auto-activados a una vez cada 7 días. La optimización de prompts debería ser deliberada, no un ciclo de retroalimentación descontrolado.
Por qué vive en el editor
El Studio es un panel, no una página. Esta es una decisión de diseño deliberada. La ingeniería de prompts es iterativa — cambia una línea, verifica el presupuesto de tokens, echa un vistazo a la diferencia, ejecuta una prueba. Cambiar de contexto entre herramientas separadas rompe el flujo.
Con el Studio colapsado, tiene un editor limpio. Con él expandido, cada señal que necesita — utilización de tokens, salud de variables, historial de versiones, ejemplos few-shot, sugerencias de optimización — está a una pestaña de distancia. Sin navegación, sin pantallas de carga, sin contexto perdido.
Disponibilidad
El Prompt Engineering Studio está disponible en planes Pro y superiores. El rastreo de versiones, presupuesto de tokens e inspección de variables están incluidos en Pro. La gestión de few-shot y el optimizador potenciado por IA (los tres niveles) están disponibles en Pro y Enterprise.
Explore todas las funcionalidades en la página de funcionalidades o comience una prueba gratuita.