por qué evito las bases de datos gráficas la pregunta: "¿está listo para producción el conocimiento gráfico rag? ¿deberíamos usarlo?" la respuesta: después de 10 años en ml, me mantengo alejado de las bases de datos gráficas. cada empresa que he visto entrar en el mundo gráfico regresa a sql en 4-5 años. los problemas son reales: difícil contratar talento (es más fácil encontrar expertos en postgresql) definición de esquema crea debates interminables sin mejores prácticas claras la mayoría de los casos de uso solo necesitan 1-2 recorridos, no operaciones gráficas complejas aún el "gráfico" de facebook era en realidad una gran base de datos mysql. la única empresa que realmente necesita bases de datos gráficas es linkedin para cálculos de amistad de 3-5 grados. incluso para el enfoque de gráfico de documentos de microsoft - preferiría usar embeddings ajustados. un gráfico es solo una matriz de adyacencia, y el ajuste fino puede acercarte a esa definición de similitud sin la complejidad operativa. comienza con tus datos: deja que casos de uso específicos justifiquen la complejidad gráfica en lugar de elegir la tecnología primero. el gráfico podría ser un 2% mejor, pero los enfoques tradicionales que funcionan bien significan que ese 2% rara vez justifica el costo de mantenimiento.