这个品类的数据长什么样
本品类的数据来源为旗下各金融、保险、理财子板块的交易系统、第三方行情接口及内部估值数据库。更新节奏为每日固定时段完成全量持仓收益率核算，盘中每小时同步最新估值快照。文档采用分层结构化格式，包含控股主体编码、子公司业务类型、资产类别、当日收益数值、基准对标值、更新时间戳等字段，其中收益类字段单位为基点，资产类别涵盖股票、债券、公募基金、保险理财产品等细分项。
这些特征在「对话日志与审计」这一环带来什么约束
由于数据按控股主体及子板块分层存储，对话日志需按控股主体、子公司业务类型做维度隔离，确保审计时可精准追溯特定主体的播报请求与数据调用链路。因数据存在固定核算批次与盘中实时快照两类更新，日志需标记请求对应的数据源类型，避免混淆当日核算完成前的快照数据与收盘后全量数据。多字段的结构化数据要求日志完整保留资产类别、基准对标值等关联字段，不可截断关键信息。同时，多来源整合的特性要求日志关联各子板块的独立调用记录，便于排查单板块数据异常对整体播报结果的影响。
配置怎么定
| 配置项 | 建议取法 | 这样取的依据 |
|---|---|---|
log_retention_days | 90 天 | 符合金融行业审计的常规合规留存周期，覆盖季度审计所需的日志范围 |
audit_log_include_fields | ["holding_company_id", "subsidiary_business_type", "asset_type", "daily_return", "update_timestamp"] | 覆盖本品类核心审计字段，确保可追溯数据来源、主体及收益值 |
agent_log_scope | per_holding_entity | 匹配本品类按控股主体隔离数据的特性，避免跨主体日志泄露 |
token_statistics_dimension | ["application", "holding_entity"] | 支持按控股主体维度统计token消耗，适配多主体的成本核算需求 |
log_truncation_threshold | 8192 字符 | 避免长日志存储溢出，同时保留完整的结构化字段信息 |
log_batch_mark_enabled | 开启 | 标记固定核算批次与实时快照的日志，便于按周期开展合规审计 |
本页给出的参数取值均为常规建议，用于确定配置的起点。实际取值受材料形态、数据量与业务规则影响，具体问题需具体分析，建议在自有样本上实测后再定。
容易做错的三处
- 现象：调用日志中
subsidiary_business_type字段为空。原因：未在audit_log_include_fields配置中加入该字段，导致日志未采集子公司业务类型的关键信息。 - 现象：跨控股主体的Agent可查看其他主体的日志。原因：
agent_log_scope配置为global，未配置为per_holding_entity，未开启按主体的日志隔离。 - 现象：对话日志丢失，且docker启动时返回配置解析错误。原因：未将
log_retention_days的配置写入docker挂载的持久化配置文件，或配置值为负数，导致日志保留规则失效，容器重启后历史日志被清除。
怎么确认配好了
- 进入日志管理界面，筛选指定控股主体的日志，检查是否仅展示该主体的调用记录，验证日志隔离配置生效。
- 导出一条完整的对话日志，核对是否包含
holding_company_id、subsidiary_business_type等配置的必填字段，验证字段采集规则正确。 - 查看token统计面板，确认可按控股主体维度筛选统计数据，验证维度配置覆盖了主体维度。
- 检查docker挂载的配置文件，确认
log_retention_days等参数已正确写入，无语法错误，验证持久化配置生效。
问题素材取自公开社区提问（2026-09-11 去重 4,834 条）。文中的配置项名称与取值区间需以所用版本的实际界面与文档为准；本页核验日 2026-09-14，当时的最新发布版本为 FastGPT v4.17.0。