What the Data Looks Like
Data sources for water utility financing daily reports include internal financing ledgers of water utilities, water sector-specific project announcements from local public resource trading platforms, and financing filing data publicly released by local financial regulatory authorities. Updates are made daily. Individual document lengths vary widely. It is recommended to calculate or test based on your own samples before finalizing settings. Document structure includes fields such as the administrative region the project belongs to, project type (e.g., pipeline operation and maintenance, water supply plant expansion and renovation), financing amount (unit: ten thousand yuan), financing channel, approval status, release date, and project fund usage summary. Some documents include excerpts from local government supporting policies.
Constraints on Vector Models and Indexing Workflows
The multi-field structure and update schedule of water utility financing daily reports create multiple constraints for vector models and indexing workflows. Text field lengths vary significantly: some short fields are only tens of characters long, while long fields can exceed one thousand characters. Adaptation to text vectorization processing for different lengths is required. Daily updated data sources require support for incremental index updates, to avoid resource consumption from full index rebuilding. Core retrieval needs focus on region, project type, and financing amount. Multi-field combined filtering rules must be configured, combined with vector recall to achieve precise matching. Some documents include excerpts of policies with professional terminology from the public utility sector. A vector model adapted to vertical domain text must be selected to ensure accurate semantic encoding.
Configuration Settings
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
embedding_model_endpoint | http://<local deployment IP>:11434/v1 | Adapts to the OpenAI-compatible interface format of Qwen3-Embedding-8B:F16 deployed via Ollama or VLLM |
chunk_size | 800-1200 characters | Adapts to long text fragments from water utility financing daily reports, avoids semantic fragmentation, and matches the context window limits of 8B-level vector models |
embedding_batch_size | 16-32 entries | Adapts to the video memory usage of locally deployed Qwen3-Embedding-8B, avoids out-of-memory errors |
milvus_collection_shards | 2-4 shards | Matches the daily report data volume scale, balances query concurrency and resource overhead |
filter_fields | ["project_region", "financing_amount", "project_type"] | Matches the core retrieval dimensions of water utility financing daily reports, enables precise field-level filtering |
rerank_model_top_n | 5-8 entries | Balances retrieval relevance and browsing efficiency, avoids excessive results increasing screening costs |
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 targeted analysis. It is recommended to test on your own samples before finalizing settings.
Three Common Misconfigurations
- Symptom: Milvus fails to start, and logs indicate a PostgreSQL connection timeout. The root cause is that the official compose file integrates a built-in PostgreSQL for metadata storage by default. If the corresponding local image is not available or the port is occupied, the deployment process will be interrupted.
- Symptom: A 400 Bad Request error is returned when connecting to Qwen3-Embedding-8B deployed via VLLM. The root cause is that the model interface path prefix is not configured correctly, or the request header does not carry required authentication information.
- Symptom: The number of vector recall results does not match the configured
recall_top_kvalue, with either empty results or more results than expected. The root cause is that index filtering rules are not configured correctly, or the segment length is set too large, causing some text to not be vectorized properly.
How to Verify Successful Configuration
- Call the vector model test interface, input a single text fragment from a water utility financing daily report, and confirm the returned vector dimensions match the model parameters.
- Upload a single test document, review the index generation logs, and confirm the segment length matches the configured
chunk_size. - Execute a retrieval request with filtering conditions, and confirm the returned results include field information corresponding to the configured
filter_fields. - Submit 10 incremental documents sequentially, review the index update logs, and confirm only newly added documents are processed, with no full index rebuilding triggered.
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.