LongClip: 探索长文本的CLIP模型

上海AI实验室和上海交大的研究人员提出了Long-CLIP,一种改进的多模态模型,解决CLIP在处理长文本时的局限,如长度限制和细粒度信息丢失。通过知识保留和主要成分匹配策略,Long-CLIP在长文本图像检索和零样本图像分类任务中表现优秀,提升了图像生成任务的性能。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

标题:《Long-CLIP: Unlocking the Long-Text Capability of CLIP》
论文:https://arxiv.org/pdf/2403.15378.pdf
源码:https://github.com/beichenzbc/Long-CLIP

导读

CLIP(Contrastive Language–Image Pre-training),这个由 OpenAI 团队开源的多模态预训练模型,它通过对比学习的方式,同时学习图像和文本的表示,从而实现在没有针对特定任务训练的情况下(即Zero-Shot场景),对图像进行分类和理解的能力。

CLIP 模型的核心思想很简单,即利用大规模的图像和文本对进行训练,通过最大化匹配对的相似度并最小化不匹配对的相似度来学习视觉和语言的联合表示。

虽然 CLIP 发布了好几年,但包括其变体在内的相关模型目前仍被许多主流的多模态 LLM 所采用。然而,CLIP-based 模型的局限性也很明显:

  • 固定长度的文本输入:CLIP模型的文本编码器(如Transformer)通常有固定的最大序列长度限制(默认77个tokens),这意味着它无法直接处理超出这一长度的文本。对于复杂的文本描述,这无疑限制了模型的理解和应用能力。
  • 有效的长度严重不足:此外,实证研究指出其实际有效的长度往往不足20。这一限制使得CLIP难以处理详尽的描述,从而限制了其在需要基于丰富前提条件进行图像检索或文本到图像生成的应用场景中的适用性。
  • 细粒度信息的丢失:最后,在处理长文本时,为了适应模型的输入限制,需要对文本进行摘要或分割,这可能导致一些细粒度的信息丢失,从而影响模型的性能。

为此,来自上海AI实验室与上海交大提出了一种即插即用的替代方案——Long-CLIP,其不仅支持长文本输入,同时保持甚至超越其零样本泛化能力,并与CLIP潜在空间保持一致,使其能够无需任何额外适应直接替换 CLIP 在下游框架中的应用。

然而,实现这一目标并非易事,因为如果只是简单的微调可能会导致CLIP性能显著下降。此外,用支持更长上下文的语言模型替换文本编码器需要使用大量数据进行预训练,这将带来巨大的开销。

因此,Long-CLIP 在 CLIP 上引入了一种高效的微调解决方案,包括两种旨在保持原始能力的新策略:

  1. 知识保留的位置上插值Knowledge-Preserved Stretching):这种方法首先保留了前20个训练良好的位置上插值,然后对剩余的位置上插值进行了更大的扩展。这种策略不仅提高了整体长度,还最小化了对已建立位置表示的干扰。

  2. CLIP特征的主要成分匹配Primary Component Matching):除了将图像的细粒度特征与长文本描述对齐外,该方法还从细粒度图像特征中提取粗粒度信息,并将其与短文本描述对齐。这要求模型不仅能捕捉图像中的不同细节,还能识别其中最重要的组成部分。

通过仅利用额外的一百万对长文本-图像对,Long-CLIP在长标题图文检索任务中展现出比CLIP高出约20%的优势,在诸如COCO和Flickr30k等传统图文检索任务中也有6%的提升。最后,通过以即插即用方式替换CLIP,Long-CLIP还增强了从详细文本描述生成图像的能力。

动机

上图展示了CLIP模型在处理长文本输入时的两个主要缺点:

  1. 有效长度的限制

    • 当输入文本的长度超过20个token时,可以明显的观察到模型的准确率(R@1,即准确率@1)增长非常缓慢。这表明CLIP模型的实际有效长度甚至不超过20个token。这意味着对于超过这个长度的文本,CLIP模型无法有效地利用额外的信息,因为它的设计和训练数据集主要针对的是较短的文本描述。
  2. 无法提取属性间的相互关系

    • CLIP模型在处理包含多个属性的图像时,无法准确地捕捉这些属性之间的相互关系。在图2的例子中,CLIP模型将最高相似度得分分配给了一个既不符合颜色也不符合相对位置的表示。例如,对于一张包含柠檬和茄子的图片,CLIP可能会错误地坚信柠檬是紫色的,即使图片中的柠檬实际上是黄色的。这种错误表明CLIP模型在理解和表示多个相互作用属性时存在局限。

这两个缺点限制了CLIP模型在更复杂场景中的应用,特别是在需要处理详细描述或需要理解多个属性相互作用的任务中。Long-CLIP模型正是为了解决这些问题而提出的,它通过支持更长的文本输入并改进模型对属性间关系的理解,从而提高了模型的性能和应用范围。

方法

好了,了解完前述背景和动机,我们来快速看下 Long-CLIP 具体是如何构建的。

上图直观地展示了Long-CLIP模型训练过程的流程图,其中包括了两个关键的子模块:细粒度图像特征与长详细描述的对齐,以及粗粒度图像特征与短摘要描述的对齐。

  1. 细粒度图像特征与长详细描述的对齐

    • 这一步骤的目的是通过训练模型来使图像的细粒度特征与长文本描述相匹配。这意味着模型需要捕捉图像中的所有细节,并理解这些细节如何与长文本描述中的内容相对应。这一过程有助于模型学习如何从长文本中提取和理解复杂的视觉信息。
  2. 主要组成部分提取(Primary Component Extraction)

    • 这里,模型不仅需要理解图像的所有细节,还需要识别出图像中最重要的组成部分。这是通过一个称为主要成分提取(Primary Component Extraction)的过程实现的,该过程从细粒度图像特征中提取出粗粒度的图像特征。这些粗粒度特征捕获了图像的关键属性,但忽略了一些不那么重要的细节。
  3. 粗粒度图像特征与短摘要描述的对齐

    • 一旦提取出粗粒度图像特征,模型就会将其与短文本描述对齐。此处要求模型不仅要捕捉图像的不同细节,还要理解这些细节的相对重要性,并能够将最重要的组成部分与简短的摘要描述相匹配。

这个训练流程使得Long-CLIP模型能够处理包含丰富细节的长文本描述,同时保持对简短文本的兼容和敏感性,从而在多种视觉-语言任务中提高性能。

伪代码如下所示:

实验

Long-CLIP的实验部分旨在验证模型在处理长文本输入方面的能力,并通过与原始CLIP模型的对比来展示其改进。

实验设置

评估数据集
  • 零样本图像分类: 主要使用ImageNet-1K数据集,同时分析了ImageNet-V2、ImageNet-O、CIFAR-10和CIFAR-100等数据集的分类能力。
  • 短标题图像-文本检索: 使用COCO2017和Flickr30k数据集进行传统的短标题图像-文本检索任务。
  • 长标题图像-文本检索: 对于长标题图像-文本检索,使用了从ShareGPT4V数据集中分离出的随机1k(图像,长文本)对,并收集了200个描述城市场景的相似图像,使用GPT-4V生成长标题。
训练设置
  • 使用ShareGPT4V数据集作为训练数据,包含约1M(长标题,图像)对。
  • 随机1k数据作为评估数据集。
  • 使用AdamW优化器进行微调,共6个epoch,批量大小为2048。

新评估数据集

  • 为了更好地评估长文本的细粒度能力,作者收集了一个包含200个(图像,长标题)对的城市数据集。
  • 从Visual Genome数据集中手动选择200张展示繁忙城市景观的相似图像。
  • 使用GPT-4V生成描述图像的长标题,包括属性的类型、颜色和相对位置,并手动检查和修正生成的标题。
  • 通过这个数据集,模型必须成功理解并模拟两种模态中的详细属性才能正确匹配图像和标题。

对比结果

  • 长标题图像-文本检索: Long-CLIP在1k ShareGPT4V验证集和200个城市数据集上的R@1性能优于原始CLIP模型。
  • 短标题图像-文本检索: 在5k COCO2017验证集和整个30k Flickr30K数据集上,Long-CLIP在R@1、R@5和R@10指标上都优于原始CLIP模型。
  • 零样本图像分类: 在多个验证集上,Long-CLIP在保持原始CLIP模型零样本分类性能的同时,展现了更好的性能。

消融研究

  • 消融实验部分验证了知识保留的位置上插值(KPS)和主要成分匹配(PCM)两个核心组件策略的有效性。
  • 通过对比使用和不使用这些策略的模型性能,证明了这些策略对于提升模型性能的重要性。

值得一提的是,Long-CLIP模型完全可以无缝替换Stable Diffusion等图像生成模型中的原始CLIP文本编码器,无需额外训练。

总结

总的来说,Long-CLIP是一个改进的视觉-语言预训练模型,它通过知识保留的位置上插值和主要成分匹配策略,有效解决了原始CLIP模型在处理长文本输入时的限制。这一模型不仅在长文本图像检索任务中表现出色,而且在零样本图像分类任务中保持了与原始CLIP相当的性能,同时还能以即插即用的方式增强图像生成任务中的长文本处理能力。

最后,如果你对本文有任何的观点或疑问,欢迎评论区下方留言讨论。同时也欢迎对多模态相关技术感兴趣的同学扫描屏幕下方二维码添加微信好友,备注“多模态学习”即可。

<think>好的,我现在需要解决MySQL中插入大数据到text类型字段时出现的Data truncation错误。首先,我需要理解这个错误的原因。用户提到使用了text类型字段request_params,但插入的数据太长导致截断错误。根据我对MySQL的了解,text类型有不同的子类型,比如TINYTEXT、TEXT、MEDIUMTEXT和LONGTEXT,它们的最大存储容量不同。可能用户当前使用的text类型容量不够,需要升级到更大的类型。比如TEXT最多能存储65535字节,而LONGTEXT可以存储4GB的数据。因此,检查表结构,确认request_params字段的类型是否是足够大的类型,比如MEDIUMTEXT或LONGTEXT,这可能解决问题。 另外,可能用户的数据超过了text类型的最大限制。例如,如果字段是TINYTEXT,最多255字节,而用户的数据超过这个长度就会出错。这时候需要修改表结构,将字段类型改为更大的类型。修改表结构的SQL语句应该是ALTER TABLE,比如ALTER TABLE 表名 MODIFY request_params LONGTEXT;。但需要注意,修改字段类型可能会影响现有数据或索引,需要评估影响。 还有可能,即使用户的字段类型是LONGTEXT,但插入的数据仍然超过了客户端或服务器端的配置限制。比如MySQL的max_allowed_packet参数,默认是4MB,如果插入的数据超过这个值,即使字段类型支持,也会被截断。这时候需要调整max_allowed_packet的大小,可以通过SET GLOBAL max_allowed_packet=更大的值;来修改,并重启服务使其生效。 另外,应用程序端的配置也可能导致问题。比如使用的连接器或ORM框架可能有自己的参数限制,例如JDBC的allowMultiQueries或者maxAllowedPacket,需要检查并调整这些设置。此外,应用程序是否在插入前对数据进行了正确的编码处理,比如转义特殊字符,可能导致数据长度意外增加。 还需要检查是否在插入时使用了错误的数据类型绑定,例如在预处理语句中错误地指定了较短的字符串长度,导致数据被截断。确保应用程序中绑定参数的代码正确,没有人为限制长度。 最后,检查字符集的影响。例如,UTF-8字符集中某些字符可能占用更多字节,导致实际存储长度超过预期。如果字段的字符集是utf8mb4,每个字符最多4字节,计算数据大小时需要考虑这一点,可能需要更大的字段类型。 总结可能的解决方案步骤:首先确认字段类型是否足够大,修改为LONGTEXT;其次检查MySQL的max_allowed_packet参数并调整;然后检查应用程序的配置和代码是否有长度限制;最后确保字符集设置正确。同时,需要考虑事务和锁的问题,修改表结构时可能需要锁定表,影响生产环境,所以需在低峰期操作。 另外,是否有其他约束或触发器导致的问题?比如字段上有CHECK约束限制长度,或者触发器在插入前修改数据导致截断。需要检查表定义是否有这些因素。 可能还需要测试插入的数据实际长度,使用LENGTH()函数来确认数据大小是否超过字段容量。例如,执行SELECT LENGTH(request_params) FROM 表名; 查看现有数据的长度,以及尝试插入的数据长度。 最后,如果所有配置都正确,但问题仍然存在,可能需要检查MySQL的版本是否存在已知的bug,或者是否有其他配置项影响,比如strict mode是否启用。在严格模式下,数据截断会导致错误,而非严格模式下可能只是警告。可以通过@@sql_mode查看当前模式,如果包含STRICT_TRANS_TABLES,则需要考虑调整。</think>### 解决方案 当MySQL的`TEXT`类型字段存储超长数据时出现**Data truncation**错误,可通过以下步骤排查与解决: --- #### 1. **确认字段类型容量** MySQL的`TEXT`类型分为四种子类型,容量限制如下: - `TINYTEXT`: 最大255字节 - `TEXT`: 最大65,535字节(约64KB) - `MEDIUMTEXT`: 最大16,777,215字节(约16MB) - `LONGTEXT`: 最大4,294,967,295字节(约4GB) **操作**: - 若`request_params`字段当前为`TEXT`或更小的类型,可升级为`LONGTEXT`: ```sql ALTER TABLE 表名 MODIFY request_params LONGTEXT; ``` - 注意修改字段类型可能导致表锁,建议在低峰期操作[^1]。 --- #### 2. **检查`max_allowed_packet`配置** 若插入数据大小超过MySQL服务器的`max_allowed_packet`参数(默认4MB),即使字段类型支持,也会被截断。 **操作**: - 查看当前配置: ```sql SHOW VARIABLES LIKE 'max_allowed_packet'; ``` - 临时调整(需重启MySQL生效): ```sql SET GLOBAL max_allowed_packet=1073741824; -- 设置为1GB ``` - 永久修改:在`my.cnf`或`my.ini`中添加: ```ini [mysqld] max_allowed_packet=1G ``` --- #### 3. **验证字符集影响** 若字段使用多字节字符集(如`utf8mb4`),实际存储的字节数可能超过预期。例如,一个`VARCHAR(10000)`字段在`utf8mb4`下最多占用40,000字节,可能超过`TEXT`类型的限制。 - 使用`LENGTH()`函数检查实际字节长度: ```sql SELECT LENGTH(request_params) FROM 表名; ``` --- #### 4. **检查应用程序配置** - **ORM框架或连接器限制**:如JDBC需设置`allowMultiQueries=true`或调整`maxAllowedPacket`。 - **代码层截断**:确保应用程序未对数据人为截断(如`substring(0, N)`)。 - **预处理语句绑定**:确认绑定参数时未限制长度(如误用`VARCHAR(255)`绑定`LONGTEXT`字段)。 --- #### 5. **关闭严格模式(谨慎操作)** 若启用`STRICT_TRANS_TABLES`模式,数据超长会直接报错;关闭后可能仅警告并截断数据。 - 查看当前模式: ```sql SELECT @@sql_mode; ``` - 临时关闭严格模式: ```sql SET SESSION sql_mode = 'NO_ENGINE_SUBSTITUTION'; ``` --- ### 相关问题 1. 如何优化MySQL大字段(如`LONGTEXT`)的查询性能? 2. `VARCHAR`和`TEXT`类型在存储机制上有何区别? 3. 如何避免因字符集导致的存储空间溢出问题? : MySQL官方文档:https://dev.mysql.com/doc/refman/8.0/en/string-type-overview.html
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

CVHub

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值