Intelligent interaction method and system based on NFC and AI digital thinking avatar

Abstract

This invention discloses an intelligent interaction method and system based on NFC and AI digital thinking avatars, belonging to the field of intelligent interaction technology. The interaction method includes: a user attaching a customized NFC card to a smart terminal, and after verification of legitimacy, being redirected to an AI interaction page bound to a real-person entity; the AI ​​digital thinking avatar is deeply bound to the real-person entity through a layered architecture, enabling identity-based dialogue and mining user needs through multi-level intent recognition; personalized responses are generated using a RAG and template fusion strategy; a structured demand report is automatically extracted, and lead scores are calculated based on a multi-dimensional model and pushed to the real-person entity according to priority. Through the above design, this application solves the problem of existing NFC and AI interaction being fragmented and lacking a closed loop for commercial conversion, achieving a complete closed loop from physical contact to commercial conversion, improving lead conversion efficiency and user experience, and is applicable to offline scenarios such as business networking and exhibitions.

Description

Technical Field

[0001] This invention belongs to the field of intelligent interaction, specifically relating to an intelligent interaction method and system based on NFC and AI digital thinking avatar. Background Technology

[0002] With the development of IoT and AI technologies, NFC technology has become a common way to interact with users. NFC, with its convenient physical reach, is widely used in mobile payments, access control, and webpage redirection. However, these applications typically execute simple, pre-set commands, lacking deep and dynamic interactive capabilities. Meanwhile, AI digital humans and chatbots are also becoming popular on various online platforms, providing users with services such as information retrieval and consultation. However, these require users to actively search for and access them, resulting in long interaction paths and fragmented scenarios.

[0003] However, in existing technologies, the application of NFC technology and AI intelligent interaction is fragmented, failing to form an effective synergy and exhibiting several objective shortcomings: First, the interaction path is fragmented, resulting in low conversion efficiency. NFC triggering typically only leads to a static page, making it difficult for users to directly enter a deep intelligent interaction environment, creating a significant gap between physical contact and valuable AI interaction. Second, the user experience is inconsistent and lacks contextual awareness. Activating AI interaction requires users to actively search for and access relevant platforms, making the activation path cumbersome and unable to quickly capture users' immediate intentions in offline scenarios such as business networking and exhibitions. Third, the lead screening and distribution process is lacking. Front-end interaction data is disconnected from back-end sales and service processes, making it difficult to systematically analyze, screen, and distribute user demand information generated during communication, leading to the loss of potential customer leads. Fourth, there is a lack of a closed-loop link for commercial conversion. Existing NFC+AI solutions only remain at the information display level, failing to form a complete commercial closed loop of "physical contact—intelligent interaction—demand mining—lead scoring—precise distribution—human follow-up," thus failing to systematically capture and convert commercial value in offline scenarios.

[0004] Therefore, how to organically integrate the convenient physical access capabilities of NFC with the deep interactive capabilities of AI digital humans, and solve the problems of fragmented interaction, poor user experience, and lack of commercial closed loop in existing technologies, has become an urgent technical challenge. Summary of the Invention

[0005] To address the shortcomings of existing technologies, such as the disconnect between NFC technology and AI intelligent interaction, inconsistent user experience, lack of clue screening and distribution mechanisms, and lack of a closed loop for commercial conversion, this application designs an intelligent interaction method and system based on NFC and AI digital thinking, achieving seamless integration of physical contact and intelligent interaction, and constructing a complete link from user needs discovery to commercial conversion.

[0006] The intelligent interaction method based on NFC and AI digital mind avatar includes the following steps: Step S1: The user attaches the customized NFC card to the smart terminal, and the smart terminal reads the data in the NFC card and initiates a jump request; Step S2: The server verifies the legitimacy of the redirection request. If the verification is successful, the smart terminal is redirected to the AI ​​interaction page corresponding to the real person bound to the NFC card. Step S3: The user engages in dialogue with the AI ​​digital thinking avatar bound to the real person on the AI ​​interaction page. The AI ​​digital thinking avatar performs intent recognition and demand mining based on the user's input. Step S4: Based on the intent recognition results and mining needs, the AI ​​digital thinking clone generates a personalized response and sends it back to the user through a combination of enhanced retrieval and preset templates. Step S5: The AI ​​digital thinking avatar extracts unstructured dialogue content into a structured customer needs report, calculates lead scores based on a multi-dimensional weighted model, and pushes the customer needs report to the real human subject's terminal according to the priority of the lead scores, so that the real human subject can follow up.

[0007] Preferably, in step S1, the NFC card stores URI data in NDEF format, and the URI data includes: the unique UUID of the NFC card, a timestamp, and a signature calculated based on the UUID and timestamp using the HMAC-SHA256 algorithm; In step S2, the legality verification includes: timestamp validity verification, signature consistency verification, and UUID binding relationship verification with the real person subject. If any verification fails, the server rejects the redirection request.

[0008] Preferably, in step S3, the AI ​​digital thinking clone is uniquely bound to the real subject through a layered architecture. The layered architecture includes: an identity information layer that stores the basic portrait of the real subject, a first rule framework layer for structurally extracting the thinking patterns of the real subject, and a second rule layer that is compiled and generated by the first rule framework layer in combination with training data and serves as prompt words for the dialogue system. The AI ​​digital mind clone injects the second rule layer as system prompts into the dialogue context, enabling an immersive dialogue that is consistent with the real person.

[0009] Preferably, in step S3, the intent recognition is a multi-level recognition oriented towards business conversion, including the following steps: Step S31: Perform preliminary intent classification on user input using a BERT-based classification model to obtain intent categories with different commercial value levels. The intent categories include product inquiries, price inquiries, casual conversation, technical support, complaints and suggestions, and corresponding confidence levels. Step S32: Trigger different processing flows based on confidence level: When confidence level ≥ 0.9, proceed directly to requirement mining; when confidence level is between 0.8 and 0.9, proceed to requirement mining after simple confirmation; when confidence level is between 0.6 and 0.8, proceed to requirement mining after clarifying the intent through reverse questioning; when confidence level < 0.6, provide a fallback response or transfer to manual processing. Step S33: For high-commercial-value intentions such as product inquiries and price requests, conduct multiple rounds of dialogue through missing slot identification and priority ranking to complete the filling of demand slots.

[0010] Preferably, the AI ​​digital mind clone supports multilingual interaction: it automatically identifies the user's input language through a language detection model (langdetect) and switches the response language according to the detection results; the second rule layer of the real person subject supports multilingual version compilation to ensure consistent identity immersion effect in different language environments; supported languages ​​include but are not limited to Chinese (Simplified / Traditional), English, Japanese, and Korean, with a language switching latency of <100ms.

[0011] Preferably, in step S4, the method for generating retrieval enhancement combined with a preset template includes: The interaction scenario is determined based on intent confidence, template matching degree, and user input complexity. Standard question-and-answer scenarios prioritize template generation; Complex consultation scenarios utilize search-enhanced generation; Casual conversation scenarios are generated directly using a large language model; For price and product inquiries, a template is used to build the response framework, knowledge is acquired and filled into the slots through the Retrieval Enhancement Generation (RAG) method, and then personalized polishing is done by combining the communication style of the real person.

[0012] Preferably, the retrieval enhancement generation method also supports a graph-enhanced retrieval generation (Graph RAG) mode, which uses a two-layer graph architecture of professional knowledge graph (PKG) and user profile graph (UPG) to achieve personalized responses based on entity relationship reasoning.

[0013] Preferably, the retrieval enhancement generation method further includes a graph-enhanced retrieval step: constructing a professional knowledge graph (PKG) with real-person subject professional knowledge as nodes and entity relationship as edges, and constructing a user profile graph (UPG) with user entities as nodes and demand relationship as edges; during retrieval, the user intent is mapped to graph nodes through entity links, and related subgraphs are extracted through multi-hop graph traversal, and the subgraph summary and vector retrieval results are fused and input into a large language model to generate a personalized response based on relational reasoning.

[0014] Preferably, the map enhancement retrieval generation method includes the following steps: Construct a two-layer knowledge graph: A Professional Knowledge Graph (PKG) is built using real-person entities such as products, solutions, industries, customer cases, and competitors as nodes, and semantic relationships such as "applicable to," "competing with," "depending on," and "containing" as edges. A User Profile Graph (UPG) is built using user entities, demand entities, preference entities, and pain point entities as nodes, and relationships such as "belong to," "have demand," and "preference" as edges. Entity Linking: Perform Named Entity Recognition (NER) on user input and link the recognized product names, company names, industry terms, and other entities to the corresponding nodes in the PKG and UPG; Multi-hop graph traversal: Starting from the linked nodes, perform 1 to 3 hop graph traversal using breadth-first search (BFS), extract relevant entity subgraphs, obtain entity relationship chains, and realize cross-entity association reasoning; Context fusion: The graph summary and vector retrieval fragments are fused according to relevance weights to construct an enhanced context, which is then input into a large language model to generate personalized responses based on relational reasoning; Dynamic graph update: After each round of dialogue, the newly disclosed needs, preferences and pain points of the user are incrementally written into the UPG through entity extraction, realizing personalized memory accumulation across sessions; the UPG is bound to the user's UUID, supporting continuous personalized services for the same user in different sessions.

[0015] Preferably, the retrieval enhancement generation method adopts a hybrid retrieval strategy: first, relevant knowledge fragments are retrieved from the knowledge base through vector retrieval and keyword retrieval respectively; then, the results of the two retrievals are fused through the RRF algorithm; and finally, the target knowledge fragments are reordered through the Cross-Encoder model for response generation.

[0016] Preferably, in step S5, the calculation dimensions of the multi-dimensional weighted model include requirement clarity, contact information completeness, budget clarity, urgency, and interaction activity; the sum of the weights of each dimension is 1, wherein requirement clarity has the highest weight and is not less than 0.25, contact information completeness has the second highest weight and is not less than 0.20, budget clarity has a weight not less than 0.15, urgency has a weight not less than 0.10, and interaction activity has a weight not less than 0.05; Preferably, the weights for the clarity of needs are 0.30, the completeness of contact information are 0.25, the clarity of budget is 0.20, the urgency is 0.15, and the activity level of interaction is 0.10. Each dimension is scored separately, then multiplied by its corresponding weight, and finally weighted and summed to obtain a clue score of 0-100. The clue scoring is divided into three priority levels: Leads scoring 85 points or higher, or users explicitly expressing their willingness to contact the real person in the conversation, are designated as P0 level and pushed immediately. Clues with a score of 60-84 points within the medium priority threshold range are classified as P1 and will be pushed out within a preset time. Clues with a score below the medium priority threshold (<60 points) are classified as P2 level and will be aggregated and pushed out according to a preset cycle.

[0017] Preferably, clues with a score of ≥85 or where the user explicitly expresses their willingness to contact the real person in the conversation are classified as P0 and pushed out immediately; Clues scoring between 60 and 84 are classified as P1 level and will be pushed out within 30 minutes. Clues with a score of <60 are classified as P2 level and will be summarized and pushed out daily.

[0018] Preferably, it also includes a weak network adaptation strategy adapted to the entire process of NFC jumps and AI interactions, the weak network adaptation strategy including: Core static resources are cached in the local storage of the smart terminal. The cache validity period is 7 days, and a cache update mechanism combining incremental update and full update is adopted. The skeleton screen technology enables progressive page loading, prioritizing the loading of critical path resources necessary for the first screen rendering; The network status is determined by combining browser network status detection with timed heartbeat detection. When the network is completely unavailable, an offline prompt page is displayed and user access logs are recorded. Once the network is restored, the user access logs are automatically retransmitted in batches.

[0019] The intelligent interaction system based on NFC and AI digital thinking avatar is used to implement the above-mentioned intelligent interaction method based on NFC and AI digital thinking avatar, including: NFC interaction module, verification jump module, AI digital thinking avatar module and demand extraction and push module. The NFC interaction module is used to realize data interaction between the customized NFC card and the smart terminal and to initiate jump requests. The NFC interaction module includes an NDEF data reading unit and a jump request construction unit. The NDEF data reading unit is responsible for reading URI data containing UUID, timestamp and HMAC-SHA256 signature from the NFC tag. The jump request construction unit is responsible for encapsulating the read URI data into a jump request and sending it to the server. The verification and redirection module is deployed on the server side and is used to verify the legality of the redirection request and guide the smart terminal to the AI ​​interaction page corresponding to the real person bound to the customized NFC card. The verification and redirection module includes a timestamp verification unit, an HMAC-SHA256 signature verification unit, and a UUID binding relationship query unit. The redirection can only be executed when all three verification units pass, and the request is rejected if any verification fails. The AI ​​digital thinking avatar module is uniquely bound to a real person and is used to perform intent recognition, demand mining, and personalized response generation for user input in order to facilitate business conversion. The AI ​​digital thinking avatar module includes: an identity information layer subunit that stores the basic profile of the real person; a first rule framework layer subunit that extracts the structured thinking patterns of the real person; a second rule layer subunit that is compiled and generated by the first rule framework layer subunit in combination with training data; a BERT-based intent classification subunit; a demand slot filling subunit; and a RAG hybrid retrieval response generation subunit. The demand extraction and push module is used to extract unstructured dialogues into structured customer demand reports, calculate lead scores based on a multi-dimensional weighted model, and push customer demand reports to the real user terminal according to the lead score priority. The demand extraction and push module includes: a dialogue information structure extraction unit, a multi-dimensional weighted scoring calculation unit, and a hierarchical push unit. The multi-dimensional weighted scoring calculation unit performs weighted calculations on the clarity of demand, completeness of contact information, clarity of budget, urgency, and interaction activity. The hierarchical push unit pushes customer demand reports to the real user terminal according to the scoring results and three-level priorities: P0 / P1 / P2. The NFC interaction module, verification jump module, AI digital thinking clone module, and demand extraction and push module are connected in pairs for communication.

[0020] The AI ​​digital thinking avatar module also includes a graph-enhanced retrieval subunit, which comprises: a professional knowledge graph (PKG) storage and query unit, used to store entities such as products, solutions, and industries of real-person subjects and their relationships; a user profile graph (UPG) storage and update unit, used to dynamically record user entities, demand entities and their relationships, and incrementally update them after each round of dialogue; an entity linking unit, used to link entities in user input to corresponding nodes in the PKG and UPG; a multi-hop graph traversal unit, used to perform 1 to 3-hop graph traversal starting from the linked nodes to extract relevant entity subgraphs; and a context fusion unit, used to fuse subgraph summaries with vector retrieval results to construct an enhanced context input large language model.

[0021] Preferably, the AI ​​digital thinking clone module further includes a weak network adaptation subunit. The weak network adaptation subunit is used to cache core static resources to the local storage of the smart terminal, realize progressive page loading through skeleton screen technology, determine the network status through browser network status detection combined with timed heartbeat detection, record user access logs when the network is unavailable, and automatically retransmit the user access logs in batches after the network is restored.

[0022] The advantages and effects of this application are as follows: 1. The intelligent interaction method based on NFC and AI digital thinking clone designed in this application can quickly launch personalized AI interaction by leveraging the "one-touch access" feature of NFC. Combined with Service Worker pre-caching, skeleton screen and other loading optimization strategies, the time from NFC triggering to AI interaction is controlled within 2 seconds, realizing the integrated integration of NFC and AI digital thinking clone. This solves the problem of the separation between physical access and intelligent interaction in the existing technology and significantly improves the user experience.

[0023] 2. The intelligent interaction method based on NFC and AI digital thinking avatar designed in this application constructs an AI identity substitution technology that binds a real person subject through a layered architecture of identity information layer, first rule framework layer, and second rule layer, as well as a dynamic system prompt word generation mechanism. This enables the AI ​​digital thinking avatar to accurately replicate the identity characteristics, thinking patterns, and communication styles of the real person subject, achieving the effect of "digital thinking avatar," which is different from the fixed role setting of general AI digital humans.

[0024] 3. The intelligent interaction method based on NFC and AI digital thinking clone designed in this application has designed a multi-level intent recognition and demand mining link for commercial conversion. Intents are classified according to commercial value, different processing flows are triggered by confidence thresholds, and the deep needs of users are actively mined by combining reverse questioning and slot filling, thereby improving the quality of consultation leads.

[0025] 4. The intelligent interaction method based on NFC and AI digital thinking clone designed in this application adopts a hybrid response generation strategy that integrates RAG and template. The template ensures the accuracy of key information, while the RAG enhances the coverage of long-tail issues and the style polishing maintains consistency. This effectively avoids the rigidity of a single template and the "illusion" risk of a single RAG.

[0026] 5. The intelligent interaction method designed in this application, based on NFC and AI digital thinking avatar, extracts demand information through a dual engine of rules and models, quantifies the value of leads through a multi-dimensional weighted model, and forms an automatic extraction and closed-loop transmission link from unstructured dialogue to structured demand reports. Real-time API push and multi-channel notifications ensure that leads quickly reach the real person, greatly improving the timeliness of lead processing compared to manual methods, and constructing a complete business conversion closed loop.

[0027] 6. The intelligent interaction method based on NFC and AI digital thinking clone designed in this application has complete weak network adaptation, high concurrency processing and security protection capabilities. The first screen interaction time in weak network environment meets the real-time interaction requirements, supports high concurrency dialogue requests, and ensures system security through multi-layer protection mechanisms such as HMAC-SHA256 signature, HTTPS transmission, AES-256-GCM storage encryption, and AI security shield. It is suitable for various offline scenarios such as business social networking, exhibitions, and enterprise customer acquisition.

[0028] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the preferred embodiments of this application are described in detail below with reference to the accompanying drawings.

[0029] The above and other objects, advantages and features of this application will become more apparent to those skilled in the art from the following detailed description of specific embodiments in conjunction with the accompanying drawings. Attached Figure Description

[0030] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In all drawings, similar elements or parts are generally identified by similar reference numerals. In the drawings, the elements or parts are not necessarily drawn to scale.

[0031] Figure 1 A flowchart of the intelligent interaction method based on NFC and AI digital thinking clone designed for this application. Detailed Implementation

[0032] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. In the following description, specific details such as specific configurations and components are provided merely to help fully understand the embodiments of this application. Therefore, those skilled in the art should understand that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. In addition, for clarity and brevity, descriptions of known functions and structures are omitted in the embodiments.

[0033] It should be understood that the phrase "an embodiment" or "this embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "an embodiment" or "this embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments.

[0034] Furthermore, reference numerals and / or letters may be repeated in different examples within this application. Such repetition is for the purpose of simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or settings discussed.

[0035] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists alone, B exists alone, and A and B exist simultaneously. The term " / and" in this article describes another type of relationship between related objects, indicating that two relationships can exist. For example, A / and B can mean: A exists alone, and A and B exist alone. In addition, the character " / " in this article generally indicates that the related objects before and after it are in an "or" relationship.

[0036] In this article, the term "at least one" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, "at least one of A and B" can mean: A exists alone, A and B exist simultaneously, or B exists alone.

[0037] It should also be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion.

[0038] Example 1 Please refer to Figure 1 This embodiment mainly introduces the specific design of an intelligent interaction method based on NFC and AI digital thinking avatar: Step S1: The user attaches the customized NFC card to the smart terminal, and the smart terminal reads the data in the NFC card and initiates a jump request; Furthermore, the technical parameters and manufacturing process of the NFC card: The specific technical parameters of the NFC card used in this embodiment are as follows: Manufacturing / Programming Process: During card production, the NDEF format data is pre-programmed into the NTAG216 chip using an ACR122U NFC reader or NXP TagWriter tool. Before programming, the uniqueness of the UUID for each card is verified using a database. After programming, the readability and correctness of the NFC data are verified by automated testing equipment; unqualified cards are automatically rejected.

[0039] I. NFC Tag Data Structure and Encoding Scheme: This invention uses NDEF (NFC Data Exchange Format) to store tag data, and the specific data structure is as follows: Record Type: URI (0x55) URI Identifier:https: / / Payload:[domain] / nfc / entry?uid=[UUID]&ts=[Timestamp]&sig=[Signature] Where: UUID is the unique identifier of the card, Timestamp is the timestamp, and Signature is the HMAC-SHA256 signature.

[0040] UUID generation rules: The UUID v4 standard (RFC 4122) is adopted. A 128-bit random value is generated using a cryptographically secure random number generator (CSPRNG), in the format xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx (where x is a random hexadecimal character, 4 represents the version number, and the high-order bits of y are 10 to indicate the variant number). Each UUID undergoes uniqueness verification before being written to the database after generation. If a collision is detected, the UUID is regenerated to ensure global uniqueness.

[0041] Signature calculation process: The signature uses the HMAC-SHA256 algorithm, and the specific steps are as follows: 1. Arrange the parameters to be signed in lexicographical order and concatenate them into a string: message=uid={UUID}&ts={Timestamp}; 2. Use the 256-bit key secret_key stored in the server-side HSM (Hardware Security Module) as the HMAC key; 3. Calculate the signature value: Signature = HMAC - SHA256(secret_key, message), the output is a 64-character hexadecimal string.

[0042] Server-side request validity verification process: 1. Parse the URL parameters and extract the three fields: uid, ts, and sig; 2. Timestamp validity check: Calculate |current time - ts| ≤ 300 seconds. If the validity period is exceeded, return HTTP 403 with the message "Link expired"; 3. Signature verification: Using the secret_key stored on the server, recalculate expected_sig=HMAC-SHA256(secret_key,uid={UUID}&ts={ts}) using the same algorithm; 4. Compare expected_sig with the sig in the request. If they do not match, return HTTP 403 and indicate "Signature verification failed"; 5. Query the database using the unique identifier uid to obtain the associated host_id (real person entity identifier). If no record is found, return HTTP 404. 6. After successful verification, the source IP, device fingerprint, and timestamp of the request are written to the access log table for subsequent security auditing and anti-replay analysis; 7. Return to the redirect URL and guide the user to the corresponding AI interaction page.

[0043] II. Redirecting Strategies in Weak Network Environments In actual product deployments, weak network environments are a common problem. This invention designs a multi-layered weak network adaptation strategy: 1. Local caching mechanism: On the first visit, core static resources (HTML template, CSS, basic JS) are cached in local storage, and the cache is valid for 7 days. In weak network environments, local cache is loaded first to ensure that basic page functions are available.

[0044] The cache update strategy is as follows: 2. Incremental update mechanism: Each request carries an ETag and an If-Modified-Since header, and the server compares the resource version number. If the resource has not changed, an HTTP 304 is returned (using local cache); if the resource has changed, the complete new resource is returned and the local cache and version number are updated.

[0045] 3. Handling after 7 days: When the first request is made after the expiration date, a full update will be performed, all core resources will be re-downloaded and the local cache will be overwritten; if the network is unavailable at this time, the expired cache will continue to be used and marked as "pending update" status, and a full update will be automatically triggered when the network is restored next time.

[0046] 4. Handling version inconsistencies: When an application is released, the server updates the resource version number. When the client detects a version inconsistency during a request, it immediately triggers a full update to ensure that users always use the latest version.

[0047] 5. Cache conflict resolution: When there is a conflict between the local cache and server resources, the conflicting local cache will be cleared and rewritten according to the server version.

[0048] 6. Progressive Loading Strategy: Employing Skeleton Screen technology, placeholders are displayed before data loading is complete, reducing user anxiety. Critical path resources are loaded first, while non-critical resources are loaded later.

[0049] The criteria for distinguishing between critical path resources and non-critical resources are as follows: 7. Critical path resources (required for first screen rendering): HTML shell page, CSS framework stylesheet (approximately 30KB after gzip), core JavaScript entry file (approximately 80KB after gzip), font files (only a subset used in the first screen).

[0050] 8. Non-critical resources (lazy loading): Image resources (using the loading="lazy" attribute), data analysis / tracking scripts, social sharing plugins, and non-first-screen functional modules (such as settings page and history page).

[0051] 9. Skeleton screen rendering trigger timing: The skeleton screen is rendered immediately after the DOMContentLoaded event is triggered, and an API data request is initiated at the same time; after the API data is returned and the DOM update is completed, the skeleton screen is hidden through a CSS transition animation (300ms fade-out) to display the real content.

[0052] 10. Offline Degradation Solution: When the network is detected to be completely unavailable, display an offline prompt page, guiding the user to check the network or try again later. Simultaneously, record user access logs and automatically retransmit once the network is restored.

[0053] Network status detection mechanism: 1. Main detection method: Obtain the browser's network status through the navigator.onLine property, and listen for online and offline events to achieve real-time detection.

[0054] 2. Auxiliary heartbeat detection: Send a lightweight heartbeat request (HTTP HEAD request, response body < 100 bytes) to the server every 10 seconds, with a timeout of 3 seconds.

[0055] 3. Offline determination criteria: If three consecutive heartbeat requests fail (i.e., unable to establish a connection with the server within 30 seconds), the system is determined to be offline and the offline degradation process is triggered.

[0056] 4. User access log storage format: Offline logs are stored using IndexedDB. Each record contains the following fields: {timestamp: ISO8601 timestamp, event_type: "page_view"|"nfc_tap"|"chat_start"|"error", url: current page URL, status: "offline"|"weak_network", device_info: device model and OS version}.

[0057] 5. Log retransmission trigger condition: Listen for the browser's online event. After the event is triggered, delay for 2 seconds (to avoid network jitter), then read all unuploaded log records in IndexedDB in batches, upload them to the server in batches via POST requests, and delete the locally uploaded records after successful upload.

[0058] III. Loading optimization for first-time visits The loading speed on the first visit directly impacts the user experience. This invention employs the following optimization measures: 1. Resource preloading: Utilize the brief time window (approximately 200-500ms) between NFC sensing and actual jumps to preload critical resources via Service Worker.

[0059] The specific mechanism by which NFC sensing signals trigger Service Workers is as follows: (1) When a user accesses the application for the first time through any means (such as scanning a QR code or manually entering a URL), the page's JavaScript registers a Service Worker, and thereafter the Service Worker remains in the browser; (2) When a user brings an NFC card close to the phone, the operating system's NFC service reads the NDEF URI record and calls the system's default browser to open the URL; (3) When the browser initiates an HTTP request, the registered Service Worker intercepts the request (fetch event) and returns the pre-cached resources from the Cache Storage first; (4) If the cache is not hit, the Service Worker will pass the request to the server, and after obtaining the response, write it to the Cache Storage for later use.

[0060] The specific list of key preloaded resources is as follows: 2. Code splitting and lazy loading: Split the application code according to the route, load only the necessary code on the first screen, and load other modules as needed.

[0061] 3. Image optimization: WebP format is used, along with responsive image srcset, to load images of appropriate size according to the device screen size.

[0062] The image size classification standards and compatible device screen resolution ranges in srcset are as follows: Example code: IV. Problems and Solutions Encountered in Actual Products 1. Universal Link Configuration Details: Deploy the apple-app-site-association (AASA) file in the / .well-known / path of the server root directory. The JSON format content contains the applinks.details array, configuring appIDs (in the format {TeamID}.{BundleID}) and path matching rules (such as [" / nfc / entry"). Apple's CDN periodically crawls and caches this file to ensure that the corresponding app can be opened directly on iOS when a user clicks the link. The domain must have HTTPS enabled and the certificate must be valid.

[0063] 2. Safari fallback solution: When the Universal Link fails to launch the app (e.g., the app is not installed), the system automatically opens the URL in Safari. After the page's JavaScript detects that the running environment is Safari, it executes the following fallback logic: First, it attempts to launch the app via... <meta http-equiv="refresh" content="0;url=..."> The tag redirects to the app store download page; at the same time, a "Continue in browser" button is displayed on the page. When the user clicks it, the H5 interactive page is loaded directly in Safari, ensuring that the user can complete the interaction regardless of whether the app is installed.

[0064] 3. Android Timeout Retry Details: The NFC read timeout is set to 3 seconds, with a maximum of 3 retries. The retry intervals are 1 second, 2 seconds, and 3 seconds respectively (linearly increasing backoff strategy). The NFC adapter connection is reinitialized each time a retry is made. If the retries still fail after 3 attempts, a message "Please tap the card again" will be displayed on the page, and a failure log will be recorded for compatibility analysis of future models.

[0065] 4. Specific implementation logic for timeout capture: All network resource requests are encapsulated as Promise, and timeout control is implemented through Promise.race([fetchPromise,timeoutPromise]), with the timeout threshold set to 5 seconds.

[0066] When timeout is triggered: (1) Cancel ongoing network requests (via AbortController); (2) Check if there is a historical version of the resource in the local cache. If so, use the cached version to display the resource in a downgraded manner. (3) If there is no cache, the skeleton screen placeholder will be displayed and the system will automatically retry once every 10 seconds in the background, up to a maximum of 3 times; (4) Display the complete offline downgrade page when all retries fail.

[0067] Step S2: The server verifies the legitimacy of the redirection request. If the verification is successful, the smart terminal is redirected to the AI ​​interaction page corresponding to the real person bound to the NFC card. I. Construction of the Basic Database: This embodiment adopts a hybrid storage architecture, combining the advantages of relational databases, vector databases and knowledge graph databases to construct a multi-layered knowledge base system. Among them, the knowledge graph database uses Neo4j for storage, which specifically supports entity relationship queries required for graph augmented retrieval generation (Graph RAG). 1. Vector Database Storage Structure Milvus is used as the vector database to store knowledge vectors after Embedding processing.

[0068] Deployment Architecture: The production environment adopts Milvus Standalone mode (single-node deployment), using etcd (v3.5) as the metadata storage engine and MinIO as the object storage engine for logs and data persistence. A single node is configured with a 16-core CPU, 64GB of memory, and a 500GB SSD, capable of storing and retrieving approximately 5 million vectors. When the data volume exceeds 5 million records, it can be smoothly scaled to Milvus Cluster mode (multi-node distributed deployment, including at least two Query Nodes, two Data Nodes, and two Index Nodes).

[0069] This vector storage / retrieval system uses a vector index of type IVF_FLAT. Its core is the inverted file IVF framework, which divides the entire vector space into 1024 clusters. Vectors within each cluster are stored in their original, uncompressed form. Vector similarity queries are accelerated by “finding clusters first and then comparing within clusters”.

[0070] During retrieval, the nprobe parameter is set to 64 (nprobe / nlist=6.25%), and the retrieval latency is kept <50ms while maintaining a recall rate >95%.

[0071] 2. Relational Database Storage Structure PostgreSQL is used to store structured data, including real-person subject information, session records, knowledge base metadata, and other structured information.

[0072] II. Data Collection and Processing Process: The collection and processing of knowledge base data adopts a pipeline architecture to ensure data quality and timeliness.

[0073] 1. Data Acquisition Layer Multi-source data acquisition: Supports access to various data sources, including company websites, product manuals, FAQ documents, historical chat logs, and email correspondence. The system defines a unified data source adapter interface (DataSourceAdapter), which is implemented by various data sources to achieve standardized data access.

[0074] The adaptation interface specifications for each data source are as follows: Interface: DataSourceAdapter Connect(config DataSourceConfig) error / / Establishing a data source connection FetchIncremental(since Timestamp) []RawData / / Incremental fetch (new data since the last synchronization) FetchFull() []RawData / / Fetch the entire data Transform(raw RawData) StandardDocument / / Convert to standard document format GetSourceType() string / / Returns the data source type identifier Specific adapter implementation: FileAdapter: Supports uploading and parsing PDF / Word / PPT / Markdown files. APIAdapter: Supports scheduled REST API fetching (configure URL / Headers / pagination parameters). DatabaseAdapter: Supports retrieving structured data via SQL queries. WebhookAdapter: Receives data actively pushed by external systems. Real-time synchronization mechanism: Webhook trigger conditions: When a document creation, update, or deletion event occurs in an external system (such as a CMS or CRM), that system sends an HTTP POST request to this system via a pre-configured Webhook URL. Webhook interface specification: POST / api / v1 / webhook / data-sync. The request header must include X-Webhook-Secret (for authentication). The request body is in JSON format and includes fields such as event_type (create / update / delete), source_id, and payload.

[0075] CronJob execution frequency: Incremental synchronization tasks are executed every 5 minutes, scanning all configured data sources for changes since the last synchronization timestamp; full synchronization tasks are executed once a day at 3:00 AM to fix possible omissions in incremental synchronization and to verify data consistency.

[0076] 2. Data Preprocessing Layer The raw data undergoes the following processing flow: Step 1: Text Extraction Text is extracted from PDF / Word documents using Apache Tika; The webpage content uses BeautifulSoup to parse the HTML; Remove HTML tags, CSS styles, and JavaScript code; Step 2: Text Cleaning Remove special characters and extra spaces; The unified encoding format is UTF-8; Sensitive information de-identification processing; Step 3: Text Segmentation A sliding window block algorithm is used; Block size can be set as needed; overlap: 128 tokens. Maintain semantic integrity and avoid truncating sentences in the middle; Step 4: Vectorization Use the Embedding model; Output a 768-dimensional vector; Batch processing, batch size 32.

[0077] Criteria for identifying sensitive information and methods for de-identifying it: The system automatically identifies the following categories of sensitive information using a regular expression pattern library: The de-identification process is performed during the text cleaning stage. The de-identified text is used for knowledge base storage and retrieval, while the original text is only read from encrypted storage when needed after authorization verification.

[0078] Specific implementation of the sliding window block algorithm: Input: Complete text T, block size S = 512 tokens, overlap O = 128 tokens Window step size: step=SO=384 tokens Algorithm steps: (1) Encode the text T into a token sequence tokens using a tokenizer[] (2) Initialization: start_index=0, chunk_list=[] (3) Loop: a.end_index=min(start_index+S,len(tokens)) b.chunk_text=decode(tokens[start_index:end_index]) c. Semantic integrity check: If the end of chunk_text is not at a sentence boundary (not ending with .!?.!?), Then it expands to the nearest sentence terminator, with a maximum expansion of 50 tokens. d. Add chunk_text to chunk_list e. If end_index >= len(tokens), terminate the loop. f.start_index += step (4)Chunk termination condition: When the number of remaining unprocessed tokens < S, all remaining tokens are taken as the last chunk to ensure no loss of trailing content (5)Output: chunk_list

[0079] Deployment method of the BGE-M3 Embedding model (1)Adopt the API call method to call the Embedding model service deployed in the cloud through the OpenAI-compatible interface instead of local deployment to reduce operation and maintenance costs and ensure service availability

[0080] (2)The model service address and API key are managed through a configuration file, supporting hot updates

[0081] (3)Whether to perform model fine-tuning: Use the pre-trained weights of BGE-M3 in the current stage without domain fine-tuning. In the future, according to the accumulation of business data, the contrastive learning method can be used to fine-tune on domain corpus to improve retrieval accuracy

[0082] Failure retry mechanism for batch processing (1)For each batch of 32 text vectorization requests, if a single batch fails, an exponential backoff retry strategy is adopted: the first retry interval is 1 second, the second is 2 seconds, the third is 4 seconds, and the maximum number of retries is 3 times

[0083] (2)If it still fails after 3 retries, write this batch of data to the failure queue (Redis List), and the background scheduled task scans the failure queue every 10 minutes and processes it again

[0084] (3)The timeout for single text vectorization is set to 10 seconds (including network transmission), and timeout is regarded as failure

[0085] 3. Data storage layer The processed data is written to both a relational database and a vector database simultaneously, and data consistency is ensured through transactions

[0086] Specific implementation method of the dual-write transaction Writing order: First write to the relational database (PostgreSQL), and then write to the vector database (Milvus). The relational database uses local transactions to ensure ACID

[0087] Consistency strategy: Adopt the eventual consistency model instead of a distributed transaction protocol (such as 2PC) to avoid performance bottlenecks

[0088] Specific implementation (1) Write the document metadata within a PostgreSQL transaction and mark the status as "pending synchronization"; (2) After the transaction is committed, Milvus is called asynchronously to write the vector data; (3) After Milvus writes successfully, the status in the updated database is "synchronization complete"; (4) If Milvus write fails, the status remains "pending synchronization". The background compensation task periodically scans the timed-out pending synchronization records and re-triggers the vector database write. (5) If a record fails to be compensated three times in a row, its status is updated to sync_failed, triggering an alarm to notify maintenance personnel to intervene manually.

[0089] Failure detection mechanism: The Milvus client sets the write timeout to 5 seconds. If the timeout expires or an error code is returned, the write operation is considered to have failed.

[0090] III. Storage of Private Information Linked to Real Users One of the core innovations of this invention is the deep integration of AI digital humans with real human subjects, enabling the AI ​​to embody a real person and engage in dialogue. Private information storage employs a tiered strategy: First layer: Identity information layer The identity information layer stores basic profile information of the real person, which is the foundation of the AI ​​digital human's "self-awareness" and specifically includes the following fields: Second layer: Business information layer (first rule framework layer + second rule layer) The business information layer is the core technology behind the "digital mind clone" of this invention. It employs a two-layer rule architecture to deeply extract and model the thought patterns of a real human subject. The "Thought Extraction Rule File" is automatically generated by the system based on the basic profile fields of the identity information layer and through a large language model. It adopts a structured meta-instruction format, defining a rule framework for "what to extract" and "how to extract" from the material, and includes six core extraction modules: (1) Core value system: extract the core beliefs, priority ranking principles, and trade-off logic when values ​​conflict with the real subject; (2) Decision thinking model: Extract problem diagnosis framework, decision reasoning chain, and typical decision pattern library (scenario-based); (3) Communication discourse system: extract language style features (high-frequency words, emotional tone), hierarchical communication strategies (expression methods for different objects), and typical speech script database; (4) Knowledge and experience base: Extract professional insights, methodological systems, and problem-solving toolkits (common pitfalls / lessons learned); (5) Contextual judgment ability: extracting scene recognition matrix and gray-scale decision-making logic (the way to handle situations where there is no standard answer); (6) Growth guidance system: extract growth stage model and heuristic question library.

[0091] The generation of the first rule framework layer adopts a customized strategy based on LLM: the key extraction dimensions of each module are dynamically adjusted according to the professional type of the real subject (such as creative / strategic, management / CEO, general). For example, for "management / CEO" experts, the decision-making thinking model module will focus on the dimensions of "resource allocation decision, personnel judgment, and crisis management".

[0092] The second rule framework layer is the final "thinking operating system" compiled from the first rule framework layer and training data, directly serving as the system prompt for AI dialogue. The second rule framework layer uses the Lisp-style S-Expression format and contains the following core modules: (1) Identity Core: includes name, role definition, personal background, core achievements, personality traits, etc.; (2) Core Values: A list of value definitions extracted from the training materials; (3) Thinking Algorithms: IF-THEN logical rules abstracted from real-life decision-making cases, such as "stress alchemy" and "trust assessment algorithm". Each algorithm includes input (triggering scenario), processing (reasoning steps) and decision criteria. (4) Communication Style: Tone of voice, keywords / verbal tics, and interaction rhythm to ensure that the AI ​​speaks "like" a real person; (5) Tool Invocation Logic: Define the tools that AI can use (knowledge base query, user memory storage / query, news query, etc.) and their invocation decision tree; (6) Security Shield: Content security filtering rules (zero tolerance for politically sensitive, pornographic, violent, etc.), integrity checks (no impersonation of government officials, no provision of medical / legal / investment advice, etc.); (7) Anti-Reverse Engineering Protocol: A three-layer defense mechanism to prevent users from obtaining system commands through prompt injection attacks; (8) Meta-Cognition: Rules for controlling the pace of the conversation (such as not asking questions in every round, avoiding interrogation-style continuous questioning).

[0093] Identity Substitution Mechanism in Dialogues – Dynamic Generation Process of System Prompts: Step 1: Read the identity information layer – obtain basic portrait information of the real person; Step 2: Invoke the first rule framework layer to generate the chain (large language model); Input: Basic profile fields for identity information layer; Output: A customized first rule framework layer; Step 3: Collect training materials – segment – ​​embed vectors – store in knowledge graph; Step 4: Initialization / iterative generation of the second rule layer; Input: First rule framework layer + memory summary from knowledge graph Processing: The second-level rule compiler (LLM) maps the information in the memory digest to the corresponding modules of the second-level rule target structure. Output: The complete Lisp format second rule layer (i.e., system suggestion words) Step 5: Incremental Update ("Precise Targeting" Update Strategy) When new training material is available, only the specific rule units that are affected are modified. Keeping most existing rules unchanged, the update type is determined through a filtering mechanism: Ordinary facts / chronological accounts—refusing to be updated (stored in the memory system, not entered into the mental model). Modifying character identity / style - Refusal to update (triggers personality protection agreement) New decision-making algorithm / values ​​- execution update System command correction - forced update Step 6: Dialogue-Time Injection – The second rule layer is injected into the dialogue context pipeline as System Prompt. Mechanism for real-person entities to edit / control permissions for private information: (1) Identity information editing permissions: Real people can edit the basic portrait fields in the identity information layer at any time through the management backend.

[0094] (2) Training material review authority: After all training materials are identified by AI, a structured “training card” (containing three categories: core viewpoints, thinking patterns, and knowledge points) is generated. Real people can review, edit, or delete inappropriate content on the card one by one. Only after confirming that there are no errors can the training be submitted.

[0095] (3) Permission to withdraw published content: Real users can withdraw published training content at any time. The system will restore the knowledge base to the snapshot state before the content was published through the rollback mechanism, including the synchronous rollback of the vector database and knowledge graph.

[0096] (4) Sensitive information protection: Information in the private information storage unit is finely managed through scene control fields to determine which dialogue scenarios allow AI to reference it, and the real person can adjust the visibility level of each piece of information at any time.

[0097] Step S3: The user engages in dialogue with the AI ​​digital thinking avatar bound to the real person on the AI ​​interaction page. The AI ​​digital thinking avatar performs intent recognition and demand mining based on the user's input. Further, understanding and filtering user intent: I. Primary Intent Recognition Layer This invention designs a multi-layered intent recognition model. The first layer is a primary intent recognition layer, used to quickly classify user input. 1. Intent Classification System Keyword library maintenance / update mechanism for each intent category: (1) Initial construction: Domain experts and product teams manually annotate and extract seed keywords for each category (about 50 to 100 keywords per category) based on real business dialogue data to form an initial keyword library, which is stored in the intent_keywords table of PostgreSQL, containing fields: keyword, intent_category, weight (weight 0-1), version (version number), status (active / deprecated).

[0098] (2) Regular update mechanism: The keyword database is updated monthly. Step 1: Extract high-frequency user input from the conversation logs of the past month; Step 2: Use the TF-IDF algorithm to identify newly added high-frequency words under each intent category; Step 3: The product team reviews the newly added candidate keywords, and after confirmation, they are included in the keyword library and assigned weights. Step 4: Mark keywords with a hit rate of less than 5% as deprecated.

[0099] (3) Version control: Each update generates a new version number (semantic version v1.0.0), and supports version rollback. When switching to the new version of the keyword library online, a canary release strategy is adopted: first verify the effect on 10% of the traffic (monitor the accuracy of intent recognition), and then switch to the full version after confirming that there is no significant drop.

[0100] 2. Intent recognition algorithm The intent classification model based on BERT is implemented as follows: Model architecture: Input: User text — pre-trained language model encoding — classification head — intent category probability distribution.

[0101] Fine-tuning details of pre-trained language models: Annotation standards and data sources for training data: Data source: Samples were taken from real customer service dialogue records of partner companies and anonymized to form training corpus.

[0102] Labeling Standards: A dual-person independent labeling system plus third-party arbitration is adopted. Two labelers independently label each dialogue with intent, and the consistency rate (Cohen's Kappa) between labelers is required to be >0.85. For samples where the two labelers have inconsistent labels, the senior labeler will arbitrate to determine the final label. The labeling guidelines document defines the judgment boundaries for each intent category and the rules for handling ambiguous cases.

[0103] The ratio of training set / validation set / test set is 8:1:1.

[0104] Model performance and creative advantages: With an accuracy of 94.2%, an F1-Score of 0.93, and an inference latency of <50ms, this model is optimized for intent classification in commercial conversion scenarios. Its core difference from general NLP intent recognition models lies in: (1) All training data are from real B2B / B2C business dialogue scenarios, rather than general dialogue data; (2) The intent classification system is divided according to commercial value (high / medium / low), which directly serves the lead screening process; (3) The model achieved F1-Scores of 0.96 and 0.95 for the two high-value intents, “product consultation” and “price inquiry”, respectively, which are significantly higher than the performance of the general intent model in the same scenario (usually 0.85~0.90).

[0105] II. Confidence Threshold and Process Triggering: Different processing flows are triggered based on the confidence score of intent recognition. The basis for setting the confidence thresholds (0.9 / 0.8 / 0.6) is as follows: Based on the test set data, precision-recall curves and ROC curves were plotted, and the optimal cutoff point was determined by analyzing the business performance under different thresholds. Threshold 0.9: Above this confidence level, the model accuracy is >98% and the false positive rate is <2%, meaning that the intent determination is almost accurate and can directly enter the business process without user confirmation, avoiding redundant interactions and reducing user experience.

[0106] Threshold 0.8: Within the range of 0.8 to 0.9, the accuracy rate is about 95%, with a possibility of about 2% to 5% false positives. This can be eliminated by a simple confirmation (such as "Are you here to learn about our product?"), resulting in extremely low user experience costs.

[0107] Threshold 0.6: Within the range of 0.6 to 0.8, the accuracy drops to 85%, and the risk of misjudgment increases significantly, requiring multiple rounds of follow-up questioning to clarify the user's true intention. Below threshold 0.6: The reliability of the model's predictions is insufficient, and a fallback process is initiated to avoid misleading the user.

[0108] The aforementioned thresholds were validated through A / B testing in the initial stage of launch, comparing the impact of different threshold schemes on lead conversion rates and user satisfaction, and the current scheme was ultimately selected.

[0109] III. Clarification of High-Value Intentions Through Multiple Rounds of Dialogue For high-value inquiries such as product consultations and price requests, the system clarifies and confirms the needs through multiple rounds of dialogue: 1. Reverse questioning strategy Follow-up question trigger conditions: If the confidence level of intent is <0.9, then the intent type is IN [product inquiry, price inquiry]: Trigger follow-up question module Follow-up question generation algorithm: (1) Missing slot identification algorithm: The collected information is compared with the predefined requirement schema (containing all required and optional slots). The unfilled slots are the missing slots. Identification process: Traverse each slot definition in the schema and check whether the corresponding field in the dialog state storage (Redis Hash) has a value and a confidence level > 0.8. If there is no value or the confidence level is insufficient, it is determined to be missing.

[0110] (2) Priority ranking of missing slots: The missing slots are ranked according to the following weighted scoring formula, and the slot with the highest score is asked first: priority_score=w_business×business_value+w_fill×fill_difficulty_inverse+w_context×context_relevance, where w_business=0.5 (business value weight, such as contact information and product type business value is the highest of 1.0), w_fill=0.3 (filling difficulty inverse, the easier the information is to obtain, the more likely it is to be asked first), w_context=0.2 (context relevance, the more relevant the slot is to the current topic, the higher the priority).

[0111] (3) Select appropriate follow-up questions from the follow-up question template library.

[0112] (4) Personalized rewriting of follow-up questions: Extract the communication style characteristics (tone, high-frequency words, and catchphrases) of the real subject from the second rule layer, and rewrite the template follow-up questions into a version that conforms to the real subject's speaking style using LLM. For example, if the real subject's style is "direct and efficient", the template "May I ask if you can disclose your budget range?" may be rewritten as "What is your approximate budget? I can match you with a suitable solution."

[0113] 2. Slot filling and requirements clarification Specific model selection and implementation details for each extraction method: (1) NER (Named Entity Recognition): Uses sequence labeling models to recognize entities such as people's names, company names, product names, numbers, and times in user input, and fine-tunes the domain dialogue data to improve recognition accuracy.

[0114] (2) Semantic classification: The BERT intent classification model architecture in Section 3.1.2 is reused, but the classification head is trained independently for the application scenario classification task. The classification dimension is the application scenario (e.g., manufacturing, retail, education).

[0115] (3) Time entity recognition: A hybrid rule and model approach is adopted. The rule layer uses regular expressions to match standard date formats (such as \d{4}[- / ]\d{1,2}[- / ]\d{1,2}) and relative time expressions (such as "next week", "within three months", "as soon as possible"); the model layer uses a sequence labeling model to recognize complex time expressions.

[0116] (4) Keyword matching similarity threshold: The similarity is normalized by edit distance (Levenshtein Distance), and the threshold is set to 0.85, that is, when 1-edit_distance / max_length≥0.85, it is considered a successful match.

[0117] 3. Multi-turn dialogue status management Using a finite state machine (FSM) to manage the states of a multi-turn dialogue: State definition: enum DialogState{ INITIAL, / / Initial state INTENT_CLARIFY, / / Intended clarification SLOT_FILLING, / / Slot filling in progress CONFIRMATION, / / Awaiting user confirmation COMPLETED, / / Requirements confirmed HANDOFF / / Transfer to human operator } State transition rules: INITIAL—INTENT_CLARIFY: Intent confidence < 0.8 INTENT_CLARIFY — SLOT_FILLING: Intent confirmed SLOT_FILLING - CONFIRMATION: Required slots filled. CONFIRMATION - COMPLETED: User confirms requirements CONFIRMATION——SLOT_FILLING: User Supplementary Information —HANDOFF: The user requests to be transferred to a human operator or the system cannot process the request. Specific criteria for determining each state transition: (1) Determination of “after confirmation of intent”: The user gives an affirmative response to the system’s intent confirmation question (such as affirmative words such as “yes”, “right”, “correct”, etc.), or the intent confidence increases to >0.9 after follow-up questioning and clarification.

[0118] (2) Determination of “Required slots are filled”: All slots marked as required=true have been filled with values, and the extraction confidence of each slot is >0.8.

[0119] (3) Determination of “user confirmation of requirements”: After the system displays a structured requirement summary to the user, the user expresses confirmation in natural language (such as “no problem”, “okay”, “that’s all”). The confirmation intent classification model (binary classification: confirmation / denial) is used to determine the confirmation. When the confidence level is >0.85, it is considered as confirmation.

[0120] (4) Threshold for determining "system cannot process": Trigger manual processing when any of the following conditions are met: The confidence level of intent recognition was <0.6 in all three consecutive rounds of dialogue. No useful information was obtained after asking the same slot more than 3 times; User sentiment analysis detected negative emotions (anger / dissatisfaction) for two consecutive rounds, with a confidence level >0.8.

[0121] Specific implementation methods of finite state machines: (1) State storage: The FSM state of each conversation session is stored in a Redis Hash structure, with the key being dialog_state:{conversation_id}. The Hash fields include: current_state (current state), intent_type (identified intent type), intent_confidence (intent confidence), filled_slots (filled slot JSON), turn_count (current conversation round number), and last_updated (last update timestamp). The TTL is set to 30 minutes, and the state is automatically released after the timeout, meaning that the conversation state is reset after 30 minutes of inactivity by the user.

[0122] (2) State transition logic: After each round of user input, the system executes the following process: Step 1: Read the current state from Redis; Step 2: Based on the current state and user input, find the target state according to the state transition rule table; Step 3: Execute the business logic corresponding to the state transition (such as intent recognition, slot extraction, follow-up question generation, etc.). Step 4: Write the new state back to Redis.

[0123] Step S4: Based on the intent recognition results and mining needs, the AI ​​digital thinking clone generates a personalized response and sends it back to the user through a combination of enhanced retrieval and preset templates. Furthermore, the methods for generating and controlling response content include: I. Statement Analysis Layer: User input undergoes multiple layers of analysis and processing to provide a basis for decision-making in generating subsequent responses. 1. Semantic understanding analysis Analysis dimensions: Entity Recognition (NER): Recognizes names of people, companies, products, numbers, times, etc.; Model: Sequence Labeling Model; Entity types: names of people, companies, products, numbers, times; Sentiment analysis: Determines user emotional tendencies; Model: Sentiment classification model; Output: Positive / Neutral / Negative; Keyword extraction: TF-IDF + TextRank hybrid algorithm; Extracts Top-5 keywords for knowledge base retrieval optimization.

[0124] Fine-tuning details of the BERT-CRF model: (1) The base model and intent classification share the pre-trained language model base (weight sharing), and the CRF layer is trained independently; (2) Fine-tuning parameters: learning rate 1e-5, epochs=15, using the negative log-likelihood of the CRF layer as the loss function.

[0125] RoBERTa-wwm-ext Sentiment Analysis Fine-tuning Details: (1) Based on the open-source Chinese-roberta-wwm-ext pre-trained model from Harbin Institute of Technology; (2) Fine-tuning the dataset: Three-class labeling (positive / neutral / negative), with a class distribution of approximately 3:5:2; (3) Fine-tuning parameters: learning rate 1e-5, epochs=5, AdamW optimizer, Dropout=0.1; (4) Sentiment analysis confidence threshold: When the confidence level is >0.7, the model prediction result is used directly; when it is 0.5~0.7, it is marked as "uncertain" and judged again in subsequent dialogues; when it is <0.5, it is "neutral" by default.

[0126] The specific fusion method of the TF-IDF+TextRank hybrid algorithm: (1) Calculate the TF-IDF score and TextRank score for each candidate keyword in the user input; (2) Both scores are Min-Max normalized to the [0,1] interval; (3) Mixed score = 0.6 × TF-ID score + 0.4 × TextRank score (TF-IDF focuses on word frequency statistics and has a higher weight; TextRank focuses on graph structure co-occurrence relationship and serves as a supplement). (4) Sort by mixed score in descending order and take the top-5 as the final keywords.

[0127] 2. Contextual Analysis Maintain the dialogue history context window (the last 10 rounds of dialogue) and analyze: (1) Topic coherence: Determine whether the current input continues the previous topic. (2) Deconstruction of reference: Analyzing the specific meanings of pronouns such as "this" and "that". (3) Intent evolution: Tracking the changing trajectory of user intent The basis for setting the dialogue history window to 10 rounds is as follows: (1) Business data statistics: Analysis of 5,000 real business dialogues shows that 90% of the effective needs can be clarified within 8 to 10 rounds of dialogue. Dialogues exceeding 10 rounds are usually repeated confirmations or small talk, with very little information increment.

[0128] (2) Token budget constraint: The average token consumption for 10 rounds of dialogue is about 2,000 to 3,000 tokens. With the addition of system prompts (second rule layer, about 2,000 tokens) and search content (about 1,500 tokens), the total is about 5,500 to 6,500 tokens. There is sufficient generation space within the context window (8K to 32K tokens) of the large language model.

[0129] (3) Processing of more than 10 rounds: When the dialogue exceeds 10 rounds, the system automatically triggers the dialogue compression task. The old dialogue from 10 rounds ago is summarized into a structured summary (about 200~300 tokens) using LLM and injected into the context as a "dialogue history summary", while retaining the complete original text of the most recent 10 rounds.

[0130] Algorithm implementation for each analysis dimension: (1) Topic coherence determination: The current round of user input and the previous round of user input are converted into vectors through the Embedding model, and the cosine similarity is calculated. If the similarity is ≥0.6, it is determined as topic continuation; if the similarity is <0.6, it is determined as topic switching, and the system will re-perform intent recognition.

[0131] (2) Reference resolution: A rule-based reference resolution method is adopted—maintaining an “entity stack” (the 5 most recently mentioned entities, arranged in reverse chronological order of mention time). When a pronoun (“this”, “that”, “it”, “they”, “the above”, etc., matched by a stop word list) is detected, it is replaced according to the following priority: a. Prioritize entities of the same type (e.g., if the context of the pronoun mentions "product", then search for the nearest PROD-type entity in the entity stack). b. The nearest entity (top element of the stack) is selected as the default candidate.

[0132] (3) Intent evolution tracking: Maintain an intent sequence list and record the intent type and confidence level identified in each round of dialogue. When the intent type changes between two adjacent rounds and the confidence level difference is >0.3, it is marked as an "intent shift event". The system actively confirms whether the user has changed the direction of their needs in the response strategy.

[0133] II. Knowledge Base Retrieval Enhanced Generation (RAG): This invention adopts a RAG architecture, combining retrieval and generation technologies to improve response quality. 1. Hybrid search strategy Search process: (1) Vector retrieval User question embedding—Milvus vector retrieval; Top-K=10, similarity threshold 0.7; Recall-related knowledge fragments; (2) Keyword search Keyword extraction – Elasticsearch Boolean query; Supplement the information that vector retrieval may have missed; (3) Results fusion RRF (Reciprocal Rank Fusion) algorithm fusion k=60, overall ranking takes the top-5. (4) Reordering Fine-tuning using the Cross-Encoder model Improve the relevance of search results The basis for setting each parameter: (1) Basis for Top-K=10: A / B testing verified that the recall rate was only 72% when Top-K=5, and increased to 93% when Top-K=10. However, the recall rate only increased slightly to 95% when Top-K=20, but the retrieval latency doubled. Top-K=10 achieves the best balance between recall rate and latency (<100ms).

[0134] (2) Basis for the similarity threshold of 0.7: The quality of search results under different thresholds was analyzed on the test set. 0.7 is the intersection of false positive rate (returning irrelevant results) <5% and false negative rate (omitting relevant results) <10%. When the threshold is below 0.7, noise increases significantly, and when it is above 0.7, the omission of effective knowledge increases.

[0135] (3) Basis and calculation process of RRF algorithm k=60: RRF (Reciprocal Rank Fusion) is a parameterless ranking fusion algorithm, from Cormack et al. (2009). The formula is RRF_score(d)= Σ1 / (k+rank_i(d)), where k is a smoothing constant and rank_i(d) is the ranking of document d in the i-th retrieval strategy. k=60 is the default value recommended by this paper, and it has been shown in multiple experiments to have good robustness to the ranking distribution of different retrieval sources. Specific calculation: If a document ranks 3rd in vector retrieval and 7th in keyword retrieval, then RRF_score=1 / (60+3)+1 / (60+7)=0.0159+0.0149=0.0308.

[0136] (4) Cross-Encoder Model Selection and Ranking Scoring Criteria: The cross-encoder / ms-marco-MiniLM-L-6-v2 model (trained based on the Microsoft MS MARCO dataset) was adopted. The input was a (query, document) text pair, and the output was a relevance score between 0 and 1. During the ranking, the top-10 results after RRF fusion were re-scored and sorted in descending order by the Cross-Encoder score. The top-5 results were taken as the final retrieval results. The inference latency of the Cross-Encoder was about 10ms / pair, and the total latency of 10 re-rankings was about 100ms.

[0137] (5) Specific syntax and parameters for Elasticsearch Boolean queries: { "query":{ "bool":{ "must":[ {"match":{"content":{"query":"keywords extracted by the user","analyzer":"ik_smart"}}} ], "should":[ {"match":{"content":{"query":"keyword synonym expansion","boost":0.5}}}, {"match":{"category":{"query":"identified intent category","boost":0.3}}} ], "minimum_should_match":1, "filter":[ {"term":{"owner_id":"The ID of the current real person"}} ] } }, "size":10 }

[0138] 2. Search Result Processing The retrieved knowledge fragments were processed as follows (1) Deduplication: Deduplication is based on semantic similarity to avoid duplicate information. (2) Truncation: A single knowledge fragment shall not exceed 300 tokens. (3) Concatenation: Concatenate according to relevance, with a total length not exceeding 1500 tokens. The specific algorithms and thresholds for semantic similarity deduplication are as follows: (1) Calculate the cosine similarity of each pair of knowledge fragments in the Top-5 search results (using the existing Embedding vector).

[0139] (2) The deduplication threshold is set to 0.92: When the cosine similarity of two knowledge segments is >0.92, they are judged as semantically duplicated content. The one with the higher Cross-Encoder score is retained, and the other one is discarded.

[0140] (3) The selection criteria for the threshold of 0.92: In the test on 200 manually labeled “duplicate / non-duplicate” knowledge pairs, 0.92 is the optimal balance point between precision > 95% (without mistakenly deleting non-duplicate content) and recall > 90% (without missing duplicate content).

[0141] III. Preset Templates and Slot Filling: For standardized scenarios, template responses are used to ensure response quality and consistency. 1. Template Definition Template Example (Price Inquiry): { "template_id":"price_inquiry_response", "conditions":{ "intent":"Price inquiry", "product_mentioned":true }, "template":"Regarding the price of {{product_name}}, our quoted price range is {{price_range}}. The specific price will need to be determined based on your actual requirements ({{requirement_factors}}). I can arrange for our professional consultant to provide you with a detailed plan, is that alright with you?" "slots":[ {"name":"product_name","source":"entity_recognition"}, {"name":"price_range","source":"knowledge_base"}, {"name":"requirement_factors","source":"context"} ] } Template creation / editing / approval mechanism: (1) Creation: Domain experts and product teams create templates in the management backend, defining template ID, trigger conditions (intent type + entity requirements), template text (including slot placeholders) and slot data source mapping.

[0142] (2) Review: Newly created or modified templates must undergo two levels of review: Product managers review the accuracy of the content and ensure business compliance; The technical lead reviews the template syntax for correctness and the validity of slot mapping. It can only be released and launched after the review is approved.

[0143] (3) Version management: The template is stored in the database. Each modification generates a new version number and supports version rollback.

[0144] 2. Template and RAG Integration Strategy The system intelligently selects the response generation method based on the scenario: Specific judgment algorithms for each scenario: (1) Standard Question and Answer Judgment: If the intent confidence is ≥0.9 and the similarity between the user input and an item in the FAQ template library is ≥0.85 (calculated by Embedding cosine similarity), the template is directly matched.

[0145] Complex Consultation Judgment: If the intent confidence is ≥0.8, but no template is matched (highest template similarity <0.85), and the user input length is >50 characters (indicating that the question has a certain degree of complexity), proceed to the RAG generation process.

[0146] (2) Casual chat determination: The intent classification result is “casual chat” and the confidence level is >0.8, or the user input length is <10 characters and does not contain any business keywords.

[0147] (3) Template + RAG fusion judgment: If the intent is to query specific technical parameters in "price inquiry" or "product consultation", first match the template to obtain the structured response skeleton, and then fill the knowledge slots in the template through RAG retrieval.

[0148] Specific splicing method for template + RAG integration: (1) Match the corresponding response template according to the intent type and the extracted entities; (2) The slot marked with source:"knowledge_base" in the template is populated with knowledge retrieved by RAG; (3) If the RAG search does not return results that meet the similarity threshold, the default value preset in the template will be used; (4) Language polishing and personalized rewriting to ensure that the reply maintains the accuracy of information while having the speaking style of a real person.

[0149] The dynamic fusion strategy designed in this embodiment solves two inherent defects in the prior art: (1) the rigidity of single template replies: unable to cope with diverse expressions and subtle differences in the same intent; (2) the insufficient accuracy of single RAG replies: in key scenarios such as price and contact information, purely generated replies may produce illusions or omit key information. This embodiment improves the reply accuracy to 97.3% in the test scenario through a three-layer architecture of "template as a baseline + RAG enhancement + style polishing" (compared to 91.2% for single RAG and 82.5% for single template).

[0150] IV. Response Generation and Optimization The final response generation process: Generation process: 1. Build a Prompt System Prompt (Identity Submission) Context (Retrieved Knowledge) History (Dialogue with History) User Input 2. Call the large language model Model: GPT-4 / Wenxin Yiyan / Tongyi Qianwen Temperature: 0.3 (to ensure recovery stability) Max Tokens: 800 3. Post-processing Sensitive word filtering Formatting standardization Length limit (no more than 500 characters) 4. Quality Assessment Relevance score (how well the answer matches the question) Consistency score (consistency with the knowledge base) If the value is below the threshold, a retry or fallback response will be triggered.

[0151] The specific template and dynamic generation rules for System Prompt: System Prompt, or the second rule layer, uses a structured rule description format and includes functional modules such as identity information, values, thinking logic, communication style, tool calls, and content security.

[0152] The second rule layer is dynamically generated based on the identity information of the real subject and training data, and is automatically updated iteratively each time new training material is available. During dialogue, the complete context pipeline is concatenated and injected in the following order: (1) Second rule layer (system prompt words, ~2000 tokens) (2) Dialogue history summary (when the dialogue has exceeded 10 rounds, a compressed summary of the old dialogue, ~200-300 tokens) (3) Additional context (RAG search results / data obtained from API, maximum 3000 tokens) (4) Current time information (Beijing time + day of the week) (5) Tool definition (JSON Schema of available tools) (6) Dialogue history (the last 10 complete dialogues) (7) Current input by the user The calling interface of the large language model and the multi-model adaptation / switching mechanism: The system defines a unified LLM call abstract interface: Interface: LLMClient Generate(prompt, config) — Response / / Synchronous generation StreamGenerate(prompt,config) — EventStream / / Streaming Generation (SSE) GetModelInfo() — ModelMetadata / / Retrieves model metadata Config:{model:string,temperature:float,max_tokens:int,top_p:float} Multi-model support is achieved through the adapter pattern: adapters such as OpenAIAdapter, WenxinAdapter, and TongyiAdapter implement the above interfaces. Model switching rules are managed through configuration files, supporting the allocation of different models according to functions. When the configuration changes, no modification to the business code is required, and hot updates take effect immediately.

[0153] The maintenance mechanism of the sensitive word database: (1) The sensitive word database is stored using a Trie tree (prefix tree) data structure, which supports multi-pattern string matching with O(n) time complexity (n is the length of the input text).

[0154] (2) Sensitive words are divided into four levels: politically sensitive (zero tolerance, direct refusal to reply), pornography and violence (zero tolerance), illegal and criminal (zero tolerance), and commercially sensitive (replace with euphemisms).

[0155] (3) The sensitive word database is updated monthly by the compliance team and can be imported / exported in batches through the management backend. It supports CSV format, and each record includes: word, level, processing method, and effective date.

[0156] (4) When updating and going online, a double buffering mechanism is used: the new dictionary is loaded into the backup Trie tree, and the pointer is switched atomically after loading is completed to ensure that the online service is not interrupted.

[0157] Specific standards for format standardization: Reply text must meet the following format requirements: (1) Plain text output, without using Markdown tags (bold, list, etc.), to simulate the natural paragraphing style of WeChat messages; (2) Paragraphs should be separated by blank lines, and each paragraph should not exceed 100 characters; (3) Avoid using rigid enumeration words such as “firstly”, “secondly”, and “finally”, and use natural transitions instead.

[0158] The specific calculation methods for relevance score and consistency score are as follows: (1) Relevance score: User questions and AI responses are encoded into vectors through the Embedding model, and the cosine similarity is calculated as the relevance score, ranging from [0,1].

[0159] (2) Consistency score: The AI ​​response and the knowledge fragment retrieved by RAG are combined into text pairs, and the implication relationship is determined by the NLI (Natural Language Inference) model. The NLI model outputs three-class probabilities (implication / contradiction / neutrality), and the implication probability is taken as the consistency score.

[0160] (3) Quality threshold: The quality check is passed when both the correlation and consistency scores are >0.7; a retry is triggered when either score is <0.7 (maximum of 2 retries, with appropriate adjustment of generation parameters each time, such as Temperature=0.2 for the first retry and Temperature=0.1 for the second retry); if the retry still fails, a fallback reply is used ("This problem is quite complicated. I will transfer you to a professional consultant for a detailed answer. Is that okay?").

[0161] Step S5: The AI ​​digital thinking avatar extracts unstructured dialogue content into a structured customer needs report, calculates lead scores based on a multi-dimensional weighted model, and pushes the customer needs report to the real human subject's terminal according to the priority of the lead scores, so that the real human subject can follow up.

[0162] Furthermore, one of the core functions of this invention is to automatically extract structured customer requirement reports from unstructured conversations into structured requirements: 1. Demand Information Extraction Extraction algorithm: (1) Rule extraction: Regular expression matching: phone number, email address, amount, time; Keyword matching: demand type, urgency level; (2) Model extraction: Use UIE (Universal Information Extraction) model; predefined schema: requirements, budget, time requirements, contact information, etc.; structured output of extraction results. (3) Dialogue status tracking: Maintain slot filling status; record user-confirmed request information. Specific rules for regular expressions: Fine-tuning details of the UIE model: (1) Basic model: The information extraction pre-trained model is adopted to support the joint extraction of multiple types of entities and relations.

[0163] (2) Fine-tuning data: 3,000 manually annotated business dialogue texts, annotating entities such as demand points, budget, time requirements, contact information, company name, and product name.

[0164] (3) Fine-tuning parameters: The learning rate and training rounds are determined as needed.

[0165] (4) Complete fields of the predefined schema: ["Requirement description", "Product type", "Budget amount", "Budget currency", "Expected time", "Contact phone number", "Contact email", "Company name", "Contact person name", "Usage scenario", "Competitor mentions"].

[0166] The mechanism for storing and updating slot fill status: (1) Storage medium: Redis Hash, Key is slot_state:{conversation_id}, TTL=24 hours.

[0167] (2) Hash field mapping: Each Schema field corresponds to a Hash Field, with the value being a JSON object {value:"extracted value",confidence:0.95,source:"turn_3",confirmed:true / false}.

[0168] (3) Update mechanism: After each round of dialogue, rule extraction and UIE extraction are performed on the user input. If the newly extracted value conflicts with the stored value (the same field but different values), it will be processed according to the following priority: a) When the user explicitly corrects the value (e.g., "It's not 100,000, it's 200,000"), replace the old value with confirmed=true. b. If the confidence level of the new value is greater than the confidence level of the old value + 0.1, then the old value should be replaced. c. In other cases, retain the old value and mark the conflict as pending confirmation.

[0169] 2. Structured Requirements Report Format Requirements Report Schema: { "report_id":"RPT-20240224-001", "created_at":"2024-02-24T10:30:00Z", "customer_info":{ "customer_id":"C-12345", "contact":"13800138000", "company": "XXX Technology Company" }, "conversation_summary":"Intelligent Customer Service System for User Inquiries...", "requirements":[ { "type":"Product Requirements", "description":"Need an intelligent customer service system", "confidence": 0.95 } ], "budget":{ "amount":"100,000-200,000", "currency":"CNY", "confidence": 0.85 }, "urgency":{ "level":"high", "expected_time":"Within 1 month", "confidence": 0.90 }, "intent_tags":["Product Inquiry","Price Sensitive"], "lead_score":85, "recommended_action": "Prioritize follow-up" } The specific formula for calculating lead_score (clue score) is as follows: The clue scoring uses a weighted multi-dimensional scoring model, with a maximum score of 100 points. The calculation formula is as follows: lead_score=W1×D_requirement+W2×D_contact+W3×D_budget+W4×D_urgency+W5×D_engagement The weight values ​​and calculation logic for each dimension are as follows: The corresponding rules for recommended_action are as follows: II. API Push Technology Implementation: Structured requirement reports are pushed to the backend platform via API, achieving seamless integration with the real user: 1. API Interface Design Interface definition: POST / api / v1 / leads / push Headers: Authorization:Bearer{access_token} Content-Type: application / json X-Request-ID:{uuid} Request Body: {Requirements Report JSON Object} Response: 200 OK:{"code":0,"message":"success","data":{"lead_id":"L-001"}} 400 Bad Request: Incorrect parameters 401 Unauthorized: Authentication failed 500 Internal Error: Server Error access_token generation / verification / expiration mechanism: (1) Generation: The user provides credentials (username + password) via POST / api / v1 / auth / login. After the server verifies the credentials, a JWT (JSON Web Token) is generated. The JWT uses the RS256 algorithm (RSA asymmetric cryptographic signature). The payload contains {user_id, host_id, role, iat (issuance time), exp (expiration time)}.

[0170] (2) Validity period: The access_token is valid for 24 hours; a refresh_token (valid for 7 days) is also issued and stored in Redis (Key: refresh_token:{user_id}, TTL=7 days). After the access_token expires, the client can use the refresh_token to apply for a new access_token without having to log in again. (3) Verification: For each API request, the gateway layer uses the RS256 public key to verify the integrity of the JWT signature and checks whether the exp has expired. If verification fails, an HTTP 401 error is returned.

[0171] (4) Revocation mechanism: When a user logs out or changes their password, the corresponding refresh_token is deleted from Redis, and the JTI (JWT ID) of the access_token is added to the Redis blacklist (TTL = the remaining validity period of the access_token). The blacklist is checked when a subsequent request is made for verification.

[0172] The X-Request-ID generation rule is as follows: The client generates a UUID v4 (RFC 4122) with each request, in the format xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx. The server uses this ID as an idempotency key (stored in Redis, TTL=24 hours). If a duplicate request with the same X-Request-ID is detected, the result of the first request is returned directly, avoiding duplicate creation of clues. Furthermore, the X-Request-ID is used throughout the entire log chain for easy problem tracking and troubleshooting.

[0173] Request parameter validation rules: (1) Use JSON Schema to verify the integrity of the request body structure. Required fields: report_id, customer_info.contact, requirements (at least one).

[0174] (2) Field type validation: lead_score must be an integer between 0 and 100, created_at must be in ISO 8601 format, and contact must match the regular expression for mobile phone number or landline number.

[0175] (3) Field length limits: conversation_summary not exceeding 2000 characters, requirements[].description not exceeding 500 characters.

[0176] (4) If the verification fails, an HTTP 400 response is returned, and the response body contains a list of specific verification error messages.

[0177] 2. Push Mechanism (1) Real-time push: The push is triggered immediately after the requirement is confirmed, with a delay of less than 1 second. Message queue (RabbitMQ) is used to smooth out peaks and valleys to ensure stability under high concurrency.

[0178] (2) Retry mechanism: Automatic retry when push fails. Retry strategy: intervals of 1s, 2s, 4s, and 8s, up to 4 times. If the number of retries is exceeded, it will be entered into the dead letter queue and handled manually.

[0179] (3) Idempotency guarantee: By deduplicating reports using report_id, multiple pushes of the same report will not create duplicate leads.

[0180] RabbitMQ deployment architecture and configuration: (1) Deployment architecture: The production environment uses a 3-node RabbitMQ cluster, and uses a Quorum Queue (arbitration queue) to ensure message persistence and high availability. The cluster nodes communicate with each other through the Erlang distributed protocol, and the remaining nodes automatically take over message processing when any node fails.

[0181] (2) Switch configuration: Direct Exchange, named lead_exchange, Durable=true. (3) Queue configuration: queue name lead_push_queue, Durable=true, message TTL=24 hours (messages that have not been consumed within 24 hours will be automatically expired and discarded), maximum queue length 100,000.

[0182] (4) Routing rules: The routing key is lead.push. After the message is sent from the producer to lead_exchange, it is routed to lead_push_queue according to the routing key.

[0183] (5) Criteria for determining push failure: Push failure is determined when the HTTP response code of the receiver is 4xx (except for 400 parameter error) or 5xx; push failure is determined when the connection times out (no response for more than 5 seconds); push failure is determined when there is a network abnormality (DNS resolution failure, connection rejection, etc.). HTTP 400 (parameter error) does not trigger a retry, but directly enters the dead letter queue and an alarm is triggered.

[0184] (6) Dead letter queue processing flow: Dead letter exchange lead_dlx (Fanout type), dead letter queue lead_dead_letter_queue. Messages entering the dead letter queue are displayed through the management backend. Operation and maintenance personnel can view the reasons for failure, manually modify the message content and resubmit it, or mark it as "manually processed" for archiving. Messages in the dead letter queue that have not been processed for more than 72 hours trigger email alerts.

[0185] 3. Notification Mechanism Notification method for real-person entities to receive clues: The basis for setting a clue score of ≥80 / 90: (1) Lead score ≥80 (App push threshold): Based on the retrospective analysis of historical lead data, the conversion rate of leads with a score ≥80 to customers is 35%~45%, which is in the top 20% of conversion rate, and is worth investing time to actively contact.

[0186] (2) Lead score ≥ 90 points (SMS notification threshold): Leads with a score ≥ 90 have a conversion rate of 60%~70%, which are high-quality leads in the top 5% of conversion rates and require the highest priority for immediate attention. Therefore, SMS, a high-reach channel, is used to ensure that the real person receives the notification as soon as possible.

[0187] (3) The above thresholds will be dynamically adjusted by continuously monitoring conversion rate data after the system goes online, and reviewed once every quarter.

[0188] Daily summary timeline and email template: (1) Time node: 9:00 AM (Beijing time) every day, automatically generated and sent by a scheduled task.

[0189] (2) Email template: includes subject ("[FuturMind]{date} Daily Customer Inquiry Report"), summary statistics (number of new leads on the day, distribution of each rating range, summary of the highest-scoring lead), lead details table (serial number, time, customer information summary, demand summary, rating, recommended action), and trend chart (line chart of the number of leads in the past 7 days).

[0190] Push interfaces and adaptation mechanisms for each notification method: (1) App push: iOS uses APNs (Apple Push Notification service), Android uses FCM (Firebase Cloud Messaging), and HarmonyOS uses Huawei Push Kit. The differences between the three platforms are encapsulated through a unified PushAdapter interface, so the business layer does not need to be aware of the specific platform when making calls.

[0191] (2) SMS notification: Integrate Alibaba Cloud SMS service (SMS API), use pre-approved SMS templates, and send messages using variable filling methods to ensure compliance.

[0192] (3) Email notification: sent via SMTP protocol, supports configuration of third-party email services (such as SendGrid, Tencent Enterprise Email).

[0193] (4) WeChat Work: Push messages through the WeChat Work group robot Webhook interface. The message format is Markdown card, which includes a lead summary and a jump link.

[0194] III. Problems and Solutions in Actual Deployment Specific implementation of the adapter pattern: Interface: LeadFormatAdapter Format(lead LeadReport) → []byte / / Converts the lead report to the target format GetContentType() → string / / Returns HTTP Content-Type Validate(data []byte) → error / / Validate the output format. Specific implementation: JSONAdapter: Outputs standard JSON format (default), Content-Type: application / json XMLAdapter: Outputs XML format for integration with traditional ERP systems; CSVAdapter: Outputs CSV format for batch importing into CRM systems; Adaptation and conversion logic: The system maintains a receiver configuration table, recording information such as supported data formats, interface URLs, and authentication methods for each receiver. During push notifications, the system automatically selects the corresponding Adapter for format conversion based on the receiver's configuration.

[0195] Specific rules and encryption mechanisms for data anonymization: (1) The de-identification rules in the log are consistent with the sensitive information processing rules in Section 2.2.2 (phone numbers, email addresses, ID cards, etc. are all masked).

[0196] (2) Encryption of sensitive fields: All requests are transmitted via HTTPS (TLS 1.3) encryption when pushing APIs.

[0197] (3) Encryption of sensitive fields: Sensitive fields such as contact and company in the database are encrypted using the AES-256-GCM symmetric encryption algorithm. The encryption key is managed by a key management service (KMS) and the key is automatically rotated every 90 days. Decryption is only performed when the business layer needs to display the data, and the decrypted data is not written to any logs.

[0198] Furthermore, the NFC design in this application can also be replaced with a QR code or a geofence; QR code links have wider compatibility and are supported by almost all smartphones; however, they require users to actively scan the code, making them slightly less convenient than the one-touch access of NFC. Geofencing, based on GPS location triggering, is suitable for large-scale scenarios.

[0199] Furthermore, a collaborative implementation of QR codes and NFC can be achieved by integrating an NFC chip and a printed QR code onto the same physical card. The QR code's encoded content is completely identical to the NFC's NDEF payload (i.e., the same URL, including uid, ts, and sig parameters). During user interaction, NFC is prioritized (triggered upon proximity). When NFC is unavailable (e.g., the phone's NFC function is disabled or the model does not support it), the user can scan the QR code on the card as an alternative. On the front of the card, the QR code is located in the lower right corner (20mm x 20mm), accompanied by the dual-entry prompt "NFC tap / scan also work." Integration requirements: The NFC antenna coil layout must avoid the QR code printing area to prevent the metal antenna from interfering with the QR code's optical recognition.

[0200] Furthermore, the geofencing accuracy optimization scheme and trigger distance threshold are as follows: (1) Accuracy optimization: A triple positioning fusion scheme of GPS + Wi-Fi fingerprint + Bluetooth beacon (BLE Beacon) is adopted. In outdoor scenarios, GPS is the main method (accuracy of about 3~5 meters), in indoor scenarios, Bluetooth beacon is the main method (accuracy of about 1~3 meters), and Wi-Fi fingerprint is used as a supplement.

[0201] (2) Trigger distance threshold: can be configured according to the deployment scenario. For exhibition scenarios, it is set to 50 meters (around the booth), for shopping mall scenarios, it is set to 200 meters (at the mall entrance), and for park scenarios, it is set to 500 meters. When a user enters the geofence range, the system will guide the user to visit the AI ​​interaction page through push notification.

[0202] Furthermore, the interaction carrier can also be replaced with: Furthermore, AI enables technological substitution. (1) Different NLP model architectures: Different large language models such as GPT series, Claude, Wenxin Yiyan, and Tongyi Qianwen can be used, and the choice can be made flexibly according to cost, performance and compliance requirements.

[0203] (2) Knowledge base technology alternatives: Vector databases can be replaced by Pinecone, Weaviate, Qdrant, etc.; relational databases can be replaced by MySQL, Oracle, etc.

[0204] (3) Intent recognition methods: In addition to the BERT classification model, rule-based methods, Few-shot Prompting, and other methods can also be used.

[0205] Furthermore, a unified calling interface and adaptation mechanism for different large language models: The system manages multi-model configurations using a connection string pattern, formatted as provider;base_url;api_key;model_name, for example, openai;https: / / api.openai.com / v1;sk-xxx;gpt-4. Upon system startup, the connection string is parsed, automatically initializing the corresponding adapter instance. Each model adapter internally encapsulates API differences from various vendors (such as request formats, streaming response protocols, and error code systems). The business layer uses a unified LLMClient interface to achieve seamless model switching. It supports configuring different models by functional module (e.g., model A for dialogue, model B for classification, and model C for embedding), with configuration updates being hot-loaded and effective.

[0206] Furthermore, the storage structure adaptation and conversion rules for other vector / relational databases are as follows: The system defines a unified vector storage abstract interface (IVectorStore), including methods such as Insert, Query, and Delete. Different vector databases implement this interface through adapters: the Milvus adapter maps Collection / Field to Milvus native API calls, the Weaviate adapter maps them to Weaviate Class / Property, and the Pinecone adapter maps them to Pinecone Index / Vector. When switching databases, only the storage engine type and connection parameters in the configuration file need to be modified; the business logic layer code remains unchanged. The data migration tool supports exporting data from one vector database and importing it into another.

[0207] Furthermore, the specific implementation of intent recognition based on rules and Few-shot Prompting is as follows: (1) Rule-based: Maintain a keyword-intent mapping dictionary. After segmenting the user input, match it with the dictionary. The matching score = number of matched keywords × sum of keyword weights / sum of total weights. The intent category with the highest score is used as the recognition result. Advantages: Fast inference speed (<5ms), no GPU resources required; Disadvantages: Limited coverage of synonyms and expression diversity.

[0208] (2) Few-shot Prompting: Embed five typical examples (25 examples in total) for each intent category in the LLM's Prompt, requiring the LLM to classify the user input and output JSON results. Advantages: No training data or model fine-tuning required, ready to use out of the box; Disadvantages: High inference latency (200-500ms), and classification stability depends on the quality of the Prompt engineering.

[0209] This application establishes the following technical barriers: (1) Data Barriers: The construction of a knowledge base for real-person subjects requires the accumulation of a large amount of professional data and is deeply bound to specific business scenarios, making it difficult to replicate. The specific types of professional data include: meeting minutes, speech drafts, work reflection notes, social communication records, reading annotations, direct feedback instructions, and other data from nine major scenarios. Data accumulation channels include: voice input (supporting real-time ASR speech-to-text conversion), text input, and document upload (PDF / Word / PPT / Markdown), covering various data generation scenarios in the daily work of experts.

[0210] (2) Algorithm barrier: The multi-level intent recognition, demand clarification, response generation and other algorithms have been trained and optimized with a large amount of data, and have a high technical threshold. Specific directions and effects of algorithm optimization: (1) The first rule framework layer generation algorithm has undergone 6 major version iterations, evolving from a general template to a customized generation strategy based on expert type, and the thought extraction coverage has increased by about 40%; (2) The second rule framework layer compilation algorithm has undergone 4 major version iterations, evolving from simple text splicing to structured rule compilation, supporting "precise targeting" incremental updates, and the dialogue consistency retention rate after knowledge base update is >95%; (3) The hybrid retrieval strategy (vector + keyword + reordering) has been optimized, and the MRR@5 has increased from 0.72 to 0.855.

[0211] (3) Engineering barriers: The implementation of weak network adaptation, high concurrency processing, real-time push and other engineering aspects requires rich practical experience. Verified by actual test: (1) Weak network adaptation: In a weak network environment, the first screen can be interacted for the time required for real-time interaction, and the NFC jump success rate is >95%; (2) High concurrency processing: The system supports 1000 QPS of concurrent dialogue requests through message queue peak shaving and horizontal scaling, and the P99 latency is <500ms (streaming first token latency is <200ms); (3) Real-time push: The end-to-end latency from the generation of clues to the arrival of the real person's main terminal is <1 second (P99 <2 seconds), and the message queue reliability is >99.99%.

[0212] (4) Security Barriers: Multi-layered protection mechanisms ensure system security—HMAC-SHA256 signature anti-forgery / anti-replay at the NFC layer, HTTPS (TLS 1.3) encryption at the transmission layer, AES-256-GCM field-level encryption at the storage layer, and a second-rule framework layer with built-in security shield and anti-reverse engineering protocol at the AI ​​layer (a three-layer defense mechanism to prevent hint injection attacks). The above multi-layered security design forms a defense-in-depth system, requiring attackers to breach multiple security layers simultaneously to compromise the system.

[0213] Example 2: Based on Example 1, this example mainly uses a business exhibition scenario to illustrate the specific implementation process of the intelligent interaction method of the present invention: 1. NFC Card Preparation and Data Encoding The customized NFC card uses the NTAG216 chip, PVC substrate, and an embedded 45-turn copper etched coil antenna. Its dimensions are 85.6mm × 54mm × 0.8mm. Data retention is >10 years, and write endurance is >100,000 cycles. NDEF format URI data is programmed into the chip using an ACR122U NFC reader / writer. The URI data format is “https: / / [domain] / nfc / entry?uid=[UUID]&ts=[Timestamp]&sig=[Signature]”, where UUID is the correct UUID. The v4 standard random value (verified for uniqueness in the database), the Timestamp is the timestamp during the burning process, and the Signature is calculated using the HMAC-SHA256 algorithm (the key is stored in the server HSM, and the parameters to be signed are "uid={UUID}&ts={Timestamp}"). After burning, the readability and correctness of the NFC data are verified by automated testing equipment, and unqualified cards are eliminated. Finally, a customized NFC card for the exhibition is formed, and each card is uniquely bound to the sales personnel (real person) of the exhibiting company.

[0214] 2. User NFC Trigger and Redirect Verification During the exhibition, potential customers (users) will attach customized NFC cards to their mobile phones (smart terminals). After the mobile phone reads the URI data in the NFC card, it will automatically initiate a redirect request. After receiving the redirect request, the server will perform the following legality verifications in sequence: (1) Timestamp verification: the difference between the current time and ts is calculated to be 200 seconds (≤300 seconds), and the verification is successful; (2) Signature verification: using the secret_key in the server's HSM, the expected_sig is calculated using the same algorithm. If it is consistent with the sig in the request, the verification is successful; (3) UUID binding verification: query the database through uid to obtain the associated host_id (corresponding to salesperson A), and the verification is successful. After the verification is successful, the server will write the request source IP, mobile device fingerprint, and timestamp into the access log table, return the redirect URL, and guide the mobile phone to the AI ​​interaction page (mini-program) corresponding to salesperson A.

[0215] 3. AI Digital Thinking Avatar Interaction and Demand Mining After entering the AI ​​interaction page, the user begins a dialogue with the AI ​​digital thinking clone of the bound salesperson A; the layered architecture of the AI ​​digital thinking clone operates as follows: storing the basic profile of salesperson A, such as name, 10 years of B2B sales experience, expertise in industrial equipment sales, and core objective of expanding customers in East China; generating a customized first rule framework layer based on the above profile, focusing on strengthening the dimensions of "customer needs assessment" and "resource matching recommendation" in the decision-making thinking model; the second rule layer is generated by combining the first rule framework layer with the training data such as salesperson A's past sales cases and communication records, including his communication style (direct and efficient, frequently using words such as "solution adaptation" and "precise matching"); the user inputs "I want to know about your company's industrial robots, what are the prices and delivery cycles?", and the AI ​​digital thinking clone performs multi-level intent recognition: (1) Primary intent classification: identified as "product consultation + price inquiry" (high commercial value) through the BERT classification model, with a confidence level of 0.92; (2) Processing process trigger: with a confidence level ≥ 0.9, directly enters the demand mining; (3) Slot Filling: The system identifies filled slots as product type (industrial robot), and missing slots as budget range, usage scenario, time requirement, and contact information. Prioritizing these slots (Contact Information > Usage Scenario > Budget Range > Time Requirement), it asks follow-up questions such as "Would it be convenient to leave a mobile number so we can send detailed information later?", "What are your main plans for using the industrial robot?", "What is your approximate budget range?", and "When do you plan to deploy the equipment?". The user replies with "138XXXX8000", "Automotive parts production line", "500,000-800,000", and "Within 3 months". The AI ​​digital thinking avatar fills the slots using regular expression matching and semantic classification, changing the dialogue status from SLOT_FILLING to CONFIRMATION and displaying a summary of the user's needs: "You want to learn about industrial robots (automotive parts production line scenario), budget 500,000-800,000, planned deployment within 3 months, contact information 138XXXX8000, is that correct?" The user replies "Yes", and the dialogue status changes to COMPLETED.

[0216] 4. Personalized response generation and feedback The AI ​​digital thinking clone determines that the current scenario is a price consultation + product consultation scenario, and generates a reply using a template + RAG fusion method: (1) Template matching: Call the price consultation template "Regarding the price of {{product_name}}, the model price range that is suitable for the {{use_scene}} scenario is {{price_range}}, and the delivery cycle is approximately {{delivery_cycle}}. We will optimize the solution according to your specific needs. Your contact information has been recorded, and a dedicated consultant will contact you later. Is that okay?"; (2) RAG search: Using "industrial robot + automotive parts production line + 500,000-800,000 + 3-month delivery" as the search keywords, relevant knowledge is obtained through a hybrid search strategy. (3) Slot filling and polishing: Fill the template with product_name=industrial robot, use_scene=automotive parts production line, price_range=500,000-800,000, delivery_cycle=3 months, and combine it with the "direct and efficient" communication style of salesperson A. After polishing, generate the reply "Regarding the price of industrial robots, the price range of models that are suitable for automotive parts production line scenarios is 500,000-800,000, and the delivery cycle is about 3 months. We will optimize the solution according to your specific needs. I have recorded your contact information 138XXXX8000. I will arrange a dedicated consultant to connect with you later. Is that okay?" and send it to the user.

[0217] 5. Requirements report generation and lead generation The AI ​​digital thinking avatar extracted the above dialogue into a structured customer needs report. The report_id is “RPT-20240615-001”, the customer_info includes customer ID “C-67890”, contact number “138XXXX8000”, company name (not mentioned by the user, left blank), the conversation_summary is “User inquires about industrial robots (automotive parts production line scenario), budget 500,000-800,000 RMB, planned deployment within 3 months, contact information 138XXXX8000”, and requirements are [{"type":"product requirements"," Description: "Industrial robot (automotive parts production line scenario)", "confidence": 0.98}], Budget: {"amount": "500,000-800,000", "currency": "CNY", "confidence": 0.95}, Urgency: {"level": "medium-high", "expected_time": "within 3 months", "confidence": 0.96}, Intent_tags: ["product inquiry", "price inquiry", "high intention"]; Lead scoring calculation: Demand clarity (5 required fields) The following criteria are applied: 1) Fully filling all slots (100 points, 100 x 0.30 = 30 points); Completeness of contact information (providing a mobile phone number, 100 points, 100 x 0.25 = 25 points); Budget clarity (clearly defining the amount range, 100 points, 100 x 0.20 = 20 points); Urgency level (within 3 months, 80 points, 80 x 0.15 = 12 points); Interaction activity level (6 rounds of dialogue, 100% positive emotion, min(6 / 10,1) x 60 + 1 x 40 = 36 + 40 = 76 points, 76 x 0.10 = 7.6 points); Total score: 30 + 25 + 20 + 12 + 7.6 = 94.6 points; Lead priority is determined as P0 level (≥85 points). The message is pushed to the backend platform via API, triggering multi-channel notifications: Salesperson A's mobile app receives a full-screen pop-up and sound alert ("[New Lead] You have a high-potential customer inquiry. Customer needs: industrial robot (automotive parts production line scenario), budget 500,000-800,000 RMB, delivery within 3 months, contact number 138XXXX8000, it is recommended to call within 30 minutes"). Simultaneously, a text message notification is received ("[AI Assistant] You have an urgent customer inquiry. Please log in to the backend for details"). A conversation summary and demand report are pushed to WeChat. After seeing the notification, Salesperson A contacts the user by phone within 30 minutes to advance subsequent cooperation negotiations.

[0218] Furthermore, during system operation, the NFC interaction module, verification jump module, AI digital thinking clone module, and demand extraction and push module used above communicate with each other through REST API, WebSocket, and other methods. Data transmission is encrypted with HTTPS (TLS 1.3) to ensure data security. The system supports high QPS concurrent requests and P99 latency <500ms, meeting the needs of high-density user access scenarios such as exhibitions.

[0219] The NFC interaction module is deployed on the user's mobile phone (a smart terminal that supports NFC function). It reads the NDEF format URI data of the customized NFC card through the mobile phone's NFC hardware, parses out the uid, ts, and sig parameters, calls the mobile browser to initiate a redirect request, and supports Web NFC API adaptation to Chrome Android browser to ensure the reliability of data reading. The verification redirection module is deployed on an Alibaba Cloud ECS server (4 cores and 8GB configuration) and includes a timestamp verification unit (calculating the time difference and determining validity), a signature verification unit (calling the HSM interface to calculate and compare the signature), a UUID binding verification unit (querying the user_uuid association table in the PostgreSQL database), and an access log recording unit (writing access logs to the access_log table in PostgreSQL). Each unit is integrated through the Spring Boot framework, with a response latency of <300ms.

[0220] The AI ​​digital thinking avatar module is deployed on an Alibaba Cloud GPU server (16 cores, 32GB GPU configuration). The intent recognition unit integrates a pre-trained language model (locally deployed), the demand mining unit maintains the dialogue state through Redis Hash, and the response generation unit integrates a vector database (4GB memory, 500GB SSD), Elasticsearch (single-node deployment, IK word segmenter), a fine ranking model, and a large language model (called via API). The demand extraction and push module is deployed on an Alibaba Cloud ECS server (4 cores and 8GB configuration). The demand extraction unit integrates an information extraction model (locally deployed). The report generation unit assembles a demand report according to a preset schema. The clue scoring unit calculates the score according to a multi-dimensional weighted formula. The API push unit pushes the demand report through a RabbitMQ message queue (3-node cluster, QuorumQueue). The notification unit integrates APNs (iOS), FCM (Android), Alibaba Cloud SMS service, Tencent Enterprise Email, and WeChat Webhook interface to achieve multi-channel notification push.

[0221] Furthermore, this application may also add a benefits-giving function when users use this product, including but not limited to various methods such as giving gifts upon first registration, giving a single privilege on the first card, and various benefits such as phone credit and gas coupons.

[0222] The above description is merely a preferred embodiment of the present invention and does not limit the scope of protection of the present invention. For those skilled in the art, the present invention can have various modifications and variations. Any changes, modifications, substitutions, integrations, and parameter alterations to these embodiments within the spirit and principles of the present invention, achieved through conventional substitutions or by achieving the same function without departing from the principles and spirit of the present invention, fall within the scope of protection of the present invention.

Claims

1. A smart interaction method based on NFC and AI digital thinking avatar, characterized in that, Includes the following steps: Step S1: The user attaches the customized NFC card to the smart terminal, and the smart terminal reads the data in the NFC card and initiates a jump request; Step S2: The server verifies the legitimacy of the redirection request. If the verification is successful, the smart terminal is redirected to the AI ​​interaction page corresponding to the real person bound to the NFC card. Step S3: The user engages in dialogue with the AI ​​digital thinking avatar bound to the real person on the AI ​​interaction page. The AI ​​digital thinking avatar performs intent recognition and demand mining based on the user's input. Step S4: Based on the intent recognition results and mining needs, the AI ​​digital thinking clone generates a personalized response and sends it back to the user through a combination of enhanced retrieval and preset templates. Step S5: The AI ​​digital thinking avatar extracts unstructured dialogue content into a structured customer needs report, calculates lead scores based on a multi-dimensional weighted model, and pushes the customer needs report to the real human subject's terminal according to the priority of the lead scores, so that the real human subject can follow up.

2. The intelligent interaction method based on NFC and AI digital thinking avatar as described in claim 1, characterized in that, In step S1, the NFC card stores URI data in NDEF format. The URI data includes: the unique UUID of the NFC card, a timestamp, and a signature calculated based on the HMAC-SHA256 algorithm using the UUID and timestamp. In step S2, the legality verification includes: timestamp validity verification, signature consistency verification, and UUID binding relationship verification with the real person subject. If any verification fails, the server rejects the redirection request.

3. The intelligent interaction method based on NFC and AI digital thinking avatar as described in claim 1, characterized in that, In step S3, the AI ​​digital thinking clone is uniquely bound to the real person through a layered architecture. The layered architecture includes: an identity information layer that stores the basic portrait of the real person, a first rule framework layer for structurally extracting the thinking patterns of the real person, and a second rule layer that is compiled and generated by the first rule framework layer in combination with training data and serves as prompt words for the dialogue system. The AI ​​digital mind clone injects the second rule layer as system prompts into the dialogue context, enabling an immersive dialogue that is consistent with the real person.

4. The intelligent interaction method based on NFC and AI digital thinking avatar as described in claim 1, characterized in that, In step S3, the intent recognition is a multi-level recognition aimed at business conversion, including the following steps: Step S31: Perform preliminary intent classification on user input using a BERT-based classification model to obtain intent categories with different commercial value levels. The intent categories include product inquiries, price inquiries, casual conversation, technical support, complaints and suggestions, and corresponding confidence levels. Step S32: Trigger different processing flows based on confidence level: When confidence level ≥ 0.9, proceed directly to requirement mining; when confidence level is between 0.8 and 0.9, proceed to requirement mining after simple confirmation; when confidence level is between 0.6 and 0.8, proceed to requirement mining after clarifying the intent through reverse questioning; when confidence level < 0.6, provide a fallback response or transfer to manual processing. Step S33: For high-commercial-value intentions such as product inquiries and price requests, conduct multiple rounds of dialogue through missing slot identification and priority ranking to complete the filling of demand slots.

5. The intelligent interaction method based on NFC and AI digital thinking avatar as described in claim 1, characterized in that, In step S4, the method for generating enhanced retrieval combined with a preset template includes: The interaction scenario is determined based on intent confidence, template matching degree, and user input complexity. Standard question-and-answer scenarios prioritize template generation; Complex consultation scenarios utilize search-enhanced generation; Casual conversation scenarios are generated directly using a large language model; For price and product inquiries, a template is used to build the response framework, knowledge is acquired and filled into the slots through the Retrieval Enhancement Generation (RAG) method, and then personalized polishing is done by combining the communication style of the real person.

6. The intelligent interaction method based on NFC and AI digital thinking avatar as described in claim 5, characterized in that, The retrieval enhancement generation method adopts a hybrid retrieval strategy: first, relevant knowledge fragments are retrieved from the knowledge base through vector retrieval and keyword retrieval respectively; then, the results of the two retrievals are fused through the RRF algorithm; and finally, the target knowledge fragments are obtained by reordering through the Cross-Encoder model for response generation.

7. The intelligent interaction method based on NFC and AI digital thinking avatar as described in claim 1, characterized in that, In step S5, the calculation dimensions of the multi-dimensional weighted model include requirement clarity, contact information completeness, budget clarity, urgency, and interaction activity; the sum of the weights of each dimension is 1, where requirement clarity has the highest weight and is not less than 0.25, contact information completeness has the second highest weight and is not less than 0.20, budget clarity has a weight not less than 0.15, urgency has a weight not less than 0.10, and interaction activity has a weight not less than 0.05; Each dimension is scored separately, then multiplied by its corresponding weight, and finally weighted and summed to obtain a clue score of 0-100. The clue scoring is divided into three priority levels: Leads scoring 85 points or higher, or users explicitly expressing their willingness to contact the real person in the conversation, are designated as P0 level and pushed immediately. Clues with a score of 60-84 points within the medium priority threshold range are classified as P1 and will be pushed out within a preset time. Clues with a score below the medium priority threshold (<60 points) are classified as P2 level and will be aggregated and pushed out according to a preset cycle.

8. The intelligent interaction method based on NFC and AI digital thinking avatar as described in claim 1, characterized in that, It also includes a weak network adaptation strategy that is compatible with the entire process of NFC jumps and AI interactions. The weak network adaptation strategy includes: Core static resources are cached in the local storage of the smart terminal. The cache validity period is 7 days, and a cache update mechanism combining incremental update and full update is adopted. The skeleton screen technology enables progressive page loading, prioritizing the loading of critical path resources necessary for the first screen rendering; The network status is determined by combining browser network status detection with timed heartbeat detection. When the network is completely unavailable, an offline prompt page is displayed and user access logs are recorded. Once the network is restored, the user access logs are automatically retransmitted in batches.

9. An intelligent interaction system based on NFC and AI digital thinking avatar, used to implement the intelligent interaction method based on NFC and AI digital thinking avatar as described in any one of claims 1-8, characterized in that, include: NFC interaction module, verification redirection module, AI digital thinking clone module, and demand extraction and push module; The NFC interaction module is used to realize data interaction and jump request initiation between the customized NFC card and the smart terminal; The verification and redirection module is deployed on the server side and is used to verify the legality of the redirection request and guide the smart terminal to the AI ​​interaction page corresponding to the real person bound to the customized NFC card. The AI ​​digital thinking avatar module is uniquely bound to the real person and is used to identify user input for business conversion purposes, mine needs, and generate personalized responses. The demand extraction and push module is used to extract unstructured dialogues into structured customer demand reports, calculate lead scores based on a multi-dimensional weighted model, and push customer demand reports to the real human terminal according to the lead score priority. The NFC interaction module, verification jump module, AI digital thinking clone module, and demand extraction and push module are connected in pairs for communication.

Images