AWS高级解决方案架构师黄海波：GenAI 时代非结构化数据处理的实践与趋势洞察

在接到这个分享主题之前，我一直在思考 GenAI 时代非结构化数据处理这个课题。就个人经历而言，我并未选择学术道路，而是更多专注于软件工程领域的应用实践。由于我所在的团队聚焦于 AWS 生态，我们的工作也更多围绕生态层面展开。

我今天分享的内容核心会聚焦在数据处理的应用落地实践上。首先，我会聊聊非结构化数据这一话题，以及其处理过程中的技术理念；接着分享两个我在工作中与客户共同完成的实践案例；最后，谈谈非结构化数据的未来趋势及我个人的一些思考。

根据 MIT Sloan的研究，在企业的全部数据资产中，非结构化数据占比约 80%，部分企业甚至更高。这类数据在企业数据资产中占比极高，若能有效盘活企业内部的非结构化数据，对企业的信息化进程与数字化转型而言，都具有重要意义。非结构化数据有诸多特点。如前面提到的，多模态数据中大部分都属于非结构化数据，涵盖文件、音频、图像等多种形式。那么，这些数据的核心特征是什么？我们又该如何借助大模型对其实现高效生成，乃至最终的有效执行？

在企业场景中，非结构化数据既没有固定格式，也缺乏配套的数据模型。这使得非结构化数据的处理工作极为复杂，检索与查询也面临很大挑战。

在利用非结构化数据时，我们会遇到不少挑战，主要集中在这几个方面：数据格式多样、没有明确的结构关系、存储分散，检索查询困难。

比如常见的非结构化数据，像图像、Word 文档、PDF 文件这些，它们自身的结构关系并不清晰。这和我们设计系统时处理结构化数据的情况完全不同 ，做结构化数据时，我们会先做数据建模，梳理出核心的实体，再给这些实体设定相应的属性。这个梳理和定义的过程，其实就是把非结构化数据转化为结构化数据的关键步骤。结构化数据最终会存入数据库进行操作，整个处理流程也有很多成熟的标准。

举个例子，在数据库领域，结构化数据有明确的应用场景和成熟的检索方法来提高效率；但非结构化数据在这方面，不管是处理标准还是检索逻辑，都还没有清晰的定义。

结合我自己的经验，非结构化数据的处理其实有个发展过程。

早期做非结构化数据处理时，大多靠关键词搜索或者规则匹配。我以前做研发，现在更偏向应用场景，比如大家日常检索数据，其实就是非结构化数据向结构化数据转化的一种体现。那时候的检索处理很直接：一个需求就得编一套规则，而且只能应对简单明确的查询。

后来机器学习发展起来，我们开始琢磨：能不能用模型来处理文本？比如要对文本做简单分类，是不是可以用样本数据训练模型？这样一来，就算是领域外的其他数据，也能做类似处理，不用再写那么多规则。

机器学习再继续发展，就出现了一些更前沿的模型。比如处理图片时，我们先标注图片内容来训练模型，之后模型就能自己识别图片里的内容并做标注了。

到了生成式 AI 阶段，大规模预训练模型开始进入大众视野，之后各种基础模型（FM）也陆续出现。其实这些模型在架构上差异不大，但参数量和训练数据的体量却在急剧增长，最终形成了语言、图像等不同类别的大模型。而这两年多模态大模型兴起后，不同模态的模型开始呈现融合趋势，这一点我在后面的案例讲解中也会具体提到。

传统非结构化数据处理存在不少局限性，具体可以从这几个方面来看：

一是过度依赖定制化规则与特征实现。要获取数据时，不同类型的数据需要用不同的规则来处理，这些规则往往不统一，还需要额外协调适配，难以覆盖语言的多样性，灵活性很低。

二是标注成本居高不下。传统 NLP 方法通常需要人工标注大量样本，用来训练分类器或序列标注模型，不仅耗费大量人力物力，标注过程本身也很繁琐，成本高。

三是泛化能力弱。在某个场景下完成数据标注和模型训练后，一旦场景发生变化（比如数据分布、业务需求调整），模型就难以适配，往往需要重新标注数据、调整模型，复用性很差。

四是多模态数据形成 “孤岛”。早期处理视频、音频、文字等多模态数据时，核心难题是如何让它们之间实现融合 ， 这些数据往往各自独立，缺乏有效的联动机制。不过这两年，多模态融合的趋势已经逐渐显现，而且越来越明显了。

五是实时性与可扩展性不足。传统的流水线式和批量处理方式，在面对大规模非结构化数据时响应很慢，很难满足实时分析和快速决策的需求，扩展性也跟不上业务增长。

接下来我们聊聊，生成式 AI 能为非结构化数据处理带来哪些改变。这里有两张图，展示的是传统机器学习模型与主流预训练模型的差异。

就像我刚才提到的，传统机器学习模型在处理非结构化数据的分析时，其实还处于比较早期的阶段。我把时间主要放在案例实际应用中上，这样大家会有直观的认识。我简单列了一下我想到的场景，实际的应用场景远不止这些。

这是一个医药行业的真实案例：很多药企在销售药物时，会通过多种渠道进行售卖， 比如药店、医院、经销商等。为此，企业搭建了一套数据流向系统，专门用于追踪和分析药物的销售路径，明确每批药物是通过哪个渠道最终到达消费者手中的。

收集这些流通环节的数据，对企业后续的运营至关重要：基于这些数据，企业可以开展生产计划优化、仓储管理升级、供应链协同等多维度的数据分析与预测，从而提升整体运营效率。

不过，目前这套系统存在一个明显的低效环节：从各渠道收集到的 “流通证据” 大多是非结构化数据。比如常见的 Excel 表格，里面的数据格式往往不规范，如果直接用简单的规则将这些数据存入数据库，后续很难对其进行有效分析，也难以通过数据认证来确保信息的准确性。

当时我们协助他们开发的一个产品，核心是围绕 “机构” 展开的。这里的 “机构” 指的是他们的各类售卖渠道，只是暂时统一用这个名称来指代。但问题在于，这些渠道的信息记录很不统一。举个具体的例子：上海市第九人民医院，在数据里的名称就各式各样，有时写作 “九院”，有时是 “上海第九医院”，还有其他不同的表述，但实际上都指向同一家医院。

这种情况下，如果不做数据清洗，这些数据的价值会大打折扣， 因为基于这样的数据得出的结果，很可能不符合预期，甚至出现错误。因此，他们在前期必须进行数据清洗。那么，他们采用的清洗方式是什么呢？

他们的清洗手段其实很直接，主要靠匹配方法。具体来说，他们有一个全国标准的机构信息数据库，清洗时就用传统的匹配算法，把数据里的机构名称和数据库里的标准名做比对匹配。但这种匹配方式问题不少。比如 “九院”，全国叫这个简称的医院有很多，甚至有的会写成数字 “9 院”，算法很难准确区分，结果就是匹配完还得靠大量人力来审核、校对、修正。我们对比过这个环节优化前的情况：匹配准确率还不到 60%，即便匹配完，还是得投入大量人力做复审，而且复审效率特别低。

后来大模型兴起后，我们建议他们试试用大模型的语义理解能力来优化， 借助模型对语义的深层理解，既能减少人工复审的压力，也能让数据清洗更精准。所以当时我们设计了一套简单的外部架构方案：基于原有数据构建一个简易知识库，让所有经过清洗的数据，最终都能精准指向标准的机构信息。

这个方案的效果很明显：匹配准确率从原来的不到 60% 大幅提升至 95%，同时处理效率提高了 50%。更重要的是，原本花在数据清洗上的员工，现在可以转去做其他更有价值的工作，对团队整体效能来说也是很大的提升。

这就是当时用的一个简单架构。不过，医药企业对合规性的要求比较高，他们不愿意调用外部模型， 因为外部调用很难满足他们的合规标准。所以我们的方案做了两方面调整：一方面，用企业现有的数据对模型做了一轮调优；另一方面，也针对性调整了我们的模型。毕竟这个领域有很多专业内容，模型如果不专门优化，可能理解不到位，输出的结果自然也不够好。

为此，我们还做了两次数据清理。最终形成的架构大概是这样：不仅对他们原有的订单模型做了调整，还对嵌入的数据重新做了优化。通过这些调整，最终达到了我们预期的效果。

Amazon

第二个案例，是我们和另一家客户合作的。这是一家电商公司，从 2016 年就开始做 VOC相关的业务，这个场景在产品销售的后端其实非常重要。现在很多客户会通过电商平台、抖音、小红书这些渠道购买商品，买完之后可能会在社交媒体上发表评论，或者如果在使用中遇到问题，也可能直接在电商平台上和客服沟通。对企业来说，收集这些反馈里的负面信息并分析，不管是对产品迭代还是服务优化，都有很大帮助。

但这里有个问题：这些数据大多是非结构化的，比如用户的评论、对话记录，很难直接丢给大模型就得到能用的结果。我们最终还是得在结构化数据的基础上做进一步分析。

举个例子，我们需要明确一条评论是正面还是负面；如果是负面，还要区分是对产品本身不满，还是对物流配送、售后服务不满。所以必须通过一些手段给这些数据分类、打标签，后续的分析也都是基于这些标签化的结构化数据展开，最后才能得出有价值的结论。

在这个过程中，打标签是个核心功能。这家公司 2016 年成立时，还没有大模型，他们就用传统 NLP 的方式做标签化：先对大量客户数据做人工标注，再用这些标注数据训练 NLP 模型，然后用模型处理新数据。但这就带来了一个问题：每个客户的产品不同，单一模型很难通用，比如 A 客户的模型，很难直接用到 B 客户身上。所以当时他们得维护几百个模型，专门用来做标签分类（PPT 左侧就是他们原来的做法）。

前年 ChatGPT 3 出来的时候，我们跟他们聊起这件事，提出能不能用大模型这种具备强大语义分析能力的工具来解决小模型的局限。所以当时就想到，用大模型来解决打标签的问题。

图片右侧是我们和他们一起商量出的解决方案，其实就是基于大语言模型（LLM）的方案。做 POC 的时候，我们试着用标签让大模型通过简单对话来打标。打标效果还算可以，准确率大概在 80%-90%，但还不够理想。其实直接用大模型，对照我们的需求给一段评论或对话打标，准确率也差不多是这个水平。但当时考虑到成本问题：客户的标签体系很复杂，分了二级、三级，要是把这么复杂的标签体系全作为上下文传给大模型处理，成本会很高。

后来我们想了个办法：把历史标注数据和现有标签数据整合起来，做成一个类似知识库的东西。之后在处理新的对话、进行打标时，会先做一轮 “召回”， 也就是查找历史记录里有没有类似的评论，看看当时给这些评论打的是什么标签。把这些相似评论和对应标签找出来后，再交给大模型，让它在这个限定范围内选择合适的标签进行标注。

这个方案在开发过程中，准确率就达到了 90% 以上。后来我们又做了优化：针对可能有问题的标签，增加了人工审核环节，审核起来效率很高。就这样，他们最终采用了这种模式，替代了原来需要维护几百个模型的旧方式。

我简单梳理一下这部分的思考：多模态 AI 会逐渐成为主流：面对不同模态的数据，可能只需要一个模型就能解决你想解决的问题。根据 Gartner 的预测，到 2027 年，大概 40% 的解决方案都会支持多模态。

不过，另一方面，可能有人会觉得未来会有一个超强大的模型 “一统天下”，但我们公司内部并不这么认为，没有哪个模型是万能的，能解决所有问题。

从我个人经验来看，通用模型的训练数据大多来自公开资源，或者是花钱购买的部分内部数据。但很多企业的内部数据，其实并没有被纳入大模型的训练中。尤其是在垂直领域或特殊行业，这些未被大模型训练过的内部数据，会导致通用模型在这些场景下的表现并不好，当然，这一问题未来可能会通过各种技术手段逐步解决。

我们认为，在医疗、金融等垂直领域，如果企业想让内部的非结构化数据得到有效处理（甚至转化为结构化数据），可能需要在现有基础模型（FM）的基础上，针对性训练出专业模型。这样做的核心目的之一，是降低模型的 “幻觉”。

大模型比如 ChatGPT，往往需要通过 API 接口调用，这背后其实存在数据隐私与安全方面的挑战。

另外，实际场景中，很多客户的真实数据量并不多，而用少量数据去训练大模型，很难达到理想效果。所以我们会帮客户基于他们的业务场景合成数据，再通过反馈机制或强化学习的方式，让模型逐步理解该领域内的知识体系。

此外，安全审计、输出内容过滤这些环节也需要持续强化，尤其在安全合规要求高的业务场景中，这些都是必不可少的。