Method and apparatus for intelligent distribution of email enhanced by constrained model

Abstract

The application discloses a kind of restricted model enhanced public mail intelligent distribution method and device.The method analyzes enterprise public mail or system mailbox received mail, generates standardized mail features;Based on forwarding rule base, enterprise knowledge base and historical processing record, generate verifiable candidate routing set;Candidate set, rule hit result and knowledge base recall result are input into restricted large language model, so that it only outputs mail label, candidate handler and semantic confidence within verifiable range;Then, rule intensity, knowledge base correlation, conversation consistency, permission verification and risk penalty are combined to calculate routing score and confidence.Satisfy automatic sending condition, the system reconstructs and forwards mail with the identity of agent;Generate prompt mail under abnormal or low confidence condition and enter the correction closed loop.The scheme improves the efficiency, accuracy and traceability of public mail distribution.

Description

Technical Field

[0001] This invention relates to the fields of email processing, natural language processing, knowledge base retrieval, enterprise process automation, privacy protection, and information security, and particularly to a constrained model-enhanced intelligent public email distribution method and apparatus. Background Technology

[0002] Enterprises typically use a corporate email address as a unified external communication channel in scenarios such as customer service, supplier collaboration, payroll delivery, regional operations, shared human resources services, and project delivery. After external customers, suppliers, employees, or system platforms send emails to the corporate email address, internal personnel need to determine who should handle the email based on the customer name, country / region, business type, division of responsibilities, email subject, body meaning, attachment content, and historical conversation context.

[0003] Current enterprise email processing methods typically rely on multiple people sharing email accounts, manual email claiming, or simple keyword forwarding rules. Multiple shared accounts allow internal personnel to view all emails and attachments in the public email account, hindering minimum access control. Manual email claiming requires repeatedly searching for customer information, business managers, and historical emails, resulting in low efficiency and a high risk of missed or incorrect forwarding. Simple rule-based forwarding systems heavily rely on fixed keywords or sender configurations; when customer names have aliases, sender email addresses change, the body of the email uses natural language descriptions, or attachments contain key information, traditional rules struggle to reliably identify the true handler.

[0004] For emails related to global hiring, payroll, multinational services, and customer operations, these emails often contain personal information, payroll sheets, contracts, employee lists, client project numbers, and historical referencing links. If internal staff directly log into the public email system, it can easily lead to expanded privileges; if the original email is simply forwarded to internal staff, external clients may see the internal staff's real email address, CC relationships, or system processing traces in subsequent replies. Existing systems typically lack a unified mechanism for proxy identity forwarding and referencing link rewriting, making it difficult to simultaneously achieve automation efficiency, client-side session continuity, and internal privacy isolation.

[0005] As large language models are introduced into enterprise workflow processing, these models can understand email semantics and multilingual expressions. However, directly using model output as the basis for sending emails presents problems such as illusion, unauthorized selection, lack of interpretability, and lack of auditability. Simply using artificial intelligence to determine email categories or recommend handlers can easily lead to technical risks such as unverifiable model outputs, untraceable results, and unauthorized routing. Therefore, a technical solution is needed that combines rules, knowledge bases, model semantic judgment, permission verification, and manual correction in a closed loop, ensuring that model output is constrained by candidate sets, structured templates, and audit links.

[0006] Current email automation solutions generally lack sustainable improvement mechanisms. When a manual correction of an erroneous forwarding occurs, the system often only re-forwards the current email without updating the correction results as auditable rules, knowledge base entries, or model parameters. As a result, errors involving the same customer alias, country / region, or business contact person may occur repeatedly, impacting the system's long-term accuracy.

[0007] Therefore, it is necessary to provide an intelligent distribution solution for enterprise public emails, which can achieve accurate, secure, auditable and continuously optimized processing of public emails through standardized feature parsing, rule matching, knowledge base retrieval, limited semantic judgment of large language models, integrated route scoring, proxy identity email reconstruction, anomaly review and error correction learning. Summary of the Invention

[0008] The purpose of this invention is to provide a constrained model-enhanced intelligent public mail distribution method and apparatus to address the shortcomings in the prior art.

[0009] To achieve the above objectives, the present invention provides the following technical solution: a restricted large language model and knowledge base-enhanced intelligent distribution method for enterprise public emails, characterized in that it includes acquiring pending emails received by the enterprise public email or system mailbox, and parsing the email header, body, attachments, historical citations, recipients, CC recipients, sender domain, email source type, and session link identifier of the pending emails to generate standardized email features; based on the standardized email features, calling a preset forwarding rule base, an internal enterprise knowledge base, and historical email processing records to generate a verifiable candidate route set containing at least one candidate processor; inputting the standardized email features, rule hit results, knowledge base recall results, candidate processor set, prohibited output list, and structured output template into a large language model, so that the large language model outputs only the email tag set and candidate processors from the verifiable candidate route set, the responsible person table, or the knowledge base recall results. The system calculates the fusion route score for each candidate processor based on the rule hit strength, knowledge base relevance, semantic confidence, session consistency, processor availability, and anomaly risk penalty. It then calculates the route confidence based on the fusion route score. When the route confidence is greater than or equal to the automatic sending threshold, it reconstructs the email header, body, attachments, citation header, and display identity using the system email or corporate email as a proxy, based on the target processor and the session link identifier. The reconstructed email is then sent to the target processor or an external sender. When the target processor is not identified, there is an identification conflict, parsing failure, sending failure, unverifiable model output, failed permission verification, or manual correction, an anomaly handling record and correction loop record are generated, and subsequent routing parameters are updated based on the manual correction results.

[0010] Normalized email features include at least the sender's email address vector, recipient's email address vector, CC recipient's email address vector, sender's domain name, subject semantic vector, body semantic vector, attachment summary vector, historical citation summary vector, candidate customer name, candidate region or country, candidate business person in charge, sensitive information marker, email source type, session link identifier, and agent identity status. Among these features, case-insensitive normalization processing is performed on email addresses, domain names, subject keywords, body keywords, and rule conditions.

[0011] The email header includes From, To, Cc, Bcc, Reply-To, Message-ID, In-Reply-To, References, Date, Subject, and custom header fields; the historical references identify the boundary between the current body and the historical body through the reference separator, email client markup, Message-ID link, and body similarity.

[0012] Each rule in the preset forwarding rule base includes a rule name, rule code, activation status, sorting field, judgment field, judgment method, matching value, execution action, action parameters, post-execution control field, rule weight, and manual priority field; the judgment field includes at least one of the following: sender, recipient, CC recipient, sender domain name, subject, body, subject or body, attachment name, customer name, region or country, business type, and sensitivity level.

[0013] The process of calling the preset forwarding rule library includes: reading the rules with enabled status in ascending order of sorting fields; when the judgment method is to meet all conditions, executing the corresponding action if all judgment fields match; when the judgment method is to meet any condition, executing the corresponding action if at least one judgment field matches; when the action is to mark a tag, assigning a value to at least one tag among customer name, region or country, business responsible person type, and risk level; when the action is to forward directly, writing the handler corresponding to the action parameter into the verifiable candidate route set; and determining whether to continue matching, stop matching, cancel forwarding by tag, or force manual review based on the control fields after execution.

[0014] The enterprise internal knowledge base includes at least one of the following: customer master data, customer alias database, region or country mapping table, business responsible person table, external employee email mapping table, service item configuration, historical forwarding log, historical correction record, email template, exception handling strategy, permission configuration, and sensitive field dictionary. The enterprise internal knowledge base is stored in the form of relational database, full-text index, vector index, graph database, or a combination thereof.

[0015] Knowledge base retrieval employs a hybrid approach combining vector similarity, full-text search, exact field matching, customer alias expansion, and business graph adjacency expansion. ,in For email retrieval, For each knowledge item, E is the embedding function, graph is the graph adjacency relevance, field is the structured field hit rate, and α, μ, and ν are configurable weights.

[0016] Semantic judgment using a large language model includes: inputting the email subject, body summary, attachment summary, historical citation summary, rule hit results, Top-K knowledge base recall results, candidate handler set, prohibited output list, and structured output template into the prompt template; constraining the large language model to select the target handler only from the candidate route set, the responsible person table, or the knowledge base recall results; outputting a structured result including customer name, region or country, business responsible person type, target handler, CC recipients, email type, basis summary, sensitivity level, and semantic confidence; when the output target handler is not in the verifiable set, the output is downgraded to a low-confidence suggestion and not sent directly.

[0017] Converged routing score Determine according to the following formula: Where j represents the j-th candidate processor, This represents the rule weight of the i-th rule. Let represent the hit function of the i-th rule for email m. This indicates that the i-th rule points to the action mapping of candidate processor j. This represents the semantic confidence of the large language model for candidate processor j. Representing knowledge entries The correlation strength with candidate processor j Indicates a session consistency item. Indicates the availability of the processor. Indicates an abnormal risk item. to Configurable weights.

[0018] The route confidence C is calculated based on the fused route score of the candidate processor. ,in and These represent the highest and second-highest scores, respectively, and τ represents the temperature coefficient. ρ represents the entropy of the probability distribution P of the candidate processor, N represents the number of candidate processors, ρ represents the risk coefficient caused by parsing anomalies, attachment anomalies, rule conflicts, knowledge base conflicts, or unverifiable model outputs, and A represents the pass rate of permission verification. When C is greater than or equal to the automatic sending threshold, it is sent automatically. When C is within the manual review threshold range, it is sent to the person in charge of the public email for confirmation. When C is lower than the manual review threshold, it enters the anomaly handling process.

[0019] The email reconstruction process includes: after an external sender sends an email to the corporate email address and the target handler is identified, the email is reconstructed as an email sent from the system email address to the internal target handler; after the internal target handler replies to the system email address, the reply email is reconstructed as an email sent from the corporate email address to the external sender; during the reconstruction process, the original email subject, body, attachments, and necessary references are preserved, and the session link identifier, original Message-ID, routing log number, and tag summary are written, and the sender, recipient, CC, and proxy email display information in the historical references are rewritten to ensure consistency.

[0020] When the target handler is not identified, there is an identification conflict, parsing fails, sending fails, or permission verification fails, an alert email or an error message email is generated. When the target handler is not identified or there is an identification conflict, the original email is exported as an EML attachment, and an alert email containing an alert identifier, attachment identifier, candidate tags, candidate handler, fusion scoring summary, knowledge base basis summary, correction instruction template, and session link identifier is generated and sent to the public email manager. When parsing fails or sending fails, the original email, error context, failure reason, number of retries, and system log number are sent to the technical manager.

[0021] The correction instruction template adopts the format ***{key:value; key:value}***, where the key must include at least one of clientName, country, businessResponsibilityType, recipient, ccList, mailType, and riskLevel, and the key is case-insensitive. When parsing correction emails, the system only parses the content inside ***{...}***, ignoring the text outside the instruction, and supports fault-tolerant parsing with spaces, newlines, blank lines, semicolons, non-fixed key order, duplicate keys, missing keys, and empty values.

[0022] Updating subsequent routing parameters based on manual correction results includes: using the manually corrected target handler as a supervision label to update rule weights, knowledge base association weights, and fusion model weights; when the same customer name, region, or business responsible person is corrected to the same result multiple times consecutively, candidate knowledge base entries or candidate forwarding rules are generated and entered into the manual review queue. After the review is passed, they are written into the customer alias database, external employee email mapping table, or business responsible person table.

[0023] The weights of the fusion model are updated using an online update formula. ΠΩ ∇θ ,in , β is the learning rate, and β is the regularization coefficient. For multi-rule conflict penalty terms, ΠΩ is the projection operator used to ensure that the updated weights satisfy the constraints of non-negativity, upper bound, and that artificial high-priority rules are not covered by the model.

[0024] For each individual email, an email forwarding log is generated. The email forwarding log includes the email log number, public email number, system email number, original sender, proxy sender, target recipient, CC recipient, email tag, hit rule, knowledge base entry, model output summary, fusion route score, route confidence, sending date, sending status, anomaly type, corrected link number, permission verification result, and sensitive information de-identification status.

[0025] External email addresses, employee names, salary fields, contract fields, ID document fields, bank account fields, attachment names, sensitive customer fields, and models in the logs are anonymized at the field level based on the summary; for authorization codes, email passwords, API keys, and tokens, only the encrypted ciphertext or masked display values ​​are saved; log query permissions are controlled according to public email, customer, region, department, role, and operation type.

[0026] For each automatic sending or manual review, a routing evidence package is generated. The routing evidence package includes at least a standardized email feature summary, a hit rule number, a knowledge base entry number, a set of candidate processors, a model structured output, a post-output verification result, a fused routing score, a routing confidence score, an authorization verification result, a risk item, a threshold version, a policy version, and an email log number. The routing evidence package is bound and stored with the original email hash, the reconstructed email hash, and the session link identifier.

[0027] The policy versions include the rule base version, knowledge base index version, prompt template version, threshold configuration version, permission configuration version, and de-identification policy version. When any policy version changes, the system writes the version number before and after the change, the person making the change, the approval status, the release time, and the rollback flag into the policy release log, so that the routing results of the same email at different times can be reproduced according to the corresponding policy version.

[0028] Before updating subsequent routing parameters based on manual correction results, the process also includes replaying and evaluating historical email samples in a sandbox environment. The replay evaluation includes at least the automatic sending accuracy rate, misfortune rate, manual review rate, permission interception rate, unverifiable model output rate, and average processing time. When the replay evaluation results meet the preset release conditions, the candidate rules, knowledge base entries, or weight parameters are released to the production environment; otherwise, the original strategy version remains unchanged.

[0029] Attachment processing includes security scanning, hash calculation, text extraction, table field recognition, OCR recognition, and sensitive field recognition of attachments. When attachment security scanning fails, attachment summary confidence is below the threshold, attachment contains highly sensitive fields, or attachment hash conflicts with historical records, the attachment risk is written into the risk item and automatic outgoing is prohibited or downgraded to manual review.

[0030] The beneficial effects of the present invention include at least the following: Reduce the need for shared login to corporate email accounts and lower the risk of unauthorized access to emails and attachments by internal personnel; By fusing rules, knowledge bases, and model semantic judgment, the distribution accuracy of complex natural language emails, multilingual emails, and emails with attachments can be improved. By reconstructing proxy identities and rewriting referencing links, external clients can maintain a continuous conversation with the corporate email, while internal processors only interact with the system email. Error closed-loop processing is achieved through anomaly alerts, correction instructions, and online updates; By using log auditing and field-level anonymization, we can meet the requirements of enterprise compliance management and issue tracing. Detailed Implementation

[0031] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. The described embodiments are only used to explain the present invention and should not be construed as limiting the scope of protection of the present invention. Equivalent substitutions made by those skilled in the art for module division, step order, weight parameters, threshold strategies, database types, model types, and email service interfaces without departing from the concept of the present invention should all fall within the scope of protection of the present invention.

[0032] In one embodiment, the system includes an external sender A, a corporate email address P, a system email address SYS, an internal target handler B, an email manager R, a technical manager J, a rules engine, a knowledge base retrieval engine, a large language model service, an email reconstruction service, a permission verification service, a log auditing service, and an error correction and learning service. External sender A is only aware of the corporate email address P, and internal target handler B is only aware of the system email address SYS. The system maintains the correspondence between A, P, SYS, and B through session link identifiers.

[0033] Emails awaiting processing can originate from external emails received via the company's public email address (P), internal replies from personnel (B) to the system email address (SYS), or notification emails generated by third-party business systems through an email gateway. The system first identifies the email source type to distinguish between external emails, internal replies, correction emails, technical anomaly emails, and system notification emails. Different source types correspond to different parsing and sending strategies.

[0034] During the email parsing phase, the system parses the From, To, Cc, Bcc, Reply-To, Message-ID, In-Reply-To, References, Date, Subject, and custom header fields in the email header, and extracts the email body, HTML body, attachment metadata, attachment content summary, historical citation fragments, and signature fragments. For the HTML body, the system first converts it to normalized text, then retains necessary links, table summaries, and embedded image descriptions. For historical citations, the system identifies the boundary between the current body and historical body based on common citation separators, email client tags, and Message-ID links.

[0035] The email m to be processed is parsed into normalized email features. , ,in Indicates the sender's email address. This represents a collection of recipient email addresses. Indicates the list of recipients for the copy. Indicates the sending domain. Represents the topic semantic vector. Represents the semantic vector of the main text. This represents the vector of attachment summaries. Represents a historical citation summary vector. Indicates customer name candidates, Indicates a country or region as a candidate. Indicates candidates for business responsibility. Indicates the sensitivity level. This indicates the session link identifier and the proxy identity status.

[0036] For attachments, the system extracts the filename, file size, hash value, readable text, table fields, and OCR summary based on the file type. For PDF, Word, Excel, image, and compressed file attachments, the system can respectively call the text extractor, table parser, OCR service, and security scanning service. If the attachment contains sensitive fields such as salary, ID number, bank account number, contract number, or employee list, sensitive information tags are written into the normalized features, and field-level desensitization or summary replacement is performed before subsequent model calls.

[0037] The rule engine reads a pre-defined forwarding rule library. Each rule can include a rule name, rule code, enabled status, sorting field, judgment field, judgment method, matching value, execution action, action parameters, post-execution control field, rule weight, and manual priority field. Judgment fields can include sender, sender domain, subject, body, attachment name, customer name, country / region, business type, or sensitivity level. Execution actions can include tagging customers, tagging countries, tagging business types, adding candidate handlers, adding CC recipients, requesting manual review, stopping subsequent matching, or canceling automatic forwarding.

[0038] When the judgment method requires all conditions to be met, the system requires all judgment fields to match before executing the corresponding action; when the judgment method requires any one condition to be met, execution is only required if at least one judgment field matches. To improve maintainability, rule matching supports case-insensitive matching, domain name suffix matching, wildcard matching, regular expression matching, synonym matching, and customer alias extension matching. In cases where multiple rules are matched, the system merges them according to the sorting field, human priority, and rule weight, and records the contribution of each rule to the candidate processor.

[0039] During the knowledge base retrieval phase, the system combines the email subject, body summary, attachment summary, historical citation summary, sender domain, matched tags, and candidate handlers into a search query. And retrieve the Top-K knowledge items from the enterprise's internal knowledge base. Recall can employ a hybrid approach using vector similarity, BM25 full-text search, exact field matching, customer alias expansion, and business graph adjacency expansion.

[0040] In one embodiment, the knowledge base hybrid similarity is defined as... Where E represents the text embedding function, graph represents the graph adjacency relevance between customers, regions, projects, and responsible persons, field represents the hit rate of structured fields such as sender domain name, customer number, country code, and business type, and α, μ, and ν are configurable weights.

[0041] The system inputs standardized email features, rule-hitting results, Top-K knowledge entries, candidate handler set, prohibited output list, and structured output template into the large language model. The structured output template requires the model to output fields such as clientName, country, businessResponsibilityType, recipient, ccList, mailType, riskLevel, reason, and confidence. Among these, recipient and ccList can only be selected from the candidate handler set, the responsible person table, or the knowledge base retrieval results.

[0042] To mitigate the risk of model illusion, the system performs constraint checks both before and after model invocation. Before invocation, the system does not provide the model with contact lists of people or sensitive plaintext fields that are beyond the current email access permissions. After invocation, the system checks whether the target recipient in the model's output exists in the verifiable set, whether the customer name can be associated with the customer master data or alias database, whether the country or region matches the service item configuration, and whether the output references provided email summaries or knowledge entries. If any critical field cannot be verified, the model output is downgraded to a low-confidence suggestion and is not used directly for sending.

[0043] For candidate handler j, the system calculates a fusion route score based on rule hit strength, model semantic confidence, knowledge base similarity, session consistency, handler availability, and risk penalty: Each term in this formula can be explained in the log for subsequent auditing and manual review.

[0044] Processor availability item This system is used to handle situations such as candidate resignation, leave, insufficient permissions, region mismatch, and unauthorized service items. If the candidate is unavailable, the system can... Set to a lower value or remove directly from the candidate set; if a backup person exists for the candidate processor, the system will add the backup person to the candidate set and inherit part of the knowledge base correlation.

[0045] Session consistency items Used to handle reply links. If the email to be processed is a reply from an external sender to an existing session, and the session link identifier... If the previous processor is j, then Take the higher value; if a new customer, country, or project number appears in the email referencing chain and is inconsistent with the responsibilities of the previous handler, then... Take the lower value or trigger manual confirmation. This option allows the system to maintain continuous processing within the same session while avoiding the erroneous use of the old handler when the business topic changes.

[0046] Risk items Risks include parsing anomalies, attachment anomalies, rule conflicts, knowledge base conflicts, unverifiable model output, excessively high sensitivity levels, insufficient permissions for candidate processors, external email addresses appearing in the internal copy list, and abnormal responses from the sending interface. Risk items can be stacked by risk type or selected based on the highest risk level. When a risk item exceeds a preset threshold, the system will not automatically send the email; instead, it will generate a reminder email or a technical anomaly email.

[0047] The system further calculates the route confidence. ,in and These are the highest and second-highest scores, respectively, where τ is the temperature coefficient. Let C be the entropy of the probability distribution of candidate processors, N be the number of candidate processors, ρ be the comprehensive risk coefficient, and A be the pass rate of permission verification. If C ≥ If so, the system will send it automatically; if ≤C< The system then sends the message to the person in charge of the public email account for confirmation; if C < If this occurs, the system will enter the exception handling process.

[0048] The authorization verification service is used to verify whether the target handler, CC recipients, and agent identities comply with the enterprise's access control policies before sending. Authorization verification can be based on roles, departments, regions, customers, service items, sensitivity levels, and data processing purposes. For example, if an internal handler is only authorized to handle payroll emails for Japan, the system will not allow automatic sending if the email is identified as a Singapore payroll email, even if the model and rules specify that handler.

[0049] When external sender A sends an email to the corporate email address P and the system identifies the target handler B, the system creates a new email from the system email address SYS to B. The new email retains the original email's subject, body, attachments, and necessary references, and adds a session link identifier, original Message-ID, tag summary, and forwarding log number to the email header, hidden identifier, or footer. This identifier is used by B to locate the original external session when replying to SYS later.

[0050] When B replies to SYS, the system uses the session link identifier to locate the original external sender A, the corporate email address P, historical tags, and the previous routing log, and reconstructs an email sent from P to A. This email retains the body, attachments, and necessary references of B's ​​reply, but rewrites the sender, recipient, CC, and proxy email information in the references to ensure consistency, preventing the external sender from knowing the real email address of the internal handler, while maintaining the continuity of the external session topic and References link.

[0051] If an external email needs to be distributed to multiple handlers simultaneously or includes candidate CC recipients, the system generates To and Cc sets based on the email type and responsible person configuration. For the primary handler, the system writes To; for collaborating handlers, regional managers, or project managers, the system writes Cc. If any handler replies with SYS, the system determines whether to synchronize with other internal handlers based on the session policy to prevent information gaps in multi-handler scenarios.

[0052] The proxy identity rewriting strategy also includes an external email isolation strategy. If an internal handler mistakenly adds an external customer's real email address to Cc when replying to the system email SYS, the system detects the external email address appearing in the internal reply's Cc list before sending, triggering the proxy identity check strategy. This removes the external email address from the internal Cc list and reconstructs the To and Cc sets in the email sent from the company email P to external sender A according to the original session policy, while simultaneously recording a proxy identity correction log.

[0053] When the system cannot find the target handler, there are conflicting candidate handlers, the rule lacks necessary labels, the model output is unverifiable, or the confidence level is below the threshold, the system generates an alert email and sends it to the person in charge of the public email, R. The body of the alert email includes the anomaly type, candidate labels, candidate handlers, a summary of the fusion score, a summary of the knowledge base basis, suggested handling methods, and a correction instruction template; at the same time, the original email is exported as an EML attachment with a session link identifier attached to avoid exposing complete sensitive content in the alert body.

[0054] Correction instructions use the format ***{key:value; key:value}***. The key can include clientName, country, businessResponsibilityType, recipient, ccList, mailType, and riskLevel, and is case-insensitive. When parsing correction emails, the system only parses the content within ***{...}***, ignoring other body text, signatures, and quotations; it supports error handling scenarios such as spaces, line breaks, blank lines, semicolons, variable key order, duplicate keys, missing keys, and empty values.

[0055] For correction emails sent by the public email administrator based on reminder emails, the system extracts the original EML from the attachments as the email to be redistributed, and updates the tags, target handlers, CC recipients, and risk level according to the correction instructions. For correction emails sent by the wrong recipients based on ordinary forwarding emails, the system extracts the original session link from the body citations, hidden identifiers, or attachments, and resends it according to the correction instructions. If the correction email is missing the original email attachments, the system can find a preserved copy of the original email in the logs based on the session link identifier.

[0056] If the correction email attachment is missing and the original email cannot be located from the logs, the attachment is not the original email, the instruction cannot be parsed, the instruction value cannot be matched, the target handler is not within the authorized scope, or the matching result conflicts, the system generates an exception prompt email and returns the original correction email as an attachment to the sender of the correction email, while also recording the exception log. For technical exceptions, such as email service connection failure, authentication failure, attachment parsing failure, and template rendering failure, the system sends a technical processing email to the technical lead J.

[0057] The system treats the manually corrected target processor as a supervisory signal, used to update rule weights, knowledge base association weights, and fusion model weights. Let the true label obtained after the t-th correction be... The current parameter is Then the formula can be updated online. ΠΩ ∇θ ,in .

[0058] In the above formula, Where β is the learning rate and β is the regularization coefficient. For multi-rule conflict penalties, ΠΩ is the projection operator, used to ensure that the updated weights still satisfy interpretable constraints such as non-negativity, upper bound, and that high-priority manual rules are not covered by the model. When a customer name, region, or business responsible person is corrected to the same result multiple times consecutively, the system automatically generates candidate knowledge base entries or candidate forwarding rules and enters the manual review queue; after approval, the relevant entries are written to the customer alias database, external employee email mapping table, or business responsible person table.

[0059] The system generates a forwarding log for each independent email. For example, the original email from A to P, the forwarded email from SYS to B, the internal reply email from B to SYS, and the external reply email from P to A are all recorded as independent emails. The log entry includes at least the email log number, public email number, system email number, sending date, original sender, proxy sender, target recipient, CC recipients, hit rules, tags, knowledge base document, model output summary, fused route score, confidence level, anomaly type, sending status, and correction link number.

[0060] To protect sensitive information, the system anonymizes external email addresses, employee names, salary fields, attachment names, sensitive customer fields, and models in logs based on their summaries. For sensitive configurations such as authorization codes, email passwords, API keys, and tokens, the system only displays masked characters, not plaintext. Log query permissions can be controlled by public email address, customer, region, department, role, and operation type. Log export operations require recording the exporter, export time, and export scope.

[0061] In a specific scenario, Client A sends an email with the subject "Singapore payroll amendment for May" to the company email P using hr@client-a.com, with a payroll adjustment form attached. The system parses information such as the sending domain client-a.com, "Singapore" and "payroll" in the subject, and the employee ID in the attachment summary. The rule engine matches Client A's domain rules and payroll business rules. The knowledge base recalls Client A's Singapore service project and regional payroll manager. The model outputs Client A's name, country "Singapore," and business manager type "payroll specialist." The fusion score shows that candidate processor B1 is significantly higher than B2, and although the attachment is sensitive, it parses normally. C is greater than the automatic sending threshold. The system sends a reconstructed email to B1 using SYS.

[0062] In another specific scenario, Customer B sends an email from their personal email address with the subject "Need help with invoice and employee onboarding," containing both invoice and onboarding questions in the body. The rules engine only hits the customer's alias. The knowledge base recall results show that both the finance manager and the onboarding manager are relevant, and the model outputs that the confidence scores of the two candidate handlers are close, leading to... The value is relatively small and the entropy is relatively high. The system determines that C falls within the threshold range for manual review and sends a reminder email to the person in charge of the public email, R. After R replies with ***{clientName:Client B; country:Japan;businessResponsibilityType:onboarding; recipient:onboarding.jp@example.com}***, the system resends the email and saves the correction result to Client B's historical correction record.

[0063] In another specific scenario, internal handler B mistakenly added an external client's real email address to the CC when replying to the system email SYS. Before reconstructing the email, the system detected the external email address in the Cc list of the internal reply, triggering a proxy identity check policy. This removed the external email address from the internal Cc list and reconstructed the To and Cc sets in the email sent to external sender A using the company email P, based on the original session policy. Simultaneously, a proxy identity correction log was recorded. This process prevents the external client from obtaining the internal handler's real email address and internal collaboration relationships.

[0064] In another specific scenario, Client C sent an email containing a scanned copy of a contract as an attachment, with the subject line simply stating "please review". Traditional keyword rules could not identify the business type. The system used OCR to extract the contract number, service country, and number of employees from the attachment. The knowledge base retrieved Client C's contract service projects based on the contract number. The model, combined with the attachment summary, determined that the email belonged to a contract change review, with the legal manager and client success manager as the candidate handlers. Due to the low confidence level of the attachment parsing and the high sensitivity of the contract, the system sent the email to a human reviewer instead of automatically sending it.

[0065] In multilingual scenarios, customer Ding uses Japanese, Spanish, or a mix of Chinese and English to describe salary, onboarding, or offboarding matters. The system can simultaneously use the original text, machine-translated summaries, and embedding vectors as normalized features. The rule engine matches fixed fields and domain names, the knowledge base recalls data using multilingual aliases and project numbers, and the large language model supplements natural language intent recognition. Since the final routing is still determined by a verifiable candidate set and fusion score, multilingual understanding does not bypass internal enterprise permission configurations.

[0066] In bulk email scenarios, external platforms may send employee change notifications from multiple countries to the company's public email in a short period. The system can deduplicate or aggregate emails based on Message-ID, subject, sender domain, attachment hash, customer ID, and employee ID to prevent identical emails from being forwarded repeatedly. For emails in the same batch but from different countries, the system still calculates the country, business type, and responsible person separately, generating independent logs to ensure a clear audit trail.

[0067] In terms of system deployment, the rule engine, knowledge base retrieval engine, large language model service, email reconstruction service, and log auditing service can be deployed on the same server or deployed separately as microservices. The large language model can be a locally deployed model, a cloud-based model, or a hybrid model; the knowledge base can be a relational database, document database, graph database, vector database, or a combination thereof; the email reconstruction service can be implemented through SMTP, IMAP, Graph API, enterprise email API, or email gateway.

[0068] In terms of security isolation, the system can perform field-level anonymization of model inputs according to enterprise security requirements, only inputting customer number, business type, country, attachment type, and summary vector into the model, while retaining sensitive fields such as original salary, ID number, and bank account number within the controlled data domain. The model output serves only as one source of information for routing decisions; the final sending action is still determined by the fusion score, threshold strategy, and permission verification.

[0069] This invention also provides an intelligent enterprise public email distribution device based on a restricted large language model and knowledge base enhancement. The device includes an email parsing module, a rule matching module, a knowledge base retrieval module, a semantic judgment module, a routing decision module, a permission verification module, an email reconstruction module, an exception handling module, an error correction learning module, and a log auditing module. These modules can be deployed on the same server or separately as email processing services, model services, retrieval services, and log services.

[0070] The email parsing module parses emails received by the company's public email or system email and generates standardized email features; the rule matching module performs rule judgment, tag marking, and candidate route generation based on the public email forwarding configuration; the knowledge base retrieval module recalls customer, region, responsible person, and historical processing information; the semantic judgment module outputs tags and semantic confidence scores through a large language model; the routing decision module calculates the fusion route score and determines the target handler; the permission verification module verifies access control policies; the email reconstruction module handles proxy sending and reference rewriting; the exception handling module generates reminder emails, exception prompt emails, and technical processing emails; the error correction learning module parses correction emails and updates weights online; and the log auditing module saves and queries the entire link record.

[0071] In an optional embodiment, the system can set the model output and rule output to three modes: strong constraint, weak constraint, or prompt only. For highly sensitive emails, the system can require both the rule and the knowledge base to be matched before allowing the model suggestion to be sent automatically; for ordinary service inquiry emails, the system can allow the model suggestion to be sent automatically when the permission verification is passed and the confidence level is high enough.

[0072] In an optional embodiment, the system can set different thresholds, different knowledge bases, and different prompt templates for different public emails. For example, payroll public emails can have higher sensitivity level weights and a higher proportion of manual review, customer service public emails can have higher session consistency weights, and technical support public emails can have higher attachment parsing and error code recognition weights.

[0073] In an optional implementation, corrective learning can either generate rules to be reviewed without automatically updating online parameters, or it can be validated in a sandbox environment before being released to the production environment. The system can record the accuracy, error rate, manual review rate, and anomaly rate before and after each parameter update, allowing the company to choose whether to roll back.

[0074] The email protocol, database, vector model, large language model, rule engine, permission system, and log system in the above embodiments can all be replaced according to the enterprise's technology stack. As long as a fusion routing based on rules, knowledge base, and model semantic judgment is adopted, combined with proxy identity forwarding, correction loop, permission verification, and log auditing, it falls within the protected concept of this invention.

[0075] Those skilled in the art can make equivalent substitutions or modifications to the module division, step sequence, weight settings, threshold strategies, email templates, correction instruction fields, log fields, model suppliers, and email interfaces without departing from the concept of this invention, and such substitutions or modifications should all fall within the protection scope of this invention. Attached Figure Description

[0076] Figure 1 This is a schematic diagram of the intelligent distribution method for enterprise public emails according to the present invention.

[0077] Figure 2 This is a schematic diagram illustrating the two-way proxy communication between the enterprise public email, system email, external sender, and internal processor of the present invention.

[0078] Figure 3 This is a schematic diagram of the routing scoring model that integrates rules, knowledge base, and large language model according to the present invention.

[0079] Figure 4 This is a schematic diagram illustrating the closed loop of reminder emails, correction emails, and online updates according to the present invention.

[0080] Figure 5 This is a schematic diagram of the intelligent corporate email distribution device of the present invention.

[0081] Figure 6 This is a schematic diagram of the permission verification and sensitive information desensitization process of the present invention.

Claims

1. A method for intelligent distribution of enterprise public emails using a restricted large language model and knowledge base enhancement, characterized in that, Includes the following steps: Retrieve pending emails received by the enterprise's public email or system email, and parse the email header, body, attachments, historical citations, recipients, CC recipients, sender domain, email source type, and session link identifier of the pending emails to generate standardized email characteristics. Based on the standardized email characteristics, a preset forwarding rule base, an internal enterprise knowledge base, and historical email processing records are invoked to generate a verifiable candidate route set containing at least one candidate processor. The standardized email features, rule hit results, knowledge base recall results, candidate handler set, prohibited output list, and structured output template are input into a large language model. This allows the large language model to output only the email tag set, candidate handlers, and corresponding semantic confidence scores from the verifiable candidate route set, the responsible person table, or the knowledge base recall results. Candidate set verification, permission verification, and risk verification are performed on the output of the large language model. If the verification passes, the fusion score for each candidate handler is calculated based on rule hit strength, knowledge base relevance, semantic confidence, session consistency, handler availability, and anomaly risk penalty. The system performs a combined route score and calculates the route confidence score. When the route confidence score is greater than or equal to the automatic sending threshold, it reconstructs the email header, body, attachments, citation header, and display identity using the system email or corporate public email as the proxy identity, based on the target processor and the session link identifier, and sends the reconstructed email to the target processor or external sender. When the target processor is not identified, there is an identification conflict, parsing fails, sending fails, the model output is unverifiable, permission verification fails, or manual correction is performed, an exception handling record and a correction closed-loop record are generated, and subsequent route parameters are updated based on the manual correction results.

2. The method according to claim 1, characterized in that, The standardized email features include at least the sender's email address vector, recipient's email address vector, CC recipient's email address vector, sender's domain name, subject semantic vector, body semantic vector, attachment summary vector, historical citation summary vector, candidate customer name, candidate region or country, candidate business person in charge, sensitive information marker, email source type, session link identifier, and agent identity status. Among these features, case-insensitive normalization processing is performed on email addresses, domain names, subject keywords, body keywords, and rule conditions.

3. The method according to claim 1, characterized in that, The email header includes From, To, Cc, Bcc, Reply-To, Message-ID, In-Reply-To, References, Date, Subject, and custom header fields; the historical references identify the boundary between the current body and the historical body through the reference separator, email client markup, Message-ID link, and body similarity.

4. The method according to claim 1, characterized in that, Each rule in the preset forwarding rule base includes a rule name, rule code, activation status, sorting field, judgment field, judgment method, matching value, execution action, action parameters, post-execution control field, rule weight, and manual priority field; the judgment field includes at least one of the following: sender, recipient, CC recipient, sender domain name, subject, body, subject or body, attachment name, customer name, region or country, business type, and sensitivity level.

5. The method according to claim 4, characterized in that, The invocation of the preset forwarding rule base includes: reading the rules in the enabled state in ascending order of sorting fields; when the judgment method is to meet all conditions, executing the corresponding action if all judgment fields match; when the judgment method is to meet any condition, executing the corresponding action if at least one judgment field matches; when the action is to mark a tag, assigning a value to at least one tag among customer name, region or country, business responsible person type, and risk level; when the action is to forward directly, writing the handler corresponding to the action parameter into the verifiable candidate route set; and determining whether to continue matching, stop matching, cancel forwarding by tag, or force manual review based on the control field after execution.

6. The method according to claim 1, characterized in that, The enterprise internal knowledge base includes at least one of the following: customer master data, customer alias database, region or country mapping table, business responsible person table, external employee email mapping table, service item configuration, historical forwarding log, historical correction record, email template, exception handling strategy, permission configuration, and sensitive field dictionary. The enterprise internal knowledge base is stored in the form of relational database, full-text index, vector index, graph database, or a combination thereof.

7. The method according to claim 1, characterized in that, The knowledge base retrieval employs a hybrid approach combining vector similarity, full-text search, exact field matching, customer alias expansion, and business graph adjacency expansion. ,in For email retrieval, For each knowledge item, E is the embedding function, graph is the graph adjacency relevance, field is the structured field hit rate, and α, μ, and ν are configurable weights.

8. The method according to claim 1, characterized in that, The semantic judgment using a large language model includes: inputting the email subject, body summary, attachment summary, historical citation summary, rule hit results, Top-K knowledge base recall results, candidate handler set, prohibited output list, and structured output template into the prompt template; constraining the large language model to select the target handler only from the candidate route set, the responsible person table, or the knowledge base recall results; outputting a structured result including customer name, region or country, business responsible person type, target handler, CC recipients, email type, basis summary, sensitivity level, and semantic confidence; when the output target handler is not in the verifiable set, the output is downgraded to a low-confidence suggestion and not sent directly.

9. The method according to claim 1, characterized in that, The converged routing score Determine according to the following formula: S j = λ 1 ∑ ω i ⋅ g i m ⋅ a i j + λ 2 p j + λ 3 m a x k s i m q m d k ⋅ r e l d k j + λ 4 c j + λ 5 c j - λ 6 r j Where j represents the j-th candidate processor, This represents the rule weight of the i-th rule. Let represent the hit function of the i-th rule for email m. This indicates that the i-th rule points to the action mapping of candidate processor j. This represents the semantic confidence of the large language model for candidate processor j. Representing knowledge entries The correlation strength with candidate processor j Indicates a session consistency item. Indicates the availability of the processor. Indicates an abnormal risk item. to Configurable weights.

10. The method according to claim 9, characterized in that, The route confidence C is calculated based on the fused route score of the candidate processor. ,in and These represent the highest and second-highest scores, respectively, and τ represents the temperature coefficient. ρ represents the entropy of the probability distribution P of the candidate processor, N represents the number of candidate processors, ρ represents the risk coefficient caused by parsing anomalies, attachment anomalies, rule conflicts, knowledge base conflicts, or unverifiable model outputs, and A represents the pass rate of permission verification. When C is greater than or equal to the automatic sending threshold, it is sent automatically. When C is within the manual review threshold range, it is sent to the person in charge of the public email for confirmation. When C is lower than the manual review threshold, it enters the anomaly handling process.

11. The method according to claim 1, characterized in that, The reconstructed email includes: after an external sender sends an email to the corporate email address and the target handler is identified, the email is reconstructed as an email sent from the system email address to the internal target handler; after the internal target handler replies to the system email address, the reply email is reconstructed as an email sent from the corporate email address to the external sender; during the reconstruction process, the original email subject, body, attachments, and necessary references are retained, the session link identifier, original Message-ID, routing log number, and tag summary are written, and the sender, recipient, CC, and proxy email display information in the historical references are rewritten in a consistent manner.

12. The method according to claim 1, characterized in that, When the target handler is not identified, there is an identification conflict, parsing fails, sending fails, or permission verification fails, an alert email or an error message email is generated. When the target handler is not identified or there is an identification conflict, the original email is exported as an EML attachment, and an alert email containing an alert identifier, attachment identifier, candidate tags, candidate handler, fusion scoring summary, knowledge base basis summary, correction instruction template, and session link identifier is generated and sent to the public email manager. When parsing fails or sending fails, the original email, error context, failure reason, number of retries, and system log number are sent to the technical manager.

13. The method according to claim 12, characterized in that, The correction instruction template adopts the format ***{key:value;key:value}***, where the key must include at least one of clientName, country, businessResponsibilityType, recipient, ccList, mailType, and riskLevel, and the key is case-insensitive. When parsing the correction email, the system only parses the content inside ***{...}***, ignoring the text outside the instruction, and supports fault-tolerant parsing with spaces, newlines, blank lines, semicolons, non-fixed key order, duplicate keys, missing keys, and empty values.

14. The method according to claim 1, characterized in that, The update of subsequent routing parameters based on manual correction results includes: using the manually corrected target handler as a supervision label, updating the rule weight, knowledge base association weight, and fusion model weight; when the same customer name, region, or business responsible person is corrected to the same result multiple times in a row, generating candidate knowledge base entries or candidate forwarding rules and entering them into the manual review queue, and writing them into the customer alias database, external employee email mapping table, or business responsible person table after the review is passed.

15. The method according to claim 14, characterized in that, The weights of the updated fusion model are updated using an online formula. ΠΩ ∇θ ,in , β is the learning rate, and β is the regularization coefficient. For multi-rule conflict penalty terms, ΠΩ is the projection operator used to ensure that the updated weights satisfy the constraints of non-negativity, upper bound, and that artificial high-priority rules are not covered by the model.

16. The method according to claim 1, characterized in that, The method also includes generating an email forwarding log for each independent email, wherein the email forwarding log includes email log number, public email number, system email number, original sender, proxy sender, target recipient, CC recipient, email tag, hit rule, knowledge base entry, model output summary, fusion route score, route confidence, sending date, sending status, anomaly type, corrected link number, permission verification result, and sensitive information de-identification status.

17. The method according to claim 16, characterized in that, The external email address, employee name, salary field, contract field, ID document field, bank account field, attachment name, sensitive customer fields, and model in the log are anonymized at the field level based on the summary; for authorization code, email password, API key, and token, only the encrypted ciphertext or masked display value is saved. Log query permissions are controlled according to public email, customer, region, department, role, and operation type.

18. The method according to claim 1, characterized in that, The method further includes generating a routing evidence package for each automatic sending or manual review. The routing evidence package includes at least a standardized email feature summary, a hit rule number, a knowledge base entry number, a set of candidate processors, a model structured output, a post-output verification result, a fused routing score, a routing confidence score, an authorization verification result, a risk item, a threshold version, a policy version, and an email log number. The routing evidence package is bound and stored with the original email hash, the reconstructed email hash, and the session link identifier.

19. The method according to claim 18, characterized in that, The policy versions include rule base version, knowledge base index version, prompt template version, threshold configuration version, permission configuration version, and de-identification policy version. When any policy version changes, the system writes the version number before and after the change, the person making the change, the approval status, the release time, and the rollback flag into the policy release log, so that the routing results of the same email at different times can be reproduced according to the corresponding policy version.

20. The method according to claim 1, characterized in that, Before updating subsequent routing parameters based on manual correction results, the process also includes replaying and evaluating historical email samples in a sandbox environment. The replay evaluation includes at least the automatic sending accuracy rate, misfortune rate, manual review rate, access control interception rate, unverifiable model output rate, and average processing time. When the replay evaluation results meet the preset release conditions, the candidate rules, knowledge base entries, or weight parameters are released to the production environment; otherwise, the original strategy version remains unchanged.

21. The method according to claim 1, characterized in that, The attachment processing includes security scanning, hash calculation, text extraction, table field recognition, OCR recognition, and sensitive field recognition of attachments. When the attachment security scan fails, the attachment summary confidence is lower than the threshold, the attachment contains highly sensitive fields, or the attachment hash conflicts with the historical records, the attachment risk is written into the risk item and automatic outgoing is prohibited or downgraded to manual review.

22. A smart email distribution device for enterprise public mail based on a restricted large language model and knowledge base enhancement, characterized in that, include: The email parsing module is used to acquire and parse pending emails received by the company's public email or system email and generate standardized email characteristics. The rule matching module is used to generate a set of verifiable candidate routes and a set of labels based on a preset forwarding rule base; The knowledge base retrieval module is used to retrieve customer, region, responsible person, and historical processing information related to pending emails from the enterprise's internal knowledge base; The semantic judgment module is used to call the large language model to output structured semantic judgment results under the constraints of the candidate route set; The routing decision module is used to calculate the fused routing score and routing confidence. The authorization verification module is used to verify the target handler, CC recipients, and proxy identities before sending; the email reconstruction module is used to reconstruct the email header, body, attachments, and citation chain using the system email or corporate email as the proxy identity; the evidence package module is used to store routing evidence packages and policy versions. The exception handling module is used to generate alert emails, exception notification emails, and technical processing emails. The error correction learning module is used to parse correction emails and update candidate rules or weights; The log auditing module is used to save, anonymize, and query the entire chain of records.

23. A computer device, characterized in that, It includes at least one processor and at least one memory, the at least one memory being used to store at least one program, which, when executed by the at least one processor, causes the at least one processor to implement the method as claimed in any one of claims 1 to 21.

24. A computer-readable storage medium storing a processor-executable program, characterized in that, The processor executable program, when executed by the processor, is used to implement the method as described in any one of claims 1 to 21.

Images