ITER

Retrieval that remembers what the agent already saw

A retriever trained only on question-document relevance keeps handing an agent the same top result on every search, even after the agent has already read it. ITER trains the retriever from the agent's own trajectories and evaluates it inside the same agent loop, so it learns to condition on interaction history rather than the question alone.

Two tools: search, and open a document

ITER's agent has two tools. search_dedup drops every document an earlier search in the same episode already surfaced, so a query never returns a result the agent has already been shown; a document that would have ranked but was already shown is listed as already seen, so the agent can still choose to reopen it. get_document opens one document by id. That pairing is strategy=dedup_dense, with the run's dense model behind the search, or dedup_bm25, using the research_dedup task template.

Trajectories become training data

Every run is a trajectory, so it is also training data. The generic recipe is shared with every other strategy in the library; this is ITER's path through it.

# trajectories -> triples -> checkpoint -> serving
skimsearchagent-build-triples --runs runs/... --dataset hotpotqa_structured \
  --out train_data/hotpotqa_i2.jsonl --query-style i2 --labeller oracle
skimsearchagent-train-retriever template > train.yaml
sbatch --export=ALL,TRAIN=train.yaml,TRAIN_ENV=$PWD/envs-train scripts/slurm/train_retriever.sbatch
skimsearchagent run configs/paper/hotpotqa_structured_sieve.yaml \
  retrieval.dense_model=models/my-retriever retrieval.dense_query_style=i2

Triples with tiered negatives come out of any run directory's records; a patched FlagEmbedding trainer fits a dense retriever on them; the checkpoint plugs back in as any strategy's dense model, served with the query style, the instruction and the precision it was trained with, so it behaves in production exactly as it behaved during training.

Released checkpoints

Any embedding model works as retrieval.dense_model. ITER releases two trained checkpoints:

Both are decoder checkpoints without a sentence-transformers config; the library detects that from the model's own config file and serves them with last-token pooling and normalisation, in the precision ITER trained them in. The query side pairs a query style with an instruction: ITER's own conditioned style for its trained models, a plain style for the untrained Qwen3-Embedding baselines it started from.

What it runs on

ITER runs on a Wikipedia chunk corpus with two question sets over it, infoseek_eval and infoseek_train, plus browsecomp_plus_chunks, a chunked BrowseComp-Plus corpus with its own evidence judgments. The Wikipedia-scale corpus is served from disk rather than held in memory, and retrieval over it goes through a prebuilt index rather than an index built during the run. The InfoSeek sets carry answers but no document labels, so they score on answer metrics and an LLM judge instead of ranking metrics.

If you use ITER

@misc{chen2026iter,
  title         = {ITER: Interaction-Aware Retrieval for Agentic Search},
  author        = {Chen, Haodong and Wang, Shuai and Yin, Yu and Zhuang, Shengyao and
                   Zuccon, Guido and Leelanupab, Teerapong},
  year          = {2026},
  eprint        = {2608.27912},
  archivePrefix = {arXiv},
  primaryClass  = {cs.IR},
  url           = {https://arxiv.org/abs/2608.27912}
}