El mes pasado lancé un cambio en el pipeline del que estaba genuinamente orgulloso. Un prompt reescrito. Un paso de revisión con contexto completo. Una rúbrica detallada para detectar repeticiones y garantizar variedad estructural entre segmentos.
Lo desplegué. Lo observé durante seis semanas. Me convencí de que funcionaba.
Luego construí un framework de evaluación. Lo ejecuté sobre 40 episodios reales en producción en 7 idiomas. Y descubrí que el paso de revisión —aquel que había diseñado con tanto cuidado— estaba empeorando los guiones de forma medible.
No neutral. Peor.
El diálogo por segmento obtuvo 3,34 sobre 5. El esquema obtuvo 3,01. ¿Y el guion final, después del paso de revisión? 2,91.
El paso diseñado para mejorar los guiones reducía la calidad en más de un 12 %.
Este cambio —de «creo que funciona» a «sé que no funciona»— comenzó hace unas semanas. Estaba viendo el curso de IA Agentic de Andrew Ng en DeepLearning.AI, donde subraya algo que suena obvio pero no lo es: las evaluaciones y las trazas son la base de cualquier sistema agéntico. Sin ellas, depuras a oscuras. Con ellas, sabes exactamente qué eslabón de la cadena se rompió.
Llevaba meses haciendo verificaciones ad hoc de calidad de guiones —métricas estructurales como ratios de turnos y equilibrio entre locutores, además de un juez LLM comparando variantes de prompts A/B. Detectaban regresiones evidentes. Pero no eran exhaustivas. Cubrían una etapa (diálogo), un idioma a la vez, y estaban diseñadas para pruebas A/B de prompts, no para auditorías de calidad de todo el pipeline.
El argumento de Andrew sobre las trazas me golpeó fuerte. Mi pipeline tiene cinco llamadas LLM importantes por episodio —investigación, esquema, diálogo por segmento, intro/outro y revisión— más un paso de TTS de ElevenLabs. Tenía métricas de calidad para una de ellas. A las otras cuatro les confiaba solo por intuición.
Así que construí un sistema de evaluación de verdad. Completo. Multidimensional. Reejecutable. Esto es lo que encontró, los seis arreglos que lancé en un día y lo que realmente mejoró.
La línea base: tres números que lo cambiaron todo
Evalué 40 episodios completos de mi base de datos de producción —cubriendo los 7 idiomas (en, vi, ja, ko, es, zh, fr) y 10 estilos de podcast— con tres rúbricas de cinco dimensiones cada una. Un juez LLM (GPT-5.6-terra) calificó cada etapa.
| Stage | Score | Worst Dimension |
|---|---|---|
| Dialogue (per-segment) | 3,34 | Factual Grounding: 2,17 |
| Outline (research + structure) | 3,01 | Citation Credibility: 1,28 |
| Final Script (post-review) | 2,91 | Publishability: 1,95 |
Tres cosas saltaron a la vista de inmediato:
1. El paso de revisión degradaba los guiones en 0,43. El diálogo obtuvo 3,34. ¿Después de la revisión? 2,91. El paso diseñado para mejorar la calidad la estaba eliminando.
2. Todas las URLs de citas eran redirecciones opacas. Cada «URL de fuente» en cada esquema apuntaba a vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQ.... Funcionan para un humano que hace clic, pero para un revisor automatizado parecen completamente inventadas. 344 hechos tenían URLs de fuente. Cero tenían resolved_url —un campo que ni siquiera existía todavía.
3. La publicabilidad fue la dimensión más baja de todo el pipeline (1,95). Podcasters reales, determinó el juez de evaluación, no publicarían estos guiones bajo su propio nombre. Patrones de IA detectables: aperturas de segmento idénticas, transiciones genéricas, falta de personalidad del presentador.
La evaluación me dio una lista priorizada de exactamente qué arreglar. Pasé el resto del día arreglándolo.
Los seis arreglos (y su impacto medido)
Arreglo 1: URLs de citas — del 0 % al 100 % de resolución
Antes: 0 de 344 hechos de investigación tenían una resolved_url. Cada URL parecía inventada.
Arreglo: Un resolvedor de URLs de 60 líneas que se ejecuta durante la generación del esquema, sigue la redirección de Vertex AI hasta la fuente real y almacena ambas URLs (original para cumplimiento con los Términos de Google, resuelta para todo lo demás).
def resolve_grounding_url(url: str) -> str:
if "grounding-api-redirect" not in url:
return url
response = requests.head(url, allow_redirects=True, timeout=5)
return response.url if response.url != url else url
Después: 23 de 23 hechos de investigación en los nuevos episodios de hoy tienen resolved_url poblada —URLs reales como simonwillison.net, axios.com, thinkingmachines.ai. 100 % de resolución.
Arreglo 2: Cambié el modelo de revisión (Gemini → DeepSeek)
Antes: Gemini 3.5 Flash ejecutaba el paso de revisión. Hacía ediciones ligeras y conservadoras: cambiaba «¡Exacto!» por «¡Sin duda!» pero en su mayoría preservaba el texto original. Añadía relleno que aplanaba el diálogo. La densidad de etiquetas de audio bajó. La ratio type-token bajó. El número de turnos se infló.
Arreglo: Cambié el paso de revisión a DeepSeek v4-pro (384K de salida máxima, limitado a 96K). Hice el proveedor configurable:
provider = get_provider("review") # reads REVIEW_PROVIDER env var
response = provider.generate(
prompt=prompt, temperature=0.0,
max_output_tokens=96000,
)
Verificación: Desplegado en producción. Un episodio vietnamita de noticias tecnológicas pasó por el pipeline completo con revisión de DeepSeek — 10,3K → 11,6K tokens, completado en 121 segundos, 0 pasadas de ajuste necesarias. Un segundo episodio (inglés) procesó 7,9K → 17K tokens en 203 segundos. La clave de API de DeepSeek reside en Google Cloud Secret Manager y se inyecta automáticamente en el despliegue a través de service.yaml.
Arreglo 3: Autocrítica del esquema (+0,50 de mejora)
Antes: Los esquemas iban directamente de Gemini al usuario sin ningún control de calidad interno. Puntuación media: 3,01.
Arreglo: Añadí un paso automatizado de crítica. DeepSeek v4-pro evalúa el esquema con una rúbrica de 6 dimensiones (las 5 dimensiones del esquema más el número de segmentos), devuelve puntuaciones + feedback específico y almacena la crítica en los metadatos del podcast.
Luego realicé un experimento controlado: tomar 6 episodios cuyos esquemas puntuaron por debajo de 3,0, ejecutar la crítica de DeepSeek, devolver el feedback a Gemini como instrucciones de regeneración y volver a puntuar.
Después: +0,50 de mejora global en los 6 episodios.
| Dimension | Before | After | Delta |
|---|---|---|---|
| Content Boundaries | 3,33 | 4,17 | +0,83 |
| Research Depth | 2,67 | 3,17 | +0,50 |
| Citation Credibility | 1,00 | 1,50 | +0,50 |
| Structural Logic | 3,67 | 4,17 | +0,50 |
| Audience Fit | 2,17 | 2,33 | +0,17 |
El peor episodio pasó de 1,80 a 3,20 (+1,40). Solo 1 de 6 empeoró. La crítica ahora está activada por defecto en producción —cada nuevo esquema pasa este control de calidad antes de que el usuario lo vea.
Arreglo 4: Los esquemas de un solo segmento ahora fallan radicalmente
Antes: La evaluación mostró episodios con un solo segmento y cero hechos de investigación puntuando tan bajo como 2,07. Eran casos de fallo que el pipeline no trataba como fallos.
Arreglo: Si el generador de esquemas produce menos de 3 segmentos válidos después de un intento de recuperación, el podcast se marca como FAILED. Se acabaron los esquemas de un solo segmento que llegaban a los usuarios. En el siguiente intento de creación, el crédito del usuario se libera para reintentar.
Arreglo 5: Reglas de localización para chino
Antes: Los episodios en chino puntuaron 2,88 —la puntuación más baja de los 7 idiomas. Artefactos de traducción (modismos ingleses traducidos literalmente), aperturas de segmento idénticas, nombres de presentadores por defecto en inglés (Alex/Maya) en lugar de nombres chinos (明辉/晓雯).
Arreglo: Escribí reglas de diálogo específicas para chino: patrones conversacionales nativos (construcciones 不是...而是...), partículas finales de oración adecuadas (吧/啊/呢), directrices anti-traducción (nunca traducir «medical miracle» literalmente), metáforas futbolísticas chinas para episodios del Mundial y perfiles de presentadores específicos para el idioma con personalidades diferenciadas.
La plantilla de diálogo en chino pasó de reutilizar los valores por defecto en inglés a tener su propia guía de 80 líneas que cubre patrones conversacionales, frases para expresar desacuerdo y encuadres específicos para cada audiencia en cada estilo de podcast.
Arreglo 6: Nombres de presentadores por defecto para idiomas distintos del inglés
Antes: Varios episodios en idiomas distintos del inglés tenían presentadores llamados Alex y Maya. Los perfiles de presentadores específicos por idioma existían, pero la ruta de respaldo en el generador de esquemas estaba codificada con los valores por defecto en inglés.
Arreglo: Seguí el arreglo a través del pipeline de resolución de perfiles con conciencia de idioma. Los episodios recientes en producción ahora usan 翔太/健一 (ja), Mạnh/Nga (vi), Hugo/Camille (fr), 明辉/晓雯 (zh). Los commits de julio ya habían arreglado la edge function y el flujo de creación —el respaldo restante estaba en el propio generador de esquemas.
El framework de evaluación (reutilizable)
El framework que encontró todo esto consta de ~500 líneas de Python, tres archivos de rúbrica (5 dimensiones cada uno), un juez compartido GPT-5.6-terra y un orquestador:
docs/pipeline/evals/
├── run.py # Orchestrator: extract → judge → report
├── judge.py # Shared LLM judge (rate with rubric)
├── rubric_outline.py # Stage 1: 5 dimensions, 1-5 scale
├── rubric_dialogue.py # Stage 2: 5 dimensions, 1-5 scale
├── rubric_final_script.py # Stage 3: 5 dimensions, 1-5 scale
├── dataset_40.json # Extracted production data
├── scores.json # Machine-readable scores
└── report.md # Auto-generated report
También construí una capa de experimentos para comparaciones A/B:
docs/pipeline/evals/experiments/
├── review_ab.py # Compare two review models
├── outline_critique_ab.py # Critique → regenerate → compare
├── shared.py # Score comparator, report generator
└── results/ # Archived by date
Ejecuta python docs/pipeline/evals/run.py --full después de cualquier cambio en el pipeline y obtén un informe en ~8 minutos. Ejecuta experiments/review_ab.py --episodes 10 para comparar modelos. Los resultados se archivan por fecha para seguimiento de tendencias —¿quieres saber si la calidad mejoró este mes respecto al anterior? Compara las puntuaciones.
La evaluación completa de 40 episodios cuesta alrededor de $1-2 en llamadas a la API. Los experimentos cuestan menos. Por la señal que obtienes a cambio —una lista priorizada de exactamente qué etapas y dimensiones del pipeline necesitan atención— es la herramienta de depuración más barata que he construido.
Lo que sigue estando roto
El experimento A/B de revisión de DeepSeek necesita el prompt de producción completo. El script del experimento usaba un prompt simplificado de 15 líneas. La revisión en producción usa un prompt de 80 líneas con reglas anti-repetición, cuotas de frases características, barreras editoriales y política de duración. Con el prompt simplificado, DeepSeek mostró resultados esencialmente neutros (-0,04). Con el prompt completo en producción, el pipeline se completa con éxito en inglés y vietnamita. Necesito actualizar el experimento para que refleje producción y volver a ejecutarlo.
La localización al chino necesita validación. Las reglas parecen correctas sobre el papel, los perfiles de presentadores están escritos, las guías de diálogo están en su sitio. Pero aún no he ejecutado la evaluación en nuevos episodios en chino para confirmar que la puntuación subió desde 2,88. Es una prioridad para esta semana.
Necesito volver a ejecutar la evaluación completa de 40 episodios con episodios nuevos. Los seis arreglos están desplegados. El siguiente paso es extraer 40 episodios generados después de estos cambios, pasarlos por las mismas evaluaciones y compararlos con la línea base histórica. Si la puntuación del guion final sube de 2,91 a más de 3,0 y la credibilidad de las citas pasa de 1,28 a algo razonable, sabré que los cambios funcionaron de principio a fin.
La auditoría de pipeline de tres preguntas
Después de esta experiencia, ahora audito cada cambio en el pipeline con tres preguntas:
1. ¿Hay un control de calidad entre cada paso? Mi esquema iba directamente de Gemini al usuario. Añadir el paso de crítica atrapó los peores esquemas antes de que nadie los viera. Cada paso del pipeline necesita un control de calidad —evaluación automatizada con LLM según criterios explícitos.
2. ¿Cada paso realmente mejora la calidad cuando se mide? Ejecutarlo y asumir que ayuda no es suficiente. Necesitas puntuaciones literales de antes y después sobre el mismo contenido. Mi paso de revisión degradó guiones durante seis semanas antes de que lo midiera. Mide primero, no des nada por sentado.
3. ¿Puedo saber qué dimensión se rompió? «La calidad es mala» no es procesable. «La credibilidad de las citas es 1,28 porque el 100 % de las URLs son redirecciones opacas» sí lo es. Una rúbrica multidimensional por etapa te dice exactamente dónde mirar. Pasé horas investigando mi paso de revisión antes de la evaluación. Con la evaluación, tardé segundos —los números señalaban directamente a la publicabilidad y al modelo de revisión.
Preguntas frecuentes
¿No sale caro ejecutar evaluaciones con LLM?
La evaluación completa de 40 episodios cuesta alrededor de $1-2 en llamadas a la API (GPT-5.6-terra, ~420K tokens totales). Los experimentos A/B cuestan aún menos. Por la señal que obtienes a cambio —una lista priorizada de exactamente qué etapas del pipeline necesitan atención— es la herramienta de depuración más barata que he construido, y más barata que los créditos que los usuarios desperdiciarían en episodios rotos.
¿Por qué 5 dimensiones por etapa? ¿Por qué no solo «calidad general»?
«Calidad general» te dice que algo va mal. No te dice qué. Cuando vi Credibilidad de Citas en 1,28, supe inmediatamente que las URLs estaban rotas. Cuando vi Publicabilidad en 1,95, supe que los rasgos de IA eran detectables. Cinco dimensiones te dan un diagnóstico diferencial. Una dimensión te da un termómetro de fiebre.
¿Cómo mantienes consistente al juez LLM?
Mismo modelo (GPT-5.6-terra), misma temperatura (0,0), mismo esfuerzo de razonamiento (medium), mismos prompts de rúbrica siempre. Las puntuaciones se archivan con marcas de tiempo para que puedas comparar entre fechas. Cambiar de juez cambia la línea base —elige uno y mantente con él.
¿Qué pasa cuando el propio juez se equivoca?
La rúbrica incluye justificaciones obligatorias para cada puntuación —el juez debe citar evidencia concreta del contenido. También hice una revisión cualitativa manual de 10 episodios en los 7 idiomas para calibrar al juez. Las puntuaciones del LLM coincidieron estrechamente con mi juicio humano. Para dimensiones críticas donde el LLM podría ser poco fiable (como «publicabilidad», que requiere juicio cultural), las comprobaciones humanas puntuales son esenciales.
Construyo DIALOGUE, una plataforma de podcasts de IA, en solitario durante mis tardes y fines de semana. Escribo sobre lo que aprendo en el camino.
Si has construido un sistema de evaluación para tu propio pipeline de LLM, me da curiosidad: ¿cómo mides la calidad y qué descubriste que te sorprendió?
Eso es todo de mi parte por ahora.
Un abrazo, Chandler