Plenty of AI systems grade whether the answer is correct. What sets OneSearch-VL apart is that it separately grades how the answer was reached.
It's an 8B (8-billion-parameter) model built to investigate three kinds of visual input — a single image, multiple images, and video — through one agent (an AI that handles a task by choosing and using tools on its own). The core mechanism looks at two things. One: did the facts underpinning the answer actually come from the screens and search results the tools returned? Two: did it point at the right spot on the screen, rather than some irrelevant place, and let that drive the rest of the investigation?
The authors pinned the effect down experimentally. When they layered this process grading on top of a reward that had scored only answer and query quality, the average across standard performance tests (benchmarks) rose from 57.3 to 61.1. They only graded the path to the answer, yet the answer they arrived at got better.
Picture a 10-second video panning slowly down a street. A few shop signs drift past. The question: of the brands that appear in this video, how many have been in business for more than 50 years?
You can't solve this by looking alone — the founding years aren't written on screen. To answer it properly you have to walk a chain. First pick the stretch where the signs are visible and pull the frame at that moment. Crop each sign, read the text, and identify which brand it is. Search the web for each brand's founding year. Keep only the ones past 50 years and count them. Only then do you get a number.
To do this the model uses several tools: selecting a segment, pulling frames, cropping, reading text, image search, web search. The important part is that the tools don't operate in silos. Whatever the tool, commands go out through the same interface and results come back in the same format. So whether it's a single image or a video, one agent handles it the same way.
Now say the model answers "three." Correct. But did that three come from real investigation, or did it glance at the wrong frame, guess, and get lucky? From the final answer alone the two look identical. You can identify every brand and still be wrong if you fetch the wrong founding years, and a sloppy process can land on three by accident. The hard part isn't the last number — it's the chain that leads there. The paper's bet is clear: hold onto that entire chain and use it the same way across data, training, and evaluation.
How to record that chain in the data is the real problem — and it's exactly where prior work kept slipping.
Think of the evidence board in a detective show: photos pinned to a wall, documents tacked up, string running between photos, documents, and conclusions. What cracks the case isn't any single photo; it's the string connecting them. The string is exactly what prior methods tended to lose. They did store evidence in graph-like structures, but they failed to preserve the full chain of dependency that runs from sign to brand to founding year to count. They kept the photos and the final conclusion but dropped the connective tissue in between. Video was worse: keyframes were used only as seeds for search, with no explicit record of which observation a given conclusion came from.
OneSearch-VL's digital version of that board is the VGEG (Visual-Grounded Evidence Graph). The photos on the wall correspond to the spots the model singled out on screen ("I looked here" — the anchors) and what they are. The tacked-up documents are external facts backed by a source. The string between them is the dependency relationship among anchors, facts, and operations. On top of that come the operations that bundle facts into an answer — counting, comparing, calculating. For our video question, the frame showing a sign (the photo), each brand's founding-year document (the tacked document), and the string linking "this sign = this brand = that founding year = qualifies under the 50-year bar" all gather on one board.
The key is that this single board gets used the same way in four places: when questions are generated, when expert solutions are filtered, when the model solves a task itself and gets scored, and when scores are assigned per operation. Instead of training and evaluation running on different yardsticks, they look at the same board. Given a task, the system cuts out just the part of the full input's large evidence map that the task needs and builds a small board from it — a minimap that flags only the region of the giant map this particular question will use.
The data, too, gets stamped out around the board. 2.5 million usable web videos are filtered down to 70,000 that contain identifiable subjects with room to search. Each video is sliced up, anchors ("this is here") are planted across the screen, and those anchors are linked to real facts and sources via image search, text reading, and web search. Questions and answers are generated against the finished board, and finally — among the solutions an expert model left behind while actually using the tools — only those that both got the answer right and passed the process-quality bar are kept. What this yields is the training data SFT-110K and RL-10K (what each number actually counts is in the FAQ at the end).
One thing worth flagging: this work didn't add a new search capability. It's closer to inheriting the data and reward of its immediate predecessor and layering a framework on top of it that supervises how evidence was handled, then widening the scope to multiple images and video.
The two grading axes from the intro have a name: EVGR. For each task it builds a rubric — what the core of the answer is, which facts should support it, what the source and the supporting sentence for each fact are, and which frames and regions should be looked at. The model's solution is laid over this rubric and scored.
Why the two axes are split matters. Look at the answer alone and a lucky path and a properly walked one look the same. But ask separately whether the facts came from real observations and whether the right spot on the screen was pointed at, and you open a gap through which a sloppy solution that happened to land on the right answer can be filtered out.
And the two axes carry different weight depending on the input type. With a single image or several images, every scene to look at is already handed to you, so there's no burden of having to pick out the frame holding the relevant moment — meaning you don't necessarily have to fire off additional visual tools, not that you use none at all. Images get the same tools — Crop, OCR — and when actually investigating several of them the model sometimes crops the screen multiple times over. Video is different. You have to pick the frame holding the relevant moment yourself, and if that choice is wrong the search that follows goes entirely off the rails. That's why the "did it point at the right spot on screen" axis bites especially hard on video. This is the real reason video investigation is hard.
Training runs in two stages. First the model imitates, wholesale, the solutions an expert left behind by actually using the tools. Then it's let loose to use the tools itself and refines its judgment with the scores it receives. The first is imitation, the second is trial and error.
A few design points worth noting. In the imitation stage, the outputs the tools returned are excluded from the "did it get it right" scoring. Those values weren't produced by the model but came in from outside, so it's only fair to evaluate the actions the model chose on its own. The score in the refinement stage is the sum of answer accuracy, query quality, and EVGR's process score — but credit is given only when the reasoning, the tool calls, and the response are correctly formatted. One more thing: live web search failing partway through is all but a constant. So a solution whose tool execution was cut off isn't thrown away wholesale; the clean part up to just before the failure is salvaged and used for training. It looks minor but is decisive in practice.
So how do you measure whether it did well? GPT-4o compares the final answer against a reference answer and sorts it into right or wrong. The comparison baselines are laid out in three tiers: answering directly with no tools, answering with search results attached, and the tool-using agent. Of these, the version that bolts tools onto the same 8B base model is the fairest head-to-head.
The clever move was to split evaluation not by what is asked but by what operation is required. The two new benchmarks use the same operation taxonomy: problems solved with a single anchor, problems that require hopping across several searches, problems that count under a condition, and problems that stitch together, compute over, or compare multiple anchors. Why split it this far? Because a single accuracy number doesn't show where the failure happened — whether the model couldn't find the subject, couldn't connect the relationships, or couldn't filter by the condition. Breaking it out per operation is what surfaces that spot.
But this cleverness also bred a suspect corner. The operation taxonomy that structures these two benchmarks is the same system as the taxonomy of the data engine that trained the model. That means the test was set by the same standard the model studied under. So you should assume these two benchmark scores carry some amount of "home advantage from sharing the same frame." That's why you need to read them alongside the externally built video benchmark VideoDR and the seven existing single-image benchmarks to keep things balanced. One more: GPT-4o's binary verdict measures only the final answer. It can't measure the quality of the path that led there. Filling that gap is what EVGR's two judges and the per-operation breakdown just described are for.
Now the numbers. The average across the seven single-image benchmarks is 58.3 — 16.3 points higher than the agent with tools bolted onto the same base model, and 1.7 points higher than the immediate predecessor, OpenSearch-VL. It beat the predecessor on all seven, and against other tool-using methods it came out on top on six of the seven. This result says one thing: even after multi-image and video solving were thrown into the same pot and learned together, single-image investigation skill didn't erode. It's the first sign that mixing didn't cost anything.
On multiple images and video the gap widens further. On the two new benchmarks it beat the comparable tool-equipped model by 20.2 and 17.6 points respectively, and on the externally built VideoDR it opened a 27.0-point lead.
What matters is where the gap opened. Not on simple lookups. It opened widest on compound problems that filter, weave, and compute over multiple pieces of evidence. On multiple images: counting under a condition (+29.8 points), gathering multiple anchors and computing (+26.3 points), comparing (+22.5 points). On video: hopping across several searches (+25.5 points), computing (+20.0 points), stitching anchors together (+19.2 points). Every one of them is a combinatorial operation the data engine targeted from the start.
The pattern leans clearly one way. The gap is small on plain finding and opens especially wide only where evidence has to be combined. This skew suggests the model improved specifically in the direction of weaving scattered evidence together — the gap opened in exactly the ability the data design aimed at from the start. But there's a clear line here. The paper reports per-operation accuracy and a reward-ablation experiment, but it doesn't present an experiment that controls the number of searches or isolates the effect of search volume on its own. So the mere fact that the improvement is large on compound problems isn't enough to conclude that the gain didn't come from simply searching more. As far as we can state right now, the pattern suggests an improvement in evidence-combination ability — and no further.
Two more experiments back this up. First, the configuration that learned all three inputs together scored a 55.8 average across six benchmarks, higher than learning a single type alone (51.7–55.1). It nails down in numbers that mixing pays off. The second is the result cited in the intro: the rise when process grading was added on top of a reward that had used only answer and query signals — direct evidence that a reward grading the process pulls up the outcome score too. Note, though, that these two experiments come from different setups (data mixture / reward composition). Don't read the 55.8 and the intro's rise as one continuous line.
Four points to flag.
One: both evaluation and reward lean on judge models. GPT-4o scores the final answer; two judge models score the process. The judges' quality and bias are the ceiling of both evaluation and reward. When a judge is wrong, the answer scoring and the reward are wrong along with it.
Two: the data engine depends heavily on an LLM for generation, verification, and filtering. The aggressive cull from 2.5 million down to 70,000 raises the quality of what remains, but it also means that what survives is governed by the leanings of the upstream model.
Three: the reported scores are for a single scale, 8B. Whether the same benefit shows up on larger or smaller models, and at what cost, is something this paper doesn't answer.
Four: the home advantage of the new benchmarks mentioned earlier. That said, the fact that the gap was also large on the externally built video benchmark takes a good deal of the edge off this concern.
OneSearch-VL's core concern is identical to one we face every day. A plausible answer looks like a correct one. Whether there's any grounding behind it, you can't tell from the answer alone. ONTLE's AI PM has exactly this soft spot.
Follow one scenario all the way through. A customer uploads a 10-minute screen recording of a checkout flow and asks: "What's missing in our checkout flow compared to competitors?" What the PM has to do is essentially the same as the video investigation we just walked through. Pin down the segment and frames where the checkout steps are visible, identify what each on-screen button does, search external documents to compare against competitor standards, then bundle those facts into a conclusion.
This is exactly where we've been burned before: a conclusion that sounds plausible but is grounded nowhere in the video and in no source. Translate EVGR's idea into ONTLE terms and it comes out like this. Separately from whether the answer is right, you check whether the facts underpinning the conclusion actually came from that frame in the video the customer uploaded and from that document you searched and read — and whether the PM really did point at the "right moment" in the video.
So the conclusion for the product is a single line: don't reach a conclusion first and slot the grounding in afterward. For every conclusion, store "which spot on screen" and "which external source" bundled in from the start. ONTLE's customer-facing screen shows work as a chronological flow. The point is to have every node in that flow carry, from the outset, "this conclusion is grounded in that scene at 03:12 of the uploaded video and in 2 external sources." Then tracing the grounding back later isn't a feature bolted on after the fact — it falls out of the structure of the work itself. On the customer screen it only needs to surface in the customer's own words, with no internal jargon — something like "Grounds: uploaded video 03:12, 2 reference sources." Make traceable grounding, not plausibility, the default. That's the practical takeaway this paper offers for a single scene of an ONTLE checkout video.
The paper points to GitHub (appletea233/OneSearch-VL) as the project repository and HuggingFace (OneSearch-VL) as the model hub. The specifics of release scope, license, and checkpoints have to be checked directly in those repositories.
They count different things. SFT-110K is a collection of expert solution processes (trajectories) merged into a unified multi-turn format, while RL-10K is a set of tasks built from a task pool spanning all three input types. One is counted in trajectories, the other in tasks, so they shouldn't be read interchangeably.
If the subject's name is exposed outright in the question, the model can answer without ever looking at the visual input. So the data engine rewrites explicit name mentions into "visually pointing references," and separately removes any question that can be answered confidently from text alone. It's a device that forces the model to go through the visual input.
It can. Web search and image search query the live web, so if the web's contents change the results can change too. It's a structural variable across this whole class of systems. If you want reproducibility, it's safer to fix and record the evaluation time and the tool environment together.