这个品类的数据长什么样
供应商审计的研发文档主要包括审计报告、不符合项清单、纠正预防措施（CAPA）记录、变更控制文档、供应商资质证明、质量协议以及生产工艺流程文件等。这些文档的来源通常是供应商提交的报告、现场审计记录以及内部质量管理系统。更新节奏相对固定，一般遵循年度审计周期或特定事件触发（如重大变更、不符合项关闭）。文档结构呈现半结构化特征，包含大量自由文本描述、表格数据和嵌入式图片。字段方面，常见的有审计日期、审计员、供应商名称、不符合项编号、风险等级、整改计划、完成日期等，单位则主要涉及时间单位、数量单位和风险评级。
这些特征在「引用来源与溯溯」这一环带来什么约束
供应商审计文档来源多样性和半结构化特点，对引用来源的准确解析提出了较高要求。审计报告中的关键结论可能分散在多个段落甚至不同文档中，这就要求系统在引用时能够精准定位到原始信息点，并提供上下文。更新频率相对固定，意味着知识库需要定期进行增量更新或全量重索引，以确保引用的时效性。文档中包含的表格数据和自由文本混合，使得传统的文本分块策略可能不足以有效捕获关键信息，从而影响溯源的粒度。此外，某些特定字段（如风险等级 riskLevel、整改计划 correctionPlan）的语义理解，直接关系到引用内容的相关性和准确性，要求系统能深入理解业务逻辑。
配置怎么定
| 配置项 | 建议取法 | 这样取的依据 |
|---|---|---|
分段长度 | 800–1200 字符 | 兼顾审计报告中长段落的完整性与短句的语义独立性 |
召回条数 | 前 8 条 | 覆盖多源信息点，避免遗漏关键审计发现和整改措施 |
相似度阈值 | 0.75 | 确保召回内容与审计查询意图高度相关，过滤低质量引用 |
重排返回条数 | 前 5 条 | 提升最终返回引用的质量与相关性，聚焦核心信息 |
maxContext | 3000 Tokens | 适应审计文档中复杂上下文的需求，提供更全面的背景 |
PARSE_FILE_TIMEOUT_SECONDS | 600 秒 | 应对大型审计报告或包含复杂表格的文档解析耗时 |
容易做错的三处
- 现象：模型输出的审计结论引用了不相关的供应商资质文件。 原因：知识库分段策略未能有效隔离不同供应商或不同审计周期的信息，导致相似度计算时发生混淆。
- 现象：调用对话接口时，返回的
detail字段中缺少知识库id或文件id信息。 原因：系统未正确配置流式输出或异步处理，导致引用元数据在传输过程中丢失或未被包含。 - 现象：模型针对某个不符合项的整改计划无法提供溯源，或溯源指向的原文不包含具体计划。 原因：文档解析时未能识别并提取包含整改计划的特定字段或表格行，导致知识库中缺乏该信息。
怎么确认配好了
- 针对典型审计场景，通过模拟提问，检查模型返回的引用来源是否精准指向原始审计报告、CAPA记录或质量协议中的具体段落。
- 检查
detail字段或日志输出，确认每次对话引用的知识库id和文件id均有返回，并且能通过这些id定位到对应的原始文档。 - 随机抽取模型输出的引用片段，手动核对原始文档，确保引用内容与原文表述一致，且无语义偏差。
- 对包含复杂表格或多层级标题的审计文件进行测试，验证系统能否正确解析表格内容并将其关联到相应的引用来源。
问题素材取自公开社区提问（2026-09-11 去重 4,834 条）。文中的配置项名称与取值区间需以所用版本的实际界面与文档为准；本页核验日 2026-09-21，当时的最新发布版本为 FastGPT v4.17.0。