Typical Data for This Category
Typical data for this category comes from daily work outputs of on-call operations staff and SRE teams. Data sources include monitoring alert systems, log aggregation platforms, APM tools, and user feedback channels. Data updates occur in real time or are generated after each incident. Core documents include incident tickets, event timelines, emergency response plans, and fault notifications. Each document typically contains fields such as incident number, occurrence time, impact scope, disposal steps, and preliminary root cause judgment. No unified fixed format exists across documents. Some documents include tables, images, or structured lists.
Constraints for Document Parsing and Chunking
Decentralized data sources and inconsistent document formats require the parsing process to support multiple non-standard structures, and avoid missing key fields. Real-time or incident-triggered update rhythms demand low latency in the parsing workflow, and cannot support overly time-consuming preprocessing steps. Incident tickets and notification documents often contain tables and timestamp-structured content. Chunking must retain field relevance, and avoid splitting cross-related content into different chunks. The timeliness of fault disposal also requires chunked content to be quickly retrievable. Avoid oversized chunks that reduce retrieval accuracy, or undersized chunks that cause context breaks.
Configuration Settings
The following configurations are based on the functional logic of FastGPT v4.17.0:
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
chunkSize | 800–1200 characters | Adapts to the field relevance of incident tickets and notification documents, and avoids splitting key disposal steps and timestamp-related content |
chunkSplitter | Split by paragraph + title | Retains the hierarchical structure within documents, and matches the logical segments of emergency response plans and event timelines |
customPdfParse | Enabled | Compatible with PDF-format fault notifications and emergency response plan documents, and retains structured information of tables and images |
UPLOAD_FILE_MAX_SIZE | 1000 MB | Adapts to the batch upload requirement of multiple documents aggregated for a single incident, and avoids upload failures caused by oversized files |
PARSE_FILE_TIMEOUT_SECONDS | 600 seconds | Matches the low-latency requirement for real-time updated document parsing, and avoids interrupting incident disposal processes due to timeout |
chunkSettingMode | Manual mode | Allows adjustment of chunking parameters for different types of incident documents, and adapts to diverse fault scenarios |
Three Common Configuration Mistakes
- Uploaded incident ticket tables cannot be chunked correctly, and table content is scattered into fragmented text after parsing. The cause is that the
customPdfParseconfiguration is not enabled, or the chunking rules do not adapt to table structured content. - Out-of-vRAM error occurs after deploying the PDF parsing component, and the current GPU device cannot be recognized. The cause is that the container GPU mapping parameters are not configured correctly, or the component version is incompatible with the current CUDA version.
- After importing Word-format fault notifications, the domain name information of embedded images is lost, and images cannot be loaded normally in conversations. The cause is that the complete path information of images is not retained during the Word to Markdown conversion process, and the parsing rule for automatically completing domain names is not configured.
How to Verify Correct Configuration
- Upload a typical incident ticket document, and check if the parsed chunked content retains key structured information such as tables and timestamps.
- Trigger a batch upload of multiple incident documents, and confirm that the parsing process does not experience timeout interruptions, and all documents have completed chunking processing.
- Adjust the
chunkSizeparameter, retrieve chunked content, and confirm that the retrieval results cover the complete context of fault disposal steps. - View container logs, confirm that the GPU device is correctly recognized, and there are no out-of-vRAM error messages.
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.