What this category's data looks like
Data for this category mainly comes from CDN consoles, DNS resolution records, user access logs, and edge node monitoring alerts. Daily produced documents include domain name access forms, cache rule configuration tables, refresh and preheating operation records, and fault analysis reports. Document fields typically include node IP addresses, cache effective duration, request hit rates, and abnormal error codes. Update frequencies are usually daily or immediate when configuration changes are made.
What constraints these characteristics impose on document parsing and chunking
Daily documents include both structured configuration tables and unstructured fault reports. The mixed format requires the parsing process to adapt to both tabular text and paragraph text. Data is updated immediately when configurations change, so chunking must retain timestamps and node identifiers linked to configurations to avoid context breaks. Long-text fault troubleshooting steps must be chunked by operation step, with each chunk containing a complete single-step operation or associated configuration. Documents contain CDN-specific terms such as TTL, origin address, and edge nodes. Chunking must preserve term integrity to prevent splitting that disrupts configuration logic.
How to set configurations
This configuration is based on FastGPT v4.17.0.
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
chunkSize | 800–1200 characters | CDN documents mostly include long configuration entries and fault steps. This range balances semantic integrity and retrieval accuracy |
chunkSplitter | Split by paragraph + heading | CDN documents are organized by configuration items or fault links. Splitting by heading preserves configuration logical association |
customPdfParse | Enabled | Most CDN-related documents are formatted configuration export PDFs or scanned documents. Enabling this optimizes table and text extraction effects |
PARSE_FILE_TIMEOUT_SECONDS | 300 seconds | Large refresh and preheating record PDFs or log export files take longer to parse. This duration covers most scenarios |
UPLOAD_FILE_MAX_SIZE | 1000 MB | CDN access log export files have large sizes. This upper limit meets conventional bulk document upload requirements |
Three common mistakes
- The symptom is that after uploading a PDF to the knowledge base, the file content cannot be read. The cause is that the
customPdfParseconfiguration is not enabled, or theUPLOAD_FILE_MAX_SIZEsetting is lower than the actual size of the uploaded file. - The symptom is that PPT/PDF documents synced from Feishu do not generate chunk previews. The cause is that the
chunkSplitterconfiguration does not adapt to the slide chunking logic of PPTs, or thePARSE_FILE_TIMEOUT_SECONDSis not adjusted to adapt to large-volume documents. - The symptom is that OCR error appears in Marker parsing logs. The cause is that the OCR parsing mode is not enabled for scanned fault report PDFs, or the
chunkSizeis set too small, causing OCR segmentation abnormalities.
How to confirm the configuration is applied correctly
- Upload a single CDN cache rule PDF, and check if the parsed chunk preview retains the correspondence between table columns and configuration items.
- View system logs to confirm that parsing time does not exceed the
PARSE_FILE_TIMEOUT_SECONDSsetting value, and there are no OCR error records. - Upload an access log file with a size close to
UPLOAD_FILE_MAX_SIZEto verify that the upload and parsing processes are not interrupted. - Adjust
chunkSizeto the boundary values of the range, and check if the chunking results still retain the integrity of CDN-specific terms.
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.