What data looks like for this category
This category of data originates from the Chinese Center for Disease Control and Prevention Information System, medical institution HIS and infectious disease reporting systems, and laboratory testing systems. The update frequency is daily. Routine documents include infectious disease report cards, epidemic analysis reports, case correction records, clustered epidemic reports, and epidemiological investigation reports. Document fields include case number, diagnosis type, reporting time limit, correction flag, clustered event association information, and others. Units are mostly standard health statistical units. The length of individual documents varies widely, ranging from report cards with hundreds of characters to epidemiological investigation reports with thousands of characters.
What constraints these characteristics impose on the "knowledge base retrieval and recall" link
Decentralized data sources require retrieval pipelines to support associated queries across multiple datasets, to avoid missing cross-system case association data. The daily update rhythm requires retrieval configurations to adapt to near-real-time data synchronization, ensuring recall results include the latest case corrections and epidemic reports. Diverse document types and obvious field differences require targeted configuration of semantic matching rules, to avoid confusing the number field of report cards with the diagnosis process of epidemiological investigation reports. The wide span of individual document lengths requires controlling the total length of recalled fragments, while retaining the semantic integrity of core business fields such as case correction and reporting time limit. Legal reporting rules require retrieval results to strictly match disease control business specifications, and non-compliant content associations must not be introduced.
Reference only; verify against the target FastGPT release and deployment documentation.
How to set configurations
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
similarity | 0.75–0.85 | Match the core semantics of infectious disease reports, filter irrelevant case data with low similarity |
limit | Top 6 entries | Cover the number of case-related documents commonly seen under a single query, while controlling the total context length |
usingReRank | Enabled | Re-rank the initially recalled results, correct semantic deviations in initial retrieval, especially for detail fields such as case correction and time limit |
datasetSearchUsingExtensionQuery | Enabled | Expand disease control professional terminology based on the original question, improve recall effectiveness for professional report terminology |
collectionIds | Fill in according to the actually bound disease control document dataset | Limit the retrieval scope to only official data sources of this category, avoid mixing irrelevant documents from other business systems |
Three common misconfigurations
- Phenomenon: After enabling
usingReRank, the retrieval result only returns a single highest-similarity entry. Cause: The return count parameter of the re-ranking model is not configured correctly. The default setting only outputs the Top 1 result, which does not meet the requirements of multi-case associated retrieval. - Phenomenon: Retrieval response time exceeds 15 seconds, failing to meet business real-time requirements. Cause: The retrieval scope of
collectionIdsis not limited, and retrieval is performed across multiple irrelevant datasets, resulting in excessive data loading and matching overhead. - Phenomenon: No document download links are returned in the published application, but normal in debug mode. Cause: The public access permission configuration of the knowledge base is not enabled, or the download permission setting of the corresponding dataset is not bound, resulting in the pipeline being unable to generate download links after publication.
How to confirm the configuration is complete
- Execute test queries containing specific cases or epidemic scenarios. Verify that retrieval results include the core fields of corresponding documents, and the number of results matches the
limitconfiguration requirements. - View retrieval logs. Confirm that
usingReRankhas taken effect, the sorted result order differs from the initial recall results, and documents related to case correction are covered. - Verify retrieval response time. Test under peak scenarios, confirm that the time meets business expectations and no timeout errors occur.
- Switch to the published environment. Test whether the download links of retrieval results are generated normally, consistent with performance in debug mode.
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.