这个品类的数据长什么样
多元金融投研数据主要来自公开行业研报、上市公司定期/临时公告、私募产品净值数据库、监管政策文件及第三方行业数据集。数据更新节奏差异较大，行业研报按周/日更新，上市公司公告实时披露，监管文件随政策发布更新。单篇文档长度跨度大，短则数百字的监管通知，长则数万字的深度研报。文档字段包含产品代码、披露日期、核心财务指标、投资评级等，部分数据集附带标准化数值单位，如年化收益率、管理规模等指标。
这些特征在「对话日志与审计」这一环带来什么约束
单篇文档长度跨度大，导致对话上下文拼接后生成的会话日志长度差异显著，需适配不同长度的日志分片存储规则，避免单条日志超出存储上限。数据更新频率不均，对话中引用的最新研报、公告需关联准确的时间戳，审计环节需验证日志中引用数据的发布时间与实际披露时间的匹配性，确保投研依据的时效性。多源数据混合引用的场景下，日志需完整记录数据来源标识与字段信息，便于回溯投研结论的原始依据。标准化数值字段与非标准化文本共存，审计时需同时校验数值单位的一致性与文本内容的合规性，符合监管对投研过程可追溯的要求。
配置怎么定
| 配置项 | 建议取法 | 这样取的依据 |
|---|---|---|
LOG_STORAGE_RETENTION_DAYS | 30–90 天 | 多元金融投研审计周期通常覆盖1-3个月，满足合规回溯要求 |
MAX_SESSION_CONTEXT_LENGTH | 8000–16000 字符 | 适配长研报、公告类对话的日志存储，避免会话内容被截断 |
ONEAPI_CALL_LOG_ENABLE | 开启 | 同步记录OneAPI调用大模型的请求、返回及错误信息，便于排查投研对话生成异常，该参数在v4.9.7版本中正式上线 |
LOG_CLEANUP_MAX_RECORDS | 100000 条 | 控制单数据库实例的日志存储总量，避免数据库负载过高，可根据实际存储容量调整 |
PG_CONNECTION_TIMEOUT | 60 秒 | 避免日志存储时因PostgreSQL连接超时导致日志丢失，适配多源数据批量写入场景 |
AUDIT_DATA_SOURCE_VERIFY | 开启 | 自动校验对话日志中引用的投研数据来源、时间戳与原始数据源的一致性，满足审计合规要求 |
本页给出的参数取值均为常规建议，用于确定配置的起点。实际取值受材料形态、数据量与业务规则影响，具体问题需具体分析，建议在自有样本上实测后再定。
容易做错的三处
- 现象：docker-compose启动时，aiproxypg容器异常退出，日志显示连接超时或端口占用。原因：未正确配置`PGCONNECTION_TIMEOUT`参数，或未预留PostgreSQL数据库的默认端口，导致日志存储链路异常。
- 现象：对话日志存储超出预设上限后，新会话日志无法写入，或旧日志被误删。原因：未根据投研审计周期调整
LOG_STORAGE_RETENTION_DAYS参数，或未设置合理的LOG_CLEANUP_MAX_RECORDS阈值。 - 现象：OneAPI调用大模型失败后，无法在对话日志中查看到错误详情。原因：未开启
ONEAPI_CALL_LOG_ENABLE参数，导致调用链路日志未被同步存储。
怎么确认配好了
- 访问系统日志管理界面，随机抽取近7天的投研对话日志，确认每条日志均包含会话ID、发起时间、引用数据来源标识及完整交互内容，审计字段无缺失。
- 执行docker-compose up -d命令，查看容器运行状态，确认aiproxy_pg容器无异常退出日志，数据库连接链路正常。
- 发起一次包含公开研报引用的对话，触发大模型调用，查看OneAPI调用日志模块，确认请求参数、返回结果及错误信息均被完整记录。
- 手动触发一次日志清理任务，确认符合预设阈值的旧日志被按规则归档或删除，验证清理配置生效。
问题素材取自公开社区提问（2026-09-11 去重 4,834 条）。文中的配置项名称与取值区间需以所用版本的实际界面与文档为准；本页核验日 2026-09-14，当时的最新发布版本为 FastGPT v4.17.0。