What the data for this category looks like
Trading rule data is sourced from internal business configuration systems of financial institutions and business standard documents published by regulatory authorities. Update cycles are triggered by regulatory policy adjustments or new business launches, with no fixed schedule. A single update covers one or multiple rule entries. Individual rule documents primarily use structured fields, including rule ID, applicable scenarios, effective start and end times, transaction trigger conditions, operation guidelines, exception notes, and other fields. Time fields use ISO date format. Trigger conditions mostly combine natural language descriptions with parameterized conditions, with no unified fixed units, varying by rule type.
Constraints imposed on vector models and indexing by these characteristics
The mixed structured fields and natural language description characteristics of trading rule data require vector models to achieve consistent encoding for both parameterized rule text and unstructured explanations. The non-fixed update cycle requires the indexing component to support incremental updates and partial refreshes, avoiding resource consumption from full reindexing. The presence of high-filter fields such as applicable customer groups and effective times requires indexing to support multi-dimensional metadata filtering to narrow recall scope. The feature of short individual document lengths but large numbers of batch entries requires batch indexing request parameter designs to adapt to high-concurrency write scenarios.
How to configure settings
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
batch_index_size | 10–50 items/request | Individual trading rule entries have short lengths. Excessively large batches risk triggering interface timeouts, while excessively small batches reduce write efficiency |
vector_model_name | bge-small-zh-v1.5 or text-embedding-3-small | Trading rule data mixes structured and natural language content. These models balance encoding accuracy and inference cost |
index_metadata_fields | Rule ID, Effective Time, Target Customer Group | These fields are high-frequency filter conditions in customer inquiries, so they must be included in metadata indexing to support precise recall |
index_refresh_interval | Calibrated to business update frequency | Trading rule updates have no fixed schedule, so refresh intervals must be set based on actual update rhythm |
recall_top_k | Top 10–15 items | There are many trading rule entries. A sufficient number of recalled items must be obtained for secondary screening based on business scenarios |
vector_db_batch_write_timeout | 30 seconds | The processing duration of batch indexing requests must match the interface timeout threshold to avoid write failures |
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, and it is recommended to test on your own samples before finalizing settings.
Three common mistakes
- Phenomenon: When submitting batch rule indexing requests, the interface returns a
413 Request Entity Too Largeerror. Cause: Thebatch_index_sizeparameter is not configured, and the number of entries submitted in a single request exceeds the interface's default limit. - Phenomenon: When customers inquire about expired trading rules, recall results still include invalid entries. Cause: The
生效时间field is not included in theindex_metadata_fieldsconfiguration, and the metadata filtering logic is not enabled. - Phenomenon: After modifying vector database data directly via an external database tool, platform recall results are not updated synchronously. Cause: Operations bypass the platform's native indexing update interface, and metadata association information is not updated synchronously, leading to data consistency breaks.
How to confirm configuration is active
- Submit an indexing request for a single test rule, enter the platform's index management interface, and check whether the displayed metadata fields include the preset configuration items.
- Trigger an incremental index update, compare the number of source data entries with the number of entries returned by vector database queries, and confirm that the update scope matches the configuration requirements.
- Input a test inquiry statement that includes a specific effective time and applicable customer group, and check whether the recall results automatically filter out rules that do not meet the conditions.
- Submit a batch indexing request that exceeds the value set for
batch_index_size, confirm that the interface returns a parameter verification failure, and verify that the configuration is active.
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.