Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Question]: What is the best to retrieve Knowledge graphs embeddings #13129

Open
1 task done
navneteberi30 opened this issue Apr 26, 2024 · 7 comments
Open
1 task done
Labels
question Further information is requested

Comments

@navneteberi30
Copy link

navneteberi30 commented Apr 26, 2024

Question Validation

  • I have searched both the documentation and discord for an answer.

Question

Hi I have general question,
How can we retrieve the knowledge graph embeddings from the graph store instead of using the local storage context?
I am unable to find any documentation related to that or is it something we can expect in future
current process looks something like this once we create the knowledge graphs and then use local storage context.
Could you please share how can we retrieve from the graph store that we build
kg_index = load_index_from_storage(
storage_context=storage_context,
max_triplets_per_chunk=10,
space_name=space_name,
edge_types=edge_types,
rel_prop_names=rel_prop_names,
tags=tags,
verbose=True,
)

@navneteberi30 navneteberi30 added the question Further information is requested label Apr 26, 2024
Copy link

dosubot bot commented Apr 26, 2024

To retrieve knowledge graph embeddings directly from a graph store, you can use a specialized approach involving the KGTableRetriever class within the LlamaIndex framework. This class is designed to interact with your graph store and supports the retrieval of embeddings by leveraging the graph store's capabilities. Here's a concise guide on setting this up:

  1. Implement the GraphStore Protocol: Define a class that implements the GraphStore protocol from LlamaIndex, ensuring it meets the requirements of your specific graph store.

  2. Initialize the KnowledgeGraphIndex: Create an instance of KnowledgeGraphIndex by providing it with a ServiceContext and your graph store instance.

  3. Set Up KGTableRetriever: Initialize KGTableRetriever with the knowledge graph index, specifying KGRetrieverMode.EMBEDDING to indicate you're retrieving embeddings. Configure additional parameters like similarity_top_k and graph_store_query_depth as needed.

  4. Retrieve Embeddings: Use the _retrieve method of KGTableRetriever with a QueryBundle to fetch the embeddings from your graph store.

Here's a simplified example to illustrate the setup:

from llama_index.core.indices.knowledge_graph.base import KnowledgeGraphIndex
from llama_index.core.service_context import ServiceContext
from llama_index.core.indices.knowledge_graph.retrievers import KGTableRetriever, KGRetrieverMode
from llama_index.core.schema import QueryBundle
from llama_index.core.graph_stores.types import GraphStore

class YourGraphStore(GraphStore):
    # Implement required methods for your graph store

your_graph_store = YourGraphStore()
service_context = ServiceContext()
knowledge_graph_index = KnowledgeGraphIndex(service_context=service_context, graph_store=your_graph_store)
kg_table_retriever = KGTableRetriever(index=knowledge_graph_index, retriever_mode=KGRetrieverMode.EMBEDDING)

query_bundle = QueryBundle(query_str="Your query here")
nodes_with_embeddings = kg_table_retriever._retrieve(query_bundle)

This setup allows you to directly interact with your graph store to retrieve embeddings, bypassing the need for local storage contexts. Ensure your YourGraphStore class correctly implements the GraphStore protocol, and adjust the ServiceContext and QueryBundle as per your application's specifics.

If you encounter any specific issues or need further clarification on implementing this solution, feel free to ask.

Details

Sources


About Dosu
This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

To continue the conversation, mention @dosu.

@oykunehir
Copy link

I have the same problem, as you mentioned in your code KGTableRetriever takes knowledge_graph_index as parameter. Which means every time we need to re-build the KG index. Is there a way to build the KG indexes and store in a graph database, then query without building the index again?

@navneteberi30
Copy link
Author

@dosu The code you provided when we will call KGTableRetriever it needs index=knowledge_graph_index so every time we call the kg_table_retriever it will recreate the knowledge_graph_index which we want to avoid.

knowledge_graph_index = KnowledgeGraphIndex(service_context=service_context, graph_store=your_graph_store)
kg_table_retriever = KGTableRetriever(index=knowledge_graph_index, retriever_mode=KGRetrieverMode.EMBEDDING)

Copy link

dosubot bot commented Apr 28, 2024

To address the concern about rebuilding the KnowledgeGraphIndex every time with KGTableRetriever, it's important to clarify that once the KnowledgeGraphIndex is initialized and passed to KGTableRetriever, it does not get recreated with each retrieval operation. The index is used as is for fetching data, which means your application can maintain the index state across different retrieval calls without needing to rebuild it.

For scenarios where you're looking to persist the knowledge graph index and avoid rebuilding it on every application start, you can leverage the persistence capabilities of the FaissVectorStore within the LlamaIndex framework. This involves saving the index to a file after its initial creation and loading it from this file when needed. Here's how you can do it:

  1. Save the Index: After creating your index, use the persist method of the FaissVectorStore to save it.
    faiss_store.persist(persist_path="/path/to/save/index")
  2. Load the Index: When you need to use the index again, load it using the from_persist_path method.
    faiss_store = FaissVectorStore.from_persist_path(persist_path="/path/to/index/file")

This approach allows you to maintain and reuse the knowledge graph index without the overhead of rebuilding it, enhancing the efficiency of your application. Remember to replace "/path/to/index/file" and "/path/to/save/index" with the actual paths relevant to your environment.

This method ensures that your application can efficiently query the knowledge graph by leveraging the stored index, significantly reducing the initialization time and computational overhead associated with rebuilding the index from scratch.

Details

Sources


About Dosu
This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

To continue the conversation, mention @dosu.

@gich2009
Copy link

Hi @navneteberi30 @oykunehir, have you guys tried using the KnowledgeGraphRAGRetriever()? You can build your index with the KnowledgeGraphIndex() and then pass in the graph_store you used for this process to the KnowledgeGraphRAGRetriever(). Let me know if this works for you.

@navneteberi30
Copy link
Author

@gich2009 that doesn't work because once i build the KnowledgeGraphIndex.from_documents() and unable to get any reposnse

kg_index = KnowledgeGraphIndex.from_documents(
        documents=github_document_loader(),
        llm=OpenAI(model="gpt-4", temperature=0.1),
        graph_store=graph_store,
        max_triplets_per_chunk=10,
        space_name=SPACE_NAME,
        edge_types=EDGE_TYPES,
        rel_prop_names=REL_PROP_NAMES,
        tags=TAGS,
        include_embeddings=True,
    )
    
 storage_context = StorageContext.from_defaults(graph_store=graph_store)
    graph_rag_retriever = KnowledgeGraphRAGRetriever(
        storage_context=storage_context,
        verbose=True,
    )

@gich2009
Copy link

@navneteberi30, let me give it a try on my side then I'll get back to you on it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants