What problem does this PR solve?

It started with me wanting to know how many nodes and edges I had in my Graph. Then the graph kept resetting halfway through the parsing. I think there is a race condition where the graph gets deleted before being rebuilt (set_graph() in ragflow/graphrag/utils.py) and the next task merging on the empty graph (maybe some issue with the lock, im not sure). It happened with multiple task executors but also with just one. By splitting up the process and separating it from the parsing a couple of issues can be solved:

1. Race conditions by only building the graph once the enitity extraction is done
2. Inefficient workflow requiring full document reparsing to create knowledge graphs
3. Suboptimal community detection running running too often during parsing, only needs to run at the end

Moved all GraphRAG functionalities to the Knowledge Graph tab
Tab always shows, all tasks can be started from there:
Extract Entities
Build Graph
Resolve Entities
Detect Communities
Show Graph statistics with total number of Nodes, Edges and Communities
Show progress of all tasks
Visualize communities

Type of change

• New Feature (non-breaking change which adds functionality)
• Bug Fix (non-breaking change which fixes an issue)
• Refactoring

Additional Notes

This is a working implementation that addresses the core issues, but the code still needs cleanup and refinement. I'm looking for feedback on the overall approach and architecture before spending time polishing the implementation details. I saw on the roadmap that you are also working on the Graphrag part, so I don't know if this is even needed.

Key improvements:

• All GraphRAG tasks accessible from one location
• Real-time progress tracking
• Graph statistics display (nodes, edges, communities)
• Community visualization
• Can be performed independently after document parsing