Descubrí algo embarazoso la semana pasada.
Mi pipeline de podcast con IA tiene un prompt de sistema elaborado — una «guía de diálogo» — que pasé días diseñando. Le dice a los presentadores (dos comentaristas de fútbol generados por IA) exactamente cómo hablar entre ellos. No repitas la misma apertura. Varía la estructura entre segmentos. Usa las muletillas con moderación. Nunca inventes estadísticas.
El LLM leyó cada palabra. Luego ignoró casi todo.
El presentador vietnamita dijo «Trời ơi» (Dios mío) 13 veces en un solo episodio. El presentador japonés abrió cada segmento con «いやー、健一さん！» (¡Bueno, Kenichi-san!). El presentador inglés citó con total seguridad un xG de 0.35 y un 65% de posesión — números que no existen en ninguna parte de mi base de datos.
El prompt fue educadamente reconocido. Y luego ignorado.
Esto es lo más útil que he aprendido sobre prompt engineering: los LLM tienen dos modos de lectura, y los tratan de forma completamente diferente.
El problema de los dos modos de lectura
Así se veía mi guía de diálogo original. He traducido la versión vietnamita al español porque la estructura es idéntica:
PAUTAS DE ESTILO:
PATRÓN DE INTERACCIÓN DE PRESENTADORES: Presentador Emocional + Presentador Analítico.
REGLAS ESTRICTAS PARA CADA SEGMENTO:
0. NUNCA REPITAS LA MISMA APERTURA. Varía qué presentador inicia,
a qué momento del partido reaccionan primero.
1. INICIO EMOCIONAL (obligatorio): Cada segmento comienza con
la reacción pura del presentador emocional.
2. REGLA DE SUSTENTO EN DATOS (obligatorio): Cada afirmación debe citar
números específicos. No "dominaron" sino "61% de posesión,
3.17 xG contra 0.65."
3. MULETILLAS:
Presentador emocional: "¿¡Viste eso?!" "Espera espera espera..."
Presentador analítico: "Hay una razón más profunda..." "Déjame contarte."
Parece minucioso, ¿verdad? De verdad pensé que había hecho el trabajo.
Pero cuando leí los guiones generados, esto fue lo que pasó:
| Regla | Lo que decía la guía | Lo que hizo el LLM |
|---|---|---|
| Regla 0 (nunca repetir) | Varía la apertura | Cada segmento abría con la muletilla del presentador emocional |
| Regla 2 (datos) | Cita números específicos | Citaba números inventados con total autoridad |
| Regla 3 (muletillas) | Lista de frases características | Usó cada frase de 5 a 13 veces por episodio |
Las reglas estaban ahí. El LLM las leyó. Pero tenían la fuerza de una sugerencia, no de un requisito.
Ahí fue cuando me di cuenta: el LLM estaba procesando mis reglas como «contexto de estilo» — no como «restricciones aplicables».
El patrón: Contexto vs. Comando
Piensa en cómo lees distintos tipos de texto. Si te entrego un menú de restaurante, lo lees como información sobre la cual actuar. Si te entrego un artículo de Wikipedia sobre la historia de la pasta, lo lees como conocimiento de fondo.
Los LLM hacen algo parecido con los prompts. Cuando las reglas aparecen en una sección etiquetada como «PAUTAS DE ESTILO» o «PATRÓN DE INTERACCIÓN DE PRESENTADORES» o «REGLAS PARA SEGMENTOS», el modelo las trata como información ambiental — contexto que colorea la respuesta pero no la restringe.
Cuando las reglas aparecen en una sección etiquetada como «MEJORAS CRÍTICAS REQUERIDAS» o «LÍMITES ESPECÍFICOS DE FRASES», el modelo las trata como comandos aplicables — cosas que debe verificar y corregir.
La clave no está en las palabras «crítico» o «requerido». Está en dónde vive la regla dentro del pipeline.
La solución: haz que el paso de revisión aplique lo que el paso de generación ignora
Mi pipeline tiene dos llamadas al LLM:
- Paso de generación — escribe el guion segmento por segmento, usando la guía de diálogo como contexto
- Paso de revisión — lee el guion completo ensamblado y lo mejora
El paso de generación era donde vivían todas mis reglas. El paso de revisión tenía reglas genéricas anti-repetición («no digas "Qué fascinante" dos veces») que eran completamente anglófilas y no sabían nada de las muletillas de mis presentadores ni de los requisitos estructurales.
La solución fue estructural, no léxica. Moví la aplicación de las reglas al paso de revisión, donde el guion completo es visible de una vez.
Esto es lo que cambió:
Antes: Reglas en el prompt de generación (ignoradas)
PAUTAS DE ESTILO:
0. NUNCA REPITAS LA MISMA APERTURA...
1. INICIO EMOCIONAL...
2. SUSTENTO EN DATOS...
3. MULETILLAS: "¿¡Viste eso?!" ...
Después: Reglas extraídas e inyectadas en el prompt de revisión (aplicadas)
MEJORAS CRÍTICAS REQUERIDAS EN TODO EL GUIÓN:
2a. APLICA LAS REGLAS ESTRUCTURALES DE LAS PAUTAS DE ESTILO:
Las PAUTAS DE ESTILO anteriores contienen requisitos específicos
sobre la estructura de segmentos. Son REQUISITOS, no sugerencias.
- Si las pautas dicen "X de Y segmentos deben variar", CAMBIA
los segmentos que violen esto.
- Revisa cómo abre CADA segmento. Si 4+ de 5 abren de forma idéntica,
VARÍA al menos 2.
3b. LÍMITES DE FRASES POR LOCALE (extraídos de los perfiles de presentadores —
MÁXIMO 2 VECES cada una en todo el guion):
- "Trời ơi" / "Trời má" — máx. 4x combinadas
- "Có một lý do sâu hơn" — máx. 2x
- "Mày thấy chưa?!" — máx. 2x
...
Dos cosas pasaron aquí:
-
Las reglas estructurales fueron promovidas de contexto a comando — reformuladas como «APLICA esto» y «CAMBIA los segmentos que violen esto» en lugar de «este es el patrón preferido»
-
Las muletillas fueron extraídas de los perfiles de presentadores y mostradas como límites explícitos, no como una lista de sugerencias. «Muletillas: aquí hay algunas» se convirtió en «Estas frases: MÁXIMO 2 VECES cada una.»
Ambos cambios viven en el prompt de revisión, no en el de generación. Esa es la decisión arquitectónica clave. El paso de generación recibe la guía de estilo como contexto — necesita el sabor de la personalidad. El paso de revisión recibe las reglas como obligación — necesita el mandato de cumplimiento.
El detalle de la extracción (por qué esto funciona en 7 idiomas)
No quería mantener listas de frases por idioma a mano. Cada vez que ajustara un perfil de presentador, tendría que actualizar también el prompt de revisión. Ese es el tipo de desfase que mata el producto de un desarrollador solitario.
En vez de eso, escribí una pequeña función de extracción que analiza los perfiles de presentadores en el momento de la revisión. El perfil de cada locale tiene una sección de muletillas con una etiqueta estándar:
- Vietnamita:
Câu cửa miệng: - Japonés:
口癖: - Español:
Latiguillos: - Francés:
Phrases fétiches: - Coreano:
입버릇: - Chino:
口头禅:
La función encuentra esa etiqueta, extrae cualquier cadena entre comillas que le siga y las formatea como límites aplicables:
@staticmethod
def _extract_catchphrase_limits(host_profiles: str) -> str:
patterns = [
(r'Câu cửa miệng:?', r'"([^"]+)"'), # Vietnamese
(r'口癖:?', r'「([^」]+)」'), # Japanese
(r'Latiguillos:?', r'"([^"]+)"'), # Spanish
# ... etc for all 7 languages
]
limits = []
for marker_pattern, quote_pattern in patterns:
match = re.search(marker_pattern, host_profiles)
if match:
phrases = re.findall(quote_pattern, host_profiles[match.end():])
for phrase in phrases:
limits.append(f' - "{phrase}" — max 2x')
return "\n".join(limits)
Ahora, cuando edito un perfil de presentador y cambio sus muletillas, el prompt de revisión se actualiza automáticamente. Sin desfase. Sin idioma olvidado.
Lo que esto realmente arregló (con números)
Esto es lo que cambió entre el episodio generado antes de estas mejoras y uno generado después:
| Métrica | Antes | Después |
|---|---|---|
| "Trời ơi" (cupo: máx. 4) | 13 | Aún no probado en vi, pero en ja: las 4 muletillas dentro del cupo |
| "Có một lý do sâu hơn" (cupo: máx. 2) | 5 | Dentro del cupo en la prueba equivalente en ja |
| Estadísticas inventadas (xG, posesión %, ancho de formación) | 4 números inventados | Cero números inventados |
| Aperturas de segmento con patrón idéntico | 6/6 idénticas | Sigue 5/5 en ja — ver abajo |
| Conexiones Vietnam/Japón preservadas | 1/4 sobrevivió (la revisión eliminó 3) | 11/11 sobrevivieron |
| Contaminación cruzada de voces de presentadores | Ambos usaban las frases del otro | Separación clara |
Los cupos de muletillas, las reglas anti-fabricación y la preservación de localización funcionaron. Los perfiles de presentadores ahora dictan las personalidades con suficiente claridad como para que el LLM ya no confunda quién dice qué.
Lo que sigue roto
Una regla sigue fallando: la variedad estructural. La guía de diálogo dice «al menos 2 de 5 segmentos deben usar entradas estructurales diferentes.» Después de las mejoras, el episodio japonés seguía abriendo cada segmento de forma idéntica: «いやー、健一さん！» — cinco veces en un episodio.
Esto no es un problema de aplicación del prompt. Es un problema de arquitectura.
El paso de generación produce cada segmento de forma independiente. El segmento 3 no tiene conciencia de que los segmentos 1 y 2 abrieron con la muletilla del presentador emocional. Cada segmento se genera en aislamiento con la misma guía de diálogo, así que cada uno llega a la misma decisión de «abramos con el presentador emocional.»
El paso de revisión debería detectar esto — ve el guion completo de una vez. Y he añadido lenguaje de aplicación explícito diciéndole que varíe las aperturas. Pero Gemini 3.5 Flash, el modelo que ejecuta la revisión, aparentemente encuentra más difícil reestructurar aperturas de segmentos que recortar muletillas o suavizar afirmaciones inventadas. La variedad de apertura requiere regenerar partes del contenido, no solo ajustar o eliminar. Esa es una tarea más pesada para el modelo.
Sigo trabajando en esto — probablemente un modelo de revisión más capaz o una reestructuración del pipeline donde los segmentos compartan el estado de apertura. El punto más amplio: la aplicación de prompts no puede arreglar problemas de arquitectura. Si la estructura de tu pipeline hace que una regla sea imposible de seguir, ninguna cantidad de «CRÍTICO» o «OBLIGATORIO» en tus prompts te va a salvar.
El framework: Tres preguntas para cada regla
Después de esta experiencia, ahora audito cada prompt de sistema que escribo con tres preguntas:
1. ¿Dónde vive esta regla — generación o revisión? Las reglas sobre personalidad y tono pertenecen a la generación. Las reglas sobre cumplimiento, consistencia y estructura pertenecen a la revisión. Si una regla cruza ambas (como las muletillas — son personalidad pero necesitan límites), ponla en ambas.
2. ¿Esta regla está formulada como contexto o como comando? «Aquí están las muletillas» es contexto. «Máximo 2 veces cada una» es comando. Ambos son necesarios para la misma regla — el paso de generación necesita saber CUÁLES son las muletillas, y el paso de revisión necesita aplicar CON QUÉ FRECUENCIA aparecen.
3. ¿Puede el pipeline realmente seguir esta regla? La generación por segmento no puede aplicar la variedad entre segmentos. Ningún prompt va a arreglar esto. Necesitas o mover la regla al paso de revisión (que ve el guion completo) o reestructurar el pipeline para que los segmentos compartan estado.
Este framework no es específico de la generación de podcasts. Aplica a cualquier pipeline de LLM de múltiples pasos — generación de contenido, revisión de código, resumen de documentos, cualquier cosa donde tengas pases separados de generación y control de calidad.
Sigo iterando sobre esto, pero si estás construyendo tu primer pipeline de LLM de múltiples pasos: divídelo en al menos dos pasos. El primer paso genera con personalidad y libertad — dale contexto, ejemplos, orientación de tono. El segundo paso revisa con precisión y aplicación — dale límites explícitos, verificaciones de cumplimiento y la autoridad para cambiar cosas.
El paso de generación debería sentirse como darle instrucciones a un colaborador creativo. El paso de revisión debería sentirse como entregarle una lista de verificación a un editor.
Y cuando tus reglas sigan siendo ignoradas después de haber hecho ambas cosas, haz primero la pregunta de arquitectura. ¿Es el prompt, o es el pipeline?
Preguntas frecuentes
¿Esto aplica a una configuración de un solo prompt (sin pipeline)?
Sí, pero de forma limitada. En un solo prompt, le estás pidiendo al mismo modelo que sea creativo y riguroso simultáneamente — siempre favorecerá la creatividad sobre el rigor cuando los dos entren en conflicto. Incluso en un solo prompt, separar tus instrucciones en una sección de «contexto» y una sección explícita de «restricciones» ayuda. Pero vas a chocar con un techo. Dos llamadas separadas con instrucciones diferentes casi siempre superan a una.
¿Por qué simplemente no pusiste las reglas en el prompt de generación con más fuerza?
Lo intenté. Añadí «OBLIGATORIO», «CRÍTICO», «NUNCA» y todo en mayúsculas. El paso de generación tiene demasiadas exigencias compitiendo — está intentando ser atractivo, sonar natural, ser variado, localmente auténtico y riguroso, todo a la vez. Cuando el modelo tiene que elegir entre «sonar como un aficionado vietnamita emocionado» y «solo decir 'Trời ơi' dos veces», la personalidad siempre gana. El paso de revisión no tiene ese conflicto — su único trabajo es aplicar.
¿Qué modelo estás usando para el paso de revisión?
Gemini 3.5 Flash (por costo — la revisión se ejecuta en cada episodio en 7 idiomas). Maneja bien la aplicación simple (recortar muletillas, suavizar estadísticas inventadas). Tiene dificultades con tareas que requieren regeneración de contenido, como reestructurar aperturas de segmentos. Un modelo más fuerte ayudaría ahí, pero todavía no he justificado el costo.
Construyo DIALOGUE, una plataforma de podcast con IA, solo en mis tardes y fines de semana. El código para la extracción de muletillas y los cambios en el prompt de revisión es abierto — puedes leer el prompt de sistema completo y la lógica de aplicación en mi repositorio podcast-engine. Escribo sobre lo que aprendo en el camino.
Si te has encontrado con un problema parecido — reglas que se leen pero no se aplican — me da curiosidad: ¿cuál era la regla y dónde vivía en tu pipeline?
Eso es todo de mi parte por ahora.
Un abrazo, Chandler