With Graph RAG, what's the actual output structure look like as part of the retrieval step, where a graph is queried (traversed?) and relevant nodes/edges/etc are returned and given to the LLM as context to the original query... what is typically the actual structure of that data? trying to understand how a table or JSON style structure would convey the additional value that using a graph affords (hope that makes sense!)
Thank you for the detailed article. I was also exploring and experimenting with Graph RAG. Are there any suggestions on improving the speed of the retrieval?
Great question :) To speed up retrieval in Graph RAG, try optimizing graph construction (prune low-relevance nodes, use HNSW indexing), improve query execution (hybrid vector + graph retrieval, caching frequent paths), and refine embeddings (GraphSAGE, Node2Vec). Also, maintaining the graph structure regularly and using tiered memory caching can help
Graph RAG vectorizes both nodes and edges using embedding techniques like GraphSAGE or Node2Vec. Unlike Pinecone/OpenSearch, which focus on vectorizing unstructured text for semantic search, Graph RAG captures structured relationships, enabling richer reasoning over knowledge graphs
👏🏼
Great article 🤘
Thanks 😊
With Graph RAG, what's the actual output structure look like as part of the retrieval step, where a graph is queried (traversed?) and relevant nodes/edges/etc are returned and given to the LLM as context to the original query... what is typically the actual structure of that data? trying to understand how a table or JSON style structure would convey the additional value that using a graph affords (hope that makes sense!)
Disregard - I asked Cluade to help explain that to me, and got the answer :)
Thank you for the detailed article. I was also exploring and experimenting with Graph RAG. Are there any suggestions on improving the speed of the retrieval?
Great question :) To speed up retrieval in Graph RAG, try optimizing graph construction (prune low-relevance nodes, use HNSW indexing), improve query execution (hybrid vector + graph retrieval, caching frequent paths), and refine embeddings (GraphSAGE, Node2Vec). Also, maintaining the graph structure regularly and using tiered memory caching can help
Not affiliated with, but this has just popped: https://blog.kuzudb.com/post/kuzu-wasm-rag/
When playing around with GraphRAGs like Neo4j and MS GraphRAG, I’ve been under the impression I need 2 flights to the LLM, I.e
1. Vector based search
2. LLM assessing the most relevant nodes
3. LLM structures Cypher/graph search/”walking” with the most relevant nodes as base
4. LLM receives response and crafts answer to user
This is obviously incredibly slow. Am I misunderstanding something?
Graph RAG vectorizes both nodes and edges using embedding techniques like GraphSAGE or Node2Vec. Unlike Pinecone/OpenSearch, which focus on vectorizing unstructured text for semantic search, Graph RAG captures structured relationships, enabling richer reasoning over knowledge graphs