A cargo ship matching method based on a vertical large model

Abstract

This invention discloses a cargo ship matching method based on a vertical large-scale model, belonging to the field of shipping information processing and intelligent ship scheduling. Addressing the difficulties in multimodal demand analysis, inaccurate calculation of actual routes, and the inability to simultaneously consider multidimensional constraints in inland waterway and coastal bulk cargo transportation, this invention extracts structured matching parameters through multimodal recognition and a vertical large-scale model in the shipping field. It calculates standard routes using a shipping basic network model, generates standardized historical route files for ships based on cleaned AIS trajectories, and performs hard filtering based on ship type, tonnage, draft, and arrival time. Then, based on dynamic weights configured according to the shipping scenario, it calculates the comprehensive matching degree of spatiotemporal urgency, route familiarity, and historical performance and pricing, generating interpretable recommendations and updating matching parameters using performance feedback, thus forming a traceable cargo ship matching process.

Description

Technical Field

[0001] This invention relates to the field of shipping information processing and intelligent ship scheduling, and in particular to a cargo ship matching method based on a vertical large model. Background Technology

[0002] Matching ships and cargo in inland and coastal bulk cargo transportation usually relies on human experience, static ship files, and straight-line distances between ports. Although electronic shipping data and common language models have been introduced in recent years, freight demand still exists in a scattered form, such as natural language, manifests, notices, and certificate images.

[0003] Existing methods struggle to simultaneously parse multimodal requirements and validate fields. Route distances do not adequately consider actual navigable waterways, lock passage, and seasonal water depths. Furthermore, it is difficult to incorporate vessel type, tonnage, draft, arrival time, route familiarity, performance, and freight rates into the same interpretable ranking process. General large models may also generate recommendations that are inconsistent with candidate vessel data.

[0004] Therefore, a cargo ship matching method is needed to address the shortcomings of the existing technology. Summary of the Invention

[0005] One objective of this invention is to propose a cargo ship matching method based on a vertical large model. This method addresses issues related to multimodal demand analysis, real-world channel calculation, historical route quantification, and the reliability of large model outputs. It constructs a continuous technical solution encompassing request parsing, scenario orchestration, route calculation, AIS trajectory processing, hard filtering, and dynamic scoring recommendation. This enables the ranking and verifiable recommendation of candidate ships that meet constraints related to ship type, tonnage, draft, and arrival time.

[0006] This invention provides a cargo ship matching method based on a vertical large model, applied to inland waterway and coastal bulk cargo transportation scenarios, including: S1, receiving natural language text, cargo manifests, port notifications, and ship certificate images, parsing the vertical large model of the shipping field obtained through optical character recognition and training, forming structured matching parameters including cargo type, cargo tonnage, loading port, unloading port, loading time, and transportation area; S2, loading shipping scenario constraint rules according to the structured matching parameters, and using a directed acyclic graph process engine to arrange data query, route calculation, candidate screening, scoring, and result generation tasks; S3, acquiring ship files, automatic identification system trajectories, port scheduling, performance, freight rates, and waterway data, including port, lock, and... A basic shipping network model is established using bifurcation points and anchorages as nodes and navigable waterways as directed edges to calculate standard routes; S4. Historical automatic identification system trajectories are cleaned, and valid voyage maps are matched to the model to form a standardized historical route archive for ships; S5. Based on the structured matching parameters and standard routes, candidate ships are subjected to hard filtering based on ship type, tonnage, draft, and arrival time to obtain a set of qualified candidate ships and the reasons for filtering; S6. Based on market freight rates, supply and demand status, historical matching times, and route maturity, scenario weights are configured, and the spatiotemporal urgency, route familiarity, and performance quotation scores of qualified candidate ships are calculated to form a comprehensive matching degree and sort them, generating recommendation results and updating the matching parameters using the performance feedback of the recommended voyages.

[0007] Optionally, S1 includes: Perform text recognition, field localization, and certificate field verification on the images, align the recognized fields with natural language text and cargo manifests, and extract special transportation requirements; The first intent category is obtained by keyword classification, the second intent category is obtained by vector similarity classification, and the third intent category is obtained by vertical large model classification. When at least two of the three categories are consistent and the confidence of each category participating in the consistency determination is not less than 0.7, the cargo ship matching intent is confirmed. When cargo tonnage, loading port, unloading port, or loading time is missing, complete it according to the session context. If the completion fails, generate a supplementary query containing the missing fields. After receiving the user's answer, merge it into the original request and re-execute the field integrity check. If the maximum number of queries is reached and the field is still missing, output an unmatched status. Furthermore, the vertical large model in the shipping field is supervised and fine-tuned using training samples consisting of historical inquiry texts, cargo lists, port notices, ship certificate fields, matching results, and performance results in the shipping field. Before generating recommendation descriptions, the output ship names, routes, scores, and filtering reasons are checked for consistency with the qualified candidate ship set and score records at the field level. If the verification fails, stop generating the natural language fact field, output the structured pending verification status, and transfer the original sorting results to manual review. Before the training samples are written, certificate sensitive fields are desensitized, quality scores are applied, and version binding is performed. Furthermore, the user selection behavior and voyage performance results include at least the user-selected vessel, actual loading time, actual arrival time, actual freight rate, and abnormal events; The method performs deduplication based on voyage number and event timestamp, and marks canceled or unfulfilled voyages, voyages with incomplete fields, and voyages with abnormal events that have not been reviewed as invalid feedback. For valid feedback calculations, the consistency between recommended vessels and actual vessels, arrival time deviations, and price deviations are calculated. The calculation results are written into the vertical large model fine-tuning sample library, recommendation preference parameter library, and matching score parameter library, respectively. After the sample quantity and quality score reach the preset release threshold, the parameters are atomically released with a single version number and the previous version is retained. When the quality score is less than 60 points, the anomaly rate exceeds 20%, or the field consistency check fails after release, a rollback is triggered, the previous version is restored, and the audit log is recorded.

[0008] Optionally, S2 includes: Using cargo type, loading port, unloading port, transport area, loading time and special transport requirements in the structured matching parameters as the scenario routing key, ship type compatibility rules, special transport constraint rules, draft constraint rules, time constraint rules and data validity period rules are read from the rule base, and data query, network path calculation, historical route extraction, hard filtering, scoring and recommendation generation are configured as nodes of a directed acyclic graph; When any node returns missing or expired data, select an alternative data source based on the data timestamp and record the data source version. If the alternative data source is still unavailable, output an unmatched status containing the missing field.

[0009] Optionally, S3 includes: The actual navigable waterways between adjacent shipping nodes are taken as directed waterway edges, and the physical distance, lock chamber queuing time, waterway passage frequency, seasonal water level and navigation restrictions are normalized respectively. The edge weights are formed by weighting and summing according to the preset non-negative edge weight coefficients. For port pairs that exist in the standard route database and whose data timestamps have not expired, the pre-calculated path is invoked. For port pairs that do not exist in the standard route database or whose pre-calculated path has expired, the Dijkstra algorithm or A* algorithm is used to calculate the path on the shipping basic network model, and the standard route consisting of a segment sequence and water depth constraints for each segment is output.

[0010] Optionally, S4 includes: The historical automatic identification system tracks are cleaned based on rules for coordinate drift, abnormal speed, non-cargo vessel identification, time breaks, and duplicate recordings, and track points with positioning errors exceeding the preset error threshold are removed. Extract candidate stopping segments from the cleaned trajectory that have a speed of no more than 3 knots per hour and a duration of no less than 30 minutes; The neighborhood radius and minimum number of samples for density clustering are adaptively determined based on the spatial density and time span of the berthing section. The cluster centers are spatially matched with the dock geofence and the anchorage geofence, respectively. The effective berthing points and temporary anchorage points of the dock are distinguished by the method of unified geographical coordinates and the handling of overlapping fences according to the dock priority rule. The trajectory between two consecutive valid berthing points at the dock is converted into a directed route sequence through directed map matching and written into the ship's standardized historical route archive.

[0011] Optionally, S5 includes: When the ship type and cargo type do not meet the preset compatibility matrix, the ship's deadweight tonnage is less than the product of the cargo tonnage and the preset loading coefficient, the ship's full-load draft is greater than the effective navigable water depth of any segment of the target route, or the estimated arrival time calculated based on the segmented voyage distance from the ship's current position to the loading port and then to the unloading port, the average speed, the current time, the loading operation time, and the time zone conversion results is later than the cargo source deadline, the corresponding ship will be marked as unqualified and at least one filtering reason will be recorded. The preset loading coefficient is between 0.8 and 1.0, and the cargo cut-off time is determined by the end time of the loading time window; Only ships that fail to meet any filtering reason are added to the qualified candidate ship set, and an empty candidate status is output when the qualified set is empty.

[0012] Optionally, S6 includes: The segmented voyage distance from the ship's current position to the loading port and then to the unloading port, the estimated arrival time and the remaining time between the cargo source deadline are mapped into a time-space urgency score according to a preset linear mapping and overdue truncation rule. When any segment set is empty, the route familiarity is marked as missing and a preset neutral score is applied. When both sets are not empty, the number of intersection elements of the directed segment set in the ship's standardized historical route archive and the standard route segment set is divided by the number of elements in the union of the two sets to obtain the segment overlap degree and map it to the route familiarity score. Historical performance and quotation scores are calculated based on the on-time rate, cancellation rate, abnormality rate, and deviation of vessel quotations from reference freight rates in the same market and statistical window within the preset statistical window. Each score is normalized to 0 to 100 according to a unified benchmark. Missing dimensions are given a preset neutral score, and the overall matching degree is calculated using non-negative scene weights that sum to 1. Furthermore, the configuration of the scenario weights includes: calculating the historical matching frequency of the target port pair, the route data coverage, the 80th percentile of the market freight rate index, and the capacity supply-demand ratio within the same statistical period and the same market scope; When the number of historical matches is not less than the preset maturity number and the route data coverage is not less than the preset coverage, the task will be marked as a regular mature route. When the market freight rate index reaches the 80th percentile and the supply-demand ratio of transportation capacity is no greater than 0.8, the task will be marked as a peak season scenario with a shortage of transportation capacity. When multiple tags are met simultaneously, a single tag is selected based on the priority of peak season capacity shortage scenarios, regular mature routes, and newly opened routes. When neither the conditions for a regular, established route nor the conditions for peak season capacity shortages are met, the task is marked as a newly established route scenario, and the corresponding non-negative weight vector is switched according to the task marking.

[0013] The beneficial effects of this invention are: 1. By using OCR, three-level intent recognition, and a large vertical model for the shipping industry, natural language, manifests, notices, and certificate images are converted into structured matching parameters. Contextual completion or supplementary queries are performed on missing fields to reduce field omissions caused by multimodal requirement parsing.

[0014] 2. By using a shipping network model consisting of real navigable waterways and standardized historical route archives formed by AIS tracks, distance, arrival time, draft adaptability, and route familiarity are calculated based on actual waterways, avoiding the use of port straight-line distance and subjective familiarity.

[0015] 3. Through hard constraint filtering, scenario dynamic weighting, multi-dimensional scoring, and candidate data consistency verification, the system outputs interpretable recommendations with scores, filtering reasons, risk and freight rate analysis, and continuously adjusts matching parameters based on performance results. Attached Figure Description

[0016] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is a flowchart of a cargo ship matching method based on a vertical large model according to the present invention.

[0017] Figure 2 This is a flowchart of the process for S4 of the present invention to clean historical AIS tracks and form a standardized historical route archive for ships. Detailed Implementation

[0018] The present invention will now be described in further detail with reference to the accompanying drawings. These drawings are simplified schematic diagrams, illustrating only the basic structure of the invention, and therefore only show the components relevant to the invention.

[0019] refer to Figures 1-2 A cargo ship matching method based on a vertical large model is applied to inland waterway and coastal bulk cargo transportation scenarios. The method includes: S1, receiving natural language text, cargo manifests, port notifications, and ship certificate images; parsing the vertical large model obtained through optical character recognition and training in the shipping field to form structured matching parameters including cargo type, cargo tonnage, loading port, unloading port, loading time, and transportation area; S2, loading shipping scenario constraint rules according to the structured matching parameters; and using a directed acyclic graph (DAG) process engine to orchestrate data query, route calculation, candidate selection, scoring, and result generation tasks; S3, acquiring ship files, automatic identification system trajectories, port scheduling, contract fulfillment, freight rates, and waterway data, including port, lock, and branching points. A shipping network model is established with anchorages as nodes and navigable waterways as directed edges to calculate standard routes; S4. Historical automatic identification system trajectories are cleaned, and valid voyage maps are matched to the model to form a standardized historical route archive for ships; S5. Based on the structured matching parameters and standard routes, candidate ships are subjected to hard filtering based on ship type, tonnage, draft, and arrival time to obtain a set of qualified candidate ships and the reasons for filtering; S6. Based on market freight rates, supply and demand status, historical matching times, and route maturity, scenario weights are configured, and the spatiotemporal urgency, route familiarity, and performance quotation scores of qualified candidate ships are calculated to form a comprehensive matching degree and sort them, generating recommendation results and updating the matching parameters using the performance feedback of the recommended voyages.

[0020] In this specific embodiment, S1 includes: In this embodiment, the multimodal access module of the business platform establishes a unique demand number for each freight demand. It saves the user-input natural language inquiry, cargo list, loading / unloading port notification, and ship certificate image as original text objects, table objects, formatted document objects, and image objects, respectively, and records the source type, upload time, file hash, and operator identifier. The text objects are encoded in UTF-8. The cargo list line contains at least the cargo name, packaging method, and quantity fields. The notification retains the port code, operation window, and restriction clauses. The certificate image retains the shooting direction and resolution. If any object cannot be decoded, an error code is written to the original object index and subsequent parsing of that object is stopped. The optical character recognition module first performs orientation correction, noise reduction, page segmentation, and character recognition on the certificate image, and outputs a record of recognized fields with page number, field box coordinates, recognized text, character confidence score, and certificate validity period. For fields such as port of loading, port of discharge, draft limit, dangerous goods category, and operation time, the field locator matches the field box according to the certificate template version and port notification form version. If multiple candidate values ​​appear for the same field, they are sorted by character confidence score, field box area, and validity period. The value with the highest ranking is retained, and the remaining values ​​are written to the conflict candidate table. The vertical large model uses a pre-trained text encoder and image field encoder from the shipping domain to form a cross-modal parsing model. The text side inputs the inquiry context and the list line sequence, and the image side inputs the field box image and its position encoding. The model outputs cargo entity, port entity, time entity, and transport area entity. The training samples come from historical inquiry texts, verified lists, port notices, certificate fields, matching results, and performance results. The training set and validation set are deduplicated according to the requirement number and then divided in an 8:2 ratio. The model version, vocabulary version, and field label set are written into the model list. For each field to be confirmed, the field fusion module calculates the keyword classification result, vector similarity classification result, and vertical large model classification result, respectively. The confidence scores of all three types of results are normalized to zero to one. Calculate the overall confidence score of the fields, where, Indicates the first The overall confidence level of each field is a dimensionless quantity. , and These represent keywords, vector similarity, and vertical large model similarity to the first... The confidence scores for each field are given by the calibration table of each model on the validation set; when at least two classes of results have the same normalized category and When this happens, write the category into a structured field; The structured field table uses demand number, cargo type, cargo tonnage, loading port, unloading port, loading time window start and end, transportation area, maximum permissible draft, special transportation requirements, and field status as fixed fields. For tonnage, tons are retained; for draft, meters are retained; and for time, UTC timestamps are retained. The field fusion module maps synonymous port names in natural language text to port codes in the port master data table, groups and sums the weights of multiple rows in the cargo list by cargo type, and associates the vessel identification number in the certificate with the vessel file table. When the master data table is not matched, the original string is retained and marked as a field to be verified. When cargo tonnage, loading port, unloading port, loading time, or transportation area is missing, the context completion module extracts candidate values ​​from identified entities, session history, and port notifications for the same requirement, and completes them according to field priority and time sequence. If a field is still missing after completion, a supplementary query is generated containing the requirement number, missing field name, candidate hints, and answer format, and the requirement status is set to pending completion. After receiving the user's answer, the system merges it into the original field table and re-executes the field integrity check. If a field is still missing after three queries, an unmatchable status is written and entry into S2 is prohibited. For special transportation requirements such as dangerous goods, oversized and overweight items, refrigerated goods, and bulk powders, the entity normalization module extracts transportation labels from the special requirements dictionary and saves the hazard level, temperature control range, cargo capacity requirements, and certificate requirements in the label records. If an image field conflicts with a text or manifest field, the system prioritizes the certificate value that is not expired and has the highest confidence level for the field. At the same time, it retains the conflict record and the manual review mark. The review conclusion can overwrite the automatic value but cannot delete the original value. The intent determination module writes keyword category, vector category, and vertical large model category into the same intent record, and uses the majority consensus rule to confirm the cargo ship matching intent: when at least two of the three categories are the same and the confidence of the participating categories all reach 0.70, the intent status is set to cargo ship matching; otherwise, it is set to pending review. The intent record saves the three categories, the three confidence levels, the number of participating categories, and the model version. Subsequently, S2 only consumes the requirements with the status of cargo ship matching. The monitoring and fine-tuning module uses historical inquiry texts, cargo lists, port notices, ship certificate fields, historical matching results, and performance results as training samples. Before writing, the ship certificate number, contact person, and account fields are replaced with irreversible identifiers. The sample quality is calculated based on field completeness, label consistency, and traceability of performance results. Only samples with a quality score of no less than 80 and no plaintext in certificate sensitive fields are included in the training queue. Training samples are deduplicated according to requirements and bound to the dataset version. The model training adopts a supervised fine-tuning method to update the field extraction layer and intent classification layer. The training configuration records the base model version, learning rate, batch size, training epochs, validation set version and stopping conditions. After each training epoch, the field accuracy and intent confidence calibration error are checked on three validation subsets: port aliases, time window expressions and special transportation requirements. If any subset is lower than the release threshold, the previous model version is retained. If the threshold is met, a new model version is generated and written to the model list. To ensure the factual source of subsequent recommendations, S1 pre-establishes a field-level consistency rule table. The rule table uses the output field name, data source table, allowed format, unit, and version number as keys. Ship name, route, score, and filtering reason can only be read from the subsequent candidate set and score record. When the rule table finds that the output field has no source record, it is marked as pending verification, and the natural language generation module is prohibited from manually adding fact fields. User selection and voyage fulfillment results are entered into the same feedback record structure. Fields include voyage number, event timestamp, user-selected vessel, actual loading time, actual arrival time, actual freight rate, and exception events. The feedback access module performs deduplication based on voyage number and event timestamp. This indicates that the first record of the same voyage and the same timestamp is retained, using... This indicates that subsequent duplicate records will be discarded. This indicates a binary deduplication flag, with a value set of {0,1} and being a dimensionless quantity; canceled or unfulfilled voyages, voyages with incomplete fields, and voyages with unreviewed abnormal events are all marked as invalid feedback and will not proceed to parameter updates. The field integrity verification module checks each of the six required fields—cargo type, cargo tonnage, port of loading, port of discharge, loading time, and transport area—using a specific method. Calculate completeness, where, Indicates the completeness of a dimensionless field. This indicates the number of required fields that passed the validation. Indicates the total number of required fields; when Furthermore, a structured matching parameter version is only allowed to be generated when the cargo tonnage is greater than zero; otherwise, only the missing fields and query status are written. Field source validation also calculates the source consistency flag. ,in, This is a verification flag indicating that the structured fields correspond to the original object's hash and field coordinates; if any field cannot be traced back to the original object, then... Set to zero and retain the pending verification status; only records with a consistency flag of 1 are entered into the versioned parameter library. When all fields are in the confirmed or completed state and the cargo tonnage is greater than zero, the structured matching parameters are written to the matching parameter library as versioned requirement records. The records include field validation summary, source object hash, model version, completion count, and time window time zone, and a parameter version number is generated for S2 to read. If any required field does not meet the integrity condition, only the unmatchable state and query record are written, and no matching parameter version is generated for subsequent steps.

[0021] In this specific embodiment, S2 includes: S2 reads the version number of the structured matching parameters generated by S1 and uses cargo type, loading port, unloading port, transportation area, loading time window and special transportation requirements to form a scenario routing key; the rule orchestration module loads ship type compatibility rules, special transportation constraint rules, draft constraint rules, time constraint rules and data validity rules from the rule base. Each rule includes rule number, input field, output field, unit, priority, effective time, expiration time and version number. The rule base uses the scenario routing key and rule version number as a composite index. The process engine configures data query, route calculation, candidate filtering, scoring, and result generation as a directed acyclic graph. Each node records the node number, input field set, output field set, executor, timeout, number of retries, and predecessor node number. Each edge records the data version and verification summary. The node topology sorting adopts a deterministic rule of prioritizing nodes with zero in-degree and ascending node number. If a back edge or duplicate node number is detected, the task configuration is rejected and the previous version is retained. Before the task is published, the validator is configured to check each node to ensure that required inputs exist, units are convertible, rule versions are valid, and output fields can be consumed by subsequent nodes; for field sets... ,use Calculate the first The input coverage of each node, where, Indicates the node index in the configuration process and , Indicates the total number of nodes. This represents the dimensionless coverage with values ​​ranging from [0,1]. This represents the actual set of input fields that can be provided. This represents the set of required fields for a node declaration; when If the node is empty, mark it as a configuration error and prevent task publishing. Non-empty and any node If a rule expires, the defect will be written to the configuration diagnostic table and the task will be prevented from entering the execution queue. The data query node reads data from vessel files, AIS tracks, port scheduling, performance records, freight rate tables, and channel depth tables based on the port code, cargo tags, and time windows specified in the requirements. It also adds the data source version, timestamp, and query conditions for each read. When the primary data source returns an empty set or a field is missing, the node selects the backup data source with the most recent timestamp according to the data validity rules. If the backup source still does not meet the field completeness requirements, it generates a list of missing fields and returns an unmatchable status. Temporary data that has not been version registered is not used. The process definition node only registers runtime data contracts and does not consume the results of subsequent steps in advance during the S2 stage. During runtime, nodes are started in the following order: S3 generates standard routes, S4 generates historical route files, S5 generates a qualified candidate set, and S6 executes scoring and recommendation generation. The output fields of the S3 node serve as the inputs of S5, and the output fields of S5 serve as the inputs of S6. The result node only accepts records with demand number, vessel number, standard route number, scoring components, and filtering reasons. After each node is completed, it writes the output field summary, record count, and verification summary to the task execution log. Subsequent nodes verify the consistency between the input and the upstream output through the version number. The process engine establishes a runtime context using task number and configuration version number. The runtime context saves the current node, the set of completed nodes, the input version, the failure reason, and the retry count. For retryable data query and model inference nodes, after the first failure, it retryes twice according to the exponential backoff interval. For route calculation and candidate filtering nodes, instead of blindly retrying, it retains a snapshot of the failed input to avoid repeatedly writing results of different versions. Each constraint rule in the rule base simultaneously stores the comparison direction, numerical threshold, unit conversion factor, applicable ship type, applicable cargo label, and non-hit handling method; the rule orchestration module filters valid rules based on rule version number and effective time. If multiple valid thresholds exist for the same field, a unique rule is determined by priority and update time. If the threshold lacks a unit or cannot be converted to the required field, the rule is marked as unexecutable and the task is prevented from being published. The process engine assigns input validation thresholds and output record thresholds to each directed acyclic graph node. When the number of input records is zero or the output validation summary does not match, the node status is set to failure. The data query node selects the source in the order of primary data source, backup data source in the same region, and historical snapshot. The selection conditions are that the timestamp does not exceed the data validity period and the field coverage reaches 1. The source selection result is written to the running context for subsequent nodes to review. To avoid duplicate tasks caused by retries, the node executor uses an idempotent key composed of the task number, node number, and input version. If a successful result already exists, it is returned directly. If a failure snapshot exists, it is only re-executed after the data source version or rule version changes. Each re-execution generates a new run attempt number and saves the reason for the failure of the old attempt, the data source used, and the retry interval in the task log. When any node fails to obtain valid output within the specified time, the output of the result generation node contains a structured unmatched state including missing fields, invalid data sources, or failed node numbers, and the original requirement version and operation log are submitted for manual review; when all orchestration verifications pass, the task status is set to orchestrated, a task context identifier is generated for S3 to S6 to consume in sequence and written to the task context table, and the task status is only updated to scoreable result after S6 is completed.

[0022] In this specific embodiment, S3 includes: S3 reads port information, loading / unloading time windows, transport areas, and special transport requirements from the task context table, and loads basic data from vessel files, port scheduling, waterway surveys, and historical route databases. The node table of the network model contains node number, node type, latitude and longitude, control depth, opening hours, port operation capacity, and safety level. Node types include at least ports, locks, forks, and anchorages. The directed edge table contains start node, end node, segment length, minimum water depth, speed limit, navigation frequency, seasonal water level correction, restricted hours, and data validity period. The network construction module retains only waterways that are within their validity period and can be proven to be navigable by waterway survey records or port navigation announcements as directed edges, and removes duplicates by starting point, ending point, and direction; for waterways between adjacent nodes, physical distance, lock queuing time, navigation frequency, seasonal water level, and navigation restrictions are normalized to zero to one, respectively. The normalization denominator comes from the historical maximum value of the same type in the network parameter table. Values ​​exceeding the upper limit are truncated to one. When seasonal water level records are missing, the most recent valid water level version is used and the data is marked as downgraded. Edge weight calculation adopts ,in, This represents the index of the shipping network node at the starting point of a directed edge. Represents the index of the shipping network node at the endpoint of a directed edge, and , ; Indicates from node To the node Dimensionless boundary weight, , , , and These represent normalized physical distance, lock queuing time, navigation frequency, seasonal water level risk, and navigation restrictions, respectively. All are dimensionless quantities with a value range of [0,1]. The normalized denominators are derived from the historical maximum value of the same type and the upper limit of the network parameter table, respectively. Values ​​exceeding the upper limit are truncated to one. , , , and This indicates the non-negative weights stored in the network weight table, and their sum is one; the weight table is indexed by transport region and month, and is updated by fitting the actual flight time error of historical voyages. The path calculation module first searches the standard route database for pre-calculated paths that have not expired, based on loading port, unloading port, transport area, and water depth level. If a path is found, it verifies that each edge on the path still exists and that the edge weight version is consistent with the current network version. If a path is not found or is found to be invalid, the Dijkstra algorithm is used on the basic network model to search for a path with the minimum total edge weight. During the search, edges with a minimum water depth less than the maximum allowable draft plus the channel safety margin in the S1 structured matching parameters are removed, and the removed edges and their water depth reasons are recorded. When multiple paths with the same total weight exist for the same node, the path with the shorter estimated travel time is selected first, and then a unique result is determined based on the fewer number of segments and the lexicographical order of the node numbers. The estimated travel time is calculated by dividing the segment length by the corresponding speed limit in the waterway grade speed limit table and adding the lock queuing time. All time values ​​are uniformly expressed in minutes. If the opening time of any segment does not intersect with the loading and unloading time window, the path is marked as time-infeasible and other paths are searched. The path results are written to the standard route table, with fields including standard route number, demand number, node sequence, segment sequence, estimated travel time, total distance, minimum water depth, network version, weight version, and calculation method. Each segment also stores the direction, navigation restrictions, and water level version for S5 to perform draft and arrival hard filtering, and for S6 to calculate route familiarity. If no feasible path exists in the search space, the state of no feasible route, the set of infeasible edges, and the data version are written, and the task context is not included in the candidate score.

[0023] In this specific embodiment, S4 includes: S4 reads the ship identification number, timestamp, longitude, latitude, speed, heading, and positioning quality from the AIS historical database and associates them with port berthing and departure records, lock passage records, and ship files by ship identification number; the trajectory records are sorted in ascending order by timestamp, and only records with high positioning quality and complete fields are retained for duplicate timestamps. Adjacent records with a time interval of more than 30 minutes are divided into different trajectory segments, and all segmentation results retain the original record number for traceability; The trajectory cleaning module checks the coordinate range and speed continuity of adjacent positioning points, and calculates the instantaneous speed based on the spherical distance and time difference between adjacent points. Points with positioning errors exceeding 500 meters, instantaneous speeds exceeding 120% of the maximum allowable speed for the ship type, points identified as non-cargo vessels, or points located in time gap intervals are removed, and the reasons for removal are recorded in the trajectory quality table. Trajectory segments with fewer than 20 consecutive valid points after cleaning are not included in the voyage filing. Candidate stop segments are formed from consecutive points with a speed not exceeding three knots per hour and a duration of not less than thirty minutes. The spatial density and temporal span of the stop segments are used to adaptively determine the clustering neighborhood radius and the minimum number of samples. Determine the first The neighborhood radius of each time window, where... Indicates the docking time window index sorted by time and , Indicates the total number of time windows. , , and Both represent radii in meters. and All represent average speed in knots and require ;function Indicates that the input will be entered. Restricted to the lower bound With the upper realm The cutoff function between these parameters, provided by the port positioning error calibration table. and ;when Use when missing or not greater than zero And mark this time window as low quality; The spatial matching module matches the berthing segment cluster center with the port geofence and the anchorage geofence respectively. When the port fence and the anchorage fence overlap, the port fence is used first. When the cluster center does not fall into any fence but the distance to the effective channel node is less than one kilometer, it is retained as a temporary anchorage point and marked for verification. Clusters that exceed this distance are only recorded as abnormal stays and are not written into the set of effective berthing points. The cleaning trajectory between two consecutive valid stops is converted into a flight segment sequence through directed map matching. The map matching cost consists of the spatial distance, heading difference, and temporal continuity of the candidate flight segments. Dynamic programming is used to select the sequence with the minimum total cost and directional continuity. If there are flight segments in the matching sequence that are inconsistent with the S3 basic network model, the process backtracks to the suboptimal sequence and records the network version. If there is still no feasible sequence, the flight is marked as a map matching failure and is not included in the familiarity statistics. The standardized historical route file uses the following fields: vessel identification number, voyage number, origin port, destination port, valid call point sequence, directed segment set, number of segments passed, average voyage time, on-time arrival rate, and file version. The number of segments passed is aggregated according to the same origin and destination nodes and directions. The on-time arrival rate is obtained by comparing the port berthing time with the reservation time window. The statistical window is fixed at the most recent twelve months and is updated once a month. When the berthing and departure times of the same vessel on the same voyage are from multiple sources, the port scheduling record is used first, followed by the AIS inferred record, while retaining the source priority and time difference. After the file is built, it is written to the historical route database. S6 reads the directed segment set and on-time performance statistics from it. The standard route number of S3 is used as the file association key. Any cleaning or matching failure information is saved in the audit log without overwriting the original AIS data.

[0024] In this specific embodiment, S5 includes: S5 reads the structured matching parameters from S1, the standard routes from S3, and candidate vessel records from the vessel archives. The candidate records include vessel type, deadweight tonnage, design draft, current draft, draft safety margin, current position, average speed, loading and unloading capacity, and certificate validity period. First, it performs a pre-screening based on the vessel's certificate validity period, operating status, and transport area. Vessels that are out of service, have expired certificates, or are not within the permitted transport area are directly written into the candidate filter table and the corresponding reasons are recorded. The compatibility between ship type and cargo type is determined by looking up a table in the ship type compatibility matrix according to ship type, cargo category, packaging method and special transport label. The matrix records the compatibility flag, upper limit of hazard level, temperature control range and version number. Ships that do not match the matrix are not used for default compatibility, but the reason for the missing ship type compatibility rule is recorded. If the ship matches the matrix but the compatibility flag is not, the ship is marked as ship type mismatch and subsequent calculations are stopped. The deadweight tonnage filtering adopts the rule that the deadweight tonnage is not less than the product of the cargo tonnage and the preset loading coefficient. The loading coefficient ranges from 0.8 to 1.0 and is read from the loading coefficient table according to cargo type and ship type. If the ship's deadweight tonnage is less than the product of the cargo tonnage and the loading coefficient, the reason for insufficient tonnage is recorded. At the same time, the ship's deadweight tonnage, cargo tonnage, loading coefficient and calculation version are retained to avoid mistakenly recording insufficient tonnage as time infeasibility. The draft filtration compares the estimated draft after cargo loading with the minimum water depth of each segment of the standard route. The estimated draft is obtained by adding the cargo increment to the ship's current draft. The cargo increment is obtained by looking up the ship type draft curve table according to the deadweight tonnage range. When the estimated draft is greater than the minimum water depth of any segment minus the safety margin, the reason for the insufficient draft and the triggering segment are recorded. Ships with a full-load draft greater than the effective navigable water depth of the target route do not enter the qualified assembly. Arrival time filtering calculates the estimated arrival time based on the segmented voyage distance from the vessel's current position to the loading port, from the loading port to the unloading port, the vessel's average speed, the current time, loading operation duration, and time zone conversion results; using... Calculate the estimated arrival time, where, This indicates the estimated UTC timestamp of arrival at the port of discharge. Indicates the current UTC timestamp. and This represents segmented distances in nautical miles. This indicates the average speed read from the ship's records, expressed in nautical miles per hour, and requires... , This indicates the loading operation time in hours. When the average speed is missing or not greater than zero, the effective speed limit in the S3 channel class speed limit table or the vessel’s most recent effective average speed will be used first. If neither of these is available, the candidate vessel will be marked as having an arrival time that cannot be calculated and written into the filtering reason. When the estimated arrival time is later than the cargo cutoff time, the candidate vessel must record at least one of the following filtering reasons: arrival delay, current segment distance, average speed, and operation time. The cargo cutoff time is determined by the end time of the loading time window, and the time comparison uses UTC timestamps. Only vessels that meet the four hard conditions of vessel type, tonnage, draft, and arrival time are included in the qualified candidate vessel set. The filter table and the qualified set are linked through the demand number and the vessel number. For vessels lacking current position, average speed, load increment, or segment distance, the system reads the most recent valid record according to the data validity period rules and records the alternative data source version; if the backup record is still missing, it does not estimate or fill it with zero, but writes the reason for the missing field and excludes the vessel; for the requirement that the standard route is empty, all candidate vessels output the reason that there is no feasible route, and the result status is set to empty candidate; After filtering, S5 writes the qualified candidate vessel set into the candidate set table, with fields including demand number, vessel number, standard route number, hard filter passed item, estimated arrival time, estimated draft, available deadweight tonnage, data version, and risk flag; the filter reason table retains the conditions and values ​​for each item that failed. S6 only reads the qualified set and uses the filter reasons to explain the recommendation results. When the qualified set is empty, an empty candidate status is generated directly without performing scoring.

[0025] In this specific embodiment, S6 includes: S6 reads the qualified candidate vessel set from S5, the standard routes from S3, the standardized historical route archives from S4, as well as market freight rates and supply and demand status; the scenario recognition module calculates the historical matching number of target port pairs, route data coverage, percentile value of market freight rate index, and capacity supply and demand ratio within the same statistical period and market scope, and reads three types of non-negative weight vectors from the scenario weight table: regular mature routes, peak season capacity shortage, and newly opened routes. The scenario parameter table uses target port pairs, transportation areas, statistical periods, and cargo types as joint keys to store maturity frequency thresholds, coverage thresholds, freight rate percentile thresholds, supply-demand ratio thresholds, time mapping segments, neutral scores for missing dimensions, weight vectors, version numbers, and effective times. This table is recalculated monthly based on the most recent twelve months of fulfillment records and historical market freight rates. The recalculation results are first checked for false alarm rates and empty candidate rates in a verification window. Only versions that pass the verification are written into the parameter database. If data is insufficient for two consecutive months, the previous version is used and the reason for the delayed update is recorded. When the number of historical matches is not less than the maturity threshold and the route data coverage is not less than the coverage threshold, the task is marked as a regular mature route; when the market freight rate index reaches the 80th percentile and the capacity supply-demand ratio is not greater than 0.8, the task is marked as a peak season capacity shortage scenario; when neither of the two conditions is met, it is marked as a newly opened route scenario; when multiple conditions are met simultaneously, a unique mark is selected according to the priority of peak season capacity shortage, regular mature routes, and newly opened routes, and the corresponding weight version is switched. For each qualified candidate vessel, the time and space urgency module performs a piecewise linear mapping based on the remaining time between the estimated arrival time and the cargo deadline. The shorter the remaining time and the less overdue the vessel, the higher the score. Overdue candidates are kept at zero and retain the overdue status of S5. The route familiarity module reads the set of directed segments in the S4 file and calculates the intersection with the set of directed segments of the S3 standard route. Segments with different directions are not included in the intersection. The performance quotation parameter table uses market scope, cargo type, statistical period, and vessel type as joint keys. Fields include on-time rate, cancellation rate, anomaly rate, reference freight rate, quotation deviation limit, normalization benchmark, sample size, version number, and effective time. An example record in the table uses a port pair and bulk cargo type as keys, storing the reference freight rate per ton per nautical mile, the quotation deviation limit of 30%, and the sample size. If the sample size is less than 30, it will switch to the transportation area-level record. If the area-level record still does not exist, it will use the scenario-neutral score and write a missing flag. The table is updated the day after the statistical window ends. When the anomaly rate exceeds the threshold, the previous version is frozen and a review is triggered. The time-space urgency score is determined by a time mapping table. The time mapping table stores the remaining time interval, corresponding score, overdue truncation rule, and version number according to the scenario label and cargo time window version. This table uses the remaining time of completed voyages to perform binning fitting with the actual on-time results. The interval boundary adopts the tenths of the validation window, and the score adopts a monotonically increasing constraint and checks the mapping error before release. The interval is looked up in the table in a left-closed and right-open manner. When the remaining time falls outside the interval, a zero score or a full score boundary value is used respectively. When there is no matching record in the table, the most recently effective version is used and the reason for version replacement is recorded. When route familiarity is missing, the neutral score and missing flag are read from the scenario parameter table to ensure that the missing handling is consistent with the weight version. use Calculate the overall matching degree, where, , , and All are dimensionless quantities ranging from zero to one, representing the overall matching degree, the time and space urgency score, the route familiarity score, and the performance quotation score, respectively. Obtained by normalizing the time mapping table according to the remaining time and scene version. The pricing parameters were obtained by normalizing the market reference freight rate and the price deviation from the performance quotation table. , and This indicates that the non-negative weights read from the scene weight table sum to one. The weight table uses scene tag, transportation region, and version number as keys, and is obtained by fitting historical recommended fulfillment losses and candidate selection results through a constrained grid search. It is verified monthly to ensure the weight sum is one, each component is non-negative, and the overall score ranking stability. The neutral scores for missing dimensions are also limited to the range of zero to one and use the same weight version, thus maintaining the dimensionless weighting result. The final weighting is then displayed to the user. Multiply by 100 to convert to a score from 0 to 100; increase the weight of route familiarity for regular and mature routes, increase the weight of time and space urgency for peak season capacity shortages, and increase the weight of fulfillment pricing and data coverage for newly established routes. The time-space urgency score is determined by a linear mapping table between remaining time and the scene's time window, while route familiarity is determined by... ,in, Indicates the dimensionless overlap of flight segments. This represents the set of directed segments of the S3 standard route. This represents the set of directed segments in the S4 historical route archives. When any set is empty, R uses the neutral score in the scenario weight table. The neutral score is looked up using the scenario label, transportation area, and missing dimension as the joint key. If no match is found, the most recently effective version is selected and the replacement version number is recorded. The route data is marked as insufficient in the recommendation results. After the recommended voyage is completed, the performance feedback is associated with the user-selected vessel, actual loading time, actual arrival time, actual freight rate, and abnormal events by voyage number and event timestamp. The system first deduplicates by voyage number and event timestamp, cancels voyages, voyages with incomplete fields, and voyages with unverified abnormal events as invalid feedback, which will not participate in parameter updates. Valid feedback is written into the vertical large model fine-tuning sample library, the recommendation preference parameter library, and the matching scoring parameter library, respectively, and the version before the update is retained. When the number of valid feedback samples in a statistical window reaches the release threshold and the quality score is not lower than 80, the system atomically releases the updated parameters with a single version number and replaces the current version after the field consistency check passes; if the quality score is lower than 80, the anomaly rate exceeds 20%, or the field consistency check fails after release, version recovery is triggered, the current version pointer is atomically switched back to the version before the update and the update is frozen, and after recovery is completed, an audit log containing the triggering conditions, the recovered version, and the operator is written. Candidate vessels are sorted in descending order of overall matching score. If the overall matching scores are the same, the order is determined by the earlier expected arrival time, the absolute value of the deviation from the performance quotation is closer to zero, and the lexicographical order of the vessel number. The results generation module outputs the vessel name, vessel number, standard route, overall matching score, three sub-scores, hard filter passed items, filtering reasons, data version, scenario markers, and risk warnings. It also performs field-level consistency checks on each output field with the S5 candidate set and scoring records. When field-level consistency checks detect inconsistencies in vessel name, route, score, or filtering reason, the generation of natural language descriptions is stopped, and only structured results to be verified are output. The original sorting results are then transferred to manual review. When the verification passes, the recommended results are written to the results table, and the recommended voyage number is returned to the business platform. The performance feedback continues to update the matching parameters in the subsequent statistics window, thereby maintaining the traceability of the same demand, candidate, scoring, and feedback chain.

[0026] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

[0027] This invention connects multimodal information parsing, shipping basic network path calculation, AIS historical route archiving, candidate vessel hard filtering, and dynamic scoring recommendation into a traceable data processing chain, enabling the matching results to simultaneously meet transportation feasibility constraints and shipping scenario change requirements.

[0028] In the recommendation generation stage, the vertical large model generates descriptions based solely on the candidate set and scoring records, and performs field-level consistency checks on ship names, routes, scores, and filtering reasons. Performance data is associated by voyage and used to update fine-tuning samples, recommendation preferences, and scoring parameters, thereby suppressing the illusion of a large model and forming a rollback-friendly iterative mechanism.

Claims

1. A cargo ship matching method based on a vertical large model, characterized in that, include: S1. Receive natural language text, cargo list, port notification and ship certificate images, analyze the vertical large model of shipping obtained through optical character recognition and training, and form structured matching parameters including cargo type, cargo tonnage, loading port, unloading port, loading time and transportation area; S2. Load shipping scenario constraint rules based on structured matching parameters, and use a directed acyclic graph process engine to orchestrate data query, route calculation, candidate screening, scoring, and result generation tasks; S3. Obtain vessel files, automatic identification system trajectories, port scheduling, performance, freight rates, and waterway data, and establish a basic shipping network model with ports, locks, forks, and anchorages as nodes and navigable waterways as directed edges to calculate standard routes; S4. Clean historical automatic identification system trajectories, match valid voyage maps to the model, and form standardized historical route files for vessels; S5. Based on structured matching parameters and standard routes, perform hard filtering on candidate vessels by vessel type, tonnage, draft, and arrival time to obtain a set of qualified candidate vessels and the reasons for filtering; S6. Configure scenario weights based on market freight rates, supply and demand status, historical matching times, and route maturity, calculate the spatiotemporal urgency, route familiarity, and performance quotation score for qualified candidate vessels, form a comprehensive matching degree and sort them, generate recommendation results, and update matching parameters using performance feedback from recommended voyages.

2. The cargo ship matching method according to claim 1, characterized in that, S1 includes: performing text recognition, field localization, and certificate field verification on the image; aligning the recognized fields with natural language text and cargo manifests; extracting special transportation requirements; obtaining a first intent category through keyword classification, a second intent category through vector similarity classification, and a third intent category through vertical large model classification; confirming the cargo ship matching intent when at least two of the three categories are consistent and the confidence of each category participating in the consistency determination is not less than 0.7; when cargo tonnage, loading port, unloading port, or loading time is missing, completing it according to the session context; if completion fails, generating a supplementary query containing the missing fields; receiving the user's answer, merging it into the original request, and re-performing the field integrity verification; outputting an unmatched state when the maximum number of queries is reached and the field is still missing.

3. The cargo ship matching method according to claim 2, characterized in that, S2 include: Using cargo type, port of loading, port of discharge, transport area, loading time and special transport requirements from the structured matching parameters as the scenario routing key, the system reads ship type compatibility rules, special transport constraint rules, draft constraint rules, time constraint rules and data validity period rules from the rule base, and configures data query, network path calculation, historical route extraction, hard filtering, scoring and recommendation generation as nodes in a directed acyclic graph. When any node returns missing data or expired data, an alternative data source is selected according to the data timestamp and the data source version is recorded. If the alternative data source is still unavailable, an unmatched status containing the missing fields is output.

4. The cargo ship matching method according to claim 1, characterized in that, S3 includes: The actual navigable waterways between adjacent shipping nodes are used as directed waterway edges. Physical distance, lock chamber queuing time, waterway passage frequency, seasonal water level, and navigation restrictions are normalized respectively. The edge weights are formed by weighting and summing according to preset non-negative edge weight coefficients. For port pairs that exist in the standard route database and whose data timestamps have not expired, the pre-calculated path is invoked. For port pairs that do not exist in the standard route database or whose pre-calculated path has expired, the Dijkstra algorithm or A* algorithm is used to calculate the path on the shipping basic network model, and the standard route consisting of a sequence of water segments and water depth constraints for each water segment is output.

5. The cargo ship matching method according to claim 1, characterized in that, S4 includes: cleaning historical automatic identification system trajectories based on coordinate drift, abnormal speed, non-cargo vessel identification, time discontinuity, and duplicate recording rules, and removing trajectory points with positioning errors exceeding a preset error threshold; extracting candidate berthing segments from the cleaned trajectories with speeds not exceeding 3 knots per hour and durations not less than 30 minutes; adaptively determining the neighborhood radius and minimum sample size for density clustering based on the spatial density and time span of the berthing segments, and spatially matching the cluster centers with the dock geofence and anchorage geofence respectively, distinguishing between valid dock berthing points and temporary anchorage points by using unified geographical coordinates and handling overlapping fences according to dock priority rules; converting the trajectories between two consecutive valid dock berthing points into directed segment sequences through directed map matching and writing them into the standardized historical route archive of the vessel.

6. The cargo ship matching method according to claim 1, characterized in that, S5 includes: When the ship type and cargo type do not meet the preset compatibility matrix, the ship's deadweight tonnage is less than the product of the cargo tonnage and the preset loading coefficient, the ship's full-load draft is greater than the effective navigable water depth of any segment of the target route, or the estimated arrival time calculated based on the segmented voyage distance from the ship's current position to the loading port and then to the unloading port, the average speed, the current time, the loading operation time, and the time zone conversion result is later than the cargo source cutoff time, the corresponding ship will be marked as unqualified and at least one filtering reason will be recorded; the preset loading coefficient is between 0.8 and 1.0, and the cargo source cutoff time is determined by the end time of the loading time window; only ships that do not hit any filtering reason will be written into the qualified candidate ship set, and an empty candidate status will be output when the qualified set is empty.

7. The cargo ship matching method according to claim 6, characterized in that, S6 include: The segmented voyage distance from the vessel's current location to the loading port and then to the unloading port, the remaining time between the estimated arrival time and the cargo deadline, are mapped to a spatiotemporal urgency score using a preset linear mapping and overdue truncation rules. When any segment set is empty, the route familiarity is marked as missing and a preset neutral score is applied. When both sets are not empty, the number of intersection elements between the directed segment set and the standard route segment set in the vessel's standardized historical route archive is divided by the number of elements in the union of the two sets to obtain the segment overlap and is mapped to a route familiarity score. Historical performance and quotation scores are calculated based on the on-time rate, cancellation rate, abnormal rate, and the deviation between the vessel's quotation and the reference freight rate in the same market and statistical window within a preset statistical window. Each score is normalized to 0 to 100 points according to a unified benchmark, with a preset neutral score applied to missing dimensions, and a non-negative scenario weight that sums to 1 is used to calculate the overall matching degree.

8. The cargo ship matching method according to claim 2, characterized in that, The vertical large-scale model in the shipping field is supervised and fine-tuned using training samples consisting of historical inquiry texts, cargo lists, port notices, ship certificate fields, matching results, and performance results in the shipping field. Before generating recommendation descriptions, the model performs field-level consistency checks on the ship names, routes, scores, and filtering reasons in the output with the set of qualified candidate ships and the score records. If the checks are inconsistent, the generation of natural language fact fields is stopped, a structured pending verification status is output, and the original ranking results are handed over to manual review. Before writing, the training samples undergo certificate-sensitive field desensitization, quality scoring, and version binding.

9. The cargo ship matching method according to claim 7, characterized in that, The configuration of scenario weights includes: calculating the historical matching count, route data coverage, 80th percentile of the market freight rate index, and capacity supply-demand ratio of the target port pair within the same statistical period and market scope; when the historical matching count is not less than the preset maturity count and the route data coverage is not less than the preset coverage, the task is marked as a regular mature route; when the market freight rate index reaches the 80th percentile and the capacity supply-demand ratio is not greater than 0.8, the task is marked as a peak season capacity shortage scenario; when multiple marks are satisfied simultaneously, a single mark is selected according to the priority of peak season capacity shortage scenario, regular mature route, and newly established route; when neither the conditions for regular mature route nor peak season capacity shortage scenario are satisfied, the task is marked as a newly established route scenario, and the corresponding non-negative weight vector is switched according to the task mark.

10. The cargo ship matching method according to claim 8, characterized in that, The user selection behavior and voyage fulfillment results include the user-selected vessel, actual loading time, actual arrival time, actual freight rate, and abnormal events. The method performs deduplication based on voyage number and event timestamp, and marks canceled or unfulfilled voyages, voyages with incomplete fields, and voyages with unverified abnormal events as invalid feedback. For valid feedback, the consistency between recommended vessels and actual fulfilled vessels, arrival time deviation, and price deviation are calculated, and the calculation results are written into the vertical large model fine-tuning sample library, recommendation preference parameter library, and matching score parameter library, respectively. After the sample quantity and quality score reach the preset release threshold, the parameters are updated atomically with a single version number, and the previous version is retained. When the quality score is less than 60 points, the anomaly rate exceeds 20%, or the field consistency verification fails after release, a rollback is triggered, the previous version is restored, and the audit log is recorded.

Images