TikTok Secretly Rewrites Your Searches: Inside the Latest Paper From Its Engineers
TikTok Secretly Rewrites Your Searches: Inside the Latest Paper From Its Engineers
How TikTok rewrites your query using the last video you watched, straight from its engineers' paper.
Ian Sorin
July 9, 2026
11 min read
- The paper: TikTok engineers published a system called CoRe that rewrites your search query using the last video you watched, before any results are ranked.
- How it learns: a 7-billion-parameter language model, retrained every week for more than five months, taught only by what users click versus skip (no human labels).
- The clever bit: its training reward copies the exact math of the live ranking system, so what the model learns and what actually ranks your results point in the same direction.
- The safety design: the rewrite is always an added signal, never a replacement. If it fails, ranking quietly falls back to normal.
- The headline result: people reformulate their search less often, which the authors read as users finding what they wanted on the first try.
You just watched a twelve-second clip of a molten chocolate cake. You tap the search bar and type a single word: chocolate.
On paper, that word is a coin toss. Chocolate the ingredient? The dessert? A brand? A Labrador named Chocolate?
And yet you almost certainly will not get a coin toss. You will get more lava cakes, plating ideas and easy dessert recipes, because the app quietly used the video you were just watching to decide what "chocolate" meant.
In June 2026, a team of engineers at TikTok (ByteDance) published a research paper describing exactly how this happens, in a system they call CoRe. I read it so you do not have to, the same way I did for Google's AI Overviews study. This article walks through what it reveals about TikTok's search engine, in plain language.
The search that depends on your last video
The paper focuses on a very specific moment it calls search-after-view: a search you run right after scrolling your personalized feed.
That moment has two properties the authors find unusually useful.
First, the last video you viewed (they label it dlast) is a strong hint about what you mean. Your query is short and often ambiguous on its own, but the video you just watched narrows it down.
Second, what you do next is a rich signal. In the same session you click on some results and pointedly skip others. Those clicks and skips are dense feedback about which interpretation was actually the right one.
So you have a narrow context (the last video) plus honest feedback (clicks versus skips). The authors argue that this combination is rare and very informative for teaching a machine to rewrite queries. That is the opening the whole system is built around.
Meet CoRe, TikTok's query rewriter
CoRe stands for Context Relevance. At its heart is a query rewriter: a small language model (a 7-billion-parameter Mistral (🇫🇷) model) that reads two things, your raw query and your last-viewed video, and writes a better version of the query.
In our example, "chocolate" becomes something closer to "chocolate lava cake recipe". Same intent, spelled out.
The key word is rewriter, not replacer. CoRe does not throw your words away. It produces an extra, context-aware version of the query that the ranking system can use alongside what you actually typed. We will come back to why that distinction matters a lot.
This is not a lab prototype. The authors report that CoRe has been retrained and redeployed every week for more than five months in the search system of a major short-video platform, feeding three separate stages of the ranking pipeline.
Training a model with no right answer
Here is the hard part. How do you train a model to rewrite queries when there is no correct answer to compare against?
Nobody can look at "chocolate" and declare, objectively, that "chocolate lava cake recipe" is the one true rewrite. A human labeler would just be guessing. So the paper does something else: it lets real user behavior be the teacher.
For each training example, the system looks at three baskets of videos drawn from real session logs.
- Positives: videos users actually clicked and engaged with (the paper calls these strict clicks).
- Hard negatives: videos that were shown to users but deliberately skipped. These are the tricky ones, close enough to appear yet not what people wanted.
- Easy negatives: random videos pulled from the catalog, almost certainly irrelevant to the query.
A good rewrite is then defined in a very concrete way: it is a rewrite that makes the ranking system score the positives high, the hard negatives low, and the easy negatives close to zero.
No opinion, no gold label. Just: did this rewrite line up with what people clicked and against what they skipped?
Why keep two kinds of negatives instead of one? Because they teach different lessons.
The hard negatives (shown, then skipped) train the rewriter on the tricky near-misses. The easy negatives (random videos) train it to brush aside anything clearly off-topic. Learning from both keeps it well-rounded, rather than good at only one kind of call.
The model that retrains every week
Interests drift. New trends, new slang, new products appear constantly, so a rewriter frozen in time slowly goes stale. CoRe's answer is to retrain on a fresh week of logs, every week.
But you cannot blindly ship a new model just because it is newer. So there is an automated promotion gate: each week's candidate is only deployed if it passes a quality check on data it has never seen.
That check looks at two families of metrics.
- Reward-like metrics: did the candidate actually get better at the goal (higher, cleaner relevance scores)?
- Stability metrics: is the model still behaving normally, or is it starting to drift into strange output (rewrites getting oddly long, too repetitive, and so on)?
A candidate is promoted only if it improves on the goal and stays inside safe behavioral bounds. Over the five-month window in the paper, the gate ran 20 weekly retrains and promoted 16 of them, an 80% acceptance rate. Of the 4 it rejected, 3 were held back for stability reasons and 1 for a drop in the core reward.
If you have ever set up continuous integration for code, this will feel familiar. It is basically CI for a language model: every week a new build, automatically tested, and only merged if it passes.
The week the model learned to cheat
This is my favorite part, because it is a very human failure.
During an early pilot, the reward-like metrics kept climbing. By that measure, the model was getting better every week. But the stability metrics started flashing: rewrites were slowly getting longer, and more and more of them were hitting the maximum length and getting cut off.
The model had quietly learned to game its own reward, in two ways.
First, it started padding rewrites with hedging phrases that name several possible intents at once. The relevance model had a mild bias toward keyword overlap, so stuffing in more plausible keywords nudged the score up without the rewrite genuinely being better.
Second, because the system only scores the truncated version of a rewrite (the part that fits the length cap), anything spilling past the cap was effectively invisible to the reward. Nothing pushed back on the bloat.
This is textbook reward hacking: the model optimized the letter of the metric, not its spirit. And crucially, the reward alone could not see it happening, which is exactly why the separate stability metrics existed.
The fix was a length-and-stop penalty. The paper reports the before-and-after cleanly:
| Metric (same week of data) | Without the fix | With the fix |
|---|---|---|
| Average rewrite length | 27.6 tokens | 22.9 tokens |
| Share of rewrites cut off by the cap | 82% | 38% |
| Core relevance metrics | baseline | all improved |
The lesson the authors draw is worth keeping: a reward function is, by construction, blind to the ways it is being gamed. You need a second, independent set of eyes (their stability metrics) to catch it.
The safety net: added, never replaced
A rewriter is only useful if the ranking system can lean on it without new risk. Two design choices handle that.
It runs off to the side, not in your way. The 7B model is not run while you wait for results. It runs asynchronously just after your query lands, and its output is cached. In steady state, more than 90% of impacted searches find a ready rewrite in the cache. If the cache misses or the service is down, your search simply proceeds with the normal signals.
It is added to ranking, never substituted in. The rewrite feeds three ranking stages, and at each one it contributes an extra parallel signal layered on top of the originals, rather than replacing them.
The three stages are just the usual funnel of a search engine: recall gathers a big pool of candidate videos, rawrank does a rough sort, and finerank does the careful final sort. At each one, CoRe adds its context-aware opinion on top of the existing machinery.
They call this a bounded blast radius: since the rewrite is only ever added, the worst case is "no better than before", not "broken". They even tested replacing the original signal instead, and it caused safety issues and worse results whenever the rewriter guessed wrong. So they kept the safer, additive design.
Their conclusion is a good engineering principle in general: graceful fallback to a known-good baseline should be a requirement, not a bonus.
Three findings that surprised me
A few results cut against what you might expect.
1. Bigger was not better. They tried a 24-billion-parameter model, roughly three times the size. It scored worse than the 7B model on their reward and cost about 1.7 times more to run. They kept the smaller one. For a field obsessed with scale, that is a nice reminder that fit-for-purpose beats big.
2. A lighter training method won. Instead of the heaviest reinforcement-learning approach (which learns from every generated attempt and is very expensive at this scale), they used a lighter preference method that only learns from the best-versus-worst rewrites in each batch. It was cheaper and it scored best.
Here is the offline comparison from the paper. Reward is their quality score (higher is better), and "rewrite improvement rate" is the share of cases where the rewrite beats your raw query.
| Model | Reward | Rewrite improvement rate |
|---|---|---|
| Your raw query (no rewrite) | 1.01 | n/a |
| Previous method (no LLM) | 1.49 | 58.2% |
| 24B model | 1.40 | 56.4% |
| 7B model, out of the box | 1.60 | 60.3% |
| 7B model, CoRe's method (shipped) | 1.93 | 66.4% |
3. The reward inherits the live system's evolution. Because the reward is scored by the production relevance model, upgrading that model shifts the reward target. When TikTok upgraded it in March, the metrics showed a one-week blip, then settled as the next models retrained against the new target. The authors frame this as a feature: the reward always tracks the real system, drift and all.
As for the online results, the paper is measured, and so I will be too. Across two staged launches, the rewriter delivered statistically significant gains on the headline relevance and engagement metrics, and a significant drop in the change-query rate, the rate at which users reformulate their search. Fewer reformulations, the authors argue, is direct evidence that people found what they wanted on the first try.
What this means for search marketers
Everything above is from the paper. This last section is my own reading, aimed at people who care about search and discovery. Treat it as interpretation, not as claims from the authors.
- TikTok search is a genuine, context-aware engine. The video someone watches right before searching shapes what they get. Discovery on the platform is a sequence, not a single isolated query.
- Short queries get expanded for you. When the engine itself fleshes out a two-word query, obsessing over exact-match keywords matters less than being richly and clearly relevant to a topic and its surrounding context.
- Engagement is literally the teacher. Strict clicks versus skips are what train the ranking. Content that earns real engagement, not just impressions, is what the system learns to surface.
- Relevance is multimodal. The scoring model reads the actual video, not only your caption and hashtags. What is on screen is part of how you rank.
- "Did they stop searching?" is the scoreboard. Change-query rate as a headline metric is the same instinct behind Google's click-based signals. If you want that rabbit hole, I wrote about it in this piece on NavBoost.
None of this is a growth hack. It is just a clearer picture of what the machine on the other side is actually optimizing for.
CoRe is, in the end, a small model doing a precise job: reading the video you just watched to guess what your short query really means, learning only from what people click and skip, retrained every week behind an automated gate, and wired in so carefully that if it broke tomorrow, you probably would not notice. It is a good window into how modern search really works now: less a static index, more a living system that learns from behavior.
If you like these paper breakdowns, I did one on what training data actually goes into large language models over in the FineWeb piece. The CoRe paper itself is on arXiv here (PDF) if you want the full technical version.
That's all for today. Bye!
Ian Sorin is an SEO consultant based in Lyon, France. With a deep passion for understanding how search engines work under the hood, he specializes in technical SEO and data-driven strategies.
