Source-linked AI summary

Conversational Recommendation over Live E-Commerce Catalogues with Self-Refreshing Retrieval

Ante Kapetanovic, Tomislav Duricic, Dionizije Fa, Andro Mercep, Emanuel Lacic

arXiv:2608.27006v1cs.IR

TL;DR

Live e-commerce catalogues challenge conversational recommenders built and evaluated on static collections. The paper introduces a merchant-agnostic assistant with a hash-based self-refreshing retriever and controller-based dialogue layer, demonstrated through WhatsApp. Its case study confirms intended synchronization behavior, while recommendation quality and cost remain unevaluated.

  • Problem

    LLM-based conversational recommenders commonly use fixed collections, whereas production catalogues continually change and require fresh indexes.

  • Method

    A merchant-agnostic retriever hashes feed records to process only new, changed, deleted, or unchanged products, while a controller dialogue layer separates LLM tasks from retrieval and ranking.

  • Results

    The measured case study confirms the intended change classification and synchronization operation counts, and the assistant is demonstrated on WhatsApp.

  • Takeaways & Limitations

    Catalogue synchronization can be decoupled from dialogue so live catalogue changes reach recommendations after a successful sync.

  • Takeaways & Limitations

    The evaluation covers synchronization rather than ranking quality, and production deployment requires safeguards for non-transactional writes.

Abstract

from arXiv · show

Conversational recommender systems based on large language models (LLMs) are usually evaluated on static, pre-indexed item collections, yet e-commerce catalogues change continuously as products are added or removed, repriced, and restocked. We present a merchant-agnostic, multi-turn conversational shopping assistant that operates over such live catalogues. Its central component is a self-refreshing retriever that ingests a merchant product feed, enriches the records, and synchronizes them into a vector index. On each run, per-item hashes identify which products are new, changed, deleted, or unchanged, so only the delta is processed rather than rebuilding the whole catalogue. A controller-based dialogue layer consumes this index, using an LLM only for intent classification and preference elicitation while retrieval, reranking, and diversity selection run as dedicated functions. Our demonstration is a WhatsApp shopping assistant in which catalogue changes reach the recommendations after the next successful sync. A live chatbot, documentation, and a recorded walkthrough are available at https://github.com/infobip/infobip-agentic-crs.

1 Introduction

LLM-based conversational recommenders are commonly evaluated on fixed collections, while production catalogues change continuously. The paper addresses this freshness problem with a self-refreshing, merchant-agnostic retriever.

  • Motivation: Production catalogues change continuously, making fixed-collection evaluation insufficient for live shopping systems.Re-indexing every change is wasteful, while index drift can surface out-of-stock or discontinued products.
  • Motivation: The paper focuses on catalogue freshness as an engineering problem complementary to LLM recommender model quality.Its engine reuses an existing merchant product feed and is merchant-agnostic.
  • Contribution: A self-refreshing retriever re-embeds only new or semantically changed products, keeping synchronization proportional to the changed subset.The dialogue pipeline consumes the refreshed index independently of the vector store, model provider, and channel.

2 System Overview

The system separates catalogue synchronization, conversational interaction, and storage. Incremental hashes update only affected records, while a controller-based dialogue pipeline combines LLM assistance with dedicated retrieval and ranking functions.

  • System Overview: Three subsystems handle catalogue ingestion, multi-turn conversation, and shared storage for vector search, profiles, and session state.Shared storage decouples catalogue synchronization from dialogue, allowing both pipelines to run independently.
  • Self-Refreshing Retriever: Each manual or scheduled run compares the latest feed snapshot with the index and applies only the difference.The retriever does not monitor the feed continuously.
  • Self-Refreshing Retriever: Stable product IDs support exact updates and deletions, while full and semantic hashes distinguish feed changes from changes requiring re-embedding.Semantic hashing covers name, description, brand, and category.
  • Self-Refreshing Retriever: New or semantically changed records are enriched, embedded, and upserted; metadata-only changes update records and filters while retaining vectors.Deleted records are removed and unchanged records are skipped.
  • Conversational Pipeline: The conversation controller uses an LLM for eight-intent classification, replies, and preference elicitation, while retrieval, filtering, reranking, and diversity selection are dedicated functions.The recommendation path uses content-based semantic retrieval and can rerank candidates with a non-generative model.

3 Demonstration

The demonstration exposes the live catalogue through a WhatsApp shopping assistant. Its measured synchronization case confirms the intended incremental operations, while the prototype has explicit feed, integration, and production-scaling boundaries.

  • Demonstration: The WhatsApp assistant elicits preferences, searches the live catalogue, and returns diverse in-stock products with links.Catalogue changes reach recommendations after each successful synchronization.
  • Demonstration: A 500-record anonymized catalogue is evaluated with median synchronization runs against a 2.914 s full rebuild baseline.The table records enrichment, embedding, metadata-update, and deletion operations.
  • Demonstration: The measured case confirms that price or stock changes update metadata only, whereas description or category changes trigger re-enrichment and re-embedding.All ID, hash, feed-field, and embedding-call checks passed.
  • Demonstration: The prototype directly accepts Google Merchant Center Atom feeds, while other catalogue sources and messaging channels require adapters.Filtering, batching, consistency, and operations remain backend concerns behind the VectorStore interface.
  • Demonstration: Non-transactional writes require production safeguards such as truncated-feed detection, staging or rollback, and abnormal-delta monitoring.The paper makes no tens-of-millions-scale claim, and the full engine and integrations remain private.

4 Concluding Remarks

The paper presents a live-catalogue conversational assistant whose retriever processes only products that are new, changed, or removed. Its case study validates synchronization behavior, but recommendation quality and cost are not evaluated.

  • Conclusion: The self-refreshing retriever keeps the vector index consistent with a live catalogue by processing only new, changed, or removed products.The assistant is deployed as a WhatsApp demonstration.
  • Conclusion: The measured case study confirms that synchronization classification and operation counts behave as intended.The evaluation concerns synchronization rather than ranking quality.
  • Conclusion: Offline relevance and live user studies of recommendation quality and cost remain future work.The paper also identifies freshness-aware retrieval and hybrid ranking as future directions.

A Engine Architecture

The engine links a self-refreshing catalogue retriever with a WhatsApp conversation pipeline through shared storage. Hash-based classification ensures that only new or semantically changed products are enriched and embedded, while recommendations follow search, reranking, and diversity selection.

  • The self-refreshing retriever converts a merchant feed into a vector index using stable IDs and full and semantic content hashes.These hashes identify which products require processing during synchronization.
  • Only new or semantically changed products are enriched and embedded, while metadata-only updates retain their vectors.The architecture also removes deleted items and skips unchanged items.
  • The conversation pipeline uses an orchestrator to dispatch either to preference elicitation or to recommendation through search, reranking, and diversity selection.This pipeline serves WhatsApp shoppers.
  • A shared storage layer holds vectors, user profiles, and sessions, with the retriever writing state and the conversation pipeline reading it.The storage layer connects catalogue synchronization and dialogue while keeping their roles distinct.
Loading 2608.27006v1…