What this category of data includes
Data serving container platform operations and maintenance typically comes from Kubernetes API, image registries, monitoring systems, and CI pipelines. Common documents generated daily include cluster change tickets, namespace quota tables, deployment records, and failure reports. Quota tables contain fields such as namespace, CPU/memory quotas, with units in cores and Gi. Change tickets note change time and impact scope. Failure reports include Pod names and error log snippets. Data update frequency is daily or after each cluster change. Most content consists of structured tables and step-by-step technical text.
Constraints on document parsing and chunking
The structured nature of operations and maintenance documents requires chunking to retain contextual links between key technical fields, and avoid splitting cross-column quota table information. Frequently updated cluster change tickets and real-time generated failure reports require parsing processes to support short-cycle batch processing, and prevent timeout interruptions. Data includes specialized technical terms and complex formulas. Key information must be extracted accurately, while non-standard formats such as log snippets must be supported. Additionally, format differences across multiple data sources require parsing configurations to be flexibly adjusted to match the structure of different document types.
How to set configurations
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
chunkSize | 800–1200 characters | Matches the average length of single sections in operations and maintenance documents, avoids splitting column information in structured tables or cross-paragraph operation steps |
chunkSplitter | Split by title + paragraph | Aligns with the hierarchical structure of operations and maintenance documents, retains contextual links for key terms such as namespace and Pod, and avoids splitting content from the same change ticket across titles |
customPdfParse | Enable Marker engine | Supports accurate parsing of complex formulas and nested tables, and adapts to monitoring data charts in failure reports and multi-column structures of quota tables |
PARSE_FILE_TIMEOUT_SECONDS | 300–600 seconds | Adapts to batch parsing of batch change documents generated by CI pipelines, and avoids task interruptions caused by overly long parsing time for a single file |
chunkSettingMode | Manual configuration | Adjusts chunking rules for the structured characteristics of operations and maintenance documents, and can enable table recognition mode separately for quota tables |
Three common misconfigurations
- Symptom: Chunk preview returns "unable to read this file content" when a PDF is uploaded to the knowledge base. Cause: The
customPdfParseconfiguration is not enabled. The default parsing engine cannot handle nested tables or binary log attachments in operations and maintenance documents. - Symptom: Complex formulas cannot be returned normally in the local deployment version. Cause: The Marker image version is incompatible with FastGPT v4.17.0, or GPU resources for formula parsing are not properly mounted.
- Symptom: Error occurs when starting the Marker container with docker. Cause: The
--gpus allparameter to enable GPU acceleration is not added, or port mapping conflicts with the internal parsing port of FastGPT.
How to verify correct configuration
- A namespace quota table PDF may be uploaded, and chunk previews may be checked for full retention of structured fields including "namespace", "CPU quota", and "memory quota".
- A failure report PDF containing mathematical formulas may be uploaded, and parsed formulas may be confirmed to display normally with no garbled characters or missing content.
- Parsing task logs may be checked, and confirmation may be made that no timeout errors related to
PARSE_FILE_TIMEOUT_SECONDSare triggered, and tasks complete normally. - Batch upload of 3 or more cluster change tickets may be tested, and confirmation may be made that chunks are not split across documents, and content from each change ticket is integrated into independent chunks.
The values provided are common starting points, and should be evaluated 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.