Mon top 19 des points clés d'un projet GenAI

Comme dans n’importe quel domaine en IT, il y a des spécificités autour des projets GenAI.

Voici mon top 19 des points clés à ne pas oublier :

1. Dérisquer au max avec des POC si possible sans code (playground provider ou outils no-code comme Flowise, Vectorshift).
2. Tester plusieurs architectures d’agent / découpage de responsabilités entre agents (si possible toujours sans écrire de code).
3. Convenir de la structuration des réponses (avec ou sans JSON ? quel format ? Il est préférable de ne pas figer trop strictement la structure à ce stade du projet).
4. Améliorer la base pour les prompts du système, sans trop les affiner (la base devrait déjà être posée dans l’étape), en particulier la communication inter-agents.
5. Choisir votre ou vos AI provider(s).
6. Ajuster le prompt système en fonction du provider. Ex : Claude XML, few-shot moins efficaces, etc.
7. Créer/définir/coder les agents ; choisir un framework comme LangChain (ou pas d’ailleurs, mais au moins faire un choix conscient).
8. Certifier la structuration des outputs (structured_output, record_summary, lib de vérification d’output, etc.). Définir les stratégies : retry ? autocorrection ?
9. Commencer les tests automatisés (tests d’intégration avec LLM as Judge). À ce stade, les risques sont encore élevés de devoir abandonner certaines parties du projet en raison de nouvelles features d’un provider ou d’un pivot fonctionnel si la partie générative ne répond pas aux attentes.
10. Selon le système, on est entre 50 et 70 % de réponses satisfaisantes à ce moment du projet ; l’objectif est d’atteindre +80 ou 90 % de satisfaction (même si difficile à mesurer).
11. Utiliser ou créer des outils pour faciliter la QA et le débogage sur des envs déployés (playground interne, outils de monitoring).
12. Warm up d’API key : good practice.
13. Setup un Grader (agent évaluateur). À ce stade, on commence à générer des résultats en QA voire en bêta, donc il est crucial de ne pas perdre d’information. Idéalement un système qui offre une vision claire du pourcentage de succès de chaque utilisation du système.
14. Commencer à investir dans des systèmes de failover ou des stratégies de retry (une part non négligeable du taux de succès réside dans les taux de succès des API des providers, qui ne sont franchement pas jojo).
15. Dynamiser les prompts système en fonction des contextes (via RAG ou autres).
16. Ajouter un système de notation par les utilisateurs.

Security layer :

1. Imposer le cloisonnement des données, si possible physique.
2. Ajouter des couches de protection pour refuser de répondre aux prompt injections.
3. Intégrer un système de monitoring pour détecter les injections.

J’aurais bien aimé avoir ce top il y a 2 ans.