tendril-models

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

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)

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):

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.

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. [email protected] · [email protected] (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.