[X] I have searched the existing issues and this feature is not already filed.
[ ] My model is hosted on OpenAI or Azure. If not, please look at the "model providers" issue and don't file a new one here.
[X] I believe this is a legitimate feature request, not just a question. If this is a question, please use the Discussions area.
Is your feature request related to a problem? Please describe.
We are trying to use GraphRAG to index and generate knowledge graphs for a diverse set of data types . Specifically, we need to handle business explanations, UI code, and backend code as separate but interconnected categories. Currently, it's not clear how to efficiently structure and index these distinct data types while maintaining their relationships.
For example, based on the query we can decide which graph is relevant to retrieve the context from, this will enhance the accuracy by routing to the relevant output directory, that will be categorized as below in the yaml file.
Describe the solution you'd like
1. Accept multiple data source directories, each corresponding to a different category (e.g., business_explanations, ui_code, be_code).
2. Allow custom configuration for each category, specifying different parsing and indexing strategies based on the data type.
3. Generate separate but interconnected knowledge graphs for each category.
4. Provide a unified querying mechanism that can search across all generated graphs while maintaining context awareness of the different categories.
5. Enable the definition of relationships between entities across different categories (e.g., linking a UI component to a business concept it implements).
Do you need to file an issue?
Is your feature request related to a problem? Please describe.
We are trying to use GraphRAG to index and generate knowledge graphs for a diverse set of data types . Specifically, we need to handle business explanations, UI code, and backend code as separate but interconnected categories. Currently, it's not clear how to efficiently structure and index these distinct data types while maintaining their relationships.
For example, based on the query we can decide which graph is relevant to retrieve the context from, this will enhance the accuracy by routing to the relevant output directory, that will be categorized as below in the yaml file.
Describe the solution you'd like
Additional context