perché evito i database a grafo la domanda: "il knowledge graph rag è pronto per la produzione? dovremmo usarlo?" la risposta: dopo 10 anni nel machine learning, sto lontano dai database a grafo. ogni azienda che ho visto entrare nel mondo dei grafi torna a sql entro 4-5 anni. i problemi sono reali: difficile assumere talenti (è più facile trovare esperti di postgresql) definizione dello schema che crea dibattiti infiniti senza chiare best practices la maggior parte dei casi d'uso ha bisogno solo di 1-2 traversate, non di operazioni grafiche complesse even facebook's "graph" era in realtà un grande database mysql. l'unica azienda che ha davvero bisogno di database a grafo è linkedin per i calcoli delle amicizie a 3-5 gradi. anche per l'approccio del document graph di microsoft - preferirei usare embedding ottimizzati. un grafo è solo una matrice di adiacenza, e l'ottimizzazione può avvicinarti a quella definizione di similarità senza la complessità operativa. inizia con i tuoi dati: lascia che casi d'uso specifici giustifichino la complessità del grafo piuttosto che scegliere prima la tecnologia. il grafo potrebbe essere migliore del 2%, ma approcci tradizionali che funzionano bene significano che quel 2% raramente giustifica il costo di manutenzione.