This document is written for FastGPT v4.17.0.
What data looks like for this category
Core data for this category comes from machine shops, precision parts factories, and machining workshops of equipment enterprises. It covers documents including process routes, operation cards, tool lists, CNC programs, first-piece inspection records, patrol inspection forms, and measuring tool calibration records. Data sources include product drawings and 3D models, CAPP/CAM systems, machine tool collection data, tool management systems, MES, and measuring and inspection tool data. Update frequency is triggered by work orders, single-piece production, spot checks, or tool changes. Documents include fields such as cutting parameters, clamping benchmarks, process dimensions, and tool models, with units mostly including millimeters, meters per minute, and revolutions per minute.
Constraints imposed by these characteristics on document parsing and chunking
The multi-type documents, high-frequency updates, and structured parameter characteristics of this category impose multiple constraints on document parsing and chunking. First, documents cover compact structured process parameters and lengthy unstructured instructions. It is necessary to avoid splitting key parameter-related groups, as this will affect the logical matching of subsequent cross-review. Second, G-code lines in CNC programs have strong execution dependencies. Continuous code segments must be retained during chunking to prevent damage to program execution logic. In addition, non-standardized document formats from multiple sources require custom parsing rules to adapt to different import formats, while also adapting to the parsing efficiency requirements of high-frequency updated work order documents.
Configuration settings
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
chunkSize | 800–1200 characters | This category’s documents contain compact process parameters and lengthy process descriptions. This range preserves the integrity of parameter groups and descriptions, and avoids splitting key process content |
chunkSplitter | Split by paragraphs and code blocks | This category’s documents include both process paragraphs and G-code CNC programs. Splitting this way preserves the independence and relevance of both types of content |
customPdfParse | Enabled | Some documents in this category come from CAD-exported PDF drawings and CAPP reports. Enabling custom parsing supports structured field extraction |
PARSE_FILE_TIMEOUT_SECONDS | 300–600 seconds | Parsing large CNC programs and multi-page process documents takes a long time. This range avoids timeout interruptions |
chunkSettingMode | Custom mode | Documents in this category have significant format differences. Custom mode allows flexible adjustment of chunking rules to adapt to different document types |
Three common configuration mistakes
- Phenomenon: When a Word document is imported, images automatically carry a domain name, but after conversion to Markdown format for import, the complete domain name is missing from image links. Cause: The image link standardization configuration of
customPdfParseis not enabled, and the complete context of image links is not retained during chunking. - Phenomenon: When parsing multi-page process reports, some operation card chunked content loses clamping benchmark fields. Cause:
chunkSplitteris configured to split by fixed characters, rather than by paragraphs or structured tags, resulting in key fields being split into different chunks. - Phenomenon: An empty result is returned when calling the API to obtain chunked index content. Cause: The
chunkSizeconfiguration does not match the counting logic of the chunk index, or associated process parameters are mistakenly split into independent chunks during chunking.
How to verify a correct configuration
- A typical operation card document is uploaded. The parsed chunked content is reviewed to confirm that key fields such as cutting parameters and clamping benchmarks are not split into different chunks.
- A CNC program document containing G-code is uploaded. Chunked content is checked to confirm that continuous code segments are retained, and that program lines are not split arbitrarily.
- The
chunkSizeorchunkSplitterconfiguration is adjusted. The test document is re-uploaded, and the completeness of the chunked results is compared to confirm that the configuration takes effect. - The corresponding API interface is called. The chunked content of the specified index is verified to be obtainable, confirming that the chunk index aligns with the configuration logic.
The values provided are common starting points and should be measured against samples from the specific deployment context.