What the data for this category looks like
Water utility intelligent due diligence report data comes from internal operation ledgers of water enterprises, real-time pipe network monitoring data, third-party water quality test reports, and government water project approval documents. It is primarily used by financial institutions for credit due diligence on water enterprises.
Update rhythms cover multiple dimensions:
- Daily pipe network operation logs are updated hourly or daily
- Water quality test reports are updated monthly or quarterly
- Project approval documents are updated irregularly alongside approval progress
Document formats include structured Excel ledgers, long-text PDF reports, and batch small-volume monitoring data files. Fields and associated units include water supply pressure (unit MPa), pipe network length (unit km), water quality pollutant concentration (unit mg/L), number of water supply households, monthly revenue, and others. Some documents contain raw data that uses multiple mixed units.
What constraints these characteristics impose on knowledge base retrieval and recall
These characteristics create clear constraints for the knowledge base retrieval and recall workflow. Data from multiple sources with varied update frequencies requires the retrieval system to support flexible switching between incremental and full updates. This avoids occupying limited computing resources from full retransmission. Documents with mixed structures need support for both semantic vector recall and structured field retrieval. A single recall method cannot cover the precise query needs of ledger data, which reduces the accuracy of due diligence reports. Raw data with multiple mixed units causes deviations in semantic retrieval similarity calculations. Preemptive unit normalization is required to avoid mismatching due diligence data. Batch import of small-volume monitoring files requires the system to support batch parsing and unified metadata tagging. This prevents fragmented issues from single-file parsing. Segmentation of long-text operation logs must retain contextual connections. Splitting without retaining context risks losing information about key monitoring nodes, which undermines the rigor of due diligence conclusions.
How to set the configurations
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
PARSE_CHUNK_SIZE | 800–1200 characters | Water utility documents include long operation logs and split structured text. This range retains contextual connections of monitoring data and avoids split breaks |
RECALL_TOP_K | Top 10 entries | Water utility due diligence data has many scattered fields. Too many recalled entries increases context processing load, while too few will miss key pipe network parameters |
SIMILARITY_THRESHOLD | 0.72–0.80 | Semantic similarity differentiation for water utility monitoring data is high. This range filters irrelevant historical operation records and retains accurate water quality and pressure data |
UPLOAD_INCREMENTAL_ENABLE | Enabled | Water utility operation data is updated daily. Incremental updates avoid resource consumption from full retransmission and ensure the timeliness of retrieved data |
STRUCTURED_PARSE_SWITCH | Enabled | Water utility documents contain a large number of structured ledgers. Enabling this extracts field metadata to support precise field-based retrieval, rather than relying solely on semantic recall |
PARSE_FILE_TIMEOUT_SECONDS | 600 seconds | A single water utility due diligence report may contain multiple pages of monitoring data. A longer timeout avoids parsing failures for large files |
The parameter values provided on this page are common starting points for configuration setup. Actual values are influenced by material format, data volume, and business rules. Specific issues require targeted analysis. It is recommended to test on your own samples before finalizing settings.
Three common configuration errors
- Phenomenon: Semantic retrieval scores are abnormally high when using the
bge-m3vector model. Cause: No unit normalization was performed for water utility data (such as MPa and kPa), leading to high similarity judgments for the same parameter with different unit expressions. - Phenomenon: Some fields are not correctly identified after batch import of water utility monitoring Excel files. Cause:
STRUCTURED_PARSE_SWITCHwas not enabled, so field metadata from structured tables was not automatically extracted, leaving some columns unparsed. - Phenomenon: A large number of irrelevant historical operation logs are returned when retrieving water utility due diligence reports. Cause:
SIMILARITY_THRESHOLDwas set below 0.70, failing to filter low-relevance non-target data.
How to verify successful configuration
- Upload a single water utility due diligence PDF, review the parsed segmentation results, and confirm that segmentation does not break the contextual connections of key monitoring data.
- Initiate a retrieval for a specific water quality indicator, and check that returned result field units are unified and comply with preset normalization rules.
- Upload same-day operation data for incremental update, review the knowledge base update log, and confirm that only new data is synchronized to the retrieval library.
- Adjust the value of
SIMILARITY_THRESHOLD, compare retrieval result relevance across different values, and determine the threshold range that meets business requirements.
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.