L'équipe d'AI Sous-chef a lancé en 2,5 mois une application et un bot reposant sur une IA cloud

L'application a reçu une liste de produits, renvoyé une recette au format attendu et présenté à l'utilisateur une salade de pommes de terre crues et d'aubergine. L'étape de cuisson de ces ingrédients était absente de l'instruction. Selon l'équipe d'AI Sous-chef, c'est précisément le retour reçu après le lancement. Pour un développeur, le problème est familier : la réponse du modèle passe avec succès les contrôles techniques, mais l'utilisateur obtient un mauvais résultat.

Dans une analyse publiée sur Habr, l'équipe explique comment elle a assemblé en deux mois et demi une application Android et un bot Telegram avec un backend commun. L'intérêt pratique de ce texte tient aux détails : comment les versions de prompts sont choisies, ce qui est vérifié dans les réponses et pourquoi ces vérifications restent insuffisantes.

Deux clients, un backend commun et des prompts dans des fichiers

Le scénario est simple : la personne photographie ses produits ou les saisit en texte, confirme la liste reconnue et reçoit des propositions de plats. L'application mobile en React Native et le bot partagent un même serveur en Python et FastAPI. La reconnaissance et la génération de recettes sont réparties entre deux modèles cloud ; les requêtes sont envoyées à l'API de Yandex.

Les instructions sont stockées séparément du code : chaque tâche dispose d'un fichier système et d'un fichier utilisateur. Les versions à utiliser sont définies par pin.json. Par exemple, la reconnaissance peut rester en v1, tandis qu'une autre version préparée est choisie pour les recettes. Le chargeur lit les fichiers et substitue les valeurs dans des expressions comme {{ products }}. Si un fichier ou une valeur requise est absent, il renvoie une erreur.

Cela permet de modifier les formulations sans réécrire la fonction d'appel du modèle. Mais il existe un détail d'exploitation : l'index des versions est mis en cache dans la mémoire du processus. Après modification de pin.json, un redémarrage ou un vidage du cache est nécessaire. Les textes des instructions, eux, sont relus à chaque appel du chargeur.

Il existe aussi une limite plus importante. D'après les auteurs, la liste de produits est insérée notamment dans l'instruction système. Des fichiers distincts ne séparent donc pas, à eux seuls, les données utilisateur des règles de comportement du modèle. La réaction à des consignes étrangères glissées dans le texte d'entrée reste à tester.

Le JSON valide la structure, la recette demande une autre évaluation

Lors de la génération des recettes, l'application demande du JSON via un paramètre de l'API, puis analyse la réponse avec json.loads et vérifie la structure attendue avec model_validate. Cela permet de détecter une réponse que le code ne saurait traiter. Cependant, la présence des champs requis ne dit rien de la complétude des étapes culinaires.

Après le retour sur les pommes de terre crues, l'équipe a commencé à retravailler le prompt. La réponse initiale n'a pas été conservée, il n'existe donc pas de comparaison vérifiable avant/après. Les auteurs ne prétendent pas que le problème est résolu.

Le dépôt contient dix scénarios de test : saisie vide, un seul ingrédient, quantités fractionnaires, texte ambigu et autres cas. Sont décrits les ingrédients superflus, les instructions vagues et les erreurs de format. Mais il n'existe pas encore de métrique unique et fiable : entre les contrôles, les prompts, les paramètres de génération et le traitement des réponses ont changé simultanément.

Par ailleurs, la reproductibilité est limitée par l'usage de latest dans les adresses des modèles. La version du prompt peut rester la même alors que le modèle derrière cette adresse est mis à jour. Pour obtenir des exécutions comparables, il faut conserver l'entrée, la réponse, les paramètres et l'identification la plus précise possible du modèle.

Ce qui peut servir dans votre propre produit

AI Sous-chef propose un mode AI_MODE=stub : au lieu de requêtes cloud, l'application reçoit des produits et des recettes préenregistrés. Sur de telles réponses, il est commode de tester l'interface et l'interaction des composants. Ce mode ne mesure pas la qualité de la génération, puisqu'il n'y a pas de génération.

Pour un product manager, une autre limite de la première version est révélatrice : la liste reconnue pouvait être confirmée, mais pas corrigée. L'utilisateur voyait l'erreur et ne pouvait pas retirer l'ingrédient erroné avant l'étape suivante. L'édition de la liste est devenue l'une des prochaines améliorations.

Selon l'article, le dépôt principal est publié sous licence GNU AGPL v3.0. On peut y étudier le chargeur de prompts, le choix des versions, la validation des réponses et le remplacement des modèles par des données prêtes. Lors d'un transfert, il faudra tenir compte des structures propres à chaque application et du cache.

Pour une équipe qui construit un service similaire, ce cas propose un ordre de travail utile : vérifier séparément le traitement de la réponse et son contenu, conserver les exemples problématiques, comparer les modifications dans des conditions identiques. Les prompts sortis dans des fichiers facilitent la maintenance. La preuve de la qualité devra néanmoins être établie sur des réponses réelles.