Metadata-Version: 2.1
Name: graphragzen
Version: 0.1.2
Summary: 
Author: benste
Author-email: benstmrs@gmail.com
Requires-Python: >=3.10,<=3.12
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3.10
Classifier: Programming Language :: Python :: 3.11
Classifier: Programming Language :: Python :: 3.12
Requires-Dist: einops (>=0.8.0,<0.9.0)
Requires-Dist: jsonref (>=1.1.0,<2.0.0)
Requires-Dist: leidenalg (==0.10.2)
Requires-Dist: llama-cpp-python (>=0.2.87,<0.3.0)
Requires-Dist: llama-prompter (==0.2.2)
Requires-Dist: networkx (>=3.3,<4.0)
Requires-Dist: openai (>=1.43.0,<2.0.0)
Requires-Dist: pandas (>=2.2.2,<3.0.0)
Requires-Dist: pyarrow (>=17.0.0,<18.0.0)
Requires-Dist: pydantic (>=2.7.0)
Requires-Dist: qdrant-client[fastembed] (>=1.11.0,<2.0.0)
Requires-Dist: sentence-transformers (>=3.0.1,<4.0.0)
Requires-Dist: tiktoken (>=0.7.0,<0.8.0)
Requires-Dist: transformers (>=4.44.0,<5.0.0)
Description-Content-Type: text/markdown

# GraphRAGZen
**GraphRAGZen** is a functional, common sense, library for developing GraphRAG pipelines.

A big **thank you** to the team at microsoft that created [GraphRAG](https://github.com/microsoft/graphrag), which is the foundation for this project.

[You can find the documentation here](https://benste.github.io/GraphRAGZen/)

# Motivation
[GraphRAG from Microsoft](https://github.com/microsoft/graphrag) makes it easy to get started with 
automated Graph RAG.

Sadly, the codebase is hard to read, difficult to adapt, and dataflow
in the pipelines near impossible to follow.

The work done by the GraphRAG team shouldn’t be in vain, but should
allow for developers to create GraphRAG applications that are
maintainable, extendable and intuitive.

And so GraphRAGZen was born; the logic given by GraphRAG in a
functional, common sense library...

## But that's just another Graph RAG library, right?
[XKCD says it well](https://xkcd.com/927/)

It's early days for GraphRAG technology, and there's no standard implementation method accepted at 
large. This shows that there's still a lack of high quality, easy to implement solutions in the 
OSS space.

From experience I found that most libraries available either provide a limited set
of abilities with the bulk hiding behind convoluted code (i.e. GraphRAG)
or are unintuitive and rely heavily on extended documentation.

This should be easily mitigated by writing a functional library. That
is, the python function is king, and the functions are named and located intuitively.

When that is established we have a toolbox that can be used as seen fit
by developers. It is modular, extendable, maintainable and intuitive.

