pourquoi j'évite les bases de données graphiques la question : "le graph de connaissances est-il prêt pour la production RAG ? devrions-nous l'utiliser ?" la réponse : après 10 ans dans le ML, je reste à l'écart des bases de données graphiques. chaque entreprise que j'ai vue entrer dans le monde graphique revient à SQL dans les 4-5 ans. les problèmes sont réels : difficile de recruter des talents (plus facile de trouver des experts PostgreSQL) définition de schéma créant des débats sans fin sans meilleures pratiques claires la plupart des cas d'utilisation n'ont besoin que de 1-2 traversées, pas d'opérations graphiques complexes même le "graph" de Facebook était en réalité une grande base de données MySQL. la seule entreprise qui a vraiment besoin de bases de données graphiques est LinkedIn pour les calculs d'amitié de 3-5 degrés. même pour l'approche de graphes de documents de Microsoft - je préfère utiliser des embeddings finement ajustés. un graphe n'est qu'une matrice d'adjacence, et le fine-tuning peut vous rapprocher de cette définition de similarité sans la complexité opérationnelle. commencez avec vos données : laissez des cas d'utilisation spécifiques justifier la complexité graphique plutôt que de choisir la technologie en premier. un graphe pourrait être 2 % meilleur, mais des approches traditionnelles qui fonctionnent bien signifient que ce 2 % justifie rarement le coût de maintenance.