What makes conversational recommenders hard to build well?

Jannach et al.'s definition of a conversational recommender system is "a software system that supports its users in achieving recommendation-related goals through a multi-turn dialogue." This definition sounds permissive but is sharp: a CRS is task-oriented, so its conversation is bounded to a few pre-defined tasks (find an item, understand options, get explanations, refuse a recommendation). It is not ELIZA. The competence can be limited to one domain (movies, restaurants).

This bounding might suggest CRS is easier than open-domain conversation. But the challenge is not language fluency; modern LLMs handle that. The challenge is initiative. Real conversation between humans is mixed-initiative — sometimes I drive, sometimes you do, and we negotiate the transitions. A CRS must support user-driven dialogue (the user asks, the system answers), system-driven (the system asks for preferences, the user responds), and mixed transitions between them. It must respond to a varied taxonomy of user intents — providing or revising preferences, asking for explanations, rejecting a recommendation, chitchatting between recommendations.

Crucially, the CRS must keep track of the ongoing dialogue and possibly past interactions. Standard recommender models assume static user representations. A CRS works with a representation that updates turn-by-turn as preferences are elicited, refined, and revised.

The framing matters because it explains why "use an LLM as a CRS" is incomplete. LLMs handle language well. They do not natively handle initiative management, intent classification, dialogue-state tracking, or item-grounded retrieval. A CRS architecture wraps the LLM in components that handle these — and the integration of the LLM's general capabilities with the bounded dialogue management is where the actual research problem lives.

Source: Recommenders Conversational