Long-document snippets: miss the answer or fill the context window

On a short page, the relevant information usually sits in a small amount of text, so a snippet is easy to find. Long documents are harder: the information needed for a query may be buried deep in a paper, filing, documentation page or report, or spread across several parts of it.

As a running example, we use a recent 22-page paper on search agents, “SearchJev: A Fast and Calibrated System-1 Model for Search Agents” (Cao et al., 2026, arXiv:2610.05107)^{1}, and a question about its results: “On BrowseComp-Plus, what accuracy and median active time does the SearchJev-4B agent reach, compared with the System-2-only agent?” Figure 2 shows what the new system returns: seven spans from across the paper, 913 tokens in total, about 4% of the document.

Returning more of the page would also cover the answer, but longer snippets fill more of the agent’s context window and raise inference cost, and most of the extra text is irrelevant to the task.

We score every token and keep only what the query needs

Our system splits the document into overlapping chunks, scores every token in each chunk with a token classifier, and decodes the scores into a few contiguous spans of text (Figure 3), all within the time budget of a search request. The numbers in this section come from a production trace of the SearchJev request from Figure 2.

Scoring tokens

The classifier reads the query together with one chunk of the document and returns, for every token in the chunk, the probability that the token is useful for the query. It is trained on real search needs and agent trajectories, labeled with the facts and evidence needed to answer complex questions. This gives supervision at a finer level than document or passage relevance.

Figure 4 shows these probabilities on excerpts of the SearchJev paper. The abstract sentence that answers the question scores close to 1, while the title and the opening of the introduction score near 0. In the reference list, the BrowseComp-Plus entry scores high and the entry after it scores 0.

The figure also shows that the model scores blocks of text rather than individual facts. Every row of Table 4 scores high, whether or not the question names it, and so does much of Table 5, which reports results on a different benchmark. The scale of the scores also depends on the document: the highest score in this paper is 0.99, but on a weakly matching page it can be as low as 0.33. A fixed threshold would keep too much from some documents and nothing from others.

Decoding scores into a snippet

Decoding turns these noisy, document-relative scores into a few clean spans. Let p_{t} be the score of token t and m = max_{t} p_{t} the highest score in the document. Decoding uses two thresholds relative to m:

θ_{run} = max(αm, 0.5),     θ_{peak} = βm.

The lower threshold decides which tokens can be part of a span; the higher one is a level a span has to reach somewhere to be kept. Production uses α = 0.6 and β = 0.75. The SearchJev paper has m = 0.99, so θ_{run} = 0.594 and θ_{peak} = 0.743. In the results discussion (Figure 5), much of the text rises above θ_{run}, but only one passage also reaches θ_{peak}, so only that passage is kept. A single threshold at θ_{run} would also keep the start of the stretch and the sentences after the passage; a single threshold at θ_{peak} would keep only scattered parts of the passage.

Decoding applies the two thresholds in three steps. Figures 6a–6c show each step on the SearchJev paper, with the results discussion from Figure 5 as the running example.

1. Threshold

Maximal runs of tokens with p_{t} ≥ θ_{run} become candidate spans. In the results discussion, words score just above and just below θ_{run}, so the text breaks into short runs (Figure 6a); across the whole paper there are 37 of them.

2. Require a peak

A run r is kept only if max_{t∈r} p_{t} ≥ θ_{peak}. This removes noise without raising θ_{run}, which would cut the edges of good spans. The runs from Figure 6a never get above 0.62 and are removed, while the run in the next paragraph reaches 0.83 and is kept (Figure 6b). 10 of the 37 runs remain.

3. Close gaps

Scores dip on function words and separators, so runs fewer than g = 80 characters apart are joined with the text between them. In the abstract, “and” scores 0.58, just below θ_{run}, and splits two kept runs 4 characters apart, so they are joined and “and” is filled back in (Figure 6c). 7 spans remain: the snippet shown in Figure 2.

If no token reaches θ_{run}, the system returns the 200 characters centered on the highest-scoring token. About 4% of documents end up in this fallback.

Snippets adapt to the question

Decoding has no length target. Both θ_{run} and θ_{peak} scale with the page’s highest score m, so a passage is judged against the best text on the same page. When a page answers the query in one place, everything else falls below θ_{run}, even text the model rates fairly well. When the answer is spread across the page, every part that scores near the top passes, and the snippet is longer. Figure 7 shows both cases on the same paper.

For “What learning rate was SearchJev trained with?”, the answer sits in one place, the training table in the appendix. The snippet is that table plus two passages of the abstract: three spans and 346 tokens. For the BrowseComp-Plus question, the facts are spread over the abstract, the introduction, two results tables and the discussion, and the snippet is seven spans and 913 tokens, nearly three times as long.

On pages that match the query only weakly, m is low and both thresholds drop with it, so those pages still return their best passages. θ_{run} never goes below 0.5, and when nothing on a page reaches it, the fallback returns 200 characters around the highest-scoring point.

No added latency

The new snippeting adds no latency to a search request: responses come back as fast as with the previous snippets. The new snippets are therefore enabled by default in our realtime search API, which answers with a p95 latency of 200 ms, so agents get them within the time budget of a single turn.

Half the tokens, higher accuracy

On production customer workloads, agents read about half as many search-result tokens with the new snippeting system, and the snippets contain more of the information needed to complete the task.

On three public benchmarks, agents using the new snippets read 28–60% fewer search-result tokens per question and score higher than with the previous snippets. On BrowseComp, accuracy rises from 56.6% to 67.3% while search-result tokens per question fall from 1.16M to 466k. Keenable now uses fewer tokens per question than Exa and Parallel on all three benchmarks and has the highest accuracy on BrowseComp and AA-Omniscience.

All runs follow the Artificial Analysis Search API benchmark setup. The agent runs in the Stirrup harness with GPT-5.6 Luna as the answer model and a limit of 25 turns. It has two tools: a web search backed by the search API under test, and a simple fetch that returns the text of a page. Everything except the search provider stays the same between runs.

Table 1. Agent results on three public benchmarks with Keenable search using previous (Before) and new (After) snippets, and with Exa and Parallel as the search tool. Tokens / question counts search-result tokens. Bold marks the best value in each row.

Benchmarks are proxies for real quality, and a result that scores well on a benchmark does not always carry over to real questions. Figure 9 shows an example from DeepSearchQA. For this question, one of the search tools in Table 1 returns a page built for it: a single table with exactly the WHO measles and mumps figures the question asks for, so the agent has the answer in one step. Real questions do not come with a page like that. For them, search has to return the WHO data pages the question refers to, and the agent has to work out the answer from them.

Figure 9. The top results one of the search tools in Table 1 returns for a DeepSearchQA question. The second result is a page with exactly the measles and mumps figures the question asks for.

Search results are agent context

An agent usually needs a few facts from each document it finds. Agents search often and read long sources, and every search result they get goes into their context. Returning whole pages or long passages fills that context with text the model does not need and leaves the agent to find the facts itself.