Here is a question from our dataset:

A motor race took place on a street circuit during a season featuring an event in a Belgian province. A driver from the same motorsport discipline as Jos Verstappen won that Belgian event. That same driver also won an award that Jackie Stewart once received. I can't quite remember the specifics of the race distance for that street circuit event; how many laps long was it?

The answer is 78 laps: the race is the 1986 Monaco Grand Prix. Every fact needed to get there sits in the leading structured database, Wikidata. Yet no single lookup reaches it. A solver has to find the Belgian Grand Prix and its winner, Nigel Mansell, through his award and his discipline, then walk back through the 1986 season to a circuit the question never names.

Today we release the Recursive Language Model (RLM) harness that lets a model work through questions like this one in code, the 10,235 traces it recorded, and the method that builds the questions. The work was carried out within AI-BRIDGES, a project funded by Wikimedia CH in close collaboration with Wikimedia Deutschland.

Between memory and SPARQL

Wikidata describes more than 100 million entities and is maintained by a volunteer community. Built for Wikimedia projects, it now serves cultural heritage institutions, researchers and commercial services. Yet Wikidata and, more broadly, the entire semantic data ecosystem  remains poorly connected to the way people increasingly ask factual questions: through conversational models.

A language model answers mostly from what it memorized during training. That memory is least reliable for less prominent entities, and it gives no account of where an answer comes from. A knowledge graph holds explicit, sourced statements, but combining them requires a SPARQL query that names the right entities and properties and chains their relations. A model that consults the graph instead of recalling it would join the accessibility of the first to the verifiability of the second.

Existing natural-language interfaces to Wikidata, such as LC-QuAD 2.0, KQA Pro or the Wikidata Query Logs dataset, treat this as a translation task: one question, one query. That framing breaks when a question describes its answer through several unnamed intermediates, as in the Monaco example. The task becomes iterative search exploration, and agents that interleave reasoning with retrieval are the natural fit. 

Three obstacles hold them back on knowledge graphs:

• Training data. Teaching an agent to explore requires traces of exploration over tasks whose difficulty can be varied and whose answers can be checked. On the open web, it is hard to certify that a question has exactly one answer and that each clue is needed. A frozen knowledge graph allows both checks.
• Interface. One navigation step on a hub entity can return thousands of neighbours. Tool-calling agents paste these results into their conversation, and models miss evidence and lose accuracy as that context grows.
• Openness and auditability. The strongest agents are commercial models whose reasoning is hidden and whose terms restrict training on their outputs. For a public resource like Wikidata, and for the institutions that rely on it, what matters is whether open models running on modest hardware can do this work.

We see a new opportunity for the adaptation of existing agents to knowledge graph search through Recursive Language Models. With this harness method initially introduced by MIT CSAIL, the model inspects an external environment through code, keeps intermediate results in persistent state and delegates the reading of selected evidence to sub-calls. There is a natural correspondence between the concept of depth of knowledge graphs (how many iterations are needed to find or connect an information?) and the concept of depth in RLM (how many recursive steps a model should take to solve a step). Yet this remains untested and we propose the first ever practical implementation of RLM for Wikidata.

Synth environment: simulating complex questions that make sense

We build each question backwards, starting from its answer. A seed entity, such as the 1986 Monaco Grand Prix, is first described by a small bundle of conditions: held at Circuit de Monaco, part of the 1986 Formula One World Championship. Two operators then make the question harder, one step at a time.

• SELECT picks a named entity in the question to hide, here Circuit de Monaco. An LLM chooses among candidates that code has already filtered.
• EXPAND replaces that name with one to three conditions describing it, here a street circuit used for auto racing. Code enumerates the possible bundles with SPARQL, and the LLM picks the one that keeps the question coherent.

After each expansion, two checks run against the graph. Certification: the full question graph must still identify the seed alone. Necessity: removing any newly added condition must admit another answer, so every clue counts. We also reject clues that leak hidden names, and require each condition to match at least two candidates on its own.

Each question needs at least three expansions and a depth of three, up to ten expansions and a depth of seven. Ten rounds turn the Monaco race into a graph of 16 relations, in which the only names left are Jos Verstappen, Jackie Stewart and a few generic concepts such as street circuit or motorsport.

Seeds are chosen to vary entity type, language and prominence. We deliberately include less prominent entities, which models are less likely to have memorized, and sample across popular, moderate and rare seeds using a long-tail score. A share of seeds is described only in Arabic, Russian or Chinese.

Once the graph is grown, we choose what to ask about the target: the entity itself, a year, a quantity, or a group of related entities with its count and extremes, seven question types in all. A writer LLM turns the graph into a natural question in the voice of a persona drawn from Nemotron-Personas-USA. A critic LLM checks that every condition is stated, the right answer is requested and nothing leaks, while mechanical checks reject any question containing an identifier, a hidden name or the answer.

What is in the dataset

The release holds 10,235 solving traces: 672 over multi-hop questions built with the pipeline above, and 9,563 over single-entity questions. A trace records a model answering a question in the RLM harness, turn by turn: the Python it writes, the graph calls it makes, what it prints and its final answer.

The model works in a persistent Python environment, following the Recursive Language Models approach of Zhang, Kraska and Khattab: it calls the graph from code, keeps results in variables, filters them and prints only what it needs. It has 13 graph functions over the snapshot, from search_entity and claims to edges and references, with labels and descriptions in English, French, German, Chinese, Arabic and Russian. Two helpers, llm_query and llm_map, hand selected evidence to a sub-call for interpretation, without graph access.

What the harness changes

We tested the harness on 100 questions built with the same pipeline, 50 single-entity and 50 multi-hop, without collection clues. The baseline is a tool-calling agent built with the OpenAI Agents SDK, given the same 13 graph functions as tools and their outputs as conversation messages. 

We ran gpt-6-luna and Qwen3.8-27B under both interfaces; GLM-5.3-flash and Gemini-3.1-flash-lite ran as tool-calling agents only.

The harness improves both models. gpt-6-luna rises from 49 to 61 correct answers and Qwen3.8-27B from 60 to 74. The gain sits mostly on multi-hop questions, where gpt-6-luna doubles its score, from 9 to 19 out of 50, and Qwen3.8-27B goes from 20 to 28. As tool-calling agents, GLM-5.3-flash and Gemini-3.1-flash-lite answer 50 and 41 questions.

The questions are hard by construction. In every configuration we tested, multi-hop questions score 9 to 28 out of 50, against 31 to 46 for single-entity ones.

• The gain comes from carrying the search further. On multi-hop questions, the harness takes each model to the target entity more often: in 35 runs against 17 for gpt-6-luna, 39 against 27 for Qwen3.8-27B. Once there, each model answers correctly at about the same rate under both interfaces. Code lets a model explore broadly without placing every result in its context: in the harness, gpt-6-luna makes 15,575 graph calls per multi-hop run against 13 as an agent, at similar token use.
• An open model on one GPU gets the best score. Served in FP8 with vLLM on a single H100, Qwen3.8-27B answers 74 of 100 questions in the harness, at an estimated $0.04 per question, and beats gpt-6-luna under both interfaces. Open weights matter for the data too: Qwen3.8-27B returns its full reasoning, which the harness records beside the code, outputs and graph calls of each turn. Traces generated this way carry the reasoning behind each action, can be produced locally, and come with no provider terms restricting their use for training.

What the community can do with it

Everything we release runs on open weights and relatively modest hardware, so it can be used, inspected and adapted.

• Ask Wikidata complex questions without SPARQL. Integrate the harness for your knowledge assistants and pipelines to ask multi-step questions to Wikidata in plain language, and get answers traced back to the statements, qualifiers and sources that support them. With Qwen3.8-27B on a single GPU, an institution can run the whole stack in-house. The released harness works on the February 2026 snapshot; connecting it to the live Wikidata API is next on our list. 
• Check and improve Wikidata. The functions that answer questions also let a model walk around an entity, read its references and compare neighbouring statements. That makes the harness a starting point for tools that flag missing sources or conflicting statements for editors to review.
• Link collections to Wikidata. Archives, libraries and museums can use it to match the people, places and works in their own records to Wikidata entities, a task often done by hand.
• Train and evaluate models. The traces are ready for fine-tuning, and the construction pipeline can grow new certified questions for other domains, languages or answer types. Any new model can be run in the same harness and compared with the results above.

What comes next

These results suggest that, for structured public knowledge, part of the capability lies in the environment around the model: in how it is allowed to explore, store and verify. This matters for infrastructures such as Wikidata, where answers should be traceable to statements and their sources, and where institutions and researchers need tools they can run, inspect and adapt.

The traces are meant for training. Our next step is to fine-tune SLMs on them and build up knowledge graph search capabilities within the model itself.

This work was carried out within the AI-BRIDGES project, supported by Wikimedia CH and in close collaboration with Wikimedia Deutschland. 

Access the dataset

The traces, the construction method and the harness are open, so that others can replicate and extend the traces and evaluate further models in the same environment.

• Dataset: Wikidata Search Traces on Hugging Face
• Harness and construction code: Github repo
• Paper: Wikidata Search Traces: A Dataset for Training Knowledge Graph Search Agents, on arXiv