文档处理框架

KMatrix 的文件处理与解释机制采用了模块化、流式处理的 ETL (Extract, Transform, Load) 架构，其核心目标是将异构的非结构化数据转化为 AI 可理解的高质量知识分块。

以下是该机制的详细拆解：

1. 核心处理机制：ETL 处理器体系

KMatrix 的文件解析并不直接在业务代码中硬编码，而是通过 EtlHandler 策略模式实现。

• 提取 (Extract)：通过 IKmFileService 实现存储抽象。无论文件是在本地服务器、阿里云 OSS 还是腾讯云 COS，系统都统一将其转换为标准输入流。
• 转换与解析 (Transform)：
  • 全能解析引擎：GenericFileEtlHandler 底层集成了 Apache Tika。这使得 KMatrix 能够原生支持数百种文件格式（PDF, Word, Excel, PPT, TXT, HTML, Markdown 等），并能自动探测文件类型。
  • 结构化定制：针对非纯文本场景，提供了专门的处理器。例如 QaPairEtlHandler 专门解析 Excel/CSV 格式的问答对，WebLinkEtlHandler 负责网页爬取内容的清洗。
• 分块策略 (Splitter)：
  • 采用 父子块 (Parent-Child) 架构：这是 KMatrix 处理策略的基础。
  • 父块 (Parent Chunk)：保留较大的文本片段（如 500-1000 字），确保召回时拥有充足的上下文语义。
  • 子块 (Child Chunk)：从父块中细分出的小片段（如 100-200 字），用于向量检索的高精度匹配。
  • 兼容singleton分块：不强制父子分块，保留了对独立分块策略的兼容。
  • 优势：在检索时，系统通过子块命中，但在生成时提供父块给大模型，完美解决了“语义碎片化”导致的理解偏差。

2. 基础设计支持

在架构设计上，KMatrix 为文件处理提供了深层的支撑：

• 职责解耦：解析逻辑（EtlHandler）与向量化逻辑（EmbeddingService）完全分离。EtlHandler 只负责“解析文本并分块”，不关心如何变成向量。这种设计使得你可以独立升级解析引擎（如引入更强的 OCR）或更换不同的向量模型。
• 配置驱动：数据集（Dataset），定义不同的文档来源、文档格式和处理策略，以及它们之间的关系；独立配置分块大小（ChunkSize）、重叠度（Overlap）以及处理策略，满足不同垂直领域对知识粒度的要求。KMatrix 的知识存储架构是： 知识库 (Knowledge Base) -> 数据集 (Dataset) -> 文档 (Document) -> 分块 (Chunk)
• 异步流水线：文件处理通常是耗时的。KMatrix 将 ETL 过程设计为后台异步任务，通过状态机管理“上传-解析-分块-向量化”的完整生命周期。

3. 扩展性 (Extensibility)

KMatrix 的设计高度强调可扩展性，方便开发者进行二次开发：

• 新增处理器 (New Handlers)：如果你需要支持特殊格式（例如解析 CAD 图纸或解析特定的行业 XML），只需实现 EtlHandler 接口并注册为 Spring Bean，系统会自动根据数据集类型路由到新的处理器。
• 解析引擎可插拔：虽然默认使用 Apache Tika，但你可以轻松地为 PDF 引入专门的解析器（如 PDFBox 或基于 AI 的布局分析工具），只需替换 DocumentParser 的实现即可。
• Metadata 增强：ChunkResult 对象支持 Map 形式的元数据扩展。你可以很方便地在解析阶段加入文件名、页码、作者、关键词甚至是自动生成的摘要，这些信息都会被持久化并用于后续的 RAG 过滤。
• OCR 预留：在 GenericFileEtlHandler 中已经预留了对 Tesseract OCR 的配置接口，开发者可以通过开启配置，实现对扫描件 PDF 或图片的文字识别支持。

总结：KMatrix 的文件处理机制是一套以“父子块策略”为核心、以“策略模式”为骨架、以“Apache Tika”为引擎的高扩展系统，既能满足开箱即用的通用需求，也为垂直领域的深度定制留足了空间。