What this use case’s data looks like
Data is sourced from an insurer’s historical claim review files, insured individuals’ medical records (including outpatient and inpatient records), and archived health disclosure submissions collected during policy application. Each entry corresponds to one or more pre-existing medical visit records for a single insured person. Document structures include fields such as the insured person’s unique identifier, consultation date, full name of the medical facility, diagnosis code, chief complaint, and detailed medical orders. Updates are triggered synchronously with claim applications. Updates to a single claim file only add new medical records for the corresponding insured person; no scheduled bulk update tasks are implemented.
Constraints on vector models and indexing
This use case’s data combines standardized diagnosis codes and free-text chief complaints and medical orders. The mixed structure requires vector models to support vectorization for both structured field codes and unstructured text. A single claim file may contain multiple medical records, with wide variation in text length. This requires support for splitting vector chunks by consultation date or relevance. Data is synchronized in real time with claim applications, so indexes must support low-latency incremental updates to avoid performance losses from full index reconstruction. Additionally, indexes must be grouped by the insured person’s unique identifier to prevent mixed recall of pre-existing condition data across different insured persons.
Configuration Settings
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
embedding_model | bge-m3 or text-embedding-v3 | Meets vectorization requirements for medical domain text and standardized diagnosis codes, while balancing semantic understanding and structured field association |
chunk_size | 800–1200 characters | Pre-existing condition records include long-form medical orders. This segment length balances context completeness and shard retrieval efficiency |
recall_top_k | Top 10–15 results | Valid pre-existing medical records associated with a single claim file typically do not exceed 10 entries. This value range avoids interference from irrelevant data |
similarity_threshold | 0.75–0.85 | A threshold range that balances recall accuracy and missed detection risk, required to distinguish similar diagnoses from confirmed pre-existing conditions |
index_incremental_update | Enabled | Adapts to real-time synchronized claim data and reduces computational overhead from full index reconstruction |
vector_db_index_type | HNSW | Supports fast recall of high-dimensional vectors, meeting the low-latency response requirements of claim initial review |
The parameter values provided on this page are general recommendations used as a starting point for configuration. Actual values are affected by material format, data volume, and business rules. Specific issues require case-by-case analysis. Testing on independent samples is recommended before finalizing settings.
Three common configuration issues
- Issue: After configuring the vector model, an error "No available channels under the default group" is displayed, or models deployed via Ollama cannot be detected. Cause: The API endpoint and key for the vector model were not correctly filled in the FastGPT model management interface. For open-source models, the key can be left blank, but the correct local address must be configured, or the model was not bound to the currently used group.
- Issue: The vector embedding task returns a failure log with the prompt "Text is too long to process". Cause: The
chunk_sizeparameter was not set, or the set value is too large, exceeding the maximum input length limit supported by the vector model. - Issue: Recall results include pre-existing condition records for other insured persons. Cause: Index grouping was not configured using the insured person’s unique identifier, resulting in mixed recall of vector data across different users.
How to confirm correct configuration
- Access the FastGPT model management interface, review the vector model list, confirm the selected model is in the "Enabled" state and bound to the currently used group.
- Upload a single simulated claim file, trigger vector index construction, and check index construction logs to confirm no errors related to embedding failures or missing shards.
- Submit a simulated initial claim review request, review the recall result list, confirm results only associate pre-existing medical records for the current insured person, and that the quantity matches expectations.
- Modify the vector model’s similarity threshold, verify that the number of recall results changes as expected in response to the threshold adjustment.
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.