CN116320171A

CN116320171A - Artificial intelligent calling system, method, device and medium based on big data

Info

Publication number: CN116320171A
Application number: CN202310595021.1A
Authority: CN
Inventors: 吴芷绮; 束红燕; 杨华
Original assignee: Anhui Botianya Intelligent Technology Group Co ltd
Current assignee: Anhui Botianya Intelligent Technology Group Co ltd
Priority date: 2023-05-25
Filing date: 2023-05-25
Publication date: 2023-06-23
Anticipated expiration: 2043-05-25
Also published as: CN116320171B

Abstract

The embodiment of the specification provides an artificial intelligent calling system, a method, a device and a medium based on big data, wherein the method is realized by the artificial intelligent calling system based on big data, a construction optimization system based on big data comprises an incoming call dispatching module, an outgoing call dispatching module, a big data module and a management module, and the method is executed by the management module and comprises the following steps: the big data control module collects original data from one or more heterogeneous data channels to obtain multi-source heterogeneous data; constructing enterprise big data by a preset method based on the multi-source heterogeneous data; determining at least one candidate calling enterprise through pre-screening conditions based on the enterprise big data; determining a list of preferred call enterprises based on the at least one candidate call enterprise; and controlling the outgoing call scheduling module to perform outgoing call scheduling based on the preferred call enterprise list.

Description

Artificial intelligent calling system, method, device and medium based on big data

Technical Field

The present disclosure relates to the field of artificial intelligence calling, and in particular, to an artificial intelligence calling system, method, apparatus and medium based on big data.

Background

Currently, with the deep application of artificial intelligence technology, various industries enter a new stage of artificial intelligence development. Intelligent calls play an important role in an increasing number of businesses. Load balancing of intelligent calls and analysis and processing of customer information are key to improving intelligent call performance.

Therefore, it is desirable to provide an artificial intelligence call system based on big data, which can ensure the balance of incoming and outgoing loads, determine the requirements of clients and improve the call success rate.

Disclosure of Invention

One or more embodiments of the present disclosure provide an artificial intelligence calling system based on big data, the system including an incoming call dispatch module, an outgoing call dispatch module, a big data module, and a management module, where the incoming call dispatch module is configured to execute incoming call dispatch and statistics of relevant information of the incoming call dispatch, and the incoming call dispatch includes: responsive to receiving the new incoming call request, assigning the incoming call request to the agent; the outgoing call scheduling module is used for executing outgoing call scheduling, and the outgoing call scheduling comprises: allocating at least the preferred call enterprises in the list of preferred call enterprises to agents; the big data module is used for constructing data of one or more dimensions which can be processed by the management module; the management module is at least used for: the method comprises the steps that a big data control module collects original data from one or more heterogeneous data channels to obtain multi-source heterogeneous data, wherein the multi-source heterogeneous data comprise at least one type of data, and the multi-source heterogeneous data contain enterprise information in a preset area; constructing enterprise big data based on the multi-source heterogeneous data by a preset method, wherein the enterprise big data at least comprises an enterprise information database; determining at least one candidate calling enterprise through pre-screening conditions based on the enterprise big data; determining a preferred call enterprise list based on the at least one candidate call enterprise, the preferred call enterprise list including one or more preferred call enterprises; and controlling the outgoing call scheduling module to perform outgoing call scheduling based on the preferred call enterprise list.

One or more embodiments of the present specification provide a big data based artificial intelligence calling method, the method is implemented by a big data based artificial intelligence calling system, a big data based construction optimization system includes an incoming call dispatch module, an outgoing call dispatch module, a big data module, and a management module, the method is executed by the management module, the method includes: the method comprises the steps that a big data control module collects original data from one or more heterogeneous data channels to obtain multi-source heterogeneous data, wherein the multi-source heterogeneous data comprise at least one type of data, and the multi-source heterogeneous data contain enterprise information in a preset area; constructing enterprise big data based on the multi-source heterogeneous data by a preset method, wherein the enterprise big data at least comprises an enterprise information database; determining at least one candidate calling enterprise through pre-screening conditions based on the enterprise big data; determining a preferred call enterprise list based on the at least one candidate call enterprise, the preferred call enterprise list including one or more preferred call enterprises; and controlling the outgoing call scheduling module to execute outgoing call scheduling based on the preferred call enterprise list, wherein the outgoing call scheduling comprises: at least the preferred call enterprises in the list of preferred call enterprises are assigned to agents.

One or more embodiments of the present specification provide an artificial intelligence calling device based on big data, including a processor for performing an artificial intelligence calling method based on big data.

One or more embodiments of the present specification provide a computer-readable storage medium storing computer instructions that, when read by a computer in the storage medium, perform an artificial intelligence call method based on big data.

Drawings

The present specification will be further elucidated by way of example embodiments, which will be described in detail by means of the accompanying drawings. The embodiments are not limiting, in which like numerals represent like structures, wherein: .

FIG. 1 is an exemplary schematic diagram of a big data based artificial intelligence call system shown in accordance with some embodiments of the present description;

FIG. 2 is an exemplary flow chart of a big data based artificial intelligence call method according to some embodiments of the present description;

FIG. 3 is an exemplary flow chart for determining a preferred call enterprise list based on service demand according to some embodiments of the present description;

FIG. 4a is an exemplary schematic diagram of an enterprise association graph as illustrated in accordance with some embodiments of the present description;

FIG. 4b is an exemplary diagram of a sub-graph corresponding to candidate call enterprise A, according to some embodiments of the present description;

fig. 5 is an exemplary diagram illustrating a determination of estimated call time for a preferred call enterprise via a call time estimation model in accordance with some embodiments of the present disclosure.

Detailed Description

In order to more clearly illustrate the technical solutions of the embodiments of the present specification, the drawings that are required to be used in the description of the embodiments will be briefly described below. It is apparent that the drawings in the following description are only some examples or embodiments of the present specification, and it is possible for those of ordinary skill in the art to apply the present specification to other similar situations according to the drawings without inventive effort. Unless otherwise apparent from the context of the language or otherwise specified, like reference numerals in the figures refer to like structures or operations.

It will be appreciated that "system," "apparatus," "unit" and/or "module" as used herein is one method for distinguishing between different components, elements, parts, portions or assemblies at different levels. However, if other words can achieve the same purpose, the words can be replaced by other expressions.

As used in this specification and the claims, the terms "a," "an," "the," and/or "the" are not specific to a singular, but may include a plurality, unless the context clearly dictates otherwise. In general, the terms "comprises" and "comprising" merely indicate that the steps and elements are explicitly identified, and they do not constitute an exclusive list, as other steps or elements may be included in a method or apparatus.

A flowchart is used in this specification to describe the operations performed by the system according to embodiments of the present specification. It should be appreciated that the preceding or following operations are not necessarily performed in order precisely. Rather, the steps may be processed in reverse order or simultaneously. Also, other operations may be added to or removed from these processes.

FIG. 1 is an exemplary schematic diagram of a big data based artificial intelligence call system, according to some embodiments of the present description.

As shown in fig. 1, big data based artificial intelligence call system 100 may include an incoming dispatch module 101, an outgoing dispatch module 102, a big data module 103, and a management module 104.

The big data based artificial intelligence call system 100 may be used to perform call tasks to facilitate a user's provision or recommendation of services to their customers or potential customers (e.g., businesses within a pre-set area). For example, the services may include quality control certification, management consultation, project declaration, and the like. It will be appreciated that the service may also include products, technologies, personnel, etc., and this specification is not limiting.

The incoming call dispatch module 101 may be configured to perform incoming call dispatch and statistics related information of incoming call dispatch. The call-in dispatch includes assigning the call-in request to the agent in response to receiving the new call-in request. An incoming call request may refer to a request for an active incoming call by a client. The incoming call request may include, but is not limited to, one or more of data instructions, voice, text messages, text pushes, images, video, broadcast, etc. An agent may refer to a service terminal or service person performing an incoming call dispatch and/or an outgoing call dispatch. The agents may include artificial agents, intelligent agents, and the like. The information related to the incoming call scheduling may include incoming call load conditions. For more description of the incoming load situation see fig. 3 and its associated description.

Outgoing dispatch module 102 may be configured to perform outgoing dispatch, which may include assigning at least a preferred call enterprise in a list of preferred call enterprises to an agent. In some embodiments, the outgoing call dispatch further includes assigning the preferred call enterprises and their service recommendation sequences in the preferred call enterprise list to agents. For more explanation of outgoing schedule see fig. 2 and its associated description.

Big data module 103 may be used to construct data of one or more dimensions that may be processed by management module 104. For example, big data module 103 may construct a vector library database based on the enterprise information of the candidate enterprises. For another example, big data module 103 may construct a base feature vector, a benefit feature vector, a service feature vector for the candidate call enterprise. As another example, big data module 103 may construct enterprise distribution vectors as well as service distribution vectors. In some embodiments, big data module 103 may be used to collect raw data resulting in multi-source heterogeneous data. For more explanation on the above data construction and data acquisition, see the relevant descriptions of fig. 2 and 5.

The management module 104 may be configured to control the big data module to collect raw data from one or more heterogeneous data channels to obtain multi-source heterogeneous data, where the multi-source heterogeneous data includes at least one type of data, and the multi-source heterogeneous data contains enterprise information in a preset area; constructing enterprise big data based on the multi-source heterogeneous data by a preset method, wherein the enterprise big data at least comprises an enterprise information database; determining at least one candidate calling enterprise through pre-screening conditions based on the enterprise big data; determining a preferred call enterprise list based on the at least one candidate call enterprise, the preferred call enterprise list including one or more preferred call enterprises; and controlling the outgoing call scheduling module to perform outgoing call scheduling based on the preferred call enterprise list. For more explanation of performing outgoing call scheduling based on a preferred call enterprise list, see fig. 2 and its associated description.

In some embodiments, the management module 104 may be further configured to obtain enterprise information for each candidate calling enterprise from an enterprise information database; determining a service demand level of each candidate calling enterprise based on the enterprise information; and determining a list of preferred call enterprises based on the service demand level. For more description of determining a preferred call enterprise list based on service desirability, see fig. 3 and its associated description.

In some embodiments, the management module 104 may be further configured to determine, from the enterprise association map, a sub-graph corresponding to each candidate calling enterprise based on enterprise information of each candidate calling enterprise; and determining the service demand degree of each candidate calling enterprise based on the sub-map. For more description of determining the service desirability of a candidate call enterprise based on the enterprise association graph, see fig. 4a, 4b and their associated description.

It should be noted that the above description of the big data based artificial intelligence call system 100 is for descriptive convenience only and is not intended to limit the present description to the scope of the illustrated embodiments. It will be appreciated by those skilled in the art that having knowledge of the principles of the big data based artificial intelligence call system, it is possible to combine individual functional units and/or components arbitrarily or to construct a big data based artificial intelligence call system in connection with other functional units without departing from such principles. For example, each module may share one management module, or each module may have a respective management module. Such variations are within the scope of the present description.

FIG. 2 is an exemplary flow chart of a big data based artificial intelligence call method according to some embodiments of the present description. As shown in fig. 2, the process 200 includes the following steps. In some embodiments, the process 200 may be performed by a management module.

In step 210, the big data module is controlled to collect raw data from one or more heterogeneous data channels, so as to obtain multi-source heterogeneous data.

The heterogeneous data channel may refer to a channel in which heterogeneous data is acquired, such as television news, newspapers, internet media accounts, portals, and the like. Heterogeneous data, among other things, refers to any data that has a high degree of variability in the type and format of the data. Such as tabular data, spatiotemporal data, textual data, etc.

Raw data refers to the initial data collected for each heterogeneous data channel. For example, the raw data collected through a television news channel is voice data (e.g., news broadcast recording), the raw data collected through a newspaper channel is image data (e.g., newspaper scanner pictures), and the raw data collected through an internet media account, web portal channel is text data.

Multisource isomerism refers to isomerism data of different sources. For example, the aforementioned voice data collected through a television news channel, image data collected through a newspaper channel, and text data collected through a web portal channel may be collectively referred to as multi-source heterogeneous data.

In some embodiments, the multi-source heterogeneous data includes at least one type of data, e.g., the multi-source heterogeneous data may include one or more of video data, image data, voice data, and text data.

In some embodiments, the multi-source heterogeneous data contains enterprise information within a predetermined region. The preset area is an area which is preset and needs to acquire enterprise information. For example, if the service area covered by the user is a city, the preset area may be the city. The service scheme provided by the user is only used for a certain province, and the preset area can be the province.

The business information refers to related information reflecting the business situation. The enterprise information may include information such as basic information of the enterprise (e.g., enterprise scale, personnel constitution, camping service, etc.), business operation conditions of the enterprise (e.g., data of financial newspaper, season newspaper, annual newspaper, etc.), etc.

In some embodiments, the management module may control the big data module to collect raw data from one or more heterogeneous data channels, resulting in multi-source heterogeneous data. The big data module can establish communication connection (such as internet, bluetooth network, etc.) with each heterogeneous data channel through connection. The management module can send out a data instruction for acquiring multi-source heterogeneous data, and the big data module can acquire the original data from one or more heterogeneous data channels through a network based on the data instruction, so that the acquired original data is sent to the management module, and all the original data received by the management module, namely the multi-source heterogeneous data.

Step 220, based on the multi-source heterogeneous data, constructing enterprise big data through a preset method.

Enterprise big data refers to large-scale enterprise information data. In some embodiments, the enterprise big data includes at least an enterprise information database. The types of enterprise information databases may include, but are not limited to mysql, sql, server, db2 and the like.

In some embodiments, the enterprise big data further includes an enterprise association graph. For more description of enterprise association graphs, see FIG. 4 and its associated description.

In some embodiments, the preset methods may include one or more of data cleansing, data storage, data analysis, data mining. The data cleansing refers to a process of rechecking and checking data, and aims to delete repeated information, correct existing errors and provide data consistency. Data mining refers to the process of algorithmically searching for information hidden in a large amount of data.

In some embodiments, the management module may construct enterprise big data through a preset method based on the multi-source heterogeneous data. By way of example only, the management module may build a database containing individual business information within a preset area by a preset method based on the multi-source heterogeneous data. For example, the management module may construct a vector corresponding to each enterprise based on the enterprise and the enterprise basic information and the enterprise business situation corresponding to the enterprise contained in the multi-source heterogeneous data through data mining, and construct a database based on each vector.

At step 230, at least one candidate calling enterprise is determined by pre-screening conditions based on the enterprise big data.

The pre-screening condition refers to a condition for determining candidate call enterprises. For example, the pre-screening condition may be a business that was previously ISO-certified but is currently outdated. The pre-screening condition may also be an enterprise that has never been subjected to any authentication.

Candidate calling enterprises refer to one or more enterprises in the enterprise big data that meet the pre-screening condition. For example, the candidate calling enterprise may be an enterprise that has never been authenticated.

In some embodiments, the management module may determine at least one candidate call enterprise based on the pre-screening conditions. For example, the management module may query enterprise big data (e.g., an enterprise information database) for enterprises that meet the pre-screening criteria, and take the enterprises that meet the pre-screening criteria as candidate calling enterprises.

Step 240, determining a list of preferred call enterprises based on the at least one candidate call enterprise.

The preferred call enterprise list refers to a list including at least one preferred call enterprise. A preferred calling enterprise may refer to an enterprise that needs to perform outgoing dispatch. For example, the preferred calling enterprise may be an enterprise whose business direction (e.g., food processing, electronic consumer product manufacturing, etc.) may be authenticated by a quality management system.

In some embodiments, the management module may determine the preferred call enterprise list based on at least one candidate call enterprise. For example, the management module may determine that all of the candidate call enterprises are preferred call enterprises. For another example, the management module may set a first preset rule, and determine an enterprise that satisfies the first preset rule from among the candidate call enterprises as a preferred call enterprise. The first preset rule may include that the enterprise scale reaches a certain standard (for example, greater than 20 people), the operation direction meets the authentication requirement (for example, the operation direction is food processing, electronic consumer product manufacturing, etc.), the historical authentication times reach a certain threshold (for example, greater than or equal to 1 time), etc. It should be appreciated that when the business direction meets the authentication requirements, it indicates that the candidate call enterprises are required to perform authentication services. The historical number of authentications reaching a certain threshold indicates that the enterprise may be willing to invest funds for the authentication.

In some embodiments, the management module may obtain enterprise information for each candidate calling enterprise from an enterprise information database, and determine a service demand level for each candidate calling enterprise based on the enterprise information; and determining a list of preferred call enterprises based on the service demand level. For more description of determining a preferred call enterprise list based on service desirability, see fig. 3 and its associated description.

In step 250, the outgoing call scheduling module is controlled to perform outgoing call scheduling based on the preferred call enterprise list.

Outgoing dispatch may refer to the relevant dispatch of an active call enterprise.

In some embodiments, outgoing call dispatch includes at least assigning a preferred call enterprise in a list of preferred call enterprises to an agent. For example, the outgoing dispatch module may assign a preferred calling enterprise to a currently idle agent.

In some embodiments, outgoing call scheduling may include assigning a preferred call enterprise and its service recommendation sequence in a preferred call enterprise list to an agent. For more description of service recommendation sequences see fig. 5 and its associated description.

In some embodiments, the management module may issue outgoing dispatch instructions to the outgoing dispatch module based on the preferred call enterprise list. The outgoing dispatch module may receive the outgoing dispatch instruction and execute outgoing dispatch.

According to the method, multi-source heterogeneous data containing enterprise information is collected, enterprise big data are built, the enterprise big data are analyzed, a candidate call list can be determined, and further, a preferable call enterprise list can be determined, so that more scientific outgoing call scheduling is implemented, the incoming and outgoing call load balance is guaranteed, the call success rate is improved to the greatest extent, and the call efficiency is improved.

Fig. 3 is an exemplary flow diagram illustrating a determination of a preferred call enterprise list based on service demand according to some embodiments of the present description. As shown in fig. 3, the process 300 includes the following steps. In some embodiments, the process 300 may be performed by a management module.

At step 310, enterprise information for each candidate calling enterprise is obtained from the enterprise information database.

In some embodiments, the management module may obtain enterprise information for each candidate calling enterprise from an enterprise information database. Specifically, the management module may retrieve the enterprise information of the candidate call enterprise from the enterprise information database based on the candidate call enterprise determined previously.

Step 320, determining a service desirability for each candidate call enterprise based on the enterprise information.

The service demand level may reflect the level of demand of an enterprise for a service (e.g., authentication service). For example, the service demand level may be expressed as a number in the range of 0-10. The larger the number, the higher the demand level.

In some embodiments, the service demand level may be determined by means of vector database matching.

In some embodiments, the management module may control the big data module to build the vector library database based on the enterprise information of the candidate enterprise. The vector database may be represented illustratively in table 1.

Taking enterprise a as an example, an exemplary vector database matching process is as follows:

the management module can control the big data module to construct a basic feature vector a1 of the candidate calling enterprise A based on the enterprise information of the candidate calling enterprise A in the enterprise information database. The basic feature vector refers to a vector reflecting basic information of an enterprise. In some embodiments, the base feature vector may be derived by direct stitching or input embedding models based on enterprise base information (e.g., enterprise scale, camping business, etc.). Taking direct stitching as an example, the base feature vector may be represented as

Wherein->

Can represent the enterprise scale (for example, the enterprise scale is 0 to 100 people corresponds +.>

Can be 1, and the enterprise scale is 100 to 200 people corresponding to->

May be 2, etc.); />

Can represent a main business (e.g. the main business is Internet technology corresponding +.>

Can be 1, and the main business is mechanical manufacturing corresponding +.>

May be 2, etc.).

The management module may match the base feature vector in the vector database based on the base feature vector a1 to obtain one or more similarity vectors, each of which corresponds to an enterprise. One or more enterprises (e.g., enterprise B, C, D) to which the similarity vector corresponds may be candidates to call the similar enterprises of enterprise a. In some embodiments, the management module may determine one or more vectors having a minimum vector distance or a vector distance less than a preset threshold as the similarity vector by calculating a vector distance (e.g., euclidean distance) of the base feature vector a1 to other base feature vectors.

The management module may control the big data module to construct the revenue feature vector a2 and the service feature vector a3 of the candidate call enterprise a. The profit feature vector refers to a vector reflecting the profit situation of the candidate calling enterprise. The service feature vector refers to a vector reflecting the service condition of the candidate call enterprises. In some embodiments, the revenue feature vector a2 and the service feature vector a3 may be obtained by direct stitching. The profit feature vector may be constructed based on business operations (e.g., financial report data (e.g., season report, year report, etc.). The service feature vector may be constructed based on the circumstances under which the enterprise is serviced (e.g., the number of services currently existing, the number of historic services, etc.).

The management module may calculate a profit distance and a service distance between the similar enterprises corresponding to the candidate calling enterprise a and the candidate calling enterprise a.

The revenue distance may reflect a revenue gap for similar enterprises from candidate calling enterprise A. In some embodiments, the management module may determine the revenue distance based on a vector distance M (M being a real number) between the revenue feature vector corresponding to each similar enterprise (e.g., enterprise B, C, D) and the revenue feature vector a2 corresponding to candidate calling enterprise a, such as taking the vector distance M as the revenue distance. It should be appreciated that the greater the revenue distance corresponding to the candidate calling enterprise a for a similar enterprise, the better the revenue situation for that similar enterprise is illustrated to be for the candidate calling enterprise a.

The service distance may reflect the service gap of the similar enterprise from the candidate calling enterprise a. In some embodiments, the management module may determine the service distance based on a vector distance N (N is a real number) between the service feature vector corresponding to each similar enterprise (e.g., enterprise B, C, D) and the service feature vector a3 corresponding to the candidate call enterprise a, e.g., taking the vector distance N as the service distance. It should be appreciated that the greater the service distance corresponding to the candidate calling enterprise a for a similar enterprise, the better the service condition of the similar enterprise is illustrated to be than the candidate calling enterprise a. The service condition can reflect the service owned by the current time of the enterprise and the times of service purchased in the historical time. The more services, the better the service situation.

The management module may obtain the candidate call enterprise a service demand based on the revenue distance and the service distance. In some embodiments, the service demand level of candidate call enterprise a may be calculated by the following formula:

where i represents the number of a similar business corresponding to candidate call business a (e.g., business B may be number 1, business C may be number 2, etc.). n represents the total number of similar enterprises for candidate calling enterprise a. D is the service demand level. S is S _i Is the similarity of the similar enterprise i and the candidate calling enterprise a. M is M _i Is the revenue distance of the similar enterprise i from the candidate calling enterprise a. N (N) _i Is the service distance of the similar enterprise i from the candidate calling enterprise a. The similarity may be determined based on a vector distance between the basic feature vector a1 of the candidate calling enterprise a and the basic feature vector of the similar enterprise, where the greater the vector distance, the smaller the similarity. It should be appreciated that the ratio of revenue distance to service distance may reflect the revenue that may be generated for an enterprise per unit of increase in service. The larger the ratio, the more necessary it is to purchase the service for the candidate call enterprise a, i.e., the greater the service demand of the candidate call enterprise a.

In some embodiments, the management module may determine a sub-graph corresponding to each candidate calling enterprise from the enterprise association graph based on enterprise information of each candidate calling enterprise, and determine a service demand level for each candidate calling enterprise based on the sub-graph. For more explanation of determining service desirability based on enterprise association graphs, see FIG. 4 and its associated description.

Step 330, determining a preferred call enterprise list based on the service demand level.

In some embodiments, the management module may select all candidate call enterprises having a service demand greater than the service demand threshold as preferred call enterprises and group the preferred call enterprises into a list of preferred call enterprises. The service demand threshold refers to the lowest service demand level at which an enterprise can accept a service. The service demand threshold may be a human experience value, a system default value, etc., or any combination thereof. For example, the management module may preset the service requirement threshold to 6.5. The candidate calling enterprises comprise E, F, G, the service demand degrees of which are 8.2, 4.4 and 6.8 respectively, and the management module can determine that enterprises E and G with the service demand degrees greater than the service demand threshold are preferred calling enterprises to form a list of preferred calling enterprises.

In some embodiments, the management module may select a predetermined number of candidate call enterprises in order of the service demand level from the largest service demand level among all candidate call enterprises. The preset number can be an empirical value or a system default value, or can be set according to actual conditions. For example, the candidate call enterprises include A, B, C, D, E, F with service demands of 6.3, 5.7, 7.9, 8.2, 4.4, respectively. The management module may set the preset number to be 3, and then the management module may determine that the candidate calling enterprises A, D and E with the first three service demands are preferred calling enterprises, and form a preferred calling enterprise list.

In some embodiments, the number of preferred call enterprises in the list of preferred call enterprises needs to be limited to within a maximum number. In some embodiments, the maximum number may be determined based on the incoming load condition.

The incoming load condition may refer to an agent occupancy condition in response to an incoming request. In some embodiments, the incoming load condition may be described in terms of classifications, numerical values, and the like. By way of classification, incoming load conditions may be described as "idle", "moderate", "busy". Taking the numerical example, the incoming load situation may be expressed as a certain value in the range of 0-100%. Accordingly, the higher the value corresponding to the incoming load condition, the more busy each agent.

In some embodiments, the management module may determine the incoming load condition based on information related to the incoming call dispatch. Specifically, the management module may determine the incoming call load condition according to statistics of the incoming call dispatch. The statistics may include statistics of the number of calls currently accessed per minute, occupancy of the agents currently occupied by incoming calls, and the like. Taking the number of calls accessed per minute as an example, the management module may determine, according to a preset numerical range in which the number of calls accessed per minute is located, an incoming call load condition corresponding to the preset range. For example, when the number of calls accessed per minute is 0-5, the corresponding incoming call load condition is idle; when the number of calls accessed per minute is 5-10, the incoming call load condition is moderate; when the number of calls per minute is greater than 10, the incoming load situation is busy.

In some embodiments, the management module may employ various data analysis algorithms to determine the maximum number based on the incoming load condition. For example, the management module may preset a correspondence relationship between the incoming load situation and the maximum number, for example, when the incoming load situation is "idle", the maximum number may be 20. When the incoming load situation is "moderate", the maximum number may be 15. When the incoming load situation is "busy", the maximum number may be 10. It should be appreciated that the more heavily the incoming load situation, the less the maximum number of preferred call enterprises.

According to the method disclosed by some embodiments of the present disclosure, the incoming load condition of each agent is used as a basis to limit the number of preferred calling enterprises, so that the situation that the agent cannot respond to an incoming request due to too busy execution of outgoing call is avoided, outgoing and outgoing loads are balanced, the scheduling efficiency of a call center is further improved, and the normal operation of incoming and outgoing calls is ensured.

According to the method, the preferred calling enterprise list needing service is determined by determining the service demand degree, so that the problem that enterprises with lower service demand degree spend more time and cost is avoided, and the calling success rate and the calling dispatching efficiency are improved.

In some embodiments, the enterprise big data further includes an enterprise association graph. The management module can determine a sub-graph corresponding to each candidate calling enterprise from the enterprise association graph based on enterprise information of each candidate calling enterprise; and determining the service demand degree of each candidate calling enterprise based on the sub-map.

The enterprise association graph is a data structure graph consisting of nodes and edges. Wherein the edges connect nodes, the nodes and edges may have features. In some embodiments, the enterprise association graph may determine nodes and edges of the enterprise association graph based on the respective enterprises within the preset area and relationships (e.g., partnerships, competing relationships, etc.) of the respective enterprises.

Fig. 4a is an exemplary schematic diagram of an enterprise association graph as illustrated in accordance with some embodiments of the present description.

In some embodiments, the nodes may correspond to respective enterprises within a preset area. As shown in fig. 4a, node a in the enterprise association graph may correspond to enterprise a, node B may correspond to enterprise B, … …, and so on, node K may correspond to enterprise K.

The node characteristics may reflect relevant characteristics of the enterprise to which the node corresponds. In some implementations, the node characteristics may include enterprise information. For more description of enterprise information, see fig. 2 and its associated description.

In some embodiments, edges may correspond to relationships that exist between enterprises. And when the relationship exists between the enterprises corresponding to the two nodes, connecting the enterprises into edges.

The edge features may reflect related features of the relationship between two enterprises corresponding to the two connected nodes.

In some embodiments, the edge feature may include a relationship type between two enterprises. Relationship types may include cooperative relationships and competing relationships. Wherein the partnership may include an upstream supply relationship, a downstream sales relationship, and the like.

In some embodiments, the edge features may include partnership dependencies. The partnership dependencies are edge features that the edges of the relationship type as partnership may have. The partnership dependencies may reflect the degree of interdependence between two enterprises having partnerships. For example, there is a raw material supply and procurement relationship between enterprise a and enterprise B. If the enterprise A only has one raw material provider for the enterprise B, the cooperation relation dependency of the enterprise A on the enterprise B is higher. But enterprise B supplies raw materials to multiple enterprises, the dependency of enterprise B on enterprise a's partnership is lower. Similarly, there is a distribution relationship.

In some embodiments, the edge feature of one edge in the enterprise association graph may represent the cooperative relationship dependency of one enterprise relative to another enterprise among the two corresponding enterprises at the same time. For example, assume that there is a cooperative relationship between enterprise a and enterprise B. As shown in FIG. 4a, the edge characteristics of the edges of node A and node B may include the partnership dependencies of enterprise A on enterprise B and the partnership dependencies of enterprise B on enterprise A.

In some embodiments, the relationship type further includes a potential partnership. A potential partnership may refer to two enterprises that may have a partnership. For example, enterprise B is a raw material provider for enterprise a, and enterprise D is the same as enterprise B's hosting business, i.e., enterprise D may also supply raw material to enterprise a, but enterprise D is not currently in collaboration with enterprise a, and thus, there is a potential collaboration relationship between enterprise D and enterprise a. In the relationship graph, nodes corresponding to the enterprise D and the enterprise A can be connected into edges, and the relationship type of the edges is potential cooperative relationship.

In some embodiments, the edge features further include potential collaboration probabilities. The potential collaboration probability is an edge feature that an edge of a relationship type that is a potential collaboration relationship may have. The potential collaboration probability may reflect a probability of potential collaboration between two enterprises.

In some embodiments, the potential collaboration probabilities may be analyzed by various dataAnd (5) determining an algorithm. For example, enterprise D and enterprise A are potential collaboration relationships, the potential collaboration probabilities of which may be based on the similarity S of the collaboration enterprise of enterprise D to enterprise A ₁ Degree of similarity S between partner enterprises of enterprise A and enterprise D ₂ Enterprise D changes the frequency P of upstream and downstream enterprises ₁ Enterprise A changes the frequency P of upstream and downstream enterprises ₂ Wait for determining, S ₁ 、S ₂ 、P ₁ 、P ₂ The larger the potential collaboration probability is.

According to the method disclosed by the embodiments of the specification, the characteristics of the edges are enriched by determining the potential cooperative relationship among enterprises, so that the relationship among the enterprises can be more comprehensively and accurately determined, and the service demand degree can be conveniently and accurately determined later.

In some embodiments, the edge features may also include a contention strength. The contention strength is an edge feature that an edge of a relationship type is a competing relationship may have. The competition strength may reflect the degree of competition between two enterprises having a competition relationship. In some embodiments, the degree of competition may be represented by the market share each of the two enterprises. For example, assume that there is a competing relationship between enterprise a and enterprise C. The market share of each of the enterprises a and C is 30% and 45%, respectively, and the competition strength can be expressed as a two-dimensional vector (30%, 45%).

The sub-graph may be part of an enterprise association graph. In some embodiments, the sub-map may be determined based on a preset maximum adjacency. The adjacency can be used to measure the degree of adjacency (or distance) of two nodes. For example, adjacency=1 indicates that two nodes are directly connected, i.e., directly connected by one edge. As shown in fig. 4a, when the connection relationship between the node a and the node B is a→b, the adjacency between a and B is 1. For another example, adjacency=2 states that two nodes are each connected to one intermediate node by one edge. As shown in fig. 4a, the connection relationship between the node a and the node C is a→b→c, and the adjacency of a and C is 2.

In some embodiments, the preset maximum adjacency may be a human experience value, a system default value, etc., or any combination thereof.

In some embodiments, the preset maximum adjacency may be determined based on an enterprise distribution vector. In some embodiments, based on the enterprise distribution vector, the more uniform the service usage of each type of enterprise, the greater the preset maximum adjacency, the more non-uniform the service usage of each type of enterprise, and the less the preset maximum adjacency. For example, for more description of determining enterprise distribution vectors, see the associated description below. The determining whether the service usage of each type of enterprise is uniform may be determined based on the degree of dispersion (e.g., variance) of the plurality of elements included in the enterprise distribution vector. The smaller the dispersion degree (e.g., variance) of the plurality of elements contained in the enterprise distribution vector, the more uniform the service usage of the various enterprises, and the larger the dispersion degree (e.g., variance) of the plurality of elements contained in the enterprise distribution vector, the more non-uniform the usage.

It should be understood that the more uniform the service usage of various enterprises, the less information the enterprise itself contains, i.e. the service requirements of the enterprise cannot be determined only by the enterprise type. When the service demand degree is predicted, more information in the enterprise association graph is required to be used, and at the moment, the larger the preset maximum adjacency degree is, the more complete the obtained sub-graph is relative to the enterprise association graph, so that the subsequent prediction is facilitated. The more uneven the service use condition of various enterprises is, the service demand degree of the enterprises can be approximately obtained by the description of the enterprise types, and the prediction is not required by using excessive information in the enterprise association map, so that the preset maximum adjacency degree can be smaller.

According to the method disclosed by some embodiments of the present disclosure, service usage uniformity of various enterprises is obtained by analyzing the enterprise distribution vector, so as to further determine whether more information in the enterprise association graph needs to be used, thereby determining the preset maximum adjacency. Compared with a complete map structure uniformly using enterprise association maps, the method reduces parameter redundancy and improves analysis speed, thereby being convenient for quickly determining the service demand of candidate calling enterprises.

In some embodiments, the sub-graph may determine, based on the preset maximum adjacency, from the nodes corresponding to the candidate call enterprises, all nodes whose adjacency is within the preset maximum adjacency and edges existing between the nodes as the sub-graph. Taking the sub-map corresponding to the candidate call enterprise a as an example, the management module may determine that the preset maximum adjacency is 2. Then, according to fig. 4a, starting from the node a corresponding to the candidate call enterprise a, the management module may use all nodes (i.e. nodes a-G) having a proximity of less than 2 to the node a and edges existing between the nodes as sub-graphs, to obtain the sub-graph corresponding to the candidate call enterprise a as shown in fig. 4 b.

The management module may determine a service desirability for each candidate call enterprise based on the sub-graph.

In some embodiments, the management module may determine the service demand level for each candidate call enterprise through a service demand level determination model based on the sub-graph. The service demand level determination model is a machine learning model.

In some embodiments, the service demand level determination model is a graph neural network model (Graph Neural Network, GNN). The service demand level determination model may be used to analyze the sub-maps to determine the service demand level for each candidate call enterprise. The input of the service demand degree determination model can be a sub-graph corresponding to the candidate calling enterprise, and the output can be the service demand degree of the candidate calling enterprise, wherein the graph neural network model can output the service demand degree of each node corresponding to the enterprise through the nodes. And outputting the corresponding nodes of the candidate calling enterprises to obtain the service demand degree of the candidate calling enterprises.

In some embodiments, the parameters of the service demand determination model may be derived through training. The management module may train the initial service demand determination model based on sets of labeled first training samples, each of which may include a sample sub-graph determined based on the sample enterprise. The labels of each set of first training samples may be actual service demands of the sample enterprise. Inputting a first training sample with a label into an initial service demand degree determining model, updating parameters of the initial service demand degree determining model through training, and obtaining a trained service demand degree determining model after training is finished when the trained model meets preset conditions.

In some embodiments, the input of the service demand level determination model may further include an enterprise distribution vector and a service distribution vector in addition to the sub-maps corresponding to the candidate call enterprises that were input. The service demand degree determination model may analyze the sub-map, the enterprise distribution vector, and the service distribution vector corresponding to the candidate call enterprises, and determine the service demand degree of each candidate call enterprise. For more description of enterprise distribution vectors and service distribution vectors, see the relevant description below.

Accordingly, the first training samples may also include a sample enterprise distribution vector and a sample service distribution vector.

According to the method disclosed by some embodiments of the present disclosure, the enterprise distribution vector and the service distribution vector can be combined based on the sub-graph, and analysis can be performed through a model, so that the service demand degree can be more quickly and accurately determined.

According to the method disclosed by the embodiments of the present disclosure, the enterprise big data is integrated through the enterprise association graph, so that the service demand level is predicted more rapidly and accurately under the condition that the data volume of the enterprise big data is huge, so that a more suitable preferable calling enterprise list can be determined later.

In some embodiments, the management module may assign the preferred call enterprises and their service recommendation sequences in the preferred call enterprise list to agents.

The service recommendation sequence refers to a sequence of services to be recommended to an enterprise. In some embodiments, the service recommendation sequence may include a sequence of one or more services including one or more of at least one quality control certificate, at least one management advisory, at least one project declaration. Illustratively, the service recommendation sequence for preferred call enterprise A is (v ₁ ，v ₂ ，v ₃ ，...）。v ₁ ，v ₂ ，v ₃ ,. different services can be represented separately, e.g. v ₁ ，v ₂ ，v ₃ The method can respectively represent quality control authentication, management consultation and project declaration. Agents may be calling the preferred calling enterpriseIn A, according to v in service recommendation sequence ₁ ，v ₂ ，v ₃ ,. the order of (e.g., quality control certification, management consultation, project reporting) recommends services to the enterprise.

In some embodiments, the service recommendation sequence may be determined based on the enterprise distribution vector and the service distribution vector.

An enterprise distribution vector refers to a vector reflecting the service conditions of different enterprises. The enterprise distribution vector may be illustratively represented in table 2.

In some embodiments, the enterprise classification in table 2 may select a corresponding classification criterion to classify the enterprise according to the actual requirement. For example, according to legal classification, a class I enterprise may be a joint venture enterprise, a class II enterprise may be a sole venture enterprise, and a class III enterprise may be a corporate enterprise. For another example, depending on the direction of operation, a type I enterprise may be a first industry-related enterprise, a type II enterprise may be a second industry-related enterprise, and a type III enterprise may be a third industry-related enterprise.

The service distribution vector is a vector that reflects the applied and owned services of different services. The service distribution vector may be exemplarily represented in the form of table 3:

In some embodiments, the management module may sort the services according to the second preset rule based on the enterprise distribution vector and/or the service distribution vector, and determine the sorted services as the service recommendation sequence. The second preset rule may be set based on experience or actual demand. For example, the second preset rule may be to sort the services in order of number from large to small according to the service distribution vector, the number of annual applications therein and/or the total number of businesses currently owning the service. For another example, the second preset rule may be to determine, according to the enterprise distribution vector, to which type of enterprise a preferred calling enterprise belongs in the enterprise distribution vector, and in service usage cases of the type of enterprise, order services according to service usage cases, for example, prioritize service with a plurality of historical purchases and applications in front. For another example, the second preset rule may also integrate the two sorting modes to sort the services together.

In some embodiments, the management module may further randomly generate a plurality of candidate service recommendation sequences based on the enterprise distribution vector and one or more services included in the service distribution vector, and determine the estimated call time of the preferred call enterprise through the call time estimation model based on the enterprise information, the candidate service recommendation sequences, the enterprise distribution vector, and the service distribution vector of the preferred call enterprise. The estimated call time refers to the estimated time to complete a call with the enterprise.

In some embodiments, the talk time estimation model is a machine learning model. The estimated talk time model may be used to analyze enterprise information, candidate service recommendation sequences, enterprise distribution vectors, and service distribution vectors for the preferred call enterprise to determine estimated talk time for the preferred call enterprise. The talk time estimation model may be a combination of one or more of a convolutional neural network model, a deep neural network model, and the like.

As shown in fig. 5, inputs to the talk time estimation model 550 may be enterprise information 510, candidate service recommendation sequences 520, enterprise distribution vectors 530, and service distribution vectors 540 for the preferred call enterprise, and outputs may be estimated talk time 560.

In some embodiments, parameters of the talk time estimation model may be derived by training. The management module may train the initial talk time estimation model based on sets of labeled second training samples, each of which may include enterprise information for the sample enterprise, sample candidate service recommendation sequences, sample enterprise distribution vectors, and sample service distribution vectors. The labels of each set of second training samples may be the actual talk time of the agent to the sample enterprise. And inputting a second training sample with a label into the initial talk time estimation model, and training the initial talk time estimation model. For further description of the subsequent training means, reference may be made to the foregoing description of training of the initial service demand determination model.

In some embodiments, the management module may use the candidate service recommendation sequence with the longest estimated talk time as the service recommendation sequence for the preferred calling enterprise. It should be appreciated that the longer the estimated talk time, the more willing the preferred calling enterprise to learn or purchase the relevant service, and therefore the best is the recommendation of the candidate service recommendation sequence with the longest estimated talk time.

According to some embodiments of the present disclosure, the estimated call time of the preferred call enterprise is determined through the call time estimated model, so that the purchase intention of the enterprise for the related service is determined, and an accurate and reasonable basis is provided for determining the optimal service recommendation sequence.

In some cases, the preferred call enterprise list has a plurality of preferred call enterprises, and if each preferred call enterprise selects the candidate service recommendation sequence with the longest estimated talk time as the service recommendation sequence, the call may occupy a considerable seat resource in a future time. If there is a new incoming call request in the future, there will be insufficient agent answer response. Based on this, the load constraint needs to be satisfied when calling the service recommendation sequence of the enterprise. In some embodiments, the load constraint may include that the sum of the estimated call times of the preferred call enterprises in the list of preferred call enterprises need to be less than a preset outgoing load threshold.

The preset outgoing load threshold refers to the longest talk time for the agent to maintain incoming and outgoing call balance. In some embodiments, the preset outgoing load threshold may be determined based on incoming load conditions for current and future periods of time. The incoming call load condition in a future period of time can be determined by various data modes such as establishing a corresponding relation, establishing a model and/or manual experience. For example, the management module may generate a correspondence of the historical time and the corresponding historical incoming load condition in advance based on the historical time and the corresponding historical incoming load condition. Accordingly, the management module may determine, based on the current time and the correspondence, a historical incoming call load condition corresponding to a historical time that is the same as or similar to the future time as an incoming call load condition in the future time. For more explanation of the incoming load situation, see the relevant description in step 330 of fig. 3, previously described.

In some embodiments, the management module may set a preset outgoing load threshold corresponding to an incoming load condition in advance according to the incoming load condition for a current and future period of time. The preset exhalation load threshold may be a historical empirical value, a system default value, or the like. For example, when the incoming load condition is idle, the preset outgoing load threshold is 15 minutes, when the incoming load condition is moderate, the preset outgoing load threshold is 10 minutes, and when the incoming load condition is busy, the preset outgoing load threshold is 5 minutes. It should be appreciated that the more busy the incoming load condition, the smaller the preset outgoing load threshold.

In some embodiments, if the sum of estimated call times of the service recommendation sequences corresponding to the preferred call enterprises in the preferred call enterprise list is greater than the preset outgoing load threshold, the management module may prioritize the service recommendation sequences of a portion of the preferred call enterprises in the preferred call enterprise list, change the determined longest estimated call time from the determined longest estimated call time to the candidate service recommendation sequence corresponding to the next longest estimated call time, and so on until the sum of estimated call times of the preferred call enterprises is just less than the preset outgoing load threshold. Wherein a portion of the preferred call enterprises may be determined at random by the system or based on enterprise size (e.g., smaller enterprise size).

In some embodiments, the candidate service recommendation sequences for each preferred call enterprise in the list of preferred call enterprises are arranged by the estimated length of talk time, which may be exemplarily shown in table 4:

assume that a certain preferred call enterprise list includes preferred call enterprises 1-3 as shown in table 4. When V is ₁₁ 、V ₁₂ 、V ₁₃ When the sum of the corresponding estimated call time is greater than the load threshold, changing the service recommendation sequence of one of the preferred calling enterprises into a candidate service recommendation sequence corresponding to the next-long estimated call time, wherein three schemes can be selected at this time: scheme one: v (V) ₂₁ 、V ₁₂ 、V ₁₃ Scheme II: v (V) ₁₁ 、V ₂₂ 、V ₁₃ Scheme III: v (V) ₁₁ 、V ₁₂ 、V ₂₃ . It is assumed that among the three enterprises, the enterprise scale is, in order from large to small, the preferred call enterprise 3, the preferred call enterprise 1, and the preferred call enterprise 2. The management module can select an enterprise with the smallest enterprise scale to change, and then select a scheme II to calculate, and determine whether the estimated call time of each candidate service sequence of the scheme meets the condition of being smaller than the preset calling load threshold. If the scheme II does not meet the conditions, changing the service recommendation sequence of the preferred calling enterprise 1 with the small enterprise scale to obtain a scheme IV: v (V) ₂₁ 、V ₂₂ 、V ₁₃ . If the fourth scheme still does not meet the condition, continuing to change the service recommendation sequence of the preferred call enterprise 3, and obtaining a fifth scheme: v (V) ₂₁ 、V ₂₂ 、V ₂₃ … … and so on until a certain solution meets the condition, the solution is determined as the service recommendation list corresponding to the current preferred call enterprise list.

According to the method, when the candidate service recommendation sequence is determined according to the estimated call time, the incoming load conditions in the current and future certain time are fully considered, so that a more suitable service recommendation sequence is determined, and the load balance of incoming and outgoing calls is ensured.

According to the method, the calling dispatching is further optimized, and the calling success rate is improved maximally by determining the proper service recommendation sequence and distributing the service recommendation sequence to the agents.

One or more embodiments of the present disclosure provide an intelligent gas valve station pressure regulating optimizing apparatus based on the internet of things, which includes a processor, where the processor is configured to execute any one of the big data-based artificial intelligence calling methods provided in the embodiments of the present disclosure.

The embodiments of the present disclosure also provide a computer readable storage medium storing computer instructions that when read by a computer in the storage medium, the computer operates any of the big data based artificial intelligence calling methods as provided in the embodiments of the present disclosure.

While the basic concepts have been described above, it will be apparent to those skilled in the art that the foregoing detailed disclosure is by way of example only and is not intended to be limiting. Although not explicitly described herein, various modifications, improvements, and adaptations to the present disclosure may occur to one skilled in the art. Such modifications, improvements, and modifications are intended to be suggested within this specification, and therefore, such modifications, improvements, and modifications are intended to be included within the spirit and scope of the exemplary embodiments of the present invention.

Meanwhile, the specification uses specific words to describe the embodiments of the specification. Reference to "one embodiment," "an embodiment," and/or "some embodiments" means that a particular feature, structure, or characteristic is associated with at least one embodiment of the present description. Thus, it should be emphasized and should be appreciated that two or more references to "an embodiment" or "one embodiment" or "an alternative embodiment" in various positions in this specification are not necessarily referring to the same embodiment. Furthermore, certain features, structures, or characteristics of one or more embodiments of the present description may be combined as suitable.

Furthermore, the order in which the elements and sequences are processed, the use of numerical letters, or other designations in the description are not intended to limit the order in which the processes and methods of the description are performed unless explicitly recited in the claims. While certain presently useful inventive embodiments have been discussed in the foregoing disclosure, by way of various examples, it is to be understood that such details are merely illustrative and that the appended claims are not limited to the disclosed embodiments, but, on the contrary, are intended to cover all modifications and equivalent arrangements included within the spirit and scope of the embodiments of the present disclosure. For example, while the system components described above may be implemented by hardware devices, they may also be implemented solely by software solutions, such as installing the described system on an existing server or mobile device.

Likewise, it should be noted that in order to simplify the presentation disclosed in this specification and thereby aid in understanding one or more inventive embodiments, various features are sometimes grouped together in a single embodiment, figure, or description thereof. This method of disclosure, however, is not intended to imply that more features than are presented in the claims are required for the present description. Indeed, less than all of the features of a single embodiment disclosed above.

In some embodiments, numbers describing the components, number of attributes are used, it being understood that such numbers being used in the description of embodiments are modified in some examples by the modifier "about," approximately, "or" substantially. Unless otherwise indicated, "about," "approximately," or "substantially" indicate that the number allows for a 20% variation. Accordingly, in some embodiments, numerical parameters set forth in the specification and claims are approximations that may vary depending upon the desired properties sought to be obtained by the individual embodiments. In some embodiments, the numerical parameters should take into account the specified significant digits and employ a method for preserving the general number of digits. Although the numerical ranges and parameters set forth herein are approximations that may be employed in some embodiments to confirm the breadth of the range, in particular embodiments, the setting of such numerical values is as precise as possible.

Each patent, patent application publication, and other material, such as articles, books, specifications, publications, documents, etc., referred to in this specification is incorporated herein by reference in its entirety. Except for application history documents that are inconsistent or conflicting with the content of this specification, documents that are currently or later attached to this specification in which the broadest scope of the claims to this specification is limited are also. It is noted that, if the description, definition, and/or use of a term in an attached material in this specification does not conform to or conflict with what is described in this specification, the description, definition, and/or use of the term in this specification controls.

Finally, it should be understood that the embodiments described in this specification are merely illustrative of the principles of the embodiments of this specification. Other variations are possible within the scope of this description. Thus, by way of example, and not limitation, alternative configurations of embodiments of the present specification may be considered as consistent with the teachings of the present specification. Accordingly, the embodiments of the present specification are not limited to only the embodiments explicitly described and depicted in the present specification.

Claims

1. An artificial intelligent calling system based on big data comprises an incoming call dispatching module, an outgoing call dispatching module, a big data module and a management module, and is characterized in that,

The incoming call scheduling module is configured to execute incoming call scheduling and count related information of the incoming call scheduling, where the incoming call scheduling includes: in response to receiving a new incoming call request, assigning the incoming call request to an agent;

the outgoing call scheduling module is configured to execute outgoing call scheduling, where the outgoing call scheduling includes: assigning at least a preferred call enterprise in a list of preferred call enterprises to the agent;

the big data module is used for constructing data of one or more dimensions which can be processed by the management module;

the management module is at least used for:

controlling the big data module to acquire original data from one or more heterogeneous data channels to obtain multi-source heterogeneous data, wherein the multi-source heterogeneous data comprises at least one type of data, and the multi-source heterogeneous data contains enterprise information in a preset area;

based on the multi-source heterogeneous data, establishing enterprise big data by a preset method, wherein the enterprise big data at least comprises an enterprise information database;

determining at least one candidate calling enterprise through pre-screening conditions based on the enterprise big data;

determining the preferred call enterprise list based on the at least one candidate call enterprise, the preferred call enterprise list including one or more of the preferred call enterprises; and

And controlling the outgoing call scheduling module to execute the outgoing call scheduling based on the preferred call enterprise list.

2. The big data based artificial intelligence call system of claim 1, wherein the management module is further to:

acquiring enterprise information of each candidate calling enterprise from the enterprise information database;

determining the service demand degree of each candidate calling enterprise based on the enterprise information; and

and determining the preferred call enterprise list based on the service demand level.

3. The big data based artificial intelligence call system of claim 2, wherein the enterprise big data further comprises an enterprise association graph,

the management module is further to:

determining a sub-graph corresponding to each candidate calling enterprise from the enterprise association graph based on the enterprise information of each candidate calling enterprise; and

and determining the service demand degree of each candidate calling enterprise based on the sub-graph.

4. The big data based artificial intelligence call system of claim 1,

the outgoing call schedule further includes: and allocating a preferred calling enterprise and a service recommendation sequence thereof in a preferred calling enterprise list to the agent, wherein the service recommendation sequence is determined based on an enterprise distribution vector and a service distribution vector, the enterprise distribution vector and the service distribution vector are determined based on the enterprise big data, the service recommendation sequence comprises a sequence of one or more services, and the one or more services comprise one or more of at least one quality control authentication, at least one management consultation and at least one item declaration.

5. A big data based artificial intelligence calling method, the method being implemented by the big data based artificial intelligence calling system of any of claims 1-4, wherein the big data based construction optimization system includes an incoming call dispatch module, an outgoing call dispatch module, a big data module, and a management module, the method being performed by the management module, the method comprising:

controlling the outgoing call scheduling module to execute outgoing call scheduling based on the preferred call enterprise list, wherein the outgoing call scheduling comprises: at least the preferred call enterprises in the list of preferred call enterprises are assigned to the agent.

6. The big data based artificial intelligence call method of claim 5, wherein the determining the list of preferred call enterprises based on the at least one candidate call enterprise comprises:

7. The artificial intelligence call method based on big data according to claim 6, wherein the enterprise big data further comprises an enterprise association graph,

the determining, based on the business information, a service requirement level of each of the candidate call businesses includes:

8. The artificial intelligence call method based on big data according to claim 5,

9. An artificial intelligence calling device based on big data, comprising a processor, wherein the processor is configured to execute the artificial intelligence calling method based on big data according to any of claims 5 to 8.

10. A computer readable storage medium storing computer instructions, wherein when the computer reads the computer instructions in the storage medium, the computer performs the big data based artificial intelligence calling method according to any of claims 5 to 8.