What the data for this category looks like
Rail transit equipment ledger data mainly comes from equipment factory archives, operation and maintenance repair systems, and online monitoring terminals. Updates are triggered incrementally after each single maintenance, with full synchronization performed monthly. Each ledger document contains structured fields and unstructured text. Structured fields include equipment number, model, total operating hours, maintenance cycle, and replacement part number, with units including kilometers, hours, and pieces. The unstructured section includes maintenance details and fault troubleshooting records, with significant variation in the length of individual documents.
What constraints these characteristics impose on the knowledge base retrieval and recall link
Rail transit equipment ledgers have dense structured fields, update frequency that fluctuates with maintenance cycles, and wide variation in document length. These traits create multiple constraints for retrieval and recall. Precise matching rules must be set for core fields such as equipment number and model to avoid recalling ledgers of unrelated equipment. Incremental updates must adapt to both monthly full synchronization and incremental synchronization triggered by single maintenance, to prevent index lag. Reasonable chunking parameters must be configured for long documents to avoid redundant cross-document recall. Unit identification logic must also be unified to ensure consistent retrieval results for synonymous units such as "kilometer" and "kilometre".
How to configure the settings
Reference only; verify against the target FastGPT release and deployment documentation.
| Configuration Item | Recommended Range | Rationale |
|---|---|---|
similarity | 0.75–0.85 | Core field matching accuracy for rail transit equipment ledgers is high. A threshold that is too low will introduce irrelevant equipment data, while a threshold that is too high may miss valid maintenance records. This range is calibrated based on actual testing |
limit | Top 8–12 entries | Each ledger has many fields. Too many recalled entries will exceed the context window, while too few will fail to cover all relevant maintenance information. Adjust based on actual scene testing |
searchMode | vector_only | Ledger data mainly consists of structured fields and operation and maintenance text. Mixed keyword and vector retrieval is not needed; only vector retrieval can ensure matching accuracy |
usingReRank | Enabled | Vector matching for long documents and multi-field data is prone to deviation. Reranking corrects errors in similarity calculation and improves the recall priority of core ledgers |
datasetSearchUsingExtensionQuery | Enabled | Core fields such as equipment number and model require extended queries to match synonymous expressions. For example, matching "CRH380A" to "Hexie 380A EMU" |
collectionIds | Corresponding exclusive collection ID for rail transit equipment ledgers | Avoid retrieving documents from other categories, ensuring the recall scope only covers target ledger data |
Three common configuration mistakes
- Symptom: The
similarityvalue of retrieval results exceeds 10000, and all results are highly duplicated. Cause: Thesimilaritythreshold filter is not configured, or the embedding model is not adapted to the structured fields of rail transit equipment, leading to abnormal offset in vector calculation. - Symptom: No index entries are generated after ledger documents are uploaded, and no available m3e channel options appear in the backend. Cause: The exclusive channel for the corresponding vector model has not been added on the FastGPT platform, or the documents do not include core ledger fields such as equipment number and model, so the index trigger conditions are not met.
- Symptom: After filling all input items in the workflow and running it, the error "Cannot convert undefined or null to object" is displayed. Cause: The
collectionIdsparameter is not configured correctly, so the retrieval link fails to obtain valid ledger collection data, triggering a type conversion error.
How to confirm the configuration is correct
- Retrieve the ledger for a specified equipment number, and check whether the returned results only include documents for that equipment, with no data from unrelated devices.
- Upload a new maintenance ledger document, wait 10 minutes, then check the index list to confirm whether the document is displayed, verifying that incremental synchronization is effective.
- Adjust the
similaritythreshold range, compare recall results under different thresholds, and confirm that the core field matching accuracy meets business requirements. - Run a workflow that includes a retrieval link, check for type conversion-related errors, and confirm that the
collectionIdsparameter is configured correctly.
The values given 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.