What the data for this category looks like
The data for this category primarily comes from enterprise existing IT system inventories, official directories of domestic hardware and software, project test environment outputs, and public materials from hardware and software vendors. Daily produced documents include hardware and software adaptation lists, compatibility test reports, system migration plans, and operation and maintenance issue ledgers. Data update cycles follow individual independent innovation replacement projects, or synchronize the latest domestic hardware and software version information quarterly. Data fields include hardware and software model, adaptation version, compatibility status, migration steps, fault troubleshooting records, etc. There are no unified fixed units, and adjustments are made based on the specific content of each individual document.
What constraints these characteristics impose on the "knowledge base retrieval and recall" link
The data sources for this category are scattered. Multiple types of knowledge bases must be associated to cover different document types such as adaptation lists and test reports, which increases the complexity of retrieval scope configuration. Data updates are not real-time. Periodic incremental synchronization is required to ensure the timeliness of recalled content. Document structures vary significantly. Adaptation lists are structured entries, while test reports are mostly unstructured test records, requiring adaptation to different matching logic. There are no unified units for fields. Priority should be given to matching models and version numbers during retrieval to avoid errors caused by unit matching. Operation work order scenarios mostly involve urgent faults. High-priority issue ledger entries must be recalled first, which places additional requirements on the recall sorting logic.
The following configurations are based on FastGPT v4.17.0
How to set the configurations
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
similarity | 0.75–0.85 | Independent innovation adaptation data mostly requires precise matching of models and versions. A threshold that is too low will introduce irrelevant compatibility entries, while a threshold that is too high will miss some compatible variants |
limit | Top 8–12 entries | Operation work order scenarios require quick access to core adaptation information. Too many entries will increase the context length, while too few entries will fail to cover all compatibility scenarios. This configuration corresponds to the segment count logic for knowledge base recall, and should be adjusted based on work order response timeliness |
searchMode | vector | Independent innovation adaptation data includes structured models and unstructured test conclusions. Vector retrieval can balance semantic and keyword matching needs |
usingReRank | Enabled | Recalled adaptation entries need to be sorted by relevance to avoid mismatches caused by similar domestic hardware and software model names |
datasetSearchUsingExtensionQuery | Enabled | Operation work orders often contain vague fault descriptions, and extended queries can associate with troubleshooting steps in corresponding adaptation issue ledgers |
collectionIds | Collection of knowledge base IDs associated with the project | Knowledge bases for independent innovation adaptation projects are split by adaptation stage. When the number of project knowledge bases exceeds 30, accurately specifying the associated collection avoids an overly large retrieval scope and reduces interference from irrelevant data |
Three common mistakes
- Phenomenon: When uploading a compatibility test report larger than 10MB, the interface prompts a vectorization exception, and normal operation resumes after repeated retries. Cause: Long text does not trigger a reasonable chunking logic, resulting in too many chunks exceeding the system's temporary cache limit.
- Phenomenon: A large number of irrelevant entries are returned when searching for work order issues, with similarity scores below 0.7. Cause: The
similarityparameter threshold is not adjusted for the precise matching requirements of independent innovation adaptation, introducing adaptation data for non-corresponding models. - Phenomenon: Retrieval results do not include the latest domestic hardware and software adaptation information. Cause: Knowledge base data is not updated according to the project cycle or quarterly, resulting in recalled content lagging behind the current adaptation list.
How to confirm the configuration is complete
- Upload a single adaptation document larger than 10MB, check that the chunk count is normal and no vectorization error prompts appear.
- Enter a test query containing specific domestic hardware and software model names, check that the recall results are sorted according to relevance priority.
- Manually trigger a knowledge base incremental synchronization, confirm that the latest adaptation list entries can be retrieved normally.
- Verify the workflow shunt configuration, confirm that tool calls and MCP calls can access the corresponding knowledge base collections separately.
- Verify the
collectionIdsconfiguration: when the number of project knowledge bases exceeds 30, only the specified associated knowledge base collection is retrieved.
Note: The configuration values listed are common starting points. They should be validated against the corresponding deployment 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.