What this category of data looks like
Data for this category primarily comes from daily outputs of manufacturing enterprise equipment departments and workshop maintenance teams. It includes documents such as equipment ledgers, inspection checklists, maintenance plans, work orders, failure analyses, spare parts lists, and special equipment inspection records. Data sources cover EAM/CMMS systems, equipment sensor collections, operator inspection records, maintenance history archives, spare parts inventory ledgers, and statutory inspection information.
Update frequency varies by scenario. Inspection checklists and sensor data are updated per shift. Maintenance plans and spare parts lists are updated weekly or monthly. Work orders and failure analysis documents are generated immediately when a fault occurs.
Documents include structured fields such as equipment numbers, inspection parameter thresholds, spare part models, and inspection validity periods. Units include equipment-related standard units such as millimeters, pascals, and operating hours.
What constraints these characteristics impose on knowledge base retrieval and recall
Data sources are scattered and update frequencies vary widely. Retrieval scope must be precisely limited to the exclusive dataset of the target workshop to avoid interference from cross-workshop documents.
There are many structured fields, including precise matching items such as equipment numbers and spare part models. Retrieval must support prioritized matching of structured fields to fit core retrieval needs.
Faults require quick location of associated documents. Retrieval response time must be controlled within a reasonable duration. Recalled results must cover core reference materials such as maintenance history and failure analyses.
Statutory documents such as special equipment inspection records require high-confidence matching. Retrieval thresholds must be strictly set to avoid missing compliance-related content.
How to set the configurations
The following configurations are written for FastGPT v4.17.0.
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
similarity | 0.75–0.85 | Matches structured fields such as equipment numbers and inspection parameters, avoids irrelevant document interference, and covers valid retrieval results |
limit | Top 8 entries | Covers three core document types: inspection checklists, work orders, and failure analyses, and controls the context length of a single retrieval |
searchMode | fullTextRecall | The query examples emphasize identifiers or specialist terms; test this mode with representative data, not as a product default. |
usingReRank | Enabled | Performs secondary sorting of recalled results by fault relevance, optimizes result priority for maintenance scenarios |
datasetSearchUsingExtensionQuery | Enabled | Supplements synonym expansion for inspection terminology and equipment models, and matches standard naming rules of equipment ledgers |
collectionIds | Exclusive dataset ID list for the target workshop | Limits retrieval scope, only calls authorized documents such as the workshop’s EAM/CMMS and inspection records. Exclusive IDs must be obtained via official code interfaces, and public IDs must not be copied directly |
Common Mistakes
- Empty retrieval results or excessive irrelevant documents. Phenomenon: After entering an equipment inspection number, returned results include equipment documents from other workshops or unrelated process parameter documents. Cause:
collectionIdsis not configured correctly, so the retrieval scope covers non-target workshop datasets, or thesimilaritythreshold is set too low, leading to excessive irrelevant content being recalled. - Invalid knowledge base ID prompt. Phenomenon: After deployment, the retrieval interface returns an error prompt indicating the dataset ID does not exist. Cause: Public dataset IDs are copied directly, the target workshop’s exclusive inspection and work order datasets are not bound, or the ID format does not match system requirements.
- Local knowledge base exposed to public network. Phenomenon: Unauthorized accounts can retrieve sensitive documents such as the workshop’s equipment ledgers and spare parts lists via public interfaces. Cause: Public network access permissions are not disabled during deployment, or no access whitelist is configured for the dataset, leading to sensitive data leakage risks.
- Retrieval response timeout. Phenomenon: After triggering a fault retrieval, no results are returned after waiting more than 10 seconds. Cause: The
limitparameter is not restricted, leading to excessive cross-category documents being recalled, orusingReRankis not enabled, leading to excessive subsequent processing time.
How to Verify Proper Configuration
- Input the inspection item number of a specific device, and verify that returned results only include associated documents such as the device’s ledger, recent inspection checklists, and work orders.
- Check the dataset name corresponding to
collectionIdsin the retrieval configuration panel, confirm that it only includes authorized documents such as the workshop’s EAM/CMMS and inspection records. - Trigger a simulated fault scenario retrieval, and check whether returned results include failure analysis documents, with top-ranked results having high relevance to the current fault.
- Test access to the knowledge base with an unauthorized account, confirm that the workshop’s equipment documents cannot be retrieved, and verify that access permission configurations are effective.
The values provided are common starting points and should be evaluated against local deployment samples.