What the data for this category looks like
Port and shipping document and material drafting data mainly comes from port operation documents, vessel scheduling logs, import and export customs declaration files, shipping service contracts, loading and unloading operation records, and other sources. Data updates are divided into real-time and scheduled categories. Loading and unloading operation records and berth scheduling information are updated in real time along with work processes. Annual cooperation agreements and industry policy documents are updated quarterly or annually. Most documents are structured forms and semi-structured text, including fixed fields such as vessel name, voyage number, berth number, cargo type, loading and unloading tonnage, and operation duration. Units include professional shipping units such as TEU, ton, hour, and meter.
What constraints these characteristics impose on the knowledge base retrieval and recall link
Port shipping document data has both structured form and semi-structured text features, and contains a large number of specialized fields and units. This requires retrieval and recall to support field-level precise matching, to avoid generic recall results interfering with the accuracy of document drafting. Real-time updated operation data requires the recall link to have low latency characteristics, and long index update waiting times are not acceptable. Some individual documents are lengthy; for example, annual shipping contracts can reach tens of thousands of characters. After chunking, cross-chunk associated information may be lost, so recall logic that supports context association needs to be configured. Additionally, document requirements for different business scenarios such as customs declaration files and vessel scheduling plans vary significantly in terms of knowledge base dimensions, so directional recall by business type must be supported.
How to set the configurations
Reference only; verify against the target FastGPT release and deployment documentation.
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
similarity | 0.72–0.80 | Matches the precision of port and shipping specialized terminology, avoids recalling irrelevant general shipping documents |
limit | Top 8 entries | Port documents mostly consist of fixed field combinations, a small number of highly matched results can cover drafting needs |
searchMode | semantic | Adapts better to professional content understanding for semi-structured operation logs and contract texts via semantic recall |
usingReRank | Enabled | Reranks recall results, prioritizes documents containing core fields such as vessel name and voyage number |
datasetSearchUsingExtensionQuery | Enabled | Generates extended query terms based on the original question, covers synonyms and professional abbreviations for port and shipping |
collectionIds | Bind port operation knowledge base and shipping policy library | Directionally recalls exclusive documents for corresponding business scenarios, avoids interference from cross-category data |
Three common errors
- Phenomenon: When uploading port operation contracts or customs declaration files larger than 10MB, the system returns an error about abnormal chunk vectorization, or the embedding field of some chunks is empty. Cause: Port documents often contain long sentences and specialized term combinations. The default chunking parameters do not adapt to the semantic integrity of long texts, leading to semantic breaks after chunking, which prevents the vectorization model from processing the broken segments normally.
- Phenomenon: When configuring knowledge base retrieval, the number of returned results does not match the set
limit, and a large number of general documents unrelated to port business are included. Cause: ExclusivecollectionIdsare not bound, so the recall scope covers the entire platform knowledge base, and irrelevant data interferes with precise matching. - Phenomenon: After the server restarts, the uploaded port operation knowledge base is in a not-ready state, and retrieval requests cannot be initiated. Cause: Automatic index triggering rules are not configured. After restarting, the system does not automatically execute the sharding and vectorization process for uploaded files, and manual index triggering is required.
How to confirm the configuration is complete
- Initiate a test query containing port specialized terminology, check whether all returned documents are from the bound port-specific knowledge base.
- Adjust the value range of the
similarityparameter, observe changes in the matching degree of returned results, and confirm that parameter adjustments take effect normally. - Upload a small port operation document, check whether the system automatically completes sharding and vectorization without requiring manual index triggering.
- Test the result sorting after the rerank function is enabled, confirm that documents with core fields and high matching degrees are displayed first.
The values provided are common starting points and should be measured against the reader's own samples.
Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-09-28.