TV LLM Conversational None UC

• 1: Dialog configuration
• 2: AI configuration by OB

1 - Dialog configuration

Configuration of the generic-ai-dialog for TV LLM Conversational None UC

Specific configuration

The TV LLM Conversational None UC is triggered by the generic-ai-dialog-v1 for channelData v1 or generic-ai-dialog-v3 for channelData v3. For this use case, the required specific configuration is set below:

Example v1:

    {
    "name": "generic-ai",
    "dialogs": [
        {
            "id": "generic-ai-dialog-v1",
            "onlyIn": [
                "set-top-box"
            ],
            "triggerConditions": [
                {
                    "intent": "intent.conversational.none",
                    "settings": {
                        "locales": {
                            "error": [
                                "tv.error.fpaOrCognitive"
                            ]
                        }
                    }
                }
            ]
        }
    ]
    }

Example v3:

    {
        "channelDataVersion": "v3",
        "id": "generic-ai-dialog-v3",
        "onlyIn": [
            "set-top-box",
            "global-video-platform"
        ],
        "triggerConditions": [
            {
                "intent": "intent.conversational.none",
                "settings": {
                    "locales": {
                        "error": [
                            "core:flc.answer.error"
                        ]
                    }
                }
            }
        ]
    }

2 - AI configuration by OB

AI configuration by OB

The following information applies to both Spain and Brazil; there will not be separate blocks for each OB.

Introduction

LLMs UCs are configured and located within the aura-config-provision repository. See the TV LLM Conversational None Preset (notice that in the url, the field [ob] needs to be replaced by [es] or [br]) LLM use cases have been designed to provide a fallback mechanism for user requests that are not currently understood, i.e. return a ‘None’ intent, or when no content is found in the video platform related to it, offering a second chance for classification and response generation.

Intent

The Conversational None Use Case has different invocation points:

1. From triage: when the LLM fails to map the user’s input to any known intent often due to ambiguous, incomplete or broad queries (“Uno hacia abajo”, “Sintoniza el canal”, “Cambia cómo suena”).
2. From failures or KOs occurring in other supported use cases.

Once the user’s input is classified as intent.conversational.none, the request is routed to the Conversational None Agent, an LLM-based conversational module designed to handle unclassified or unsupported queries with the goal of guiding the user toward valid flows or supported actions within the platform by suggesting possible next steps or rephrasing options.

The conversation is considered complete once the LLM returns a response to the user. Subsequent user inputs will be reprocessed through the full recognition pipeline, including both deterministic and LLM-based intent classifiers.

LLM output format

In the output format, the LLM returns a structured JSON response based on predefined Use Cases configured within the field use_cases in the preset (in args). These Use Cases follow a structured format that includes three fields separated by a pipe (|):

• NAME (mandatory): The name of the Use Case.
• DESCRIPTION (optional): A short explanation or instruction. This field may be empty.
• EXAMPLE (mandatory): A representative user utterance for that Use Case.

Sample extract from use case information:

Based on this information and according to matching criteria with the user’s request, the LLM constructs its output response by returning two fields:

• “speak”: intended for voice output to be spoken by the system.
• “text”: displayed on screen as visual feedback within the Video Platform interface.

The content of these fields varies depending on the type of match between user’s input and the predefined Use Cases:

• Single Use Case Match:
  • If the Use Case has a description:
    • “speak”: this field references the name of the Use Case related to the request, describes its invocation process and includes a relevant example.
    • “text”: this field mirrors the example used in “speak”.
  • If the Use Case has no description:
    • “speak”: this field mentions the name of the Use Case linked to the request and the corresponding example.
    • “text”: this field mirrors the example used in “speak”.
• Multiple Use Cases Match:
  • “speak”: this field mentions the ambiguity and shows two likely Use Cases with examples.
  • “text”: this field includes the same two examples.
• No match:
  • “speak”: this field explains the uncertainty and suggests two random valid Use Cases with examples.
  • “text”: this field repeats only the examples pertaining to the Use Cases shown in “speak”.

This conditional behavior ensures that the assistant gives relevant, helpful responses tailored to the context of the user’s request.

Examples in Castilian Spanish:

Examples in Brazilian Portuguese: