DTP 药房研发文档结构化解析的对话日志与审计

这个品类的数据长什么样

DTP 药房（Direct to Patient）的研发文档主要来源于药厂提供的药品说明书、临床试验报告、药理毒理研究、不良反应监测报告以及药师日常经验总结。这些文档更新频率相对稳定，通常在药品上市审批、说明书修订、临床数据更新时进行，周期可能从数月到数年不等。文档结构以 PDF、Word、结构化数据库导出文件为主，内容包含大量专业术语、剂量单位（如 mg/kg、IU）、药代动力学参数（如 Tmax、Cmax）、适应症、禁忌症、用法用量等字段，且常涉及表格与图表。部分文档可能包含手写批注或扫描件。

这些特征在「对话日志与审计」这一环带来什么约束

DTP 药房研发文档的特点对对话日志与审计提出了特定要求。首先，文档的专业性和严谨性要求对话日志必须精确记录每次查询的完整上下文，包括用户输入的专业术语、系统召回的知识点以及最终生成答案。其次，更新频率相对较低但关键性高的特点，意味着审计需能追溯到特定知识点在不同版本文档中的变化，并关联到具体对话。此外，日志中必须能区分不同药师或患者角色的查询，以满足合规性要求。大量专业字段和单位的存在，要求日志能准确捕获并展示这些信息，避免因单位混淆导致的误解。扫描件和手写批注的存在，可能导致文本识别错误，需要在日志中标记潜在的识别问题。

配置怎么定

配置项	建议取法	这样取的依据
`logLevel`	`INFO`	记录详细的查询流程和结果，便于问题追溯，避免信息冗余。
`maxContext`	`2000 字符`	确保捕获完整查询意图及关键上下文，覆盖DTP文档中较长的专业描述。
`logRetentionDays`	`365 天`	满足药品监管的长期审计要求，支持年度合规性审查。
`auditUserIdentifier`	`用户ID`	精确区分不同药师或系统用户的操作，满足合规审计的用户追溯需求。
`responseLogThreshold`	`500 字符`	记录系统生成的完整答案，确保答案的准确性和完整性可供复核。
`metadataFields`	`文档版本, 药品名称, 来源机构`	便于按业务维度对日志进行筛选和分析，快速定位特定研发文档的查询。

容易做错的三处

对话记录中缺少关键的药品剂量单位或药代动力学参数，原因是没有正确配置内容解析器，导致这些专业字段在结构化过程中丢失。
无法追溯特定用户对某一药品说明书的查询历史，原因是用户身份识别机制未与企业内部认证系统正确集成，导致 auditUserIdentifier 字段为空或不准确。
在查看历史对话时，思考过程或中间推理步骤未显示，原因是代理服务或RAG工作流的日志级别设置过低，未捕获到详细的推理过程信息。

怎么确认配好了

随机抽取多条包含专业术语和计量单位的查询，检查对话日志中是否完整记录了用户输入、系统召回内容以及生成的答案，并核对关键字段（如 用法用量、不良反应）的准确性。
模拟不同用户身份进行查询，然后检查日志中的 auditUserIdentifier 字段，确认能够正确区分并记录操作用户。
选择近期有更新的研发文档进行查询，对比日志中记录的 文档版本 或 更新时间 元数据，确保与实际文档版本一致。
执行一些复杂查询，尤其涉及多文档召回的场景，检查日志中的 metadataFields 是否能准确反映所有召回文档的来源信息。

问题素材取自公开社区提问（2026-09-11 去重 4,834 条）。文中的配置项名称与取值区间需以所用版本的实际界面与文档为准；本页核验日 2026-09-21，当时的最新发布版本为 FastGPT v4.17.0。