1、关于数据的分类分级
数据分类分级属于日常工作中的常规事项。回顾以往,主要依赖人工对数据进行打标,众所周知该方式存在诸多问题,为提升效率和准确性,很多企业或机构都引入了数据资产管理平台或者说是数据应用能力平台,借助平台集成资产盘点、数据分类梳理、原数据接入、构建数据资产清单、信息检索等相关功能。
同样平台确实优化了流程和资源的规整,但数据资源的处理层面依旧依赖人工对数据表的标注,或者说规则学习仍耗时费力,需要持续培训,然而技术人员的理解差异,字段注释仍旧不能完全规范,也不确定,导致分类分级的准确性较差,同时人工处理效率较低,也无法满足大规模数据处理的需求。
面对不断新增的数据内容和数据分类分级高要求,能否尝试试利用大模型进行服务,首先,大模型对规则和文档具有强大的理解能力,自然性的适合处理此类任务。
2、简单处理步骤
针对测试用例,面对抽取的数据内容,基于分类分级的规则做向量化,并存储在向量数据库中作为知识库。同时,引入Prompt 工程,对工作进行提示词的规范化编写,以便控制大模型的输出结果,也能输出一个标准的参照结果。
而以往检索则依赖固定的关键字进行模糊匹配,在引入大型语言模型后,数据检索体验明显提升。大模型能够自动生成元数据的中文描述,精确查找相关信息,不用繁琐的预选择和预处理。
当实现数据的分类分级后,则可利用大型语言模型就对应的商品或服务进行全面打标,模型会根据商品或服务的名称及详细描述,智能生成多个相关标签,当然也可以手工进行调整,匹配具体应用服务的场景项。在此过程中,不代表大模型能完全智能化,结合用户与服务事项的交互行为,需要结合实际的人工权重将标签按合理地分配给用户,使得每个用户都拥有丰富且个性化的标签集合,从而细化用户与服务之间的向量关系,从而精准推荐,该过程中虽然存在人工辅助,但较以往而言,效率已有明显提升。其关键的特点在于,小众用户的测试则可推导出对应特点属性的用户群体,从而实现群体化匹配与推荐。
相对而言,针对数据处理需求,主要是利用大模型对知识和问题的理解能力。借助模型的智能技术来判断用户数据分层分级过程中风险,通过工具代理、任务切分、记忆管理、分析反馈和总结输出各模块协同,对处理流程进行多步判断,以更准确地识别问题。更为便捷的是,基于大模型产生的处置思路和处置建议等,为技术人员提供清晰的参考指导,在步骤或标签规范角度还是起到了积极的作用。
3、问题分析
初期容易产生过度期望,因为大模型的超凡能力导致大家都期望在一次对话中能解决所有问题,预想这是一个强大的数据能力治理与分析系统,数据功能模块又能快速的融合大型语言模型,实现数据聚合、复杂Prompt和丰富的Tools调用。
反观,该期望对大模型能力的要求非常高,实际上大模型的能力确不尽人意,也侧面反应出大模型的服务能力仍然需要提升,其次在处理大量token需要大模型具有思维链能力,在实际过程中存在局部处理的问题,暂时无法形成思维能力而拼接或联动上下游内容,无法进行链式输出,导致对人员的理解要求再次提升,需要编写结构非常复杂、内容庞杂的规则集,在原基础上进行规则引导,这种方式不仅导致复杂度增加,同时也会影响到平台功能融合的稳定性,又得重新基于业务构建工作流,并对任务进行分解编排和多次调用尝试。
基于筛选数据的场景服务匹配,服务后的业务数据在大模型的回溯中,效果不明显,业务场景化需求,能否被处理优化后进行知识库,从而继续反哺大模型能力,可能因场景效果或数据量问题,暂时不明显。感觉对于规模相对较小且需求多变的状态而言,微调的成本与效率并不十分契合,相反微调的技术需要与时效成本更好,不如直接通过RAG实现,直接调用历史信息或向量知识库。
通过融合调用,大模型直接用于判断,将执行直接推导到工作流进行处理,如大模型只用负责理解问题并判断需要调用哪些工具和工作流。其次,只用负责观察工具调用的结果,并生成数据分析结论,并判断是否需要再次调用工具,问题是否被解决,生成最终回复。
大模型的监测和判断其实还有个好处,即解决没有注释和标志的字段信息,引导补充并增强数据层级的价值性,同时循环扫描也有利于数据信息安全的体系的构建。