What the data for this category looks like
Data sources for diversified holdings intelligent due diligence reports include public regulatory disclosure documents, the group’s internally archived due diligence working papers, and special reports issued by third-party institutions. Update rhythms fall into three categories:
- Regularly disclosed data is updated quarterly and annually
- Temporary announcement data is updated when events such as connected transactions or equity changes occur
- Project-specific due diligence data is updated dynamically alongside due diligence progress
Document structures include modules such as equity hierarchy trees, revenue breakdown tables, related party directories, and risk warning texts. Fields include consolidated statement revenue, number of subsidiaries, number of equity tiers, related transaction amounts, and more. A single document covers multi-dimensional business content.
What constraints these characteristics impose on the vector models and indexing link
The data contains mixed structured tables and unstructured text content. This requires vector models to support cross-format content encoding, and indexes to support associative retrieval of both dense vectors and structured metadata. Update rhythms include two modes: regular batch updates and real-time event-triggered updates. This requires indexes to support dual configuration logic for incremental synchronization and scheduled full reconstruction. Fields with strong business correlation such as equity tiers and related transaction amounts require indexes to support precise filtering based on metadata fields. The wide coverage of business dimensions in a single document requires chunking strategies to balance content integrity and semantic consistency of vector encoding.
How to set the configurations
| Configuration Item | Recommended Value Range | Rationale |
|---|---|---|
chunk_size | 800–1200 characters | Adapts to the mixed structure of structured tables and long text paragraphs in diversified holdings due diligence reports, avoiding overly fragmented or overly long single segments that affect vector encoding consistency |
chunk_overlap | 50–80 characters | Retains contextual connections across segments, adapting to cross-paragraph business logic such as equity hierarchies and related transactions |
embedding_batch_size | 20–30 items per batch | Balances single-batch processing time and system resource usage, adapting to embedding tasks for batch due diligence documents |
index_update_strategy | Incremental update + daily full validation | Matches the mixed update rhythm of regularly disclosed data and temporary announcements, ensuring consistency between index data and source data |
retrieve_threshold | 0.72–0.85 | Filters low-correlation recall results, adapting to retrieval scenarios with many professional terms and strong business correlation in due diligence reports |
metadata_filter_enable | Enabled | Supports filtering recall results based on metadata fields such as "report type" and "update time", meeting the multi-dimensional retrieval needs of diversified holdings due diligence |
The parameter values provided on this page are all common recommended starting points for configuration. Actual values are affected by material form, data volume and business rules. Specific issues require case-by-case analysis, and it is recommended to test on your own samples before finalizing settings.
Three common errors
- Phenomenon: After replacing the embedding model, the recall results of historical due diligence documents deviate significantly, and retrieval efficiency fails to meet expectations. Cause: No batch re-embedding operation was performed, and historical documents still use vectors generated by the old model.
- Phenomenon: Manually uploaded due diligence report documents cannot be retrieved after several hours. Cause: The index update strategy is configured to only cache temporarily generated real-time indexes, and persistent storage is not enabled.
- Phenomenon: When retrieving related party information, results cannot be filtered by subsidiary hierarchy, and irrelevant entities are included in recall results. Cause: The metadata filtering function is not enabled, and filtering by the "subsidiary hierarchy" field is not configured.
How to confirm the configuration is correct
- Upload a test due diligence report fragment, check the embedding task logs, and confirm that the configured
embedding_batch_sizevalue matches the actual batch processing count. - Trigger a full index rebuild, check the index refresh logs, and confirm that the configured
index_update_strategyis correctly applied. - Initiate a retrieval test with metadata filtering, verify whether the
metadata_filter_enableconfiguration takes effect, and confirm that retrieval results are filtered by the specified fields. - Adjust the
retrieve_thresholdconfiguration value, retrieve the same keywords, observe changes in the number of recall results, and confirm that the threshold configuration takes effect.
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.