What the data for this category looks like
Market data is sourced from exchange public APIs or professional market aggregation services. It is pushed in real time during trading sessions, and updated at fixed intervals outside trading hours. Each individual record is a structured entry containing fields such as ticker code, ticker name, latest transaction price, price change amount, price change percentage, trading volume, transaction amount, update timestamp, and more. Units follow standard units for the corresponding trading product: stocks use yuan and lots, futures use contract units, tons, and similar standards. The total size of a full batch of market data grows with the number of tickers. The length of detailed data for a single ticker remains stable at around 100 characters.
What constraints these characteristics impose on deployment and upgrade
The real-time update nature of market data demands that the index synchronization interval configured during deployment matches the second-to-minute update rhythm, to prevent retrieval data from lagging behind market prices. The presence of multiple fixed structured fields requires completing field mapping configuration before deployment, to avoid missing fields or type mismatches during retrieval. The large size of full batch data requires using incremental updates during upgrades instead of full replacement, to prevent service interruptions. The low update frequency outside trading sessions allows version upgrades or configuration adjustments during this window, to reduce business impact.
How to Set Configuration Values
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
PARSE_CHUNK_SIZE | 800–1200 characters | A single ticker's detailed market data is approximately 100 characters. 800–1200 characters can accommodate 3 to 5 complete ticker datasets, avoiding chunk loss |
recallTopK | Top 20–30 entries | Market data retrieval often requires comparing multiple tickers. Too many recalled entries increases inference latency, while too few fails to meet cross-ticker retrieval needs |
similarityThreshold | 0.65–0.75 | Market data retrieval primarily focuses on exact matching of ticker codes or names. A threshold that is too low introduces irrelevant data, while one that is too high misses relevant tickers |
refreshInterval | 5–10 seconds | Matches the real-time update rhythm during trading sessions. Can be adjusted to 300 seconds outside trading hours |
PARSE_FILE_TIMEOUT_SECONDS | 600 seconds | Allows sufficient time for parsing when importing full batch market data, avoiding timeout interruptions |
maxContext | 10000 characters | Adapts to the length of batch-recalled market data, ensuring retrieval results can be fully passed to the model |
The parameter values provided on this page are common starting points for configuration. Actual values are affected by data format, data volume, and business rules. Specific issues require individual analysis, and it is recommended to test on your own samples before finalizing settings.
Three Common Misconfigurations
- Phenomenon: When
PARSE_CHUNK_SIZEis set to 3000 characters, some tickers are missing from retrieval results after importing market data, and achunk droppederror appears in the parsing log. Cause: A single ticker's detailed data is only around 100 characters. A 3000-character chunk will include excessive redundant whitespace or truncated incomplete data, causing the parsing engine to filter invalid chunks. - Phenomenon: When deploying on a cloud server, unable to pull images via Redis. After service startup, a
connection refusederror is returned. Cause: The corresponding port is not open in the Redis configuration, or the container network mode is not correctly associated with the Redis service. - Phenomenon: Unable to call the model after customizing the vLLM inference address. The frontend returns a
404 Not Founderror. Cause: The custom request address does not include the vLLM model inference path, only the port number is filled in.
How to Verify Proper Configuration
- Import a single batch of test market data, check if there are any
chunk droppedrelated errors in the parsing log to confirm that chunk loss issues have been resolved. - Submit a retrieval request containing multiple ticker names, verify that the number of recalled entries matches the
recallTopKconfiguration. - Check the index update log to confirm that the update interval matches the
refreshIntervalconfiguration, and the data synchronization frequency meets expectations. - Submit a model call request, confirm that the returned result contains complete market data fields, with no missing fields or type mismatch issues.
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.