What data for this category looks like
Daily documents for this category include gameplay design documents, numerical tables, version requirement sheets, and balance test records. Data sources include player behavior data, public competitor materials, battle logs, and version feedback. Updates occur weekly or per game version. Most documents follow structured formats, including numerical tables and text with rule entries and version numbers. Numerical tables contain fields such as character ID and attribute values. Units include attack power values, percentages, battle duration, and more. Gameplay design documents split gameplay rules and numerical logic by module.
Constraints imposed on document parsing and chunking
Structured numerical tables have strong correlations between fields and their corresponding values. During chunking, preserve the binding relationship between fields and their values. Splitting these apart makes numerical logic irrecoverable. Rule entries in gameplay design documents are split by module. Fixed character count chunking interrupts complete rule descriptions. High-frequency update requirements (weekly or per version) require chunking to support fast processing of small documents. Parse unstructured battle logs and player behavior data with additional adaptation to their original formats. This prevents loss of field information.
How to configure settings
The following configurations apply to FastGPT v4.17.0.
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
chunkSize | 800–1200 characters | Matches module lengths of gameplay design documents and field group lengths of numerical tables. Prevents splitting rules or numerical correlations |
chunkSplitter | Split by document structure | Adapts to structured numerical tables and module divisions in gameplay design documents. Retains content correlation better than fixed character chunking |
customPdfParse | Enabled | Game design documents often contain tables and embedded numerical charts. Enabling this preserves original layout and field structure |
PARSE_FILE_TIMEOUT_SECONDS | 600 seconds | Matches parsing duration of single version requirement sheets or balance test records. Prevents timeout failures for large documents |
UPLOAD_FILE_MAX_SIZE | 1000 MB | Adapts to the upper limit of document collections for single batch version updates. Supports bulk upload requirements |
trainingType | General text training | Covers both rule text and structured numerical content in game design documents. Ensures parsing completeness |
Three common mistakes
- Using chunk mode with the
pushdata apiduring upload results in persistent indexing status. The root cause is failure to adjust thechunkSizeparameter for small documents updated weekly. Undersized chunk sizes cause indexing queue backlogs. - Uploading PDF-format gameplay design documents or numerical tables results in ignored images. The root cause is failure to enable the
customPdfParseconfiguration. Default parsing only extracts plain text, and does not retain embedded charts or numerical screenshots. - Uploading JavaDoc-generated HTML-format version requirement descriptions yields no parsing results. The root cause is failure to configure parsing rules for the corresponding document type. Uploading raw HTML files does not extract valid structured content.
How to verify correct configuration
- Upload a typical numerical table document. Confirm parsed results retain the correspondence between fields and values. Verify chunking does not split correlated content.
- Upload a PDF document containing embedded images. Confirm parsed results include image-related information. Verify the
customPdfParseconfiguration is active. - Use the
pushdata apito upload a small version requirement sheet. Confirm indexing completes within a reasonable duration. Verify thePARSE_FILE_TIMEOUT_SECONDSconfiguration is appropriate. - Upload bulk HTML-format interface documents. Confirm parsed results extract valid text content. Verify document type parsing rules are configured correctly.
The values listed above are common starting points. They 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.