# itext2kg: three research lines for building knowledge graphs with LLMs

> The itext2kg repository gathers the work behind three papers on knowledge graph construction with large language models: iText2KG for incremental graphs, ATOM for dynamic temporal graphs, and C-Unseen for finding weak signals in those graphs. It is a research codebase with a work in progress badge, a heavy dependency floor around LangChain and Neo4j, and measured gains that are the authors' own claims.

**AuvaLab/itext2kg** — We build KGs the way nature builds matter

- Repository: https://github.com/AuvaLab/itext2kg
- Stars: 980 · Forks: 106
- Language: Python
- License: Apache-2.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/auvalab-itext2kg

## Three papers in one package

The repository is a portfolio rather than a single library. The README opens by saying that it brings together three complementary lines of work from Yassir Lairgi's PhD, and names them with their venues.

The first is iText2KG, Incremental Knowledge Graphs Construction Using Large Language Models, from WISE 2024. The second is ATOM, AdapTive and OptiMized dynamic temporal knowledge graph construction using LLMs, from the Findings of EACL 2026. The third is C-Unseen, Weak Signal Detection in Dynamic Temporal Knowledge Graphs via LLM Reasoning, from WISE 2026. Each has its own arXiv link and badge, and the legacy documentation for the original library is kept in a separate file, README_itext2kg.md, which tells you that the current README covers all three and the old one covers only the first.

The badges tell you two more things. The status badge says Work in Progress, which is an unusual thing to state plainly and is worth taking at face value. And the package is on PyPI as itext2kg, with a download badge, so it is distributed rather than being a research folder of scripts.

The overall promise is in the title line: construct your knowledge graph, static, temporal, or temporal-dynamic, and detect weak signals. That is three different jobs, and they build on each other. iText2KG turns documents into a graph. ATOM makes that graph dynamic, with time. C-Unseen reads the evolving graph and reports the structures that are rare but coherent and growing, which is a research question about temporal graphs rather than a construction task.

The audience is therefore two: researchers reproducing or extending the papers, and engineers prototyping document-to-graph extraction who want a reference implementation that handles the awkward parts, such as entity disambiguation and temporal attribution.

## iText2KG: incremental construction with an async core

The original line of work is the foundation, and its changelog in the README is a list of practical engineering decisions.

The 19/07/2025 entry describes a migration of the core methods to async and await for non-blocking I/O with the LLM APIs, a logging system replacing print statements, improved batch processing for handling multiple documents and LLM calls, and better error handling with retry mechanisms. Each of those matters more in this domain than it would in an ordinary library, because a graph build is a long sequence of LLM calls, and a library that blocks the event loop or prints to stdout is unusable in a batch job.

The 29/07/2025 entry adds a simpler variant, iText2KG_Star, which directly extracts relationships and eliminates the separate entity extraction step, reducing token consumption. It also adds facts-based construction using a Document Distiller, and support for building dynamic knowledge graphs that evolve over time, with a notebook as the example. That entry carries an important caveat: the temporal and logical conflicts resolution is not handled in this version.

Earlier entries are about the details that make a graph usable. From 07/10/2024, the code was refactored with data models for Entity, Relation and KnowledgeGraph, and entities are embedded using both their name, at a weight of 0.6, and their label, at 0.4, so that concepts that share a name stay apart, with Python the language and Python the snake as the example. A max_tries parameter was added to build_graph to handle LLM hallucinations. From 17/09/2024, compatibility with all LangChain chat and embedding models, and a build_graph that can expand an existing graph rather than only create one.

The pattern across those entries is a library that started as a research artefact and grew the parts a production user would demand: models, retries, logging, and a way to extend a graph instead of rebuilding it.

## ATOM: atomic facts, dual time and parallel merging

The ATOM line, from the 20/10/2025 entry, is a complete architectural redesign of the dynamic temporal construction, and it is where the engineering content is.

The pipeline is three modules running in parallel. The first decomposes text into minimal atomic facts, and the reason given is the forgetting effect, where an LLM omits facts when the context is long. Splitting first means each extraction call sees a small unit, which is the standard answer to that problem. The second module extracts 5-tuples of subject, predicate, object, t_start and t_end directly from those atomic facts, in parallel. The third merges the atomic facts into the graph with a parallel pairwise merge algorithm.

The dual-time modelling is the detail with the most downstream consequences. The implementation distinguishes t_obs, when the fact was observed, from t_start and t_end, when it was true, and the stated purpose is to prevent temporal misattribution in dynamic knowledge graphs. Without that split, a document written in 2025 about an event in 2019 produces a graph that says the event happened in 2025, which is the kind of error that makes a temporal graph useless for historical questions.

The merge step is where the claimed performance numbers come from, and they are the project's own. A 93.8 per cent latency reduction against Graphiti and 95.3 per cent against iText2KG, achieved by replacing slow LLM-based resolution with distance metrics, cosine similarity, for scalable parallel merging. The construction gains are quoted as roughly 31 per cent in factual exhaustivity, roughly 18 per cent in temporal exhaustivity and roughly 17 per cent in stability.

Those figures are claims from the authors' evaluation, and the repository has an evaluation directory, so the honest way to read them is as results you would want to reproduce on your own documents before relying on them. The mechanism behind the speedup, replacing an LLM call with a distance metric, is the part that transfers: it is the obvious way to make merging parallel, and it is also a change in behaviour, since a similarity threshold is not the same as a reasoning step.

The 04/09/2026 entry adds two ready to run builders under useful_scripts, one that produces a temporal or dynamic graph from dated texts and one that produces a static graph from a PDF, and it adds optional domains on atomic facts so that facts can be labelled and filtered, with the default remaining empty so that behaviour is unchanged.

## C-Unseen: defining and finding a weak signal

The third line of work, released on 04/09/2026 alongside the ATOM scripts, is the most novel and the least conventional.

It starts by defining the thing it looks for. A weak signal in a dynamic temporal knowledge graph is a rare, semantically coherent subgraph that proliferates across consecutive TKG snapshots. Three properties matter in that sentence. The subgraph is rare, so it is not part of the dominant narrative of the snapshot. It is semantically coherent, so it means something rather than being an artefact of extraction noise. And it proliferates over time, so it appears in several consecutive snapshots, which is what separates a signal from a one-off anomaly.

The pipeline has two modules. The Rare Subgraphs Extractor uses chain of thought reasoning from the LLM to identify subgraphs that are in tension with the dominant narrative of the snapshot. The Weak Signal Alerter then tracks persistence and corroboration across time, which is the part that operationalises the definition.

The result is self-interpretable: the rare and weak-signal labels are written back onto the graph so that a person can inspect them. That is a deliberate design choice in a research area where the usual complaint is that a model found something and nobody can see why.

The claim in the README is that this outperforms keyword, topic and graph based weak-signal baselines. That is a comparison against methods that do not use an LLM, and it is the interesting result of the paper, since the obvious alternative to paying for model calls is a cheap statistical filter. The trade is cost and latency against a reasoning step that can notice a pattern whose words do not appear together anywhere.

## The dependency floor: LangChain, Neo4j and the document stack

The requirements file shows what this kind of library drags in, and it is worth reading before committing.

The core is LangChain, with langchain at about 0.3.26, langchain-core at about 0.3.69 and langchain-openai at about 0.2.0, plus langchain-experimental for the tokenization utilities. The compatibility with all LangChain chat and embedding models, stated in the 17/09/2024 changelog entry, is the practical consequence of sitting on that layer: the model provider is pluggable, but the framework version is not, and the ranges are pinned narrowly.

Storage is Neo4j, at 5.28 or newer and below 6.0, with the openai client at 1.97 or newer. A knowledge graph library that targets Neo4j means the graph is a Neo4j database, with its own driver, its own connection handling and its own deployment story. The openai client is a direct dependency as well as the LangChain provider, which suggests some calls go straight to the API rather than through the abstraction.

Document handling is well covered: pypdf, pymupdf for PDF text and layout, openpyxl for spreadsheets, pandas for the data frames around them, and tiktoken for counting tokens, which matters because token consumption is the main cost driver in this kind of tool and the iText2KG_Star variant exists to reduce it. Dates are handled with python-dateutil, which is central to the dual-time modelling in ATOM. The data model and configuration use pydantic and pydantic-settings, and the science stack is numpy and scikit-learn, with scikit-learn also relevant to the cosine similarity merging. The test tools are pytest and pytest-asyncio, the latter matching the async rewrite of the core methods.

That is a heavy floor for a library, and it is the honest cost of building on a general LLM framework rather than on raw HTTP calls.

## Where the code lives and how to try the pieces

The repository layout separates the three lines in a way that a reader can follow. The itext2kg directory holds the package itself, the useful_scripts directory holds the ready to run builders added in September 2026, and those two are the two entry points worth starting from:

```text
useful_scripts/build_atom_kg_from_json.py
useful_scripts/build_atom_kg_from_pdf.py
```

The first takes dated texts and produces a temporal or dynamic graph. The second takes a PDF and produces a static one. Between them they cover the two most common starting points, and running them is a faster way to understand the code than reading the modules.

The other directories are the supporting work. The evaluation directory holds the evaluation code behind the quoted exhaustivity and latency numbers. The datasets directory holds data used with that code, and the docs directory holds the documentation and the banner images the README uses. The tests directory is there, and MANIFEST.in, setup.cfg and a pyproject.toml with setuptools as the build backend describe the packaging.

The README also links a demo badge to the examples directory, and the 29/07/2025 entry names one notebook by path, the dynamic knowledge graph construction example, which is a good indication of what the examples are for: showing the shape of a graph built over time from a series of dated documents.

The split between the current README and the legacy one, README_itext2kg.md, matters more than it looks. The current README is organised around papers and their changelogs, and the legacy file is the original library documentation. A reader looking for how to call the original API will find it there, and a reader looking for what the project currently believes about temporal graph construction will find that at the top.

## Adoption: what to verify before you build on it

The first thing to establish is which of the three lines you actually want, because they overlap in the same package and promise different things. iText2KG builds a graph from documents and can extend one. ATOM builds a dynamic temporal graph with dual time and parallel merging. C-Unseen reads a dynamic temporal graph and reports weak signals. If your problem is static extraction from PDFs, the third line is irrelevant, and if your problem is a graph over time, the first line's dynamic support comes with a documented gap.

That gap is the most important limitation in the repository, and it is stated in the changelog rather than buried: the temporal and logical conflicts resolution is not handled in the dynamic knowledge graphs version. In plain terms, when two documents disagree about the same fact, the library does not decide which is right, and the two statements can coexist in the graph. ATOM's dual-time modelling reduces misattribution of time, but it is not conflict resolution, and the two should not be confused.

The second limitation is the obvious one for this class of tool: the output is only as good as the model and the prompt, and the quality numbers in the README are the authors' own evaluation on their own data. The 31 per cent exhaustivity gain and the 95 per cent latency reduction are claims you should either reproduce or treat as context. The mechanism behind the latency claim, cosine similarity instead of an LLM for merging, is a real design decision with real consequences, since a threshold is a different kind of judgement than a model call.

The third is the operational one: repeated LLM calls are expensive and slow, and the async rewrite and the reduced token consumption of the Star variant are both answers to that. Budget for it before designing around it.

The licence is Apache-2.0, with the LICENSE file at the repository root, which permits commercial use and modification with the notice preserved, and this describes the published terms rather than legal advice. The release record shows v1.1.0 for C-Unseen on 2026-09-04, v1.0.0 for ATOM on 2025-10-28 and v0.0.9 for iText2KG on 2025-09-01, so the versions track the newest research line rather than the oldest. The repository is not archived, with the last push on 2026-09-04.

## Conclusion

Adopt itext2kg when you are prototyping knowledge graph extraction from documents and want the architecture of three published approaches in one place, and when you can live with the research code quality and the LangChain and Neo4j dependency floor. It is the wrong tool for a production pipeline that needs guaranteed conflict resolution, because the dynamic graph version states that temporal and logical conflicts are not handled, and it is the wrong tool for a budget that cannot absorb repeated LLM calls. Before building on it, decide which of the three lines you actually want, because they overlap in the package and differ in what they guarantee, and read the legacy README_itext2kg.md, which still documents the original library.

## FAQ

### What is the itext2kg repository?

It brings together three research lines on knowledge graph construction with large language models: iText2KG for incremental graph construction, ATOM for dynamic temporal graph construction, and C-Unseen for weak signal detection in dynamic temporal knowledge graphs. The package is published on PyPI as itext2kg.

### What is a weak signal in a dynamic temporal knowledge graph?

According to the C-Unseen work, it is a rare, semantically coherent subgraph that proliferates across consecutive TKG snapshots. The pipeline has a Rare Subgraphs Extractor that uses LLM chain of thought to find subgraphs in tension with the dominant snapshot narrative, and a Weak Signal Alerter that tracks persistence and corroboration over time.

### What does ATOM do differently from the original iText2KG?

ATOM uses a three-module parallel pipeline that first decomposes text into atomic facts to counter the forgetting effect, then extracts 5-tuples of subject, predicate, object, t_start and t_end, then merges them with a parallel pairwise algorithm. It also models dual time, t_obs against t_start and t_end, to prevent temporal misattribution.

### Does itext2kg resolve conflicting facts?

Not in the dynamic knowledge graphs version. The README states that temporal and logical conflicts resolution is not handled there, so two contradictory statements can both end up in the graph. The dual-time modelling in ATOM reduces misattribution of dates rather than resolving contradictions.

### What are the main dependencies of itext2kg?

The requirements file lists LangChain and its OpenAI provider, the Neo4j driver, the OpenAI client, PDF and spreadsheet handling through pypdf, pymupdf and openpyxl, pandas, tiktoken, pydantic and pydantic-settings, numpy and scikit-learn, python-dateutil for date handling, and pytest with pytest-asyncio for the tests.

## Sources

- [AuvaLab/itext2kg on GitHub](https://github.com/AuvaLab/itext2kg)
- [Issues](https://github.com/AuvaLab/itext2kg/issues)
- [License: Apache-2.0](https://github.com/AuvaLab/itext2kg/blob/main/LICENSE)
- [README](https://github.com/AuvaLab/itext2kg/blob/main/README.md)
- [Releases](https://github.com/AuvaLab/itext2kg/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/auvalab-itext2kg