Instructions to use abdelkarim98/tendril-models with libraries, inference providers, notebooks, and local apps. Follow these links to get started.
- Libraries
- Transformers
How to use abdelkarim98/tendril-models with Transformers:
# Load model directly from transformers import AutoModel model = AutoModel.from_pretrained("abdelkarim98/tendril-models", device_map="auto") - Notebooks
- Google Colab
- Kaggle
TENDRIL β trained roles for cheap multi-hop RAG
The two small trained models behind TENDRIL, the system in What Does a Reasoning Tree's LLM Budget Buy? A Cost Audit of Multi-Hop Retrieval-Augmented Generation and a Four-Call Alternative.
- π» Code: https://github.com/abdelkarim-choukri/TENDRIL-RAG
- π Paper: arXiv link pending β added on announcement
- βοΈ Licence: MIT
The one-line claim these models support: in multi-hop RAG the gap between cheap and expensive systems is retrieval-buyable, not call-buyable. Extra LLM generation buys almost nothing; re-retrieving evidence inside the reasoning chain buys most of the gap, at zero extra LLM calls. These are the models that do the retrieving.
What is in this repository
| folder | params | size on disk | role |
|---|---|---|---|
rtrag_builder_v1/ |
184M | 712 MB | the Builder β a DeBERTa-v3-base cross-encoder used three times over: scoring the initial pool, scoring newly retrieved chunks, and rescoring candidates conditioned on partial chains. Also does per-hop re-retrieval at inference. |
rtrag_decomposer_t5/ |
247M | 476 MB | the planner β a flan-T5-base fine-tuned to split a multi-hop question into at most four single-hop sub-questions with #1β#3 placeholders. Used only by the all-small TENDRIL-S configuration. |
rtrag_builder_v1/ config.json model.safetensors head.pt report.json
added_tokens.json special_tokens_map.json
spm.model tokenizer.json tokenizer_config.json
rtrag_decomposer_t5/ config.json generation_config.json model.safetensors
special_tokens_map.json spiece.model
tokenizer.json tokenizer_config.json
head.pt is the Builder's linear scoring head and is required β the
cross-encoder is a base encoder plus that head, not a SequenceClassification
checkpoint you can load standalone.
Download
git clone https://github.com/abdelkarim-choukri/TENDRIL-RAG && cd TENDRIL-RAG
bash scripts/fetch_weights.sh
That places them exactly where the code looks for them:
checkpoints/rtrag_builder_v1/
checkpoints/rtrag_decomposer_t5/
which are the defaults of src/rtrag_decomp_probe.py --builder,
src/rtrag_probe2_rescore.py --model and configs/tendril*.json. Or directly:
from huggingface_hub import snapshot_download
snapshot_download("abdelkarim98/tendril-models",
allow_patterns="rtrag_builder_v1/*",
local_dir="checkpoints", local_dir_use_symlinks=False)
Intended use
In scope. Research on retrieval quality for multi-hop question answering: reranking, chain-aware evidence assembly, and question decomposition, in the LongBench v1 / HotpotQA / 2WikiMultihopQA / MuSiQue setting these were trained and measured on. The Builder is a reranker β it scores a (query, chunk) pair; it does not generate text. The planner rewrites a question into sub-questions; it does not answer them.
Out of scope. Neither model answers questions, checks facts, or judges truth. The Builder's score is a relevance score, not a correctness signal β the paper reports a separate negative result showing chain completeness is not readable from this score geometry (a 22-feature gate reaches only AUC 0.73β0.75, and 0.60 on MuSiQue, near chance). Do not use these as a filter for factual reliability. Both were trained on English Wikipedia-derived corpora and carry whatever biases those contain.
Training
The Builder. Supervision requires no LLM at all. 6,000 questions per dataset from the public training-side splits, paragraphs pooled into an RT-RAG-style corpus and chunked with RT-RAG's chunker; a chunk is gold if and only if its source document is one of that question's own supporting paragraphs β document identity, not title match, which on MuSiQue would introduce false positives. A second family of pools replays round 1 of the deployment loop, which is what teaches the model to score conditioned queries. Together 21,471 listwise groups, trained with a group softmax.
Hyper-parameters, read from the shipped rtrag_builder_v1/report.json:
base_model deberta-v3-base-squad2 epochs 2 (epoch 0 selected)
lr 1e-05 batch_groups 2
max_len 352 seed 42
The planner. Two thirds of its supervision is free and gold: MuSiQue
publishes question decompositions (19.5k) and 2Wiki's evidence triples
template into sub-questions (12.0k). HotpotQA publishes none, so for that
third (~9k) the 14B's own planning outputs are distilled offline. This is the
one place a large model is used in training anything here, it is a one-off
pass over ~9k training questions rather than over a corpus, and it applies to
rtrag_decomposer_t5 only.
All 200 LongBench evaluation ids and the 400-question development ids are excluded from every training source.
Evaluation
Builder, validation pools (from report.json, shipped in the checkpoint)
| split | metric | HotpotQA | 2Wiki | MuSiQue |
|---|---|---|---|---|
| plain (n=400 each) | full-chain@15 | 0.835 | 0.465 | 0.4675 |
| plain (n=400 each) | anchor@15 | 1.000 | 1.000 | 0.990 |
| conditioned | top-3 hit | 0.9459 | 0.9447 | 0.7802 |
| conditioned | top-1 hit | 0.8108 | 0.8894 | 0.6154 |
| conditioned | n | 37 | 199 | 91 |
These are single-pass validation numbers on training-side pools, which is what the checkpoint's own record contains. They are not the deployed front-end result and should not be quoted as it β the two conditioned splits in particular are small (n = 37 on HotpotQA).
Deployed system, LongBench v1 (n = 200 per dataset)
The full Stage 0 pipeline β bge retrieval, two rounds of anchor-conditioned
re-querying, the cond2 rescore and the seating rule β reaches full-chain
coverage of 0.940 / 0.870 / 0.655, which is +6.0 / +14.0 / +12.5 points
over RT-RAG's own front end, at zero LLM calls on both sides.
End to end, with a Qwen2.5-14B-Instruct reader and RT-RAG's own evaulate.py
scorer (EM):
| system | LLM calls/q | HotpotQA | 2Wiki | MuSiQue |
|---|---|---|---|---|
| TENDRIL-1 (front end + 1 call) | 1 | 47.0 | 49.0 | 27.5 |
| TENDRIL-S (planner from this repo) | 3.45 | 47.0 | 58.0 | 31.0 |
| TENDRIL | 4.31 | 48.0 | 64.0 | 39.0 |
| RT-RAG reasoning tree (our reproduction) | 47.9β103.4 | 51.0 | 65.5 | 38.0 |
A paired per-question sign test cannot distinguish TENDRIL from the reproduced tree on any dataset, in exact match (p = 0.41 / 0.73 / 0.87) or under a blind LLM judge (p = 0.50 / 0.60 / 0.18).
No F1 parity is claimed. Pooled over n = 600 the F1 deficit is statistically detectable (β3.33, p = 0.039). And although TENDRIL's MuSiQue EM exceeds the tree's, both F1 and the judge favour the tree there, so no MuSiQue win is claimed either. A high p-value is evidence of no difference detected at this sample size, never evidence that two systems are equal.
Limitations
- In-domain training is required. The Builder must be trained on retrieval pools from its target domain. A prompt-based system adapts to a new dataset by writing examples into a prompt; this one does not.
- Local open-weight readers only. Everything reported was measured with locally served open-weight generators. Whether the central finding holds for a frontier API model is untested and unclaimed.
- One benchmark family, one seed. LongBench v1's three multi-hop subsets at
n = 200 each, one run per configuration. Two cells are too small to support
conclusions on their own: MuSiQue 4-hop (n = 15) and 2Wiki
inference(n = 26). - Depth hurts. Front-end coverage on MuSiQue falls 0.729 β 0.610 β 0.067 from two hops to four. At four hops a complete chain is assembled for about one question in fifteen, so accuracy there is limited by evidence, not by reasoning.
Provenance
These two checkpoints are the artifacts that produced the paper's numbers. Note honestly: no SHA-256 of either was recorded in the project's own documentation before publication here. The hashes below were computed at upload time (2026-09-08) and are the first written record.
| file | sha256 (first 16) |
|---|---|
rtrag_builder_v1/model.safetensors |
4656f79df348dec0 |
rtrag_builder_v1/head.pt |
fa5a87b78ac850fc |
rtrag_decomposer_t5/model.safetensors |
ab5e5a391994245b |
The code in the GitHub repository is byte-identical to the code that produced
the results, and that is recorded β see PROVENANCE.md there.
Citation
@article{choukri2026tendril,
title = {What Does a Reasoning Tree's {LLM} Budget Buy? A Cost Audit of
Multi-Hop Retrieval-Augmented Generation and a Four-Call Alternative},
author = {Choukri, Abdelkarim and Deng, Xiang},
year = {2026},
note = {arXiv preprint}
}
Contact
Abdelkarim Choukri Β· Xiang Deng β School of Computer Science and Technology,
Harbin Institute of Technology, Shenzhen.
24sf51014@stu.hit.edu.cn Β· choukriabde98@outlook.com (permanent backup).
Acknowledgement
RT-RAG's authors released their code, which is the only reason a cost audit of it was possible. RT-RAG's code is not redistributed here or in the GitHub repository; it is cloned from its own repository under its own licence.
Model tree for abdelkarim98/tendril-models
Base model
google/flan-t5-base