# De 0 à MVP en 2 semaines : créer un système de service client IA de niveau production

1. Contexte : quatre principaux problèmes liés à la production du service client de l'IA d'entreprise

La mise en œuvre d’un service client IA au niveau de l’entreprise est toujours confrontée à quatre problèmes critiques de niveau production qui ne peuvent pas être résolus par des démos open source. Voici les principaux objectifs de conception de ce projet et les principes architecturaux que j'ai ancrés dès l'étape MVP :

1. Déploiement privé et conformité obligatoires : les données sensibles telles que les données clients, les manuels de produits et les informations de commande dans le commerce électronique, la finance et d'autres secteurs ne peuvent pas être connectées aux API LLM du cloud public. Un déploiement local complet et un déploiement de modèle privé sont nécessaires pour garantir que les données restent dans le domaine et sont conformes aux exigences réglementaires telles que la loi sur la protection des informations personnelles. Il s'agit d'une condition préalable à la mise en œuvre du projet et non d'une fonctionnalité facultative.
2. Goulots d'étranglement en matière de performances dans les scénarios à forte concurrence : les scénarios de service client présentent un trafic évident en période de pointe et hors pointe. Lors de grandes promotions, le volume de consultation peut atteindre 10 à 20 fois le niveau quotidien. Les services LLM traditionnels souffrent souvent d'une latence de réponse élevée, d'une perte de session et d'une avalanche de services, ne parvenant pas à garantir la stabilité dans un contexte de concurrence élevée.
3. Défis d'adaptation pour les bases de connaissances multi-sources : les connaissances du service client d'entreprise sont dispersées dans plusieurs sources de données : données de commande/produit CSV structurées, manuels de produits/contrats de service PDF non structurés et interfaces de base de données des systèmes d'entreprise. La recherche traditionnelle en texte intégral et la récupération vectorielle de base ne peuvent pas résoudre des problèmes tels que la perte d'associations sémantiques entre pages et l'échec de l'analyse du contenu des tableaux/images.
4. Coûts d'inférence incontrôlables : plus de 70 % des consultations dans les scénarios de service client sont des questions répétitives à haute fréquence. Invoquer de grands modèles pour obtenir des réponses sans distinction entraîne un gaspillage de ressources GPU dans les déploiements privés et une augmentation des coûts des API du cloud public, rendant les coûts d'exploitation de l'entreprise totalement incontrôlables.

L'objectif principal de ce projet est d'abord de réaliser une validation complète en boucle fermée du "déploiement privé - dialogue utilisateur - appel d'outil - optimisation des coûts" via la version MVP, puis d'itérer progressivement dans un système prêt pour la production, plutôt que de créer une démo de jouet qui s'exécute uniquement localement.

2. Présentation de l'architecture : conception complète, du MVP au niveau production

2.1 Architecture d'atterrissage de la version MVP complète

Le principe de conception de base de la version MVP est le suivant : valider la boucle fermée minimale tout en réservant des capacités d'expansion transparentes pour les itérations de niveau production, en rejetant la sur-ingénierie et les solutions temporaires qui conduisent à une refactoris...
[Courte citation de 8% de l'article original]