JieGou incluye packs de inicio para nueve departamentos, cada uno con 7-10 recetas y 2-5 flujos de trabajo. Eso son aproximadamente 150 recetas y 40 flujos de trabajo. Escribir cada uno a mano, probarlo con entradas realistas, evaluar la calidad de la salida e iterar hasta que sea lo suficientemente bueno para enviar — ese es un trabajo de tiempo completo para un equipo.
Necesitábamos un mejor enfoque. Así que construimos la Fábrica de Recetas: un pipeline automatizado que genera, prueba, evalúa y promueve plantillas a escala.
El pipeline
La Fábrica de Recetas ejecuta cinco etapas:
1. Catálogo → Generar
Cada receta comienza como una especificación en el catálogo: un título, descripción, departamento objetivo, campos de entrada esperados, campos de salida esperados y criterios de calidad. El catálogo actualmente tiene ~150 especificaciones de recetas en 9 departamentos.
La etapa de generación toma cada especificación y usa un LLM para producir una receta completa: una plantilla de prompt pulida, un esquema de entrada detallado con descripciones de campos y un esquema de salida estructurado. El LLM sigue un meta-prompt que codifica nuestros estándares de calidad de recetas — instrucciones claras, nivel de detalle apropiado y mejores prácticas de esquemas.
2. Generar → Datos de prueba
Para cada receta generada, una segunda llamada al LLM produce 3-5 entradas de prueba sintéticas. Estas cubren el caso típico, casos extremos (entrada mínima, entrada inusualmente larga, entrada ambigua) y escenarios específicos del departamento. Las entradas de prueba son lo suficientemente realistas para producir salidas significativas sin requerir datos reales de clientes.
3. Datos de prueba → Ejecutar pruebas
Cada receta se ejecuta contra un LLM real usando las entradas de prueba sintéticas. Esto detecta problemas que se ven bien en la plantilla pero fallan en tiempo de ejecución: desajustes de esquema, prompts que producen salidas fuera de objetivo, plantillas que exceden los límites de contexto e instrucciones que el modelo interpreta diferente a lo previsto.
4. Ejecutar pruebas → Evaluar
Aquí es donde entra LLM-as-judge. Un LLM separado evalúa cada resultado de prueba en cinco dimensiones:
- Cumplimiento de esquema — ¿La salida coincide con el esquema esperado? ¿Están todos los campos requeridos presentes y correctamente tipados?
- Completitud — ¿La salida aborda todos los aspectos de la entrada? ¿Hay brechas o secciones faltantes?
- Accionabilidad — ¿La salida es útil? ¿Puede una persona actuar sobre ella sin trabajo adicional significativo?
- Calidad de formato — ¿La salida está bien organizada, claramente escrita y apropiadamente detallada?
- Consistencia — A través de múltiples entradas de prueba, ¿la receta produce salidas consistentemente estructuradas?
Cada dimensión recibe una puntuación de 0-100. La puntuación general es un promedio ponderado.
5. Evaluar → Promover
Las recetas que puntúan 75+ en general sin ninguna dimensión por debajo de 50 se promueven a la cuenta demo en Firestore. Las recetas que fallan se marcan para revisión manual e iteración.
Lo que LLM-as-judge nos enseñó
Construir un sistema automatizado de evaluación de calidad produjo varios conocimientos no obvios.
La especificidad del prompt importa más que la longitud. Las plantillas de recetas tempranas eran largas y detalladas. El LLM-as-judge consistentemente puntuó prompts más cortos y específicos más alto en cumplimiento de esquema y calidad de formato. Un prompt de 200 palabras que dice exactamente qué hacer supera a un prompt de 500 palabras que cubre cada caso extremo. El modelo sigue instrucciones claras mejor que instrucciones exhaustivas.
Los esquemas de salida son la palanca de calidad más importante. Las recetas con esquemas de salida detallados — descripciones de campos, restricciones enum, estructuras de objetos anidados — puntuaron significativamente más alto en completitud y consistencia. El esquema actúa como un segundo conjunto de instrucciones que restringe la salida del modelo independientemente del prompt.
Las entradas de prueba de casos extremos revelan fragilidad. El caso de prueba estándar generalmente funciona. Los casos extremos — entrada mínima, formato inusual, campos opcionales faltantes — exponen recetas que se rompen bajo condiciones del mundo real. Una receta que puntúa 90 en el caso típico pero 40 en casos extremos no está lista para producción.
Los criterios de evaluación necesitan calibración. Nuestro primer paso de puntuación LLM-as-judge fue demasiado indulgente. Las recetas puntuaban 85+ que producían salidas mediocres. Ajustamos el prompt de evaluación con ejemplos específicos de cómo se ve cada nivel de puntuación. “Accionabilidad” en 80+ significa que la salida incluye próximos pasos específicos, no solo análisis. “Calidad de formato” en 80+ significa encabezados claros, estructura consistente y longitud apropiada.
La consistencia entre departamentos requiere estándares compartidos. Una receta de investigación de prospectos de ventas y una receta de evaluación de currículums de RRHH ambas extraen datos estructurados de entradas no estructuradas. El estándar de calidad debería ser el mismo. Estandarizamos los criterios de evaluación entre departamentos para que la fábrica aplique estándares consistentes sin importar el dominio de la receta.
La fábrica de flujos de trabajo
Después de que la fábrica de recetas demostró ser efectiva, construimos un pipeline equivalente para flujos de trabajo. La fábrica de flujos de trabajo genera flujos de trabajo multi-paso a partir de especificaciones, crea entradas de prueba que ejercitan el flujo completo (incluyendo ramas de condición e iteraciones de bucle), los ejecuta de extremo a extremo y evalúa la salida compuesta.
La evaluación de flujos de trabajo es más difícil que la evaluación de recetas porque la calidad depende de qué tan bien se encadenan los pasos, no solo de la calidad individual de cada paso. Un flujo de trabajo donde cada paso puntúa 85 individualmente podría puntuar 60 en general si los datos no fluyen limpiamente entre pasos. Los criterios de evaluación incluyen integridad de datos entre pasos y coherencia general.
Ejecutar la fábrica
El pipeline completo se ejecuta con un solo comando: npm run recipe-factory. Toma las especificaciones del catálogo, genera recetas, crea datos de prueba, ejecuta pruebas, evalúa resultados y promueve las recetas aprobadas a la cuenta demo.
Las etapas individuales pueden ejecutarse por separado para iteración:
npm run generate-recipes— Regenerar recetas desde especificaciones del catálogonpm run generate-test-inputs— Crear nuevos datos de pruebanpm run run-recipe-tests— Ejecutar recetas contra LLMnpm run evaluate-recipes— Puntuar los resultadosnpm run promote-recipes— Enviar recetas aprobadas a Firestore
Esta modularidad nos permite iterar en una etapa específica sin re-ejecutar todo el pipeline.
Por qué esto importa para los usuarios
La Fábrica de Recetas es una herramienta interna, pero sus efectos son visibles para el usuario. Cada receta en un pack de inicio ha sido:
- Generada a partir de una especificación que define criterios de calidad
- Probada con entradas realistas incluyendo casos extremos
- Evaluada por un juez LLM en cinco dimensiones de calidad
- Promovida solo si cumple con el umbral de calidad
Cuando instala un pack de inicio, las recetas no son borradores iniciales. Han pasado por un pipeline automatizado de calidad que detecta los problemas más comunes antes de que lleguen a usted.
Dicho esto, son puntos de partida. La terminología específica de su equipo, los estándares de calidad y las preferencias de salida son cosas que la fábrica no puede conocer. Las recetas están diseñadas para ser personalizadas — la fábrica asegura que comiencen en una línea base alta para que su personalización sea refinamiento, no remediación.