An AI recommender can learn when to recommend, not only what. A shopper opens a beauty assistant with a vague line: just browsing, not sure what they need. One version of the model answers with a product straight away, then another at the next turn, and another after that. The second version asks two questions instead. Skin or hair? Any particular concern? It names a product only at the third turn, when the shopper mentions that their foundation goes on patchy.
Both versions run on the same base model. The difference was trained in. That scene comes from the case study in Adapting Generative Recommenders for Multi-Turn Interaction, and it puts a name on something most AI visibility reports skip: the moment a recommendation happens.
What did the National Taiwan University study publish?
The study, posted to arXiv on 6 October 2026 as arXiv:2610.08136, presents INTEGER, a method that turns a product recommender into an assistant able to hold a conversation without losing its recommendation accuracy. Its seven authors are Yu-Chen Den, Zhi Rui Tam, Yung-Yu Shih, Shih-Hsin Wang, Yun-Nung Chen and Pu-Jen Cheng of National Taiwan University, and Eugene Yang of Johns Hopkins University. The paper is a preprint and has not yet been through peer review.
The starting point is a recommender trained on shopping histories. It sees what a user bought or rated, and predicts the next item. The researchers asked whether such a model can learn to talk, take corrections and refine its suggestions, without forgetting the link between past behaviour and the right product. Their answer is yes, with three safeguards, and a fourth step that teaches the model to react when a user rejects a suggestion.
The experiments use two public Amazon catalogues, Beauty (9,880 users, 11,707 products) and Toys and Games (9,631 users, 11,498 products). Because no large dataset pairs real shopping histories with real conversations, the dialogues were synthesized with a Tencent language model: 6,302 conversations for Beauty and 5,647 for Toys, averaging about seven turns each. The model itself is built on Qwen3-1.7B, a small open model.
What is a generative recommender?
A generative recommender recommends by writing out a product's identifier, token by token, the way a language model writes a sentence. Older recommenders score every product in a catalogue and return the top of the list. A generative one produces the code of the product directly.
The code is not arbitrary. In this study, each product's content is turned into an embedding with a sentence encoder, then compressed into a short sequence of codes, three levels of 256 values plus one for disambiguation. Products with similar content share the beginning of their code. A moisturiser and a neighbouring moisturiser sit on the same branch; a toy truck sits elsewhere.
That design has a consequence worth stating plainly. In a system built this way, the text that describes a product decides where it lives in the catalogue, and which products count as its neighbours. Because words and products share the same output space, recommending an item and writing a reply become one operation. That is what makes the conversation possible, and also what makes it fragile.
How does the model decide when to recommend?
INTEGER adds a special routing token to the model's vocabulary: if the model emits it at the start of a turn, it recommends; if not, it keeps talking. The decision is made by the same model that writes the reply, with no separate classifier.
The researchers measured how strongly the model wanted to recommend at every assistant turn of the test conversations. On the turns where a recommendation was expected, the median probability was 0.88. On conversational turns before that point, it was 0.09, and after it, close to zero. The separation between the two kinds of turn reached an AUC of 0.94.
The comparison model, trained on the same dialogues mixed with one-shot recommendation examples, tells the opposite story. Its AUC was 0.51, no better than chance. Its median probability of recommending on the turns before the expected moment was 0.99, higher than on the right turn. In the authors' reading, it had learned that a recommendation can open a conversation whatever the user has said.
The recommendation moment is the turn at which an AI system stops asking or explaining and puts forward a specific product, service or provider. In this study, a well-trained model places it after the user has named a concrete need, not at the first message.
Why does teaching an AI to talk weaken its recommendations?
Because conversation and recommendation share the same parameters, training one can overwrite the other. The paper measures both directions of that forgetting.
A model trained only on dialogues collapsed on both fronts. On Beauty, its hit rate fell to 0.029 and its conversation quality, scored from 1 to 5 by a separate judge model, dropped to 2.39. Removing either of the two behavioural safeguards cost about a third of the recommendation accuracy: from 0.049 to 0.033 without re-anchoring, to 0.034 without replay.
The first safeguard, which the authors call history re-anchoring, re-inserts the user's purchase history right before the product code is generated. The second, behavioural replay, keeps training the model on the original history-to-product task while it learns to talk. A third ingredient, general instruction data, restores conversational quality: with it, the judge score rose from 4.14 to 4.77 while accuracy barely moved.
The attention analysis is the most telling part. At the moment of recommending, the full model paid 2.11 times more attention to the user's history than when chatting. The dialogue-only model paid slightly less, 0.86 times. Looking at the history when it matters is a learned behaviour, and plain conversational training does not teach it.
For a brand, the practical reading is simple. In a system like this, two people who type the same sentence do not get the same product, because what each of them did before weighs on the answer at the decisive turn.
What happens when the user says no?
Before preference training, the model re-offered the rejected item every single time. Asked for something else, or told a product did not suit, it came back with the same product in its top ten, in 100% of the tested cases.
The authors then trained it with Direct Preference Optimization on pairs where the preferred answer replaces the current item rather than repeating it. The rejected item stayed in the top ten in 28.4% of variety requests and 26.9% of rejections. The correct item, originally ranked between second and fiftieth, was recovered in the top ten 36.7% and 36.4% of the time, against 22.8% and 18.2% before.
The detail that matters is what did not change. Whether the user asked for something similar or rejected the product outright, the replacement landed at almost exactly the same distance from the rejected item: a similarity of 0.885 in one case, 0.886 in the other. The model learned one move, step to the nearest neighbour, and applied it whatever the reason. The authors say so themselves, and note that an objection such as "too expensive" or "I want it in black" would need training on product attributes that this method does not have.
The substitution neighborhood is the set of items an AI system falls back on when a user rejects its recommendation. In the model studied here, the fallback stays close to the rejected item in content space, regardless of the reason the user gave.
How strong are the results?
INTEGER beat every baseline on Beauty and gave mixed results on Toys, with absolute hit rates that stay low. The table below reports the figures as published.
| Measure | INTEGER | Best baseline | Starting model (TIGER) |
|---|---|---|---|
| Beauty · Hits@10 | 0.051 | 0.045 | 0.038 |
| Beauty · Conv. Q | 4.77 | 4.58 | n/a |
| Toys · Hits@10 | 0.057 | 0.057 (tie) | 0.036 |
| Toys · NDCG@10 | 0.028 | 0.032 | 0.020 |
| Toys · Conv. Q | 4.25 | 4.55 | n/a |
On Beauty, the gain in hit rate over the best baseline is 13.3%, and the conversation score is significantly higher. On Toys, INTEGER ties the best conversational recommender on hits, loses on ranking quality and on conversation score. Against the recommender it was built from, it wins clearly on both catalogues.
A hit rate of 0.051 means the right product made the top ten in about one test dialogue in twenty. That is normal for this kind of benchmark, where the target is a single item among more than eleven thousand. It is also a reminder that these are research numbers on a narrow task, not a picture of how often a commercial assistant gets it right.
Supported: a recommender can learn to wait for a clear need before recommending, to weigh the user's history at that moment, and to replace a rejected item with a near neighbour. Not supported: "ChatGPT, Gemini or Perplexity recommend this way." No public source describes how those assistants decide when to recommend. The study shows that the behaviour can be learned, on a small model, two Amazon categories and synthetic conversations.
What does this change for measuring AI visibility?
It changes the unit of measurement: from a single prompt to a short conversation. What follows is the KAIS reading of the study. It extends the research to answer engines by analogy, and each point says how much of it is observable.
The first consequence concerns timing. Most AI visibility panels send one question and read one answer. If assistants hold back until a need is stated, the opening answer is the least representative moment of the decision. A brand can be absent from the first reply and named once the buyer describes a precise problem, or the reverse. The fix is observable: scripted scenarios of three or four turns in which the need is revealed gradually, with the turn of first appearance recorded for each brand.
The second concerns wording. In the case study, the recommendation was triggered by a concrete problem, patchy foundation, not by a category name. For a panel, that argues for questions written in the customer's own words, symptoms and situations included, alongside category and provider questions. It is the same logic as the query territories described in our analysis of query fan-out: the decision has several sides, and each side has its own vocabulary.
The third concerns personalisation. If past behaviour weighs on the answer at the decisive turn, a measurement taken from a clean account captures a baseline, not what a returning customer sees. That baseline is still the right reference for comparing brands, because it is the same for everyone. It should be labelled as a proxy, not presented as the experience of every user.
The fourth concerns rejection. Adding a refusal turn to a scenario, "not that one, something else", shows who takes the place of the leader. In the study, the replacement came from the content neighbourhood of the rejected item. Whether answer engines behave the same way is an inference to test, not a fact. But the question is commercially sharp: when a buyer turns down the market leader, is your brand the next candidate?
A multi-turn scenario records four things
- Turn of first appearance: at which exchange the brand is first named. Observed.
- Trigger: the user statement that preceded the recommendation. Observed.
- Substitute after refusal: which brand replaces the rejected one. Observed.
- Why it was chosen: proximity, history or evidence. Inferred, never observed.
None of this replaces the distinction between being cited and being recommended, set out in Your brand is cited by AI. Is it recommended?. It adds a dimension to it. A recommendation share measured on single prompts says whether a brand is chosen. A conversation says when, after what, and who comes next.
Where does this sit in the KAIS AI Visibility Chain?
The study sits entirely inside the seventh stage of the KAIS AI Visibility Chain, Be Recommended, and splits it into two questions: when the recommendation happens, and who replaces a rejected one.
Be Discovered → Be Retrieved → Be Understood → Be Trusted → Be Cited → Influence the Answer → Be Recommended.
It also illustrates one of the chain's documented exceptions. A generative recommender does not retrieve web pages and cite them. It recommends from what its parameters learned, here from shopping histories and product descriptions. That is the same shape as parametric recommendation in answer engines: a brand named with no visible source. A report that follows only citations would never see that path.
The earlier stages still apply. A brand that is not discoverable, not understood or not trusted will not enter any neighbourhood worth falling back on. The study simply shows that, at the last stage, timing and proximity become variables of their own.
The question moves to the third turn
For years the visibility question was where a page ranked for a query. Answer engines turned it into whether a brand appears in the answer. Conversational recommenders push it one step further. The useful questions are now at which turn a brand is named, after which statement from the buyer, and who takes its place when the buyer says no.
The shopper who opened with "just browsing" did not want a product at the first turn. The model that understood that was the one that recommended well.
Sources
- Den, Tam, Shih, Wang, Chen, Cheng and Yang — Adapting Generative Recommenders for Multi-Turn Interaction, arXiv:2610.08136 [cs.IR], 6 October 2026, National Taiwan University and Johns Hopkins University. Preprint, licence CC BY-NC-ND 4.0. Dataset statistics (Table 1), main results (Table 3), ablation (Table 4), routing probabilities and AUC (section 5.1), attention ratios (section 5.2), refinement results (Table 5), case study (Figure 5) and the authors' stated limitations (section 6). All figures in this article are taken from the paper; none were reproduced or re-measured by KAIS.