Intelligent outbound call method and device

Abstract

The application discloses an intelligent outbound call method and device. The method comprises the following steps: in response to an upstream request, a conversion result in a unified data format and protocol is generated; a corresponding downstream large model is selected based on the conversion result, and a script to be used in an outbound call scene is returned, and the outbound call scene realizes interactive enhancement of an outbound call process through a preset plug-in. Through the application, multi-model dynamic adaptation and automatic processing of results are realized, the connection cost and iteration cycle are reduced, and customer experience and call efficiency are improved.

Description

Technical Field

[0001] This application relates to the field of intelligent outbound calling technology, and in particular to an intelligent outbound calling method and apparatus. Background Technology

[0002] With the development of the digital economy, industries such as finance and telecommunications are upgrading their demand for intelligent outbound calling from "automated broadcasting" to "intelligent interaction".

[0003] Traditional outbound calling systems are based on fixed process trees and preset script libraries, and can only achieve simple "play-button response" interaction. They cannot understand personalized customer questions, such as "the difference between the interest rate of this loan and that of competitors" or "how to restore the credit limit after overdue repayment", which leads to poor customer experience and low business conversion rate. Summary of the Invention

[0004] This application provides an intelligent outbound calling method and device to connect multiple upstream systems and multiple large models and to provide an intermediate engine with outbound calling scenario-based capabilities, thereby solving the three major core problems of "adapting to fragmentation", "mechanical interaction" and "compliance risks".

[0005] The embodiments of this application adopt the following technical solutions:

[0006] In a first aspect, embodiments of this application provide an intelligent outbound calling method, the method comprising:

[0007] In response to upstream requests, generate conversion results with unified data format and protocol;

[0008] Based on the conversion result, the corresponding downstream large model is selected, and the script to be used in the outbound call scenario is returned. The outbound call scenario enhances the interaction of the outbound call process through a preset plugin.

[0009] In some embodiments, the preset plugin interfaces with the upstream request conversion module and the model routing module through a standardized interface to perform semantic interruption, connector scheduling, and session context management; it is also used to perform end-to-end outbound call compliance filtering and / or record tamper-proof compliance audit logs.

[0010] In some embodiments, in response to an upstream request, a conversion result with unified data format and protocol is generated, including:

[0011] The design pattern of main framework plus plugins is adopted. By converting the request protocols and data formats of different upstream systems into a uniform JSON format, key metadata is extracted as standardized data input. The main framework is used for data flow and plugin scheduling, while the plugins are used to adapt to specific upstream types and support flexible expansion.

[0012] Listen to the request ports of different upstream systems and receive the request data in real time; match the corresponding upstream adapter plugin according to the protocol type and upstream system identifier in the request data;

[0013] The protocol parsing and format conversion interface in the upstream matching plugin is called to convert the upstream data into standard JSON format. The JSON format data includes at least the request type, metadata, core content, and scene tags.

[0014] The transformed standard request is bound to upstream metadata for metadata association and stored in a temporary session cache.

[0015] In some embodiments, the corresponding downstream large model is selected based on the conversion result, and the script to be used in the outbound calling scenario is returned, including:

[0016] Establish a multi-scenario model routing strategy, and pre-set API call templates and model protocol template libraries for large models. The multiple model routing strategies include scenario matching strategy, performance priority strategy and manual specification strategy. The scenario matching strategy is used to match the pre-set model according to the scenario tags in the standard JSON request.

[0017] The performance priority strategy is used to collect the performance indicators of each model in real time. When the response latency of any model is greater than 1 second or the success rate is less than 95%, the system switches to the backup model with the best performance.

[0018] The manual specification strategy is used to support upstream systems to carry model identifiers in requests and directly call specified models, meeting the customization needs of special business scenarios.

[0019] Based on the conversion result, the API call template of the preset large model is called in the model protocol template library, and the model output is converted into the format required by the upstream.

[0020] In some embodiments, the outbound call scenario enhances the interaction of the outbound call process through a preset plugin, including:

[0021] The preset plugin includes a semantic interruption plugin for enabling accurate responses to customer inquiries in real time. The semantic interruption plugin includes an offline configuration module and an online judgment module.

[0022] The offline configuration module is used to build an interruption intent word library that includes an interruption word library and a non-interruption word library according to outbound call scenarios. The interruption word library includes high-frequency question words in outbound call scenarios, explicit interruption instructions, and supports uploading industry-specific vocabulary through the configuration center.

[0023] The non-interruption word library includes modal particles, confirmatory statements, and environmental noise indicators; wherein the online judgment module is used to receive customer question text data forwarded by the core adaptation layer and the current broadcast status in real time;

[0024] A lightweight Embedding model is invoked for semantic matching, converting the customer's question text into a semantic vector, and simultaneously calculating the similarity with the word vectors in the allowed interruption lexicon and the uninterrupted lexicon;

[0025] If the similarity with a word in the allowed interruption dictionary is greater than or equal to a preset threshold, an interruption command is generated that includes at least pausing the current broadcast, the customer's question text, and the session ID, and the pause operation is executed.

[0026] If the similarity with words in the non-interrupted word library is greater than or equal to the preset threshold or there is no matching result, a non-interrupted instruction is generated, and only the judgment result is recorded.

[0027] In some embodiments, the outbound call scenario enhances the interaction of the outbound call process through a preset plugin, including:

[0028] The preset plugin includes a connector scheduling plugin, which is used to insert contextual connectors during the inference latency of the downstream large model.

[0029] A linking language database was constructed based on outbound call scenarios and interaction stages.

[0030] Based on the scene tags and the interaction stage, a connecting phrase is randomly selected from the connecting phrase library to ensure that the connecting phrase is different for each outbound call;

[0031] If the downstream large model inference latency is less than the preset fast return threshold, then the broadcast operation of the connecting phrase will be canceled.

[0032] If the downstream large model inference latency is greater than or equal to the preset fast return threshold, the connecting phrase will be passed to the outbound call scenario as a script to be used and forwarded to the upstream.

[0033] In some embodiments, the outbound call scenario enhances the interaction of the outbound call process through a preset plugin, including:

[0034] The preset plugins include a session context management plugin for achieving interactive coherence and a plugin for recording the interaction history of a single outbound call;

[0035] Each upstream outbound call request generates a unique session ID, which serves as the unique identifier for the session data;

[0036] It records five types of data: customer question text, model response text, interaction timestamp, scene tag, and upstream system identifier. Each data item is associated with a session ID and stored in a memory cache.

[0037] Clear the cached data of the session after the outbound call ends;

[0038] When an outbound call is abnormally interrupted, timed-out session data is cleared via a scheduled task.

[0039] If the request does not contain a session ID, a new session ID is generated, and the context fields are initialized and context association logic is established.

[0040] In some embodiments, the outbound call scenario enhances the interaction of the outbound call process through a preset plugin, including:

[0041] The preset plugins include a full-link compliance filtering plugin, which is used to build a multi-level sensitive word library according to outbound call scenarios and regulatory requirements. The sensitive word library includes at least general violation words, outbound call-specific violation words, and business rule words.

[0042] Build a compliance prompt library to replace illegal content as a default compliance fallback prompt; use upstream input filtering as the first layer of verification. This verification is used to receive the upstream request text forwarded by the core adaptation layer, first perform sensitive word matching, and if a sensitive word is matched, directly return the compliance prompt to the upstream system without triggering subsequent model calls.

[0043] If no sensitive words are detected, a violation semantic identification process will be performed. If a violation is determined, a compliance prompt will also be returned.

[0044] Downstream large model request filtering is used as a second layer of verification. This verification is used to perform secondary verification on the Prompt template, context and customer question-related fields in the request before generating the model request.

[0045] If any non-compliant content is detected, the non-compliant portion will be automatically removed, and a compliance verification flag will be added to the request to prompt the model to avoid generating non-compliant content.

[0046] The downstream large model output filter is used as the third layer of verification. This verification is used to first match sensitive words. If a sensitive word is matched, the non-compliant part is replaced with a compliance prompt.

[0047] If no sensitive words are detected, perform semantic violation identification. If a violation is determined, return a compliance prompt directly and do not report the violation to the upstream system.

[0048] Record the filtering results and store them in the compliance audit log;

[0049] Upstream feedback filtering is used as the fourth layer of verification. This verification is used to perform a final verification on the plugin before the processed results are fed back upstream, to ensure that illegal content caused by data transmission or plugin abnormalities is not blocked.

[0050] In some embodiments, the outbound call scenario enhances the interaction of the outbound call process through a preset plugin, including:

[0051] The preset plugins include session metadata and audit log plugins for business traceability and compliance auditing, which record session metadata. The session metadata includes at least session ID, upstream system identifier, call ID, customer ID, outbound call scenario, model type, model response latency, number of semantic interruptions, number of compliance interceptions, and outbound call result.

[0052] Each time the upstream request-engine processing-upstream feedback processing cycle is completed, the aforementioned metadata is recorded once;

[0053] The metadata is stored in a relational database and can be queried by session ID, customer ID, time range, or outbound call scenario.

[0054] The compliance audit log should include at least the audit ID, session ID, filtering process, violation type, violation content, processing result, processing time, and operator information.

[0055] Secondly, embodiments of this application also provide an intelligent outbound calling device, the device comprising:

[0056] The generation module is used to respond to upstream requests and generate conversion results that are consistent with the data format and protocol.

[0057] The return module is used to select the corresponding downstream large model based on the conversion result and return the script to be used in the outbound call scenario. The outbound call scenario enhances the interaction of the outbound call process through preset plugins.

[0058] Thirdly, embodiments of this application also provide an electronic device, including: a processor; and a memory arranged to store computer-executable instructions, which, when executed, cause the processor to perform the above-described method.

[0059] Fourthly, embodiments of this application also provide a computer-readable storage medium that stores one or more programs, which, when executed by an electronic device including multiple applications, cause the electronic device to perform the above-described method.

[0060] The at least one technical solution adopted in this application embodiment can achieve the following beneficial effects: In response to an upstream request, a conversion result with unified data format and protocol is generated. Further, based on the conversion result, a corresponding downstream large model is selected, and the script to be used in the outbound call scenario is returned. The outbound call scenario enhances the interaction of the outbound call process through a preset plugin. The method of this application achieves dynamic adaptation of multiple models and automated result processing, reducing integration costs and iteration cycles, and improving customer experience and call efficiency. Attached Figure Description

[0061] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0062] Figure 1 This is a schematic diagram of the system architecture of the intelligent outbound calling method in the embodiments of this application;

[0063] Figure 2 This is a flowchart illustrating the intelligent outbound calling method in the embodiments of this application;

[0064] Figure 3 This is a schematic diagram of the structure of the intelligent outbound calling device in the embodiments of this application;

[0065] Figure 4 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0066] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0067] Breakthroughs in large-scale model technology have made intelligent outbound call interaction possible, but significant technical barriers exist in the integration of existing outbound call systems with large-scale models. Firstly, upstream outbound call systems are diverse, with inconsistent protocols and data formats. For example, softswitch platforms use MRCP / SIP protocols to transmit voice streams, telemarketing systems use XML to assign tasks, and voice platforms use WebSocket to transmit audio streams. Therefore, a unified adaptation framework is lacking. Secondly, different large-scale models have significantly different API calling methods, parameter requirements, and authentication logic. Outbound call systems need to develop dedicated integration modules for each type of "upstream-model" combination, resulting in high development costs, low iteration efficiency, and an inability to meet the specific requirements of outbound call scenarios for real-time performance (end-to-end latency must be <1.5s) and compliance (sensitive word interception rate must be ≥99%).

[0068] Against this backdrop, this application provides an intermediate engine that can connect multiple upstream systems and multiple models and has outbound call scenario-based capabilities, solving the three core problems of "adapting to fragmentation", "mechanical interaction" and "compliance risks", and promoting the intelligent upgrade of traditional outbound call systems.

[0069] The most similar technical solutions to the intelligent outbound calling method in the embodiments of this application can be mainly divided into three categories, and their core features and limitations are as follows:

[0070] (1) Traditional process tree outbound call system (usually without the ability to interface with large models)

[0071] These systems use a fixed process tree as their core architecture. During development, linear dialogue nodes are designed based on business needs, such as common credit card debt collection. Each node is associated with preset scripts and key response rules (e.g., "After announcing the loan amount, press 1 to confirm, press 2 to transfer to a human operator"). Upstream, they only connect to a single type of outbound call execution system (e.g., a specific brand's softswitch platform). Data interaction is limited to a simple loop of "task instruction - broadcast feedback," lacking the interfaces and logic to connect to larger models. Typical applications include early bank bill notification outbound call systems and telecom operator package recommendation broadcast systems. Their core shortcomings are "high response latency, insufficient anthropomorphism, weak language understanding, and poor interaction flexibility," and they explicitly state that they "cannot connect to large models to achieve intelligent interaction."

[0072] (2) Single large model, i.e. dedicated docking solution for outbound calling system

[0073] These systems develop dedicated interfaces for a specific large model (such as ChatGPT) and a specific outbound calling system, implementing a one-way flow of "outbound calling system initiating a request - model generating a response - outbound calling system broadcasting." The specific logic is as follows: the outbound calling system converts the customer's voice into text using ASR and then directly sends it to the target large model via hard-coded API call parameters; after receiving the large model's text output, it forwards it directly to the TTS module to generate a voice broadcast without format optimization or compliance verification. For example, some internet companies' customized "large model + marketing outbound calling" systems only support the integration of a single model with a single outbound calling platform. This "single large model outbound calling integration solution" "only adapts to the API of a specific AI model, does not support the access of other models, and lacks independent session monitoring, sensitive word filtering, and other supporting functions," while also suffering from "high voice interaction latency (>2s) and lack of semantic interruption capabilities."

[0074] (3) General API Gateway (customized for non-outbound call scenarios)

[0075] These systems use general-purpose API gateway tools (such as Kong and APISIX) as an intermediate forwarding layer between the "upstream system and the large model." Their core functions include request routing, traffic control, and basic authentication. After receiving HTTP / HTTPS requests from the upstream system, the gateway forwards them to the corresponding large model API according to preset routing rules. After receiving the model's output, it directly returns it to the upstream, without optimization for outbound call scenarios. For example, an enterprise's unified API management platform for multiple systems, accommodating the interface forwarding needs of systems such as OA and CRM. This "general-purpose API gateway" has "core capabilities of traffic control and interface forwarding, but does not include business processing components related to AI model interaction," and cannot handle voice stream data (such as MRCP protocol conversion) and real-time interaction requirements (such as semantic interruption) in outbound call scenarios.

[0076] The core flaws in the aforementioned technical solutions severely restrict the integration and application of outbound calling systems with large-scale models, as detailed below:

[0077] (i) The large-scale model integration capability is lacking or limited, failing to meet the diverse needs of various scenarios.

[0078] Traditional outbound call systems lack the ability to integrate with large models and can only rely on a pre-set script library to respond to customers. When faced with questions that are beyond the scope of the script (such as "the specific reasons for the loan approval failure"), they can only mechanically repeat "please consult customer service", which results in the inability to meet customer needs in a timely manner and a high business interruption rate (actual test data from the reference document shows that the customer hang-up rate of traditional systems is >35%).

[0079] While a single, dedicated large-model integration solution supports large-model calls, it only adapts to a specific model (e.g., only supporting Qwen-7B). If a business scenario requires switching models (e.g., using the logically rigorous Pangu model for debt collection, or the expressive DeepSeek model for marketing), the API call parameters, authentication logic, and result parsing code need to be refactored, resulting in a development cycle of 1-2 weeks, which cannot quickly respond to business iteration needs. Furthermore, this solution does not support format conversion of the large-model output. If the upstream outbound calling system requires TTS text fragments to be ≤20 characters long (to avoid excessively long broadcasts that might annoy customers), long texts output by the large model (e.g., "Your loan amount is 50,000 yuan, with an annualized interest rate of 3.8%, and a repayment period of 12-36 months") require manual splitting and cannot be automated.

[0080] (ii) Poor compatibility with multiple upstream systems and high integration costs.

[0081] Existing technical solutions lack a unified upstream adaptation framework: traditional outbound calling systems can only connect to a single type of upstream execution system (such as only supporting softswitch platforms of specific brands). If new upstream sources are added (such as audio streams from remote bank voice platforms or structured tasks from credit card telemarketing systems), the protocol parsing module and data conversion logic need to be redeveloped, with an adaptation cycle of up to 2-3 weeks. Furthermore, the code is highly coupled, making subsequent maintenance difficult.

[0082] Furthermore, while the general API gateway supports multiple upstream connections, it cannot handle special data types in outbound call scenarios. For example, real-time voice streams transmitted by softswitch platforms via the MRCP protocol need to be converted into text streams before further processing. However, the general gateway lacks MRCP protocol parsing capabilities, requiring the deployment of an additional independent protocol conversion service. For cross-channel interactive data transmitted by converged communication platforms via WebSocket (such as "a customer simultaneously inquires via telephone and a mini-program"), the general gateway cannot associate the multi-channel context of the same customer, resulting in the large model being unable to obtain a complete interaction history and poor response consistency.

[0083] (iii) Lack of contextualized interactive capabilities for outbound calls, resulting in poor customer experience.

[0084] Existing technical solutions are not optimized for the real-time and natural requirements of voice outbound calls; specific shortcomings include:

[0085] Lack of semantic interruption capability: Customers must wait for the large model to generate a response and for the voice broadcast to finish before they can ask questions (e.g., when a customer hears "annual loan interest rate of 3.8%", they want to immediately ask "whether it includes handling fees", but they have to wait for the complete broadcast to end). This results in a mechanical interaction and poor customer experience. According to the actual test data in the reference document, this problem accounts for more than 40% of the total hang-up rate.

[0086] Large model inference latency leads to a "silent period": the latency for large models to generate responses is typically 500ms-1.5s. During this period, customers do not hear any sound and may mistakenly believe the call has been interrupted, thus hanging up the phone. Neither dedicated large model integration solutions nor general gateways have been designed with optimization mechanisms to address this issue, resulting in a shortened effective call duration.

[0087] No conversation context association: Existing solutions do not record the interaction history of a single outbound call (e.g., if a customer asks "Can my credit limit be increased?" and then asks "What materials are needed for the increase?"), each call to the large model is a "stateless request", which cannot generate a coherent response based on the history of the conversation. Customers need to repeat their needs, resulting in low interaction efficiency.

[0088] (iv) Insufficient compliance management in outbound calling scenarios poses regulatory risks.

[0089] Outbound calling scenarios (especially in the financial sector) have extremely high compliance requirements, and it is necessary to strictly block illegal statements (such as "guaranteed principal and interest", "risk-free investment", "100% approval"), but the compliance control capabilities of existing technical solutions are seriously insufficient.

[0090] If a traditional process tree system is used, relying solely on a static sensitive word database for filtering dialogue cannot identify hidden violations. For example, if a customer asks, "Can investing in this product guarantee that the principal will not be lost?", the system cannot determine that the question involves a "principal guarantee" and will still reply with the usual dialogue.

[0091] If a single large model-specific integration solution is adopted: basic sensitive word checks are only performed after the large model outputs, without compliance verification for upstream inputs. For example, customers may induce the system to generate illegal content such as, "You just say that the loan will definitely be approved, so I will apply." There is also no business rule verification (such as not restricting the broadcast of "credit limit increase" related phrases for overdue customers).

[0092] If a general API gateway uses a general sensitive word library (such as politically sensitive words) that does not include outbound call scenario-specific prohibited words (such as "credit repair" and "fast loan" in the financial field) and cannot dynamically adjust compliance rules in combination with outbound call business scenarios (such as avoiding "threat and intimidation" expressions in debt collection scenarios), it will result in a high risk of violations.

[0093] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0094] like Figure 1 As shown, it adopts an architecture with at least one core adaptation layer, five scenario-based functional plugins, and at least one visual configuration center. All modules focus on four core capabilities: "upstream connection, model routing, interaction enhancement, and compliance management." They do not involve the training, inference, or parameter optimization within large models and only assume the role of "connection and adaptation."

[0095] Intelligent outbound call engine: The core execution unit of this invention is positioned as an "intermediate adaptation hub" between the upstream outbound call related system and the downstream large model. Its core functions focus on unified request format, model call scheduling, enhanced interactive features in outbound call scenarios, and compliance management. It does not involve the training, inference logic, or parameter optimization within the large model, but only plays the role of connecting "request forwarding - result conversion".

[0096] Multi-upstream system adaptation: This refers to the engine's support for connecting to various upstream initiators in the entire outbound call business chain, including but not limited to softswitch platforms (responsible for outbound call task establishment and voice reception), remote bank voice platforms (handling audio streaming transmission and ASR integration), credit card telemarketing business management systems (issuing structured outbound call task instructions), and converged communication platforms (managing cross-channel interactions). It achieves compatibility with different upstream protocols and data formats through plug-in design.

[0097] Multi-model integration: This refers to the engine's preset API call templates for mainstream dialogue models (such as the Qwen series, Pangu series, and DeepSeek series), which support dynamic selection of the appropriate model based on the outbound call scenario (such as financial collection, product marketing, and event notification). At the same time, it converts the text output of the large model into a format that can be directly used by the upstream system (such as TTS speech-to-text and structured business data).

[0098] Enhanced contextualized interaction for outbound calls: This refers to a set of exclusive functions developed by the engine to meet the real-time and natural requirements of voice outbound calls. These functions include semantic interruption (identifying the customer's real-time questioning intent and pausing the current broadcast), transitional speech scheduling (inserting transitional speech within the large model inference delay to avoid silence), and session metadata association (binding the call identifier and interaction context of a single outbound call). The core objective is to improve the fluency of human-computer interaction and customer acceptance.

[0099] End-to-end compliance filtering: This refers to the engine's mechanism for sensitive word blocking, illegal semantic recognition, and business rule verification throughout the entire process of "upstream input - model request - model output - upstream feedback" for outbound call scenarios (especially in the financial sector). For example, it blocks illegal expressions such as "guaranteed principal and interest" and "high-yield promises" to ensure that the interactive content complies with regulatory norms and corporate systems.

[0100] This application provides an intelligent outbound calling method, such as... Figure 2 The diagram shows a flowchart of an intelligent outbound calling method in an embodiment of this application. The method includes at least the following steps S210 to S220:

[0101] Step S210: In response to the upstream request, generate a conversion result with unified data format and protocol.

[0102] Based on the upstream request, a transformation result is generated to unify the data format and protocol. Generally speaking, the request protocols and data formats of different upstream systems are converted into JSON format that the engine can process uniformly. At the same time, key metadata is extracted to provide standardized data input for subsequent modules.

[0103] Step S220: Select the corresponding downstream large model based on the conversion result and return the script to be used in the outbound call scenario. The outbound call scenario enhances the interaction of the outbound call process through a preset plugin.

[0104] Based on the conversion result, the corresponding downstream large model is selected. The selected downstream model returns the script to be used in the outbound call scenario. Interaction enhancement can be achieved by using preset plugins. The plugins are connected to the adaptation layer through standardized RESTful API interfaces or Java interfaces, supporting independent development, on-demand deployment, dynamic enabling or disabling, and solving specific problems of outbound call scenarios such as "interaction enhancement", "compliance control" and "conversation management".

[0105] The above method enables a pluggable multi-upstream adaptation mechanism. Through a "main framework + upstream adaptation plug-in" design, compatibility with various upstream systems such as softswitch platforms, voice platforms, telemarketing systems, and converged communication platforms is achieved. Adding a new upstream system only requires developing a plug-in, without modifying the engine's core code, thus solving the "upstream adaptation fragmentation" problem and shortening the adaptation cycle to within one day.

[0106] By using the above method, a scenario-based multi-model routing strategy is introduced: API call templates for mainstream large models are preset, supporting three routing strategies: "scenario matching", "performance priority" and "manual specification", dynamically selecting the appropriate model, and automatically converting the model output into the format required by the upstream (such as TTS fragments and structured data), solving the problem of "single-model docking for large models", and the model switching time is ≤30s.

[0107] Through the above methods, the outbound call-specific interaction enhancement solution integrates three major functions: semantic interruption corresponding to a scenario-based lexicon and lightweight semantic recognition, transitional phrase scheduling corresponding to at least 3-7 words of scenario-based transitional phrases, and conversation context management corresponding to a unique conversation ID associated with historical interactions. This solves the problem of "mechanical outbound call interaction" and aims to reduce the hang-up rate to below 15% and reduce the number of times customers repeat their statements by ≥80%.

[0108] Through the above methods, the end-to-end outbound call compliance filtering system constructs a four-fold compliance verification of "upstream input - model request - model output - upstream feedback", combines a special sensitive word library for outbound call scenarios with violation semantic recognition rules, achieves accurate interception of violation content, and records tamper-proof compliance audit logs to solve the problem of "insufficient compliance control", with a sensitive word interception accuracy rate of ≥99.5%.

[0109] In one embodiment of this application, the preset plugin interfaces with the upstream request conversion module and the model routing module through a standardized interface to perform semantic interruption, connector scheduling, and session context management; it is also used to perform end-to-end outbound call compliance filtering and / or record tamper-proof compliance audit logs.

[0110] Scenario-based multi-model routing strategy: Preset API call templates for mainstream large models, support three routing strategies: "scenario matching", "performance priority" and "manual specification", dynamically select the appropriate model, and automatically convert the model output into the format required by the upstream (such as TTS fragments and structured data), solving the problem of "single large model docking", and the model switching time is ≤30s.

[0111] Preferably, it can also enable scenario-based configuration of compliance rules, supporting dynamic adjustment of compliance rules based on outbound call scenarios (such as prohibiting "profit promises" in marketing scenarios and prohibiting "threats and intimidation" in debt collection scenarios) and customer types (such as restricting "credit limit increase" scripts for overdue customers), avoiding business interruption caused by "one-size-fits-all" compliance control.

[0112] A full-chain outbound call compliance filtering system is adopted: a four-fold compliance verification is constructed, consisting of "upstream input - model request - model output - upstream feedback". Combined with a sensitive word library and violation semantic recognition rules for outbound call scenarios, it can accurately intercept violation content and record tamper-proof compliance audit logs to solve the problem of "insufficient compliance control". The accuracy rate of sensitive word interception is ≥99.5%.

[0113] In one embodiment of this application, in response to an upstream request, generating a unified data format and protocol conversion result includes: adopting a main framework plus plugin design pattern, converting the request protocols and data formats of different upstream systems into a uniformly processable JSON format, while extracting key metadata as standardized data input, wherein the main framework is used for data flow and plugin scheduling, and the plugins are used for flexible expansion to support adaptation to specific upstream types; listening to the request ports of different upstream systems and receiving request data in real time; matching the corresponding upstream adaptation plugin according to the protocol type and upstream system identifier in the request data; calling the protocol parsing and format conversion interface in the upstream matching plugin to convert the upstream data into a standard JSON format, wherein the JSON format data at least includes the request type, metadata, core content, and scene tags; binding the converted standard request with the upstream metadata for metadata association and storing it in a temporary session cache.

[0114] The core adaptation layer serves as the intermediary between the upstream system and the large model. It is the "brain" of the engine, responsible for unifying data formats, scheduling downstream models, and controlling data flow. It comprises two core units: the upstream request conversion module and the model routing module, and is the core carrier for solving the problems of adapting to multiple upstream systems and connecting with multiple models.

[0115] The upstream request conversion module's core function is to convert the request protocols and data formats of different upstream systems into a unified JSON format that the engine can process. It also extracts key metadata (such as call identifiers and customer IDs) to provide standardized data input for subsequent modules. The module adopts a "main framework + plugin" design pattern. The main framework is responsible for data flow and plugin scheduling, while the plugins are responsible for adapting to specific upstream types and support flexible expansion. The specific design is as follows:

[0116] The core logic of the main framework is as follows: Receiving upstream requests: Listening to request ports of different upstream systems (such as MRCP protocol port 5060, WebSocket port 8080, and HTTP port 80) and receiving request data in real time; Plugin matching: Automatically matching the corresponding upstream adaptation plugin based on the request protocol type (such as MRCP, SIP, WebSocket, HTTP) and upstream system identifier (such as "Ronglian Qimo Softswitch" and "Remote Bank Voice Platform"); Data conversion: Calling the "Protocol Parsing" and "Format Conversion" interfaces of the matching plugin to convert upstream data into standard JSON format. JSON contains four main fields: "Request Type (Voice Stream / Text / Task Instruction), Metadata (Call ID, Customer ID, Task Number), Core Content (Text / Audio Stream Identifier), and Scenario Tags (Marketing / Collection / Notification)"; Metadata association: Binding the converted standard request with upstream metadata (such as the call session ID of the softswitch platform and the task number of the telemarketing system) and storing it in a temporary session cache (validity period consistent with the duration of a single outbound call, up to 2 hours) for easy subsequent tracing and context association.

[0117] Optionally, the specific upstream adapter plugin design includes (categorized by upstream type):

[0118] (1) Softswitch platform adapter plugin:

[0119] Protocol parsing: Supports MRCPv2 / SIP protocols, receives real-time voice stream data transmitted from softswitch platforms, and parses parameters such as voice sampling rate (e.g., 8kHz) and encoding format (e.g., G.711);

[0120] Data conversion: Call the upstream ASR service (without involving the internal logic of ASR, only passing parameters) to convert the voice stream into text, and at the same time extract metadata such as call identifier (Call-ID), caller number, and called number from the softswitch platform, and encapsulate it into a standard JSON request;

[0121] Special handling: Supports receiving "pause / continue" commands from the softswitch platform and synchronizing them to subsequent semantic interruption plugins to achieve cross-module collaboration.

[0122] (2) Remote banking voice platform adaptation plugin:

[0123] Protocol parsing: Supports the WebSocket protocol, receiving real-time audio streams (such as PCM format) and ASR intermediate results (such as sentence-by-sentence recognition text) transmitted from the voice platform;

[0124] Data conversion: Encapsulate audio stream identifiers (such as audio IDs within the platform), ASR intermediate results, and voice platform session IDs into standard JSON requests;

[0125] Special handling: Supports receiving "real-time interruption events" from the voice platform (such as events triggered by the platform when the customer starts speaking), which can trigger the semantic interruption plugin's judgment logic in advance and shorten response latency.

[0126] (3) Credit Card Telemarketing Management System Adaptation Plugin:

[0127] Protocol parsing: Supports HTTP / HTTPS protocols, receives outbound call task instructions in XML format issued by the system, and parses out the task type (such as "new customer marketing" or "old customer recall"), target customer list (including customer ID and profile tags), and business parameters (such as recommended product ID and promotional activity code).

[0128] Data conversion: Convert the structured data in the XML instructions (such as customer profile tags "interest rate sensitive" and "credit limit requirement ≥ 100,000") into the "metadata" and "scenario tag" fields in standard JSON, and associate them with the task number to facilitate subsequent statistics on task completion rate;

[0129] Special handling: Supports receiving the system's "task pause / terminate" command, synchronizing it to the model routing module, pausing subsequent model calls, and avoiding resource waste.

[0130] (4) Converged communication platform adapter plugin:

[0131] Protocol parsing: Supports the MQTT protocol and receives cross-channel interactive data transmitted by the platform (such as inquiries initiated by customers simultaneously via telephone and mini-program, including voice and text messages on the telephone and text messages on the mini-program).

[0132] Data transformation: Extract the customer's unified identifier (such as mobile phone number), associate it with the interaction content of different channels, and encapsulate it into a standard JSON request containing "multi-channel context";

[0133] Special handling: Supports querying historical interaction records by "customer unified identifier" (such as mini-program consultation content in the past 24 hours), supplementing the "context" field of the current request, and providing the model with a complete interaction history.

[0134] In one embodiment of this application, selecting the corresponding downstream large model based on the conversion result and returning the script to be used in the outbound call scenario includes: establishing a multi-scenario model routing strategy, and simultaneously pre-setting API call templates and model protocol template libraries for large models. The multiple model routing strategies include a scenario matching strategy, a performance priority strategy, and a manually specified strategy. The scenario matching strategy is used to match the preset model according to the scenario tags in the standard JSON request; the performance priority strategy is used to collect the performance indicators of each model in real time, and switch to the backup model with the best performance when the response latency of any model is greater than 1 second or the success rate is less than 95%; the manually specified strategy is used to support the upstream system to carry the model identifier in the request and directly call the specified model to meet the customization requirements of special business scenarios; and calling the API call template of the preset large model in the model protocol template library according to the conversion result, and converting the model output into the format required by the upstream.

[0135] The model routing module enables dynamic calling and result conversion of multiple models. Specifically, the core function of this module is to dynamically select the downstream large model based on the outbound call scenario and model performance, complete request forwarding and result reception, and convert the model output into a format that can be directly used by the upstream system. It is the core unit for solving the problem of multi-model integration, and the specific design is as follows:

[0136] (a) Model Protocol Template Library:

[0137] Template Design: Pre-set API call templates for each major model (Qwen-32B, Pangu-7B, DeepSeek-R1). The templates contain three main categories of parameters: "basic parameters (API address, request method POST / GET, timeout), authentication parameters (APIKey / Token location, such as Header / Body), and business parameters (prompt template, temperature value, max_tokens)". Example (Qwen-32B template): The API address is "https: / / api.qwen.com / v1 / chat / completions", the request method is POST, the Header carries "Authorization: Bearer {APIKey}", and the Body's prompt template is "You are a financial outbound call assistant, the current scenario is {scenario tag}, the customer's historical context is {context}, the customer's current question is {core content}, please generate a concise and compliant reply with a length of ≤50 characters".

[0138] Template Management: Supports adding / editing / deleting templates through the configuration center. When adding a new model, only the template needs to be uploaded, without modifying the module code, improving adaptation efficiency by more than 90%.

[0139] (b) Model routing strategy:

[0140] Scenario matching strategy: Matches preset models based on "scenario tags" (such as "marketing", "collection", "notification") in standard JSON requests. For example: Marketing scenario: Selects the DeepSeek-R1 model (actual testing, according to the documentation, shows that its generated marketing scripts have a 15% higher conversion rate than other models); Collection scenario: Selects the Pangu-7B model (strong logical rigor, with a violation rate as low as 0.1%); Notification scenario: Selects the Qwen-1.8B model (response latency <300ms, meeting the real-time requirements of high-frequency notifications); Performance priority strategy: Real-time collection of performance metrics (response latency, success rate, violation rate) for each model. When the response latency of a model is >1s or the success rate is <95%, it automatically switches to the best-performing backup model; Manual specification strategy: Supports upstream systems to carry "model identifiers" (such as "model:Qwen-32B") in requests, and the engine directly calls the specified model to meet the customization needs of special business scenarios.

[0141] (c) Model result transformation logic:

[0142] Text format optimization: Based on the requirements of the upstream system, optimize the text output by the large model, for example:

[0143] Outbound call system TTS requirements: Break long text messages into segments of ≤20 characters (e.g., "Your loan amount is 50,000 yuan, annual interest rate is 3.8%, and repayment period can be selected from 12 to 36 months" should be broken down into "Your loan amount is 50,000 yuan", "Annual interest rate is 3.8%", and "Repayment period can be selected from 12 to 36 months") to avoid excessively long broadcasts;

[0144] Telemarketing business system requirements: Extract structured data (such as "Customer Intent Level: High" and "Key Requirement: Credit Limit Increase") from model responses and encapsulate it into business fields in JSON format;

[0145] Error handling: If the model returns an error (such as timeout or API Key expiration), the backup model will be automatically triggered; if all backup models fail, a pre-set compliance fallback message will be returned (such as "The system is currently busy, please call back later") to avoid business interruption.

[0146] Results Feedback: The transformed results, along with the original model output, routing strategy, response time, and other information, are encapsulated into a standard JSON response and passed to the data flow unit of the core adaptation layer, triggering subsequent processing by interaction enhancement and compliance filtering plugins.

[0147] This solution addresses the issue of limited compatibility with large models, enabling dynamic adaptation to multiple models and automated result processing. Breaking away from the traditional limitation of "supporting only a single model," it pre-sets API call templates for mainstream large models (including request parameter formats, authentication methods, and timeouts). It supports dynamic model selection based on outbound call scenarios (e.g., marketing, debt collection, notifications) and model performance (e.g., response latency, reply accuracy), without requiring code refactoring; model switching time is ≤30 seconds. It also resolves the issue of "large model output format mismatch with upstream requirements," automatically converting model output text to the required format for the upstream system (e.g., TTS text fragment splitting, structured business data extraction), avoiding manual intervention and improving processing efficiency. Furthermore, it implements a fault-tolerance mechanism for large model calls. When a model service fails (e.g., timeout, error), the engine automatically switches to a backup model, ensuring uninterrupted outbound call service and improving model availability to up to 99.9%.

[0148] In one embodiment of this application, the outbound call scenario enhances the interaction of the outbound call process through a preset plugin, including: the preset plugin includes a semantic interruption plugin for achieving accurate responses to customer inquiries in real time; the semantic interruption plugin includes an offline configuration module and an online judgment module; wherein the offline configuration module is used to construct an interruption intent word library that includes a permitted interruption word library and a non-interruption word library according to outbound call scenario classification; the permitted interruption word library includes high-frequency question words in outbound call scenarios, explicit interruption instructions, and supports uploading industry-specific vocabulary through a configuration center; the non-interruption word library includes interjections, confirmatory statements, and environmental noise indicators; wherein the online judgment module... The positioning module is used to receive customer question text data and the current broadcast status forwarded by the core adaptation layer in real time; it calls the lightweight embedding model to perform semantic matching, converts the customer question text into a semantic vector, and calculates the similarity with the word vectors in the allowed interruption word library and the non-interruption word library; if the similarity with words in the allowed interruption word library is greater than or equal to a preset threshold, an interruption instruction containing at least the pause current broadcast, the customer question text, and the session ID is generated and the pause operation is executed; if the similarity with words in the non-interruption word library is greater than or equal to the preset threshold or there is no matching result, a non-interruption instruction is generated and only the judgment result is recorded.

[0149] The semantic interruption plugin is used to enable accurate responses to customer inquiries in real time.

[0150] The core function of this plugin is to identify the customer's interruption intent, trigger the upstream system to pause the current broadcast, and at the same time convert the customer's question into a model request, thus solving the problem of "mechanical interaction." The specific design is as follows:

[0151] (1) Offline configuration module:

[0152] Construction of the interruption intent vocabulary: Constructing an "interruption-allowed vocabulary" and a "non-interruption vocabulary" categorized by outbound call scenario:

[0153] Allowed interruption word library: Includes high-frequency question words in outbound call scenarios (such as "how much interest", "how to apply", "what materials are needed"), explicit interruption instructions (such as "wait a moment", "stop for a moment", "I have a question"), and supports uploading industry-specific terms through the configuration center (such as "credit requirements" and "repayment methods" in the financial field); Non-interruption word library: Includes interjections (such as "um", "ah", "oh"), confirmatory expressions (such as "yes", "okay", "okay"), and environmental noise indicators (such as "background noise" and "mute") to avoid accidental interruptions; Semantic similarity threshold configuration: Set a similarity threshold through the configuration center (default 0.9). When the semantic similarity between a customer's question and a word in the "Allowed interruption word library" is greater than or equal to the threshold, it is determined as "interruption required", otherwise "no interruption required".

[0154] (2) Online judgment module:

[0155] Data reception: Real-time reception of customer inquiry text (from upstream ASR conversion) forwarded by the core adaptation layer and the current broadcast status (e.g., "broadcasting product interest rate"); Semantic matching: Calling a lightweight embedding model (e.g., BGE-M3, which does not involve model training, but only uses a pre-trained model to calculate semantic vectors) to convert the customer inquiry text into semantic vectors, and calculating similarity with the word vectors in the "allowed interruption lexicon" and "non-interrupted lexicon".

[0156] (3) Interruption judgment:

[0157] If the similarity with the allowed interruption word list is greater than or equal to the threshold, an "interruption instruction" is generated, which includes "pause current broadcast", "customer question text", and "session ID". This instruction is then passed to the core adaptation layer, which forwards it to the upstream outbound call system to perform the pause operation. If the similarity with the non-interruption word list is greater than or equal to the threshold or there is no matching result, a "non-interruption instruction" is generated. Only the judgment result is recorded, and the current broadcast is not affected. Subsequent processing: After the interruption instruction is triggered, the customer question text is automatically encapsulated into a new standard request and passed to the model routing module to generate a targeted response, realizing a closed loop of "customer question - system pause - instant response".

[0158] This addresses the lack of contextualized interaction in outbound calls, improving customer experience and call efficiency.

[0159] Develop a semantic interruption function. By constructing a dedicated "interruption intent lexicon" for outbound call scenarios and using lightweight semantic recognition logic, it can identify customer question intents in real time (such as "Wait a moment" or "How much is the interest?"), triggering the upstream system to pause the current broadcast. Simultaneously, it converts the customer question into a model request, achieving a natural interaction of "customer questions at any time - system instant response," aiming to reduce the hang-up rate caused by "mechanical interaction" to below 15%. Design a transitional phrase scheduling mechanism. Within the large model inference latency, insert a 3-7 word transitional phrase based on the current outbound call scenario (e.g., "Let's continue" for marketing, "I understand your situation" for debt collection), avoiding "silent periods" and improving customer perception. The goal is to reduce the hang-up rate caused by "silent periods" by more than 50%. Implement session context management, generating a unique session ID for each outbound call, recording contextual information such as customer questions, model responses, and interaction timestamps. Subsequent model calls automatically carry historical context, ensuring response consistency, aiming to reduce the number of times customers repeat themselves by ≥80%.

[0160] In one embodiment of this application, the outbound call scenario enhances the interaction of the outbound call process through a preset plugin, including: the preset plugin includes a connector scheduling plugin, used to insert contextualized connectors within the downstream large model inference latency; constructing a connector library according to the outbound call scenario and interaction stage; randomly selecting a connector from the connector library according to the scenario tag and interaction stage to ensure that the connector is different for each outbound call; if the downstream large model inference latency is less than a preset fast return threshold, canceling the broadcast operation of the connector; if the downstream large model inference latency is greater than or equal to the preset fast return threshold, passing the connector to the outbound call scenario as a script to be used, and forwarding it to the upstream.

[0161] The connector scheduling plugin is used to address the "quiet period" in large model inference.

[0162] The core function of this plugin is to insert contextualized transitional phrases within the large model inference latency (500ms-1.5s) to prevent customers from mistakenly believing the call has been interrupted due to "no sound." The specific design is as follows:

[0163] (1) Construction of the cohesive corpus:

[0164] Contextualized Classification: A linking language library is constructed based on outbound call scenarios (marketing, collection, notification) and interaction stages (after the opening remarks, during product introduction, after Q&A). An example is shown below:

[0165] Marketing scenario - during product introduction: "Let's continue," "There's another key advantage," "Please listen carefully."

[0166] Debt collection scenario - after the question is answered: "I understand your situation." "Let's talk about solutions." "How about this?"

[0167] Notification scenario - after the opening remarks: "Let me tell you something," "It's mainly about this," "Let me explain briefly."

[0168] (2) Compliance verification: All connecting phrases have been reviewed by business experts to avoid expressions that may cause ambiguity (such as not using words that may accept customers’ non-compliant requests, such as “no problem” or “of course”). The length is strictly controlled to 3-7 characters to ensure smooth and unobstructed broadcasting.

[0169] (3) Scheduling logic:

[0170] Triggering Timing: When the core adaptation layer sends a model request to the model routing module, it simultaneously sends a "scheduling trigger signal" to the plugin, which includes "scene tag," "interaction stage," and "session ID." Connector Selection: The plugin randomly selects one connector from the connector library based on "scene tag + interaction stage" (to avoid the customer hearing repetitive content), ensuring that the connector is different for each outbound call. Priority Control: If the model inference latency is <300ms (i.e., the large model returns results quickly), the plugin automatically cancels the connector broadcast to avoid the confusion of "the connector not finished playing before the model response arrives." If the latency is ≥300ms, the connector is immediately passed to the core adaptation layer, which forwards it to the TTS module of the upstream outbound call system to generate the voice. Switching Mechanism: When the model response arrives, the plugin sends a "connector termination signal" to the core adaptation layer, and the upstream system immediately stops the connector broadcast and switches to the model response, ensuring a smooth transition.

[0171] In one embodiment of this application, the outbound call scenario enhances the interaction of the outbound call process through a preset plugin, including: the preset plugin includes a session context management plugin for achieving interactive coherence, used to record the interaction history of a single outbound call; generating a unique session ID for each upstream outbound call request as a unique identifier for session data; recording five types of data: customer question text, model response text, interaction timestamp, scenario tag, and upstream system identifier, with each data item associated with a session ID and stored in a memory cache; clearing the cached data of the session after the outbound call ends; clearing timed-out session data through a scheduled task when the outbound call is abnormally interrupted; and generating a new session ID if there is no session ID in the request, while simultaneously initializing the context field and establishing context association logic.

[0172] The session context management plugin is used to achieve interactive consistency.

[0173] The core function of this plugin is to record the interaction history of a single outbound call, providing context support for subsequent model calls and solving the problem of inconsistent responses caused by "stateless requests". The specific design is as follows:

[0174] (1) Session data storage:

[0175] Session ID Generation: A unique session ID (formatted as "Call-ID_timestamp", such as "123456_20240520143000") is generated for each upstream outbound call request, serving as a unique identifier for session data; Storage Content: Records five categories of data: "customer question text, model response text, interaction timestamp, scenario tag, and upstream system identifier". Each data entry is associated with a session ID and stored in a memory cache (such as Redis). The validity period is consistent with the duration of a single outbound call (maximum 2 hours) to avoid long-term occupation of storage resources; Data Cleanup: After the outbound call ends (upstream system sends a "hang-up signal"), the cached data of the session is automatically cleaned up; If the outbound call is abnormally interrupted (such as network failure), a scheduled task cleans up session data that has timed out (>2 hours) to ensure efficient use of cache space.

[0176] (2) Contextual association logic:

[0177] Context Extraction: When the core adaptation layer receives a new upstream request, the plugin extracts the historical interaction data of that session from the cache based on the "session ID" in the request (by default, it extracts the most recent 5 rounds of interaction to avoid excessively long context causing increased model inference latency); Context Encapsulation: The historical interaction data is concatenated in "chronological order" into the format "Customer: {Question 1}; System: {Reply 1}; Customer: {Question 2}; System: {Reply 2}", and added as the "context" field to the standard JSON request; Model Request Supplementation: The core adaptation layer passes the request containing the "context" field to the model routing module, which automatically inserts the "context" into the prompt template (e.g., "Customer Historical Context: {Context}"), ensuring that the large model generates responses based on the complete interaction history; Special Handling: If the request does not contain a session ID (e.g., the first interaction), the plugin automatically generates a new session ID and initializes the "context" field (to be empty) to ensure that subsequent interactions can be correctly associated.

[0178] Solve the problem of fragmentation in multiple upstream adaptations, and reduce integration costs and iteration cycles.

[0179] A pluggable upstream adaptation framework was built, developing dedicated adaptation plugins for different upstream types such as softswitch platforms, voice platforms, telemarketing systems, and converged communication platforms. This allows for "adding a new upstream only requires developing a plugin, without modifying the engine's core code," shortening the adaptation cycle from 2-3 weeks to within 1 day. The upstream data format and protocol conversion logic were unified, converting requests from different upstreams (such as MRCP voice streams, XML task instructions, and WebSocket audio streams) into the engine's standard JSON format. This ensures that subsequent modules such as model calls, interactive enhancements, and compliance filtering can be processed based on a unified data format, reducing code coupling. Metadata association with upstream systems was implemented, binding key information in upstream requests (such as call identifiers, customer IDs, and outbound call task numbers) with subsequent interaction data. This facilitates business traceability and problem troubleshooting (e.g., if an outbound call task fails, it can quickly pinpoint whether the problem lies with the upstream instruction or the model call).

[0180] In one embodiment of this application, the outbound call scenario enhances the interaction of the outbound call process through a preset plugin, including: the preset plugin includes a full-link compliance filtering plugin, used to construct a multi-level sensitive word library according to the outbound call scenario and regulatory requirements, the sensitive word library at least includes general violation words, outbound call-specific violation words, and business rule words; constructing a compliance prompt library for replacing violation content as a preset compliance fallback prompt; using upstream input filtering as the first layer of verification, this verification is used to receive the upstream request text forwarded by the core adaptation layer, first perform sensitive word matching, if a sensitive word is matched, directly return a compliance prompt to the upstream system without triggering subsequent model calls; if no sensitive word is matched, perform violation semantic recognition, if determined to be a violation, also return a compliance prompt; using downstream large model request filtering as the second layer of verification, this verification... Before generating a model request, the Prompt template, context, and customer question-related fields in the request are validated a second time. If any violations are found, the violating parts are automatically removed, and a compliance verification flag is added to the request to warn the model to avoid generating violating content. The downstream large model output filtering is used as a third layer of validation. This validation first performs sensitive word matching. If a sensitive word is matched, the violating part is replaced with a compliance prompt. If no sensitive word is matched, a violation semantic identification is performed. If it is determined to be a violation, a compliance prompt is returned directly without feeding back the violation to the upstream system. The filtering results are recorded and stored in the compliance audit log. The upstream feedback filtering is used as a fourth layer of validation. Before feeding back the processed results to the upstream, the plugin performs a final validation to ensure that violating content caused by data transmission or plugin anomalies is not intercepted.

[0181] The end-to-end compliance filtering plugin is used to address compliance risk issues.

[0182] The core function of this plugin is to perform compliance checks and block illegal content throughout the entire process of "upstream input - model request - model output - upstream feedback". The specific design is as follows:

[0183] (1) Construction of compliance rules system:

[0184] Sensitive word database: A multi-level sensitive word database is constructed according to outbound call scenarios and regulatory requirements, including: General prohibited words: such as politically sensitive words and abusive words; Outbound call-specific prohibited words: such as "guaranteed principal and interest", "high-yield promise", "credit repair" and "fast loan disbursement" in the financial field, and "absolutely the best" and "100% effective" in the marketing field; Business rule words: such as prohibited words for overdue customers such as "credit limit increase" and "new loan application".

[0185] (2) Rules for identifying illegal semantics: Based on the “dynamic semantic recognition” technology in the reference document, a lightweight NLP model (such as the lightweight version of Baidu Wenxin Yiyan) is called to identify implicit illegal semantics (such as when a customer asks “Can investing in this product guarantee that the principal will not be lost?”, the model determines that it is “involving a guarantee of principal”; when the system replies “Overdue payment will affect the credit score of family members”, it is determined that it is “threatening debt collection”).

[0186] Compliance alert library: Preset compliance fallback alerts to replace non-compliant content, as shown in the example below:

[0187] To block "principal and interest guaranteed" claims, the response is: "This question involves prohibited wording and we are unable to answer it for you at this time. Please contact our customer service." To block "threatening debt collection," the response is: "We will handle your repayment matters in accordance with laws and regulations. If you need assistance, please contact our customer service hotline."

[0188] End-to-end filtering logic:

[0189] Upstream input filtering (first layer of verification): Receive upstream request text (customer questions, business instructions) forwarded by the core adaptation layer, first perform sensitive word matching. If a sensitive word is matched, directly return a compliance prompt to the upstream system without triggering subsequent model calls; if no sensitive word is matched, perform violation semantic recognition. If it is determined to be a violation, also return a compliance prompt to ensure that "the source of the problem is compliant".

[0190] Model request filtering (secondary verification): Before the core adaptation layer generates a model request, the plugin performs a secondary verification on the "prompt template + context + customer question" in the request to avoid the model generating an illegal response due to illegal content in the context; if illegal content is found, the illegal part is automatically removed (such as deleting the "break-even" expression in the context), and a "compliance verification mark" is added to the request to prompt the model to avoid generating illegal content.

[0191] Model output filtering (third-level verification): Receives the model output text forwarded by the model routing module, first performs sensitive word matching. If a sensitive word is matched, replaces the non-compliant part with a compliance prompt (e.g., replaces "This product guarantees principal and interest" with "The return of this product is subject to actual conditions," + compliance prompt); if no sensitive word is matched, performs non-compliant semantic recognition. If it is determined to be non-compliant, directly returns a compliance prompt without reporting the non-compliant content upstream; records the filtering results (e.g., "Sensitive word matched: Guaranteed principal and interest, replaced with compliance prompt"), and stores them in the compliance audit log.

[0192] Upstream Feedback Filtering (Fourth Layer of Verification): Before the core adaptation layer feeds back the processed results upstream, the plugin performs a final verification to ensure that illegal content caused by data transmission or plugin anomalies is not blocked, further reducing risks.

[0193] In one embodiment of this application, the outbound call scenario enhances the interaction of the outbound call process through a preset plugin, including: the preset plugin includes a session metadata and audit log plugin for business traceability and compliance auditing, which records session metadata, including at least session ID, upstream system identifier, call ID, customer ID, outbound call scenario, model type, model response latency, number of semantic interruptions, number of compliance interceptions, and outbound call result; the metadata is recorded once for each completion of the upstream request-engine processing-upstream feedback processing loop; the metadata is stored in a relational database and supports querying by session ID, customer ID, time range, or outbound call scenario; the compliance audit log includes at least audit ID, session ID, filtering step, violation type, violation content, processing result, processing time, and operator information.

[0194] The session metadata and audit log plugins are used to enable business traceability and compliance auditing.

[0195] The core function of this plugin is to record key metadata and compliance audit information during engine operation, supporting business traceability and regulatory auditing. The specific design is as follows:

[0196] (1) Session metadata records:

[0197] Recorded content includes "Session ID, Upstream System Identifier, Call ID, Customer ID, Outbound Call Scenario, Model Type, Model Response Latency, Number of Semantic Interruptions, Number of Compliance Interceptions, and Outbound Call Result (Success / Failure)"; Recording timing: Metadata is automatically recorded once after each "Upstream Request - Engine Processing - Upstream Feedback" cycle to ensure data integrity; Storage and querying: Metadata is stored in a relational database (such as MySQL) and supports queries by dimensions such as "Session ID, Customer ID, Time Range, and Outbound Call Scenario," facilitating business personnel to analyze outbound call performance (such as model response latency and semantic interruption success rate in a specific marketing scenario).

[0198] (2) Compliance audit log recording: Record content: includes "Audit ID, Session ID, Filtering process (upstream input / model request / model output / upstream feedback), Violation type (sensitive words / semantic violation), Violation content, Processing result (interception / replacement with compliance prompt), Processing time, Operator (if manual intervention)"; Tamper-proof design: adopts a mechanism that makes the log unmodifiable after it is written (such as adding a timestamp and signature after writing), which meets the regulatory audit requirements for "data tamper-proof"; Export function: supports exporting audit logs by time range and violation type (format is Excel / PDF), which is convenient for responding to regulatory inspections and internal compliance reviews.

[0199] This application addresses the issue of insufficient compliance control in outbound calls and reduces regulatory risks. By constructing a full-chain compliance filtering system—"upstream input - model request - model output - upstream feedback"—this embodiment develops a dedicated sensitive word library (such as "guaranteed principal and interest," "credit repair," and "high-yield promises") and violation semantic recognition rules (such as identifying implicit violations like "inducing investment" and "threatening debt collection") for outbound call scenarios (especially in the financial sector). The accuracy rate for intercepting target sensitive words is ≥99.5%, and the accuracy rate for identifying violation semantics is ≥98%.

[0200] This application also provides an intelligent outbound calling device 300, such as... Figure 3 As shown, a structural schematic diagram of the intelligent outbound calling device 300 in this application embodiment is provided. The intelligent outbound calling device 300 includes at least: a generation module 310 and a return module 320, wherein:

[0201] In one embodiment of this application, the generation module 310 is specifically used to: generate a conversion result with unified data format and protocol in response to an upstream request.

[0202] Based on the upstream request, a transformation result is generated to unify the data format and protocol. Generally speaking, the request protocols and data formats of different upstream systems are converted into JSON format that the engine can process uniformly. At the same time, key metadata is extracted to provide standardized data input for subsequent modules.

[0203] In one embodiment of this application, the return module 320 is specifically used to: select the corresponding downstream large model based on the conversion result, and return the script to be used in the outbound call scenario, wherein the outbound call scenario enhances the interaction of the outbound call process through a preset plugin.

[0204] Based on the conversion result, the corresponding downstream large model is selected. The selected downstream model returns the script to be used in the outbound call scenario. Interaction enhancement can be achieved by using preset plugins. The plugins are connected to the adaptation layer through standardized RESTful API interfaces or Java interfaces, supporting independent development, on-demand deployment, dynamic enabling or disabling, and solving specific problems of outbound call scenarios such as "interaction enhancement", "compliance control" and "conversation management".

[0205] In one embodiment of this application, the preset plugin interfaces with the upstream request conversion module and the model routing module through a standardized interface to perform semantic interruption, connector scheduling, and session context management; it is also used to perform end-to-end outbound call compliance filtering and / or record tamper-proof compliance audit logs.

[0206] In one embodiment of this application, the generation module 310 is further configured to:

[0207] The design pattern of main framework plus plugins is adopted. By converting the request protocols and data formats of different upstream systems into a uniform JSON format, key metadata is extracted as standardized data input. The main framework is used for data flow and plugin scheduling, while the plugins are used to adapt to specific upstream types and support flexible expansion.

[0208] Listen to the request ports of different upstream systems and receive the request data in real time; match the corresponding upstream adapter plugin according to the protocol type and upstream system identifier in the request data;

[0209] The protocol parsing and format conversion interface in the upstream matching plugin is called to convert the upstream data into standard JSON format. The JSON format data includes at least the request type, metadata, core content, and scene tags.

[0210] The transformed standard request is bound to upstream metadata for metadata association and stored in a temporary session cache.

[0211] In one embodiment of this application, the return module 320 is further configured to:

[0212] Establish a multi-scenario model routing strategy, and pre-set API call templates and model protocol template libraries for large models. The multiple model routing strategies include scenario matching strategy, performance priority strategy and manual specification strategy. The scenario matching strategy is used to match the pre-set model according to the scenario tags in the standard JSON request.

[0213] The performance priority strategy is used to collect the performance indicators of each model in real time. When the response latency of any model is greater than 1 second or the success rate is less than 95%, the system switches to the backup model with the best performance.

[0214] The manual specification strategy is used to support upstream systems to carry model identifiers in requests and directly call specified models, meeting the customization needs of special business scenarios.

[0215] Based on the conversion result, the API call template of the preset large model is called in the model protocol template library, and the model output is converted into the format required by the upstream.

[0216] In one embodiment of this application, the return module 320 is further configured to:

[0217] The preset plugin includes a semantic interruption plugin for enabling accurate responses to customer inquiries in real time. The semantic interruption plugin includes an offline configuration module and an online judgment module.

[0218] The offline configuration module is used to build an interruption intent word library that includes an interruption word library and a non-interruption word library according to outbound call scenarios. The interruption word library includes high-frequency question words in outbound call scenarios, explicit interruption instructions, and supports uploading industry-specific vocabulary through the configuration center.

[0219] The non-interruption word library includes modal particles, confirmatory statements, and environmental noise indicators; wherein the online judgment module is used to receive customer question text data forwarded by the core adaptation layer and the current broadcast status in real time;

[0220] A lightweight Embedding model is invoked for semantic matching, converting the customer's question text into a semantic vector, and simultaneously calculating the similarity with the word vectors in the allowed interruption lexicon and the uninterrupted lexicon;

[0221] If the similarity with a word in the allowed interruption dictionary is greater than or equal to a preset threshold, an interruption command is generated that includes at least pausing the current broadcast, the customer's question text, and the session ID, and the pause operation is executed.

[0222] If the similarity with words in the non-interrupted word library is greater than or equal to the preset threshold or there is no matching result, a non-interrupted instruction is generated, and only the judgment result is recorded.

[0223] In one embodiment of this application, the return module 320 is further configured to:

[0224] The preset plugin includes a connector scheduling plugin, which is used to insert contextual connectors during the inference latency of the downstream large model.

[0225] A linking language database was constructed based on outbound call scenarios and interaction stages.

[0226] Based on the scene tags and the interaction stage, a connecting phrase is randomly selected from the connecting phrase library to ensure that the connecting phrase is different for each outbound call;

[0227] If the downstream large model inference latency is less than the preset fast return threshold, then the broadcast operation of the connecting phrase will be canceled.

[0228] If the downstream large model inference latency is greater than or equal to the preset fast return threshold, the connecting phrase will be passed to the outbound call scenario as a script to be used and forwarded to the upstream.

[0229] In one embodiment of this application, the return module 320 is further configured to:

[0230] The preset plugins include a session context management plugin for achieving interactive coherence and a plugin for recording the interaction history of a single outbound call;

[0231] Each upstream outbound call request generates a unique session ID, which serves as the unique identifier for the session data;

[0232] It records five types of data: customer question text, model response text, interaction timestamp, scene tag, and upstream system identifier. Each data item is associated with a session ID and stored in a memory cache.

[0233] Clear the cached data of the session after the outbound call ends;

[0234] When an outbound call is abnormally interrupted, timed-out session data is cleared via a scheduled task.

[0235] If the request does not contain a session ID, a new session ID is generated, and the context fields are initialized and context association logic is established.

[0236] In one embodiment of this application, the return module 320 is further configured to:

[0237] The preset plugins include a full-link compliance filtering plugin, which is used to build a multi-level sensitive word library according to outbound call scenarios and regulatory requirements. The sensitive word library includes at least general violation words, outbound call-specific violation words, and business rule words.

[0238] Build a compliance prompt library to replace illegal content as a default compliance fallback prompt; use upstream input filtering as the first layer of verification. This verification is used to receive the upstream request text forwarded by the core adaptation layer, first perform sensitive word matching, and if a sensitive word is matched, directly return the compliance prompt to the upstream system without triggering subsequent model calls.

[0239] If no sensitive words are detected, a violation semantic identification process will be performed. If a violation is determined, a compliance prompt will also be returned.

[0240] Downstream large model request filtering is used as a second layer of verification. This verification is used to perform secondary verification on the Prompt template, context and customer question-related fields in the request before generating the model request.

[0241] If any non-compliant content is detected, the non-compliant portion will be automatically removed, and a compliance verification flag will be added to the request to prompt the model to avoid generating non-compliant content.

[0242] The downstream large model output filter is used as the third layer of verification. This verification is used to first match sensitive words. If a sensitive word is matched, the non-compliant part is replaced with a compliance prompt.

[0243] If no sensitive words are detected, perform semantic violation identification. If a violation is determined, return a compliance prompt directly and do not report the violation to the upstream system.

[0244] Record the filtering results and store them in the compliance audit log;

[0245] Upstream feedback filtering is used as the fourth layer of verification. This verification is used to perform a final verification on the plugin before the processed results are fed back upstream, to ensure that illegal content caused by data transmission or plugin abnormalities is not blocked.

[0246] In one embodiment of this application, the return module 320 is further configured to:

[0247] The preset plugins include session metadata and audit log plugins for business traceability and compliance auditing, which record session metadata. The session metadata includes at least session ID, upstream system identifier, call ID, customer ID, outbound call scenario, model type, model response latency, number of semantic interruptions, number of compliance interceptions, and outbound call result.

[0248] Each time the upstream request-engine processing-upstream feedback processing cycle is completed, the aforementioned metadata is recorded once;

[0249] The metadata is stored in a relational database and can be queried by session ID, customer ID, time range, or outbound call scenario.

[0250] The compliance audit log should include at least the audit ID, session ID, filtering process, violation type, violation content, processing result, processing time, and operator information.

[0251] It is understood that the above-mentioned intelligent outbound calling device can realize all the steps of the intelligent outbound calling method provided in the foregoing embodiments. The relevant explanations of the intelligent outbound calling method are applicable to the intelligent outbound calling device, and will not be repeated here.

[0252] Figure 4 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Please refer to it. Figure 4 At the hardware level, the electronic device includes a processor, and optionally also includes an internal bus, a network interface, and memory. The memory may include main memory, such as high-speed random-access memory (RAM), or non-volatile memory, such as at least one disk drive. Of course, the electronic device may also include other hardware required for other business operations.

[0253] The processor, network interface, and memory can be interconnected via an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 4 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0254] Memory is used to store programs. Specifically, programs may include program code, which includes computer operation instructions. Memory may include main memory and non-volatile memory, and provides instructions and data to the processor.

[0255] The processor reads the corresponding computer program from non-volatile memory into main memory and then executes it, forming an intelligent outbound calling device at the logical level. The processor executes the program stored in memory and specifically performs the following operations:

[0256] In response to upstream requests, generate conversion results with unified data format and protocol;

[0257] Based on the conversion result, the corresponding downstream large model is selected, and the script to be used in the outbound call scenario is returned. The outbound call scenario enhances the interaction of the outbound call process through a preset plugin.

[0258] The above is as stated in this application. Figure 2 The method executed by the intelligent outbound calling device disclosed in the illustrated embodiment can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this application can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0259] The electronic device can also perform Figure 2 The method for executing intelligent outbound calling devices, and the realization of intelligent outbound calling devices in... Figure 2 The functions of the embodiments shown are not described in detail here.

[0260] This application also proposes a computer-readable storage medium that stores one or more programs, the programs including instructions that, when executed by an electronic device including multiple applications, enable the electronic device to perform... Figure 2 The method executed by the intelligent outbound calling device in the illustrated embodiment is specifically used to perform the following:

[0261] In response to upstream requests, generate conversion results with unified data format and protocol;

[0262] Based on the conversion result, the corresponding downstream large model is selected, and the script to be used in the outbound call scenario is returned. The outbound call scenario enhances the interaction of the outbound call process through a preset plugin.

[0263] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0264] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0265] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0266] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0267] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0268] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0269] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0270] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0271] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0272] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A smart outbound calling method, characterized in that, The method includes: In response to upstream requests, generate conversion results with unified data format and protocol; Based on the conversion result, the corresponding downstream large model is selected, and the script to be used in the outbound call scenario is returned. The outbound call scenario enhances the interaction of the outbound call process through a preset plugin.

2. The intelligent outbound calling method as described in claim 1, characterized in that, The preset plugin interfaces with the upstream request conversion module and model routing module through standardized interfaces to perform semantic interruption, connector scheduling, and session context management; it is also used to perform end-to-end outbound call compliance filtering and / or record tamper-proof compliance audit logs.

3. The intelligent outbound calling method as described in claim 1, characterized in that, In response to upstream requests, generate conversion results with unified data format and protocol, including: The design pattern of main framework plus plugins is adopted. By converting the request protocols and data formats of different upstream systems into a uniform JSON format, key metadata is extracted as standardized data input. The main framework is used for data flow and plugin scheduling, while the plugins are used to adapt to specific upstream types and support flexible expansion. Listen to the request ports of different upstream systems and receive the request data in real time; match the corresponding upstream adapter plugin according to the protocol type and upstream system identifier in the request data; The protocol parsing and format conversion interface in the upstream matching plugin is called to convert the upstream data into standard JSON format. The JSON format data includes at least the request type, metadata, core content, and scene tags. The transformed standard request is bound to upstream metadata for metadata association and stored in a temporary session cache.

4. The intelligent outbound calling method as described in claim 1, characterized in that, Based on the conversion result, the corresponding downstream large model is selected, and the script to be used in the outbound calling scenario is returned, including: Establish a multi-scenario model routing strategy, and pre-set API call templates and model protocol template libraries for large models. The multiple model routing strategies include scenario matching strategy, performance priority strategy and manual specification strategy. The scenario matching strategy is used to match the pre-set model according to the scenario tags in the standard JSON request. The performance priority strategy is used to collect the performance indicators of each model in real time. When the response latency of any model is greater than 1 second or the success rate is less than 95%, the system switches to the backup model with the best performance. The manual specification strategy is used to support upstream systems to carry model identifiers in requests and directly call specified models, meeting the customization needs of special business scenarios. Based on the conversion result, the API call template of the preset large model is called in the model protocol template library, and the model output is converted into the format required by the upstream.

5. The intelligent outbound calling method as described in claim 1, characterized in that, The outbound call scenario enhances the interaction of the outbound call process through preset plugins, including: The preset plugin includes a semantic interruption plugin for enabling accurate responses to customer inquiries in real time. The semantic interruption plugin includes an offline configuration module and an online judgment module. The offline configuration module is used to build an interruption intent word library that includes an interruption word library and a non-interruption word library according to outbound call scenarios. The interruption word library includes high-frequency question words in outbound call scenarios, explicit interruption instructions, and supports uploading industry-specific vocabulary through the configuration center. The non-interruption word library includes modal particles, confirmatory statements, and environmental noise indicators; wherein the online judgment module is used to receive customer question text data forwarded by the core adaptation layer and the current broadcast status in real time; A lightweight Embedding model is invoked for semantic matching, converting the customer's question text into a semantic vector, and simultaneously calculating the similarity with the word vectors in the allowed interruption lexicon and the uninterrupted lexicon; If the similarity with a word in the allowed interruption dictionary is greater than or equal to a preset threshold, an interruption command is generated that includes at least pausing the current broadcast, the customer's question text, and the session ID, and the pause operation is executed. If the similarity with words in the non-interrupted word library is greater than or equal to the preset threshold or there is no matching result, a non-interrupted instruction is generated, and only the judgment result is recorded.

6. The intelligent outbound calling method as described in claim 1, characterized in that, The outbound call scenario enhances the interaction of the outbound call process through preset plugins, including: The preset plugin includes a connector scheduling plugin, which is used to insert contextual connectors during the inference latency of the downstream large model. A linking language database was constructed based on outbound call scenarios and interaction stages. Based on the scene tags and the interaction stage, a connecting phrase is randomly selected from the connecting phrase library to ensure that the connecting phrase is different for each outbound call; If the downstream large model inference latency is less than the preset fast return threshold, then the broadcast operation of the connecting phrase will be canceled. If the downstream large model inference latency is greater than or equal to the preset fast return threshold, the connecting phrase will be passed to the outbound call scenario as a script to be used and forwarded to the upstream.

7. The intelligent outbound calling method as described in claim 1, characterized in that, The outbound call scenario enhances the interaction of the outbound call process through preset plugins, including: The preset plugins include a session context management plugin for achieving interactive coherence and a plugin for recording the interaction history of a single outbound call; Each upstream outbound call request generates a unique session ID, which serves as the unique identifier for the session data; It records five types of data: customer question text, model response text, interaction timestamp, scene tag, and upstream system identifier. Each data item is associated with a session ID and stored in a memory cache. Clear the cached data of the session after the outbound call ends; When an outbound call is abnormally interrupted, timed-out session data is cleared via a scheduled task. If the request does not contain a session ID, a new session ID is generated, and the context fields are initialized and context association logic is established.

8. The intelligent outbound calling method as described in claim 1, characterized in that, The outbound call scenario enhances the interaction of the outbound call process through preset plugins, including: The preset plugins include a full-link compliance filtering plugin, which is used to build a multi-level sensitive word library according to outbound call scenarios and regulatory requirements. The sensitive word library includes at least general violation words, outbound call-specific violation words, and business rule words. Build a compliance prompt library to replace illegal content as a default compliance fallback prompt; use upstream input filtering as the first layer of verification. This verification is used to receive the upstream request text forwarded by the core adaptation layer, first perform sensitive word matching, and if a sensitive word is matched, directly return the compliance prompt to the upstream system without triggering subsequent model calls. If no sensitive words are detected, a violation semantic identification process will be performed. If a violation is determined, a compliance prompt will also be returned. Downstream large model request filtering is used as a second layer of verification. This verification is used to perform secondary verification on the Prompt template, context and customer question-related fields in the request before generating the model request. If any non-compliant content is detected, the non-compliant portion will be automatically removed, and a compliance verification flag will be added to the request to prompt the model to avoid generating non-compliant content. The downstream large model output filter is used as the third layer of verification. This verification is used to first match sensitive words. If a sensitive word is matched, the non-compliant part is replaced with a compliance prompt. If no sensitive words are detected, perform semantic violation identification. If a violation is determined, return a compliance prompt directly and do not report the violation to the upstream system. Record the filtering results and store them in the compliance audit log; Upstream feedback filtering is used as the fourth layer of verification. This verification is used to perform a final verification on the plugin before the processed results are fed back upstream, to ensure that illegal content caused by data transmission or plugin abnormalities is not blocked.

9. The intelligent outbound calling method as described in claim 1, characterized in that, The outbound call scenario enhances the interaction of the outbound call process through preset plugins, including: The preset plugins include session metadata and audit log plugins for business traceability and compliance auditing, which record session metadata. The session metadata includes at least session ID, upstream system identifier, call ID, customer ID, outbound call scenario, model type, model response latency, number of semantic interruptions, number of compliance interceptions, and outbound call result. Each time the upstream request-engine processing-upstream feedback processing cycle is completed, the aforementioned metadata is recorded once; The metadata is stored in a relational database and can be queried by session ID, customer ID, time range, or outbound call scenario. The compliance audit log should include at least the audit ID, session ID, filtering process, violation type, violation content, processing result, processing time, and operator information.

10. An intelligent outbound calling device, characterized in that, The device includes: The generation module is used to respond to upstream requests and generate conversion results that are consistent with the data format and protocol. The return module is used to select the corresponding downstream large model based on the conversion result and return the script to be used in the outbound call scenario. The outbound call scenario enhances the interaction of the outbound call process through preset plugins.

Images