这个品类的数据长什么样
医保准入相关的研发文档数据主要来源于国家医保局、各省市医保局官方网站发布的政策文件、药品目录调整通知、谈判准入结果、支付标准文件以及企业提交的申报材料。这些数据更新频率较高，国家层面通常是年度或半年度调整，地方层面则可能根据实际情况不定期发布补充通知。文档结构以非结构化和半结构化为主，包括 PDF 格式的政策原文、Word 格式的申报模板、以及部分 Excel 格式的药品清单。核心字段包括药品通用名、剂型、规格、适应症、支付范围、支付标准、谈判结果、生效日期、截止日期等，单位涉及金额（元）、数量（盒/支/片）、百分比（%）等。
这些特征在「对话日志与审计」这一环带来什么约束
医保准入研发文档高频的更新节奏要求对话日志系统能够准确记录每次文档更新后的解析与RAG过程，确保审计时能追溯到特定时间点的知识状态。文档中复杂的非结构化与半结构化特点，使得解析结果可能存在歧义或错误，对话日志需要详细记录用户对解析结果的修正、疑问及系统提供的原始依据，以便后续评估解析模型的准确性。多样的字段与单位，特别是支付标准这类敏感信息，对日志的完整性与安全性提出了更高要求，需要确保在日志中明确标识和保护。此外，对谈判结果、生效日期等时效性强的字段，日志需要支持按时间维度进行高效检索与分析，以应对医保政策快速变化的挑战。
配置怎么定
| 配置项 | 建议取法 | 这样取的依据 |
|---|---|---|
logRetentionDays | 365 天 | 医保政策变更周期长，历史数据对审计和分析有价值。 |
maxMessageLength | 2000 字符 | 医保政策原文复杂，确保完整记录用户提问和系统回复。 |
enableRawDocumentLogging | true | 记录RAG过程中召回的原始文档片段，便于追溯知识来源。 |
auditLogGranularity | full | 详细记录每次交互的输入、输出、中间步骤与模型调用信息。 |
tokenUsageThreshold | 1000 tokens/次 | 监控模型资源消耗，及时发现异常调用模式。 |
sensitiveDataMaskingPatterns | 正则表达式列表 | 针对支付标准、企业内部代号等敏感信息进行脱敏处理。 |
容易做错的三处
- MongoDB 数据库中的对话记录占用空间过大，导致查询效率下降，原因是没有定期清理过期的日志数据。
- 用户删除对话后，相关的日志记录也随之消失，审计时无法追溯历史操作，原因是应用未将用户前端操作与后端日志持久化机制解耦。
- 工作流中设置的聊天记录上下文长度为 1，但实际对话仍关联到很久以前的历史记录，原因是RAG召回机制或系统默认上下文策略覆盖了工作流的单次设置。
怎么确认配好了
- 随机选择一批医保准入相关的对话记录，检查其
logRetentionDays是否符合预期，确保历史记录未被过早删除。 - 模拟用户进行包含敏感信息的提问与回复，查看
sensitiveDataMaskingPatterns是否生效，确认敏感数据在日志中已正确脱敏。 - 通过系统后台查询特定时间段内医保准入应用的
tokenUsageThreshold消耗记录，验证统计数据与实际模型调用情况是否一致，并根据历史趋势设定合理阈值。 - 随机抽取多条对话日志，检查
enableRawDocumentLogging字段，确认召回的原始文档片段是否完整记录，且与实际RAG过程中的召回内容一致。
问题素材取自公开社区提问（2026-09-11 去重 4,834 条）。文中的配置项名称与取值区间需以所用版本的实际界面与文档为准；本页核验日 2026-09-21，当时的最新发布版本为 FastGPT v4.17.0。