What the data for this category looks like
The data for water utility intelligent due diligence reports primarily comes from three sources: public operational archives of water supply and drainage operation enterprises, public utility statistical announcements from housing and urban-rural development authorities, and real-time collected data from pipe network IoT monitoring systems. Update cycles fall into three categories: hourly (for pipe network pressure and water quality), monthly (for operational costs and service volume), and annual (for enterprise annual reports). Most documents are structured tables and semi-structured reports. They include fields such as total pipe network length, average daily water supply, COD concentration, unit water supply cost, and service coverage population. Units used include meters, cubic meters, milligrams per liter, yuan per ton, and others.
Constraints on multi-turn dialogue and prompt engineering
The multi-source temporal granularity, mixed field units, and compliance requirements of water utility due diligence data create multiple constraints for the multi-turn dialogue and prompt engineering process. Multi-source data covers update cycles ranging from hourly to annual. During multi-turn dialogue, users must be guided to clearly specify the data time range to avoid confusion between real-time monitoring data and monthly operational data. Field units cover multiple types. The prompt must require output results to attach corresponding units; otherwise, the response is deemed non-compliant. Water utility data involves public service compliance requirements. During multi-turn dialogue, data sources must be verified as public announcements to avoid introducing undisclosed internal information. Document length spans a wide range, so parsing and context management must be adapted for data sources of different lengths.
Configuration settings
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
maxContext | 16384–32768 token | A single water utility due diligence annual report often contains dozens of pages, and this range can accommodate multiple parsed text segments and multi-turn dialogue history, covering context requirements for most scenarios |
UPLOAD_FILE_MAX_SIZE | 500 MB | The file sizes of water utility annual reports and pipe network monitoring summary reports are usually large, and this value covers most compliant upload scenarios |
PARSE_FILE_TIMEOUT_SECONDS | 600 seconds | Structured parsing of large water utility operational reports requires a long time, and this setting avoids parsing failure due to timeout |
rag_top_k | Top 8–12 entries | Water utility data has many fields and close associations. Too many recalled entries will cause context redundancy, while too few may miss key pipe network or operational parameters |
similarity_threshold | 0.75–0.85 | There are many professional terms in water utility data. This range balances recall accuracy and coverage, avoiding incorrect recall of unrelated public utility data |
chunk_size | 800–1200 characters | Structured paragraphs in water utility reports are of moderate length. This segmentation range ensures that a single segment contains complete fields and values, facilitating subsequent recall and understanding |
The parameter values provided on this page are conventional recommendations used as a starting point for configuration. Actual values are affected by material form, data volume, and business rules. Specific issues require specific analysis, and it is recommended to test on your own samples before finalizing settings.
Three common mistakes
- Phenomenon: When the API is called to connect to the open-source intelligent agent, uploading a water utility due diligence report returns a parsing failure response, with a timeout error displayed in the logs. Cause: The
PARSE_FILE_TIMEOUT_SECONDSparameter was not adjusted, and the default value is shorter than the parsing time required for large water utility reports. - Phenomenon: Water utility due diligence results returned by the platform front-end test dialogue differ from those returned by API calls. Cause: API calls do not specify the
rag_top_kandsimilarity_thresholdparameters consistent with the front end, resulting in different recalled data source entries. - Phenomenon: After a dialogue application is created and an API call is used, the configured water utility due diligence knowledge base does not load by default. Cause: The API call does not include the
kb_idsparameter, so the associated knowledge base ID is not specified, and the knowledge base does not load by default.
How to confirm the configuration is set correctly
- Check the platform's upload file limit prompt to confirm that the
UPLOAD_FILE_MAX_SIZEparameter matches the actual upload size of the water utility report. - Initiate a test dialogue to verify that returned results attach the corresponding units for water utility data, confirming that the system prompt configuration is active.
- Compare the parameter configurations of the front-end test and API calls to confirm that values for parameters such as
rag_top_kandsimilarity_thresholdare consistent. - Upload a water utility knowledge base file configured with the
kb_idsparameter, initiate an API call, and confirm that the knowledge base content is correctly recalled.
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.