人人都会AI编程

半结构化数据：Markdown、HTML、JSON、Excel

更新时间：2026-07-12

在实际业务场景中，知识并不总是以规整的纯文本形式存在。大量信息被存储在 Markdown、HTML、JSON 或 Excel 这类半结构化数据里——它们既包含自然语言内容，又夹杂着标记、键值、表格等结构信息。RAG 系统需要妥善处理这些格式，否则检索和生成的质量将大打折扣。下面逐一介绍这四种常见类型的处理方法与注意事项。

Markdown

特性与场景

Markdown 是技术文档、内部 Wiki、README 等最常见的编写格式。它以少量标记符号（如 #、**、-）来表示标题、加粗、列表等结构，内容本身仍以可读的纯文本为主体。

处理要点

  • 保留层级信息：标题层级（#, ##）通常对应文档的章节结构。在切分（chunking）时，可将标题作为元数据附加到对应内容片段上，帮助检索时按章节过滤或提升相关度排序。
  • 去除格式噪音，但别丢掉语义：移除多余的星号、链接语法等纯标记，但要将链接文本保留或将重要链接的 URL 以自定义格式注入片段。例如将 产品规格 处理为“产品规格（参见 docs/spec.md）”，既保留了文本语义，也提供了可追溯路径。
  • 代码块处理：Markdown 中的代码块通常不属于自然语言问答的核心内容，但包含重要的技术细节。可整体保留并加长对应 chunk 的长度，或单独切为独立片段。

一个真实例子

某公司内部 Wiki 用 Markdown 撰写运维手册。原始内容是：

## 日志查询

在 `Kibana` 中使用以下查询：
`error: 500`

直接按段落切分可能丢失标题信息，导致检索到该片段时不知道其上下文。更好的做法是在嵌入时将该段标记上来源标题“日志查询”，这样当用户搜索“错误日志查询方法”时，匹配度更高。

HTML

特性与场景

HTML 广泛存在于内部网站、帮助中心、电子说明书等场景。它包含大量用于渲染的标签、样式和脚本，内容隐藏在标签之间。

处理要点

  • 提取正文而非保留标签：嵌入模型对 HTML 标签的理解往往不佳，需先用 BeautifulSoup、trafilatura 等工具提取纯文本内容，去除 <div>、<span>、<script> 和 <style>。
  • 利用语义标签：<h1>～<h6> 可像 Markdown 标题一样转化为层级信息；<table> 标签需特别注意，表格数据如果直接转成文本行列，含义可能丢失，可尝试将表格转为 Markdown 表格格式或结构化 JSON 后再嵌入。
  • 保留链接等关键属性：若回答需要引用原文链接，提取文本时可将 <a href="..."> 的链接地址以 链接文字 的形式保留，同样可保留 <img> 的 alt 文本。

实用建议

对于批量处理大量 HTML 页面，推荐使用 “先提取主要内容 + 再分块” 的两步流程。例如先通过trafilatura提取文章正文，屏蔽页眉页脚导航等无关内容，再对该纯净文本进行分块和向量化。

JSON

特性与场景

JSON 常用于存储结构化记录，如产品信息库、API 响应、配置数据等。每个字段具有明确的含义，但字段名和值之间的语义关系需要被翻译成自然语言才能被大模型有效利用。

处理要点

  • 平铺为可读描述：将 JSON 对象转成平铺的键值对列表或段落，例如 {"name":"X200","memory":"16GB"} 可转为“产品名称：X200；内存：16GB”。避免直接嵌入原生 JSON，因为 LLM 对压缩格式的语义理解不如自然语言稳定。
  • 保持字段级元数据：如果某个 JSON 条目代表一条结构化知识，可将关键字段值作为元数据存储，方便检索时按条件过滤（如按产品类别、价格区间）。
  • 处理嵌套和列表：适度递归展开，但不要过度拖长 chunk。可将数组展开为“支持的颜色：银、深空灰”，而不是保留原始数组语法。

真实例子

一个电商知识库用 JSON 存储 SKU 信息：

{"sku": "A123", "name": "蓝牙耳机", "battery_life": "8小时", "price": 299}

处理后可转为：“SKU A123，蓝牙耳机，电池续航8小时，售价299元”。用户查询“续航久的耳机”时，该片段更容易被检索和解读。

Excel

特性与场景

Excel（或 CSV）是业务人员最常用的数据存储形式，通常包含多行多列的表格，例如价格清单、配置表、问题集等。

处理要点

  • 按行/按逻辑块切分：根据表格规模选择策略。若每行独立意义（如一条产品记录），可按行转化为文本段落；若是宽表（一个条目跨多列），需确保同一行的各列在同一个 chunk 内。
  • 将列名融入文本：每行数据应带上列名以让模型理解字段含义。例如“产品型号：X200，内存：16GB”要远比“X200，16GB”明确。
  • 处理合并单元格和复杂表头：需先通过预处理将合并单元格展开、多重表头拉平为一行标准字段名，否则生成的信息对模型而言歧义极大。
  • CSV 一样适用：处理逻辑相同，只是解析工具不同。

工具使用

Python 的 pandas 可以轻松读取 Excel 或 CSV，然后逐行生成文本。对于大型表，可按行数（如一次取 20 行作为一个 chunk）批量转换成 Markdown 表格，在提示词中直接呈现给 LLM 做表格推理。

通用原则总结

处理半结构化数据时，可以遵循几条通用准则：

  1. 内容与元数据分离：结构标记/键名等作为元数据保留，用于过滤或排序，但给嵌入模型的输入应主要是自然语言。
  2. 保持语义单元完整：无论哪种格式，都不要在一个字段、一个表格行或一个列表项的中间切断，最小单元即为一个完整的语义块。
  3. 可溯源：转换后必须在 chunk 元数据中记录来源格式和原始位置，方便再投影回原文档。
  4. 针对问答场景优化表述：在将结构化内容转为自然语言时，可以有意识加入常见问题的关键词（如将“RAM:16GB”扩展为“内存 16GB”），让检索更容易命中。

通过上述方法，这些半结构化数据可以像纯文本文档一样被 RAG 系统高效利用，真正让企业内各类型信息资产发挥出统一查询和问答的效力。