When to use it
==============

``lightrag-agensgraph`` is for teams that want a **turnkey graph-RAG engine** — point LightRAG
at documents and it builds the knowledge graph and answers questions — with the whole pipeline
(graph, vectors, key-value, and document status) stored in one AgensGraph database.

**Good fits**

- **Question answering across many documents.** LightRAG's dual-level retrieval combines
  entity-centric and relationship-centric context, so it handles questions that span documents
  better than plain vector RAG. Choose a mode per query: ``naive``, ``local``, ``global``,
  ``hybrid``, or ``mix``.
- **Knowledge bases that grow over time.** Ingest documents incrementally; the document-status
  pipeline tracks each one, deduplicates re-submissions, and merges entities that recur across
  documents. For a large one-off load, ``bulk_ingest()`` rebuilds the vector indexes once at the
  end instead of inserting into them record by record.
- **Multi-tenant deployments.** Give each tenant its own ``workspace`` so independent knowledge
  bases share a single database with no data leakage.
- **Curated graphs.** Merge, edit, and delete entities, relationships, and whole documents as
  your source data changes.

**How it compares**

- Pick **LightRAG** when you want an opinionated graph-RAG engine and don't need to build a
  general application framework around it.
- Pick **cognee** for a broader memory layer with more search modes (chain-of-thought,
  summaries, code graphs, ontology-typed extraction).
- Pick **LangChain** or **LlamaIndex** when you need full control of the retrieval pipeline
  inside one of those frameworks.

**Consider an alternative when**

- You need bespoke retrieval logic or tight framework integration — a LangChain or LlamaIndex
  build gives you more control.
- You want an agent to drive AgensGraph through tools — use the **MCP servers**.