AutoSchemaKG: Letting a Knowledge Graph Design Itself

Building a knowledge graph usually starts with a whiteboard. An expert sits down and decides, in advance, what kinds of entities and relationships the graph will hold. In a recent Passion Academy session, Tamim Hussein looked at AutoSchemaKG, a framework that skips that step, and used alopecia areata (AA) research as a case study to show what that actually looks like in practice.

‍

Slides

‍

‍

‍

The Problem It’s Solving

‍

Picture Sara, a biomedical researcher, trying to turn a pile of AA papers into a structured graph. The traditional way is to design the schema first, deciding that:

‍

• E.g.  entities will be things like Gene, Protein, Cytokine, Immune cell, Drug and Disease
• Relationships will be things like encodes, inhibits and contributes to.

‍

Only then does she start reading papers and fitting each finding into those predefined boxes.

‍

The problem is that research moves faster than any fixed schema can. A paper comes along describing a new immune-cell subtype, or a treatment event, or a causal mechanism that doesn’t cleanly fit any existing category. Now Sara has to stop and revise the schema itself before she can carry on. In a fast-moving field, the schema stops being a helpful structure and starts being the thing slowing everything down.

‍

‍

What AutoSchemaKG Actually Is

‍

AutoSchemaKG isn’t one model, it’s a framework that coordinates several pieces working together. At the top sits the method itself, which handles extraction, concept-building and graph construction.

‍

Underneath that is atlas-rag, the actual Python package that runs the pipeline. That package calls on an LLM, such as Llama or Qwen, to do the reading and reasoning. The final output is a knowledge graph, exported as CSV or GraphML files, ready to load somewhere else.

‍

The paper behind it (Bai et al., ACL 2026) reports some genuinely large numbers from their own experiments: over 50 million documents processed, more than 900 million nodes, 5.9 billion edges, over 95% extraction precision,and measurable gains in both multi-hop question answering and factual accuracy.

‍

Note: These are the authors’ own benchmarks, not an independent test against a tool like Neo4j.

‍

‍

How It Builds a Graph, Step by Step

‍

The pipeline can be broken down into six stages, moving from raw papers to a finished graph.

‍

1. Prepare the papers. PDFs get converted to plain text, then cut into small chunks that fit within what the model can read at once and grouped into batches to keep things efficient.
2. ‍Pull out relationships. The model reads each chunk three times, looking for three different things: connections between entities (Baricitinib inhibits JAK1), connections between an entity and an event (Baricitinib is involved in “hair regrowth improved after treatment”), and connections between two events (JAK signalling decreased before inflammatory gene expression fell).‍
3. Assemble the facts into a graph. All of those extracted relationships come together into what’s effectively a web of specific facts: IFN-γ is produced, T cells accumulate around hair follicles, this contributes to alopecia areata. At this point, nothing has a general label yet. The graph knows that IFN-γ is produced, but nothing in it yet says “this is a cytokine.”‍
4. Figure out what each entity actually is. This is where the model looks at an entity’s surroundings, what it inhibits, what it treats, what it improve and uses that context to generate a few general labels for it. Baricitinib, surrounded by “inhibits JAK1” and “improves hair regrowth,” gets labelled as a JAK inhibitor (a Medication and a Therapeutic intervention). The surrounding context is what lets the model work out what something means specifically within this graph.‍
5. Do the same for events and relationships. An event like “Baricitinib increased hair regrowth after 36 weeks” gets its own general labels, like treatment response and clinical improvement. Relationships get the same treatment: “inhibits” generates labels like blocks and suppresses. Unlike step 4, this step doesn’t look at surrounding context, it works from the text alone.‍
6. Tidy up the labels into a shared layer. Many different entities will generate overlapping labels. Baricitinib and a second drug, Ritlecitinib, might both get labelled Medication and JAK inhibitor. This step deduplicates those matching phrases so they become shared nodes that multiple entities link back to. What it doesn’t do is organise those labels into a clean hierarchy. “JAK inhibitor” and “Medication” sit at very different levels of generality, and the pipeline doesn’t sort that out automatically.

‍

Put together, the finished graph connects the specific facts (gene → cytokine → pathway → disease mechanism → disease) to this general concept layer. This is what lets you ask a question like “what drug interrupts the pathway that leads to this disease?” and have the graph actually trace a path to the answer.

‍

‍

What “Dynamic” Does and Doesn’t Mean

‍

“Dynamic” here means the labels and categories come from whatever is in the corpus you feed it, so a different set of papers produces a different set of concepts. It does not mean the graph is constantly rewriting itself in real time as new information arrives.

‍

Feeding in a new paper still means running it through the same extraction and labelling steps, matching it against existing entities where possible and merging the result into the graph. This is  a process that needs something external to trigger it. New facts and labels get added but the existing structure doesn’t get reorganised from scratch every time. In practice, this is closer to a scheduled batch job than a live, self-updating system.

‍

‍

Where It Still Needs a Human

‍

The paper is upfront about some of its own limits. The model’s biases and blind spots carry straight through into the graph, since extraction is only as good as the LLM doing it. Highly specialised, technical fields are genuinely hard to organise well. And in places where the source material is sparse, the resulting graph can end up with gaps or inconsistencies.

‍

A few more practical gaps are worth naming:

‍

• The system won’t automatically notice that “Drug” and “Medication” are the same idea unless something reconciles them.
• It has no way to adjudicate when two papers contradict each other, both findings just sit in the graph side by side.
• The general labels it generates don’t form a tidy hierarchy on their own.
• Things like security, backups, access control and monitoring are entirely outside its scope.

‍

This is a research pipeline, not production infrastructure. Automating the construction of a graph doesn’t remove the need for someone to govern it.

‍

‍

How It Relates to Neo4j

‍

A natural question is whether this replaces a graph database like Neo4j. It doesn’t, because the two are solving different problems.

‍

‍

‍

A System That Uses Both

‍

Put together, a realistic setup looks like a short pipeline

‍

• Papers go into AutoSchemaKG, which produces a rough graph of entities, events, relationships and labels.
• A person then reviews that output, merging duplicate labels, resolving contradictions and applying real domain judgment.
• Only after that does the cleaned-up graph get loaded into Neo4j, where it can be queried reliably by a research tool or application.

‍

Each part does the piece it’s actually good at. AutoSchemaKG does the heavy lifting of reading and structuring raw text. A human reviewer brings judgment the system doesn’t have. Neo4j brings the reliability and query performance you need once the graph is actually being used for something.

‍

‍

The Takeaway

‍

AutoSchemaKG solves a real and specific problem: in a field that moves quickly, designing a schema by hand becomes the bottleneck on getting new findings into a usable graph. Letting the structure emerge from the literature itself removes that bottleneck.

‍

What it doesn’t do is replace judgment. It will still mix up synonyms, leave contradictions unresolved and need a human to decide what actually matters (especially in a field like medicine where getting it wrong has real consequences). Used as a fast way to get a first draft of a graph off the ground, rather than a finished, production-ready system, it’s a genuinely useful tool.

‍

‍

References

‍

• Bai et al., “AutoSchemaKG: Autonomous Knowledge Graph Construction through Dynamic Schema Induction from Web-Scale Corpora,” ACL 2026
• Official implementation: HKUST-KnowComp/AutoSchemaKG and the atlas-rag Python package
• Neo4j GraphRAG Python Knowledge Graph Builder, GraphSchema and entity resolution documentation

‍