What the data for this category looks like
Yield and market data for investment platforms primarily comes from stock exchanges, fund registration and settlement institutions, and the platform’s own transaction database. Data updates strictly follow the trading day cycle. Full daily data is refreshed after each trading day closes. Each data entry includes fields such as trading date, product unique identifier, unit net value, cumulative net value, daily return rate, interval return rate, etc. Units include percentage, Chinese yuan, and product shares. High-frequency market data is pushed at minute-level intervals, but only daily closing summary data is required for daily report broadcasting scenarios.
What constraints do these characteristics impose on "conversation logs and auditing"?
The trading day update cycle requires conversation logs to be archived by trading day, to avoid mixing cross-day data. The multi-field, multi-unit structure requires audit logs to fully record request parameters, returned fields, and corresponding units for each conversation call, to prevent audit deviations caused by unit conversions. The timeliness of market data requires logs to retain the request initiation time and data return time, to verify during audits whether the data is the compliant version for the corresponding trading day. Conversation content in investment scenarios involves information related to trading decisions. Audit logs must retain the full context chain, including user questions, recalled market data snippets, AI-generated broadcast content, and associate corresponding product identifiers and dates, to meet compliance and traceability requirements.
How to set the configurations
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
enableAuditLog | Enabled | Financial scenarios mandate that conversation operations are auditable, so full audit log recording must be enabled |
logRetentionDays | 90 days | Financial compliance requirements mandate that conversation logs be retained for at least one full accounting cycle. 90 days covers quarterly audit needs |
auditLogIncludeFields | ["request_time", "product_code", "return_rate", "unit", "user_id", "chat_id"] | Must cover audit-required fields including time, product identifier, core data fields, user and session identifiers, to ensure traceability |
maxContext | 8000–12000 token | Investment scenarios require retaining full recalled market data context and user questions, to avoid missing audit links due to truncated context |
mongodbWriteTimeoutMS | 5000 milliseconds | Market data updates frequently. This ensures log writes to the database do not time out or block, preventing log loss |
chatHistoryIsolation | Isolate by user | Investment platform user data is sensitive. This ensures conversation logs and audit records from different users cannot be accessed across accounts, meeting data security requirements |
The parameter values provided on this page are common starting points for configuration. Actual values are affected by material form, data volume, and business rules. Specific issues require individual analysis. It is recommended to test on your own samples before finalizing settings.
Three common mistakes
- Phenomenon: MongoDB write timeout occurs after a conversation call, and the log reports a
slow operation xxxxmserror. Cause: ThemongodbWriteTimeoutMSconfiguration is not set to match the duration required for batch writes of market data, causing audit log write blocking. - Phenomenon: Chat records are not archived by trading day, and cross-day data is mixed in the same session log. Cause: Log archiving rules are not configured based on the
logRetentionDayscycle dimension, and classification storage is not performed using associated trading date fields. - Phenomenon: Some conversation logs are not written to the database after the client interrupts the SSE connection. Cause: A reasonable threshold for
sseConnectionTimeoutis not set, and log persistence logic for session interruptions is not configured, causing incomplete write operations to be lost.
How to confirm the configuration is correct
- Log in to the FastGPT backend log management page, filter session records for the corresponding trading day, and check if the preset audit fields are included, to confirm field completeness.
- Initiate a conversation request with product code and yield data, view the MongoDB
fastgpt_chat_logscollection, and verify that the log includes request time, user identifier, and session ID, and that the write time meets the configuration requirements. - Switch to different accounts to initiate conversations, check their respective chat history pages, and confirm that session records from other accounts cannot be viewed, to verify that the isolation configuration is effective.
- View system runtime logs, confirm there are no error messages about ungenerated audit logs, to verify that the
enableAuditLogconfiguration is properly enabled.
Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-09-14.