LLM Graph Builder

LLM Graph Builder is a Neo4j Labs application for turning unstructured information into a knowledge graph. The repository describes support for PDFs, documents, text files, YouTube videos, web pages, local uploads, Google Cloud Storage, S3, and other web sources. Users connect a Neo4j database, choose a model, and generate nodes, relationships, and properties that can be explored as a graph instead of searched only as text chunks. That graph-first workflow is the reason to consider it. Many RAG systems split documents into passages and search those passages later. LLM Graph Builder tries to extract entities and relationships, store them in Neo4j, visualize them, and support chat over the resulting data. For teams already using Neo4j, it offers a practical starting point for GraphRAG, graph search, data import, and internal knowledge tooling. The setup is technical. The README calls for Python 3.12 or higher for local backend deployment and Neo4j Database 5.23 or later with APOC installed. Neo4j Aura databases are supported, including the free tier. Local users configure backend environment variables for the Neo4j URI, username, password, and database name, then run the backend and frontend according to the documented deployment path. Model support is broad in the project documentation. The README lists OpenAI, Gemini, Diffbot, Azure OpenAI, Anthropic, Fireworks, Groq, Amazon Bedrock, Ollama, DeepSeek, and other OpenAI-compatible endpoints in supported or development paths. It also documents token usage tracking through an environment variable, which is useful when ingestion jobs run over large files or many sources. LLM Graph Builder is best for data teams, AI platform engineers, and developers who want graph-backed retrieval on top of Neo4j. It is not a one-click SaaS tool. Teams should expect to bring a Neo4j database, model credentials, deployment time, and data-review habits. The payoff is an inspectable graph layer that can make relationships, source metadata, and downstream chat behavior easier to reason about. For OpenTools readers, the key question is whether the project saves work in a real builder workflow rather than merely sounding interesting. This listing focuses on documented inputs, outputs, setup requirements, limits, and the kind of team that can make practical use of the software. A second review point is operational fit. Teams should check credentials, data exposure, hosting requirements, model costs, and maintenance effort before putting the tool into a sensitive workflow. Open-source availability helps with inspection, but it does not remove the need for access control and testing. The page intentionally avoids unsupported claims. When a source gives a number, license, install path, or named integration, the summary uses that source-backed fact. When the source is unclear, the listing describes the uncertainty instead of turning it into a marketing claim.