What this category of data looks like
Expense list data is sourced from the billing systems or medical insurance settlement systems of treating medical institutions. It is submitted synchronously with each single claim application, and has no fixed update cycle. The documents are in structured table format, including fields such as treatment date, medical institution name, charging item name, medical insurance catalog code, unit price, quantity, pricing unit, total amount, etc. Unit price and total amount are denominated in Chinese Yuan. Some line items will include supplementary notes.
What constraints these characteristics impose on multi-turn dialogue and prompt engineering
The structured table characteristics of this category require multi-turn dialogue to extract key information grouped by fields, to avoid missing easily overlooked fields such as medical insurance catalog code and pricing unit. Differences in list formats across different medical institutions require prompts to pre-set common format adaptation rules to support custom table headers. The characteristic that there is no historical data for a single submission requires multi-turn dialogue to focus on the verification of the current list, without cross-cycle comparison. The strong correlation between amount and unit requires clear verification logic for unit price and total amount to be specified in the prompt, to avoid amount deviations caused by unit errors.
How to set configurations
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
maxContext | 4000–6000 characters | Expense lists typically contain 10-20 line items. Combined with other context for claim initial review, sufficient length is needed to carry the complete list and dialogue history |
PARSE_FILE_MAX_SIZE | 5 MB | Expense lists are mostly in PDF or Excel format. A single file usually does not exceed 2 MB, so redundant space is reserved to support multi-page lists |
prompt_template | Verify each field of the expense list one by one, check that unit price × quantity = total amount, flag abnormal items and guide confirmation | Adapt to the structured verification requirements of expense lists, clarify the abnormal fields that need confirmation in multi-turn dialogue |
max_tokens | 1500–2000 characters | Verification results and multi-turn confirmation prompts need to be output, to avoid truncation caused by overly long generation |
temperature | 0.1 | Stable output is required for verification tasks, to avoid random deviations |
retry_times | 2 times | Reserve retry space for format parsing failures, to avoid extended process caused by excessive retries |
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 specific analysis, and it is recommended to test on your own samples before finalizing.
Three common mistakes
- Only a single verification prompt can be sent per dialogue turn, and two messages requiring user confirmation cannot be sent consecutively. This occurs because batch message triggering rules for advanced orchestration are not configured, resulting in only one piece of content being output per interaction.
- Some fields in the parsed expense list are empty, and the verification result shows "Medical insurance catalog code not found". This is because the
PARSE_FILE_MAX_SIZEconfiguration value is too small, causing large PDF-format lists to fail to be fully parsed and some fields to be lost. - After more than 3 turns of multi-turn dialogue, amount matching errors appear in the verification results. This is because the reasonable range of
maxContextis not limited, and overly long dialogue history interferes with the model's judgment of the current expense list.
How to confirm the configuration is complete
- Upload a standard-format expense list to trigger multi-turn dialogue, and check whether the model can extract and verify key information field by field.
- Adjust the value of
maxContext, upload test data containing multi-turn interactions, and confirm that the dialogue history is not truncated unexpectedly. - Simulate an expense list containing abnormal fields, and check whether the model can correctly flag abnormal items and guide user confirmation.
- Connect to the target business channel, and test whether the output verification results can be displayed normally.
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.