Datasetpublic

hotchpotch/fineweb-ir-simulated-search-queries

fineweb-ir-simulated-search-queries An English web-retrieval dataset built by generating simulated search queries for FineWeb-style positive target documents. This dataset contains English query-document pairs derived from HuggingFaceFW/fineweb-edu. Each row is designed so that the associated document is a positive retrieval target for the generated query. The queries were generated with a Qwen3.5-35B-A3B model quantized to NVFP4 and served through OpenAI-compatible vLLM serve… See the full description on the dataset page: https://huggingface.co/datasets/hotchpotch/fineweb-ir-simulated-search-queries.

sourceHugging Faceupdated 5mo agoView on Hugging Face

0likes126downloads

Dataset Card

fineweb-ir-simulated-search-queries

An English web-retrieval dataset built by generating simulated search queries for FineWeb-style positive target documents.

This dataset contains English query-document pairs derived from HuggingFaceFW/fineweb-edu. Each row is designed so that the associated document is a positive retrieval target for the generated query. The queries were generated with a Qwen3.5-35B-A3B model quantized to NVFP4 and served through OpenAI-compatible vLLM serve endpoints.

The dataset is intended for information retrieval research and engineering over open web text. It mixes direct fact-seeking queries with broader discovery-oriented queries, and it mixes natural-language semantic questions with shorter search-style query formulations. The goal is to approximate the range of queries a practical retrieval system may encounter, rather than producing only one clean benchmark-style query per document.

The source corpus is HuggingFaceFW/fineweb-edu. For this release, the English documents were extracted from FineWeb-Edu and then used as the document side for simulated-query generation. The public config name in this dataset is english. The published document field is the source-side text used during generation.

Loading the dataset

python

from datasets import load_dataset

ds = load_dataset(
    "hotchpotch/fineweb-ir-simulated-search-queries",
    "english",
    split="train",
    streaming=True,
)
row = next(iter(ds))
print(row)

Note that categorical columns are stored as Hugging Face ClassLabel, so some loading modes may return integer IDs instead of string names.

License

This dataset is derived from HuggingFaceFW/fineweb-edu. At the time of this release, the upstream FineWeb-Edu dataset card declares the license as:

—ODC-By (odc-by)

Please also review the upstream FineWeb-Edu dataset card and Common Crawl-related source terms for your intended use.

Acknowledgements

This dataset builds on HuggingFaceFW/fineweb-edu. Thank you for publishing FineWeb-Edu and making large-scale educational web text available in a form that makes retrieval-oriented repurposing practical.

Technical report

Dataset structure

The dataset uses the following top-level columns, in this exact order.

Column	Type	Meaning
`query`	`string`	Generated search query intended to resemble realistic user search behavior for finding the associated document or closely related documents.
`document`	`string`	Source-side document text used during generation and intended to act as the positive retrieval target.
`source_id`	`string`	Original document identifier carried over from the source `FineWeb2-IR` row.
`source_dump`	`string`	Common Crawl dump identifier associated with the source document.
`source_file_path`	`string`	Original WARC file path associated with the source document.
`source_original_row_id`	`int64`	Stable upstream row identifier preserved from the source corpus preparation pipeline.
`query_form`	`ClassLabel`	Whether the output was generated as a search-style query or a semantic natural-language question.
`mode`	`ClassLabel`	Main query style, such as direct, partial, tangential, typo-heavy, or keyword-style generation.
`asker_level`	`ClassLabel`	Intended phrasing difficulty or linguistic sophistication level.
`answer_type`	`ClassLabel`	How directly the document is expected to answer the query.
`clean_or_noisy`	`ClassLabel`	Whether the query was generated as a cleaner polished query or as a noisier search-log-like query.
`focus_segment`	`ClassLabel`	Which region of the source document the generator was encouraged to focus on.

query is the simulated user search input and document is the positive retrieval target text. An auxiliary source query used during local preparation is not included in the public release.

Released subsets

The following counts describe the current release.

Config	Source	Language	Train	Validation	Test
`english`	`fineweb-edu`	English	2,635,310	1,996	29,799

Control semantics

`query_form`

Value	Meaning
`search_query`	A search-engine-style query, often shorter and more compressed.
`semantic_question`	A natural-language question or question-like search input.

`clean_or_noisy`

Value	Meaning
`clean`	A clearer, more polished, more natural query.
`noisy`	A noisier query that may be rougher, typo-bearing, broader, or more compressed.

`mode`

Value	Meaning
`direct`	The query asks for information stated directly in the document.
`partial`	The query focuses on only part of the document and may be less tightly specified.
`tangential`	The query stays related to the topic but approaches it from a somewhat different angle.
`rough`	The query is short, rough, fragmented, or search-log-like.
`typo`	The query intentionally includes misspellings or typographical noise.
`keyword`	The query is compressed into a keyword-heavy search style.
`vague`	The query is broader or more underspecified than a direct lookup.

`focus_segment`

Value	Meaning
`all`	The whole document may be used as grounding context.
`front`	Focus on the earlier part of the document.
`middle`	Focus on the middle part of the document.
`back`	Focus on the later part of the document.

`asker_level`

Value	Meaning
`middle_school`	Simpler and more accessible phrasing.
`high_school`	Standard everyday phrasing.
`college`	More precise or somewhat more specialized phrasing.

`answer_type`

Value	Meaning
`direct`	The document is expected to directly answer the query.
`indirect_hint`	The document is expected to provide only a clue or partial support.
`interest`	The document is relevant to the topic, but may not directly answer the query.

Construction methodology

This section is written so that a senior data scientist or engineer can reproduce a close variant of the dataset design. The resulting generations will not be bitwise identical without the original prompts, seeds, and serving setup, but the methodological recipe is intended to be clear.

Step 1. Define the source document corpus

Start from HuggingFaceFW/fineweb-edu, which provides English educational web documents filtered from FineWeb. For this release, the English document pool was extracted from FineWeb-Edu and organized into train, validation, and test splits before generation. Those same splits are preserved in the public release after regeneration and filtering.

Step 2. Reuse the source-side document text as the retrieval target

For each source row, the generation input keeps the source-side text as the grounding document. An auxiliary query field was available during the local generation pipeline, but it is not part of the public output schema for this dataset.

The stable generation key is the row index within each split.

Step 3. Assign query-generation controls

Each row is assigned a deterministic control bundle from its stable row index together with a fixed control seed. The generation controls cover:

—query_form
—clean_or_noisy
—mode
—focus_segment
—asker_level
—answer_type

This design introduces structured variation across directness, noise level, linguistic sophistication, and which part of the document the generator should focus on.

Step 4. Generate search queries with a vLLM-served model

The generation run used a Qwen3.5-35B-A3B model quantized to NVFP4 through OpenAI-compatible vLLM serve endpoints. The prompts asked the model to generate one user-like retrieval query grounded in the source document and constrained by the selected control bundle.

The generation setup used temperature-based sampling rather than greedy decoding. Each raw row JSON stored the generated query, the source text, the control values, and generation bookkeeping such as ok and error.

Step 5. Filter completed generations for public release

The public dataset is not a direct dump of all raw row JSON files. Only rows satisfying all of the following conditions are exported:

—ok == true
—error == null
—query is non-empty
—text is non-empty
—all categorical control values are valid members of the released schema

The resulting dataset keeps the original split structure of the source corpus.

Step 6. Export the final IR dataset

Export the retained rows as a flat retrieval dataset with one query-document pair per row. The public schema keeps the retrieval text fields first, followed by the generation control columns:

—query
—document
—query_form
—mode
—asker_level
—answer_type
—clean_or_noisy
—focus_segment

The stable internal row index used during generation is intentionally omitted from the public release.

Author

—Yuichi Tateno (@hotchpotch) <img src="https://secon.dev/images/profile_usa.png" width="64" height="64" alt="Yuichi Tateno" />