HyPE: Moving the RAG Question–Document Gap into Indexing

The paper in 90 seconds

• Problem: A standard dense RAG system embeds the user’s question and compares it with declarative document chunks. The question sounds like “what do I need to find?” while the document sounds like “what is described here?” The mismatch is stylistic as well as semantic.
• Core insight: HyPE (Hypothetical Prompt Embeddings) moves hypothetical-content generation from query time to indexing time. An LLM creates several likely questions for each chunk; those questions are embedded and linked back to the original chunk. Online retrieval becomes question-to-question matching.
• Strongest evidence: In the six-dataset aggregate in Table IV, HyPE’s Retriever claim recall is 71.5 ± 12.5 versus 53.6 ± 19.0 for Naive RAG; context precision is 63.5 ± 13.8 versus 42.3 ± 17.4. The numbers come from fixed bge-m3, Mistral-NeMo, RAGChecker, and the paper’s preprocessing.
• Main boundary: HyPE is not a free vector replacement. Every chunk needs at least one indexing-time LLM call, and the index stores multiple vectors for the same chunk. Prompt quality, chunking, corpus freshness, and query distribution decide whether offline cost buys online value.

Core engineering takeaway: HyPE’s important contribution is a cost-placement decision. It uses one-time hypothetical-question generation to improve alignment for long or stylistically distant corpora, so serving does not need a new generation call for every request. It is a useful retrieval-layer experiment, but the paper does not establish that it will beat Naive RAG or HyDE for every corpus, embedding model, or generator.

Identity, scope, and evidence map

This reading uses the complete arXiv 2607.29402 v1 HTML and v1 PDF. The authors are Domen Vake, Jernej Vičič, and Aleksandar Tošić. The arXiv record says that v1 was submitted on 2026-07-31 and lists an IEEE Access 13 (2025) journal reference. Both dates matter: 2025 is the journal citation year, while 2026 is the later arXiv submission. They should not be collapsed into one publication date.

The paper is a retrieval method and empirical benchmark paper. It changes how indexing and retrieval align text, then compares three pipelines on six datasets, four retrieval depths, and multiple RAGChecker metrics. It is not a new embedding backbone and not a new generator. The intervention is narrower: what text is embedded, when hypothetical text is created, and how an online query reaches the original chunk.

Layer	How this reading treats it
Directly supported by the paper	Offline hypothetical-question generation, the vector–chunk index, Naive RAG/HyDE/HyPE pipelines, six datasets, bge-m3, Mistral-NeMo, RAGChecker metrics, and the numbers in Tables III–V.
Author interpretation	Question-to-question alignment can reduce query/document style mismatch; offline generation avoids an extra LLM call per request; better retrieved context can improve downstream generator metrics.
Not established by the evidence	Improvement for every domain, equal behavior for every embedding model, guaranteed lower total cost, freshness under rapidly changing corpora, or production faithfulness guarantees.
Bloss0m engineering synthesis	Treat HyPE as a versioned indexing contract that records the source chunk, generated prompt, generator version, embedding version, rebuild reason, and query-to-chunk evidence path.

Paper Essence Contract: six short answers

1. What problem does it solve? It addresses the embedding-alignment gap between interrogative user queries and explanatory corpus chunks.
2. Why are existing approaches insufficient? Naive RAG compares a query with a document; HyDE generates a hypothetical answer at every query, which can help alignment but adds online inference and may lack niche-domain knowledge.
3. What is the core idea? Generate several hypothetical prompts for every chunk offline, embed those prompts, map each vector back to its original chunk, and compare real queries with question-like representations.
4. How does one input move through the method? document → chunk → hypothetical questions → embeddings → vector–chunk index is the indexing path; user query → query embedding → ANN search over hypothetical questions → original chunks → generator is the online path.
5. What evidence supports the headline? Cross-dataset and cross-depth results in Table III, mean ± sd aggregates in Table IV, the distributions in Figures 4, 5, and 7, dataset-level F1 in Figure 8, and the Wilcoxon/Cliff’s delta analysis in Table V.
6. Where does the claim stop? It stops at six benchmarks, fixed bge-m3, fixed Mistral-NeMo, and the authors’ chunking and prompt-generation choices. Corpus churn, more generators and embedding models, real traffic, and full indexing cost are not tested.

Prior approach limitation: why the obvious alternatives are insufficient

Raw vector retrieval is efficient, but it asks a question-like query to match a chunk whose language is usually explanatory. HyDE addresses that mismatch by asking a model to generate a hypothetical answer at query time, yet that adds an online generation call and can be unreliable when the model does not know the niche domain. Lexical document expansion such as Doc2Query can help first-stage matching, but it expands text rather than changing dense prompt-to-chunk alignment, and generated expansions can bloat the index or introduce irrelevant wording. HyPE’s claimed gap is therefore narrower: preserve real source chunks, keep the online path simple, and prepare question-like dense representations before serving.

Three retrieval objects to understand first

A query, a chunk, and a hypothetical prompt are different texts

Suppose a RAG corpus is split into chunks $C_1,\ldots,C_n$. Naive RAG embeds a user query $q$ as $f(q)$ and compares it directly with a chunk representation. The query might ask, “What triggers account lockout?” The chunk might say, “The account enters a locked state after five consecutive verification failures.” The two express the same fact, but from different grammatical and informational perspectives.

HyPE asks a generator $G$ to create $k$ hypothetical questions for each chunk:

$Q_i = \{q_{i1}, q_{i2}, \ldots, q_{ik}\}$

Each question is embedded by $f$:

$v_{ij}=f(q_{ij}) \in \mathbb{R}^{d}$

The index stores vector–chunk pairs rather than one vector per chunk:

$E=\{(v_{11},C_1),(v_{12},C_1),\ldots,(v_{nk},C_n)\}$

Here, $k$ means the number of hypothetical prompts per chunk, not the top-$k$ chunks returned by the online ANN search. The paper uses the same letter in two algorithmic contexts, so an implementation should name these parameters separately. The first controls indexing tokens, vector count, and hypothetical coverage; the second controls online context breadth, duplication, and generator noise.

Core intuition: precompute possible questions instead of guessing an answer per request

Naive RAG’s control point is the incoming query: ask the vector index which chunks look like the query. HyDE’s control point is also online: ask an LLM to produce a hypothetical answer, embed that answer-like text, and use it to retrieve real documents. Both put their extra work on the serving path.

HyPE reverses that placement. When a document enters the corpus, the system asks: “Which questions might future users ask that this chunk could answer?” The hypothetical prompts become an offline alignment layer. An online query only needs to be embedded with the same embedding model, matched to nearby hypothetical questions, and followed back to the original chunk. HyPE does not rewrite the source into an answer or permanently append question text to the document; it stores query-like vectors that point to the source.

Figure 1 (original paper Figure 1, framework overview at the end of Section II): the source chunk is on the left, hypothetical questions/embeddings are in the middle, and query-time retrieval returns to the original context on the right. The key observation is that generation belongs to indexing, not every request. Original Figure 1 anchor · Original SVG endpoint. The arXiv HTML page marks the paper CC BY 4.0; this article uses the v1 image directly with attribution, subject to the original license and copyright conditions.

Walk one example through the method

The following is a faithful explanatory example derived from the mechanism, not a new experiment from the paper.

1. Input: one source chunk. The document says: “If verification fails five times within fifteen minutes, the service locks the account; an administrator can unlock it after thirty minutes.”
2. Indexing representation: hypothetical prompts. The generator might produce “When is an account locked?”, “How many failed verifications trigger lockout?”, and “How long until an administrator can unlock the account?” bge-m3 embeds each question, and every vector points to the same source chunk.
3. Decision: a user query. The user asks, “How many verification failures lock the account?” The online path only embeds the query and performs ANN search. If it is close to the second hypothetical prompt, the system returns the original chunk.
4. Output: generator context. Mistral-NeMo receives the source chunk, not the synthetic question. The hypothetical prompt is an index entry, not answer evidence.
5. Likely failure point: prompt quality or freshness. If the generator never imagined the phrase “verification failure,” or if the source changed while the old prompt remained in the index, the vector may not cover the real query. If several vectors for one chunk appear in top-k, the generator may also see amplified relevant noise.

The example makes the intervention precise: HyPE does not rewrite the answer and does not change the online generator; it changes the representation entering ANN search.

What differs between the three pipelines

Table I compares three pipelines:

Pipeline	When hypothetical content is added	Representation being matched	Extra online LLM call
Naive RAG	None	prompt-to-document	0
HyDE	Inference-time hypothetical answer	document-to-document	1 query-level generation
HyPE	Indexing-time hypothetical questions	prompt-to-prompt	0

Figure 2 (original paper Figure 2, Section III Methodology): the important distinction is where augmentation occurs. HyDE generates online; HyPE generates during indexing; both ultimately return real document chunks. Original Figure 2 anchor · Original PNG endpoint. The paper page marks the work CC BY 4.0; this article uses the v1 image with attribution, subject to the original license and copyright conditions.

Indexing cost is moved, not removed

For a corpus with $n$ chunks, the paper describes roughly $n$ LLM calls: one call per chunk, with each call producing $m$ prompts. Increasing $m$ can expand question coverage without requiring one call per prompt, because multiple prompts can be generated in one call. The cost moves offline:

• Generation cost: the generator must create prompts for every chunk; a large or frequently changing corpus pays this repeatedly.
• Index size: one chunk may correspond to several vectors, multiplying vector storage and duplicate retrieval candidates.
• Consistency work: changing the source chunk, prompt generator, or embedding model can require a rebuild or a versioned coexistence period.
• Serving benefit: the query path remains query embedding plus ANN search; unlike HyDE, it does not need a new synthetic answer generation call per request.

The precise claim is therefore “no additional query-time LLM latency,” not “no additional computation.” The following is a Bloss0m engineering synthesis: when query volume is low and the corpus changes quickly, HyPE may not beat HyDE or a simpler reranker in total cost. When the corpus is stable, query volume is high, and query/document style mismatch is material, paying once may make sense.

How to read the experiment: six datasets and fixed controls

The paper uses six datasets: MS MARCO, RAGBench, Ragas-WikiQA, RAG-dataset-12000, MultiHopRAG, and Single-Topic RAG. Table II ranges from 80 Q&A pairs in Single-Topic and 232 in Ragas-WikiQA to 82,326 in MS MARCO and 73,286 in RAGBench. Average chunk length ranges from 82 to 688 tokens. The authors re-segment RAG-dataset-12000 and MultiHopRAG with a maximum of 500 tokens and 50-token overlap; the other datasets use their existing segmentation.

The controls include:

• the same data and chunking procedure for all three pipelines;
• bge-m3 as the embedding model;
• Mistral-NeMo as the fixed generator, so generator differences mainly reflect retrieved-context differences;
• retrieval depths $k\in\{1,3,5,10\}$, with cosine versus Euclidean distance additionally tested at $k=5$;
• RAGChecker metrics across retriever, generator, overall, and noise dimensions.

This resembles a focused retrieval-augmentation comparison, but it also limits external validity. The paper does not provide a full factorial study over embedding families, generators, chunkers, or prompt generators.

Read RAGChecker metrics by layer

• Retriever context precision: how many retrieved passages directly match the query’s needs.
• Retriever claim recall: how much necessary information was retrieved.
• Generator context utilization: how much the generator uses the retrieved context.
• Faithfulness: whether the answer remains supported by retrieved passages.
• Hallucination: unsupported-claim behavior; lower is better.
• Noise sensitivity: error sensitivity when relevant or irrelevant context is perturbed; this is a downside dimension here.
• Self-knowledge: the model’s recognition of missing information, which should not be read as another retrieval success rate.

Result 1: Where do the precision and recall gains concentrate?

Table III shows that HyPE leads in many dataset/depth cells, but not every cell. On RAG-dataset-12000 at @1, context precision is 55.8 for Naive RAG, 55.1 for HyDE, and 82.6 for HyPE; claim recall is 34.7, 33.3, and 63.6. At @10, HyPE claim recall reaches 84.6 while Naive RAG is 56.1 and HyDE is 55.6.

MS MARCO is an important counterexample. At @1, HyPE precision and recall are 68.7 and 50.2, below Naive RAG’s 73.6 and 56.2. At @10, HyPE’s 62.5 precision is slightly above Naive RAG’s 61.5, while its 84.0 recall is still slightly below 85.7. This is not enough to call HyPE a failure, but it shows that a style bridge has less room when short passages already have high lexical overlap with questions.

Single-Topic RAG is the opposite shape. At @1, precision rises from 28.7 for Naive RAG and 22.5 for HyDE to 68.8 for HyPE. At @10, claim recall rises from 36.8 and 36.4 to 81.4. That supports the paper’s interpretation that hypothetical question vectors are more useful when the corpus is narrow, the documents are longer, and query phrasing differs from the source style.

Figure 4 (original paper Figure 4, Section V Results): the box plots provide information that one mean hides. HyPE has higher context precision at multiple $k$ values and narrower distributions in this six-dataset setup, but that is not a guarantee for every query distribution. Original Figure 4 anchor · Original SVG endpoint. The original page marks the paper CC BY 4.0; this article uses the v1 image with attribution, subject to the original license and copyright conditions.

Figure 5 (original paper Figure 5, Section V Results): claim recall complements the precision view. “More necessary information retrieved” and “less irrelevant material retrieved” are separate properties and should not be collapsed into one success label. Original Figure 5 anchor · Original SVG endpoint. The original page marks the paper CC BY 4.0; this article uses the v1 image with attribution, subject to the original license and copyright conditions.

Aggregate numbers are attractive; read the spread with them

Table IV reports these six-dataset means:

Metric	Naive RAG	HyDE	HyPE	How to read it
Retriever claim recall ↑	53.6 ± 19.0	52.6 ± 17.8	71.5 ± 12.5	More necessary information is covered, with a smaller cross-dataset spread
Retriever context precision ↑	42.3 ± 17.4	41.6 ± 15.9	63.5 ± 13.8	Retrieved context is more concentrated
Generator faithfulness ↑	52.2 ± 15.0	51.4 ± 14.8	69.3 ± 6.0	Downstream grounding with the fixed generator
Generator hallucination ↓	26.0 ± 11.9	25.1 ± 11.4	19.9 ± 8.2	Lower is better, but this is not a production hallucination rate
Noise sensitivity in relevant context ↓	13.8 ± 7.8	14.2 ± 6.6	21.0 ± 4.4	HyPE is worse; this is an important trade-off
Overall F1 ↑	27.9 ± 9.7	27.2 ± 9.6	37.6 ± 7.7	A compact summary across several precision/recall dimensions

The relevant-context noise result is the one not to skip. The paper treats a higher value as worse and suggests that several nearby vectors may retrieve repeated copies of relevant chunks. Alignment can improve while duplicated or perturbed evidence becomes more damaging to the generator. Retrieval precision and generator robustness are different optimization targets.

Result 2: Is the generator actually better? First, notice that it is the same generator

HyPE directly changes retrieval, while the generator remains Mistral-NeMo. Therefore the Figure 7 changes in faithfulness, hallucination, context utilization, and related metrics should be read as downstream effects of different retrieved context passed through the same generator. They do not show that HyPE is itself a better language model.

Figure 7 (original paper Figure 7, Section V Results): these generator metrics come after the retrieved context is processed by fixed Mistral-NeMo. Faithfulness and hallucination improve in the aggregate, but the relevant-context noise downside remains visible. Original Figure 7 anchor · Original SVG endpoint. The original page marks the paper CC BY 4.0; this article uses the v1 image with attribution, subject to the original license and copyright conditions.

Table V uses paired Wilcoxon signed-rank tests, Holm adjustment, and Cliff’s $|\delta|$ to compare HyPE with both baselines. The effect sizes are medium to large for many metrics. Two cautions remain. First, there are only six dataset-level paired observations, which is why a distribution-free test is appropriate but not a substitute for broader sampling. Second, adjusted p-values and the minimum attainable exact level must be read from the table; “five metrics meet the stricter threshold” should not become “everything is statistically significant.”

Result 3: Distance is not the main character

At $k=5$, the paper compares cosine and Euclidean distance. Figure 6 shows no major difference between the two distance choices for claim recall and context precision across the three pipelines. The practical interpretation is not that distance never matters. Under this bge-m3, index, dataset, and $k=5$ configuration, the main difference is more plausibly the representation and indexing stage than the distance metric alone.

Figure 6 (original paper Figure 6, Section V Results): this controlled comparison helps separate question-question representation from the distance choice. It does not establish that all embedding models are distance-insensitive. Original Figure 6 anchor · Original SVG endpoint. The original page marks the paper CC BY 4.0; this article uses the v1 image with attribution, subject to the original license and copyright conditions.

Result 4: Dataset-level F1 says that not every corpus needs a style bridge

Figure 8 breaks F1 down by dataset. HyPE separates more clearly on RAG-dataset-12000, Single-Topic, and WikiQA, which contain longer or more specialized material; on MS MARCO, all three pipelines are close. That distribution is more useful for engineering than the headline average because it suggests a selection rule: first measure query/document style mismatch, then decide whether to generate hypothetical prompts for the corpus.

Figure 8 (original paper Figure 8, Section V Results): each subplot expands a dataset across $k=1,3,5,10$. The convergence on MS MARCO is an important boundary; an aggregate mean should not be used to claim universal superiority. Original Figure 8 anchor · Original SVG endpoint. The original page marks the paper CC BY 4.0; this article uses the v1 image with attribution, subject to the original license and copyright conditions.

Ablations, failure modes, and open questions

Prompt quality is currently averaged away

HyPE treats a chunk’s hypothetical questions as equally important. It does not decide which prompts are representative, hallucinated, redundant, or domain-inappropriate. That keeps the method easy to describe, but leaves a quality gate missing: a bad prompt is not merely one less vector. It can encode an incorrect phrasing into the index and make ANN search overconfident about the wrong surface form. The paper leaves prompt scoring and domain-conditioned generation for future work.

Chunking remains a shared variable

The authors use the same preprocessing for all pipelines to keep the comparison fair. That does not mean the chunking is optimal. A long chunk preserves context but dilutes vector specificity; a short chunk makes the representation more precise but can lose surrounding conditions. HyPE adds multiple question vectors per chunk, but it does not remove the chunk-boundary problem. A gain on one dataset cannot be attributed only to prompt-to-prompt alignment while ignoring segmentation.

Relevant noise is a counter-signal

Repeated vectors can make it more likely that a relevant chunk is retrieved, but they can also make relevant information appear repeatedly in the top-k context. The noise-sensitivity result is therefore a useful warning: retriever precision and generator robustness do not necessarily move together. A production system should record chunk identity, hypothetical-prompt identity, and duplicate count. Deduplicating the top-k list is not merely a presentation cleanup; it changes the evidence mass seen by the generator.

One generator and an unmeasured indexing bill

Fixing Mistral-NeMo improves comparability, but it does not show that another generator will respond in the same way. More importantly, the paper explains the one-call-per-chunk structure without publishing a full indexing token count, generation latency, vector-storage estimate, or corpus-refresh cost table. “Cost-effective” should therefore mean a structural reduction in query-time calls, not a completed end-to-end TCO study.

Keep the statistical denominator and selection process visible

The paper reports six-dataset means ± sd and paired Wilcoxon tests with Holm–Bonferroni adjustment. That exposes cross-dataset variation and paired differences, but six datasets are not a large independent sample of production users. Prompt generation, chunking, retrieval depth, and model choices are also researcher-controlled. The effect signal is interesting; external validity still requires more corpora, more backbones, multilingual tests, and long-lived update experiments.

Bloss0m engineering judgment and when not to use it

Conditions for a bounded pilot

The following is a Bloss0m engineering interpretation, not a checklist proposed by the authors:

1. The corpus is relatively stable, or the team can rebuild prompts incrementally after source changes.
2. Query volume is high enough that a query-time LLM call costs more than an offline indexing pass.
3. Queries are interrogative while the corpus is long-form, explanatory, or domain-specific.
4. The team can preserve source chunks, prompts, model versions, embedding versions, and generation timestamps for audit and rollback.
5. Evaluation includes recall, precision, faithfulness, duplicate context, and relevant-context noise sensitivity rather than only one top-k metric.

Conditions where it should not be adopted directly

• The corpus changes every few minutes and every answer requires the newest evidence.
• The indexing LLM bill, vector multiplication, or refresh window is still unknown at the target corpus size.
• The prompt generator lacks domain knowledge, but the generated questions would be treated as a coverage guarantee for legal, medical, or safety decisions.
• The query and document already have high lexical overlap, as in the paper’s short MS MARCO passages.
• The system cannot trace a vector back to its source chunk or revoke old prompt vectors after a source update.
• Strict evidence provenance is required, but the system stores only synthetic prompts rather than the original chunk, version, and context actually passed to the generator.

A versioned contract that can be implemented

Bloss0m engineering synthesis: If HyPE were placed in a production RAG system, each index record should at least include source_chunk_id, source_version, hypothetical_prompt_id, prompt_generator_model, prompt_generation_time, embedding_model, embedding_version, chunker_config, prompt_quality_state, supersedes, and expires_at. The online trace should record matched prompt IDs, deduplicated source chunk IDs, the final context sent to the generator, and any freshness or quality-policy rejection.

This contract is not a formal protocol from the HyPE paper. It is an engineering boundary derived from the paper’s indexing/serving separation. The central rule is simple: a synthetic prompt may help find the source, but it cannot replace the source as answer evidence.

Artifacts and reproducibility

As of 2026-09-19, the reading covers the arXiv full HTML, the v1 PDF, the authors’ linked RAGChecker repository, and the dataset endpoints named in the paper. Their states should remain separate:

Artifact	Status	What can be done	What is still missing
Paper figures	usable	The arXiv HTML exposes flow, pipeline, precision/recall, distance, generator, and F1 figures; this article preserves v1 Figures 1, 2, 4, 5, 6, 7, and 8	Attribution and original copyright/reuse conditions still apply
RAGChecker	usable	The public Apache-2.0 repository provides installation and input schema for retriever and generator diagnostics	It is not the HyPE authors’ full experiment runner or exact preprocessing release
Ragas-WikiQA	usable	The Hugging Face endpoint is accessible and exposes 232 rows	It redirects to the maintainer’s current namespace; a snapshot must be pinned for long-term reruns
RAG-dataset-12000	endpoint usable	The Hugging Face dataset page is accessible as a data entry point	This reading did not verify identical preprocessing, chunking, and splits to the authors’ run
Single-Topic RAG	external dataset workflow	The paper supplies a Kaggle URL that can serve as the data source	A Kaggle download, version, and credential workflow was not completed as a reproduction
HyPE implementation	no dedicated public repository verified	Algorithms 1–2, equations, and figures make a conceptual reimplementation possible	No author code, prompt template, complete index files, token bill, seed, or exact run script was verified
Mistral-NeMo and bge-m3	public upstream models	Official upstream sources can be used to rebuild a baseline	Model revision, hardware, batch size, ANN implementation, and preprocessing still need to be fixed

This is why the article does not call HyPE “one-click reproducible.” A sound reproduction path would pin six dataset snapshots, use the same chunking, bge-m3, Mistral-NeMo, RAGChecker, and the authors’ hypothetical-prompt template, then rerun Naive, HyDE, and HyPE. Without exact prompts, indexing parameters, and full logs, that is a method-level reproduction rather than a claim-level reproduction.

Next reading

Read this after RAG-ANYTHING: bringing multimodal data into retrieval, Dense Passage Retrieval: the unit of vector retrieval, RAGSieve: checking retrieval integrity, and Predicting Partial Answer Quality in Agentic RAG. HyPE adds a decision about indexing representation and query-time budget rather than another generator.

For an implementation experiment, use the same source chunks, embedding model, and generator to compare Naive, HyDE, and HyPE on precision, claim recall, duplicate context, relevant-context noise sensitivity, indexing cost, and refresh lag. First determine whether the corpus resembles Single-Topic or MS MARCO before paying for a full hypothetical-prompt index.

Three things to remember

1. Technical idea: HyPE turns hypothetical content from query-time answer generation into indexing-time question generation. Retrieval becomes question-to-question matching, while the returned evidence remains the original chunk.
2. Evidence: The six-dataset aggregate improves retriever recall and precision, and Figure 8 shows the clearest gains on longer or narrower corpora. MS MARCO convergence and worse relevant-context noise sensitivity show that the result is conditional.
3. Boundary: HyPE reduces query-time LLM calls, not total cost. Fast corpus change, uncontrolled prompt quality, or missing source/index versioning can consume the benefit through freshness, storage, and provenance failures.

Primary sources

• Bridging the Question-Answer Gap in Retrieval-Augmented Generation: Hypothetical Prompt Embeddings — arXiv 2607.29402 v1
• Full paper HTML with Figures 1–8, Tables I–V, Algorithms 1–2, and Sections I–VI
• v1 PDF
• IEEE Access DOI record
• RAGChecker official repository
• Ragas-WikiQA dataset endpoint
• RAG-dataset-12000 dataset endpoint
• Single-Topic RAG evaluation dataset
• Mistral NeMo official model announcement