这个品类的数据长什么样
汽车服务营销的数据主要来源于车险保单系统、线下门店维保档案、客户CRM与车险预约平台。数据更新节奏分实时与定时：维保工单、预约记录实时生成，客户基础信息与保单到期数据每周同步。单条客户关联数据文档结构包含客户ID、车辆VIN码、投保险种、消费金额、到店时间、下次维保/续保提醒日期，字段单位统一为元、公里、YYYY-MM-DD格式，部分数据包含服务技师编号与门店编码。
这些特征在「多轮对话与提示词」这一环带来什么约束
车辆VIN码作为唯一标识，要求多轮对话中需精准关联客户与对应车险与维保数据，避免跨客户信息混淆。实时生成的维保与续保提醒数据要求对话上下文需支持实时调用最新服务记录，需限制上下文窗口的实时数据加载量。多字段的文档结构要求提示词需明确指定召回字段范围，过滤非营销相关的内部编码字段。统一的字段单位要求提示词需规范输出格式，避免单位混用导致的营销信息偏差。
配置怎么定
| 配置项 | 建议取法 | 这样取的依据 |
|---|---|---|
maxContext | 8000–12000 字符 | 汽车服务营销需容纳多轮对话与多条维保、续保记录，长上下文可避免关键信息截断 |
recall_top_k | 前6–8 条 | 汽车服务营销需覆盖维保、续保、周边救援等场景，过多召回会稀释有效营销信息 |
conversation_history_retention_days | 30–90 天 | 营销复盘需查看历史对话，过长保存会占用不必要的存储资源 |
knowledge_base_permission_mode | 按角色隔离 | 汽车服务的内部工单与保单数据需限制仅授权客服角色可访问，避免敏感信息泄露 |
parse_file_chunk_size | 800–1000 字符 | 汽车服务的维保文档包含长描述内容，分段长度适配字段密度与召回精度 |
prompt_template | 固定包含VIN码匹配规则、字段单位规范、营销场景限定 | 精准匹配客户与对应数据，避免输出偏差与无关信息 |
本页给出的参数取值均为常规建议，用于确定配置的起点。实际取值受材料形态、数据量与业务规则影响，具体问题需具体分析，建议在自有样本上实测后再定。
容易做错的三处
- 现象：对话记录保存时长不符合预期，部分超过配置天数的记录仍可查看。原因：未正确修改
conversation_history_retention_days参数所在的系统配置文件，或配置值未重启服务生效。 - 现象：知识库召回结果包含未授权的内部工单或保单数据。原因：未开启
knowledge_base_permission_mode的角色隔离设置，或未为客服角色分配对应知识库权限。 - 现象：多轮对话中出现单位混用，如将保养里程标注为英里，未使用公里。原因：提示词模板未明确指定字段单位的统一规范，未限制输出格式。
怎么确认配好了
- 查看系统配置文件中
conversation_history_retention_days的参数值，确认与业务需求匹配后重启服务。 - 切换不同角色账号，测试访问知识库，验证仅授权角色可查看对应内部数据。
- 发起模拟多轮对话，输入客户VIN码与维保/续保需求，检查召回的字段是否符合预设范围。
- 调整
maxContext参数后，发起包含多条历史对话的测试，确认上下文加载无截断。
问题素材取自公开社区提问（2026-09-11 去重 4,834 条）。文中的配置项名称与取值区间需以所用版本的实际界面与文档为准；本页核验日 2026-09-14，当时的最新发布版本为 FastGPT v4.17.0。