What data for this category looks like
Core data sources for this category include the Chinese Center for Disease Control and Prevention Information System, medical institution HIS systems, infectious disease reporting systems, and laboratory testing systems. Data updates occur daily. Commonly processed documents include infectious disease reporting cards, epidemic situation analysis reports, case correction records, clustered epidemic reports, and epidemiological investigation reports. Infectious disease reporting cards contain fixed fields such as basic case information, diagnosis results, and reporting time limits. Epidemiological investigation reports include long-form content such as case activity trajectories and exposure history. Supported document formats include Word, Excel, PDF, and others. A single batch Excel report may contain dozens to hundreds of case records. A single epidemiological investigation report can reach several megabytes in size.
What constraints these characteristics impose on document parsing and chunking
Daily updated batch data demands an efficient parsing workflow to avoid delaying daily ledger summary and report generation due to parsing delays. Use chunking rules aligned to business units for formatted business documents, such as splitting by individual reporting cards or single case records. This avoids cross-case chunk merging that causes subsequent summary errors. Large-volume epidemiological investigation reports and batch Excel files increase parsing time, requiring longer timeout settings and appropriate chunk lengths. Multi-source document formats require the parsing module to support accurate extraction across different formats. For example, use row-level separation for Excel, and structured field extraction for PDF. Without this, content misalignment or missing key fields may occur. Statutory reporting rigor requires chunking to retain key identifiers such as case numbers and reporting times, to ensure accurate subsequent recall and summary.
How to configure settings
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
chunkSize | 800–1200 characters | Matches the typical content length of a single infectious disease reporting card or single case record, ensuring each chunk contains a complete business unit |
chunkSplitter | Use custom separators | Adapts to different document formats: use the line separator \n for Excel scenarios to match single records, use "Case ID:" as the separation starting point for reporting card scenarios to avoid cross-row merging |
customPdfParse | Enable structured extraction | For PDF-format epidemiological investigation reports and epidemic situation analysis reports, extract preset fields such as case ID and reporting date, to avoid content chaos caused by unstructured parsing |
UPLOAD_FILE_MAX_SIZE | 20 MB | Adapts to daily uploaded large-volume documents of 10–15 MB, to avoid upload failures due to file size exceeding the limit |
PARSE_FILE_TIMEOUT_SECONDS | 600 seconds | Reserve sufficient time for large file parsing, to avoid parsing failure due to timeout interruption |
chunkSettingMode | Manual mode | For fixed-format Center for Disease Control and Prevention documents, manually configure chunking rules, which better aligns with field association requirements of business scenarios than automatic mode |
All configuration items above are supported in FastGPT v4.17.0 and later versions.
Three common configuration mistakes
- Large-volume Word document parsing times out, with the interface displaying the "parse failed: timeout" error. The cause is that the
PARSE_FILE_TIMEOUT_SECONDSsetting value is less than the actual parsing time, and the processing rhythm for large files is not adapted. - Multiple records are merged into a single chunk after Excel batch import. The phenomenon is that the knowledge base entry contains multiple case pieces of information, and retrieval cannot be performed by single record. The cause is that
chunkSplitteris not correctly configured to separate by rows, and the default general chunking rule is used. - A query that exactly matches the chunk content cannot recall the target entry. The phenomenon is that a specific knowledge base cannot match the corresponding entry, but a newly created knowledge base with the same configuration can recall normally. The cause is that key identifier fields such as case number and reporting date are not retained during chunking, resulting in the loss of matching features for the chunk.
How to confirm the configuration is correct
- Upload a single 10–15 MB Word-format infectious disease reporting card, check that the parsing status has no timeout errors, and the time consumption falls within the range of the preset
PARSE_FILE_TIMEOUT_SECONDS. - Upload an Excel-format batch of infectious disease reporting cards, check each knowledge base entry one by one, confirm that each entry only contains the case information of a single Excel row, with no cross-row merging.
- Upload multiple Center for Disease Control and Prevention documents in different formats, check that each document in the workflow or knowledge base is independently parsed into corresponding chunks, with no content confusion or omission.
- Enter a query that exactly matches the content of a chunk, verify that the corresponding entry can be recalled normally, and confirm that key matching fields are retained during chunking.
Note: The configuration values listed are common starting points, and should be evaluated against your own specific 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.