结构化数据与非结构化数据：为什么拆分会误导客服团队

• 本文用客服场景的例子，说明结构化、半结构化与非结构化数据的区别，指出二元划分的价值与误用，并给出以决策为核心的做法：为高频决策建立字段，为叙述性内容标注负责人与复核日期，把重复流程变成引导式流程。

客服团队打开看板，往往能立刻得到一个整齐的答案：各队列的工单量、占比最高的账单类问题、逐渐拉长的处理时长。可当有人追问“为什么账单类电话特别耗”时，看板却给不出任何解释。答案其实藏在通话录音、在线聊天记录和客服备注里，而这些内容都无法塞进一个表格字段。

这个场景把“结构化数据与非结构化数据”的差别浓缩在一个画面里，也解释了为什么几乎所有数据指南都从这个分类讲起。本文将用呼叫中心熟悉的例子，界定结构化数据与非结构化数据，并进一步提出一个不那么常见的观点：这种二元划分适合做初步归类，却不适合作为行动方案。

结构化数据与非结构化数据：标准定义

维基百科将非结构化数据定义为：没有预定义数据模型、或游离于预定义组织结构之外的信息。结构化数据恰好相反，它存在于字段之中，每个值都属于某个在数据产生之前就已定义好的类别。IBM 的指南补充了它在实践中的结果：结构化数据可以放进关系型数据库或数据仓库的行与列，而非结构化数据通常以原生格式存放在数据湖或非关系型存储中。

什么是结构化数据？

在客服场景里，它指的是工单编号、产品、队列、解决代码、时间戳和处理时长。每个值都有明确的字段名和固定的类型，因此一次查询就能统计出结果，报表也能跨月呈现趋势，无需任何人逐条阅读工单。

什么是非结构化数据？

它涵盖客户输入的文本、通话录音、客服留下的备注，以及错误截图。数据库无从判断一条事实在哪里结束、下一条又从哪里开始。

什么是半结构化数据？

大量数据落在两者之间。IBM 把中间这一类称为半结构化数据：没有固定模式，但标签或元数据赋予了它一定的形态。

维度	结构化	半结构化	非结构化
形态	固定字段与类型	标签或键值，结构灵活	无预定义模型
客服示例	工单记录、CRM 字段	带时间戳的聊天日志、来自 API 的 JSON	通话录音、邮件正文、客服备注
容易回答的问题	每个队列有多少工单？	哪些对话提到了退款？	客户为什么生气？
难点	前期定义字段	保持标签一致	提取含义本身

最后一行点出了整场讨论的核心：一方难以设计、却易于查询；另一方几乎不费成本就能产生，却要付出高昂的理解代价。

把非结构化数据当成问题，这一观点站得住脚吗

这种普遍看法最强有力的版本是这样的：组织数据大部分没有模式，分析工具只能读取其中的结构化部分，于是最大的那堆数据里，藏着无人采集的价值；只要把这堆数据转换好，洞察自然浮现。

这一看法往往还附带一些数字，其中流传最广的是“非结构化数据占企业数据的 80%”。维基百科将其追溯到美林证券 1998 年的一份声明，并指出该数字的确切来源并不清楚。其他文章把比例推向 90%，并归功于分析机构，但原始报告都藏在付费墙之后。任何具体百分比都应只当作数量级来参考，因为没有谁真的像人口普查那样测量过它。

不过，趋势本身并无争议。录音转写、文档、消息和录音的堆积速度，远快于任何人填写表单的速度。对于依靠对话运转的呼叫中心而言，这堆数据尤其庞大。

二元划分说对了什么

有两点值得肯定。其一，数据类型决定了哪些工具能够处理它：SQL 查询读不了通话录音，而用语音模型去统计工单数量又大材小用。其二，这种分类迫使团队如实盘点结构化与非结构化数据；把资产分成两栏之后，团队往往会发现非结构化素材比自己以为的多得多。

因此，这种二元划分值得出现在最初的讨论里。麻烦出现在它被当成行动方案的时候。

二元划分在哪里误导客服团队

以一个事实为例：某位客户为同一笔订单付了两次款，它同时存在于四个地方。

工单记录显示：类别“账单”，子类别“重复扣费”，状态“已解决”。这属于结构化数据。
通话转写记录了客户在周二看到两笔扣款、周五来电，并且此前已尝试过在线聊天。这属于非结构化数据。
客服备注写着“退款已批准，客户对等待时间不满”。它很短，但仍是非结构化数据。
政策文章写明：超过一定金额的重复扣费需要主管审批。它同样是自由文本，却带有一个负责人和一个复核日期。

没人会说这四样东西是不同的东西。它们从四个角度描述同一件事，而每个角度回答的问题各不相同：工单说明频率，转写说明原因，备注呈现客服的决定，文章则说明公司允许怎么做。

把结构化数据当作“干净的那一半”会带来损害。一名疲惫的客服在交班时从下拉菜单里随手选的工单类别，看起来是结构化的，却常常是错的。反过来，一篇精心编辑的排障文章没有任何模式，读起来却完全准确。结构描述的是容器，它与容器里内容的可靠性无关。

客服团队中的结构化与非结构化数据示例

下表整理了客服团队实际拥有的各类资产。

资产	类型	团队今天能用它做什么
工单字段	结构化	统计、分析趋势、路由、生成报表
聊天日志	半结构化	按关键词搜索，按时间和渠道筛选
通话录音	非结构化	转写为文本后再分析
知识文章	非结构化，带元数据	检索、关联、按周期复核
SOP（标准作业流程）	非结构化，含有序步骤	遵循、审计、转换为引导式流程

注意最后两行。文章和 SOP 按定义都没有模式，却比任何录音都更容易被团队管理，因为有人给它们加了标题、负责人和复核日期。也就是说，薄薄一层元数据，就把一个文件变成了系统可以管理、筛选、路由，并在无人使用后予以淘汰的对象。这与“数据与信息之别”是同一个道理：价值来自上下文，而非模式。

非结构化数据的代价，最终落在搜索上

如果一半数据的查询成本极低，另一半的阅读成本极高，那么最终账单会以“时间”的形式送达。关于这笔账单的研究，来自知识工作领域整体。

Gartner 于 2023 年对 4,861 名数字工作者的调查显示，47% 的人难以找到完成工作所需的信息。APQC 在 2021 年对 982 名知识工作者的调查给出了成本数字：每周有 2.8 小时花在查找或索取信息上。麦肯锡 2012 年关于社交技术的报告则发现，互动型员工每周将近 20% 的工作时间用于搜索，而一套可检索的知识记录能将这段时间缩短最多 35%。

这些研究都没有比较结构化数据与非结构化数据。它们衡量的是“可查找性”，而可查找性取决于团队如何标注、归属和组织内容，与其格式无关。一千篇标签规范的文章，胜过一万个无人治理的文件。

最有力的反驳：把一切结构化，其余交给 AI 阅读

一个公允的反驳者会说：整个问题都是暂时的；随着模型进步，结构化与非结构化数据的划分终将淡出。语言模型阅读自由文本的能力已经足够好，标注不再重要——只要把它指向通话转写和共享网盘，然后提问即可。

这话有一部分成立。IBM 将检索增强生成（RAG）和聊天机器人文本分析列为非结构化数据的主要用途，说明相关技术确实存在，团队也的确能在原始转写中发现无人能提前定义的规律。

但当答案必须准确时，局限就显露出来了。一个读到三个互相冲突的退款政策版本的模型，会把三者都总结一遍，却不知道哪一版才是现行有效的。检索质量取决于审批状态、归属关系和最近一次复核的日期。因此，正是赋予内容结构的元数据，决定了团队能在多大程度上信任 AI 层。Baklib 的 AI 对话这类能力，也只有在内容带有清晰的审批状态、归属与复核日期时，才能给出可信的答案。模型降低了阅读非结构化数据的成本，却无法指出其中哪一部分具有权威性；而一个流畅给出的错误答案，比一个缓慢的正确答案代价更大，因为客户没有理由去怀疑它。

另一方面也有实实在在的成本。增加结构需要投入精力，而一支匆忙给所有内容打标签的团队，往往打得很糟，因为疲惫的人只会挑最接近的标签，然后赶去处理下一张工单。一个产品稳定的小型团队，靠普通文档加一个好的搜索框就能运转很久。只有当业务量或变化速度超出人们能记住的范围时，这笔投入才开始产生回报。

按决策来结构化，而非按数据类型

对结构化与非结构化数据修正后的立场其实很短：先问业务反复做出哪些决策，再为这些决策补充所需的结构，其余内容保持原样。一个持续发生的决策，值得拥有一个字段；一个一年只做两次的决策，配上一段说明和知情者的姓名就够了。

对客服团队而言，这可以落到四个动作。

为负责路由与衡量工作的字段建立结构。 类别、产品、解决代码和结果。字段列表要足够短，让客服无需猜测就能填写。
为叙述性内容标注负责人、主题与复核日期。 通话转写只需要关联到对应工单，别的几乎都不用；而文章必须有一个负责人，因为一篇过时的文章比一篇缺失的文章更糟。
把重复出现、带分支的流程变成引导式流程。 当某个决策取决于通话中收集到的回答时，一棵交互式决策树能把结构放在客服需要它的位置，一次只问一个问题。
让判断保持非结构化。 那种“这通电话正走向取消”的感觉不符合任何模式，用辅导去触及它，比用表单更有效。

这块领域属于隐性知识。

格式的选择遵循同样的逻辑。一篇文章、一份 SOP 和一棵决策树，可以用不同强度的结构承载同一个事实，而恰当的结构强度取决于读者正在做什么——这正是关于显性知识的那篇文章所探讨的。

工具在什么情况下才有价值

几十篇文章的负责人和复核日期，用一张电子表格就能追踪；但超过几百篇之后，就需要有人来强制落实。知识库软件会记录负责人、有效期和使用情况，并显示客服实际打开过哪些条目，从而把复核精力投向流量最高的地方。Baklib 正针对这一场景：它把文章、SOP 和决策树统一收进一个受治理的知识管理系统，嵌入客服的工作流，并能通过帮助中心把权威内容直接开放给客户自助查阅。当然，其他平台也在做类似的事。真正重要的是，复核循环能否在无人记得启动它的情况下自动运转——一旦这个循环依赖人的记忆，它就会在产品发布占满负责人日程的那一周停摆，直到某位客服把一条已经退役的政策引用给一个比谁都清楚的客户，才有人发觉。