这个品类的数据长什么样
既往症判定的数据来源包括医保结算明细、门诊/住院病历、体检报告、投保健康告知存档。数据随理赔申请触发时同步拉取对应被保人的关联数据，无固定周期性更新。不同数据源的文档结构存在差异：医保结算明细包含就诊日期、医院名称、诊断名称、费用明细字段；病历包含主诉、现病史、既往病史、医嘱字段；体检报告包含各项指标、异常项标注字段。诊断编码统一使用ICD-10标准，就诊日期采用YYYY-MM-DD格式，费用单位为元。
这些特征在「多轮对话与提示词」这一环带来什么约束
数据来源分散且包含结构化表格与非结构化文本等多模态内容，要求多轮对话需按数据源类型依次整理信息，避免一次性投喂过长内容导致上下文窗口溢出。数据随申请实时拉取，要求每次对话调用时同步更新关联数据源，无法依赖静态缓存内容。字段存在标准编码要求，提示词需明确指定识别ICD-10编码，不应仅以文本描述作为识别依据，确保判定结果的规范性。不同文档的长度差异较大，长病历可能占用大量上下文空间，需设置合理的分段与召回规则，避免关键信息被截断。
配置怎么定
| 配置项 | 建议取法 | 这样取的依据 |
|---|---|---|
maxContext | 8000–12000 字符 | 既往症相关数据包含多份病历和结算明细，总长度通常在6000-10000字符，预留足够上下文避免关键信息截断 |
recallTopK | 前 8 条 | 既往症数据分散在不同就诊记录，召回过多会引入冗余信息，过少会遗漏关键既往病史 |
promptTemplate | 按「就诊记录-医保结算-健康告知」的顺序整理既往症信息，识别ICD-10编码，结合本次理赔申请的就诊记录判定是否属于既往症范畴 | 明确梳理顺序避免信息混乱，指定编码标准提升判定准确性，绑定理赔申请上下文确保判定针对性 |
enableMCP | 开启 | 需要调用医保接口实时拉取最新结算数据，不应仅依赖静态知识库的历史内容 |
similarityThreshold | 按实测标定 | 需根据业务场景的既往症关联规则调整，过滤低相关性的历史就诊记录 |
timeout | 300 秒 | 跨数据源拉取和多轮校验需要较长处理时间，避免因超时中断判定流程 |
本页给出的参数取值均为常规建议，用于确定配置的起点。实际取值受材料形态、数据量与业务规则影响，具体问题需具体分析，建议在自有样本上实测后再定。
容易做错的三处
- 现象：多轮对话节点输出的
newContext与aiReply字段内容重复，且未保留有效既往症数据。原因：未区分上下文拼接和回复生成的边界，将AI回复内容错误混入上下文队列。 - 现象：配置
enableMCP调用医保数据接口后，返回的既往症判定结果与实际记录不符。原因：提示词未明确要求优先使用MCP返回的结构化数据进行判定，仍依赖静态知识库内容。 - 现象：提交理赔申请后，AI回复的内容与当前问题无关，错误关联了其他被保人的既往症记录。原因：工作流中未正确绑定全局变量
applicantId，导致调用的数据源对应错误的被保人信息。
怎么确认配好了
- 触发一次模拟理赔申请，查看
context字段的拼接内容，确认包含按就诊记录、医保结算、健康告知顺序排列的有效数据。 - 调用MCP工具拉取测试用的医保数据，查看返回结果是否包含预设的ICD-10编码和就诊信息，确认工具调用正常。
- 提交包含已知既往症的测试用例，核对AI回复的判定结果是否与预设的既往症记录匹配，调整
similarityThreshold至符合业务要求的区间。 - 检查工作流中全局变量的绑定配置，确认
policyId、applicantId等变量已正确传入提示词模板，未出现空值。
问题素材取自公开社区提问（2026-09-11 去重 4,834 条）。文中的配置项名称与取值区间需以所用版本的实际界面与文档为准；本页核验日 2026-09-14，当时的最新发布版本为 FastGPT v4.17.0。