[Question]: Would you like dynamic multi-graph support?

[laszukdawid]

Do you need to ask a question?

• I have searched the existing question and discussions and this question is not already answered.
• I believe this is a legitimate question, not just a bug or feature request.

Your Question

Hi @danielaskdd (and other LightRAG team),

We recently started playing with LightRAG and are somehow enjoying it. For our own purpose we needed to extended it so that it supports multi-graph. Quick look at other issues sounds like this might be partially what the issue #2373 is requesting - although they want also UI changes which we don't have at this moment. If you're open, I'm happy to contribute some of the code. High level, we're dynamically creating LightRAG instances per "workspace" / "graph_id" requested, and then each query is routed to relevant graph?

Additional Context

No response

[danielaskdd]

Could you please provide a detailed description of the implementation approach and use cases?

[laszukdawid]

Sure. The use case, that we had, is to support dynamic creation of graphs which are "obviously" or intentionally separate. For example, dealing with some privacy terms in different jurisdictions, e.g. EU or Australia, some words/entities might be the same per name but different per definition. Likewise, since we want to play with different models as AB testing we might want to store the same entities but they might have different relations.

As for implementation, the constraints for the current implementations are:

• not divert too far from this repo's main branch - you're doing great job here and we much prefer LightRAG over other graph-based RAGs implementations
• reuse components (logic and databases) as we're still developing heavily

With those constraints, the implementation right now adds multigraph_lightrag_server.py which is extending lightrag_server.py logic through adding extra routes (for multi graphs) and checks whether required config is set. As the server starts, it initiates MultiGraphLightRAG instance (implemented in lightrag/multigraph_rag.py) and reads dbs for existing 'graphs'. For the most of it, we re-used your concept of "workspace" and so each "graph" is associated with "graph_id" which is actually a pointer to a LightRAG workspace. MultiGraphLightRAG is implemented mostly as routing mechanism where depending on the "graph_id" in the request, it checks whether such graph exists, and if it doesn't, it instantiates a new LightRAG (existing, yours) object with specified configuration. (Note: at the moment, all graphs are expected to have the same configuration, i.e. same model, embedding, db resources.) Beyond routing there's a tone of logic for validation, keeping lock, deletion... but it's mostly self._multi_graph: dict[str, LightRAG] = {}.
Remaining part is APIs for graphs' CRUDs and queries.