这个品类的数据长什么样
投资平台的收益率与行情数据主要来自证券交易所、基金登记结算机构及平台自有交易数据库。数据更新节奏严格匹配交易日周期，每个交易日收盘后完成当日全量数据刷新。单条数据文档包含交易日期、产品唯一标识、单位净值、累计净值、日收益率、区间收益率等字段，单位涵盖百分比、人民币元、产品份额，高频行情数据虽按分钟级推送，但日报播报场景下仅需使用每日收盘后生成的汇总数据。
这些特征在「对话日志与审计」这一环带来什么约束
交易日周期的更新节奏要求对话日志需按交易日维度归档，避免跨日数据混淆。多字段多单位的结构要求审计日志完整记录每一次对话调用的请求参数、返回字段及对应单位，防止单位转换引发的审计偏差。行情数据的时效性要求日志留存请求发起时间与数据返回时间，确保审计时可验证数据是否为对应交易日的合规版本。投资场景下的对话内容涉及交易决策相关信息，审计日志需留存完整上下文链路，包括用户提问、召回的行情数据片段、AI生成的播报内容，且关联对应产品标识与日期，满足合规可追溯要求。
配置怎么定
| 配置项 | 建议取法 | 这样取的依据 |
|---|---|---|
enableAuditLog | 开启 | 金融场景下强制要求对话操作可审计，需启用完整的审计日志记录功能 |
logRetentionDays | 90 天 | 金融合规要求下，对话日志需留存至少一个完整会计周期，90天覆盖季度审计需求 |
auditLogIncludeFields | ["request_time", "product_code", "return_rate", "unit", "user_id", "chat_id"] | 需覆盖审计所需的时间、产品标识、核心数据字段、用户与会话标识，确保可追溯 |
maxContext | 8000–12000 token | 投资场景下需留存完整的行情数据召回上下文与用户提问，避免因上下文截断导致审计链路缺失 |
mongodbWriteTimeoutMS | 5000 毫秒 | 行情数据更新频率较高，需确保日志写入数据库无超时阻塞，避免日志丢失 |
chatHistoryIsolation | 按用户维度隔离 | 投资平台用户数据敏感，需确保不同用户的对话日志与审计记录无法跨账号访问，符合数据安全要求 |
本页给出的参数取值均为常规建议，用于确定配置的起点。实际取值受材料形态、数据量与业务规则影响，具体问题需具体分析，建议在自有样本上实测后再定。
容易做错的三处
- 现象：对话调用后MongoDB写入超时，日志报
slow operation xxxxms错误。原因：未将mongodbWriteTimeoutMS配置为适配行情数据批量写入的时长，导致审计日志写入阻塞。 - 现象：聊天记录未按交易日归档，跨日数据混杂在同一会话日志中。原因：未按
logRetentionDays的周期维度配置日志归档规则，且未关联交易日期字段进行分类存储。 - 现象：客户端中断SSE连接后，部分对话日志未写入数据库。原因：未设置
sseConnectionTimeout的合理阈值，且未配置会话中断时的日志落盘逻辑，导致未完成的写入操作丢失。
怎么确认配好了
- 登录FastGPT后台的日志管理页面，筛选对应交易日的会话记录，检查是否包含预设的审计字段，确认字段完整性。
- 发起一次带产品代码与收益率数据的对话请求，查看MongoDB的
fastgpt_chat_logs集合，验证日志是否包含请求时间、用户标识与会话ID，且写入时间符合配置要求。 - 切换不同账号发起对话，检查各自的聊天历史页面，确认无法查看其他账号的会话记录，验证隔离配置生效。
- 查看系统运行日志，确认无审计日志未生成的报错信息，验证
enableAuditLog配置已正常启用。
问题素材取自公开社区提问（2026-09-11 去重 4,834 条）。文中的配置项名称与取值区间需以所用版本的实际界面与文档为准；本页核验日 2026-09-14，当时的最新发布版本为 FastGPT v4.17.0。