很多企业在建设 AI 知识库时最开始关注的是“能不能上传文档、能不能问答”。真正进入业务场景以后问题会变得更具体Word 文档按什么边界切Markdown 的标题层级要不要保留PDF 的阅读顺序错了怎么办扫描图片怎么做 OCRExcel 表格是按行切还是按表切切片以后怎么判断质量最后检索时是只用向量检索还是要关键词、混合检索和 Rerank这些问题决定了知识库能不能从“演示可用”走向“生产可信”。知识库的核心不是上传文件而是把不同形态的企业资料转化为可检索、可授权、可引用、可评测的知识资产。一、主流开源知识库/RAG 项目在解决什么问题从主流开源生态看知识库能力大致分为三类面向应用平台的知识库例如 Dify、RAGFlow面向开发框架的 RAG 组件例如 LlamaIndex、LangChain、Haystack面向文档解析的基础工具例如 Unstructured、Docling、Marker。项目主要定位切片/检索相关特点适合关注点DifyAI 应用平台与知识库知识库、文本分段、父子分段、问答分段、索引和检索配置应用平台内快速构建 RAGRAGFlow深度文档理解 RAG 平台DeepDoc、版面理解、表格和复杂文档解析、模板化切片PDF、表格、版式复杂文档LlamaIndex数据到 LLM 的 RAG 框架Document、Node、Node Parser、Sentence Splitter、Semantic Splitter、Retriever 体系自定义 RAG 管线LangChainLLM 应用开发框架递归字符切分、Markdown/HTML/Header Splitter、语义切分和检索器集成通用 RAG 工程开发HaystackRAG Pipeline 框架DocumentCleaner、DocumentSplitter、Embedders、Retrievers、Pipeline 编排可编排检索增强流水线Unstructured文档解析与预处理将 PDF、Office、HTML、图片等解析为结构化元素并支持 chunking多格式文档解析Docling文档转换与结构抽取PDF、Office、HTML、图片等转结构化文档关注表格、版面、OCR高质量文档转换MarkerPDF/图片转 Markdown/JSON/HTML面向 PDF、图片、表格、公式、OCR 和结构化输出复杂 PDF 结构化这些项目给出的共同启发是RAG 效果的上限首先由文档解析质量决定其次由切片策略和检索策略决定。只做固定长度切文本和单一向量检索在企业制度、合同、报表、手册和流程文件中很容易出现召回不准、引用错误、权限越界和答案不可追踪。二、不同类型文档应该如何切片不同类型文档的切片技术差异很大。企业知识库不能把所有文件都当作普通文本处理而应先识别文档结构再选择合适的解析组件、切片策略和检索策略。各类型文档解析与切片流程图下面以 RAGFlow 的 DeepDoc 和内置 chunking template 为例说明开源知识库通常如何处理复杂文档先做 OCR、表格结构识别、版面识别等解析再根据文档布局选择合适的切片模板而不是所有文档都按固定长度切分。文档类型常用开源组件/技术解析重点切片与质量控制WordRAGFlow General/Manual 模板、python-docx、Apache POI、Unstructured、Docling样式树解析、标题层级识别、段落/表格/图片元素抽取可参考 RAGFlow 的模板化切片思路按文档布局选择模板再按标题路径、自然段、条款编号、表格块切片长段再按句子或 Token 切分。MarkdownRAGFlow General 模板、LangChain MarkdownHeaderTextSplitter、LlamaIndex MarkdownNodeParser、FlexmarkMarkdown AST、标题路径、代码块、表格、列表识别按标题路径切片代码块和表格尽量整体保留技术文档写入语言、模块、标题路径等元数据。PDFRAGFlow DeepDoc、Docling、Unstructured、Marker、PyMuPDF、pdfplumberOCR、TSR 表格结构识别、DLR 版面识别、阅读顺序恢复RAGFlow 的 DeepDoc 先做视觉解析再选择 chunking template复杂 PDF 需要保留坐标、页码、表格结构和引用来源。图片/OCRRAGFlow DeepDoc、PaddleOCR、Tesseract、EasyOCR、Docling、UnstructuredOCR、版面检测、文本块坐标、置信度、表单字段识别按页面区域、字段组、表单块或票据字段切片RAGFlow 这类方案会把 OCR 和版面理解放在切片之前低置信度片段需要降权或复核。Excel/表格RAGFlow Table/QA 模板、Apache POI、EasyExcel、pandas、DuckDB、Unstructured、DoclingSheet/表头/合并单元格/单位/公式/字段类型识别按 Sheet、表格区域、行组、指标主题切片对金额、日期、状态等字段优先采用结构化检索或 SQL 查询。1. Word 文档用样式树和标题层级保护语义边界Word 文档的关键不是“抽出文字”而是把样式、标题、段落、表格、图片说明、编号列表一起解析出来。常见组件包括 python-docx、Apache POI、Unstructured 和 Docling。Java 技术栈中Apache POI 更适合读取 docx 的段落、样式、表格和嵌入对象Python 生态中python-docx、Unstructured、Docling 更常用于把 Office 文档转为结构化元素。切片时优先按标题层级建立标题路径例如“员工手册 考勤管理 请假规则”。每个切片都应带上标题路径、页码或段落编号、文档来源、更新时间、权限范围等元数据。制度、合同、手册类文档通常按条款、自然段、编号列表和小节切分段落过长时再用 SentenceSplitter、RecursiveCharacterTextSplitter 或 TokenTextSplitter 二次切分。以 RAGFlow 为例它不是让所有文件都套同一种固定长度切片方式而是提供多种内置 chunking template让用户根据文档布局和内容类型选择合适模板。Word 或制度类文档可以参考这种思路先判断它更像通用文档、问答文档还是表格文档再决定按章节、条款、问答对或表格块组织切片。Word 中的表格不能简单拼成一串文本。更好的做法是保留表头、字段、单位和所在章节把一张表作为一个或多个独立表格块处理。对于“金额超过 10 万由谁审批”这类问题表头和条件列比单个数字更重要。2. Markdown 文档用标题路径和 AST 保留技术文档结构Markdown 天然带有结构适合做知识库。常见组件包括 LangChain 的 MarkdownHeaderTextSplitter、LlamaIndex 的 MarkdownNodeParser以及 markdown-it、Flexmark 等 Markdown AST 解析器。核心思路是先解析标题、段落、列表、代码块和表格再决定切片边界。Markdown 的切片不建议只按字符长度切。标题路径应写入每个片段例如“API 文档 鉴权接口 请求参数”。代码块、配置块、表格和连续列表尽量保持完整如果必须拆分也要保留语言标识、文件名、模块名和上下文标题。对于技术文档质量保障重点是避免切断代码块、命令行示例和参数表。LangChain 的 Header Splitter 适合保留标题元数据LlamaIndex 的 NodeParser 适合把文档转为带元数据的 Node方便后续检索和引用。3. PDF 文档先做版面理解再做文本切片PDF 是知识库里最容易出问题的格式。复杂 PDF 可能包含双栏排版、扫描页、浮动页眉页脚、脚注、表格、图片和水印。常见组件包括 RAGFlow 的 DeepDoc、Docling、Unstructured、Marker、PyMuPDF、pdfplumber、PaddleOCR 等。它们解决的不是简单抽文本而是版面识别、阅读顺序恢复、表格抽取和 OCR。以 RAGFlow 为例DeepDoc 侧重复杂 PDF 的视觉文档理解。官方文档把复杂 PDF 的解析任务拆成 OCR、TSR 和 DLROCR 负责识别扫描页和图片文字TSR 负责表格结构识别DLR 负责文档版面识别。RAGFlow 从 v0.17.0 起还把 DeepDoc 的数据抽取任务和 PDF 的 chunking method 解耦意味着解析模型和切片模板可以分别选择以便在速度、精度和文档类型之间做权衡。PDF 切片通常要分三步第一步做页面结构解析识别标题、正文块、表格、图片、页眉页脚和脚注第二步清洗噪声去掉重复页眉页脚、水印和无意义空行第三步按章节、条款、页面块、表格区域或图文块切分。RAGFlow、Docling、Unstructured、Marker 这类工具的价值就在于把 PDF 转成更接近文档结构的 Markdown、JSON 或元素序列。PDF 的质量保障重点是阅读顺序和表格结构。多栏 PDF 如果阅读顺序错了切片再精细也会变成错乱文本表格如果被拆成零散行检索时容易只命中局部数字无法还原业务含义。4. 图片和扫描件OCR 切片要保留坐标、置信度和字段关系图片、扫描件、发票、合同扫描件和截图类资料入口技术通常是 OCR 和版面检测。常见组件包括 PaddleOCR、Tesseract、EasyOCR、Docling 和 Unstructured。OCR 结果不应只保留纯文本还要保留文本块坐标、行列关系、字段标签和识别置信度。这类内容切片时可以按页面区域、版面块、字段组、表单区或票据字段切分。例如发票可以按“购买方信息、销售方信息、金额税额、明细行、校验信息”组织合同扫描件可以先做 OCR再按条款编号和页面结构切片。质量保障重点是 OCR 置信度、字段对应关系和人工复核机制。对低置信度文字、扭曲扫描、印章遮挡、手写内容等应降低索引权重或进入复核流程避免错误文字被模型当作可信知识。5. Excel、CSV 和表格优先保留结构必要时走结构化查询Excel、CSV 和网页表格不是普通段落文本。常见组件包括 Apache POI、EasyExcel、pandas、DuckDB、Unstructured、Docling。解析时要识别 Sheet、表格区域、表头层级、合并单元格、公式、单位、指标口径和字段类型。RAGFlow 的内置模板化思路对表格也有参考价值表格文档不应套普通文本模板而应尽量保留表头、行列关系和单元格语义。表格切片常见方式有四种按 Sheet 切、按表格区域切、按行组切、按指标主题切。对于宽表、指标表、台账和报表不建议把所有单元格直接拼成一段自然语言可以为每张表生成摘要同时把行记录进入结构化索引或数据库。检索时金额、日期、状态、编号、客户名称等字段往往更适合关键词、过滤条件或 SQL 查询。向量检索适合解释表格含义和找到相关表但精确统计、筛选和排序应交给结构化检索链路。三、切片后的质量如何保证切片质量不是靠最后调 Prompt 解决的而是要从入库链路就开始控制。知识库切片质量保障方法图第一保证解析质量。文档解析阶段要检查编码、乱码、页眉页脚、OCR 置信度、表格结构和阅读顺序。解析错误会直接进入切片和索引后续检索很难修复。第二保证切片边界。切片不应只看长度还要看语义完整性。一个好的切片应该包含完整问题、完整条款、完整步骤或完整表格单元。对于较长内容可采用滑动窗口或父子切片既保证召回粒度又保留大段上下文。第三保证元数据完整。每个切片都应绑定来源文档、页码、章节、标题路径、更新时间、业务分类、权限范围和解析方式。元数据决定了后续能否按业务范围过滤、按权限过滤、按来源引用和按版本追踪。第四保证权限随片段流转。企业知识库不能只在文档列表上做权限控制。真正安全的做法是把文档权限、资源权限、角色范围和可见范围写入切片或索引元数据并在检索阶段严格过滤。第五保证可评测。知识库上线前要准备一批典型问题观察命中文档、命中片段、召回顺序、答案引用和响应耗时。上线后还要记录检索日志、命中统计、未命中问题和用户反馈用于持续优化切片和检索策略。四、知识库检索有哪些策略AI知识库检索策略架构图1. 向量检索向量检索适合语义相似问题例如用户用不同表达方式询问同一业务规则。它的优势是能跨表达方式召回相关内容缺点是对编号、专有名词、金额、日期等精确条件不一定稳定。2. 关键词/BM25 检索关键词检索适合精确术语、条款编号、产品型号、制度名称、字段名等场景。它不一定理解语义但对“必须出现某个词”的查询非常有效。3. 混合检索混合检索把向量检索和关键词检索结合起来既覆盖语义相似又保留关键词精确匹配能力。企业知识库中混合检索通常比单一向量检索更适合作为默认策略。4. 元数据过滤和权限过滤在召回前或召回后根据知识库、文档类型、业务域、时间、版本、部门、角色、可见范围进行过滤。对于企业级应用权限过滤不是可选项而是生产环境的基本要求。5. 父子切片检索父子切片适合“召回小片段、回答用大上下文”的场景。系统先用小切片提高召回精度再把父级段落或章节作为上下文交给模型避免答案只看到局部信息。6. Rerank 重排序初次召回后Rerank 模型或规则会重新判断问题与候选片段的相关性把更可能回答问题的片段排到前面。复杂知识库中Rerank 对答案质量提升很明显尤其适合多文档、多业务域混合检索。7. 查询改写和多路召回对于口语化问题系统可以先做查询改写、同义词扩展、业务词补全或多 Query 召回。例如用户问“报销怎么走”系统可以扩展为“费用报销流程、发票要求、审批节点、报销单填写规范”。8. 表格和结构化检索当知识来自 Excel、数据库或指标表时结构化查询可能比向量检索更可靠。平台可以把表格转为字段、指标和行记录也可以通过 SQL 或专用工具查询再把结果交给模型解释。五、企业选型时应重点看什么选择知识库/RAG方案时不建议只看“支持多少文件格式”。更应该看六个能力文档解析能力、切片策略能力、检索组合能力、权限控制能力、评测与调试能力、工程集成能力。企业知识库最终要进入业务流程、Agent、工作流和权限体系而不是停留在孤立的文档问答页面。六、智能体开发平台如何承接企业知识库场景云程智能体开发平台把知识库作为企业 AI 应用的基础能力而不是孤立的文档问答模块。平台围绕文档解析、文档切片、向量化、检索策略、权限控制、召回测试和检索日志形成完整链路。在知识入口链路中平台关注 Word、PDF、Markdown、图片、表格等多类型资料的解析、切片和索引入库并把来源、章节、文档权限、资源权限等信息随知识片段一起沉淀。在检索链路中平台支持面向 Agent 和工作流的知识检索能力可结合向量检索、混合检索、Rerank、权限过滤和引用追踪让模型回答有来源、有边界、有日志。更重要的是云程平台把知识库与 Agent 构建、工作流编排、Tool/MCP/Skill 能力调用、应用发布、权限治理和链路日志放在同一个工程化体系里。企业建设知识库的目标不只是“能问文档”而是让知识真正参与业务任务执行并且在安全、可控、可追踪的条件下服务企业 AI 应用。