Catalog Customization#

Catalog Schema#

The JSON schema used for Catalog RAG is currently targeted towards a restaurant based retail application. The RAG pipeline can be modified/updated to work for the existing schema easily. Here is a breakdown of various fields within the JSON schema -

  • _id [Dict] - Stores unique id

  • $oid [Str] - hexadecimal unique id for each entry in menu

  • menu_item [Bool] ⇒ set to False if you don’t want to show the item over UI as a separate item (for ex, toppings, ingredients), otherwise True

  • recommendation_type [List[Str]] ⇒ Reserved for future use

  • synonyms [List[Str]] ⇒ Alias name, if any, for this item

  • tags [List[Str]] ⇒ tags based on restrictions, specification etc., (For ex, vegan)

  • variations [List[Dict]] ⇒ Defining all possible variations

    • name [Str] ⇒ Reserved for future use

    • size [Str] ⇒ corresponding size of variation (For ex, small)

    • calories [Int] ⇒ total calories

    • price [Float] ⇒ total price

    • description [Str] ⇒ description of the food item (optional if is_default not set)

    • image [Str] ⇒ image location in NGC registry (optional if is_default not set)

    • is_default [Bool] ⇒ if available and set to True, this variation would be added to the cart if the user doesn’t mention a specific variation size

  • ingredients [List[Str]] ⇒ all ingredients present, ensure that ingredients are also added as separate food items in menu with menu_item=False)

  • toppings [List[Str]] ⇒ all available toppings, ensure that toppings are also added as separate food items in menu with menu_item=False)

  • name [Str] ⇒ name of the food item

  • item_id [Str] ⇒ unique alphanumeric item id

  • category [Str] ⇒ category of food item to which current item belongs to

All of the key-value pairs for a particular item are mandatory . So while updating OR adding a new menu item , make sure that all the default key-value pairs are present. Here is the snippet of the default schema used for Catalog RAG -

[
     {
     "_id": {
          "$oid": "string"
     },
     "menu_item": true,
     "recommendation_type": [
          "string"
     ],
     "synonyms": [
          "string"
     ],
     "tags": [
          "string"
     ],
     "variations": [
          {
          "name": "string",
          "size": "string",
          "calories": 0,
          "price": 0,
          "description": "string",
          "image": "string",
          "is_default": true
          }
     ],
     "ingredients": [
          "string"
     ],
     "toppings": [
          "string"
     ],
     "name": "string",
     "item_id": "string",
     "category": "string"
     }
]

Modifying the default Catalog#

The Catalog RAG provides an API POST /api/menu to set the catalog (with the same schema) on the fly. Note that the plugin server, cart manager, the UI Server and the UI need a restart following this update. Users can access this endpoint within the kubernetes cluster by using the Catalog RAG service port. Requests can be sent via curl or via the fastapi client page (Example: http://localhost:8080/docs).

For major changes that include using the Catalog RAG for a very different application than a retail restaurant, it is recommended to update the prompt vectorstore_prompt.txt and upload the updated json in the Catalog source such that it is utilized for creating a vectorstore at startup. The later approach would need the user to rebuild the Catalog RAG container and use the updated container for the Tokkio Catalog RAG microservice:

  1. Download the Catalog RAG resource:

    ngc registry resource download-version <CATALOG_RAG_RELEASE_VERSION>

  2. Navigate to the source directory with Dockerfile and build the container for the updated:

    docker build -t catalog-rag-container:test

  3. Tag the created image to be uploaded to the specific NGC path used for your organization:

    sudo docker tag <image_name> <NGC_PATH/ucs-tokkio-catalog-rag-container:version_num>

  4. Push the updated container to NGC:

    docker push <NGC_PATH/ucs-tokkio-catalog-rag-container:version_num>

  5. Use the updated container in the Catalog RAG microservice build. Modify the manifest.yaml in the ucs-tokkio-catalog-rag folder to use the updated container and the version. Build the microservice using UCS tools. Make sure to note down the updated microservice version number.

  6. Use the updated microservice version number for Catalog RAG to rebuild the Tokkio application. Refer to the Quickstart Guide section.

Updating Catalog Images#

The catalog image registry must be updated if any item image needs to be added or modified. To do that, follow the steps below:

  1. Run below commands to generate the UI production build. A “build” directory will be generated:

    npm install
npm run build

2. Make a new /images directory and put it inside the /build directory of the UI. The subfolders in this directory should be equal to image_loc field in API response from UI server. For example, the API response from GET: category/item/23 will have an image_loc field. Suppose image_loc field is equal to images/image-category/item23.png. Then UI should have an image for item 23 at directory /public/images/image-category/item23.png This should be followed for all items in the catalog. 3. The new /images directory should replace existing image directory in /build/images. 4. Upload updated build directory to S3 bucket:

aws s3 sync ./build s3://tokkio-ui

  1. Serve the newly generated static files in /build directory.

Functionality Customization - Catalog Schema, CM, Plugin Server and UI#

The Tokkio retail reference application expects the user to stick to the catalog schema and API flow as defined in the Tokkio retail microservices (MS). However, if needed these can be modified to incorporate any new requirements. In most of the cases changes would be needed across Plugin Server, CM, Catalog RAG and UI and their APIs.

On this page