AdvancedLiterateMachinery: Alibaba's OCR and Document Understanding Monorepo
A collection of original, innovative ideas and algorithms towards Advanced Literate Machinery. This project is maintained by the OCR Team in the Language Technology Lab, Tongyi Lab, Alibaba Group.
At a glance
- What is it?
- Advanced Literate Machinery is a C++ and Python research repository from Alibaba's Tongyi Lab that bundles OCR models, document parsing toolchains and benchmarks. It is a collection of separate projects rather than one installable package, and that shape decides who can use it.
- Who is it for?
- Adopt it if you are researching scene text recognition, document parsing or OCR-centric evaluation and you are willing to work per-subdirectory, because there is no single install. Do not adopt it if you need a supported, versioned library with an upgrade path; the newest release listed is v1.7.0-gem-model-release from 2024-04-02, and the last push was on 2026-03-17.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Activity is slowing. The repository last received commits 6 months ago.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Advanced Literate Machinery actually is
The README states the long-term goal plainly: build a system that can "read, think and create", and start by teaching machines to read from images and documents. That framing matters, because it explains why the repository is organised the way it is. It is not a library with a stable API. It is a monorepo of research artefacts from the 读光 OCR Team in the Tongyi Lab at Alibaba Group, grouped into AIGC/, Applications/, Benchmarks/, DocumentUnderstanding/, OCR/ and resources/.
The problems it addresses are concrete even if the packaging is not. Scene text recognition in images, key information extraction from visually situated text, table structure recognition, layout analysis, web page understanding from render trees, and evaluation of large multimodal models on OCR-centric tasks. Each of those is a separate subdirectory with its own paper, its own model and, usually, its own way of being run.
The intended audience is researchers and engineers who already know which task they need. Someone looking for a single import that reads a PDF will be disappointed. Someone evaluating a text spotting architecture, or building a document parsing pipeline out of published components, will find the pieces here.
How the subprojects fit together: shared ideas, separate code
A pattern runs through the 2024 releases, and it is worth naming because it tells you what to expect inside each directory. OmniParser, released under OCR/, handles text spotting, key information extraction and table recognition in one model. The README describes the unifying choices: a shared encoder-decoder architecture, a single objective called point-conditioned text generation, and one input and output representation built from prompts and structured sequences. Three tasks that were historically three pipelines become one sequence generation problem.
Platypus, also under OCR/, applies the same instinct to text in different forms, using what the README calls a single unified architecture instead of choosing between a specialist and a generalist model. SceneVTG sits under AIGC/ and inverts the direction: a multimodal large language model proposes text regions and contents, and a conditional diffusion model renders them into images.
So the architecture is not one system. It is a family of models that share a research thesis, that unified representations beat task-specific pipelines, and share almost no runtime. Data flows in per project: images or HTML in, structured sequences or generated images out. There is no top-level service, no shared inference server, and no common configuration layer that the README documents.
Getting started: there is no single install
The top-level README does not give installation instructions. It gives release notes, papers and links. Each subdirectory is where setup lives, and the README points at ModelScope for several of the underlying models, noting that most of the algorithmic models in the DocXChain toolchain come from modelscope/modelscope. That is the honest starting point: pick your subdirectory first, then read that directory's README.
The repository URL appears in the README's own links, and the directory names are the ones listed at the top level, so the first step is simply obtaining the code and opening the folder you need. The README does not print a clone command, so use the repository URL as given:
git clone https://github.com/AlibabaResearch/AdvancedLiterateMachinery.gitAfter that, the README is silent on what to run. It does not document a requirements file, a Python version, a CUDA version, or a model download step for any subdirectory. What it does document is where the models come from: ModelScope for most of DocXChain's algorithmic models, and RapidLatexOCR for formula recognition, with whole PDF conversion to JSON format supported in DocXChain under Applications/. Everything else has to be read from the individual subdirectory, because the top-level document does not carry it.
Where it breaks down: no top-level versioning or upgrade path
The most serious limitation is structural. The repository has no top-level package, no pinned dependency set and no documented compatibility matrix. Releases are per model, not per repository: v1.7.0-gem-model-release, v1.6.0-LaTeX-OCR-models, v1.4.0-LISTER-release. If you depend on two subprojects, you own the job of reconciling their environments yourself.
That also means there is no upgrade story in the usual sense. The README does not document rollback, migration between model versions, or deprecation policy. A research monorepo of this kind tends to accumulate directories at different levels of freshness, and nothing in the top-level document tells you which are current.
It is also the wrong tool for production document ingestion at scale. There is no server, no batching API and no throughput or latency claim anywhere in the README, and I would not assume one. If your requirement is a maintained extraction service with operational guarantees, this repository is a source of models and ideas, not the service. The same applies if you need something you can install with a single package manager command and forget about.
The alternative: a packaged document conversion library
The closest thing to a drop-in alternative in the related searches is Docling, and the difference is exactly the one that matters here. Docling is a packaged library: you install it, you point it at a document, you get structured output. Advanced Literate Machinery is a set of research subdirectories where you choose a model, supply the environment, and often handle weights yourself.
The trade-off is real in both directions. A packaged library gives you an install command, a version number and a changelog, and it hides the model choices from you. This repository gives you the individual architectures, the papers and the training data behind them, which is what you want if you are reproducing a result or adapting a model to a domain the packaged tool does not cover. It is not what you want if the conversion itself is the whole task.
The same distinction applies to layout work. If your interest is layout analysis on DocLayNet or D4LA, this repository is one source among several, and the README does not claim to cover every layout model family.
Licence, maintenance and what an upgrade costs
The repository is Apache-2.0, which permits commercial use and modification with the usual attribution and notice requirements. That is a permissive starting point, but it applies to this repository's code. Individual subprojects may pull models from ModelScope, and DocXChain explicitly does for most of its algorithmic models, with formula recognition drawn from RapidLatexOCR. Those components carry their own terms, and the top-level README does not enumerate them. Check each dependency's licence before shipping anything, and treat this as a technical inventory task rather than a legal opinion.
On maintenance: the repository is not archived, and the last push was on 2026-03-17. The most recent release listed, however, is v1.7.0-gem-model-release from 2024-04-02, and the newest items in the README's update log are the 2024.12 and 2024.9 releases. Commits and releases are telling different stories, so read the subdirectory you care about rather than the repository as a whole.
The upgrade cost follows from the structure. Because there is no shared version, upgrading means re-reading a subdirectory's README, re-checking its weights and re-testing your pipeline against whatever changed in that folder alone. Budget for that per subproject, not once.
Editorial conclusion
Adopt it if you are researching scene text recognition, document parsing or OCR-centric evaluation and you are willing to work per-subdirectory, because there is no single install. Do not adopt it if you need a supported, versioned library with an upgrade path; the newest release listed is v1.7.0-gem-model-release from 2024-04-02, and the last push was on 2026-03-17. Before committing, open the subdirectory you actually need and check whether it ships weights, a requirements file and a runnable entry point, because the top-level README documents the research, not the setup.
Frequently asked questions
What is Advanced Literate Machinery in OCR?
It is a research repository from the 读光 OCR Team in Alibaba's Tongyi Lab, whose stated goal is to build systems that can read, think and create, starting with reading from images and documents. In practice it collects OCR, document understanding and AIGC subprojects such as OmniParser, Platypus, DocXChain and SceneVTG under one Apache-2.0 repository.
How do I install AdvancedLiterateMachinery?
There is no top-level install. The README gives no installation steps, so you obtain the repository and work from the subdirectory you need, installing that subproject's dependencies and obtaining its model weights separately. DocXChain, for example, draws most of its models from ModelScope and uses RapidLatexOCR for formula recognition.
Is AdvancedLiterateMachinery a replacement for Docling or other document parsing libraries?
Not directly. Docling is a packaged library you install and run, while this repository is a set of separate research subprojects with per-model releases and no shared versioning. It suits reproducing or adapting published models; a packaged library suits straightforward document conversion.
Community notes