What this category of data looks like
Data for this category originates primarily from engine Profiler, crash platforms, real-device testing tools, and frame rate collection systems. Update frequency follows a daily or per-version iteration schedule. Daily generated documents include performance test reports, device adaptation lists, optimization records, and crash analysis reports. Document fields include device model, frame rate value, resource usage, crash log ID, package size, and additional metrics. Some documents contain embedded test screenshots and device adaptation tags. Most data structures are structured or semi-structured.
What constraints do these characteristics impose on the document parsing and chunking workflow
Documents in this category are mostly structured test reports and semi-structured optimization records. They include embedded test screenshots and device parameters, and have a high update frequency. The document parsing workflow must support extraction and association of embedded images. This prevents loss of visual evidence for performance tests. Chunking must adapt to small-volume documents updated at high frequency. This avoids context fragmentation caused by overly long chunks. It must also retain context association for professional fields such as frame rate and resource usage. This ensures the large language model can accurately link performance data and optimization measures. It must adapt to the differentiated structure of different device adaptation lists.
How to Configure Settings
The following configurations are based on the document parsing module of FastGPT v4.17.0.
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
chunkSize | 800–1200 characters | Adapts to professional fields and paragraph lengths of game performance documents, avoids context fragmentation of performance data during chunking |
chunkSplitter | By paragraph + semantic boundary | Adapts to structured paragraphs of performance test reports, retains association between test steps and results |
PARSE_FILE_TIMEOUT_SECONDS | 300–600 seconds | Adapts to large-volume performance log files exported from real-device tests, avoids parsing timeouts |
UPLOAD_FILE_MAX_SIZE | 1000 MB | Adapts to performance optimization record packages exported in batches per version, meets batch parsing requirements |
customPdfParse | Enabled | Supports parsing PDF format performance reports exported from engine Profiler, retains original typesetting and embedded charts |
chunkSettingMode | Manual configuration | Adapts to differentiated document structures of different device adaptation lists, allows flexible adjustment of chunking rules |
Three Common Misconfigurations
- Embedded test screenshots in performance test reports cannot be read by the large language model. This occurs when the
customPdfParseconfiguration is not enabled. The parsing workflow then fails to extract associated information for embedded images. - Parsing fails when using Yuque public links or Feishu multi-dimensional documents as data sources. This happens if the link is not a publicly accessible shared link. It also happens if parsing adaptation rules for the corresponding data source are not enabled.
- HTTP tool calls show normal parameter parsing but do not execute the corresponding operation. This occurs when reasonable timeout parameters are not configured. The parsing workflow times out and interrupts, so subsequent tool calls are not triggered.
How to Verify Correct Configuration
- Upload a performance test PDF exported from engine Profiler. Check if the parsed result includes embedded frame rate charts and device adaptation tags.
- Enter a publicly shared Yuque performance document link. Confirm that the parsing status shows completed, with no error prompts.
- Set
PARSE_FILE_TIMEOUT_SECONDSto 600 seconds. Upload a single 100MB crash analysis log. Check if parsing completes before the timeout. - Import Excel files and multi-dimensional documents from a Feishu folder. Check if the parsed result includes table content and document text.
The provided configuration values are common starting points. They should be evaluated against the applicable sample data.
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.