Multi-model switching and distributed multi-stage machine learning to enhance field diagnostics and services

Abstract

The invention relates to multi-model switching and distributed multi-stage machine learning to enhance field diagnostics and services. In particular, an improved solution is provided for on-site diagnostics and services to enable more efficient and efficient communication with users. Some solutions enable a user to better communicate with a provider to obtain more useful diagnostic and service information. Certain solutions can employ a multi-model switching machine learning technique to enhance communication of a user with the provider and / or response of the provider.

Description

Technical Field

[0001] The present disclosure relates generally to providing diagnostic and service information in broadband networks, and more specifically to employing machine learning models to enhance the provision of such information. Background Art

[0002] Current analysis systems for broadband operator network diagnostics and services are typically based on fixed analysis algorithms and data collection procedures. Furthermore, these algorithms are typically executed independently on local customer premises equipment (CPE), network edge devices, or the cloud. Such systems can cause frustration and confusion to users of the system, particularly subscribers, who typically may not know to ask the right questions and / or provide the right information to allow the system to diagnose the problem, and who may not understand the information provided by the system, such as diagnostic information or solutions that employ overly technical information or require deeper system knowledge than the subscriber may possess. Therefore, there is a need for solutions that enable more effective and efficient broadband operator field diagnostics and services. Summary of the invention

[0003] In one aspect, the present disclosure relates to a device comprising: a network interface; one or more processors; and logic, the logic comprising instructions stored on a non-transitory computer-readable medium, the instructions being executable by the one or more processors, the logic comprising: logic for receiving a user query related to a network service; logic for receiving operational information about the network service; logic for generating an enhanced chat prompt using a first machine learning engine based at least in part on the operational information; logic for transmitting the enhanced chat prompt through the network interface for processing by a general conversational artificial intelligence; logic for receiving a response generated by the general conversational artificial intelligence through the network interface; logic for enhancing the response using a second machine learning engine; and logic for providing the enhanced response for presentation to a user.

[0004] On the other hand, the present disclosure relates to a system, comprising: a first device, comprising: a first one or more processors; and a first logic, the first logic comprising instructions stored on a first non-transitory computer-readable medium, the instructions being executable by the first one or more processors, the first logic comprising: logic for receiving a user query related to a network service; logic for receiving first operation information about the network service; logic for generating an enhanced chat prompt using a first machine learning engine based at least in part on the operation information; logic for transmitting the enhanced chat prompt for general conversational artificial intelligence processing; and a second device, comprising: a second one or more processors; and a second logic, the first logic comprising instructions stored on a second non-transitory computer-readable medium, the instructions being executable by the second one or more processors, the first logic comprising: logic for receiving a user query related to a network service; logic for receiving first operation information about the network service; logic for generating an enhanced chat prompt using a first machine learning engine based at least in part on the operation information; logic for transmitting the enhanced chat prompt for general conversational artificial intelligence processing; and a second device, comprising: a second one or more processors; and a second logic, the first logic comprising instructions stored on a second non-transitory computer-readable medium, the instructions being executable by the second one or more processors, the The second logic includes: logic for receiving the enhanced chat prompt from the first device; logic for receiving second operation information about the network service; logic for further enhancing the chat prompt using at least a second machine learning engine based at least in part on the second operation information; logic for transmitting the further enhanced chat prompt for processing by a general conversational artificial intelligence; logic for receiving a response generated by the general conversational artificial intelligence; logic for enhancing the response using a fourth machine learning engine; and logic for providing the enhanced response to the first device; wherein the first logic further includes: logic for receiving the enhanced response from the second device; logic for further enhancing the response using a third machine learning engine; and logic for providing the further enhanced response for presentation to the user.

[0005] On the other hand, the present disclosure relates to a method, comprising: receiving a user query related to a network service at a device including a processor; receiving operational information about the network service at the device; utilizing the device to enhance a chat prompt using a first machine learning engine based at least in part on the operational information; utilizing the device to transmit the enhanced chat prompt for processing by a general conversational artificial intelligence; utilizing the device to receive a response generated by the general conversational artificial intelligence; utilizing the device to enhance the response using a second machine learning engine; and providing the enhanced response from the device for presentation to the user. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Figure 1 is a block diagram illustrating an example broadband network in accordance with some embodiments.

[0007] Figure 2 is a block diagram illustrating the flow of information between various components of an example system for providing field diagnostics and service in accordance with some embodiments.

[0008] Figure 3 is a block diagram illustrating a chat prompt and response engineering model according to some embodiments.

[0009] Figure 4 Example techniques for enhancing chat prompts and / or responses according to some embodiments are described.

[0010] Figure 5A and 5B is a flow diagram illustrating a process for enhancing chat prompts and responses according to some embodiments.

[0011] Figure 6 is a block diagram illustrating an example multi-head machine learning model according to some embodiments.

[0012] Figure 7 is a block diagram illustrating an example hierarchical machine learning model according to some embodiments.

[0013] Fig. 8A and 8B is a block diagram illustrating an example model hopping machine learning model according to some embodiments.

[0014] Figure 8C and 8D Description of some embodiments Fig. 8A and 8B An example backbone architecture for use with models from .

[0015] Fig. 9 is a block diagram illustrating an example machine learning model for analyzing orthogonal frequency division multiplexing channels of a broadband network according to some embodiments.

[0016] Fig.10 is a block diagram illustrating an example machine learning model for analyzing quadrature amplitude modulation channels of broadband networks in accordance with some embodiments.

[0017] Fig.11 is a block diagram illustrating an example multi-model switching machine learning model operating in parallel mode according to some embodiments.

[0018] Fig.12 is a timeline diagram illustrating a timeline for model delegation options according to some embodiments.

[0019] Fig.13 is a block diagram illustrating an example multi-model switching machine learning model operating in parallel mode using a majority voting strategy according to some embodiments.

[0020] Figures 14 to 16 is a block diagram illustrating the operation of an example multi-model switching machine learning model operating in serial mode according to some embodiments.

[0021] Fig.17 is a block diagram illustrating example components of a computer system according to some embodiments. DETAILED DESCRIPTION

[0022] Some embodiments provide improved solutions for more effective and efficient on-site diagnostics and services for providers (also referred to herein as "operators" of such networks and services) that provide broadband (and / or other) services to customers, for example. In short, as used herein, a "provider" is any entity that provides services to customers or other users. An example of a provider is a broadband provider that, in some embodiments, provides network services (which may include, but are not limited to, data services, Internet service providers (ISP) services, telecommunications services, television and / or streaming content services, and / or the like). Examples of broadband providers include, but are not limited to, cable TV providers, ISPs, satellite TV providers, telephone service providers, and / or the like. On the one hand, some embodiments may enable users to better communicate with providers to obtain more useful diagnostic and service information, in particular. In particular, certain embodiments employ multi-model switching machine learning techniques to enhance user communications with providers (e.g., fault tracing requests, etc.) and / or responses of providers. This may enable more relevant and feasible fault tracing suggestions (or other communications) to be provided, which may increase user satisfaction and enable providers to use subscriber communication resources more efficiently, among other benefits.

[0023] For purposes of this disclosure, the term "user" refers to any entity that uses the solution described herein, e.g., to submit queries to the system and / or receive responses back from the system. Users may include, but are not limited to, actual customers (e.g., subscribers) of a provider; customers, partners or guests of such customers; other users of the services provided (e.g., Internet services, television or content distribution services, telecommunication services, etc.), and / or the like. For convenience, the terms "customer," "subscriber," and "user" are used synonymously herein unless the context clearly dictates otherwise.

[0024] In some embodiments, the device, system and / or method may be implemented in a provider network, which may include an edge network, such as a cable TV network, a digital subscriber line (DSL) network, a metropolitan Ethernet network, and / or a passive optical network (PON) network, to name a few examples. In aspects of some embodiments, machine learning (ML) and analytical capabilities (including but not limited to data clients, ML agents, and / or ML proxies) may be distributed across various levels of the network hierarchy, covering devices and functional components, such as Internet of Things (IoT) devices, user devices, customer premises equipment (CPE), signal amplifiers, edge nodes, other provider network components, and / or cloud resources. In some embodiments, these capabilities may be dynamically configured, deployed, and / or utilized to enable improved field diagnostics and services for providers. In particular, these capabilities may include one or more general conversational artificial intelligence engines (GPC AI) (also referred to herein as "chat engines") and / or other user interfaces (UIs) (e.g., as described below), as well as a variety of adaptive and distributed ML models that enable chat (and / or other) prompt engineering and response expansion.

[0025] The term "chat engine" (or GPC AI) is used herein to describe any machine learning engine and / or artificial intelligence configured to interact with other entities (e.g., with users); in some aspects, such interactions are conducted in a conversational (e.g., prompt and response) manner and are designed to answer questions (e.g., queries) posed in a natural language format and provide those answers in a natural language format. Examples of chat engines include, but are not limited to, ChatGPT from OpenAI, Bard from Google, LLaMA from Meta, any other publicly available and / or privately operated system that performs similar functions, and / or the like. In one aspect, some embodiments may integrate a chat engine into a provider's analytics system to enhance the provider's field operations and services, generate natural and actionable chat insights, reports and surveys for providers and / or users, provide self-service recommendations and / or promotions for operator services to users (e.g., via a chat interface), improve chat accuracy and relevance of analytics applications. In other aspects, various embodiments may utilize diagnostic and / or operational information of device platforms and networks to improve chat accuracy and relevance via chat prompt enrichment and chat response augmentation.

[0026] As used herein, the term "chat prompt" means any text or data that can be provided to, for example, a chat engine to prompt a response, including but not limited to a user query provided by a user. A "response" is any response received from the target of a chat prompt (e.g., a chat engine) that is or purports to be a response to a chat prompt. An "enhanced" chat prompt or response, respectively, is a chat prompt or response that has been enhanced by any of the techniques described herein (e.g., by adding information or context to the user query (or any other chat prompt) and / or the response that increases the probability that a relevant and / or actionable response is ultimately returned to the user). As used herein, the term "operational information" may include any information about the network (or other) services provided, including but not limited to information about the network infrastructure (e.g., information about the architecture, topology, performance, outages or problems with the network or any of its various components), user environment information (e.g., user LAN information, user identification information, user sentiment information, subscriber account or profile information, information about CPE and / or user devices involved in the provision or consumption of network services, etc.), provider policies, and / or any other available information that may be relevant to users, providers, network services and / or the provision of network services.

[0027] Certain embodiments provide more efficient communication between the provider's analysis system (and other resources) and users seeking help by improving user interface (UI) components and interactions. For example, some embodiments customize and / or fine-tune chat models for diagnostic tasks by using the fine-tuning capabilities of the chat engine. Embodiments may also utilize many different types of UI components and technologies for local user chat input / output, including but not limited to text chat interfaces (e.g., in a web browser and / or on a provider web page), voice interfaces (e.g., interactive voice response (IVR)) and voice ML capabilities on CPE devices, landline telephone interfaces (e.g., interfaces available on packet cable VoIP systems and DSL / PON modems), far-field voice (FFV) interfaces (e.g., interfaces on set-top boxes (STBs) and remote controls), applications and / or application (app) interfaces on PCs, mobile phones, tablet computers, smart TVs and other smart devices and / or the like, electronic program guide (EPG) interfaces provided by STBs on TVs, etc. Some embodiments may also implement various ML capabilities in these UIs, including but not limited to keyword spotting (KWS), speaker recognition, natural language processing (NLP), text-to-speech (TTS), and speech-to-text (STT), etc. However, the embodiments are not limited to any particular UI components or technologies; any of many existing UI technologies may be implemented according to various embodiments.

[0028] More generally, as used herein, the term "user interface" means any communication interface (and / or means for providing such an interface) that allows a customer (or other user) to consume products (including services) provided by a provider and / or to interact with the provider. Such interaction may include, for example, providing a user query to the provider network and / or receiving a response to that query. The term "user query" is used broadly herein to describe any communication from a user to a provider (and / or to a chat engine that provides a response to the query) using any communication mode that is available and / or appropriate given the particular user interface(s) employed. In some aspects, a query may include a question and / or request regarding an issue or problem with the use of a provider's service or network and / or the user's CPE, including but not limited to a service request (e.g., a request for a provider to fix or make a change to correct a real or perceived problem with a customer's consumption of a service and / or network). In some cases, the interface used by a customer to provide a query may be the same as the interface used to provide a response. For example, a user may call in a question to an IVR (or human operator) on a landline phone, and a response to that query may be provided (again by the IVR or human operator) over the same phone (i.e., in the form of a phone call). Similarly, a customer may send a query via a chat interface on a provider's website and receive a response through the same chat interface. However, in other cases, the interface used by the provider's system to receive queries and the interface used by the provider's system to provide responses may be different. For example, the provider's system may receive queries through a chat interface and provide responses through a telephone interface (e.g., via a call back). Unless expressly stated otherwise, neither the nature of the CPE nor the nature of the UI limit any embodiment, and the above examples are provided for illustrative purposes only.

[0029] Thus, various embodiments may enable user-initiated local diagnostics and self-help, diagnose and / or repair Internet access problems (e.g., related to data speed, latency, etc.), perform and / or teach the user to perform LAN and / or WiFi configuration (e.g., change channel / band, add extender, adjust transmitter power, etc.), resolve STB video problems (e.g., macroblocking issues, black screen, freeze, etc.), and the like. In other aspects, if appropriate, the UI may market or alert the user to new features and services (possibly with an overview, pricing, and contact instructions). Such services may include Internet level upgrades, video package upgrades, newly available WiFi services, new devices and / or device features, etc.

[0030] As used herein, unless the context dictates otherwise, the term "local" is used from the perspective of a user and / or CPE, meaning that the term "local device" refers to the CPE, and the term "local" when describing a component refers to a component that is part of the local and / or a component that is local (e.g., within the same premises and / or owned, used, etc. by the user of the CPE (even not within the premises, which may be the case for mobile devices, etc.)). In contrast, as used herein, the term "remote device" may include any device that is not a CPE. For example, as discussed below, a remote device may include, but is not limited to, one or more edge devices, core devices, and / or cloud servers. Reference to a "remote" component indicates that such a component is part of the remote device.

[0031] On the other hand, some embodiments may enhance the accuracy and / or relevance of the provider's analytical insights. This may include using various ML models to provide more detailed analysis (e.g., based on the collection, aggregation, and / or correlation of various user, device, network, specific, and generic data). Also through the use of ML models, this may also provide more actionable and / or specific recommendations that take into account many more factors than was previously possible.

[0032] One set of embodiments provides devices; such devices may include, but are not limited to, CPEs such as cable TV, DSL and / or PON modems, optical network interface (ONU) routers, access points, fiber interfaces, Ethernet interfaces, cable and / or satellite set-top boxes (STBs) (and / or satellite receivers), and the like. Such devices may also include edge devices (e.g., cable headends, DSL access multiplexers (DSLAMs), optical fiber terminals (OLTs), signal amplifiers) and other provider equipment (e.g., core devices, computer systems (e.g., personal computers, servers, etc.), and / or the like). Some embodiments provide devices that may serve as components of larger devices such as those described above; examples of such components may include semiconductor components that may range from a single circuit to a complex system on a chip (SoC).

[0033] Among other hardware and / or software components, such devices may include logic. As described in further detail below, in some cases, the logic may be a hardware circuit system. In other cases, some or all of the logic may include instructions that can be executed by one or more processors. Therefore, such devices may also include one or more processors (examples of which are described in further detail below). In some cases, the instructions may be encoded on a non-transitory storage medium, which may include firmware and / or, for example, if some or all of the instructions are implemented as software, then include permanent or volatile storage devices, many of which are described in detail below. In one set of embodiments, the logic may configure or program the device to perform the operations and / or methods described herein.

[0034] For example, a device according to some embodiments may include logic for receiving a user query related to a network service and / or logic for receiving operational information about the network service. In some cases, the device may include logic for enhancing a chat prompt using a first machine learning engine, for example, based at least in part on the operational information. "Machine learning engine" means software that uses one or more machine learning models to perform one or more machine learning jobs or tasks. On the one hand, a machine learning engine may be considered to "include" such a model, even if the model is technically separated from the engine itself. The following discussion describes various techniques that can be performed by a machine learning engine to select a model, organize the operation of a selected model, perform tasks and jobs using such a model, and / or the like. On the one hand, a machine learning engine may be any combination of hardware and / or software that can perform these techniques. In some cases, enhancing prompts may include enriching prompts and / or generating supplementary prompts. These two operations are described in further detail below. In some cases, the device may include logic for dividing user queries into "local" (local to that device) and "remote" (remote relative to that device) answerable queries. The machine learning engine in the device (e.g., CPE, first edge device, etc.) may provide a first answer to the received query as part of a new prompt, and then the machine learning engine may transmit the first answer along with the simplified query to a second machine learning engine at a second device (e.g., another edge device, a core device, etc.). The device may also include logic for transmitting an enhanced chat prompt for processing by the GPC AI. In a particular embodiment, the device may include logic for receiving a response generated by the GPC AI, logic for enhancing the response using a second machine learning engine, and / or logic for providing an enhanced response for presentation to the user. Such a device may include other logic, such as for performing the operations described in conjunction with the accompanying drawings (including but not limited to Figure 5A and 5B ) describes the logic of the action in more detail.

[0035] Another set of embodiments provides a system that may include multiple devices. Some or all of such devices may include similar functionality (and / or different or additional functionality) as described above and elsewhere herein. By way of example only, a system may include a first device. In some cases, the first device may be a CPE or the like. The first device may include logic for receiving user inquiries related to a network service, and / or logic for receiving first operational information about the network service (e.g., operational information about a local network, the device itself, etc.). The first device may further include logic for enhancing chat prompts using at least a first machine learning engine, for example, based at least in part on the operational information. The first device may also include logic for transmitting enhanced chat prompts for processing by the chat engine. However, such transmission does not necessarily have to be directed to the chat engine. For example, in some embodiments, the first device may direct the second device to receive a transmission of an enhanced chat prompt.

[0036] In some cases, the second device may be, for example, an edge device in an edge network of a broadband provider or another device remote from the CPE, such as a remote device, as described in further detail below. The second device may include logic to receive an enhanced chat prompt from the first device and / or logic to receive second operational information (e.g., regarding the edge network, provider policy, etc.). The second device may then include logic to further enhance the chat prompt using at least a second machine learning engine, for example, based at least in part on the second operational information. The second device may also include logic to transmit the further enhanced chat prompt for processing by the chat engine.

[0037] In some embodiments, the second device may include logic to facilitate returning information to the user. By way of example only, the second device may include logic to receive a response generated by the chat engine, logic to enhance the response, e.g., using at least a third machine learning engine, and / or logic to provide the enhanced response to the first device. The first device may further include logic to receive the enhanced response from the second device, logic to further enhance the response, e.g., using at least a fourth machine learning engine, and / or logic to provide a further enhanced response for presentation to the user.

[0038] Various embodiments may provide substantial improvements over current systems and processes. (Of course, it should be noted that the embodiments are not limited to embodiments that provide all (or any) of such improvements.) By way of example only, some embodiments allow a chat engine (or chatbot) to be seamlessly integrated into an analytics system to generate comprehensive and insightful information for operators and users, where chat prompts and responses are designed (e.g., enhanced, augmented, etc., based on the techniques described below) to adapt to the dynamics of user input, device and network status, user / operator preferences, and the like.

[0039] In one aspect, some embodiments employ distributed multi-stage processing including ML models that can be executed collaboratively on CPE, provider devices (e.g., edge devices, core devices, etc.), and / or the cloud (e.g., a cloud-based chat engine). In another aspect, ML models (including but not limited to the models described below) executed on CPE and / or provider devices can provide pre-processing, post-processing, and / or direct assistance to the chat engine. Such ML models can be adaptively configured and / or selected / determined via a multi-model switching scheme, including but not limited to a model hopping mode, a parallel model mode, and a serial model mode, such as described in further detail below.

[0040] The multiple models adopted by various embodiments may include, but are not limited to, pre-trained fixed models and / or auxiliary models derived and dynamically determined using some common backbone network architecture. The generation of auxiliary models from the common backbone network architecture may take into account factors such as model complexity, model performance, ML engine processing power, device and network status, user and operator preferences, etc. On the one hand, the generation of auxiliary models may be represented by a dedicated multi-head of the common backbone architecture. In some embodiments, the multi-head may be trained with dedicated and / or dynamic chat prompts and data sets, while the backbone architecture may be trained with shared and static chat prompts and data sets. As used herein, the term "application" is widely used to represent applications, purposes, goals, etc., and the techniques described herein are used for the application purposes, goals, etc. according to embodiments, implementation schemes, or specific conditions, except when used in conjunction with a mobile phone or computer (in which case, "application" or "app" means a software application stored on or running on such a device). Therefore, the application can diagnose and / or repair network outages or other conditions reported by a user or another device, generate responses to specific inquiries from the user, etc. As disclosed herein, in many cases, the selection of an ML model to use, or the decision to switch between models, may be based (at least in part) on the application in question, since different models may be more or less relatively appropriate (for a variety of reasons) in the context of a given application. Thus, as used herein, "specific" information refers to any information that is specific to that particular application, including but not limited to operational information (e.g., as described above) and any other information relevant to the particular situation (as opposed to generic information that is not specific to the particular situation surrounding the user's inquiry, such as general network information, troubleshooting information, etc.).

[0041] Some embodiments include the ability to retrain various ML models. For example, ML models and / or chat engines may be retrained (offline or during operation) to adapt to field conditions of provider's equipment, CPE and user devices, diagnostic and service requirements, etc. In some embodiments, ML models executed at various locations (e.g., at CPE, edge devices and other provider devices, on the cloud, etc.) may cooperate with each other to improve training effectiveness and end-to-end hybrid system functionality.

[0042] Figures 1 to 4 Some examples of such devices and systems are described. Figure 1 1 is a block diagram illustrating an example broadband provider's network 100 according to some embodiments, which may include components of a system that may provide, among other things, field diagnostics and services. The network 100 includes a core network 105a and an edge network 105b. In one aspect, the core network 105b may be an internal network of the broadband provider, including a plurality of edge devices 110, some of which (e.g., edge devices 110a-c) provide connectivity between devices in the core network 105a and devices in CPE 115. The CPE 115 may include any device that acts as an interface between the edge network 105b and a user device (not shown) at a consumer end.

[0043] This CPE may include, but is not limited to, the CPE described above, and CPE may generally be considered to be equipment on the subscriber side that provides an interface with the provider's network. In many cases, CPE is given, loaned, leased, and / or sold to a subscriber; in other cases, CPE may be purchased by the subscriber from a third party or otherwise provided by the subscriber. In addition, in some embodiments, CPE may also include user devices, even though some conventional usages of the term "CPE" may exclude such user devices. The term "user device" is used broadly herein to include any device that can (but not necessarily always) provide connectivity between a customer (or any other user) and the edge network 105b. Thus, user devices may include, but are not limited to, mobile phones, voice over IP (VoIP) devices, landline (e.g., plain old telephone system or POTS) phones, computers (including, but not limited to, laptops, desktop computers, workstations, servers, tablet computers, etc.), televisions and television remote controls, display devices, game consoles, smart home appliances, local area network (LAN) hardware, and / or the like. In one aspect, CPE 115 and / or user devices may provide, among other things, one or more UIs to allow a user to interact with a provider's network 100 (including but not limited to the networks described above).

[0044] Each of the edge devices 110 may be any device that provides an interface between the core network 105a and devices outside the core network 105a. For example, in the edge network 105b, the edge devices 110a-c may be a cable headend, a DSL access multiplexer (DSLAM), a passive optical network (PON) transceiver, an optical fiber terminal (OLT), and / or the like. More generally, the edge device 110 may include any device that provides connectivity between the core network 105a (and / or devices therein, such as the core device 120 and / or the operator user interface 125) and resources outside the core network 105a, particularly the CPE 115. The core network 105 may also include border devices, such as the core device 120d having a WAN connection, such as through a point of presence (POP) and / or peer connection to an external network 130. In some embodiments, the external network 130 may be the Internet.

[0045] Edge devices 110 and core devices 120 (collectively referred to as "provider devices") may be any server, networking device (e.g., switch, router, etc.), or other device involved in providing broadband services to customers, particularly within core network 105a and / or edge network 105b, but more generally anywhere in provider network 105. They may include content delivery networks (CDNs), diagnostic and / or repair facilities, and / or the like. In some cases, one or more core devices 120 may be part of a communication path that provides content or services (e.g., broadband services) to consumers. Thus, one or more core devices 120 may participate in the chat and prompt enrichment process performed by various embodiments.

[0046] In some embodiments, provider network 100 includes (or, as in the illustrated embodiment, communicates with) chat engine 135. In one aspect, chat engine 135 may reside on cloud server 140 (which may include any number of physical or virtual machines, etc.), which may have other logical components described elsewhere herein. Figure 1 An external network 130 is illustrated that provides communications between the core network 105a and the chat engine 135, but other embodiments may include the chat engine 135 and / or cloud server 140 within the core network 105a and / or another network operated by a broadband provider. In some embodiments, the provider operates the cloud server 140 and / or chat engine 135. In other embodiments, the cloud server 140 and / or chat engine 135 may be operated by a third party with whom the provider may or may not have a contractual arrangement to use the services of the cloud server 140 and / or chat engine 135.

[0047] In one aspect, the chat engine 135 may receive prompts (formed by user inquiries, as described herein) and provide responses. As described herein, various embodiments may enhance the prompts and / or responses to increase the likelihood that the responses will contain actionable, understandable information that appropriately addresses the (real or perceived) situation that gave rise to the user's inquiry.

[0048] In certain embodiments, providing a response to a user query may involve human personnel (e.g., a support engineer, a help desk attendant, etc.). Thus, as illustrated, the provider network 110 (and / or the core network 105a) may include and / or communicate with an operator UI 125. The operator UI 125 may include one or more devices that may provide a UI for such personnel working for or on behalf of the provider. In some embodiments, the support personnel may (directly and / or indirectly) receive a user query (or a prompt generated thereby) from a user, communicate that information to a chat engine 135 (directly or through another device, such as an edge device 120), receive a response from the chat engine 135, enhance that response, and / or communicate that response to a customer directly (e.g., via a voice or chat interface) or indirectly (e.g., by providing the response to another device, such as an edge device), which may or may not (further) enhance or augment the response before further transmitting the message toward the customer (and / or directly to the customer, such as through a UI in a CPE 115). As described in further detail below, some embodiments may be implemented, for example, by a user. Figure 1 The described networks, devices and systems are implemented in the networks, devices and systems.

[0049] Figure 2 1 is a logical block diagram illustrating the flow of information between various components of an example system 200 for providing field diagnostics and services according to some embodiments. Example components include a CPE 115 that communicates directly or indirectly with one or more remote devices 201, one of which (e.g., a cloud server 140) ultimately communicates with a chat engine 135. As noted above, the term "remote device" is used broadly herein and may refer to any device that is not a CPE. With respect to remote devices alone, they may include, but are not limited to, one or more edge devices 110, core devices 120, chat engines 135, cloud servers 140, and / or the like. Reference to a "remote" component indicates that such component is part of the remote device and / or is located remotely from the CPE 115.

[0050] The connection between CPE 115 and a particular remote device 201 may be relatively direct (e.g., if remote device 201 is an edge device 110) or relatively indirect (e.g., if remote device 201 is a cloud server 140, where communications between CPE 115 and remote device 201 may be routed through one or more edge devices 110, core devices 120, networks such as provider network 105 and / or external network 130, etc.) - in some cases, there may be multiple remote devices 201 between CPE 115 and chat engine 135 (including, in some embodiments, cloud server 140 on which chat engine 135 resides). Therefore, the examples are provided for exemplary purposes only. Figure 2 , and in other embodiments, the information flow may include additional and / or different components, such as additional edge devices 115, core devices 120, and / or the like in any communication path configuration (e.g., serial, parallel, etc.).

[0051] The CPE 115 includes a local chat prompt and response engineering (CPRE) component 205a (which may include software running on, for example, a processor of the CPE 115), and a local adaptive multi-model ML engine (ML engine 210a) (which may also include firmware or software running on, for example, a processor of the CPE 115). These logical components, while illustrated separately, may also be combined such that the CPRE 205a is implemented as part of one or more ML models operated by the ML engine 210a; similarly, each component may run on the same or different processor(s), which may include, but is not limited to, a central processing unit (CPU), a graphics processing unit (GPU), a neural processing unit (NPU), a digital signal processor (DSP), or any other general or special purpose processor. The local ML engine 210a may employ multiple ML models 220a-n controlled by a multi-model switching controller (MMSC) 215a. As described in further detail below, the MMSC 215a may be hardware, firmware, and / or software that includes logic to control the use of different models and / or switching between different models in an adaptive multi-model switching scheme. The local CPRE 205a may include a prompt and response cache 225. The CPRE 205a may also access (and / or may collect, receive, and / or store) input data 230, which may include, but is not limited to, platform profile and status information 230 of the CPE 115 and / or other local conditions (e.g., local network statistics and information, weather data, etc.), as well as user and / or operator preferences 235.

[0052] The CPE 115 may also include one or more UIs 240, such as the UIs described above, some or all of which may be provided through various user devices 245, which may include but are not limited to landline phones 245a, laptops or other computers 245b, mobile phones 245c, cameras 245d, STBs 245e, etc. The CPE 115 also includes a network interface 250, the nature of which will depend on the type of edge network 105b employed. The network interface may provide communication between the CPE 115 and the remote device 201 using typical facilities of such an edge network.

[0053] The remote device 201 may also include a CPRE 205b and / or an ML engine 210b. In some embodiments, the remote device may also access (and / or may receive, collect and / or store) input data 255 and / or policy information 260. Depending on the nature of the remote device, the data 255 and policy information may vary. For example, if the remote device 201 is an edge device 110 and / or a core device 120, the data 255 may include, but is not limited to, network profile and status information about the provider network 105 (and / or portions thereof, such as the edge network 105b), and related operating policies of the provider 255. If the remote device is another device (e.g., a cloud server 140), the data and / or policy information available to the ML engine 210b and / or CPRE 205b may be different and may include, for example, more general data including, for example, specifications and information about the models of the CPE 115 and / or other remote devices 201, general information about network (e.g., Internet) problems, etc. Each remote device 201 also provides communication (via any suitable communication pathway and / or through any suitable additional remote devices 201) with a cloud server 140 (which in this context may be considered another remote device 201, except that the cloud server may also host a chat engine 135). As described above, the cloud server 140 may be located within the provider network 105 and / or may be accessible through an external network 130 (e.g., the Internet).

[0054] In one aspect, the local ML engine 210a may perform local ML processing on the user input using the local ML models 220a to n, such as KWS, speaker ID, NLP, TTS / STT, emotion detection, gesture detection, movement detection, etc. In another aspect, the local ML engine may perform any necessary pre-processing for the local CPRE function 205a. Similarly, the ML engine 210b in the edge device (if any) may perform any necessary pre-processing for the corresponding CPRE function 205b (if any) to enrich the chat prompt. In some embodiments, the ML engine 210 may support model fine-tuning and dynamic multi-model switching and reconfiguration (e.g., as described in further detail below) to adapt to the user input and any other relevant information or conditions, such as the state 230, 255 of the device and network, user and operator preferences 235 and / or operator policies 260. The dynamic ML model switching is coordinated by the corresponding MMSC 215a, 215b as appropriate. While various embodiments may employ many different ML models 220 in different types of arrangements, typical ML models 220 for the ML engine 210 may include convolutional neural network (CNN) models, transformer models, and / or recurrent neural network (RNN) models. The selection of these models 220 may be determined based on their performance and cost optimization to support local applications and / or with respect to corresponding ML models in the core device 120 and / or cloud server 140 in order to increase training effectiveness and enhance the end-to-end hybrid framework of the application. In some cases, these models may be independent and / or these models may also be created as dedicated multi-heads of a common backbone network architecture, such as described below. The multi-heads may be trained with dedicated and dynamic chat prompts and data sets, while the backbone architecture may be trained with shared and static chat prompts and data sets.

[0055] More specifically, in some embodiments, the local CPRE function 205a may, in some cases, perform local prompt synthesis and enrichment using the ML-processed user prompts based on the data 230 and / or the user and operator preferences 235. The local CPRE function 205a may also perform local response enrichment using responses received from one or more of the remote devices 201 (in some cases, by augmenting the responses based on the data 230 and / or the user and operator preferences 235). Likewise, the CPRE function 205b (if any) of each remote device 201 may further enrich the prompts after processing by the corresponding ML engine 210b (if any), and / or augment the responses, possibly in conjunction with the data 255 and / or the policy 260. In many respects, the ML engine 210b and / or MMSC 205b of the remote device 201 operates very similarly to the ML engine and / or MMSC of the local device 115. Of course, in some cases, the remote device 201 need not perform initial prompt generation based on the user query, as that may typically be handled at the CPE 115. However, with respect to prompt and response enhancements (e.g., enrichment and / or expansion), CPE 115 and remote device 201 may operate similarly (albeit perhaps with access to different data, different computing resources, etc.). More specifically, both CPE 115 and remote device 201 may operate according to the procedures and techniques discussed herein. Furthermore, as further discussed below, in Figure 2 There may be multiple remote devices 201 in an arrangement of , and each of those devices may execute (but need not execute in every case) similar prompting and response enhancement procedures.

[0056] In some cases, such as when the remote device 201 is a cloud server 140, the CPRE 205b may perform cloud prompt synthesis and enrichment, for example, with data 255 and / or policy information 260. It may also perform cloud response enrichment using responses received from the chat engine 135 in conjunction with the same type of data. In some cases, the CPRE 205b of the cloud server 140 may be assisted by an appropriate ML model 210b. The chat engine 135 may perform chat-related cloud ML processing. In some cases, the chat ML model may be retrained and fine-tuned with a domain-specific dataset.

[0057] The operation and information flow of system 200 is determined by Figure 2 The arrows labeled with numbers 1 to 15 are illustrated. In an exemplary embodiment, the operation may be performed according to a process such as the following:

[0058] 1. User input is captured by the UI (e.g., through the user device 245) as input to the local ML engine 210a. The input may be in the form of text, voice, image, and / or video, etc.

[0059] 2. Using the locally available appropriate ML models 220a-n, the local ML engine 210a at the CPE 115 generates inputs for the local CPRE function 205a. For example, the inputs may be in the form of text describing the user prompt and other user attributes, such as emotions, gestures, and movements, etc. In other cases, the inputs may be text converted from speech, text typed by the user, etc. The ML engine may analyze other information, including but not limited to prompt parameters (described below) and / or diagnostics to generate additional inputs. For example, the Fig. 9 and 10 Illustrates how the adaptive multi-model switching technique can generate diagnostic data for a Data Over Cable Service Interface Specification (DOCSIS) network. This input is transmitted to the local CPRE function 205a.

[0060] 3. The local CPRE function 205a generates an enhanced prompt, e.g., by forming the original prompt from the original user query and / or input from the ML engine 210a, and / or enriches the prompt, e.g., by merging prompt parameters (which may include, but are not limited to, user and operator preferences 235 and device platform profile and state 230) with the user query / original prompt to provide an enriched prompt. For example, the Figure 4 Techniques for generating enriched prompts are described. Figure 4 Also described are techniques for generating one or more supplemental prompts, which can be used to trigger one or more supplemental responses as described below. The enhanced prompts can be stored in the local prompt and response cache 225 so that a lookup entry is created when a corresponding response is generated. If a corresponding response is already available in the local prompt and response cache 225 for the user prompt, the cached response can be used directly. Otherwise, the enhanced prompt is sent to the local network interface 250 for transmission to the remote device 201. In some cases, the enhanced prompt may include any supplemental prompts generated by the local CPRE 205a, wherein the transmission of the enhanced prompt may include the supplemental prompts. In other cases, the supplemental prompts (if any) may be transmitted separately. This transmission may be performed by the edge device 110, which is a type of remote device 201 and provides communication between the CPE 215 and other remote devices 201, for example, through the provider network and / or the external network 130, as described above.

[0061] 4. Send the enhanced hints to the remote device 201 over the network interface 250, which in some cases may route the hints to the additional ML engine 210b for further processing. (In other cases, the remote device 201 may simply forward the hints to another device (e.g., another remote device) without any further processing of the hints.

[0062] 5. In some cases, the remote device 201 (which as described may also include the CPRE 205b and / or the ML engine 210b) may further utilize the ML engine 210b to generate additional inputs and provide the inputs to the CPRE 205b. Thus, the CPRE 205b may enhance the (possibly already enhanced) chat prompt (e.g., enrich the chat prompt with additional data, which may include network status and profile information 255 and / or operator policies 260), and / or generate one or more (additional) supplemental prompts. In other cases, a particular remote device 201 may not include these components, and / or they may not be used to enhance the chat prompt in a particular case.

[0063] 6. Transmit the prompt (whether or not further enhanced by the remote device 201) from the remote device 201 to another remote device 201. The above process 5 may be repeated for each additional remote device 201. After a certain number of iterations, the remote device 201 will be the cloud server 140 when the prompt passes through the network(s) (e.g., 105b, 105a, 130, etc.) towards the chat engine 135.

[0064] 7. In some cases, the cloud server 140 as a remote device may include an ML engine 210b and / or CPRE functionality 205b, which may further enhance the chat prompt (process 5 above). This enhanced prompt (at this point, it has been enhanced at the CPE 215 and possibly one or more remote devices 201 (including but not limited to the cloud server 140)) is provided to the chat engine 135 as an input prompt.

[0065] 8. The chat engine 135 generates a response to the input prompt by running an appropriate cloud ML model (e.g., a chat model) on the enhanced prompt. Some of these models can be retrained and fine-tuned using application domain specific data. Likewise, the chat engine can generate supplemental responses to any supplemental prompts included in the enhanced prompt (or submitted separately from the enhanced prompt). The chat engine 135 response(s) are transmitted to the remote device 201.

[0066] 9. The response from the chat engine 135 may be augmented by the CPRE function 205b in each remote device 201 , for example by incorporating additional information, which may include but is not limited to data 255 and / or operational policies 260 . Figure 4 An example of generating a supplemental prompt to trigger a supplemental response is described, which can be used to augment the response. Other embodiments can use other techniques to augment the response, including but not limited to adding proprietary and / or provider-specific information, analysis and / or diagnostic information from the provider's analysis system, etc. to the response from the chat engine.

[0067] 10. The (possibly enhanced and / or augmented) response may then be transmitted to each respective remote device 201. In some cases, the response follows the same (albeit reverse) path through the remote device 201 as the prompt followed to reach the chat engine 135. In other cases, the return path may be different and / or may include more, fewer, and / or different remote devices than the original path.

[0068] 11. After passing through and / or further augmented / augmented by the applicable remote device 201, the response is transmitted to the CPE 115.

[0069] 12. The augmented response received by the CPE network interface 250 is processed by the local ML engine 210a and applied as input to the local CPRE function 205a.

[0070] 13. The local CPRE function 205a generates a final response by incorporating appropriate locally available information for the application, device, user and / or operator (eg, data 230 and / or user and operator preferences 235).

[0071] 14. The expanded response is provided to UI 240, which provides it to the user in an appropriate format (this may be on the same user device (e.g., 245a) and / or a different user device (e.g., 245b-e) that originally transmitted the query).

[0072] Figure 3 300 is a block diagram illustrating a chat prompt and response engineering model 300 according to some embodiments. In some embodiments, this model 300 can be generally applied to many different physical or logical configurations, including but not limited to Figure 1 and 2 In one aspect, the chat prompt and response engineering model may involve some or all of the following functions, which may be implemented locally on a device (e.g., CPE 115, edge device 110, etc.) and / or in the cloud: prompt enrichment function 305, response expansion function 310, and / or adaptation and association layer 315.

[0073] In general terms, prompt enrichment functionality 305 may enrich the original user prompt. In some cases, the enriched prompt may trigger a more relevant and useful chat response from the chat engine 135. Response augmentation functionality 310 may involve augmenting the original chat response from the chat engine 135 with supplemental content triggered by the supplemental prompt consisting of supporting parameters. Adaptation and association layer 315 may adapt the final response by associating the chat history. It may also perform further prompt enrichment and response augmentation if necessary. One feature of many embodiments is that each of these functions may be present in an information flow (e.g., as described above with respect to the chat history) depending on system confirmation, resource availability, the nature of the particular prompt and / or response, etc. Figure 2 The information flow described herein is executed partially or in whole at each stage.

[0074] All three functions 305-315 may also incorporate supplemental information (e.g., prompt parameters 320). Example prompt parameters 320 may include, but are not limited to, some or all of the following: the user prompt itself; analytical insights such as provided by a provider's analytical system and / or ML model backbone; device platform attributes (which may include, but are not limited to, information about the device platform configuration profile and dynamic state of the CPE device 115 and / or local network, user device, etc.); network attributes (which may include, but are not limited to, information about the provider's network configuration profile and dynamic state, other information about general outages or problems on the Internet, etc.); service attributes, which may include, but are not limited to, operator preferences and policies (e.g., QoS or traffic management policies that may affect the perceived network performance at the CPE 115); and / or user attributes, which may include, but are not limited to, user preferences, dynamic emotions, gestures, and movements, etc.

[0075] In one aspect, the model 300 may generate one or more final responses 325 that may be provided to the user via an appropriate UI 240. The final responses 325 may include static information and / or information dynamically generated by the chat engine 135, the response expansion functionality 310, and / or the adaptation and correlation layer 315. By way of example only, the final responses 325 may include diagnostic points related to the original user inquiry, an operator report and / or survey, a self-help guide, promotional materials, and / or the like.

[0076] Figure 4A process 400 for enriching and / or expanding a prompt and / or response is described. As described above, enhancing a prompt or response may include any improvement or modification to a prompt or response, particularly (but not limited to) such improvement or modification for the purpose of ultimately returning more useful, relevant, actionable, and / or understandable information to the user in response to the user's query. Thus, enhancing a prompt may include (but not limited to) enriching a prompt, generating one or more supplemental prompts, enriching and / or expanding a response, etc. In some embodiments, this process (and / or its operations) may be used in the systems and / or methods disclosed herein and / or used to implement Figure 3 The model 300 of FIG. This process 400 can be performed at any level of the hierarchy (e.g., CPE 115, edge device 110, core device 120, cloud server 140, etc.) and / or any combination of those levels, and the process 400 provides a technique for enriching prompts that can be used to generate enriched responses from the chat engine 135. The process 400 also provides an example of a way to generate an augmented response. However, it should be noted that the embodiments are not limited to any of these techniques.

[0077] To generate an enriched response, an enriched prompt synthesis function 405 (which may be a CPRE, such as the CPRE described above) supplies data from one or more prompt parameters (such as the prompt parameters described above, to name a few examples) to a prompt enrichment function 410, which also receives the original prompt (which, as described above, may include a user query after being processed by one or more ML engines). In some embodiments, the synthesis function 405 and the enrichment function 410 may be combined within a single functional component (e.g., PRCE 305). The enriched prompt is fed to the chat engine 135 to trigger the enriched response.

[0078] To trigger the augmented response, the original prompt may be fed into the chat engine 135 to generate the original response. However, the process 400 may also generate the supplemental prompt using a supplemental prompt synthesis function 415, which in some cases may be implemented in the CPRE and / or may employ data from one or more prompt parameters. The supplemental prompt may, but need not necessarily, be generated based on the original response to the original prompt (e.g., as a follow-up "question" to the original prompt). The supplemental prompt may be fed to the chat engine 135, which then generates the supplemental response. The supplemental response and the original response may be integrated (e.g., in the adaptation / correlation layer 240) to generate the augmented response.

[0079] In some cases, these two aspects of the process may be combined in different ways. For example, the original prompt may be used to generate an enriched prompt and a supplemental prompt, as described above. The resulting enriched response and supplemental response may be integrated (e.g., in the adaptation / correlation layer 240) to generate an augmented enriched response. In some cases, the original prompt may also be provided to the chat engine 135, and the original response and supplemental response (possibly, but not necessarily, first integrated to generate an augmented response, such as Figure 4 ) can be integrated with the enriched response to produce an enriched, expanded response.

[0080] This process can be further understood by referring to the example of a user of an STB who has a problem with the attached TV. In this example, the user can provide a simple query that is used to generate the original prompt. For example, the user can provide a simple query, such as "Why doesn't my TV work?" By itself, this query may trigger a generic original response, such as "Without more information, there is no way to answer this question. There may be many reasons why your UV does not work, such as power problems, faulty connections, or internal component problems. It is best to consult a professional technician to diagnose and repair the problem." This is not very helpful.

[0081] On the other hand, if the STB enriches the original prompt with some prompt parameters (name of the provider and / or local environmental conditions), the enriched prompt will generally trigger a more relevant and useful expanded response from the chat engine. For example, if "I have a Comcast set-top box with an HDMI connection to my TV" is added by the STB to enrich the original prompt, the enriched prompt becomes: "I have a Comcast set-top box with an HDMI connection to my TV. Why doesn't my set-top box work?" This will produce a better response, such as the following: "If your TV doesn't work with a Comcast set-top box, it may be due to several different problems. First, make sure the HDMI cable is securely connected to both the set-top box and the TV. If the connection is secure, you should check whether the set-top box is powered on and whether the TV input is set to the correct HDMI source. If the problem persists, you may need to contact Comcast for further assistance." This response can be much more helpful.

[0082] In some embodiments, the chat response expansion may add context-sensitive supplemental responses to the original chat response to produce an expanded response that is more specific to and relevant to the user's situation. In some cases, supplemental prompts from CPE or core devices may be used to trigger supplemental responses from the chat engine. On the one hand, supplemental prompts may be dynamically generated or statically provided based on operating conditions. On the other hand, supplemental prompts may be composed of contextual information from sources such as device platforms, networks, system configurations, and / or service profiles. Synthesis may follow predefined or dynamic grammars.

[0083] A simple example might be to provide a supplemental prompt, “If this doesn't work, how can I contact my provider?” This supplemental prompt might trigger a response of something like “If you can't resolve the issue yourself, you can contact Comcast Xfinity Customer Service by calling 1-800-Xfinity (1-800-934-6489) or by visiting their website at www.xfinity.com / support. You can also use the live chat feature on their website or send them a message on Twitter @ComcastCares.” That supplemental response might be used to augment the original response or more helpfully augment the enriched response, which would produce an augmented response such as, “If your TV isn't working with your Comcast set-top box, it could be due to several different issues. First, make sure the HDMI cable is securely connected to both the set-top box and the TV. If the connection is secure, you should check that the set-top box is powered on and that the TV input is set to the correct HDMI source. If the problem persists, you may want to contact Comcast for further assistance.”

[0084] The enriched and / or expanded response may also include insight enhancement through the use of supplemental prompts. An example may be a CPE identifying its device platform with a supplemental prompt "My set-top box is a XiOne model." This supplemental prompt will generate a supplemental response that is integrated with the enriched and / or expanded response to generate the following expanded response: "If your TV is not working with the XiOne set-top box, it may be due to several different issues. First, make sure the HDMI cable is securely connected to both the XiOne and the TV. If the connection is secure, then you should check that the set-top box is powered on and that the TV input is set to the correct HDMI source. If this does not work, then you can try resetting your XiOne using these steps. 1. While the device is powered on, press and hold the WPS button on the XiOne box for 10 to 15 seconds. 2. The color of the LED will change to amber. 3. The Disaster Recovery image will be displayed on your TV screen. 4. The box will now update the firmware and restart. If this does not resolve the issue, then you can contact Comcast by calling 1-800-Xfinity (1-800-934-6489) or by visiting their website at www.xfinity.com / support Xfinity Customer Service. You can also use the live chat feature on their website or send them a message on Twitter @ComcastCares. " As described above, the adaptation and association layer can be designed to group and associate low-level insight outputs to produce high-level insights via the chat engine 135 or a dedicated ML model (e.g., clustering). It should be apparent from this example that the original prompt can be enriched and / or augmented one or more times to produce a much more relevant and actionable response from the chat engine 135. In addition, it should be noted that this response can be further enhanced, augmented and / or enriched (e.g., by the CPE 115 and / or one or more remote devices 201) before being delivered to the user via the UI, such as by adding further information such as some of the data described above (e.g., edge network conditions, operator policies, etc.).

[0085] As described, some embodiments provide methods, including but not limited to methods that may be implemented by a device or system, such as those described above. Figure 5A and 5BAn exemplary method 500 and procedure 555 for enhancing a chat prompt and / or augmenting a response to the prompt based on a user query is described. The method 500 may include receiving a user query related to a network service (block 505). In one aspect, the query is received from a user via a UI (including but not limited to the UI described above). The various embodiments are not limited to any particular UI, and many embodiments may employ several different UIs; the selection of a particular implementation of the method 500 or similar methods may depend on, for example, the preferences of the user (e.g., a customer) and / or the circumstances in which the query arises. In some embodiments, the query (now perhaps in the form of an enhanced chat prompt) may be received from a CPE or another device; for example, the CPE may receive the user query and generate an enhanced chat prompt, which may be received by a remote device 201 (e.g., an edge device 110) that may also execute the method 500.

[0086] In some embodiments, the method 500 includes receiving and / or collecting operational information (block 510). In some aspects, the operational information may include any relevant information about local network services and / or other prompting parameters, including but not limited to information about the operation of the CPE or devices attached thereto, local conditions, and the like. This information may include diagnostic information, which may include any information that may be relevant to or helpful in diagnosing one or more specific conditions of the provider's services and / or the customer's use of the provider's services, including but not limited to information about any conditions that prompted the user to transmit a query. In certain aspects, when the operational information is received by the CPE, the operational information may include information local to the CPE's environment, as the CPE may not have specific information about the operation of a larger edge network or other centralized components of the provider's system. For example, the method 500 may include receiving diagnostic information (e.g., at the CPE device 115, the remote device 201, etc.), such as from other connected devices. In some cases, the method 500 may include collecting diagnostic information, such as from a user (e.g., using a local response question), from a sensor, and the like.

[0087] In some embodiments, the method may include, for example, enhancing a chat prompt based at least in part on the operational information (block 515). Enhancing the chat prompt may include one or more operations, some or all of which may be performed by the ML engine. In some cases, enhancing the prompt may include processing the user query using a machine learning model to generate an actionable prompt (block 520). This prompt may then be enriched and / or expanded (e.g., by generating a supplemental prompt), as described in detail above (block 525). In certain aspects, the prompt may be enhanced using a variety of different neural engines and / or model aggregation strategies, e.g., as described in further detail below.

[0088] The method may include transmitting an enriched chat prompt for processing by a chat engine (e.g., 135) (block 530). As described above, this does not require transmitting the prompt directly to the chat engine. Instead, the enriched prompt may be delivered to a remote device (e.g., a remote device 201 in an edge network 105b or a provider's core network 105a that is further away from the user, such as an edge device 110, a core device 120, a cloud server 140, etc.). Such devices may further enhance the prompt using operational information available to those devices (e.g., as described in the above system). This information may include, but is not limited to, information about the performance and / or problems of the network (which may not be visible to devices closer to the user), provider policies that may affect the user (e.g., bandwidth limitations), and / or the like. Thus, method 500 may be repeated one or more times, for example, starting from block 505 at a remote device (in which case this would include receiving an enhanced prompt based on the original user query, rather than receiving the original user query itself). In other cases, the process may be repeated by the same device starting from block 510.

[0089] After repeating these operations (which are optional in many embodiments) any number of times on (several) appropriate devices, the enhanced prompt is transmitted (block 530) to the chat engine for a response. If the enhancement of the prompt includes generating any supplemental prompts, those supplemental prompts may also be transmitted.

[0090] Next, at block 535, method 500 may include receiving a response generated by the chat engine, and at block 540, method 500 may include enhancing the response using a second machine learning engine. In some cases, the response may be enhanced using dedicated information, which may include, among other things, some or all of the prompt parameters described above and / or other relevant information. In some cases, as described above, enhancing the response may include, for example, augmenting the response with one or more supplemental responses received from the chat engine (block 545); as described, the supplemental response(s) may be triggered by the supplemental prompt transmitted in block 530. Method 500 may be repeated one or more times starting from block 535 to further enhance the response.

[0091] Then, an enhanced and / or expanded response may be provided for presentation to the user (block 550). In some cases, providing the response may include providing the response directly to the user, for example, through a user interface of the CPE. In other cases, providing the response may include providing a prompt to another device in the network that is closer to the user, such as a remote device 201 (e.g., edge device 110) and / or ultimately to CPE 115, which may then present the response to the user, for example, through an appropriate UI. In some cases, the same UI (e.g., a voice response unit, a chat session, etc.) that received the original query is used to provide the response. In other cases, a different UI (e.g., instructions and / or explanations) is provided on a display or television attached to the CPE. As described above, these are merely examples, and different embodiments are not limited to any particular UI. Providing the response to the user may include providing information to the user that can be used to improve the performance of the service provided to the user. In some aspects, method 500 may also perform automated steps that can improve the performance of the service. Merely by way of example, in some cases, if a user's Internet service is poor, the system may change the configuration in the user's CPE (e.g., the wireless channel used to carry the WiFi signal) and / or instruct the user to change settings in the user's device. In other cases, as described herein, the system may be able to resolve incorrect configurations elsewhere in the network, e.g., changing parameters in a router's software defined network (SDN) control plane, etc., to better manage traffic and provide better network performance.

[0092] Utilizing an ML engine to enhance a prompt (block 515) or response (block 540) may employ a variety of different options, including, but not limited to, a different ML engine, a different ML model, and / or a different multi-model switching strategy. Examples of some different options are illustrated by blocks 560 through 595, which are discussed below. Any of such options, which may include a different ML engine and / or a different multi-model switching strategy, may be used in the various devices, methods, and / or operations described above.

[0093] For example, in some embodiments, at least one of the ML engines may include a multi-headed ML model, an instance of which is composed of Figure 6 and 7Description. As used herein, the term "multi-head machine learning model" refers to any ML model that includes two or more ML models as "heads" (or sub-models), each of which may perform some or all of the processing for a specific task. For example, local models deployed at each level of the operator network hierarchy (e.g., CPE 115, edge device 110, core device 120, cloud server 140, etc.) may be created as multiple heads sharing a common backbone. In other embodiments, a single ML engine 210 may include multiple heads and / or run multiple heads alone (and / or in conjunction with one or more heads running on another device). In the present disclosure, in the context of multi-head models, the terms "model" and "head" may be used interchangeably unless the context indicates that the term "model" is used to refer specifically to the multi-head model itself. Figure 6 One such arrangement 600 is illustrated, in which a ML multi-headed ML model 605 includes an ML backbone architecture 610. In some embodiments, the backbone 610 may be trained with common and / or pre-generated hints and data sets that may represent baseline or "normal" conditions for devices and networks. On the other hand, in some embodiments, different ML models (e.g., 605) may be trained with dedicated and dynamic hints and data sets that represent special or "abnormal" conditions for devices and networks (e.g., channel anomalies and various types of channel impairments). For model input and output, the multi-headed model may exchange information with an external I / O interface 620 (e.g., via internal memory 625) and / or with local functional elements / data 630 (e.g., via host processor 635). In particular, local device attributes, profiles, and states may be provided to the multi-headed model 605 by the host processor 635.

[0094] In one aspect, a mixture of cues and datasets from multiple disciplines can be used to train the model 605 and / or head 615 on tasks and applications. Outputs from the model 605 and / or head 615 can include at least the following types:

[0095] a. Binary (true / false) or discrete (e.g., integer) values. For example, such outputs may be sent to a higher functional layer (e.g., locally, in another device, and / or in the cloud) to signal that further ML processing is required. For example, the need for further processing by a higher level may be represented as a binary value. If further processing is required, then based on the dynamic condition of the device and the actions taken (e.g., diagnostic and / or remedial steps performed), the level of further processing required may be represented as an integer.

[0096] b. Sent to a higher functional layer for further ML processing (which may include, for example, one or more remote devices 201

[0097] The input of the processing (e.g., edge device 110, core device 120 and / or cloud server 140) is filtered or pre-processed values ​​to correlate inputs from multiple devices to locate network problems.

[0098] Different models 605 and / or heads 615 may be arranged to run sequentially and / or in parallel to support adaptive multi-model switching, e.g., as described in detail below. As used herein, "adaptive multi-model switching" means any technique or implementation in which multiple models are available to an ML engine or environment and in which the selection of one or more models to be used rather than other available models is based on the specific processing task at hand. As used herein, the term "processing task" means any query, prompt, assignment, job, or task provided to an ML engine in order to answer, enhance, enrich, supplement, augment, respond to, solve, reason about, complete, or otherwise perform. Embodiment specific instances of processing tasks may include, but are not limited to, all of the prompt and response enhancement techniques (or portions thereof) described herein, generation of chat prompts and responses, and the like.

[0099] In a particular embodiment, the model 605 and / or the head 615 may be arranged to implement a hierarchical ML process, examples of which may be found in Figure 7 middle. Figure 7 1 illustrates hierarchical processing by multiple ML models (or heads) 705. As an example, for hierarchical ML processing and fault diagnosis, one of the multiple head models (e.g., 705a, in FIG. 1 ) may be trained, for example, using a quadrature amplitude modulation (QAM) and / or modulation error ratio (MER) data set (depending on the channel type). Figure 8B , 9 , and 10) to detect high-level and general channel anomalies, while another such model (e.g., 705b) can be trained using a wide range of data sets of the PHY, MAC, MAC, TCP / IP, and application layers of the OSI data model to classify specific and detailed channel impairments that trigger anomaly conditions.

[0100] The multi-headed model 705 may be trained / retrained using feedback represented by a dedicated reward model, for example, using reinforcement learning. For example, the multi-headed model 705 may be viewed as policies for various diagnostic tasks and services. The inputs to these policies may include various state information of the device / network environment; the outputs from these policies represent the desired state of the environment; and the mapping from input to output represents the actions taken in accordance with the policy. Within this conceptual framework, the reward model may be trained with data sets and preference scores that may be generated by technical experts in relevant disciplines, operator technicians, and device local capabilities, states, and configurations.

[0101] In many embodiments, multiple ML models are stored and made available to ML engines on both local devices (e.g., CPE 115, edge devices, etc., depending on the context) and any appropriate remote devices 201 (e.g., edge devices 110, core devices 120, cloud servers 140, etc.). In one aspect, some or all of the ML engines may be configured to employ adaptive multi-model switching, e.g., by switching among and running different models, adapting to user input and the state and configuration of the device and network. One example of such switching is mode hopping between multiple models.

[0102] Fig. 8A An example of an ML engine 800 configured to operate in a model hopping mode is illustrated. As used herein, the term "hopping" refers to a technique of switching between two or more different ML models during the course of a processing task. The hopping may be controlled by a prearranged policy, and / or it may depend on circumstances encountered during the processing of the processing task. As described above, the MMSC 215 typically controls the operation of the ML engine 800. In this case, the MMSC 215 controls the model hopping behavior of the engine 800. The hopping decision among different models 805 made by the MMSC 215 may be determined by factors that may include, among other things, device and network configuration and state 815, user input attributes 820, and / or model attributes 825. The network configuration and state may include information about the application, the user's local network, the CPE 115, the user device 145, the provider network 105, the operator policy, and / or the like. This information may include identification and / or descriptive information (e.g., the type of user network, identification or description of other devices on the user LAN, WiFi channels used and / or SNRs of such channels (if the user LAN includes a wireless LAN), identification of any provider devices and / or transmission lines involved in delivering services to the user, etc.) and / or status information (e.g., any status codes (normal or abnormal) generated by any of the devices on the user LAN and / or the provider's network 105, unavailability and / or degraded performance of any such devices, any known outages of the provider's network, etc.). User input attributes may include any information about the user (e.g., identity, subscription status, userid, etc.) and / or the user input itself (e.g., a query), including but not limited to expressions of the input (e.g., typed text, spoken text, video, image, etc.), indicators of user emotion (gestures, facial expressions, etc.), and / or the like. Model attributes may include any information about models selected for use in the ML engine (and / or models that were not selected), such as known strengths and weaknesses of such models for different applications, resource requirements, and / or absolute or relative execution times of such models, etc.

[0103] In some embodiments, multiple ML models (e.g., Model 1 (805a)) to Model n (805n) may be used for different application tasks (e.g., detection and classification of events, anomalies, conditions, etc.). Figure 8B As illustrated in the configuration 830 of , multiple models (or heads in this case) 805 can share the same backbone structure 835 (possibly with different parameters). Figure 8C As illustrated in , the backbone structure 835 may include a CNN (e.g., a residual network (ResNet) model) that may derive multiple auxiliary models for both detection and classification tasks. Fig.8D As illustrated, the backbone structure may use a single transformer model (e.g., transformer encoder) as the backbone to derive multiple auxiliary models for such tasks. In these cases, the MMSC 215 may configure the engine 800 for model hopping among auxiliary models that share the same backbone (e.g., CNN or transformer). These auxiliary models may be represented by different "heads" 805 (e.g., detection head 805a and classification head 805b), such as Figure 8B As described in .

[0104] As described above, in some embodiments, the MMSC 215 makes model hopping decisions based on factors that may include, among other things, application-specific characteristics, device and network configuration and status, user input attributes, model attributes, and the like. Fig. 9 and 10 An example illustrating a situation where model hopping may be useful. A DOCSIS cable broadband edge network has a combination of single-carrier quadrature amplitude modulation (QAM) channels and orthogonal frequency division multiplexing (OFDM) downstream channels. In this case, two separate ML models can be trained for these two types of channels, respectively, in order to detect and classify abnormal conditions of these channels for network diagnostic purposes.

[0105] The two ML models corresponding to the two channel types (QAM and OFDM) may have different model properties. For example, in an OFDM channel, an anomaly may appear as a receive MER (RxMER), which is the ratio of the average symbol power to the average error power, which is a scalar value. For this type of anomaly, the MMSC 215 may select, for example Fig. 9 The model of the exemplary model 900 of FIG. 215 may be an anomaly detector having an autoencoder architecture based on a convolutional neural network CNN 905 and a transposed CNN 910, which can detect anomalies by quantization. On the other hand, in a QAM channel, which anomalies appear as inaccurate constellation points in the constellation diagram, and the anomalies can be classified into different qualitative properties. In this case, the MMSC 215 may select, for example, Fig.10A model of an exemplary model 1000 is an anomaly classifier having an architecture based on a fully connected (FC) neural network 1005 (as illustrated) and capable of classifying detected anomalies into several general categories 1015 with different qualitative properties based on an input pattern 1010, such as “signal with high / low attenuation” (1015a), “signal with high / low interference” (1015b), “signal with high / low attenuation in addition to high / low interference” (1015c), etc.

[0106] During runtime of the cable modem CPE, these two models are made locally stored and / or available to the local ML engine on the CPE. The MMSC 215 can implement a channel scan schedule to scan all downstream channels (single carrier QAM and OFDM channels) for anomalies, jump to and execute the ML model (in the ML engine) corresponding to the scanned channel type. The ML anomaly detection / classification results across all channels can then be analyzed to provide diagnostic input (e.g., for the local CPRE).

[0107] In some cases, the multi-model switching performed by various embodiments includes running multiple models in parallel (block 570). Unless the context dictates otherwise, the term "parallel" is used broadly herein to refer to the operation of multiple processes or events that are not strictly performed in serial fashion. Fig.11 An example parallel multi-model switching technique 1100 is illustrated in which the MMSC 215 schedules multiple related ML models 1105 to be run in parallel by the ML engine. In various embodiments, parallel execution may be achieved through a multitasking scheme, such as multitasking at the model layer level or multitasking at the model level. A processed output block 1110 may process the output of each of the models using various strategies 1115 (which may depend on implementation-specific characteristics) to produce a collective output from the parallel models 1105. Examples of such strategies may include, but are not limited to, optimal output selection 1110a, output majority voting 1110b, output aggregation 1110c, and / or model delegation 1110d.

[0108] Thus, in some embodiments, running multiple models in parallel includes adopting an optimal output selection strategy (block 575). For example, for each input data, all parallel models may be executed until completion. When the optimal output selection strategy is adopted, the output selected as the collective output from the multi-model switching technique is the optimal output among all outputs of these models using appropriate optimization criteria based on the properties of the relevant application, input data, etc. In some embodiments, running multiple models in parallel includes adopting an output aggregation strategy (block 580). When using such a strategy, for each input data, all parallel models may be executed until completion. The collective output is aggregated by all outputs of these models. In some cases, the aggregation of different outputs may be weighted according to dedicated factors and / or input data.

[0109] In some embodiments, running multiple models in parallel may include employing a model delegation strategy (box 585) in which responsibility for producing the collective output of a set of models is delegated to one or more specific models in the set; such delegation may be relatively temporary or relatively permanent, and it may typically be based on an assessment of which model exhibits the best performance (e.g., on a sample or subset of the processing task at hand). Fig.12 A timeline 1200 is provided of an example of using this strategy. In this example, at time t0, MMSC 215 ( Fig.12 120, and the MMSC 215 executes the parallel models 1205 against one or more sets of initial input data (not shown). In various aspects, the MMSC 215 may execute one model at a time until a determination is made and / or execute all models to completion before designating a delegated model. In either case, based on an analysis of the corresponding outputs of these models, the MMSC 215 delegates one of the parallel models at time t1 to provide the collective output for the ML engine. Once the determination of the delegated model has been completed, the rest of the models (except the designated model) may be deactivated until the MMSC 215 (e.g., at time t2) determines that it should designate a different delegated model (if necessary) and executes the models 120 in parallel again, repeating the process.

[0110] In some embodiments, running multiple models in parallel includes employing an output majority voting strategy (block 590 ) in which the outputs of multiple models or heads are compared to determine a collective output of the models. Fig.13An example 1300 of output selection using a majority voting strategy to determine a collective output 1305 is illustrated. In this example, three well-known image classification models (Residual Network (ResNet) model 1310a, Beginning model 1310b, and Transformer model 1310c) are employed to analyze an image of a person (who may be, for example, a user submitting a query via video). ResNet model 1310a determines that the person is an adult and provides that output 1315a. On the other hand, Beginning model 1310b determines that the person is a child and provides that output 1315b, while Transformer model 1310c determines that the person is an adult and provides that output 1315c. These outputs 1315 are provided to majority voting logic 1320. Based on the fact that "Adult" received two votes (i.e., outputs 1315a and 1315c) and "Child" received only one vote (output 1315b), the majority voting logic selects "Adult" as the collective output of parallel models 1305. (It should be noted that while this example 1300 includes only three voting models, other embodiments may include more or fewer models. More generally, according to various embodiments, any of the strategies described herein may employ any number of models of any appropriate type (which, as described, may depend on the nature of the application, local conditions, etc.)).

[0111] In addition to (or instead of) running the models in parallel, multi-model switching may include running the multiple models serially (block 595 ). Fig.14 An example of an ML engine 1400 running multiple models in series is illustrated. In this mode, the MMSC 215 selects and schedules multiple related ML models 1405 to be executed by the ML engine in series, where the output of the previous model is used as the input of the model's successor model in the series along with any other necessary information 1410, as illustrated. For the case where the models are distributed between a local device (e.g., CPE 135) and one or more remote devices (e.g., remote devices 201, including, for example, edge devices 110, core devices 120, and / or cloud servers 140), the MMSC 215 is also responsible for coordinating the local and remote ML engines. In some cases, the selection and / or ordering of the heads and / or models 1405 by the MMSC 215 may be determined by factors such as device and network configuration and state 815, user input attributes 820, and / or model attributes 825.

[0112] In some embodiments, the serial mode can be used in conjunction with other modes (e.g., the various parallel execution modes and strategies described above). For example, the model output in the serial mode can be generated from the skip mode or the parallel mode. Returning again to the example of the DOCSIS cable broadband edge network, Fig.15An example SoC device 1500 is illustrated in which an anomaly detection / classification ML engine 1505 executes ML models 1510a, 1510b for QAM and OFDM channel anomaly detection / classification, respectively, locally on the SoC device 1500 using a model hopping mode (e.g., as described above). Fig.15 ), the anomaly detection / classification results are sent as input to another on-chip ML engine 1520 along with the channel spectrum data for impairment classification, in coordination with the on-chip ML engine 1520 (not shown). After the input has been processed using the preprocessor 1525, the ML engine 1520 runs the impairment classification ML model 1510c, which uses spectrum analysis to further determine the type and cause of the channel anomaly. Therefore, both models 1510a, 1510b are executed in parallel, while the third model 1510c is executed serially after the first two models 1510a, 1510b are executed. The output from the impairment classification model 1510c can be used, for example, as described above, for example, with respect to Figures 2 to 4 The described CPRE functions as input to produce enhanced prompts and / or responses.

[0113] Fig.16 An alternative configuration 1600 of this same arrangement is illustrated, in which the first two models 1510a, 1510b are executed in parallel on the SoC 1500, while the impairment classification model 1605 is executed on the cloud system. In some cases, the output of the cloud-based model 1605 may be transmitted back to the SOC for further use (e.g., as input to a CPRE for prompt / response enhancement). Fig.16 The impairment classification model 1605 is illustrated as running on a cloud-based model (e.g., executing on cloud server 140), but the same principles can be applied to running different models serially (or even in parallel) on a local device (e.g., CPE 115 or a SoC therein) and one or more remote devices (e.g., remote device 201).

[0114] Example Embodiments

[0115] Certain exemplary embodiments are described below. Each of the described embodiments may be implemented alone or in any combination, as will be apparent to those skilled in the art. Therefore, no single embodiment or combination of embodiments should be considered limiting.

[0116] Fig.17is a block diagram illustrating an example of a device 1700 that may operate as described herein, including but not limited to acting as a user device 245, CPE 115, edge device 110, core device 120, cloud server 140 and / or any other computer system (or component of any of these) in accordance with various embodiments, and / or performing some or all of the operations of the methods and procedures described herein. Fig.17 The components shown in the should not be considered necessary or required for every embodiment. For example, many embodiments may not include a processor and / or may be implemented entirely in hardware or firmware circuitry. Similarly, many embodiments may not include an input device, an output device, or a network interface.

[0117] Under this premise, if Fig.17 1700, device 1700 may include a bus 1705. Bus 1705 includes one or more components that enable wired and / or wireless communications among the components of device 1700. Bus 1705 may, for example, connect the components of device 1700 via operational coupling, communicative coupling, electronic coupling, and / or electrical coupling. Fig.17 Such components may include a processor 1710, a non-volatile storage device 1715, a working memory (e.g., system dynamic random access memory (DRAM)) 1720, and / or a circuit system 1725. In some cases, the system 1700 may include a human-machine interface component 1730 and / or a communication interface 1735.

[0118] Although these components are shown as being integrated within device 1700, some components may be located external to device 1700. Thus, device 1700 may also include facilities for communicating with such external devices instead of or in addition to the components themselves, which facilities may therefore be considered part of device 1700 in some embodiments.

[0119] By way of example only, non-volatile storage 1715 may include a hard disk drive (HDD), a solid state drive (SSD), and / or any other form of permanent storage (i.e., a storage device that does not require power to maintain the state of stored data). While such storage is typically incorporated into device 1700 itself, such storage may be external to device 1700 and may include an external HDD, SSD, flash drive, or the like, as well as networked storage (e.g., shared storage on a file server, etc.), storage on a storage area network (SAN), cloud-based storage, and / or the like. Unless the context dictates otherwise, any such storage may be considered part of device 1700 in accordance with various embodiments.

[0120] Similarly, human-machine interface 1730 may include input components 1740 and / or output components 1745, which may be disposed within device 1700, external to device 1700, and / or a combination thereof. Input components 1740 may enable device 1700 to receive input, such as user input and / or sensed input. For example, input components 1740 may include a touch screen, a keyboard, a keypad, a mouse, a button, a microphone, a switch, a sensor, a global positioning system sensor, an accelerometer, a gyroscope, and / or an actuator. In some cases, such components may be external to device 1700 and / or may communicate with components internal to device 1700, such as an input jack, a USB port, a Bluetooth radio, and / or the like. Similarly, output component 1745 can enable device 1700 to provide output, for example, via a display, printer, speaker, and / or the like (any of which may be internal to device 1700 and / or external to the device but in communication with internal components such as a USB port, Bluetooth radio, video port, and / or the like). Again, unless the context dictates otherwise, any such component may be considered part of device 1700 in accordance with various embodiments.

[0121] It should be apparent from these examples that various embodiments may support a variety of arrangements of external and / or internal components, all of which may be considered part of device 1700. In certain embodiments, some or all of these components may be virtualized; examples may include virtual machines, containers (e.g., Docker containers, etc.), cloud computing environments, platform as a service (PAAS) environments, and / or the like.

[0122] In one aspect, non-volatile storage 1715 may be considered as a non-transitory computer-readable medium. In some embodiments, non-volatile storage 1715 may be used to store software and / or data for use by device 1700. This software / data may include an operating system 1750, data 1755, and / or instructions 1760. Depending on the nature of device 1700, the operating system may include instructions for managing the basic operations of device 1700, and may include a variety of personal computer or server operating systems, embedded operating systems, and / or the like. Data 1755 may include any of a variety of data used or generated by device 1700 (and / or its operations), such as media content, databases, documents, and / or the like. Instructions 1760 may include software code, such as application programs, object code, assembly, binary, etc., used to program processor 1710 to perform operations according to various embodiments. In one aspect, in some embodiments, operating system 1750 may be considered as part of instructions 1760.

[0123] The processor 1710 may include one or more of a central processing unit, a graphics processing unit, a microprocessor, a controller, a microcontroller, a digital signal processor (DSP), programmable logic (e.g., a field programmable gate array (FPGA), an erasable programmable logic device (EPLD) or the like), an application specific integrated circuit (ASIC), a system on a chip (SoC), and / or another type of processing component. The processor 1710 may be implemented in hardware, firmware, or a combination of hardware, firmware, and / or software. In some implementations, the processor 1710 includes one or more processors capable of being programmed to perform one or more operations or processes described elsewhere herein.

[0124] For example, in some embodiments, the device 1700 may include logic 1765. This logic may be any kind of code, instructions, circuitry, or the like that may cause the device 1700 to operate in accordance with the embodiments herein (e.g., to perform some or all of the processes and / or operations described herein). By way of example only, the logic 1765 may include instructions 1760, which may be stored on a non-volatile storage device 1715 as described above, loaded into a working memory 1720, and / or executed by the processor 1710 to perform operations and methods in accordance with various embodiments. In one aspect, these instructions 1760 may be viewed as programming the processor 1710 to operate in accordance with such embodiments. Similarly, the operating system 1750 (to the extent that it is discrete from the instructions 1760) may be stored on a non-volatile storage device 1715, loaded into a working memory 1720, and / or executed by the processor 1710.

[0125] Alternatively and / or in addition, logic may include circuitry 1725 (e.g., hardware or firmware), which may operate independently of, or in cooperation with, any processor 1710 that device 1700 may or may not have. (As described above, in some cases, circuitry 1725 itself may be considered a processor 1710.) Circuitry 1725 may be embodied by a chip, SoC, ASIC, programmable logic device (FPGA, EPLD, etc.), and / or the like. Thus, some or all of the logic that implements or causes the execution of some or all of the operations described herein may be encoded in hardware or firmware circuitry (e.g., circuitry 1725) and executed directly by such circuitry, rather than software instructions 1760 loaded into working memory 1720. (In some cases, this functionality may be embodied by hardware instructions). Thus, unless the context dictates otherwise, the embodiments described herein are not limited to any specific combination of hardware, firmware, and / or software.

[0126] The device 1700 may also include a communication interface 1735, which may enable the device 1700 to communicate with other devices via a wired (electrical and / or optical) connection and / or a wireless (RF) connection. For example, the communication interface 1735 may include one or more RF subsystems (e.g., a Bluetooth subsystem, such as the subsystems described above, such as a Wi-Fi subsystem, a 5G or cellular subsystem, etc.). In addition or alternatively, some such systems may be implemented in combination as discrete chips, SoCs, and / or the like. The communication interface 1735 may further include a modem, a network interface card, and / or an antenna. In some cases, the communication interface 1735 may include a plurality of I / O ports, each of which may be any facility that provides communication between the device 1700 and other devices; in a particular embodiment, such a port may be a network port, such as an Ethernet port, a fiber optic port, etc. Other embodiments may include different types of I / O ports, such as serial ports, pinouts, and / or the like. Depending on the nature of device 1700 , communications interface 1735 may include any standard or proprietary components to enable communications as described in accordance with various embodiments.

[0127] in conclusion

[0128] Although the foregoing description employs examples related to the provision of services, and in particular broadband services, the embodiments are not limited to these examples. In different embodiments of the present invention, the principles and functions disclosed herein may be applied across many fields. By way of example only, embodiments may be used to provide organizations with internally focused (e.g., directed to support personnel) and / or externally focused (e.g., directed to customers, third parties, etc.) diagnosis and / or repair of any type of network or computer system (including, for example, large LANs, enterprise networks). In addition, various embodiments may be deployed in any situation where enhanced communication between a first party (e.g., a customer, internal support personnel, etc.) and a second party (especially when that second party is an automated service, a chat engine, etc.) may benefit. Therefore, unless the claims herein are specifically limited to a particular field of use (e.g., a broadband network), the claims should not be interpreted as being limited to that field.

[0129] In the foregoing description, for the purpose of explanation, numerous details are set forth to provide a thorough understanding of the described embodiments. However, it will be apparent to those skilled in the art that other embodiments may be practiced without some of these details. In other examples, for clarity, structures and devices are shown in block diagram form without showing all the details. Several embodiments are described herein, and although various features are attributed to different embodiments, it should be understood that the features described with respect to one embodiment may also be combined with other embodiments. However, for the same reason, a single feature or several features of any described embodiment should not be considered essential to each embodiment of the present invention, because other embodiments of the present invention may omit such features.

[0130] Thus, the foregoing description provides an illustration and description of some features and aspects of various embodiments, but it is not intended to be exhaustive or to limit the implementation to the precise form disclosed. Those skilled in the art will recognize that modifications may be made in light of the above disclosure or may be acquired from the practice of the implementation, all of which may fall within the scope of the various embodiments. For example, as described above, the methods and processes described herein may be implemented using software components, firmware and / or hardware components (including but not limited to processors, other hardware circuit systems, custom integrated circuits (ICs), programmable logic, etc.) and / or any combination thereof.

[0131] In addition, although the various methods and processes described herein may be described with respect to specific structural and / or functional components for ease of description, the methods provided by the various embodiments are not limited to any specific structural and / or functional architecture, but may be implemented in any suitable hardware configuration. Similarly, although some functionality is attributed to one or more system components, unless the context dictates otherwise, this functionality may be distributed among various other system components according to several embodiments.

[0132] Likewise, while the procedures of the methods and processes described herein are described in a particular order for ease of description, various procedures may be reordered, added, and / or omitted according to various embodiments unless the context dictates otherwise. Furthermore, procedures described with respect to one method or process may be incorporated into other described methods or processes; likewise, system components described with respect to a particular structural architecture and / or with respect to one system may be organized in alternative structural architectures and / or incorporated into other described systems. Thus, while various embodiments are described with or without certain features for ease of description and illustration of aspects of those embodiments, various components and / or features described herein with respect to particular embodiments may be replaced, added, and / or subtracted from other described embodiments.

[0133] As used herein, the term "component" is intended to be broadly interpreted as hardware, firmware, or a combination of hardware and software. It will be apparent that the systems and / or methods described herein may be implemented in different forms of hardware, firmware, and / or a combination of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods does not limit the implementation scheme unless specifically described in the following claims. Therefore, when the operation and behavior of the systems and / or methods are described herein without reference to specific software code, those skilled in the art will understand that software and hardware may be used to implement the systems and / or methods based on the description herein.

[0134] In the present disclosure, when an element is referred to herein as being "connected" or "coupled" to another element, it is understood that an element may be directly connected to another element or that there may be an intermediary element between the elements. Conversely, when an element is referred to as being "directly connected" or "directly coupled" to another element, it is understood that there are no intermediary elements in the "direct" connection between the elements. However, the presence of a direct connection does not exclude other connections in which there may be intermediary elements. Similarly, although the methods and processes described herein may be described in a particular order for ease of description, it is understood that unless the context dictates otherwise, the intermediary process may occur before and / or after any portion of the described process, and as described above, the described procedures may be reordered, added, and / or omitted according to various embodiments.

[0135] In this application, the use of the singular includes the plural, unless specifically stated otherwise, and the use of the term "and" means "and / or", unless otherwise indicated. Moreover, as used herein, the term "or" is intended to be inclusive when used in a series of items, and may also be used interchangeably with "and / or", unless otherwise explicitly stated (for example, if the combination "any" or "only one of..." is used). In addition, the use of the term "including" as well as other forms (such as "includes" and "included") should be considered non-exclusive. Moreover, terms such as "element" or "component" cover both elements and components that constitute one unit and elements and components that constitute more than one unit, unless specifically stated otherwise. As used herein, the phrase "at least one of..." preceding a series of items (where the term "and" or "or" is used to separate any of the items) modifies the entire list, rather than each member of the list (i.e., each item). The phrase "at least one of" does not require selection of at least one of each listed item; rather, the phrase allows for a meaning that includes at least one of any of the items and / or at least one of any combination of the items. For example, the phrase "at least one of A, B, and C" or "at least one of A, B, or C" each refers to only A, only B, or only C; and / or any combination of A, B, and C. In instances where selection of "at least one of each of A, B, and C" or, alternatively, "at least one of A, at least one of B, and at least one of C" is intended, it is explicitly described as such.

[0136] Unless otherwise indicated, all numbers used herein to represent quantity, size, etc. should be understood to be modified by the term "about" in all examples. As used herein, the articles "a" and "an" are intended to include one or more items and can be used interchangeably with "one or more". Similarly, as used herein, the article "said" is intended to include one or more items quoted in conjunction with the article "said" and can be used interchangeably with "said one or more". As used herein, the term "set" is intended to include one or more items (e.g., related items, unrelated items, combinations of related and unrelated items and / or the like), and can be used interchangeably with "one or more". In the case of intending only one item, the phrase "only one" or similar language is used. Moreover, as used herein, the term "has", "have", "having" or the like is intended to be an open term. In addition, the phrase "based on" is intended to mean "based at least in part on", unless otherwise explicitly stated. In the foregoing description, depending on the context, satisfying a threshold may refer to a value being greater than a threshold, greater than or equal to a threshold, less than a threshold, less than or equal to a threshold, equal to a threshold, and / or the like.

[0137] Although specific combinations of features are described in the claims and / or disclosed in the specification, these combinations are not intended to limit the disclosure of the various embodiments. In fact, many of these features can be combined in ways not specifically described in the claims and / or disclosed in the specification. Therefore, although each dependent claim listed below may be directly dependent on only one claim, the disclosure of the various embodiments includes the combination of each dependent claim with every other claim in the claim set. No element, action, or instruction used herein should be interpreted as being critical or essential unless explicitly described as such.

Claims

1. A device comprising: Network interface; one or more processors; and logic, the logic comprising instructions stored on a non-transitory computer-readable medium, the instructions being executable by the one or more processors, the logic comprising: Logic for receiving user inquiries related to network services; logic for receiving operational information about the network service; logic to generate an enhanced chat prompt using a first machine learning engine based at least in part on the operational information; logic for transmitting the enhanced chat prompt via the network interface for general conversational artificial intelligence processing; logic for receiving, via the network interface, a response generated by the general conversational artificial intelligence; logic to enhance the response using a second machine learning engine; and Logic is used to provide the enhanced response for presentation to a user.

2. A device according to claim 1, wherein the operational information includes performance information about a client equipment associated with the user, and wherein the device further includes logic for modifying a configuration of the client equipment based at least in part on the enhanced response to improve the performance of the client equipment. The device of claim 1 , wherein the device is a client device in a broadband network.

4. The device according to claim 3, wherein: The logic for receiving user inquiries includes: Logic is provided to receive the user query from another device. The device of claim 3 , wherein the other device is a client equipment in a broadband network.

6. The device according to claim 1, wherein: The logic for enhancing the chat prompt includes: logic for enriching the prompt with operational information; and The response is an enriched response.

7. The device according to claim 1, wherein The logic for enhancing the chat prompt includes: Logic for generating supplemental prompts; and The device further comprises: Logic for transmitting the supplemental prompt for processing by a general conversational artificial intelligence; logic for receiving a supplemental response; and Logic is provided for augmenting the response with the supplemental response.

8. The apparatus of claim 1, wherein enhancing the response comprises enhancing the response with special data.

9. The device of claim 1, wherein at least one of the machine learning engines comprises a multi-head machine learning model.

10. The apparatus according to claim 1, wherein the multi-head machine learning model comprises a backbone network trained with a common dataset and a plurality of multi-head models trained with dedicated datasets.

11. The apparatus of claim 1, wherein at least one of the machine learning engines employs adaptive multi-model switching.

12. The apparatus of claim 11, wherein the multi-model switching comprises jumping between a plurality of models. The apparatus according to claim 11 , wherein the multi-model switching comprises running a plurality of models in parallel.

14. The apparatus of claim 13, wherein running multiple models in parallel comprises employing an optimal output selection strategy.

15. The apparatus of claim 13, wherein running multiple models in parallel comprises employing an output majority voting strategy.

16. The apparatus of claim 13, wherein running multiple models in parallel comprises employing an output aggregation strategy.

17. The apparatus of claim 13, wherein running multiple models in parallel comprises employing a model delegation strategy.

18. The apparatus of claim 11, wherein the multi-model switching comprises running a plurality of models in series.

19. A system comprising: A first device comprising: first one or more processors; and first logic, the first logic comprising instructions stored on a first non-transitory computer-readable medium, the instructions executable by the first one or more processors, the first logic comprising: Logic for receiving user inquiries related to network services; logic for receiving first operation information related to the network service; logic to generate an enhanced chat prompt using a first machine learning engine based at least in part on the operational information; Logic for transmitting the enhanced chat prompt for general conversational artificial intelligence processing; and A second device comprising: second one or more processors; and second logic, the second logic comprising instructions stored on a second non-transitory computer-readable medium, the instructions executable by the second one or more processors, the second logic comprising: logic to receive the enhanced chat prompt from the first device; logic for receiving second operation information related to the network service; logic for further enhancing the chat prompt using at least a second machine learning engine based at least in part on the second operational information; Logic for transmitting the further enhanced chat prompt for general conversational artificial intelligence processing; Logic for receiving a response generated by the general conversational artificial intelligence; logic to enhance the response using a fourth machine learning engine; and logic to provide the enhanced response to the first device; Wherein the first logic further comprises: logic to receive the enhanced response from the second device; logic to further enhance the response using a third machine learning engine; and Logic is used to provide the further enhanced response for presentation to the user.

20. A method comprising: receiving, at a device including a processor, a user query related to a network service; receiving, at the device, operational information about the network service; utilizing the apparatus to enhance a chat prompt using a first machine learning engine based at least in part on the operational information; transmitting, using the device, the enhanced chat prompt for general conversational artificial intelligence processing; receiving, using the device, a response generated by the general conversational artificial intelligence; enhancing the response using a second machine learning engine with the device; and The enhanced response is provided from the device for presentation to the user.

Images