Fine-tuning voice large model to drive air flow full-duplex dispatching closed-loop system

Abstract

The application discloses a fine-tuning voice large model driven logistics full-duplex dispatching closed-loop system and relates to the technical field of artificial intelligence voice interaction. The application discloses a fine-tuning voice large model driven logistics full-duplex dispatching closed-loop system and relates to the technical field of artificial intelligence voice interaction. The application discloses a fine-tuning voice large model driven logistics full-duplex dispatching closed-loop system and relates to the technical field of artificial intelligence voice interaction. The application discloses a fine-tuning voice large model driven logistics full-duplex dispatching closed-loop system and relates to the technical field of artificial intelligence voice interaction. The application discloses a fine-tuning voice large model driven logistics full-duplex dispatching closed-loop system and relates to the technical field of artificial intelligence voice interaction. The application discloses a fine-tuning voice large model driven logistics full-duplex dispatching closed-loop system and relates to the technical field of artificial intelligence voice interaction. The application discloses a fine-tuning voice large model driven logistics full-duplex dispatching closed-loop system and relates to the technical field of artificial intelligence voice interaction.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence voice interaction technology, and in particular to a closed-loop system for full-duplex logistics delivery driven by a finely tuned large voice model. Background Technology

[0002] With the increasing demand for voice interaction in last-mile delivery services such as outbound confirmation, order modification communication, and anomaly follow-up, existing logistics voice interaction systems are gradually introducing large-scale voice models, full-duplex dialogue, and work order interface linkage to replace the traditional manual registration and one-way broadcast customer service process. Existing solutions typically focus on voice recognition accuracy, intent classification, interruption detection, and work order creation. However, they lack unified data association processing for the temporal relationship between the user's audio on the call end, the response audio on the playback end, the playback position, and the work order interface execution record. This makes it difficult for the system to accurately distinguish between content the user has already heard, content generated by the model but not yet played, operations already executed in the background, and operations only in a pending verification state when the user interrupts, confirms short sentences, continuously modifies delivery requests, or experiences delayed work order receipt returns. This affects the consistency of delivery request parsing, work order submission, and voice feedback.

[0003] Existing full-duplex voice systems in logistics often handle user interruptions by stopping the current broadcast, re-recognizing the user's audio, and generating a new response. Internally, these systems typically only record the dialogue text, recognition results, and work order return results, failing to accurately determine the range of response audio that had already been played before the user spoke, based on the playback position. Since the generation, queuing, and actual playback of response audio at the playback end are not identical, the model, when understanding user confirmations, negations, and revisions, easily uses unplayed response audio as contextual basis, establishing a confirmation relationship between the user's audio and incorrect response segments. For common operations in logistics delivery scenarios such as address changes, rescheduling, and placement location adjustments, user expressions often rely on recently heard delivery fields and target values. If the system cannot establish stable interactive evidence between the user's audio and already played response audio, it will be difficult to determine the actual delivery field corresponding to a brief confirmation segment, and it will be difficult to maintain a waiting state before the revision content is complete. This can lead to problems such as premature submission, field mismatch, and repeated queries. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention provides a closed-loop logistics delivery system driven by a finely tuned large voice model.

[0005] This invention provides a closed-loop logistics delivery system driven by a fine-tuned large voice model, comprising: The acquisition module is used to acquire user audio from the call end, response audio from the playback end and playback position, work order interface execution records, record available time, and associate user audio with played response audio according to playback position to form interactive evidence; The fine-tuning module is used to capture interaction evidence and execution records at available times, construct training prefixes with the same interaction evidence but different execution records, label delivery requirements based on interaction evidence, label operation instructions based on the differences between delivery requirements and execution records, and fine-tune the prediction results and labeling deviations of the training prefixes by the speech big model. The dual-view reasoning module is used to establish a shared parameter and cache-separated understanding view and generation view in the fine-tuning speech model. The understanding view only parses the delivery requirements based on the interaction evidence, while the generation view re-encodes the delivery requirements and execution records into decision prefixes, generates operation instructions based on the decision prefixes, and then generates response audio, recursively tracing cache source dependencies along the attention connection. The cache recovery module is used to update the interaction evidence according to the playback position at the start of the interruption, revoke unplayed response audio, remove caches that reference unplayed response audio according to source dependency, re-encode the interaction evidence and the retained execution records according to the dual-view input range, and restore dual-view inference. The work order closed-loop module is used to query the work order interface verification execution record according to the operation command, compare the verification result with the delivery requirement, submit only the unexecuted difference work orders, write the receipt to the execution record and backflow to generate the view, generate the response audio and send it to the playback end for parallel playback with the user's audio reception.

[0006] In summary, the present invention has at least one of the following beneficial technical effects: 1. The present invention provides a closed-loop logistics delivery system based on a fine-tuned large-scale voice model, which associates user audio with played response audio to form interactive evidence. It also constructs training prefixes based on available time, where the interactive evidence is the same but the execution records differ, maintaining consistent delivery requirement labeling. Operation instructions are labeled according to differences in execution records, ensuring consistent requirement interpretation by the model. Furthermore, it distinguishes between submission, query, and result feedback based on execution records. By establishing a shared parameter and cache-separated understanding and generation view, the data reading range for requirement parsing and operation judgment is separated, reducing interference from unplayed response audio on confirmation relationships, lowering the risk of delivery field mismatch and premature submission, ensuring consistency between training and online inference bases, and improving the accuracy of requirement understanding and the reliability of operation generation under continuous interruption conditions.

[0007] 2. This invention recursively traces cache source dependencies along attention connections. After an interruption occurs, caches that directly or indirectly reference unplayed response audio are removed, while consecutive prefix caches that meet the conditions are retained. This reduces residual invalid content and unnecessary recalculation, while retaining execution records of sent operations to prevent loss of actual execution status due to broadcast cancellation. Based on this, combined with the requirement revision number, operation identifier, and verification results, only unexecuted difference work orders are submitted, reducing the risk of false confirmations of old receipts and duplicate writing. Before playback, the execution stage corresponding to the response audio is verified; if execution is completed but the feedback is not fully played, only the result feedback is supplemented, ensuring consistency between voice recovery, work order execution, and result feedback, improving the reliability of the delivery closed-loop processing and the traceability of execution records. Attached Figure Description

[0008] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0009] Figure 1 This is a framework diagram of a closed-loop logistics delivery system based on a finely tuned large voice model, provided in an embodiment of the present invention.

[0010] Figure 2 This is a schematic diagram of the fine-tuning module training prefix construction and model fine-tuning process provided in the embodiments of the present invention.

[0011] Figure 3 This is a schematic diagram of the cache recovery and dual-view inference recovery process based on interrupt triggering provided in an embodiment of the present invention.

[0012] Figure 4 This is a schematic diagram of the work order closed-loop verification and differential work order generation and submission process provided in the embodiments of the present invention. Detailed Implementation

[0013] The following description, in conjunction with the implementation of the present invention, is merely an example and illustration of the concept of the present invention. Those skilled in the art can make various modifications or additions to the specific embodiments described, or use similar methods to replace them, as long as they do not deviate from the concept of the invention, and all such modifications and additions should fall within the protection scope of the present invention.

[0014] Example This invention is applicable to communication scenarios in last-mile delivery of express logistics. The processing objects include user audio on the call end, response audio on the playback end, playback location, and work order interface execution records. The system continues to receive user audio on the call end while outputting response audio on the playback end. It maintains consistency between voice understanding, work order operation, and voice feedback in cases such as user interruption, confirmation, modification of delivery address, modification of delivery time, and adjustment of placement location. This implementation adopts a full-duplex intelligent voice interaction system framework for last-mile delivery scenarios in express logistics. This framework involves the fields of artificial intelligence voice large-scale models, full-duplex human-machine dialogue, audio noise reduction preprocessing, and intelligent customer service work order automation. The core is that the system does not use generated but unplayed response audio as the basis for user semantic understanding, nor does it delete already occurred work order interface execution records due to the cancellation of unplayed response audio. Instead, it relies on the data correlation between interaction evidence, delivery requirements, execution records, cache source dependencies, and playback location to restore the dual-view reasoning of the fine-tuned voice large-scale model and complete the delivery loop accordingly.

[0015] This application discloses a closed-loop logistics delivery system driven by a finely tuned large voice model.

[0016] Reference Figures 1 to 4 A closed-loop logistics delivery system driven by a finely tuned large voice model, including: The system is deployed between the logistics customer service server and the voice communication gateway. The acquisition module connects the call terminal, the playback terminal, and the work order interface. The fine-tuning module performs training tasks in the offline training server. The dual-view inference module, the cache recovery module, and the work order closed-loop module are deployed in the online inference server.

[0017] The acquisition module is used to acquire user audio from the call end, response audio from the playback end and playback position, work order interface execution records, record available time, and associate user audio with played response audio according to playback position to form interactive evidence; Specifically, the user audio on the call end is represented using a 16kHz, 16-bit, mono PCM audio stream, buffered as an audio frame every 20 milliseconds; the response audio on the playback end is output using the same sampling rate, and the playback position is indicated by the sampling point number in the response audio; the work order interface execution record is represented using a structured record, including operation identifier, waybill identifier, requirement revision number, delivery field, target value, operation status, receipt content, verification result, and available time. All of the above data, after entering the system, are written to a timing buffer under the same time base. This time base can be the server clock count, in milliseconds, used to compare the order of data, and does not participate in determining the business meaning.

[0018] During system operation, the acquisition module first obtains the user's audio from the calling end and records the start and reception times of that audio segment. Simultaneously, it obtains the response audio from the playback end, the playback position, and the actual playback time corresponding to that position. It also retrieves the execution record of the work order interface corresponding to the current call from the work order interface. The playback position is not the moment the response audio was sent to the playback end, but rather the sampling point position where the playback end has actually completed playback; therefore, it reflects the range of response audio that the user heard before starting to speak.

[0019] The acquisition module unifies the start acquisition time, actual playback time, and reception time to the same time base. The reception time of the user's audio at the call end is taken as the available time for that user's audio, and the reception time of the work order interface execution record is taken as the available time for that work order interface execution record. For a segment of user audio at the call end with a start acquisition time of 12,000 milliseconds, the acquisition module filters playback positions from the already received playback positions, ensuring the actual playback time is no later than 12,000 milliseconds. If the latest playback position obtained is 96,000 sampling points, the playback end's response audio is extracted from the range of 0 to 96,000 sampling points to obtain the played response audio. The acquisition module then compares the reception completion time of this played response audio with the reception time of the playback position, taking the later time as the available time for the played response audio. The user's audio segment is then associated with the played response audio to form interactive evidence. This interactive evidence simultaneously retains the user's audio, the played response audio, and their respective available times. Subsequent interpretation views only rely on the interactive evidence to analyze delivery requirements, avoiding the use of content the user has not yet heard to interpret the user's voice.

[0020] The fine-tuning module is used to capture interaction evidence and execution records at available times, construct training prefixes with the same interaction evidence but different execution records, label delivery requirements based on interaction evidence, label operation instructions based on the differences between delivery requirements and execution records, and fine-tune the prediction results and labeling deviations of the training prefixes by the speech big model. Specifically, in the offline phase, the fine-tuning module constructs training prefixes using the interaction evidence and execution records saved by the acquisition module. The fine-tuning module sequentially selects the available times of the interaction evidence and execution records as cutoff times, retaining data whose available times are no later than these cutoff times, thus obtaining training prefixes that meet the online visibility condition. For multiple training prefixes with the same interaction evidence but different execution records, the fine-tuning module sets the same delivery demand label for these training prefixes, enabling the large speech model to learn that the same user speech should correspond to the same delivery demand under the same played response audio.

[0021] The fine-tuning module then labels the operation instructions based on the differences between the delivery request and the execution record, enabling the voice model to learn that the same delivery request should correspond to different subsequent operations under different execution records. For example, if the user has confirmed that the delivery address in the delivery field of the waybill number ending in 2741 has been changed to Building 3, Park A, and if there is no corresponding operation to be verified in the training prefix and the current effective value of the work order interface is still the original address, the operation instruction is labeled as "submit"; if the training prefix already contains the operation to be verified corresponding to the same request revision number, the operation instruction is labeled as "query"; if the verification result shows that the current effective value already meets Building 3, Park A, the operation instruction is labeled as "result feedback". The above labeling is not directly inferred from the final result of the complete call, but is determined by the data available before the interception time, thus consistent with the data visibility range in online inference.

[0022] In this implementation, the large-scale speech model adopts an end-to-end structure, with initial parameters being the basic parameters of the large-scale speech model before fine-tuning of the logistics speech. In one feasible structure, the large-scale speech model includes an audio encoding front-end, a 32-layer Transformer backbone, a structured control output unit, and a speech decoding unit. The hidden dimension is 4096, the number of attention heads is 32, and the feedforward intermediate dimension is 11,080. The audio encoding front-end converts 20-millisecond audio frames into audio features. The structured control output unit outputs delivery requirements and operation instructions, and the speech decoding unit generates speech tags corresponding to the response audio. The fine-tuning module freezes the basic parameters of the large-scale speech model and sets low-rank adaptation parameters in the attention projection layer. The low-rank adaptation parameters can be set in query projection, key projection, value projection, and output projection. The low-rank value can be between 8 and 64, with smaller rank values ​​used for resource-constrained scenarios and larger rank values ​​used for scenarios with many types of delivery fields.

[0023] During training, in each attention layer, only the reading location for interactive evidence is open for the delivery demand prediction stage, while the reading location for delivery demand and execution records is open for the operation instruction prediction stage. The fine-tuning module calculates the negative logarithmic loss for the prediction probabilities of the corresponding labels based on the delivery demand prediction results and the operation instruction prediction results, respectively. Both negative logarithmic losses are obtained by taking the logarithm and inverse of the prediction probabilities that are greater than zero and not greater than one, and are dimensionless training values, not directly added to dimensional data such as milliseconds or sampling points. The fine-tuning module adds the two losses and then updates the low-rank adaptation parameters in reverse to obtain the fine-tuned speech model. The training process can use a learning rate of 1 / 50,000 to 1 / 10,000. The training stops when the negative logarithmic loss on the validation set does not decrease further within a preset number of rounds. After training, only the basic parameters and low-rank adaptation parameters are loaded for online inference.

[0024] The dual-view reasoning module is used to establish a shared parameter and cache-separated understanding view and generation view in the fine-tuning speech model. The understanding view only parses the delivery requirements based on the interaction evidence, while the generation view re-encodes the delivery requirements and execution records into decision prefixes, generates operation instructions based on the decision prefixes, and then generates response audio, recursively tracing cache source dependencies along the attention connection. Specifically, during the online inference phase, the dual-view inference module establishes a shared-parameter understanding view and a separate-caching view within the fine-tuned speech model. Shared parameters mean that the understanding view and the generation view use the same set of basic parameters and low-rank adaptation parameters. Separate caching means that the understanding view and the generation view each store their own caches within their respective attention layers, and the cache corresponding to the response audio generation position in the generation view is not directly provided to the understanding view. The understanding view reads the interaction evidence from the acquisition module and sets the execution records and the positions corresponding to unplayed response audio in each attention layer as unreadable positions.

[0025] Subsequently, based on the interaction evidence, the waybill identifier, delivery field, and target value are extracted. The confirmation relationship between the user's audio and the played response audio is written into the delivery request, and the corresponding audio interval is recorded. If the played response audio fully plays a segment about the delivery address being Building 3 in Park A, and the user's audio is correct, for this type of short confirmation segment, the understanding view associates this short confirmation segment with the segment to be confirmed in the played response audio, forming a delivery request containing the waybill identifier, delivery field, target value, and audio interval. The generation view then re-encodes the delivery request and execution record into a decision prefix. First, it generates an operation instruction based on the decision prefix, and then generates the response audio after the decision prefix. Since the operation instruction is generated before the response audio, when the operation instruction is generated again later, the dual-view inference module reconstructs the decision prefix based on the updated delivery request and execution record, without using the cache corresponding to the response audio generation position, thereby avoiding the generated voice content from negatively affecting the work order operation judgment.

[0026] The cache recovery module is used to update the interaction evidence according to the playback position at the start of the interruption, revoke unplayed response audio, remove caches that reference unplayed response audio according to source dependency, re-encode the interaction evidence and the retained execution records according to the dual-view input range, and restore dual-view inference. Specifically, when an interruption occurs during a call, the cache recovery module updates the interaction evidence based on the playback position at the start of the interruption. Assuming the playback end has generated three segments of response audio, the first segment has finished playing, only the first half of the second segment has played, and the third segment is still in the playback queue, if the user starts speaking, the cache recovery module removes the unplayed response audio from the playback queue, extracts the response audio segments that cross the playback position according to the already played sampling range, and uses the extracted already played response audio as the source identifier for the new audio segment allocation.

[0027] The cache recovery module then removes caches that reference unplayed response audio based on source dependency, and re-encodes the interaction evidence and retained execution records according to the dual-view input range to restore dual-view inference. This recovery is not simply clearing the entire history, nor is it merely deleting the unplayed response audio itself; rather, it checks whether the cache directly or indirectly references the unplayed response audio. If a cache is calculated from user audio, but the preceding state corresponding to the unplayed response audio has already been read during the calculation, that cache is also removed. If a cache only references the source identifier in the updated interaction evidence, and the input marker, marker position, and attention visibility range remain unchanged, it can be retained as a continuous prefix cache. This reduces invalid recalculations and avoids retaining intermediate states affected by unplayed response audio.

[0028] The work order closed-loop module is used to query the work order interface verification and execution records according to the operation instructions, compare the verification results with the delivery requirements, submit only the unexecuted difference work orders, write the receipt to the execution record and backflow to generate the view, generate the response audio and send it to the playback end for parallel playback with the user's audio reception. Specifically, after generating the view output operation instructions, the work order closed-loop module first queries the work order interface according to the operation instructions to verify the execution record. If the delivery request does not contain a pending completion mark and there are no pending verification operations involving the same delivery field in the execution record, the work order closed-loop module compares the target value corresponding to the current requirement revision number with the current effective value obtained from the work order interface query item by item, extracts inconsistent delivery fields and target values, and generates a difference work order. Taking the user request to change the delivery time to 6 PM as an example, if the current effective value is still 7 PM, the work order closed-loop module generates a difference work order containing the waybill identifier, requirement revision number, delivery field, delivery time, and target value of 6 PM; if the current effective value is already 6 PM, the difference work order is not submitted, but the verification result is only fed back to the generated view, and the generated view generates the response audio of the result feedback. The work order closed-loop module assigns an operation identifier to the difference work order, associates the operation identifier, waybill identifier, requirement revision number, delivery field, and target value into the execution record, and then submits the difference work order to the work order interface. After the receipt is returned, the work order closed-loop module updates the corresponding execution record based on the operation identifier carried in the receipt, and writes the receipt into the execution record feedback generation view. The generation view then generates a response audio and sends it to the playback end. During this period, the playback end's response audio output and the caller's audio reception occur in parallel, and subsequent playback positions continue to be fed back to the acquisition module to form new interaction evidence.

[0029] Furthermore, the data acquisition module specifically includes: The system obtains user audio and start collection time from the call end, response audio, playback position and corresponding actual playback time from the playback end, and execution record corresponding to the current call from the work order interface. The system records the reception time, unifies the start collection time, actual playback time and reception time to the same time base, and uses the reception time of user audio and execution record as the corresponding available time. For each user audio segment, select playback positions whose actual playback time is no later than the start time from the received playback positions, select the playback position with the latest actual playback time, and extract the response audio according to the completed playback sampling range indicated by it to obtain the played response audio. The receiving completion time of the played response audio is compared with the receiving time of the selected playback position, and the later time is taken as the available time of the played response audio. The user's audio is associated with the played response audio to form interaction evidence, and their respective available moments are retained. If no playback position that meets the criteria is found, the played response audio in the interaction evidence is recorded as empty. The interaction evidence and execution record are saved and transmitted to the fine-tuning module respectively. The interaction evidence is transmitted to the understanding view, and the execution record is transmitted to the generation view.

[0030] In a specific embodiment, the implementation of the acquisition module can be further refined. The user audio acquired by the acquisition module from the caller includes the audio frame sequence number, start acquisition time, end acquisition time, and reception time. The response audio acquired from the playback terminal includes the response audio version, speech segment boundaries, and audio sampling point range. The playback position includes the response audio version, the sampling point sequence number that has been played, and the actual playback time. The work order interface execution record is formed by the query results, submission results, and receipt results of the work order interface. Each record is appended with the reception time on the acquisition module side. The acquisition module unifies the above times to milliseconds, allowing direct comparison of the start acquisition time, actual playback time, and reception time under the same time base.

[0031] For each segment of user audio from a call, the acquisition module filters playback positions whose actual playback time is no later than the initial acquisition time. The latest playback position is selected as the playback boundary that can be referenced for the user's voice in that segment. Then, the response audio is extracted according to the completed playback sampling range indicated by this playback position. If no playback position matching the criteria is found, it means that there was no identifiable played response audio before the user spoke. The acquisition module records the played response audio in the interaction evidence as empty, and the subsequent understanding view must not use unplayed content as a confirmation object. The acquisition module saves the interaction evidence and execution records separately. The interaction evidence is transmitted to the fine-tuning module and the understanding view, while the execution records are transmitted to the fine-tuning module and the generation view, thus separating the understanding basis from the execution basis at the data source.

[0032] Furthermore, the fine-tuning module specifically includes: The available time of the interaction evidence and the execution record are used as the cutoff time in turn. Data with available time no later than the cutoff time are retained. Training prefixes with the same interaction evidence but different execution records are constructed. The same delivery requirement label is set for the same interaction evidence. For confirmed delivery requests, training prefixes that do not contain corresponding verification operations and have unexecuted differences are marked as submissions, training prefixes that contain corresponding verification operations are marked as queries, and training prefixes that do not contain corresponding verification operations and whose verification results meet the delivery requirements are marked as result feedback. In each attention layer, only the reading location of interactive evidence is opened for the delivery demand prediction stage, while the reading location of delivery demand and execution record is opened for the operation instruction prediction stage. The basic parameters of the large speech model are frozen, and low-rank adaptation parameters are set in the attention projection layer. The negative log loss is calculated for the prediction probability of the corresponding labels based on the prediction results of delivery demand and operation instructions, respectively. The two losses are added together and the low-rank adaptation parameters are updated accordingly to obtain the fine-tuned large speech model.

[0033] In a specific embodiment, in conjunction with the data acquisition process, the fine-tuning module constructs the training prefix using a grouped sample approach. The fine-tuning module sequentially uses the available time of the interaction evidence and execution records as the cutoff time, retaining data no later than the cutoff time and deleting user audio, played response audio, and execution records later than the cutoff time, so that the training prefix simulates the data state that is already readable during online inference. For the same interaction evidence, the fine-tuning module constructs different training prefixes for different execution records: one set does not contain the corresponding operation to be verified and has unexecuted differences; one set contains the corresponding operation to be verified; and one set does not contain the corresponding operation to be verified and the verification result meets the delivery requirements. Since the interaction evidence is the same in the three sets of training prefixes, the delivery requirement labeling remains consistent; based on the different execution records, the operation instructions are labeled as submission, query, and result feedback, respectively. During training, the attention visibility range in the delivery requirement prediction stage only includes the interaction evidence, while the attention visibility range in the operation instruction prediction stage includes both the delivery requirement and the execution record. The resulting fine-tuned speech model does not use background states to change user semantics during the user speech understanding stage, but can use background states to avoid duplicate order placement during the operation judgment stage.

[0034] Furthermore, the fine-tuning module also includes: Select the playback positions corresponding to different complete unconfirmed segments from the same response audio, associate the short confirmation segments in the same user audio with the already played response audio before each playback position, and construct training prefixes with different playback positions; Match the brief confirmation snippets with the last fully played confirmation snippets in each interactive piece of evidence; When a unique match is formed, the delivery requirement is marked based on the matched delivery field and target value, and the execution record marking operation instruction is combined. When no unique match is formed, a "to be completed" flag is written in the delivery request annotation, and the operation instruction is marked as "waiting". The training prefixes with different playback positions and the training prefixes with the same interaction evidence but different execution records are used together to update the low-rank adaptation parameters; During audio encoding, the available time of audio features is determined by the latest available time of all audio required to calculate the audio features. Only audio features whose available time is no later than the truncation time are included in the training prefix, and training prefixes with the same readable data in the same prediction stage have the same label.

[0035] In one specific embodiment, to ensure the fine-tuning speech model correctly processes short confirmation segments, the fine-tuning module selects playback positions corresponding to different complete confirmation segments from the same response audio. It associates the short confirmation segments in the same user's audio with the previously played response audio before each playback position, constructing training prefixes with different playback positions. The confirmation segments can be delivery address confirmation segments, delivery time confirmation segments, and placement location confirmation segments, with segment boundaries recorded by the generating view when generating the response audio. The fine-tuning module matches the short confirmation segments with the last fully played confirmation segments in each interaction evidence. When only one complete confirmation segment can establish a confirmation relationship with the short confirmation segment, it labels the delivery requirement based on the matched delivery field and target value, and combines this with the execution record to label the operation instruction. When no unique match is formed, it writes a "to be completed" mark in the delivery requirement label and labels the operation instruction as "waiting." If the user only correctly states the delivery address and delivery time before the system has fully played them, the training label does not forcibly specify the delivery field, but instead allows the model to learn to wait for completion. During audio encoding, the fine-tuning module determines the available time of an audio feature based on the latest available time of all audio data required to calculate the feature. Only if the available time of an audio feature is no later than the truncation time is the audio feature included in the training prefix, thus avoiding the use of subsequent audio data that has not yet arrived during training. For training prefixes with the same available data in the same prediction stage, the fine-tuning module sets the same label, thereby restricting the model from prematurely changing the current output based on future user order modifications.

[0036] Furthermore, the dual-view reasoning module specifically includes: In each attention layer of the understanding view, the positions corresponding to the execution record and the unplayed response audio are set as unreadable positions; Extract the waybill identifier, delivery field, and target value based on the interaction evidence, write the confirmation relationship between the user's audio and the played response audio into the delivery requirement, and record the corresponding audio interval; Only complete, played response audio segments that refer to a single object are used as confirmation objects. When the user's audio expression is revised and the delivery field and target value are not determined at the same time, the delivery request is marked as pending completion. The generation view generates a waiting instruction based on the pending completion mark. When the user's audio specifies the delivery field and target value, the delivery request is updated and the pending completion mark is cleared. The requirement revision number is assigned according to the order in which the delivery requirement is formed and revised. The requirement revision number is written into the operation instructions and response audio generated accordingly. When the target value of the delivery field is changed to a historical value again, a new requirement revision number is assigned. In the generated view, delivery requests and execution records are encoded as decision prefixes, operation instructions are generated from the decision prefixes, and response audio is generated after the decision prefixes; When generating operation instructions again, the decision prefix is ​​reconstructed based on the updated delivery requirements and execution records, without using the cache corresponding to the response audio generation location.

[0037] In a specific embodiment, in the dual-view reasoning module, the understanding view generates delivery requests using a field-based recording method. The understanding view extracts the waybill identifier, delivery field, and target value based on interaction evidence, and writes the confirmation relationship between the user's audio and the played response audio into the delivery request. The delivery request includes at least the waybill identifier, delivery field, target value, confirmation relationship, audio range, and request revision number. Only complete, played response audio segments with a unique referent can be used as confirmation objects. When the user's audio indicates a revision but the delivery field and target value are not simultaneously determined (e.g., the user initially says no, the address remains unchanged, but the adjusted delivery time is not yet stated), the understanding view marks the delivery request as pending completion. The generation view then generates a waiting instruction based on this pending completion mark, preventing the work order closure module from submitting a discrepancy work order. Once the user's audio from the subsequent call clarifies the delivery field and target value, the understanding view updates the delivery request and clears the pending completion mark. Each time a delivery request is generated and revised, the dual-view reasoning module assigns a request revision number according to the order of generation and revision. Even if the target value of the delivery field changes back to a historical value, a new request revision number is assigned to distinguish different operational reasons based on different voice evidence. The request revision number is written into the generated operation instructions and response audio for version verification by the cache recovery module and the work order closure module.

[0038] Furthermore, the dual-view reasoning module also includes: Assign source identifiers to user audio segments, response audio segments, and record items in the execution record, and associate delivery requests with the source identifiers corresponding to the audio segments they reference; When generating the cache for each attention layer, the source identifier of the current input data is merged with the source identifier carried by the previous state involved in the computation, and then passed along the attention connection level by level to form a source dependency that includes both direct and indirect sources. The source dependencies are associated with and saved with the corresponding caches. At the same time, the input tags, tag positions and attention visibility ranges corresponding to the caches are recorded. The source dependencies, input tags, tag positions and attention visibility ranges are then transmitted to the cache recovery module to determine the retention range of the caches.

[0039] In one specific embodiment, to ensure the cache recovery process has a computable basis, the dual-view inference module also assigns source identifiers to user audio segments, response audio segments, and record items in the execution record. The source identifier can be a pre-defined character sequence containing data type, call sequence number, segment sequence number, and record sequence number. The source identifier is only used to distinguish data sources and does not indicate business priority. Delivery requests are associated with and saved with the source identifier corresponding to the audio segment they reference, enabling subsequent operation instructions to trace back to the user audio and played response audio of the call that generated the delivery request. When generating caches for each attention layer, the dual-view inference module merges the source identifier of the current input data with the source identifier carried by the preceding state involved in the calculation and passes it level by level along the attention connection, forming a source dependency that includes both direct and indirect sources. When saving the cache, the source dependency, input marker, marker position, and attention visibility range are recorded simultaneously and transmitted to the cache recovery module. Since the source dependency comes from the actual calculation connection of the model, the cache recovery module can determine whether a cache, although superficially corresponding to user audio, internally references unplayed response audio, thereby determining whether the cache can be retained.

[0040] Furthermore, the cache recovery module specifically includes: The interaction evidence is updated based on the playback position at the start of the interruption. Unplayed response audio is removed from the playback queue. Response audio segments that cross the playback position are truncated according to the played sampling range. The truncated played response audio is used as the source identifier for the new audio segment allocation. The allowed source set of the understanding view is constructed with the source identifiers corresponding to the updated interaction evidence. Under the condition that the model parameters remain unchanged, the continuous prefix cache that all source dependencies are within the allowed source set and the input marker, marker position and attention visibility range are unchanged is retained. The subsequent interaction evidence is re-encoded from the end position of the continuous prefix cache to parse the updated delivery requirements. The source identifiers referenced by the updated delivery requests and the source identifiers corresponding to the retained execution records constitute the allowed source set of the generated view. The continuous prefix cache of the generated view is determined according to the same retention conditions, and the remaining delivery requests and execution records are re-encoded to reconstruct the decision prefix. If a continuous prefix cache is not available, it is recalculated from the starting point of the corresponding view. The cache corresponding to the complete response audio segment that spans the playback position is not reused, and the cache of the generated view is not copied to the understanding view.

[0041] In one specific embodiment, the recovery process after an interruption is based on the aforementioned source dependency. The cache recovery module updates the interaction evidence according to the playback position at the start of the interruption. First, it removes the unplayed response audio from the playback queue, then extracts the response audio segments that cross the playback position according to the played sampling range, and uses the extracted played response audio as a new audio segment to assign a source identifier.

[0042] For the understanding view, the cache recovery module constructs the allowed source set of the understanding view using the source identifiers corresponding to the updated interaction evidence. Under the condition that the model parameters remain unchanged, it retains consecutive prefix caches where all source dependencies are within the allowed source set, and the input tags, tag positions, and attention visibility ranges remain unchanged. It then re-encodes subsequent interaction evidence starting from the end position of the consecutive prefix caches and parses the updated delivery requests. For the generation view, the cache recovery module constructs the allowed source set of the generation view using the source identifiers referenced by the updated delivery requests and the source identifiers corresponding to the retained execution records. It determines the consecutive prefix cache of the generation view according to the same retention conditions and re-encodes the remaining delivery requests and execution records to reconstruct the decision prefix. If a consecutive prefix cache is not obtained, the cache recovery module recalculates from the starting point of the corresponding view. Caches corresponding to complete response audio segments spanning playback positions are not reused, and the cache of the generation view is not copied to the understanding view to maintain the data visibility range of each view consistent with its input range.

[0043] Furthermore, the cache recovery module also includes: When canceling an unplayed response audio, the requirement revision number carried by the operation instruction that has not yet been sent is compared with the current requirement revision number, and the operation instruction with the inconsistent requirement revision number is canceled; For operation instructions that have been sent, retain the corresponding execution records, mark the execution records that have not yet been verified as pending verification, and transmit them to the work order closed-loop module for query; For execution records that have been successfully verified and those that have failed verification, retain the corresponding verification results, re-encode the retained execution records into the generated view, and do not change the sent operation to unsent due to the cancellation of the response audio.

[0044] In one specific embodiment, while canceling the unplayed response audio, the cache recovery module also processes incomplete operation instructions. For operation instructions that have not yet been sent, the cache recovery module compares the requirement revision number it carries with the current requirement revision number; if they do not match, it indicates that the operation instruction comes from a delivery requirement that has expired, and the cache recovery module cancels the operation instruction. For operation instructions that have already been sent to the work order interface, the cache recovery module does not delete the corresponding execution record due to the cancellation of the unplayed response audio, but retains the execution record and marks the execution record without verification results as pending verification before transmitting it to the work order closed-loop module for querying. For execution records that have been successfully verified and those that have failed verification, the cache recovery module retains the corresponding verification results and re-encodes the retained execution records into the generated view. Through this processing, the system will not mistakenly consider the incomplete playback of the response audio as the work order not being sent, nor will it change the record of a sent operation to unsent. The subsequent work order closed-loop module can determine whether a difference work order still needs to be submitted based on the actual execution records.

[0045] Furthermore, the work order closed-loop module specifically includes: For the same waybill identifier, when the delivery request does not contain a pending completion mark and the execution record does not contain any pending verification operations involving the same delivery field, the target value corresponding to the current requirement revision number is compared with the current effective value obtained from the work order interface query item by item, and inconsistent delivery fields and target values ​​are extracted to generate a difference work order. Assign an operation identifier to the differential work order, and associate the operation identifier, waybill identifier, requirement revision number, delivery field and target value into the execution record; The update of the requirement revision number and the submission of the difference work order are processed serially according to the waybill identifier. Before submission, the requirement revision number of the difference work order is checked to ensure that it is consistent with the current requirement revision number. The difference work order is submitted to the work order interface that supports deduplication by operation identifier and the execution record is marked as pending verification. The resending of the same difference work order uses the original operation identifier. Update the corresponding execution record according to the operation identifier carried in the receipt. The receipt only confirms that the work order is in a pending verification state when it is accepted. Query the current effective value and operation execution status to complete the verification. Write the execution record with the time of receiving the verification result as the available time. The receipt corresponding to an earlier requirement revision number only updates the corresponding execution record and is not directly used to confirm that the delivery requirement corresponding to the current requirement revision number has been completed.

[0046] In a specific embodiment, the work order closed-loop module uses the waybill identifier as the processing unit when handling discrepancies in work orders. For the same waybill identifier, if the delivery request does not contain a pending completion marker and the execution record does not contain any pending verification operations involving the same delivery field, the work order closed-loop module compares the target value corresponding to the current requirement revision number with the currently effective value obtained from the work order interface query, extracting inconsistent delivery fields and target values ​​to generate a discrepancy work order. After the discrepancy work order is generated, the work order closed-loop module assigns an operation identifier to it. The operation identifier uses a pre-defined character sequence, and the operation identifier, waybill identifier, requirement revision number, delivery field, and target value are associated and written into the execution record. For the same waybill identifier, requirement revision number updates and discrepancy work order submissions are processed serially. Before submission, the requirement revision number of the discrepancy work order is checked again to ensure it matches the current requirement revision number. After verification, the discrepancy work order is submitted to the work order interface that supports deduplication by operation identifier, and the execution record is marked as pending verification. When the same discrepancy work order needs to be resent due to network receipt delays, the original operation identifier is used, and the work order interface identifies it as the same operation accordingly. After the receipt is returned, the work order closed-loop module updates the corresponding execution record based on the operation identifier carried in the receipt. If the receipt only confirms work order acceptance, the execution record remains in a pending verification state. The work order closed-loop module continues to query the current effective value and operation execution status to complete the verification, and writes the time of receipt of the verification result as the available time into the execution record. Receipts corresponding to earlier requirement revision numbers only update the corresponding execution record and are not directly used to confirm that the delivery requirement corresponding to the current requirement revision number has been completed, thereby avoiding old receipts from overwriting new requirements.

[0047] Furthermore, the dual-view reasoning module also includes: The execution stage is determined based on the receipts and verification results in the execution record. The execution stage includes work order acceptance, delivery field activation and execution failure. A response audio segment corresponding to the execution stage is generated, and the current requirement revision number and the execution record used as the basis for generation are associated with the response audio segment. Before playback, verify that the requirement revision number associated with the response audio segment is consistent with the current requirement revision number, and verify the execution stage and target value of the delivery field corresponding to the segment supported by the execution record. After verification, transmit the response audio segment to the playback end. Based on the playback location, the playback range of the response audio segment is registered. When the execution record has met the current delivery requirements but the corresponding response audio segment has not been fully played, only the response audio of the result feedback is generated. No more operation instructions for repeated submission are generated, and the updated playback location is sent back to the acquisition module to form subsequent interaction evidence.

[0048] In a specific embodiment, during the closed-loop feedback phase, the dual-view inference module determines the execution phase based on the receipts and verification results in the execution record. Execution phases include work order acceptance, delivery field activation, and execution failure. The generation view generates a corresponding response audio segment based on the execution phase and associates the response audio segment with the current requirement revision number and the execution record used as the basis for generation. If the execution phase is only work order acceptance, the response audio segment indicates that acceptance has been registered; if the verification result shows that the delivery field has been activated, the response audio segment indicates that the corresponding delivery field has been updated; if execution fails, the response audio segment indicates that the corresponding change could not be completed and proceeds to subsequent processing. Before the response audio segment is transmitted to the playback end, the dual-view inference module verifies that the requirement revision number associated with the response audio segment is consistent with the current requirement revision number and verifies that the execution record supports the execution phase and target value of the delivery field corresponding to the segment. Only after verification is the segment transmitted to the playback end. The playback end continues to send back the playback position, and the dual-view inference module registers the played range of the response audio segment based on the playback position. When the execution record has met the current delivery requirements but the corresponding response audio segment has not been played completely, the generated view only supplements the response audio of the generated result feedback, no longer generates operation instructions for repeated submission, and sends the updated playback position back to the acquisition module for the acquisition module to form subsequent interaction evidence.

[0049] Taking a call involving a delivery address change and rescheduling as an example, the system has already generated a response audio through a view, with content corresponding to new address confirmation, address change work order acceptance, and delivery time inquiry, of which only the new address confirmation segment is played. The user then says, "Yes, this is the address, and the time is changed to 6:00." The acquisition module, based on the playback position at the start of the call, forms interactive evidence containing only the new address confirmation segment. The understanding view associates this address with the fully played delivery address confirmation segment, generating a delivery requirement that maintains Building 3 in Campus A. Simultaneously, based on the time being changed to 6:00, it generates a delivery requirement with a target delivery time of 18:00 and assigns a new requirement revision number. The cache recovery module cancels unplayed response audio, removes cached references to unplayed response audio, but retains the submitted and verified address change execution record. The work order closure module, after querying the current effective value, confirms that the delivery address meets the delivery requirement and does not generate an address change difference work order, only generating a difference work order for the delivery time. After the receipt is written to the execution record and fed back to the generated view, the generated view produces a response audio segment that matches the work order acceptance stage. If the user interrupts again before the feedback has been fully played, the aforementioned process resumes based on the playback position and source dependency, and will not resubmit already effective delivery fields because the feedback has not been fully played.

[0050] Therefore, the interactive evidence generated by the acquisition module provides a training prefix for the fine-tuning module and an online parsing basis for understanding the view; the fine-tuned speech model obtained by the fine-tuning module provides shared parameters for the dual-view inference module; the delivery requests, operation instructions, response audio, and source dependencies generated by the dual-view inference module then enter the cache recovery module and the work order closed-loop module, respectively; the cache recovery module retains the actual execution record and reconstructs the decision prefix when interrupting the call; the work order closed-loop module writes the verification results back to the execution record and feeds back to generate the view. All data continue to be used in subsequent steps, forming a closed-loop processing chain from the user audio at the call end to the response audio at the playback end, from the delivery request to the discrepancy work order, and from the receipt to subsequent interactive evidence.

[0051] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to any specific implementation. Clearly, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention.

Claims

1. A closed-loop logistics delivery system driven by a fine-tuned large-scale voice model, characterized in that: include: The acquisition module is used to acquire user audio from the call end, response audio from the playback end and playback position, work order interface execution records, record available time, and associate user audio with played response audio according to playback position to form interactive evidence; The fine-tuning module is used to capture interaction evidence and execution records at available times, construct training prefixes with the same interaction evidence but different execution records, label delivery requirements based on interaction evidence, label operation instructions based on the differences between delivery requirements and execution records, and fine-tune the prediction results and labeling deviations of the training prefixes by the speech big model. The dual-view reasoning module is used to establish a shared parameter and cache-separated understanding view and generation view in the fine-tuning speech model. The understanding view only parses the delivery requirements based on the interaction evidence, while the generation view re-encodes the delivery requirements and execution records into decision prefixes, generates operation instructions based on the decision prefixes, and then generates response audio, recursively tracing cache source dependencies along the attention connection. The cache recovery module is used to update the interaction evidence according to the playback position at the start of the interruption, revoke unplayed response audio, remove caches that reference unplayed response audio according to source dependency, re-encode the interaction evidence and the retained execution records according to the dual-view input range, and restore dual-view inference. The work order closed-loop module is used to query the work order interface verification execution record according to the operation command, compare the verification result with the delivery requirement, submit only the unexecuted difference work orders, write the receipt to the execution record and backflow to generate the view, generate the response audio and send it to the playback end for parallel playback with the user's audio reception.

2. The closed-loop logistics delivery system based on a fine-tuned large voice model driven by claim 1, characterized in that, The data acquisition module specifically includes: The system obtains user audio and start collection time from the call end, response audio, playback position and corresponding actual playback time from the playback end, and execution record corresponding to the current call from the work order interface. The system records the reception time, unifies the start collection time, actual playback time and reception time to the same time base, and uses the reception time of user audio and execution record as the corresponding available time. For each user audio segment, select playback positions whose actual playback time is no later than the start time from the received playback positions, select the playback position with the latest actual playback time, and extract the response audio according to the completed playback sampling range indicated by it to obtain the played response audio. The receiving completion time of the played response audio is compared with the receiving time of the selected playback position, and the later time is taken as the available time of the played response audio. The user's audio is associated with the played response audio to form interaction evidence, and their respective available moments are retained. If no playback position that meets the criteria is found, the played response audio in the interaction evidence is recorded as empty. The interaction evidence and execution record are saved and transmitted to the fine-tuning module respectively. The interaction evidence is transmitted to the understanding view, and the execution record is transmitted to the generation view.

3. The closed-loop logistics delivery system based on a fine-tuned large voice model driven by claim 2, characterized in that, The fine-tuning module specifically includes: The available time of the interaction evidence and the execution record are used as the cutoff time in turn. Data with available time no later than the cutoff time are retained. Training prefixes with the same interaction evidence but different execution records are constructed. The same delivery requirement label is set for the same interaction evidence. For confirmed delivery requests, training prefixes that do not contain corresponding verification operations and have unexecuted differences are marked as submissions, training prefixes that contain corresponding verification operations are marked as queries, and training prefixes that do not contain corresponding verification operations and whose verification results meet the delivery requirements are marked as result feedback. In each attention layer, only the reading location of interactive evidence is opened for the delivery demand prediction stage, while the reading location of delivery demand and execution record is opened for the operation instruction prediction stage. The basic parameters of the large speech model are frozen, and low-rank adaptation parameters are set in the attention projection layer. The negative log loss is calculated for the prediction probability of the corresponding labels based on the prediction results of delivery demand and operation instructions, respectively. The two losses are added together and the low-rank adaptation parameters are updated accordingly to obtain the fine-tuned large speech model.

4. The closed-loop logistics delivery system based on a fine-tuned large voice model driven by claim 3, characterized in that, The fine-tuning module also includes: Select the playback positions corresponding to different complete unconfirmed segments from the same response audio, associate the short confirmation segments in the same user audio with the already played response audio before each playback position, and construct training prefixes with different playback positions; Match the brief confirmation snippets with the last fully played confirmation snippets in each interactive piece of evidence; When a unique match is formed, the delivery requirement is marked based on the matched delivery field and target value, and the execution record marking operation instruction is combined. When no unique match is formed, a "to be completed" flag is written in the delivery request annotation, and the operation instruction is marked as "waiting". The training prefixes with different playback positions and the training prefixes with the same interaction evidence but different execution records are used together to update the low-rank adaptation parameters; During audio encoding, the available time of audio features is determined by the latest available time of all audio required to calculate the audio features. Only audio features whose available time is no later than the truncation time are included in the training prefix, and training prefixes with the same readable data in the same prediction stage have the same label.

5. The closed-loop logistics delivery system based on a fine-tuned large voice model driven by claim 1, characterized in that, The dual-view reasoning module specifically includes: In each attention layer of the understanding view, the positions corresponding to the execution record and the unplayed response audio are set as unreadable positions; Extract the waybill identifier, delivery field, and target value based on the interaction evidence, write the confirmation relationship between the user's audio and the played response audio into the delivery requirement, and record the corresponding audio interval; Only complete, played response audio segments that refer to a single object are used as confirmation objects. When the user's audio expression is revised and the delivery field and target value are not determined at the same time, the delivery request is marked as pending completion. The generation view generates a waiting instruction based on the pending completion mark. When the user's audio specifies the delivery field and target value, the delivery request is updated and the pending completion mark is cleared. The requirement revision number is assigned according to the order in which the delivery requirement is formed and revised. The requirement revision number is written into the operation instructions and response audio generated accordingly. When the target value of the delivery field is changed to a historical value again, a new requirement revision number is assigned. In the generated view, delivery requests and execution records are encoded as decision prefixes, operation instructions are generated from the decision prefixes, and response audio is generated after the decision prefixes; When generating operation instructions again, the decision prefix is ​​reconstructed based on the updated delivery requirements and execution records, without using the cache corresponding to the response audio generation location.

6. The closed-loop logistics delivery system based on a fine-tuned large voice model driven by claim 5, characterized in that, The dual-view reasoning module also includes: Assign source identifiers to user audio segments, response audio segments, and record items in the execution record, and associate delivery requests with the source identifiers corresponding to the audio segments they reference; When generating the cache for each attention layer, the source identifier of the current input data is merged with the source identifier carried by the previous state involved in the computation, and then passed along the attention connection level by level to form a source dependency that includes both direct and indirect sources. The source dependencies are associated with and saved with the corresponding caches. At the same time, the input tags, tag positions and attention visibility ranges corresponding to the caches are recorded. The source dependencies, input tags, tag positions and attention visibility ranges are then transmitted to the cache recovery module to determine the retention range of the caches.

7. The closed-loop logistics delivery system based on a fine-tuned large voice model driven by claim 6, characterized in that, The cache recovery module specifically includes: The interaction evidence is updated based on the playback position at the start of the interruption. Unplayed response audio is removed from the playback queue. Response audio segments that cross the playback position are truncated according to the played sampling range. The truncated played response audio is used as the source identifier for the new audio segment allocation. The allowed source set of the understanding view is constructed with the source identifiers corresponding to the updated interaction evidence. Under the condition that the model parameters remain unchanged, the continuous prefix cache that all source dependencies are within the allowed source set and the input marker, marker position and attention visibility range are unchanged is retained. The subsequent interaction evidence is re-encoded from the end position of the continuous prefix cache to parse the updated delivery requirements. The source identifiers referenced by the updated delivery requests and the source identifiers corresponding to the retained execution records constitute the allowed source set of the generated view. The continuous prefix cache of the generated view is determined according to the same retention conditions, and the remaining delivery requests and execution records are re-encoded to reconstruct the decision prefix. If a continuous prefix cache is not available, it is recalculated from the starting point of the corresponding view. The cache corresponding to the complete response audio segment that spans the playback position is not reused, and the cache of the generated view is not copied to the understanding view.

8. The closed-loop logistics delivery system based on a fine-tuned large voice model driven by claim 7, characterized in that, The cache recovery module also includes: When canceling an unplayed response audio, the requirement revision number carried by the operation instruction that has not yet been sent is compared with the current requirement revision number, and the operation instruction with the inconsistent requirement revision number is canceled; For operation instructions that have been sent, retain the corresponding execution records, mark the execution records that have not yet been verified as pending verification, and transmit them to the work order closed-loop module for query; For execution records that have been successfully verified and those that have failed verification, retain the corresponding verification results, re-encode the retained execution records into the generated view, and do not change the sent operation to unsent due to the cancellation of the response audio.

9. The closed-loop logistics delivery system based on a fine-tuned large voice model driven by claim 8, characterized in that, The work order closed-loop module specifically includes: For the same waybill identifier, when the delivery request does not contain a pending completion mark and the execution record does not contain any pending verification operations involving the same delivery field, the target value corresponding to the current requirement revision number is compared with the current effective value obtained from the work order interface query item by item, and inconsistent delivery fields and target values ​​are extracted to generate a difference work order. Assign an operation identifier to the differential work order, and associate the operation identifier, waybill identifier, requirement revision number, delivery field and target value into the execution record; The update of the requirement revision number and the submission of the difference work order are processed serially according to the waybill identifier. Before submission, the requirement revision number of the difference work order is checked to ensure that it is consistent with the current requirement revision number. The difference work order is submitted to the work order interface that supports deduplication by operation identifier and the execution record is marked as pending verification. The resending of the same difference work order uses the original operation identifier. Update the corresponding execution record according to the operation identifier carried in the receipt. The receipt only confirms that the work order is in a pending verification state when it is accepted. Query the current effective value and operation execution status to complete the verification. Write the execution record with the time of receiving the verification result as the available time. The receipt corresponding to an earlier requirement revision number only updates the corresponding execution record and is not directly used to confirm that the delivery requirement corresponding to the current requirement revision number has been completed.

10. The closed-loop logistics delivery system based on a fine-tuned large voice model driven by claim 9, characterized in that, The dual-view reasoning module also includes: The execution stage is determined based on the receipts and verification results in the execution record. The execution stage includes work order acceptance, delivery field activation and execution failure. A response audio segment corresponding to the execution stage is generated, and the current requirement revision number and the execution record used as the basis for generation are associated with the response audio segment. Before playback, verify that the requirement revision number associated with the response audio segment is consistent with the current requirement revision number, and verify the execution stage and target value of the delivery field corresponding to the segment supported by the execution record. After verification, transmit the response audio segment to the playback end. Based on the playback location, the playback range of the response audio segment is registered. When the execution record has met the current delivery requirements but the corresponding response audio segment has not been fully played, only the response audio of the result feedback is generated. No more operation instructions for repeated submission are generated, and the updated playback location is sent back to the acquisition module to form subsequent interaction evidence.

Images