JieGou livre des packs de démarrage pour neuf départements, chacun avec 7-10 recettes et 2-5 workflows. Cela représente environ 150 recettes et 40 workflows. Écrire chacun à la main, le tester avec des entrées réalistes, évaluer la qualité de la sortie et itérer jusqu’à ce que ce soit assez bien pour livrer — c’est un travail à temps plein pour une équipe.
Nous avions besoin d’une meilleure approche. Alors nous avons construit la Recipe Factory : un pipeline automatisé qui génère, teste, évalue et promeut des templates à grande échelle.
Le pipeline
La Recipe Factory exécute cinq étapes :
1. Catalogue → Générer
Chaque recette commence comme une spécification dans le catalogue : un titre, une description, un département cible, des champs d’entrée attendus, des champs de sortie attendus et des critères de qualité. Le catalogue contient actuellement ~150 spécifications de recettes à travers 9 départements.
L’étape de génération prend chaque spécification et utilise un LLM pour produire une recette complète : un template de prompt soigné, un schéma d’entrée détaillé avec des descriptions de champs et un schéma de sortie structuré. Le LLM suit un méta-prompt qui encode nos standards de qualité de recettes — instructions claires, niveau de détail approprié et bonnes pratiques de schéma.
2. Générer → Données de test
Pour chaque recette générée, un second appel LLM produit 3-5 entrées de test synthétiques. Celles-ci couvrent le cas typique, les cas limites (entrée minimale, entrée inhabituellement longue, entrée ambiguë) et des scénarios spécifiques au département. Les entrées de test sont assez réalistes pour produire une sortie significative sans nécessiter de vraies données clients.
3. Données de test → Exécuter les tests
Chaque recette est exécutée contre un vrai LLM en utilisant les entrées de test synthétiques. Cela attrape les problèmes qui semblent corrects dans le template mais échouent à l’exécution : incompatibilités de schéma, prompts qui produisent des sorties hors cible, templates qui dépassent les limites de contexte et instructions que le modèle interprète différemment de ce qui était prévu.
4. Exécuter les tests → Évaluer
C’est là que le LLM-as-judge intervient. Un LLM séparé évalue chaque résultat de test sur cinq dimensions :
- Conformité au schéma — La sortie correspond-elle au schéma attendu ? Tous les champs requis sont-ils présents et correctement typés ?
- Complétude — La sortie traite-t-elle tous les aspects de l’entrée ? Y a-t-il des lacunes ou des sections manquantes ?
- Actionnabilité — La sortie est-elle utile ? Une personne peut-elle agir dessus sans travail supplémentaire significatif ?
- Qualité de format — La sortie est-elle bien organisée, clairement écrite et appropriément détaillée ?
- Cohérence — À travers plusieurs entrées de test, la recette produit-elle une sortie structurée de manière cohérente ?
Chaque dimension reçoit un score de 0-100. Le score global est une moyenne pondérée.
5. Évaluer → Promouvoir
Les recettes qui scorent 75+ globalement sans aucune dimension en dessous de 50 sont promues vers le compte de démo dans Firestore. Les recettes qui échouent sont signalées pour revue et itération manuelles.
Ce que le LLM-as-judge nous a appris
Construire un système d’évaluation de qualité automatisé a produit plusieurs insights non évidents.
La spécificité du prompt compte plus que la longueur. Les premiers templates de recettes étaient longs et détaillés. Le LLM-as-judge a systématiquement mieux noté les prompts plus courts et plus spécifiques sur la conformité au schéma et la qualité de format. Un prompt de 200 mots qui dit exactement quoi faire surpasse un prompt de 500 mots qui couvre chaque cas limite. Le modèle suit mieux les instructions claires que les instructions exhaustives.
Les schémas de sortie sont le levier de qualité le plus important. Les recettes avec des schémas de sortie détaillés — descriptions de champs, contraintes d’enum, structures d’objets imbriquées — ont obtenu des scores significativement plus élevés en complétude et cohérence. Le schéma agit comme un second jeu d’instructions qui contraint la sortie du modèle indépendamment du prompt.
Les entrées de test de cas limites révèlent la fragilité. Le cas de test standard fonctionne habituellement. Les cas limites — entrée minimale, formatage inhabituel, champs optionnels manquants — exposent les recettes qui cassent dans des conditions réelles. Une recette qui score 90 sur le cas typique mais 40 sur les cas limites n’est pas prête pour la production.
Les critères d’évaluation nécessitent un calibrage. Notre première passe de scoring LLM-as-judge était trop indulgente. Les recettes scoraient 85+ alors qu’elles produisaient des sorties médiocres. Nous avons resserré le prompt d’évaluation avec des exemples spécifiques de ce à quoi chaque niveau de score ressemble. « Actionnabilité » à 80+ signifie que la sortie inclut des prochaines étapes spécifiques, pas juste de l’analyse. « Qualité de format » à 80+ signifie des en-têtes clairs, une structure cohérente et une longueur appropriée.
La cohérence cross-département nécessite des standards partagés. Une recette de recherche de prospects commerciaux et une recette de screening de CV RH extraient toutes deux des données structurées à partir d’entrées non structurées. La barre de qualité devrait être la même. Nous avons standardisé les critères d’évaluation à travers les départements pour que l’usine applique des standards cohérents quel que soit le domaine de la recette.
L’usine à workflows
Après que l’usine à recettes a fait ses preuves, nous avons construit un pipeline équivalent pour les workflows. L’usine à workflows génère des workflows multi-étapes à partir de spécifications, crée des entrées de test qui exercent le workflow complet (incluant les branches de conditions et les itérations de boucles), les exécute de bout en bout et évalue la sortie composite.
L’évaluation des workflows est plus difficile que celle des recettes parce que la qualité dépend de la façon dont les étapes s’enchaînent, pas seulement de la qualité individuelle de chaque étape. Un workflow où chaque étape score 85 individuellement pourrait scorer 60 globalement si les données ne circulent pas proprement entre les étapes. Les critères d’évaluation incluent l’intégrité des données inter-étapes et la cohérence globale.
Exécuter l’usine
Le pipeline complet s’exécute avec une seule commande : npm run recipe-factory. Il prend les spécifications du catalogue, génère les recettes, crée les données de test, exécute les tests, évalue les résultats et promeut les recettes passantes vers le compte de démo.
Les étapes individuelles peuvent être exécutées séparément pour l’itération :
npm run generate-recipes— Régénérer les recettes à partir des spécifications du cataloguenpm run generate-test-inputs— Créer de nouvelles données de testnpm run run-recipe-tests— Exécuter les recettes contre le LLMnpm run evaluate-recipes— Scorer les résultatsnpm run promote-recipes— Pousser les recettes passantes vers Firestore
Cette modularité nous permet d’itérer sur une étape spécifique sans re-exécuter le pipeline entier.
Pourquoi c’est important pour les utilisateurs
La Recipe Factory est un outil interne, mais ses effets sont visibles par les utilisateurs. Chaque recette dans un pack de démarrage a été :
- Générée à partir d’une spécification qui définit les critères de qualité
- Testée avec des entrées réalistes incluant des cas limites
- Évaluée par un juge LLM sur cinq dimensions de qualité
- Promue uniquement si elle atteint le seuil de qualité
Quand vous installez un pack de démarrage, les recettes ne sont pas des brouillons. Elles sont passées par un pipeline de qualité automatisé qui attrape les problèmes les plus courants avant qu’ils ne vous atteignent.
Cela dit, ce sont des points de départ. La terminologie spécifique de votre équipe, vos standards de qualité et vos préférences de sortie sont des choses que l’usine ne peut pas connaître. Les recettes sont conçues pour être personnalisées — l’usine s’assure qu’elles démarrent à un niveau de base élevé pour que votre personnalisation soit du raffinement, pas de la remédiation.