AmpliGraph: Knowledge Graph Embeddings on a TensorFlow 2 Back End

The gap AmpliGraph fills between a triple store and a link prediction score

A knowledge graph is a set of statements, usually written as subject, predicate, object. Asking whether an edge that is not in the graph should be there is a supervised learning problem, and doing it from scratch means writing a scoring function, a negative sampling scheme, a training loop and an evaluation protocol. AmpliGraph packages all four. The README lists four reasons to use it: discovering new knowledge from an existing graph, completing large graphs with missing statements, generating stand-alone embeddings, and developing or evaluating a new relational model. The audience is therefore not the analyst who wants a dashboard. It is the engineer or researcher who already has the triples and needs the model layer. The library also ships a Datasets submodule for loading graphs, which matters because the standard benchmarks (FB15K-237, WN18RR, YAGO3-10, FB15k, WN18) are the ones its published MRR table is computed on. If your graph is proprietary, the dataset helpers are less useful and you are bringing your own loader.

Embeddings plus a scoring function: the two-stage mechanism

The README describes the pipeline in two steps. First, the models generate knowledge graph embeddings, which it defines as vector representations of concepts in a metric space. Second, the library combines those embeddings with model-specific scoring functions to predict unseen and novel links. That separation is the whole design. The embedding table is shared machinery; the scoring function is what distinguishes TransE from DistMult from ComplEx from HolE from RotatE. AmpliGraph 2 ships those five, and the README says more are coming. The scoring function is also what determines which relation patterns a model can represent, which is why the MRR table is not a single ranking. ComplEx and RotatE both reach 0.51 on WN18RR while TransE reaches 0.22 there, yet TransE reaches 0.50 on YAGO3-10, the highest of any AmpliGraph model in that column. There is no model that wins everywhere, and the table makes that plain. The Compat submodule exists to extend the 2.x APIs back toward the 1.x ones for users already familiar with the older interface, which is a migration aid rather than a compatibility guarantee.

Installation, the develop branch, and the version string you should check

The stable path is a single command, pip install ampligraph, followed by importing the package and reading ampligraph.__version__, which the README shows returning '2.2.0'. The README states the prerequisites as Linux, macOS or Windows with Python 3.9 to 3.11, so a Python 3.12 or 3.13 environment is outside the documented range. For the development version the README gives a different sequence: clone the repository, cd AmpliGraph, git checkout develop, then uv sync. Note that this uses uv rather than pip, and that the sanity check on that path returns '2.2-dev' instead of a release number. The default branch in the repository metadata is develop, so a plain clone lands on the development line unless you check out a tag. The documentation itself can be built locally with cd docs followed by make clean autogen html. The README does not document the configuration keys for training runs in the excerpt available here, so the model hyperparameters and the exact call signatures are something you will have to read from the docs site or the source rather than from the README.

The 2.0 break is the first thing to plan around

The README is direct about this: version 2.0.0 moved to a TensorFlow 2 back end with Keras-style APIs, the data input/output pipeline changed, and support for some obsolete models was discontinued. The MRR table shows the consequence. ConvE and ConvKB appear only with the label AmpliGraph v1.4, and the text above the table says versions below 2.0 also include ConvE and ConvKB. So if your pipeline depends on either of those, the 2.x line does not have them. The Compat submodule softens the API surface change but does not restore the missing models. This is a real fork in the road rather than a footnote. Anyone upgrading from 1.x should treat the I/O pipeline change as the larger migration cost, since it touches data loading and evaluation rather than just the training call. The release cadence is also worth reading plainly: 2.0.1 in July 2023, 2.1.0 in February 2024, and 2.2.0 in July 2026. That is a gap of roughly two and a half years between the last two releases. A library on that cadence is stable, but you should not expect fast turnaround on an issue you file.

Reading the MRR table honestly, including the tie-breaking footnote

The evaluation section reports filtered MRR across five datasets and compares AmpliGraph's implementations against literature best figures, with citations to Lacroix et al. 2018 and Kadlec et al. 2017. The footnote is the part most readers skip and should not. It states that the results above assign the worst rank to a positive in case of ties, that this is the most conservative approach, and that some published literature may adopt a protocol that assigns the best rank instead. That single sentence changes how you should read every number in the table. If you benchmark AmpliGraph against a paper that used best-rank tie-breaking, a gap in the third decimal place may be an artifact of the protocol rather than a difference in model quality. The table also flags literature best values with asterisks pointing to different sources, so the comparison column is not internally consistent either. Treat the table as a statement about AmpliGraph's own implementations under one stated protocol, not as a neutral leaderboard.

Where AmpliGraph is the wrong tool

AmpliGraph predicts links between concepts. It is not a graph database, it does not store your triples, and it does not serve queries. If what you need is traversal, pattern matching or a query language over a live graph, this library is the wrong layer. It is also a poor fit for graphs where the relations are not the point. The models here learn from relation types, so a graph with a single predicate or with predicates that carry no consistent meaning gives the scoring functions little to work with. The TensorFlow 2 dependency is a second constraint: you inherit TensorFlow's install footprint and its own version compatibility rules on top of AmpliGraph's Python 3.9 to 3.11 window, which narrows the environments where both are satisfied. Finally, the model set is small by design. Five models in 2.x against a research literature that produces new scoring functions regularly means that if your result depends on a specific architecture not on the list, you are either extending a base estimator yourself or using something else.

What you give up compared with PyKEEN or DGL-KE

The obvious alternatives in this space are PyKEEN and DGL-KE, and the difference is not quality but scope and dependency weight. PyKEEN is built around a model registry that spans a much wider catalogue of knowledge graph embedding models and training pipelines, so it is the better choice when you want to try many scoring functions and compare them, or when you need a model AmpliGraph does not implement. DGL-KE sits on a graph deep learning framework and is oriented toward training at scale on multi-GPU or distributed setups. AmpliGraph's approach is narrower: a fixed set of five models, a TensorFlow 2 back end, a Keras-style API, and a set of high-level Discovery conveniences for clustering entities and predicting near duplicates that the README calls out as a separate module. That makes AmpliGraph a reasonable fit when you want a small, readable surface and you are already in a TensorFlow environment. It is a weaker fit when breadth of model choice or distributed training is the requirement.

Licence, maintenance and what to check before you depend on it

AmpliGraph is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant, but it also carries notice and attribution obligations you should route through your own legal review rather than treating as settled here. The README asks for a citation in academic work, with a BibTeX entry pointing at DOI 10.5281/zenodo.2595043, and the repository carries a Zenodo badge. Citations and stars are not maintenance signals, and the README's own line inviting readers to star the project is a request, not evidence of anything. What is evidence is the release history: three releases across roughly three years, with the most recent in July 2026. The project is not archived, the develop branch is active, and the documentation is built from the same repository. Before you build on it, confirm the Python version your environment actually runs, confirm whether you need ConvE or ConvKB (in which case you are on 1.4 and outside this line), and confirm that your evaluation harness matches the worst-rank tie-breaking the README documents, because that choice will decide whether your numbers are comparable to the table above.

Editorial conclusion

Adopt AmpliGraph if you have a triple store or a CSV of subject-predicate-object facts and you want a link predictor you can train and evaluate without writing a TensorFlow graph by hand. Do not adopt it if you need the ConvE or ConvKB models that only exist in the 1.x line, or if you need a model outside the five the 2.x README lists. Before committing, verify two things on your own data: that your Python version sits inside the 3.9 to 3.11 window the README states, and that your evaluation script uses the same tie-breaking rule as the MRR table, because the README notes that assigning the worst rank to a positive in case of ties is more conservative than the protocol some published results use.

Official sources

1. Accenture/AmpliGraph on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases