共计 2812 个字符，预计需要花费 8 分钟才能阅读完成。
更多 LDP+AI 场景细节，敬请期待 5 月 10 日（明天）的 Tapdata 发布会。
最近几个月，AI 畛域堪称经验了近十年以来最为魔幻且不堪设想的时刻。
自 ChatGPT 公布以来，无论是底层大模型、训练框架、利用框架还是 GPT 插件等等各种新构想和产品层出不穷，为各行各业带来了粗浅的改革和前所未有的时机。
AI 大模型在面向通用常识的智能畛域曾经展现出弱小的能力，其普适性和泛化能力开始被认可。越来越多的企业开始把眼光投向了 AI 技术，而在这个畛域中，高质量、可信赖的数据集是企业是否胜利利用 AI 技术的要害。
对于企业而言，坐拥的大量丰盛且独特的外部数据资源，无疑是 AI 模型训练的“人造养料”，可能为之提供更精确、个性化的训练素材，并从中获取独特的 AI 能力。如果能在这场浪潮中把握住本身数据资源的微小后劲，抢占 AI 先机，这将对晋升企业竞争力至关重要。
那么问题来了，企业该如何充分利用外部数据资源，为 AI 大模型提供更有价值的公有数据集？上面让咱们一起联合几个简略的示例，来具体谈一谈。
一、抓住问题外围：孤岛旧患「缠身」，如何无效开掘企业外部公有数据
遗憾的是，企业外部这些极具价值的公有数据通常扩散在各种简单的零碎中，无论从技术角度还是平安角度，它们都很难在通用 AI 的训练阶段被采集到，这显然十分不利于企业的 AI 利用的落地。
长期以来困扰着企业的数据孤岛问题，再一次成为企业倒退特色 AI 路上的一大妨碍。企业外部的数据扩散在各个系统、部门和业务中，一方面是数据流转不畅，难以真正整合与共享；另一方面，没有一个对立的视图和规范，导致同一份数据被多个业务部门别离存储，数据反复、冗余，难以保证数据的品质和一致性。
因而，如何无效地整合并利用这些公有数据也成为以后的一个热点话题。
二、LDP 与 AI 的碰撞：企业数据集成、治理与服务在 AI 日常利用中的交叉点
事实上，Tapdata 也始终在继续开掘人工智能这样的翻新场景，而孤岛问题也恰好是 LDP 攻破的重点方向，因而，二者的联合堪称顺其自然。
Tapdata LDP 的核心理念
信息化时代，企业外部收集大量业务数据，这些数据扩散在各个数据源以内，如何高效地集成与治理这些数据也就成了企业迫切需要解决的问题。而 Tapdata LDP 实时数据集成与服务平台正是为了满足这些需要而诞生的。
LDP 的全称是 Live Data Platform，其中，Live 的含意为“实时的、陈腐的”，数据的实时精确正是其外围卖点，针对不同的数据类型，Tapdata 反对应用日志解析、轮询或者触发器等各种伎俩进行实时数据的采集。
Platform 则意味着 LDP 不仅仅是一个简略的数据传输工具，除了提供实时的数据通道之外，它还具备数据源信息的智能治理，针对不同数据类型的托管存储以及各种上游服务的对接能力。在上游服务对接方面，LDP 既能够将数据间接传输到各种各样的数据指标以内，还能够把数据公布为传统的数据 API 服务，或是将这些陈腐的数据提供到 AI 大模型服务中，为 AI 大模型提供企业公有数据的认知能力。上面咱们将通过几个简略的例子来展示 LDP 将如何在 AI 利用中提供的这些能力。
+ AIChat：为企业公有 AI 对话模型供数
如上图所示，咱们在 ChatGPT 对话模型中输出了 3 个问题，因为 AI 大模型具备肯定的数学推理和计算能力，相似于“1+ 1 等于几”这样的通用问题，解决起来没有压力。但另外两个与 Tapdata 相干的发问，给出的答案却和咱们预期的后果相去甚远。
造成这个后果的起因有二，其一是海内的大模型服务，对中文材料的学习获取相对而言并不欠缺，会有很多内容缺失；再就是这几个问题还还波及到了很多目前在公开网络上无奈获取的内容，属于企业内的公有常识。
那么如何能力让 AI 对话服务实现咱们想要的成果呢？
这就须要咱们向对话模型提供企业公有数据集加以训练，比方公司外部的大量 wiki 材料中，就藏着这类问题的正确答案。
以飞书文档为例，Tapdata 反对以飞书文档作为源，获取其中的文本内容，读取外部 wiki 中的数据并解决后，即可依照指标接口要求把数据传输至 AIChat，一个基于 ChatGPT 的对话服务。在这个过程中，数据源和指标都是以插件模式为 LDP 提供反对的，开发者和用户能够依照本人的服务接口特色很快地开发属于本人的连接器。
于是，通过将飞书文档的内容以文本语料的模式提供给 AI 对话服务，通过 Tapdata LDP 的【数据指标和服务层】跳转到 AI 对话的服务界面，咱们在这里胜利实现了想要的 AI 问答成果：
Tapdata 在企业公有 AI 对话模型的训练场景下，具备以下三点劣势：
- 数据的传输管道能够放弃秒级的数据更新，用户材料变更时能够实时反馈到对话模型中；
- 反对上游对接各种服务，一键构建公有 AI 服务，老本非常低；
- 针对不同的数据起源，能够通过平台能力做对立治理，十分合乎企业外部的应用模式。
由此可见，在 AI 对话模型这个相当炽热的背景下，Tapdata 仍然能够以实事数据集成和服务平台的角色，助力企业减速落地利用。
+ ChatBI：利用 AI 能力获取数据洞察
第二个例子是对于 AI 的数据洞察能力。
如上图所示，咱们针对用户的数据，应用自然语言问了一个问题，即“客户的年龄散布是什么”。在不须要用户写任何业余 SQL 的前提下，间接给出了一个客户年龄散布的柱状图，这极大升高了用户在数据摸索场景下对专业技能的要求。
上面以保险公司为背景，LDP+ChatBI 服务为例，来展现这个场景是如何落地的。相似于 AIChat，这里的 ChatBI 是一款智能问答报表服务，反对应用自然语言对数据进行摸索。
依然是通过 LDP 将 MySQL 源库中的保险理赔表作为源数据，同步到 ChatBI 服务中，再通过 Tapdata LDP 的【数据指标和服务层】跳转到服务界面，即可开启 AI 数据洞察之旅：
无论是想要寻找零碎中客户保单金额最大的几条，还是想要晓得零碎中共有多少保单，都能够疾速以图表的形式呈现出剖析后果。
在以后的技术架构下，AI 大模型所具备的对于数据库畛域的认知能力能够十分好地和传统数据库进行配合，从而无效升高数据摸索的老本耗费。而 Tapdata LDP 则能够将各种对数据有须要的上游 AI 服务集成到产品外部，反对多种智能剖析上游服务，为用户提供利用便当。
LDP 智能数据治理
值得一提的是，Tapdata 连贯各种各样的数据源之后，除了通过工作进行数据的流转和加工之外，如何治理和了解、对接这些数据源里的数据也越来越受到关注。不论作为数据资产实现积淀和积攒，还是进行再加工，对数据的精确标注都十分重要。
但事实是，程序员大多都不违心给本人代码写正文，DBA 则更不会给本人的表构造做注解，数据库的名字、表名、字段名的缩写拼音形形色色，从这些构造中获取数据的业务含意往往并非易事。
Tapdata 在实现数据源对接之后，对加载的表构造，能够通过应用数据库、表、字段等名字，以及采样数据，进行综合剖析，通过 AI 大模型的能力主动推断数据表的业务含意。
