What This Category of Data Looks Like
This category of data is primarily sourced from the national medical security information platform, hospital HIS and medical insurance interfaces, medical insurance catalog coding database, and cross-regional medical treatment settlement platform. Daily processed documents include medical insurance settlement lists, expense details, medical record homepages, prescriptions, rejection lists, and settlement reconciliation statements. Data updates occur once per day. Each individual document contains fields such as diagnosis and treatment item codes, pharmaceutical supplies codes, expense amount, insured person identifier, and settlement status. Supported units include yuan, person-times, and standard date formats.
Constraints Imposed by These Characteristics on Vector Models and Indexes
This category of data has scattered sources and diverse formats, including structured coding fields and unstructured text content. This requires the index link to support mixed storage and retrieval of multi-format data. Daily updated data volume must be processed via an incremental indexing mechanism to avoid performance losses caused by full reconstruction. Precise matching of diagnosis and treatment item and pharmaceutical supplies codes is required. This requires the index to set exclusive retrieval rules for structured fields, while combining vector retrieval to achieve associated matching of unstructured content. For single or batch settlement audit business scenarios, the index must support low-latency batch recall to ensure process handling efficiency.
Configuration Recommendations
These configurations apply to FastGPT v4.17.0.
| Configuration Item | Recommended Value Range | Rationale |
|---|---|---|
| Chunk Length | 800–1200 characters | Adapts to the single-block content density of medical insurance settlement lists, avoiding splitting breaks between codes and text |
| Overlap Length | 100–150 characters | Retains cross-block coding association information, preventing key matching fields from being split |
defaultToken | 4096 | Matches the average text length of medical insurance documents, ensuring complete loading of single-block content |
maxToken | 8192 | Supports concatenation of multi-block content for batch settlement audits, meeting context requirements |
| Similarity Threshold | 0.75–0.85 | Balances recall accuracy between code matching and text consistency, adapting to the strict requirements of medical insurance audits |
| Single Search Limit | Top 10 entries | Controls the number of retrieval results, avoiding redundant information interfering with audit judgments |
Three Common Misconfigurations
- Retrieval result count is far lower than expected. The cause is that the incremental index switch is not enabled, so daily updated medical insurance data is not correctly loaded into the index database.
- Vector retrieval results do not match the expected code matching degree. The cause is that exclusive structured indexing is not configured for diagnosis and treatment item code fields, and only general vector retrieval is used, leading to insufficient matching accuracy.
- System prompts insufficient disk space. The cause is that cleanup rules are not configured according to storage logic, and storage quotas for original files, split text blocks, and embedded vectors are not differentiated, resulting in total usage exceeding the threshold.
How to Confirm Configurations Are Properly Set
- The knowledge base storage statistics panel can be reviewed to confirm that the storage proportion of original files, split text blocks, and embedded vectors meets expectations.
- A test medical insurance settlement list can be uploaded, and retrieval initiated to verify that recall results include associated prescriptions and expense details.
- Index construction task logs can be reviewed to confirm that daily incremental index tasks execute automatically without failure errors.
- The similarity threshold can be adjusted, and retrieval result matching accuracy verified to confirm alignment with business audit strict requirements.
The values provided here are common starting points, and should be evaluated against local sample data.
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-28.