What data for this category looks like
Data for insurance intelligent due diligence reports mainly comes from underwriting archives, claim dossiers, regulatory filing documents, and third-party credit reports. Update cycles align with underwriting cases, claim process progress, or regulatory document updates. Documents have a fixed structure, including sections such as insured identity information, insured object details, health notification records, underwriting conclusions, and past claim details. Fields include sum insured (unit: ten thousand yuan), payment period (unit: years), health abnormal items, underwriting scores, and more. Some documents include handwritten annotations and stamp areas from paper scans.
What constraints do these characteristics impose on the document parsing and chunking link
The multi-source, multi-format nature of insurance due diligence reports requires the parsing link to support PDF scans, Word documents, and encrypted format files. It also must support text extraction from handwritten annotations and stamp areas. The fixed chapter structure with scattered fields requires chunking to retain chapter boundaries, and avoid splitting core business fields such as underwriting conclusions and claim details. The high proportion of long documents requires controlling single chunk length to adapt to subsequent retrieval logic, while retaining the binding relationship between fields and units to prevent business information misalignment. Some documents have encryption or watermark occlusion, so support is needed for parsing weakly encrypted files and restoring text from watermark areas.
Configuration settings
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
PARSE_FILE_MAX_SIZE | 500 MB | Individual insurance due diligence report documents usually do not exceed this threshold, to avoid excessive consumption of parsing resources |
maxChunkSize | 800–1200 characters | The length of core business fields in insurance reports is concentrated. This range can retain chapter integrity and adapt to context windows |
ENABLE_OCR_PARSE | Enabled | Over 60% of offline due diligence reports are in scan format. OCR must be enabled to extract printed and handwritten text |
PARSE_FILE_TIMEOUT_SECONDS | 600 seconds | Long document parsing requires sufficient time to complete OCR recognition and chunking logic processing |
CHUNK_OVERLAP_RATE | 10–15% | Insurance reports have many cross-chapter associated fields. Overlapping chunks can improve the accuracy of subsequent retrieval |
The parameter values provided on this page are common starting points for configuration. Actual values are affected by material form, data volume and business rules. Specific issues require specific analysis. It is recommended to test on your own samples before finalizing settings.
Three common errors
- Phenomenon: After deploying the parsing service container, a GPU memory overflow error is prompted or the GPU cannot be recognized. The log shows CUDA initialization failed. Cause: The host GPU driver and CUDA runtime environment are not properly mounted, or the CUDA version inside the container does not match the version of the third-party parsing component.
- Phenomenon: After parsing Word-format due diligence reports, the image links in the generated Markdown do not include the domain name prefix. Cause: The automatic domain name addition rule is only configured during the file upload stage, and the domain name information of images is not bound synchronously during the document parsing stage.
- Phenomenon: Parsing encrypted insurance due diligence reports returns empty results or a
400 Bad Requesterror. Cause: The encrypted file parsing configuration item is not enabled, or the correct document decryption password is not provided during upload.
How to confirm the configuration is correct
- Upload a typical insurance due diligence report scan. Check whether the parsing result includes all core chapters and fields, and confirm that the handwritten annotations and stamped text recognized by OCR are complete.
- View the parsing logs to confirm that the parsing timeout configuration takes effect, and no timeout interruption records appear.
- Test documents of different lengths, and check whether the chunking results retain chapter boundaries and the single chunk length matches the expected configuration.
- Upload an encrypted document, enter the correct decryption password, and confirm that the parsing result is generated normally, with no empty content or errors.
Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-09-14.