What the Data for This Category Looks Like
Data for this category primarily originates from search ad backends, search term reports, bidding ranking data, and landing page data. Updates follow a daily or weekly cadence. Commonly used documents are structured tables, with four core formats: keyword lists, negative keyword lists, bid records, and search term reports. Fields include keyword text, matching mode, bid value, search volume, conversion data, and units that vary based on field type.
Constraints for Document Parsing and Chunking Workflows
The structured table nature of search ad documents requires that chunking preserves field relationships and prevents splitting multi-column content from a single record. The daily or weekly update frequency creates a need for batch parsing. Single files may contain tens of thousands of entries, so support for parsing and chunking large files is required. Header formats of documents exported from different ad platforms have minor differences, so custom parsing rules must be supported to adapt to various export formats.
Configuration Settings
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
chunkSize | 800–1200 characters | A single structured record for search ads occupies approximately 100 characters. This range can hold 8 to 12 complete records, avoiding data breaks within chunks |
chunkSplitter | Table row splitting mode | Adapts to the structured table format of search ad documents, preserving field relationships for each record |
PARSE_FILE_TIMEOUT_SECONDS | 300–600 seconds | Large quarterly search term reports take longer to parse. This range covers parsing needs for most scenarios |
UPLOAD_FILE_MAX_SIZE | 1000 MB | Adapts to the maximum size of quarterly search term reports, preventing large file uploads from being blocked |
chunkSettingMode | Custom mode | Adapts to minor format differences in documents exported from different ad platforms, enabling precise configuration of chunking rules |
Common Misconfigurations
- No response from the parsing node after file upload. This occurs when
UPLOAD_FILE_MAX_SIZEis not adjusted to match the size threshold of ad reports, resulting in file uploads being blocked by the system. - Only partial table data is captured. This happens when
chunkSplitteris not configured to use table row splitting mode. Splitting by regular text line breaks breaks the field relationships of structured data, or whenchunkSizeis set too small, truncating a single complete record. - Parsing tasks fail mid-process. This occurs when
PARSE_FILE_TIMEOUT_SECONDSis set lower than the actual parsing time required for large search term reports, causing the task to terminate due to timeout.
How to Verify Correct Configuration
- A single 100 MB quarterly search term report can be uploaded. After parsing completes, confirm that the number of generated chunks matches the number of rows in the original table.
- Parsing logs can be reviewed to confirm no timeout errors or file size limit warnings appear.
- Chunked content can be randomly sampled to verify that fields such as keyword, matching mode, and bid for each record are not split across chunks.
- This configuration applies to FastGPT v4.17.0. The currently running version can be confirmed via the version query interface.
Note: The values provided are common starting points and should be evaluated against specific local 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.