What the data for this category looks like
Data for this category is produced by SREs, technical leads, and quality teams. Daily documents include RCA reports, incident tickets, post-incident review minutes, and remediation tracking sheets. Data sources include incident timelines, system logs, monitoring metrics, and code commit records. Update frequency follows either post-major-incident or monthly cycles. Document structures typically include incident timestamps, root cause analysis entries, linked evidence URLs, and remediation tracking items. Some documents include embedded incident screenshots, log snippets, and monitoring charts.
What constraints do these characteristics impose on document parsing and chunking
The document characteristics of this category create multiple constraints for parsing and chunking. First, documents contain unstructured log snippets, embedded incident screenshots, and monitoring charts. Support for multimodal content parsing is required to preserve evidence integrity. Individual post-incident review documents are typically large in size. Chunking parameters must be adjusted appropriately to avoid breaking the contextual logic of root cause analysis. Documents include embedded incident timestamps, linked evidence URLs, and remediation tracking fields. Chunking must retain field relevance and link targeting, and avoid splitting content that spans business logic. Data update frequency is low, but individual documents link to multiple sources. Parsing efficiency must be optimized for low-frequency, high-complexity document processing scenarios.
How to configure settings
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
chunkSize | 800–1200 characters | This category of documents includes long log snippets and root cause analysis paragraphs. This range balances contextual integrity and chunk count, and is compatible with the chunking logic of FastGPT v4.17.0 |
chunkSplitter | Split by paragraph + heading | Documents have clear heading hierarchies for incident descriptions, root cause analysis, remediation items, and similar sections. Splitting by headings preserves business logic integrity |
PARSE_FILE_TIMEOUT_SECONDS | 300–600 seconds | Individual post-incident review documents may contain large volumes of embedded logs and screenshots. Sufficient time is required to complete full parsing |
customPdfParse | Enabled | Most documents in this category are PDF-format RCA reports. Custom parsing supports extraction of embedded charts and links |
UPLOAD_FILE_MAX_SIZE | 1000 MB | Some incident post-incident review documents include multiple log attachments. Larger file upload support is required |
Three common misconfigurations
- Symptom: A "data source not supported" prompt appears when parsing a publicly shared Yuque link. Cause: The link was not confirmed as a fully public share page with no permission restrictions. FastGPT only supports parsing web data sources that comply with public access rules.
- Symptom: Embedded incident screenshots are missing from parsing results after uploading an RCA report PDF. Cause: The multimodal parsing mode of the
customPdfParseconfiguration item was not enabled. Default parsing only extracts plain text content. - Symptom: A timeout error triggers during parsing of a large post-incident review document. Cause: The value set for
PARSE_FILE_TIMEOUT_SECONDSis lower than the actual time required for document parsing, or the document size exceeds theUPLOAD_FILE_MAX_SIZElimit.
How to confirm correct configuration
- Upload a typical RCA report PDF, and verify that all embedded text and image content appears in the parsing results.
- Review chunked document fragments to confirm that each chunk contains a complete business logic unit, such as a single root cause analysis entry or remediation tracking item.
- Test parsing a publicly shared Yuque link to confirm normal extraction of page text and embedded links.
- Upload a test document of a preset size to confirm that no timeout error occurs during parsing.
The values provided are common starting points and should be evaluated against the user'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.