父子块切分演示知识库.md 12 KB
企业知识库 RAG 系统操作与服务手册
一、知识库建设目标
企业知识库 RAG 系统用于集中管理公司内部的产品资料、员工服务流程、技术支持规范和常见问题。过去这些资料分散在网盘、邮件、项目群和个人电脑中，员工遇到问题时往往需要反复询问同事，或者打开多个文件进行查找。知识库系统将这些内容统一导入，经过文本切分、向量化和索引后，员工可以直接用自然语言提问。
知识库回答问题时，不是简单地把整本手册发送给大模型，而是先从大量文档中检索与问题最相关的内容。为了让检索更加准确，系统会把较大的文档切分成适合保存上下文的父块，再把父块切分成更短的子块。子块用于相似度搜索，父块用于补充完整语境。这样既能避免每次检索返回过多无关内容，也能减少答案缺少上下文的问题。
知识库中的每份文档都应该有明确的主题、稳定的标题层级和完整的段落。建议使用一级标题表示文档名称，二级标题表示业务模块，三级标题表示具体流程或问题。段落之间保留必要的空行，不要把多个完全无关的主题连续写在同一个段落中。
二、文档导入与格式要求
系统支持 Markdown、TXT、PDF、Word、PPT、PPTX、JPG 和 PNG 等文件类型。Markdown 和 TXT 文件适合保存结构清晰的制度、流程和产品说明；PDF 和 Office 文件适合保存已经排版完成的正式手册；图片文件通常用于识别截图、扫描件或现场设备标签。导入前应检查文件是否能够正常打开，以及文字是否存在乱码。
Markdown 文档建议使用 UTF-8 编码保存。文件名应包含能够表达主题的名称，例如“售后服务流程.md”“员工账号管理.md”或“产品部署手册.md”。不要使用“最终版”“最终版2”“最新版本”这类容易失控的名称，建议在文档中写明版本号、负责人、生效日期和过期日期。
导入程序会递归扫描指定目录下的文件。它先读取文件扩展名，再从文件类型映射表中选择对应的加载器。TXT 文件会显式按照 UTF-8 编码读取，Markdown 文件使用 Markdown 加载器，PDF、Word、PPT 和图片文件使用相应的解析或 OCR 加载器。加载成功后，系统会把来源名称和文件路径写入文档元数据，方便后续追踪答案来自哪个知识库文件。
如果文件无法加载，程序会记录警告日志并继续处理其他文件。常见原因包括文件扩展名不在支持列表中、文件权限不足、文件编码错误、PDF 内容是不可识别的扫描图片，或者文件本身已经损坏。处理导入异常时，应先根据日志定位具体文件，不要直接删除整个知识库目录。
三、员工账号与权限管理
员工登录知识库后，可以根据权限访问不同的资料范围。普通员工通常可以查询员工服务、办公系统和通用产品资料；技术支持人员可以访问故障排查、部署手册和内部解决方案；产品经理可以维护产品规格、版本变更和发布说明；管理员负责配置数据源、检查导入任务和处理权限申请。
账号权限应遵循最小权限原则。员工只应看到完成工作所必需的资料，涉及客户合同、内部报价、生产密钥和安全事件的文档不能默认开放给所有用户。权限发生变化时，应由部门负责人提交申请，管理员核对申请人身份、所属部门、访问范围和有效期限后再执行变更。
员工离职、转岗或长期休假时，应及时回收或调整账号权限。对于临时项目成员，可以创建带有明确过期时间的临时权限，不建议直接复制长期员工账号的全部权限。每次权限变更都应保留操作记录，包括操作人、操作时间、变更前权限、变更后权限和变更原因。
四、知识库检索流程
用户提问后，系统首先对问题进行预处理，包括清理多余空格、识别问题中的关键词和判断可能涉及的业务领域。随后，系统使用向量检索查找语义相近的子块，也可以结合关键词检索、BM25 检索或其他排序方式提高召回效果。多个检索结果会按照相似度和业务规则进行排序。
例如，用户提问“生产环境部署失败后应该收集哪些信息”，系统可能会召回“故障排查流程”中的部署环境、错误日志、复现步骤和影响范围，也可能召回“生产故障升级规范”中的客户影响和紧急程度要求。单个子块可能只包含其中一部分内容，因此系统需要根据子块携带的 parent_id 找到对应父块，再使用父块补充完整的流程上下文。
检索结果不能只看相似度最高的一条。相似度最高的内容有时只是某个关键词的局部匹配，未必能够完整回答问题。系统可以保留多个候选子块，再根据来源文件、标题层级、版本号和发布日期进行过滤。对于同一主题的多个版本，应优先使用生效时间最新且状态为正式发布的文档。
如果检索结果为空，系统不应编造答案。更合适的处理方式是提示用户没有找到足够依据，并建议用户补充产品名称、版本号、故障现象或所属部门。对于涉及生产故障、数据安全和权限变更的问题，还应提示用户联系对应负责人。
五、产品发布与版本管理
产品文档应按照产品名称、主要版本和发布日期进行归档。每次正式发布前，产品团队需要确认功能说明、配置要求、兼容性说明、升级步骤和回滚方案是否完整。对于已经停止维护的版本，应在文档中明确标记维护状态和最后支持日期，避免员工误把旧版本操作步骤用于新版本环境。
版本变更说明至少需要包含变更原因、影响范围、配置变化、数据库变化、接口变化和验证结果。如果新版本修改了默认配置，应同时说明旧配置是否仍然兼容。对于需要人工执行的升级步骤，应给出执行顺序、预计耗时、风险点和失败后的恢复方式。
产品问题关闭后，应将最终解决方案沉淀到知识库，而不是只留在聊天记录中。解决方案应说明问题表现、影响版本、根本原因、临时处理方法、长期修复方法和验证结果。如果同一问题在不同环境下表现不同，应分别记录操作系统、部署方式、依赖组件和相关日志特征。
六、故障排查与升级规范
收到客户或内部员工的故障反馈后，一级支持人员首先要确认产品版本、部署环境、故障发生时间、影响用户数量、错误提示、复现步骤和最近一次变更。信息越完整，后续定位越快。不要只记录“系统不能用”或“接口报错”，应尽量保留原始错误信息、请求参数、响应状态码和相关日志片段。
初步排查可以按照“确认现象、缩小范围、检查依赖、验证修复”的顺序进行。确认现象时，需要判断问题是全部用户都能复现，还是只有某个账号、某个租户或某个网络区域受到影响。缩小范围时，可以比较正常环境和异常环境的版本、配置、资源使用率和最近变更记录。
如果问题涉及数据库连接，应检查连接地址、端口、账号权限、连接池状态和数据库健康情况。如果问题涉及缓存，应检查缓存服务是否可访问、关键键是否存在以及是否出现大面积过期。如果问题涉及向量检索，应检查向量数据库连接、集合名称、索引状态、嵌入模型配置和查询结果数量。
当一级支持无法在规定时间内解决时，应升级给对应产品线支持组。升级单必须包含问题标题、客户影响、紧急程度、产品版本、部署环境、故障现象、复现步骤、已经尝试的方案、相关日志和期望解决时间。紧急生产故障需要同步值班负责人，并持续更新处理进展。
七、数据更新与索引刷新
知识库文档更新后，需要重新执行导入和索引流程，才能让新的内容参与检索。更新前应确认文件名称、版本号和生效日期，避免把草稿文件与正式文件同时放在同一数据目录中。对于大批量更新，建议先在测试目录验证文件能够正常加载和切分，再执行正式刷新。
刷新过程通常包括读取文件、切分文档、生成嵌入向量、写入向量数据库和更新相关缓存。切分阶段会先生成父块，再根据每个父块生成子块。每个子块会保留自己的内容、来源文件、父块 ID、父块内容和唯一 ID。向量数据库主要保存子块向量，但子块元数据中的父块信息用于检索后的上下文恢复。
如果某个文件已经删除或替换，刷新流程应同步处理旧数据，不能只追加新向量，否则旧版本仍可能被检索出来。生产环境执行刷新前，应确认目标集合、数据来源和备份情况。刷新完成后，需要检查导入文件数量、父块数量、子块数量以及若干典型问题的检索结果。
在刷新过程中出现异常时，应优先查看失败文件和错误日志。单个文件解析失败不一定意味着所有数据都不可用，但如果向量写入过程被中断，应确认事务或批量写入状态，避免出现只有部分数据更新成功的情况。正式环境的刷新操作应记录开始时间、结束时间、操作人、文件版本和最终统计结果。
八、常见问题与处理建议
问题一：为什么搜索结果与用户问题看起来相关，但回答仍然不完整？可能原因是子块太短，只包含了一个步骤或一句定义，没有携带完整上下文。可以检查子块对应的 parent_id 和 parent_content 是否正确，并确认回答阶段使用了父块内容，而不是只使用子块正文。
问题二：为什么同一个问题召回了旧版本和新版本两份答案？可能是旧文档没有从索引中删除，或者文档元数据中缺少版本号和生效状态。处理时应清理旧版本数据，并在检索排序中优先选择正式且最新的版本。
问题三：为什么中文 TXT 文件导入后出现乱码？通常是文件实际编码与读取时指定的 UTF-8 不一致。应确认文件保存编码，并在统一转换为 UTF-8 后重新导入。不要只修改文件扩展名，因为扩展名不会改变文件实际编码。
问题四：为什么 Markdown 标题没有出现在检索结果中？需要检查 Markdown 文件是否使用规范的标题语法，例如使用 #、## 和 ###，并确认加载器没有在解析阶段丢失标题。标题是重要的上下文信息，应该尽量保留在父块和子块内容中。
问题五：为什么修改了知识库文件，问答结果却没有变化？修改本地文件并不会自动修改向量数据库中的旧数据。必须重新执行导入、切分、向量化和索引刷新流程，并确认缓存已经针对当前知识库完成失效处理。
九、服务联系与记录要求
日常使用问题可以先查看员工服务手册和系统操作指南。产品使用问题应联系对应产品线支持组，部署和故障问题应提交包含完整上下文的服务单，权限和数据访问问题应联系管理员。涉及生产环境的紧急问题，不要只在普通群聊中留言，应按照值班流程电话或即时通知负责人。
所有服务单在关闭前都应填写最终处理结果。处理结果不能只写“已解决”，还应说明实际原因、执行过的操作、验证方式和后续预防措施。能够复用的解决方案应同步沉淀到知识库，并由文档负责人确认标题、版本、生效范围和适用环境。
知识库的价值不只是让系统能够回答问题，更重要的是让组织中的经验可以被持续复用。高质量的文档、明确的版本管理、完整的故障记录和可追溯的检索来源，都会直接影响 RAG 系统最终回答的准确性和可信度。