企业官网建设流程全解析

很多企业在建设 AI 知识库时，最开始关注的是“能不能上传文档、能不能问答”。真正进入业务场景以后，问题会变得更具体：Word 文档按什么边界切？Markdown 的标题层级要不要保留？PDF 的阅读顺序错了怎么办？扫描图片怎么做 OCR？Excel 表格是按行切，还是按表切？切片以后怎么判断质量？最后检索时，是只用向量检索，还是要关键词、混合检索和 Rerank？

这些问题决定了知识库能不能从“演示可用”走向“生产可信”。知识库的核心不是上传文件，而是把不同形态的企业资料转化为可检索、可授权、可引用、可评测的知识资产。

一、主流开源知识库/RAG 项目在解决什么问题

从主流开源生态看，知识库能力大致分为三类：面向应用平台的知识库，例如 Dify、RAGFlow；面向开发框架的 RAG 组件，例如 LlamaIndex、LangChain、Haystack；面向文档解析的基础工具，例如 Unstructured、Docling、Marker。

这些项目给出的共同启发是：RAG 效果的上限首先由文档解析质量决定，其次由切片策略和检索策略决定。只做固定长度切文本和单一向量检索，在企业制度、合同、报表、手册和流程文件中很容易出现召回不准、引用错误、权限越界和答案不可追踪。

二、不同类型文档应该如何切片

不同类型文档的切片技术差异很大。企业知识库不能把所有文件都当作普通文本处理，而应先识别文档结构，再选择合适的解析组件、切片策略和检索策略。

各类型文档解析与切片流程图

下面以 RAGFlow 的 DeepDoc 和内置 chunking template 为例，说明开源知识库通常如何处理复杂文档：先做 OCR、表格结构识别、版面识别等解析，再根据文档布局选择合适的切片模板，而不是所有文档都按固定长度切分。

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 和 DLR：OCR 负责识别扫描页和图片文字，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 应用。