Pith. sign in

REVIEW 3 major objections 4 minor 4 cited by

Rethinking Chunk Size For Long-Document Retrieval: A Multi-Dataset Analysis

T0 review · 3 major / 4 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read This paper claims that in fixed-size chunked retrieval, the optimal chunk size is set by answer locality and embedding-model context design: 64-128 tokens for fact-based answers, 512-1024 tokens for dispersed or technical answers.

desk verdict Useful recall tables and a defensible chunk-size heuristic, but the model-sensitivity claim contradicts the paper's own Table 2 and the missing coverage baseline undermines the causal reading. read the letter →

arxiv 2505.21700 v2 pith:QPLL27O4 submitted 2025-05-27 cs.IR

Sinchana Ramakanth Bhat , Max Rudat , Jannis Spiekermann , Nicolas Flores-Herr This is my paper
classification cs.IR
keywords chunksizeretrieval-augmentedgenerationlong-documentretrievalrecall@kembeddingmodelsanswerlocalityfixed-sizechunkingRAGevaluation
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper tries to establish that chunk length is a first-order control on retrieval quality in long-document retrieval-augmented generation, not a background detail. Across six question-answering datasets and two embedding models, it compares fixed-size chunks of 64 to 1024 tokens and measures Recall@k. It reports that small chunks win on datasets with short, entity-like answers, while large chunks are needed where answers are dispersed or require technical context. It also claims the best chunk size depends on the retriever: a long-context decoder-style model benefits from large chunks, while an encoder-style model holds its own on small chunks and fine-grained matching. If correct, practitioners can choose chunk size from answer locality and model context window instead of relying on a single default.

What carries the argument

The central mechanism is a controlled sweep over fixed-size token chunks, with Recall@k as the probe. Documents are split into non-overlapping chunks of 64, 128, 256, 512, and 1024 tokens, each chunk is embedded, and the top-k chunks by cosine similarity are retrieved. The datasets are chosen to vary document length, answer length, answer locality, and question density, and the paper reads recall differences against those statistics. The explanatory variable is answer locality, defined as whether the correct span sits near the question-similar text or is dispersed across the document. Model properties carry the second half of the argument: Stella is a decoder-based retriever with a very long context window, while Snowflake is an encoder-based retriever with a shorter context window, and the paper attributes their different chunk-size sensitivities to this architectural difference.

What would settle it

Run the same six datasets at chunk sizes 64 through 1024 but retrieve a fixed token budget, for example enough top chunks to sum to 1024 tokens, and recompute Recall@k; if small-chunk retrieval matches large-chunk retrieval at equal budget, the reported chunk-size advantage is a coverage artifact rather than a context-quality effect.

Watch

Extended reading notes

Core claim

The paper's central claim is that retrieval effectiveness in fixed-size chunked RAG is jointly determined by chunk size, dataset answer characteristics, and embedding-model architecture. In the reported experiments, SQuAD peaks at 64-token chunks (Recall@1 of 64.1% for Stella), with recall dropping 10-15% at 512 tokens, while TechQA improves from about 4.8% to 71.5% Recall@1 at 1024 tokens and NarrativeQA rises from 4.2% to 10.7% as chunks grow. The paper interprets these trends through answer locality: concise, localized spans favor small chunks, while dispersed or context-heavy answers favor large chunks. It further claims model sensitivity is architecture-driven, with Stella leveraging global context at 512-1024 tokens and Snowflake performing competitively on small chunks through entity-based matching. The paper concludes that chunk size selection should be dataset- and model-aware, and that current evaluation lacks intrinsic chunk-quality measures.

Load-bearing premise

The conclusions about broader context assume that comparing Recall@k across chunk sizes is fair even though a larger chunk mechanically covers much more document text, so some of the measured gain could simply be a wider net rather than better retrieval.

Editorial extensions

If this is right

  • For fact-centric corpora resembling SQuAD, retrieval pipelines should use 64-128 token chunks; for narrative or technical corpora, 512-1024 token chunks are safer.
  • Chunk size should be treated as a tunable hyperparameter alongside the embedding model, since a single default chunk size will sacrifice recall on one class of questions.
  • Long-context decoder-style embedding models can exploit large chunks, while encoder-style models with shorter context windows should be paired with smaller chunks or evaluated primarily on entity-matching tasks.
  • Dataset builders can stitch shorter QA pairs into longer synthetic documents to create long-document testbeds, but the resulting answer-locality patterns must be reported because they change chunk-size conclusions.
  • String-match based Recall@k is workable but limited; the reported chunk-size rankings should be confirmed with semantic relevance metrics before being used as design rules.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The paper's large-chunk advantage may be partly a coverage artifact: a 1024-token chunk contains sixteen times as much document text as a 64-token chunk, so Recall@k can rise even if retrieval quality per token is unchanged, and the paper does not compare against a coverage-matched baseline.
  • A direct test of that confound is to fix a retrieval token budget across chunk sizes, for example retrieving enough top chunks to sum to 1024 tokens; if small-chunk retrieval matches large-chunk retrieval at equal budget, the reported size effect is mostly coverage rather than context understanding.
  • The architecture-based explanation suggests a testable prediction the paper does not run: other long-context decoder-style embedders should show the same large-chunk preference, and short-context encoder embedders should follow Snowflake, which could be checked without new datasets.
  • Answer-length and answer-locality statistics could be turned into a cheap chunk-size selector for new corpora, a practical extension the paper points toward but does not construct.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 4 minor

Summary. The paper evaluates fixed-size token chunking (64, 128, 256, 512, and 1024 tokens) for retrieval in a LlamaIndex-based RAG pipeline with two embedding models, Stella and Snowflake, over six QA datasets, four of which are stitched into synthetic long documents. It reports Recall@1 through Recall@5 for every configuration and interprets the results as showing that small chunks suit concise, fact-based answers, that large chunks help dispersed or technical answers, and that embedding models differ in chunk-size sensitivity. The main contribution is the systematic ablation table and the practical guidance it offers to retrieval practitioners.

Significance. The manuscript addresses a timely and practical question: how fixed-size chunking interacts with dataset type and embedding model in RAG retrieval. Its strengths are the multi-dataset coverage, the transparent reporting of full R@1-R@5 values in Table 2, and the public code repository. If the coverage confound were controlled and the model-specific claims corrected, the finding that optimal chunk size depends on answer dispersion and retriever behavior would be a useful empirical guide. As written, however, the headline causal and model-specific conclusions are not yet supported by the reported results.

major comments (3)
  1. [Section 4.1, Section 4, Table 2] The headline causal claim that larger chunks are necessary for datasets with descriptive or technical responses is not supported by the reported metric. Recall@k is defined as the answer chunk appearing in the top k results, and no coverage or random-retrieval baseline is reported. For a document of D tokens and a single answer, a uniform random retriever has expected Recall@1 approximately equal to c/D under fixed chunk size c, so the mechanical success floor grows linearly with chunk size. The gains at 512-1024 tokens in NarrativeQA, NQ, TechQA, and NewsQA are therefore consistent with a coverage artifact and do not by themselves demonstrate that broader context improves retrieval quality. Please report a coverage-normalized metric, such as observed Recall@k divided by the expected random baseline, or include a random-chunk retriever as a control for every row of Table 2, and re-state the interpretations in Sections 4.1 and 4.2 in terms of that controlled comparison.
  2. [Section 4.3 vs Table 2] The model-sensitivity claim is contradicted by the paper's own Table 2. Section 4.3 states that 'Stella demonstrates stronger performance at larger chunk sizes (512-1024 tokens), improving recall@1 by 5-8% compared to Snowflake in long-document datasets (NarrativeQA, NQ, TechQA).' In Table 2, NQ at 1024 tokens gives Snowflake R@1 = 0.4774 versus Stella R@1 = 0.3493, and TechQA at 1024 gives Snowflake 0.7154 versus Stella 0.6192; at 512 tokens, NQ also favors Snowflake (0.3895 vs 0.3854). Only NarrativeQA shows a slight Stella advantage at 1024 tokens. In addition, Section 4.1 reports that Snowflake peaks at 1024 tokens on COVID-QA, which conflicts with the claim that Snowflake 'deteriorates at larger chunk sizes.' The analysis in Section 4.3 must be corrected to match the data, or the claim should be restricted to the specific datasets and chunk sizes where it actually holds.
  3. [Section 3, Table 1, Section 4.2] Four of the six datasets (NewsQA, COVID-QA, TechQA, SQuAD) are stitched from unrelated QA pairs into synthetic documents of at least 50,000 characters. The dataset-characteristic explanations in Section 4.2, such as 'document structure,' 'answer locality,' and 'well-structured Wikipedia text,' are partly derived from these artificial documents, where chunk boundaries can cut across originally separate documents and neighboring chunks are semantically unrelated. The limitations section acknowledges that some datasets 'contain synthetic structures,' but the conclusions are still stated unconditionally. Please separate the results for natural long documents (NarrativeQA and NQ) from the stitched documents, and either analyze the stitched data at the level of the original documents or present them as a separate stress test rather than as direct evidence about long-document retrieval.
minor comments (4)
  1. [Section 4.2] In the SQuAD discussion, the sentence 'Even at 64 tokens, recall@1 remains high (64.1%), increasing marginally with larger chunks' is contradicted by Table 2, which shows a monotonic decline for both models as chunk size increases (Stella R@1 falls from 0.6419 at 64 tokens to 0.3855 at 1024 tokens).
  2. [Section 4] The phrase 'the trends remain conistent' should read 'the trends remain consistent.'
  3. [Abstract and Conclusion] The summary statements that 'Stella benefits from larger chunks' and 'Snowflake performs better with smaller chunks' overgeneralize the results; Table 2 shows Snowflake outperforming Stella at 1024 tokens on NQ and TechQA, so the abstract and conclusion should be qualified to match the corrected analysis.
  4. [Section 4, Table 2] No confidence intervals or significance tests are reported; since the Recall@1 values are averages over large query sets, a paired bootstrap or McNemar test would help determine whether small differences, such as the 1-2% differences used to support model-sensitivity claims, are statistically reliable.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the paper is an empirical chunk-size ablation with fixed settings, no fitted-parameter prediction loop, and no load-bearing self-citation.

full rationale

This paper reports a systematic empirical evaluation of fixed-size chunking across six QA datasets and two embedding models. It does not derive a prediction from a fitted model, does not estimate parameters and then 'predict' a quantity already determined by those parameters, and does not invoke a self-citation chain to force its conclusions. The comparison of Recall@k across chunk sizes is an experimental measurement with stated fixed settings (chunk sizes 64-1024 tokens, LlamaIndex TokenTextSplitter, no overlap, Stella and Snowflake embeddings). The authors' interpretations of why certain chunk sizes help are causal hypotheses about answer locality and model architecture, but these interpretations are not circular: they are not defined in terms of the outcome metric, and no equation in the paper reduces the reported trend to an identity. The reader-identified coverage concern (a 1024-token chunk covers more document text than a 64-token chunk, so larger-chunk recall gains may partly reflect mechanical coverage rather than retrieval understanding) is a validity or confound limitation, not a circularity pattern in the sense of self-definition, fitted-input-as-prediction, or self-citation load-bearing reasoning. The paper explicitly acknowledges related limitations in Section 5, including string-matching evaluation and synthetic document stitching, which further shows these are recognized empirical caveats rather than hidden definitional moves. No fitted values are reused as predictions, no author-overlapping citations provide load-bearing support, and no ansatz is smuggled in via citation. Therefore the appropriate circularity score is 0.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

The central claim is an empirical pattern, not a derivation, so the ledger contains no fitted constants or invented entities. The load-bearing assumptions are the string-match relevance definition, the validity of stitched long documents, and the implicit assumption that chunk coverage does not distort recall comparisons; the first and third are not tested, and the second is flagged in the paper's limitations.

assumptions (3)
  • domain assumption String matching between the expected answer and document text defines whether an answer is present and whether a chunk is the relevant retrieval target.
    Invoked in Section 3 (filtering by string match) and Section 4 (success = relevant chunk in top k). The authors' own Section 5 notes string matching may not capture semantic relevance.
  • ad hoc to paper Recall@k comparisons across chunk sizes are valid without a coverage-normalized or random-retrieval baseline.
    Unstated in Section 4; without it, the advantage of larger chunks may be a mechanical artifact of covering more text per retrieved item.
  • ad hoc to paper Stitched documents formed by concatenating QA pairs approximate naturally long documents.
    Section 3 states four datasets were stitched to reach a minimum of 50,000 characters; Section 5 concedes 'some contain synthetic structures'.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Rethinking Chunk Size For Long-Document Retrieval: A Multi-Dataset Analysis." pith.science (2026). https://pith.science/paper/QPLL27O4

@misc{pith2026250521700,
  author       = {Pith},
  title        = {Pith review of: Rethinking Chunk Size For Long-Document Retrieval: A Multi-Dataset Analysis},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/QPLL27O4}},
  note         = {Machine review of arXiv:2505.21700}
}
read the original abstract

Chunking is a crucial preprocessing step in retrieval-augmented generation (RAG) systems, significantly impacting retrieval effectiveness across diverse datasets. In this study, we systematically evaluate fixed-size chunking strategies and their influence on retrieval performance using multiple embedding models. Our experiments, conducted on both short-form and long-form datasets, reveal that chunk size plays a critical role in retrieval effectiveness -- smaller chunks (64-128 tokens) are optimal for datasets with concise, fact-based answers, whereas larger chunks (512-1024 tokens) improve retrieval in datasets requiring broader contextual understanding. We also analyze the impact of chunking on different embedding models, finding that they exhibit distinct chunking sensitivities. While models like Stella benefit from larger chunks, leveraging global context for long-range retrieval, Snowflake performs better with smaller chunks, excelling at fine-grained, entity-based matching. Our results underscore the trade-offs between chunk size, embedding models, and dataset characteristics, emphasizing the need for improved chunk quality measures, and more comprehensive datasets to advance chunk-based retrieval in long-document Information Retrieval (IR).

Discussion (0). Sign in to comment.

Forward citations

Cited by 4 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. An Agile Method for Implementing Retrieval Augmented Generation Tools in Industrial SMEs

    cs.CL 2025-08 conditional novelty 6.0 of 10

    EASI-RAG is a structured agile method for deploying RAG tools in industrial SMEs, validated by one case study where a no-experience team built a working assistant in three weeks.

  2. Cross-Attention Calibrated Deduplication for Retrieval-Augmented Generation System

    cs.CL 2026-07 conditional novelty 5.5 of 10

    CACD deduplicates RAG chunks via cross-encoder scores, attention-entropy NIS, and majority vote, dropping ~9.75% of chunks on SQuAD faster than cosine filtering.

  3. RAG Strategies for Natural Language-Based SQL Query and REST API Call Generation

    cs.SE 2026-02 conditional novelty 5.0 of 10

    In a 631-case enterprise benchmark, iterative retrieval (CoRAG) achieved 10.29% exact match vs 7.45% for standard RAG on combined SQL/API generation with hybrid documentation, while no-RAG gives 0% exact match.

  4. The Effect of Text Chunk Size on Retrieval-Augmented Generation Performance

    cs.IR 2026-06 reject novelty 3.0 of 10

    The paper reports paragraph chunks best for a math textbook and sentence chunks best for a narrative, but its conclusion says the opposite for narrative and never measures generation quality.

Reference graph

Works this paper leans on

31 extracted references · 17 canonical work pages · cited by 4 Pith papers

  1. [1]

    Jasper and stella: distillation of sota embedding models, 2025

    Dun Zhang, Jiacheng Li, Ziyang Zeng, and Fulong Wang. Jasper and stella: distillation of sota embedding models, 2025

    work page 2025

  2. [2]

    Leveraging passage retrieval with generative models for open domain question answering, 2021

    Gautier Izacard and Edouard Grave. Leveraging passage retrieval with generative models for open domain question answering, 2021

    work page 2021

  3. [3]

    Rae, Erich Elsen, and Laurent Sifre

    Sebastian Borgeaud, Arthur Mensch, Jordan Hoffmann, Trevor Cai, Eliza Rutherford, Katie Millican, George van den Driessche, Jean-Baptiste Lespiau, Bogdan Damoc, Aidan Clark, Diego de Las Casas, Aurelia Guy, Jacob Menick, Roman Ring, Tom Hennigan, Saffron Huang, Loren Maggiore, Chris Jones, Albin Cassirer, Andy Brock, Michela Paganini, Geoffrey Irving, Ori...

    work page 2022

  4. [4]

    Retrieval-augmented generation for large language models: A survey, 2024

    Yunfan Gao, Yun Xiong, Xinyu Gao, Kangxiang Jia, Jinliu Pan, Yuxi Bi, Yi Dai, Jiawei Sun, Meng Wang, and Haofen Wang. Retrieval-augmented generation for large language models: A survey, 2024

    2024

  5. [5]

    Peters, and Arman Cohan

    Iz Beltagy, Matthew E. Peters, and Arman Cohan. Longformer: The long-document transformer, 2020

    2020

  6. [6]

    Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni, and Percy Liang

    Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni, and Percy Liang. Lost in the middle: How language models use long contexts, 2023

    2023

  7. [7]

    End-to-End Training of Neural Retrievers for Open-Domain Question Answering

    Devendra Singh Sachan, Mostofa Patwary, Mohammad Shoeybi, Neel Kant, Wei Ping, William L Hamilton, and Bryan Catanzaro. End-to-end training of neural retrievers for open-domain question answering. arXiv preprint arXiv:2101.00408, 2021

    work page Pith review arXiv 2021

  8. [8]

    DuReadervis: A Chinese dataset for open-domain document visual question answering

    Le Qi, Shangwen Lv, Hongyu Li, Jing Liu, Yu Zhang, Qiaoqiao She, Hua Wu, Haifeng Wang, and Ting Liu. DuReadervis: A Chinese dataset for open-domain document visual question answering. In Smaranda Muresan, Preslav Nakov, and Aline Villavicencio, editors,Findings of the Association for Computational Linguistics: ACL 2022, pages 1338–1351, Dublin, Ireland, M...

    work page 2022

Show all 31 references
  1. [9]

    Retrieval-augmented generation for knowledge-intensive nlp tasks

    Patrick Lewis, Ethan Perez, Aleksandra Piktus, Fabio Petroni, Vladimir Karpukhin, Naman Goyal, Heinrich Küttler, Mike Lewis, Wen-tau Yih, Tim Rocktäschel, Sebastian Riedel, and Douwe Kiela. Retrieval-augmented generation for knowledge-intensive nlp tasks. In Proceedings of the...

    2020

  2. [10]

    Ye Liu, Kazuma Hashimoto, Yingbo Zhou, Semih Yavuz, Caiming Xiong, and Philip S. Yu. Dense hierarchical retrieval for open-domain question answering, 2021

    2021

  3. [11]

    Is semantic chunking worth the computational cost?, 2024

    Renyi Qu, Ruixuan Tu, and Forrest Bao. Is semantic chunking worth the computational cost?, 2024

    2024

  4. [12]

    Mix-of-granularity: Optimize the chunking granularity for retrieval-augmented generation

    Zijie Zhong, Hanwen Liu, Xiaoya Cui, Xiaofan Zhang, and Zengchang Qin. Mix-of-granularity: Optimize the chunking granularity for retrieval-augmented generation. arXiv preprint arXiv:2406.00456, 2024

    2024 arXiv

  5. [13]

    Bert: Pre-training of deep bidirectional transformers for language understanding

    Jacob Devlin, Ming-Wei Chang, Kenton Lee, and Kristina Toutanova. Bert: Pre-training of deep bidirectional transformers for language understanding. In Proceedings of the 2019 conference of the North American chapter of the association for computational linguistics: human langu...

    2019

  6. [14]

    Roberta: A robustly optimized bert pretraining approach

    Yinhan Liu, Myle Ott, Naman Goyal, Jingfei Du, Mandar Joshi, Danqi Chen, Omer Levy, Mike Lewis, Luke Zettlemoyer, and Veselin Stoyanov. Roberta: A robustly optimized bert pretraining approach. arXiv preprint arXiv:1907.11692, 2019. 6 A PREPRINT - AUGUST 19, 2025

    1907 arXiv

  7. [15]

    Dense passage retrieval for open-domain question answering

    Vladimir Karpukhin, Barlas Oguz, Sewon Min, Patrick SH Lewis, Ledell Wu, Sergey Edunov, Danqi Chen, and Wen-tau Yih. Dense passage retrieval for open-domain question answering. In EMNLP (1), pages 6769–6781, 2020

    2020

  8. [16]

    Unsupervised dense information retrieval with contrastive learning, 2022

    Gautier Izacard, Mathilde Caron, Lucas Hosseini, Sebastian Riedel, Piotr Bojanowski, Armand Joulin, and Edouard Grave. Unsupervised dense information retrieval with contrastive learning, 2022

    2022

  9. [17]

    Unsupervised dense information retrieval with contrastive learning, 2021

    Gautier Izacard, Mathilde Caron, Lucas Hosseini, Sebastian Riedel, Piotr Bojanowski, Armand Joulin, and Edouard Grave. Unsupervised dense information retrieval with contrastive learning, 2021

    2021

  10. [18]

    Gomez, Lukasz Kaiser, and Illia Polosukhin

    Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N. Gomez, Lukasz Kaiser, and Illia Polosukhin. Attention is all you need, 2023

    2023

  11. [19]

    Roformer: Enhanced transformer with rotary position embedding, 2023

    Jianlin Su, Yu Lu, Shengfeng Pan, Ahmed Murtadha, Bo Wen, and Yunfeng Liu. Roformer: Enhanced transformer with rotary position embedding, 2023

    2023

  12. [20]

    Smith, and Mike Lewis

    Ofir Press, Noah A. Smith, and Mike Lewis. Train short, test long: Attention with linear biases enables input length extrapolation, 2022

    2022

  13. [21]

    On faithfulness and factuality in abstractive summarization

    Joshua Maynez, Shashi Narayan, Bernd Bohnet, and Ryan McDonald. On faithfulness and factuality in abstractive summarization. arXiv preprint arXiv:2005.00661, 2020

    2005 arXiv

  14. [22]

    Long range arena: A benchmark for efficient transformers

    Yi Tay, Mostafa Dehghani, Samira Abnar, Yikang Shen, Dara Bahri, Philip Pham, Jinfeng Rao, Liu Yang, Sebastian Ruder, and Donald Metzler. Long range arena: A benchmark for efficient transformers. arXiv preprint arXiv:2011.04006, 2020

    2011 arXiv

  15. [23]

    LlamaIndex, 11 2022

    Jerry Liu. LlamaIndex, 11 2022

    2022

  16. [24]

    The NarrativeQA reading comprehension challenge

    Tomáš Koˇciský, Jonathan Schwarz, Phil Blunsom, Chris Dyer, Karl Moritz Hermann, Gábor Melis, and Ed- ward Grefenstette. The NarrativeQA reading comprehension challenge. Transactions of the Association for Computational Linguistics, 6:317–328, 2018

    2018

  17. [25]

    Dai, Jakob Uszkoreit, Quoc Le, and Slav Petrov

    Tom Kwiatkowski, Jennimaria Palomaki, Olivia Redfield, Michael Collins, Ankur Parikh, Chris Alberti, Danielle Epstein, Illia Polosukhin, Jacob Devlin, Kenton Lee, Kristina Toutanova, Llion Jones, Matthew Kelcey, Ming-Wei Chang, Andrew M. Dai, Jakob Uszkoreit, Quoc Le, and Slav...

    2019

  18. [26]

    NewsQA: A machine comprehension dataset

    Adam Trischler, Tong Wang, Xingdi Yuan, Justin Harris, Alessandro Sordoni, Philip Bachman, and Kaheer Suleman. NewsQA: A machine comprehension dataset. In Phil Blunsom, Antoine Bordes, Kyunghyun Cho, Shay Cohen, Chris Dyer, Edward Grefenstette, Karl Moritz Hermann, Laura Rimel...

    2017

  19. [27]

    COVID-QA: A question answering dataset for COVID-19

    Timo Möller, Anthony Reina, Raghavan Jayakumar, and Malte Pietsch. COVID-QA: A question answering dataset for COVID-19. In Karin Verspoor, Kevin Bretonnel Cohen, Mark Dredze, Emilio Ferrara, Jonathan May, Robert Munro, Cecile Paris, and Byron Wallace, editors, Proceedings of t...

    2020

  20. [28]

    The TechQA dataset

    Vittorio Castelli, Rishav Chakravarti, Saswati Dana, Anthony Ferritto, Radu Florian, Martin Franz, Dinesh Garg, Dinesh Khandelwal, Scott McCarley, Michael McCawley, Mohamed Nasr, Lin Pan, Cezar Pendus, John Pitrelli, Saurabh Pujar, Salim Roukos, Andrzej Sakrajda, Avi Sil, Rosa...

    2020

  21. [29]

    SQuAD: 100,000+ questions for machine comprehension of text

    Pranav Rajpurkar, Jian Zhang, Konstantin Lopyrev, and Percy Liang. SQuAD: 100,000+ questions for machine comprehension of text. In Jian Su, Kevin Duh, and Xavier Carreras, editors, Proceedings of the 2016 Conference on Empirical Methods in Natural Language Processing , pages 2...

    2016

  22. [30]

    Arctic-embed 2.0: Multilingual retrieval without compromise, 2024

    Puxuan Yu, Luke Merrick, Gaurav Nuti, and Daniel Campos. Arctic-embed 2.0: Multilingual retrieval without compromise, 2024

    2024

  23. [31]

    Qwen2 technical report, 2024

    An Yang, Baosong Yang, Binyuan Hui, Bo Zheng, Bowen Yu, Chang Zhou, Chengpeng Li, Chengyuan Li, Dayiheng Liu, Fei Huang, Guanting Dong, Haoran Wei, Huan Lin, Jialong Tang, Jialin Wang, Jian Yang, Jianhong Tu, Jianwei Zhang, Jianxin Ma, Jianxin Yang, Jin Xu, Jingren Zhou, Jinze...

    2025

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.