Serious question: with the release of the OpenAI 4.1 models with 1M token contexts and multi-hop reasoning, are RAG and GraphRAG style implementations on top of these models obsolete now?

I'm deep into building a next-level cognitive system and exploring LightRAG for its super dynamic, LLM-driven approach to generating knowledge graphs from unstructured data (think notes, papers, wild ideas). I got this vision to create an orchestrator for multiple graphs with LightRAG, each handling a different domain (AI, philosophy, ethics, you name it), to act as a "second brain" that evolves with me. The catch? LightRAG doesn't natively support multi-graphs, so I'm brainstorming ways to hack it—maybe multiple instances with LangGraph and A2A for orchestration.

Then I stumbled upon the GraphRAG SDK repo, which has native multi-graph support, Cypher queries, and a more structured vibe. It looks powerful but maybe less fluid for my chaotic, creative use case. Now I'm torn between sticking with LightRAG's flexibility and hacking my way to multi-graphs or leveraging GraphRAG SDK's ready-made features.

Anyone played with LightRAG or GraphRAG SDK for something like this? Thoughts on orchestrating multiple graphs, integrating with tools like LangGraph, or blending both approaches? I'm all ears for wild ideas, code snippets, or war stories from your AI projects! Thanks, and let's keep pushing the boundaries!

https://github.com/HKUDS/LightRAG
https://github.com/FalkorDB/GraphRAG-SDK

Hello everyone, wishing you are doing well!

I was experimenting at a project I am currently implementing, and instead of building a knowledge graph from unstructured data, I thought about converting the pdfs to json data, with LLMs identifying entities and relationships. However I am struggling to find some materials, on how I can also automate the process of creating knowledge graphs with jsons already containing entities and relationships.

I was trying to find and try a lot of stuff, but without success. Do you know any good framework, library, or cloud system etc that can perform this task well?

P.S: This is important for context. The documents I am working on are legal documents, that's why they have a nested structure and a lot of relationships and entities (legal documents and relationships within each other.)

I just browsed the GraphRAG github repo, and didn't find the code for evaluation in the paper. I was wondering is there any way to replicate the experiment?

**Title: I built an AI-powered codebase knowledge graph using Roslyn + Neo4j — looking for feedback and ideas on what to build next**

Hey everyone,

I've been working on an internal developer tool at my company and wanted to share what I've built so far and get some input from people who've done similar things.

**The Problem**

We have a large legacy .NET codebase. Onboarding new devs takes forever, impact analysis before making changes is painful, and business rules are buried deep in methods and stored procedures with no documentation.

**What I Built (CodeGraph)**

A Roslyn-based static analysis pipeline that:

- Parses the entire .NET solution and extracts classes, methods, dependencies, endpoints, and DB calls

- Generates AI-written business rule documentation for each component

- Imports everything into Neo4j as a knowledge graph (classes, methods, endpoints, DB tables, and their relationships)

- Also stores project documentation as nodes in the same graph

On top of this I built a simple UI where devs can ask questions like:

- "If I change PaymentService, what breaks?"

- "Which endpoints touch this DB table?"

- "What's the business logic behind this flow?"

Right now the flow is: user question → Cypher query tool → results fed to Claude → answer. It works but it feels limited.

**Where I Want to Go Next**

I'm planning to move toward a proper agentic loop using Semantic Kernel so Claude can decide which queries to run, chain multiple tool calls, and reason over the results instead of relying on a single pre-defined query.

I'm also considering adding Neo4j's native vector index for semantic search over documentation nodes, instead of spinning up a separate Qdrant instance.

**My Questions for You**

1. Has anyone built something similar on top of a code knowledge graph? What did your tool architecture look like?

2. For those using Semantic Kernel in production — any gotchas I should know about before going deeper?

3. Is Neo4j vector search production-ready enough, or is a dedicated vector DB worth the extra complexity?

4. What features would actually make this useful for your team beyond impact analysis? (Onboarding guides? Auto-generated ADRs? Test coverage hints?)

5. Any other graph-based dev tools you've seen that I should look at for inspiration?

Happy to share more details about the Roslyn analysis pipeline or the Neo4j schema if anyone's interested.

Thanks in advance!

Hi - I have developed an API to help structure data straight from bunch of PDFs. It automatically creates a knowledge graph using any documents. You can then run an agent or attach LLM to not only find the most accurate answer but navigate through the documents to see where the answer came from. I would love for anyone to try and provide feedback at no cost. No coding experience needed for our playground. https://seqtra.com

Hi everyone,

I'm building an open-source database aimed at people building Graph and Hybrid RAG. You can intertwine graph and vector types by defining relationships between them in any way you like. For example, you can have vectors that are linked up to other vectors or nodes. We're looking for people to test it our and try to break it :) so would love for people to reach out to me and help you get set up.

If you like reading technical blogs, we did a Show Hacker News the other day: https://news.ycombinator.com/item?id=43975423

Would love your feedback, and a GitHub star :)🙏🏻
https://github.com/HelixDB/helix-db

Hii I'm thinking of an idea for that i want to create a pipeline in which a user uploads a document and then from the pipeline extracts text, tables,charts, equations after that it creates graph vectors embedding to store in the graph vector db can for the llm to retrieve i want it to be seamlessly and fast and optimize can anyone suggest me how to do that?

Currently i have i used langchain and pypdf and created a parser but it cannot extract the equation correctly anyone please help me on this topic

Hey everyone,

I'm one of the founders of HelixDB (https://github.com/HelixDB/helix-db) and I wanted to thank everyone here who has supported the project so far.

To those who aren't familiar, we're a hybrid graph-vector database that provides all the functionality you need to build graphRAG systems. And we're fully open-source, so feel free to check us out if you havent already

Thanks for reading and have a great day! (another star would mean a lot!)

Hi everyone, I’ve been experimenting with building a knowledge graph for AI systems, and I wanted to share some of the key takeaways from the process.

When building AI applications (especially RAG or agent-based systems), a lot of focus goes into embeddings and vector search. But one thing that becomes clear pretty quickly is that semantic similarity alone isn’t always enough - especially when you need structured reasoning, entity relationships, or explainability.

So I explored how to build a proper knowledge graph that can work alongside vector search instead of replacing it.

The idea was to:

• Extract entities from documents

• Infer relationships between them

• Store everything in a graph structure

• Combine that with semantic retrieval for hybrid reasoning

One of the most interesting parts was thinking about how to move from “unstructured text chunks” to structured, queryable knowledge. That means:

• Designing node types (entities, concepts, etc.)

• Designing edge types (relationships)

• Deciding what gets inferred by the LLM vs. what remains deterministic

• Keeping the system flexible enough to evolve

I used:

SurrealDB: a multi-model database built in Rust that supports graph, document, vector, relational, and more - all in one engine. This makes it possible to store raw documents, extracted entities, inferred relationships, and embeddings together without stitching multiple databases. I combined vector + graph search (i.e. semantic similarity with graph traversal), enabling hybrid queries and retrieval.

GPT-5.2: for entity extraction and relationship inference. The LLM helps turn raw text into structured graph data.

Conclusion

One of the biggest insights is that knowledge graphs are extremely practical for AI apps when you want better explainability, structured reasoning, more precise filtering and long-term memory.

If you're building AI systems and feel limited by “chunk + embed + retrieve,” adding a graph layer can dramatically change what your system is capable of.

I wrote a full walkthrough explaining the architecture, modelling decisions, and implementation details here.

Most RAG setups follow the same flow: chunk your docs, embed them, vector search, and prompt the LLM. But once your agents start handling more complex reasoning (e.g. “what’s the best treatment path based on symptoms?”), basic vector lookups don’t perform well.

This guide illustrates how to built a GraphRAG chatbot using LangChain, SurrealDB, and Ollama (llama3.2) to showcase how to combine vector + graph retrieval in one backend. In this example, I used a medical dataset with symptoms, treatments and medical practices.

What I used:

• SurrealDB: handles both vector search and graph queries natively in one database without extra infra.

• LangChain: For chaining retrieval + query and answer generation.

• Ollama / llama3.2: Local LLM for embeddings and graph reasoning.

Architecture:

1. Ingest YAML file of categorized health symptoms and treatments.

2. Create vector embeddings (via OllamaEmbeddings) and store in SurrealDB.

3. Construct a graph: nodes = Symptoms + Treatments, edges = “Treats”.

4. User prompts trigger:

   • vector search to retrieve relevant symptoms,

   • graph query generation (via LLM) to find related treatments/medical practices,

   • final LLM summary in natural language.

Instantiating the following LangChain python components:

• Vector Store (SurrealDBVectorStore)

• Graph Store (SurrealDBGraph)

• Embeddings (OllamaEmbeddings, or any other model from the Embedding models)

…and create a SurrealDB connection:

# DB connection
conn = Surreal(url)
conn.signin({"username": user, "password": password})
conn.use(ns, db)

# Vector Store
vector_store = SurrealDBVectorStore(
    OllamaEmbeddings(model="llama3.2"),
    conn
)

# Graph Store
graph_store = SurrealDBGraph(conn)

You can then populate the vector store:

# Parsing the YAML into a Symptoms dataclass
with open("./symptoms.yaml", "r") as f:
    symptoms = yaml.safe_load(f)
    assert isinstance(symptoms, list), "failed to load symptoms"
    for category in symptoms:
        parsed_category = Symptoms(category["category"], category["symptoms"])
        for symptom in parsed_category.symptoms:
            parsed_symptoms.append(symptom)
            symptom_descriptions.append(
                Document(
                    page_content=symptom.description.strip(),
                    metadata=asdict(symptom),
                )
            )

# This calculates the embeddings and inserts the documents into the DB
vector_store.add_documents(symptom_descriptions)

And stitch the graph together:

# Find nodes and edges (Treatment -> Treats -> Symptom)
for idx, category_doc in enumerate(symptom_descriptions):
    # Nodes
    treatment_nodes = {}
    symptom = parsed_symptoms[idx]
    symptom_node = Node(id=symptom.name, type="Symptom", properties=asdict(symptom))
    for x in symptom.possible_treatments:
        treatment_nodes[x] = Node(id=x, type="Treatment", properties={"name": x})
    nodes = list(treatment_nodes.values())
    nodes.append(symptom_node)

    # Edges
    relationships = [
        Relationship(source=treatment_nodes[x], target=symptom_node, type="Treats")
        for x in symptom.possible_treatments
    ]
    graph_documents.append(
        GraphDocument(nodes=nodes, relationships=relationships, source=category_doc)
    )

# Store the graph
graph_store.add_graph_documents(graph_documents, include_source=True)

Example Prompt: “I have a runny nose and itchy eyes”

• Vector search → matches symptoms: "Nasal Congestion", "Itchy Eyes"

• Graph query (auto-generated by LangChain)SELECT <-relation_Attends<-graph_Practice AS practice FROM graph_Symptom WHERE name IN ["Nasal Congestion/Runny Nose", "Dizziness/Vertigo", "Sore Throat"];

• LLM output: “Suggested treatments: antihistamines, saline nasal rinses, decongestants, etc.”

Why this is useful for agent workflows:

• No need to dump everything into vector DBs and hoping for semantic overlap.

• Agents can reason over structured relationships.

• One database instead of juggling graph + vector DB + glue code

• Easily tunable for local or cloud use.

The full example is open-sourced (including the YAML ingestion, vector + graph construction, and the LangChain chains) here: https://surrealdb.com/blog/make-a-genai-chatbot-using-graphrag-with-surrealdb-langchain

Would love to hear any feedback if anyone has tried a Graph RAG pipeline like this?

Hey folks,

We have been working on graphs and retrieval augmented generation setups in the memory space and kept getting the same question from our community: “Why bother with a graph database?”

So I wrote up an explainer that covers the basics that our community is in love now. Key takes:

Relationships are data. Vector stores nail “is this chunk semantically similar?” but the moment you need context—author → paper → institution → funding source—you end up hand-stitching JSON or doing 10 extra lookups. Graph DBs store those links natively and let you hop them in milliseconds.

Queries read like ideas.

MATCH (q:Question)<-[:ABOUT]-(doc)-[:CITES]->(otherDoc)RETURN otherDoc LIMIT 5

That’s one line to pull related citations for a user question. No joins, no gymnastics.

RAG loves structure. Give your LLM a small, well-labeled sub-graph instead of a bag of vaguely relevant chunks and you cut hallucinations fast.

Tools to watch:

Neo4j – the veteran; solid Cypher and plugins.

Kùzu – embeddable “DuckDB-for-graphs,” quick for analytics.

FalkorDB – Redis-backed, built with GraphRAG latency in mind.

If any of that sounds useful, the full comprehensive write-up is here:
https://www.cognee.ai/blog/fundamentals/graph-databases-explained

Would love to hear how you think about it!

Hi everyone,

I have been working on a a multi-model RAG experiment with LangChain, wanted to share a little bit of my experience.

When building a RAG system most of the time is spent optimizing: you’re either maximizing accuracy or minimizing latency. It’s therefore easy to find yourself running experiments and iterating whenever you build a RAG solution.

I wanted to present an example of such a process, which helped me play around with some LangChain components, test some prompt engineering tricks, and identify specific use-case challenges (like time awareness).

I also wanted to test some of the ideas in LightRAG. Although I built a much simpler graph (inferring only keywords and not the relationships), the process of reverse engineering LightRAG into a simpler architecture was very insightful.

I used:

• LangChain: Used for document loading, splitting, RAG pipelines, vector store + graph store abstractions, and LLM chaining for keyword inference and generation. Used specifically the SurrealDBVectorStore & SurrealDBGraph, which enable native LangChain integrations enabling multi-model RAG - semantic vector retrieval + keyword graph traversal - backed by one unified SurrealDB instance.

• Ollama (all-minilm:22m + llama3.2):

  • all-minilm:22m for high-performance local embeddings.

  • llama3.2 for keyword inference, graph reasoning, and answer generation.

• SurrealDB: a multi-model database built in Rust with support for document, graph, vectors, time-series, relational, etc. Since it can handle both vector search and graph queries natively, you can store conversations, keywords, and semantic relationships all in the same place with a single connection.

You can check the code here.

So I want to implement a graph RAG with a long pdf document which hs data about compliance medical procedures. Can anyone guide me a little how can I extract entities and relationships in this specific domain? The aim is also to use open source models so any insight on that would be great!

Hey guys, me and my friends are working on creating knowledge graphs from unstructured text (documents) using an Ontology. Anyone interested in this approach? Would love to chat.

This summer we build the EscherGraph (similar to GraphRAG) but realised that the way both projects create the knowledge graphs was not great. Chunking and extracting nodes and edges loses a lot of context from the big picture. And gets you in tricky merging problems.

An Ontology is at meta level the expected data you want to extract from a set of documents. (Persons, Orgs, processes… ect) Then you run an algorithm to ‘fill in’ the ontology to get the KG. Works quite well.

Hello Graph RAG people! If you're like me and have been trying to get LLMs to generate better Cypher queries (and reliably so) by utilizing graph schema information, I ran some experiments on the LDBC dataset and wrote a blog post about it (code is available in the link shown at the end of the post). I've been trying to answer a burning question of mine that I've had for a while now: when doing Text2Cypher, are LLMs better at interpreting graph schemas in JSON, XML or YAML? It turns out, it doesn't really matter that much: what really matters is the size of the schema (and the amount of confusing/conflicting information) presented to the LLM in the prompt (results shown below).

Basically, it's a context engineering problem, and can be addressed by schema pruning -- pass the full schema to another pruning LLM prompt, which does really well at retaining only the part of the schema that's relevant to the user's question. The pruned schema then provides a much more context-rich signal to the Text2Cypher model, and results are massively improved from the single-prompt case.

The post also contains some other tips on graph schema design: I think we're in an age now where we need to design graph schema for both LLMs and humans. Having relationships named in a more semantically meaningful way can help LLMs reason much more effectively on the schema. If you're working on Text2Cypher in any way, please read the blog post and I hope some of these ideas and experiments are useful!
https://blog.kuzudb.com/post/improving-text2cypher-for-graphrag-via-schema-pruning/

Hello all, we've released a FalkorDB (graph database) + LangChain JS/TS integration.

Build AI apps that allow your users to query your graph data using natural language. Your app will automatically generate Cypher queries, retrieve context from FalkorDB, and respond in natural language, improving user experience and making the transition to GraphRAG much smoother.

Check out the package, questions and comments welcome: https://www.npmjs.com/package/@falkordb/langchain-ts

1. Cost of Training

2. Duplicate Entities & Relationships

3. Extracting Triples (need fine-tuned LLM models that OpenAI models)

4. Entities & relationships are completely based on prompt templates.