What data looks like for this category
Data mainly comes from natural resources department public planning indicators, housing and urban-rural development department filing prices, real estate enterprise public project announcements, and first-hand industry research materials. Update frequency varies greatly by data type: policy documents are updated irregularly, land acquisition and filing data is updated monthly, and construction progress and competitor dynamics are updated weekly. Most individual documents are structured tables or long-text reports, containing fields such as project number, plot coordinates, floor area ratio, calculated floor area, average filing price, start and completion time. Units include square meters, yuan per square meter, ten thousand yuan, floor area ratio, and others.
What constraints do these characteristics impose on the database and operations link
High proportion and large number of structured fields require the database to support joint indexes and multi-condition queries to avoid retrieval delays. Large differences in update frequency require dividing synchronization tasks by data type to avoid resource occupation from full-volume pulling. Mixed structured and long-text content requires adapting to dual storage modes, storing structured indicators and document body separately. Potential unit differences across different sources require unit standardization verification before data writing to prevent statistical deviations in subsequent retrieval.
How to set the configuration
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
PARSE_FILE_TIMEOUT_SECONDS | 600 seconds | Residential development project reports are mostly long-text, and parsing a single document takes a long time. 600 seconds covers the parsing needs of most long documents |
UPLOAD_FILE_MAX_SIZE | 1000 MB | Single files such as project feasibility study reports and planning drawings are large in size, so this setting adapts to large-file upload scenarios |
Retrieval Top N | Top 15 | Residential development investment research requires multi-dimensional data covering plot indicators, competitors, policies, and others. 15 entries balance retrieval coverage and retrieval efficiency |
Similarity Threshold | 0.72–0.78 | Mixed structured fields and text content. A threshold that is too low will introduce irrelevant competitor data, while a threshold that is too high may miss relevant policy interpretations |
DB_SYNC_BATCH_SIZE | 200 items/batch | Batch synchronization avoids overload from single requests, and adapts to classified synchronization needs for data with different update frequencies |
MONGO_COLLECTION_TTL | 90 days | Historical inactive project data does not need to be retained for online retrieval long-term. 90 days balances storage costs and data reuse needs |
The parameter values provided on this page are common starting points for configuration. The 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 the settings.
Three common mistakes
- Symptom: An error is reported when starting after configuring the Oracle database connection, prompting
ORA-01017or connection timeout. Cause: Residential development data sources include multiple sets of historical filing databases, and the connection string does not specify the correct service name and character set, resulting in authentication failure or failure to establish a session. - Symptom: Calling the
/api/core/dataset/collection/create/apiColinterface returns400 Bad Request. Cause: Required field parameters unique to residential projects, such as floor area ratio and calculated floor area, are not passed correctly, resulting in interface verification failure. - Symptom: Conversation records in MongoDB cannot be automatically cleaned, and storage usage exceeds the limit. Cause: The
MONGO_COLLECTION_TTLparameter is not configured, or the expiration time is set too long, resulting in historical conversation data not being automatically deleted.
How to confirm the configuration is complete
- Run a database connection test to verify the connection status of different data sources, and confirm that indexes and field verification rules take effect.
- Upload a typical residential development project report, check whether the parsed data fields are complete and whether the units meet the preset standards.
- Trigger a batch synchronization task, observe the execution time and success rate of the synchronization batches, and confirm that no overload occurs.
- Check the TTL index status of MongoDB to confirm that the automatic cleaning rules for conversation records have been loaded correctly.
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.