场景先行
先确定用户、问题范围、允许回答内容和转人工边界,再决定导入哪些资料。


先确定用户、问题范围、允许回答内容和转人工边界,再决定导入哪些资料。
记录来源、负责人、版本、生效日期、适用范围、保密等级和更新周期。
过期、重复或相互矛盾的内容先由业务确认,不能交给模型自行选择事实。
检查标题、章节、表格、扫描件和分段结果,确保依据完整且可以核验。
访问控制应覆盖原文件、检索、回答、接口、导出、日志和备份。
用真实问题检查检索、答案、引用、拒答和权限,并持续记录错误原因。
同一批企业资料用于客服、销售、内部培训、售后排障或管理制度查询时,问题范围和风险不同。先选一个高频且边界清楚的场景,列出使用人、常见问题、允许回答的内容和必须转人工的情况。
场景越模糊,资料越容易无边界扩张。试点阶段可以先覆盖一个产品线或一个部门,确认实际价值和风险后再增加资料、用户与系统接口。
每份资料至少记录名称、来源部门、内容负责人、文件类型、版本、生效日期、适用产品或地区、保密等级和更新周期。无法确定负责人或有效性的文件,不应直接作为正式回答依据。
将产品手册、价格政策、合同条款、售后规则、操作流程、培训资料和客服记录分开管理。不同类型的资料可以相互补充,但不能让聊天记录或个人笔记覆盖已经确认的正式制度。
同一产品如果存在多个版本,应明确当前有效版本、历史版本和替代关系;同一问题如果不同部门答案不一致,应先由业务负责人确认统一口径。系统无法替企业决定哪个冲突事实才有效。
重复文档不一定增加可靠性,反而可能让检索结果混入旧内容。删除无独立价值的副本,保留必要历史记录时应标注失效状态,并限制其用于当前业务回答。
标题应说明文件解决什么问题,正文使用清晰章节、完整表头、明确单位和必要上下文。扫描件、复杂表格、图片参数、页眉页脚和跨页内容需要先测试解析结果,不能只因为系统显示上传成功就认为信息已经可用。
RAG系统通常会把文档拆分后检索相关片段。IBM公开资料指出,不合适的固定切分可能在表格或语义中间截断信息,导致不完整或不准确回答。因此需要按文档结构检查分段、表格和上下文是否被正确保留。
公开产品信息、内部流程、客户资料、价格底线、合同和核心技术不能使用同一访问范围。应按用户、部门、角色和场景控制检索与回答权限,并记录重要访问和变更。
权限不仅存在于最终对话界面,也要覆盖原始文件、索引、导出、接口、日志和备份。使用外部模型或SaaS时,还要确认数据传输、存储位置、保留周期和供应商责任。
从客服、销售、培训和业务记录中整理真实问题,覆盖正常问法、简称、条件组合、跨文档问题、无答案问题和权限边界。每题保存标准依据,分别检查检索到了什么、回答是否准确、引用是否对应以及该拒答时能否拒答。
上线后记录未命中、错误依据、过期答案、权限异常和人工纠正,再回到资料、检索、提示规则或业务流程定位原因。每份关键资料都应有负责人和复查周期,避免系统长期引用已经失效的信息。
先确定业务场景和使用人,再建立资料目录,逐份标注来源、负责人、版本、生效日期、适用范围和保密等级。清理重复、过期和冲突内容后,检查文档解析与分段,最后用真实问题验收。
问题可能发生在原始资料、文档解析、分段、检索、回答规则或权限。应先查看系统实际找到了哪些片段,再判断是资料里没有答案、找错依据,还是模型没有正确使用依据,不能只调整提示词。
是否支持某种格式要看具体系统,显示上传成功也不代表内容解析完整。扫描PDF、复杂表格、跨页内容、图片参数和公式尤其需要抽样检查解析结果,并保留原始来源用于核验。
不应依赖AI自行判断企业内部哪个版本有效。应由内容负责人确认当前口径,标注有效版本和替代关系,并限制历史或失效资料参与正式回答。
没有统一周期。价格、库存、活动和政策可能需要高频同步,产品手册和制度则按业务变化更新。关键是每类资料都有负责人、触发条件、复查日期和失效处理方式。
猪运赢可围绕业务场景、资料目录、权限边界、真实测试题、知识库选型、试点验收和持续维护协助梳理。具体资料范围、系统接口、部署方式和安全责任以双方确认的方案为准。