What data for this category looks like
Data for this category comes from multiple business systems of precast concrete (PC) component, pipe pile, bridge component, and municipal product factories. It includes component detailed drawings, steel bar cutting lists, mold inspection records, pouring and vibration logs, curing ledgers, demolding and factory inspection reports. Data sources include BIM or detailed design documents, steel bar and concrete batch ledgers, mold table and curing kiln operation records, laboratory test data, and QR code traceability systems. Updates are triggered per individual component, per batch of materials, or per curing batch in a kiln. Documents contain fields such as component number, steel bar specification, embedded position, strength indicators, and mostly use standard engineering units like millimeters, megapascals, and cubic meters.
What constraints do these characteristics impose on the document parsing and chunking process
The multiple document types and fine-grained update rhythm of this category impose multiple constraints on the document parsing and chunking process. First, documents come in various formats including vector detailed drawings, tabular cutting lists, and text-based operation records, so adaptation logic for different parsing engines is required. Second, each individual component corresponds to an independent document, so duplicate parsing of duplicate fields from the same batch of materials must be avoided during batch processing. Third, documents contain engineering-specific terminology, coordinate parameters, and strength indicators. When chunking, contextual associations must be preserved to avoid breaking the logical link between steel bar embedded positions and curing parameters. Finally, data sources are scattered, so standardized fields must be extracted uniformly to ensure chunked content meets the retrieval needs of process Q&A.
How to set the configuration
This document is written based on the configuration rules of FastGPT v4.17.0.
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
chunkSize | 800–1200 characters | Precast concrete component documents contain long-text process steps and parameters. This range preserves complete process logic and avoids chunking that breaks the link between curing procedures and strength requirements. |
chunkSplitter | Mixed chunking by paragraph + fixed length | For text annotations and tabular data in detailed drawings, splitting by paragraph preserves semantic integrity. For long-text cutting lists, using fixed-length chunking balances retrieval accuracy and coverage. |
customPdfParse | Enabled | Detailed drawings for precast concrete components are mostly annotated PDF formats. Enabling custom parsing can accurately extract key information such as component numbers and steel bar specifications from drawings, avoiding generic parsing missing engineering details. |
PARSE_FILE_TIMEOUT_SECONDS | 600 seconds | Large detailed drawing files for single bridge components have significant file size, requiring longer parsing time. 600 seconds covers the parsing cycle of most documents and avoids parsing failure due to timeout. |
UPLOAD_FILE_MAX_SIZE | 1000 MB | Archived files containing multiple sets of mold inspection records can reach hundreds of megabytes in size. This upper limit meets the upload needs of batch archived documents. |
chunkSettingMode | Manual configuration | The field structures of different types of precast component documents, such as pipe piles and bridge components, vary greatly. Manual configuration allows adjusting chunking rules for specific documents to adapt to retrieval needs in specific use cases. |
Three common errors
- Symptom: After uploading an Excel file for a steel bar cutting list, the data processing step returns empty fields. Cause: Custom parsing configuration for tabular documents was not enabled. Generic parsing cannot recognize specialized fields such as steel bar specifications and component numbers in engineering tables.
- Symptom: When uploading multiple curing record PDFs in batch, vectorization takes an excessively long time. Cause: The
chunkSizeparameter was not adjusted, and using an excessively small chunk length led to a sharp increase in the number of chunks. Additionally, optimized chunking rules for long text were not enabled. - Symptom: After local deployment, initiating a process Q&A triggers a full document parsing process. Cause:
chunkSettingModewas not configured correctly. The global parsing mode is enabled by default, which includes user questions in the parsing scope. The configuration only for uploaded knowledge base documents does not take effect.
How to confirm the configuration is properly set
- Upload a typical component detailed drawing PDF, check the chunked content after parsing, and confirm that key fields such as component number and embedded position have been fully extracted.
- Upload a single archived document with a volume of approximately 500 MB, verify that the upload and parsing processes do not trigger timeout errors, and confirm that the parsing timeout configuration adapts to the current document size.
- Initiate a retrieval request targeting a steel bar cutting list, check if the returned chunked results contain complete process parameters, and confirm that the chunking rules match the document type.
- Test batch uploading multiple documents of the same type, confirm that no empty fields appear in the data processing step, and verify the effectiveness of the custom parsing configuration.
The values provided here are common starting points and should be evaluated against the reader's own samples.