Tencent WeFair: A 2B Query Rewriter Serving WeChat Short-Video Search at 100M+ Queries a Day

Tencent's Weixin Group has published a paper on how it trains and runs a small language model that rewrites search queries in WeChat short-video search. The model, WeFair-2B, is described as deployed in production and serving "over 100 million queries per day." The paper, posted to arXiv on October 30, 2026 as 2610.16927 and featured on the Hugging Face papers page on November 2, is interesting for one finding that applies well beyond search: richer behavioral rewards did not make the rewrites more faithful, and strict, verifiable feedback worked better in the final training stage.

This is a research explainer. It covers the problem, the three-stage recipe, the numbers the authors report, and what builders can reuse. All figures are the authors' own, and we did not reproduce them.

At a glance

What problem does it solve?

A short search query is often ambiguous. A rewriter uses the user's recent searches and viewed content to expand it into a more informative query, which the search system uses as an extra retrieval query. Real-time search has strict latency limits, so the rewriter has to be small, and large general models are too slow per inference.

The paper's concern is intent drift. Models trained to maximize what users go on to watch can favour engaging content over what the user wants right now. The authors' example: a search for "crepe cake" is redirected toward recipes, when the user wanted videos of eating it. They define drift as a rewrite that adds information supported by the user's context but differing from the immediate need, and hallucination as a rewrite adding information the input does not support.

The system also has to decide when not to rewrite. A clear query should be left alone, so the model outputs either a short rewrite or a "preserve" marker.

How is WeFair trained?

The central idea is to match how strict the feedback is to what each training stage needs. The authors call the order demonstration, preference and verification.

Stage 1: curriculum SFT (demonstration)

Supervised fine-tuning runs in three phases. Phase one predicts a query from its preceding context, using a large pool of search-session data. Phase two learns a teacher-written rationale followed by the answer, and phase three predicts the answer directly. The rationales come from Gemini-3.1-Pro-Preview. The first phase uses broad, lower-fidelity data, and the later phases use a smaller set of reformulation and preservation examples.

The human feedback comes from real sessions. The team mines adjacent queries where the first got no video click and the second got an effective view, defined as watching a video for more than ten seconds. It filters them with rules (about half are removed) and then with three-model majority votes for intent continuity, information gain and contextual bridging (about one third of those pass). Preservation examples include natural ones, where the original query worked, and hard ones, where a proposed addition lacked support in the context.

Stage 2: DPO on consumption

Starting from the SFT model, the team samples 64 candidates per input and builds up to two preference pairs. A chosen candidate needs a relevant consumed video in its top-10 retrieval results, and a rejected one has none in its top 100. One pair uses the human reformulation as the positive. For queries that should be preserved, the preserve marker is the positive.

Stage 3: GRPO with exact-match reward

The final stage samples 32 responses per input and rewards a response only if it exactly matches the human reformulation or the preserve marker. Anything else gets zero. The authors say they tried graded similarity, retrieval and learned-judge rewards and that "the high-fidelity reward function outperforms other designs." They also flag a risk: preserving is easier than rewriting accurately, so the policy may learn to preserve too often, which they manage with a data ratio and reward weights.

What do the offline results show?

The authors trained on four weeks of search logs and tested on the next three days. As judge they used DeepSeek-V4.1-Flash, and checked it on 500 sampled Gemini-3.1-Pro rewrites against human review, with 96.6 percent agreement and a Cohen's kappa of 0.919. Baselines were DeepSeek-V4.1-Flash, Gemini-3.1-Pro and Qwen3.8-27B, plus the reproduced WeWrite and AWHCP methods.

Key points reported:

• WeFair-4B reaches 73.48 percent overall accuracy, above the strongest large baselines, Gemini 3.1 and DeepSeek 4.1. WeFair-2B reaches 72.81 percent and the highest consistent recall, 83.95 percent.
• Gains from size flatten: overall accuracy rises 5.91 points from 0.8B to 2B but only 0.67 points from 2B to 4B.
• WeFair-2B cuts the intent drift rate to about one third of comparable rewriting methods.
• Gemini 3.1 had the lowest hallucination and drift rates and the highest exact match, but much lower rewrite recall, meaning it preserved queries that should have been rewritten.
• Direct output beats chain-of-thought output at both 2B and 4B in overall accuracy. The authors read this as the training giving the model effective implicit reasoning.

Ablations support the recipe. The full curriculum beat versions without the early phases. SFT-only had low preservation recall, so it over-rewrote. DPO added small gains in recall but also over-rewrote. Adding the strict GRPO stage balanced rewriting and preserving, and the full sequence scored highest overall.

What happened online?

A 10-day online A/B test reported relative increases of 2.951 percent in click-through rate and 2.593 percent in effective video-view rate, with a 2.350 percent relative drop in query reformulation rate. The reformulation drop is the telling number: fewer users had to retype a query to get what they wanted.

Two cautions. These are relative changes inside one company's product, and the paper gives no absolute baselines in the text we read. And an A/B test on one platform for ten days says little about other languages or markets.

How does it fit into retrieval and ranking?

The rewrite is an addition, not a replacement. Two paths use it: a lightweight cache lookup of candidates linked to the rewrite, and an extra vector retrieval. In ranking, the original query stays as an anchor. The model's probability of the preserve token at the first decoding step gates the extra computation: above a threshold, relevance uses only the original query. Below it, the system combines scores for the original and the rewrite with weights. That design limits the damage of a wrong rewrite.

Where does it sit among earlier work?

The paper positions itself against a line of query-rewriting research. PicQue combines hybrid reasoning supervision with GRPO to curb over-rewriting, and uses historical reformulations as context for training examples that are then manually verified. WeWrite, from the same company, mines real user reformulations for supervised fine-tuning and builds GRPO rewards from lexical similarity and conditional query volume. AWHCP combines SFT, DPO and GRPO with quality, format and recall rewards. The authors reproduced WeWrite and AWHCP on the same training data for a fair comparison.

WeFair's claimed difference is not a new algorithm, since SFT, DPO and GRPO are all standard. It is the question of which kind of feedback belongs at which stage, and the finding that adding graded or learned rewards in the last stage hurt accuracy. That is a modest but practical contribution, and it is the part most likely to transfer to other domains such as product search or assistants that rewrite user requests.

What can builders reuse?

1. Separate what each stage is for. Noisy, broad data is fine for teaching a capability. Preference data refines choices. The final on-policy stage needs rewards you trust. This echoes our coverage of how small fine-tuned models can beat frontier models on a narrow task and the Exowatt case where a fine-tuned Qwen3 beat Claude Opus on alarm triage.
2. Prefer verifiable rewards where you can. Exact match is crude but hard to game, which matters because a graded reward invites reward hacking.
3. Add an abstain option. A "do nothing" output, with its own reward, protects queries that need no change.
4. Keep the original input as an anchor. Gate downstream use of a model's output by its own confidence.
5. Be honest about the judge. The authors validated their LLM judge against humans. Do the same with yours.

For another small, production-minded model release, see the Tencent Hy memory writer and our look at Liquid AI's d1 decision model.

Limits and open questions

• No release. The Hugging Face page lists no model, dataset or Space, and the training data comes from private logs.
• Single product. Chinese-language short-video search in one app.
• Offline judging. The judge is another LLM, though the authors report high agreement with humans.
• Reward hacking risk. The paper itself notes the pull toward over-preserving.
• Privacy. The authors say the data is de-identified and sanitized, and as ever readers cannot audit that.

Related reading

• Coinbase's fine-tuned Qwen3.5 9B beats frontier models on fraud
• Exowatt: fine-tuned Qwen3 beats Claude Opus on alarm triage
• Tencent Hy memory: an open memory-writer model
• Liquid AI d1: a small decision model
• DeepSeek V4.1 Flash 1017: open weights and pricing
• Vals AI: Chinese models across languages
• Sources: arXiv 2610.16927, Hugging Face paper page

Figures are from the authors' paper and accurate as of November 2, 2026.