What this category of data looks like
Data for this category typically comes from ERP systems, supplier shipping documents, logistics tracking information, and equipment manufacturer backends. Daily processed documents include purchase orders, arrival acceptance forms, serial number lists, and invoice materials. Data updates follow a per-order or weekly cadence. Data fields include purchase model, serial number, supplier information, arrival time, acceptance status, and others. Units are mostly physical measurement units such as sets, pieces, and units, and must be bound to the delivery requirements of specific integration projects.
What constraints do these characteristics impose on the reranking and hybrid retrieval link
Data for this category comes from multiple dispersed sources, and update cadences vary with purchase orders. This means hybrid retrieval must support heterogeneous document formats and field structures. Core document fields are physical attributes such as purchase model and serial number. The reranking link must prioritize matching strongly associated business fields to avoid result deviations caused by generic semantic matching. Additionally, since data is bound to specific integration projects, retrieval results must be filtered by project dimension. It must also adapt to the rapid response needs of on-duty operations, limiting the number of valid results returned per query.
How to set the configurations
| Configuration Item | Recommended Value Range | Rationale |
|---|---|---|
| Similarity threshold | 0.72–0.85 | Matches strongly related business fields such as purchase model and serial number, filters low-relevance generic semantic results |
| Maximum single search results | Top 8–12 | Adapts to the rapid response needs of on-duty operations, reduces manual screening workload |
| Search mode | Hybrid retrieval | Supports multi-source heterogeneous data such as ERP, supplier shipping documents, and logistics information |
| Enable reranking | Yes | Prioritizes reranking core business fields such as model and serial number, improves business matching accuracy of retrieval results |
| Reranking result limit | Top 3–5 | Calibrated through actual testing, focuses on the most relevant arrival acceptance-related results |
This configuration applies to FastGPT v4.17.0.
Three common mistakes
- Symptom: The reranking model call returns a "model incompatible" error or empty results. Cause: The reranking model is not configured in the request format required by FastGPT, or an unsupported reranking model architecture is used.
- Symptom: The custom reranking model request address cannot connect after being filled in, and logs show connection timeout. Cause: The model service address inside the docker container is not filled in correctly, or the port permissions for the model service are not opened.
- Symptom: Qwen3-Reranker-8B cannot be used as a reranking model, and an exception occurs during calling. Cause: The current FastGPT version does not support this reranking model, and the request parameters do not match.
How to confirm the configuration is complete
- Upload typical documents of this category, perform a retrieval test, and check whether the results prioritize matching core business fields such as model and serial number.
- Check the enabled status of the reranking function, confirm that retrieval results have undergone reranking processing before display.
- Verify the hybrid retrieval effect of multi-source data, confirm that documents from different sources such as ERP, logistics information, and supplier shipping documents can all be retrieved.
- Adjust configuration item parameters, observe changes in the number and relevance of retrieval results, and confirm that the configuration takes effect.
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-10-19.