A community project on Hugging Face has put a large multilingual training ground for reinforcement learning (RL) on the Hub. FineEnvs, by Adithya S. Kolavi, released two OpenEnv environments with roughly 12 million tasks in total: document OCR over a million pages in 22 languages, and read speech over all 102 FLEURS languages. The project README gives the underlying counts; we found no source for any "largest open RL library" claim, so treat that label as unverified.
The more useful part for builders is the proof of concept. The author trained Gemma 4 E4B with GRPO on each environment for Kannada and reports 16 percent fewer character errors on OCR and 45 percent fewer on speech recognition. This post explains what is in the release, reads the numbers critically, and shows how to start.
Quick reference: what was released
| Question | Answer (per the README and Hub collection) |
|---|---|
| Who? | Adithya S. Kolavi, via the FineEnvs organization on Hugging Face and GitHub |
| What? | Two OpenEnv servers: Nayana OCR and FLEURS multilingual ASR |
| Size | Nayana: 1,006,170 pages, 22 languages, 11M tasks. FLEURS: 102 languages, 1,151,940 tasks |
| Also served | Sarvam Indic OCR Bench (evaluation splits) and the FLEURS test and validation splits |
| Trained models | kannada-ocr-grpo and kannada-asr-grpo (Gemma 4 E4B plus LoRA adapters) |
| Compute | One A100: 10.5 h for OCR, 4.7 h for ASR |
| License | Code Apache 2.0; FLEURS CC BY 4.0; Nayana pages and the OCR adapter CC BY-NC 4.0 |
| Independent check | None found yet for the Kannada gains or the "largest" claim |
What are RL environments, and why does this one matter?
In RL for language models, an environment is the thing that hands the model a task, scores the answer and returns a reward. The model then updates toward answers that earn more reward. We covered the Hub-side plumbing in our guide to Hugging Face putting RL environments on the Hub, and the same pattern shows up in OpenAI's Lean math environments in Harbor format and in the TermGrade terminal environments.
Most of those released environments are about code, math or terminals. Multilingual perception is far thinner. Reading a Kannada document or transcribing Kannada speech is a task with a verifiable answer, which is exactly what RL needs, yet there have been few open environments for it. This release fills that gap with real scale: Nayana contributes 11 million tasks from just over a million pages, and FLEURS contributes more than a million speech tasks across 102 languages.
How do the two environments work?
Both servers follow the same design, described in the README:
- The environment owns the task and the reward. The trainer only handles task IDs, so you can swap the training library without rewriting the scoring.
- Data stays in a bucket. Pages and clips are fetched one at a time, so you never download the whole corpus up front.
- Every checkpoint is scored while the run trains. A second job follows the run's bucket, loads each new adapter into a vLLM engine, scores it on held-out data and logs it to Trackio.
- Every change is paired against the untuned model, item by item, with a 95 percent interval.
The two environments also differ in what the model is asked to do. The Nayana OCR server covers document OCR, layout detection and visual question answering over the million pages, with Sarvam Indic OCR Bench served as evaluation-only splits scored by Sarvam's own metrics.py. The FLEURS ASR server covers transcription, verbatim transcription and language identification, scored per word or per character depending on the script. Both trained runs used the reward 0.8 x (1 - character error) + 0.2 x exact match.
Reward signal guiding a model toward better answers in a multilingual RL environment
What did the Kannada runs show?
The author used Gemma 4 E4B with LoRA adapters trained by GRPO, a group-relative RL method, and held out the data the model was scored on.
Reading (OCR). Trained on 4,000 Kannada text crops from Nayana, the model was tested on the Kannada part of Sarvam Indic OCR Bench, 300 crops it never trained on:
| Metric | Base | Trained | Change (95% CI) |
|---|---|---|---|
| Character error rate | 0.4277 | 0.3602 | -0.068 (-0.083, -0.052) |
| Word error rate | 0.773 | 0.747 | -0.026 (-0.038, -0.014) |
| Outputs that slip into another script | 12.3% | 4.7% | not reported |
Hearing (ASR). Trained on every Kannada clip in FLEURS, tested on the 838 Kannada test clips:
| Metric | Base | Trained | Change (95% CI) |
|---|---|---|---|
| Character error rate | 0.1047 | 0.0571 | -0.048 (-0.057, -0.039) |
| Word error rate | 0.312 | 0.243 | -0.069 (-0.079, -0.059) |
| Transcripts that slip into another script | 20.8% | 1.6% | not reported |
How to read these numbers honestly
The project README itself says the OCR gain comes mostly from the model learning to stay in the Kannada script. The script-slip rate falling from 12.3 to 4.7 percent supports that. In plain terms, a large share of the improvement is the model stopping an obvious failure, not learning to read Kannada glyphs far better. That is still valuable, but it is a narrower claim than "OCR improved 16 percent" suggests.
The ASR gain is bigger, and also easier to explain: the base model wrote transcripts in the wrong script about one time in five, and the trained one almost never does. Word error rate improved less (31.2 to 24.3 percent), so a trained model still gets roughly one word in four wrong on FLEURS Kannada. The ASR test set is also FLEURS, the same family the model trained on, so the OCR result on a benchmark it never saw is the better generalization evidence.
There is a useful engineering lesson in the README. The ASR run "only worked once the trainer actually fed the model the audio": TRL 1.13 drops audio features from the forward pass that its loss is computed from, so earlier runs trained on transcripts the model had not heard. Images are not dropped, so the OCR half never hit this. If you train a multimodal model with RL, verify that the modality actually reaches the loss before you trust a reward curve.
How does this compare with dedicated speech models?
Do not read the Kannada gain as a competitor to purpose-built recognizers. It is a recipe showing that a general multimodal model can be pushed toward a language with verifiable rewards on one GPU. For ready-made small recognizers, see Tether's TranscribePsy for European languages or Cactus Whistle for tiny on-device models. FineEnvs is more interesting as raw material: if you want a model for a language that those releases do not cover, this is a free, scored practice ground.
It also fits a pattern in the broader FineEnvs collection. Other projects there include a GeoGuesser environment where a 4B model outscored gpt-5.4-mini and claude-haiku-4.5, and a multi-harness run training a small model inside OpenCode, Claude Code, Codex and Mini-SWE-Agent. That echoes the small-model-beats-big-model results we tracked in Coinbase's fine-tuned Qwen3.5 9B and in the wider open-source RL-as-a-service stacks.
Why verifiable rewards suit OCR and speech
RL works best where the grader cannot be argued with. Code has unit tests and math has a final answer. Transcription has a reference text, so the reward can be computed from character error and exact match with no LLM judge in the loop. That removes a major source of noise and reward hacking, the failure mode we saw discussed in OpenAI's work on metagaming in RL evals. It also means a small team can afford the run: one A100 for under half a day each.
The catch is that character error rewards one thing only. A model can lower it by copying the script correctly while still mishandling names, numbers or layout. That is why the author keeps the paired, held-out evaluation running during training and publishes every held-out prediction in the runs dataset, so you can inspect the failures and not just the averages.
Licensing: check before you ship
The code is Apache 2.0 and FLEURS is CC BY 4.0, which is permissive. But the Nayana pages and annotations, from CognitiveLab, are CC BY-NC 4.0, and the README says the OCR adapter trained on them carries the same non-commercial license. Sarvam Indic OCR Bench is Apache 2.0, with credit to Sarvam AI. If you plan a commercial product on the OCR side, you would need to train on different data.
How to try it
- Start at the FineEnvs Hugging Face organization and open the "Multilingual Multimodal Envs" collection.
- Read
ocr/README.mdorasr/README.mdin the GitHub folder; each has DESIGN, LEARNINGS and REPRODUCE pages with the exact commands. - Use the playground Spaces (
nayana-ocr-env,fleurs-asr-env) to see tasks and rewards before you train. - Reproduce the Kannada run on a single A100 through the provided Hugging Face Jobs launcher, then swap in your own language from the 22 or 102 available.
- Evaluate on a held-out benchmark, not only on the data family you trained on.
What to watch next
- Independent replication. The numbers come from the author's own runs with paired intervals; nobody outside the project has reproduced them yet.
- Scale comparisons. Task counts depend on how you count a task; one page can yield many tasks.
- Other languages. The release trains only Kannada. How well the recipe transfers to the other 21 OCR and 101 speech languages is untested here.
Details reflect the FineEnvs README and Hugging Face collection as of October 14, 2026.
Related reading
- Hugging Face puts RL environments on the Hub: what OpenEnv means
- OpenAI Lean math RL environments in Harbor format
- TermGrade: 1,004 terminal RL environments
- Open-source RL as a service: post-training stacks
- Tether TranscribePsy open speech model
- Coinbase's fine-tuned Qwen3.5 9B beats frontier models on fraud
- Official: FineEnvs on Hugging Face and the multilingual project README
