支持私有化部署
AI知识库

53AI知识库

学习大模型的前沿技术与行业应用场景


最佳实践|Zilliz 如何助力MiniMax的AI落地与预训练数据管理

发布日期:2025-08-06 18:58:13 浏览次数: 1515
作者:Zilliz

微信搜一搜,关注“Zilliz”

推荐语

Zilliz与MiniMax强强联手,打造大模型时代的数据管理新范式,揭秘Talkie AI精准推荐背后的技术突破。

核心内容:
1. 大模型训练数据管理面临的挑战与行业趋势
2. Zilliz向量数据库如何解决Talkie高并发与精准推荐难题
3. 合作案例对AI数据管理架构的示范意义

杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家
图片

随着大模型玩家之间的技术路线逐渐趋同,数据管理能力,正逐渐成为大模型竞赛中各个玩家的关键胜负手。

2020年6月发布的GPT-3 ,训练数据还仅有 570GB 的文本数据,模型参数超过 1750 亿个。到了2023年发布的GPT-4 ,模型参数已经达到1.8 万亿,背后的训练数据更是高达13万亿token。

而随着模型尺寸变得越来越大,多模态也在同期成为主流。为此,我们不仅需要更大的计算资源,也对非结构化数据的管理提出了更高的要求,对应的数据存储、处理、传输和检索系统升级已经迫在眉睫。

在这个背景下,头部大模型玩家MiniMax 和 向量数据库领军企业Zilliz 的合作成为了行业的一个重要标杆。

两者的合作不仅仅解决了MiniMax 旗下Talkie 等产品的高并发和精准推荐的问题,更为大模型训练提供了高效、灵活的数据管理架构。

那么这一合作是如何实现的?它又是如何推动数据管理和大模型训练的技术突破的?本文将对以上问题,进行逐一详细拆解。

01 

提升 Talkie AI 的用户体验:精准推荐与高并发处理

在如今的AI产品市场,Talkie 的地位已经不必多说。依托MiniMax全球先进的多模态AIGC技术,Talkie 构建了一个支持用户自由创造和分享AI Agent的交互平台,并入选 a16z 评选的 Top 50 AI-first 网页端产品、Top 50 AI 移动应用双榜单。

面对如此庞大的用户群体,Talkie 的遇到的第一大难关是如何做好推荐物料(类似游戏中的道具)。更进一步,这个问题可以被拆解成三方面:

如何借助语义相似度,做更精准的物料推荐: 在Talkie 中,每一项推荐物料(如角色语音包、互动内容等)都被编码为一个32维的向量,并根据用户历史行为,从物料库中实时筛选出最匹配的内容。

如何快速的将用户需求推送给他:系统的响应速度往往会对用户的购买转化带来直接影响,Talkie 必须在 30 毫秒内返回推荐结果。

如何应对千万级别用户带来的高并发随着Talkie 的月活不断增加至千万量级,其 QPS(每秒查询次数)有时会达到 5000 次以上。系统必须能够在短时间内响应大量用户的请求,并保证低延迟的服务体验。

起初,MiniMax 依赖 Redis 实现缓存式检索方案,Redis 作为一个内存数据库,快,但贵,也不稳。

尤其是随着物料增长至百万级,Redis 首先会遇到内存限制: 一般情况下,Redis 将数据存储在内存中,这虽然提高了访问速度,但随着数据量的增长,内存开销也大幅增加。

而且 Redis 缺乏原生的向量检索能力,必须通过外部工具或插件来勉强实现embedding 搜索,这在实际工程中往往会引入额外的延迟和复杂性。

因此,Talkie 需要一个能同时满足高性能 + 可扩展性 + AI原生的专业向量数据库产品,于是他们找到了 Zilliz Cloud。而根据这一需求,Zilliz给出了定制化解决方案:

  • 用 8 个计算单元(CU)为一个基本配置,配上 7 副本,多副本容灾、负载均衡,从而确保即使某一个副本失效,系统依旧能够继续稳定运行。

  • 多副本架构也使得Talkie 在面对大规模并发请求时,保证了其数据查询的高可用性和可靠性,确保查询延迟低至 30 毫秒。

这套新架构不仅支撑了 Talkie 的千万用户扩张,也为其后续产品扩展以及双方更多的合作奠定了基础。

02 

低成本去重百亿文档,加速模型训练

Talkie 的推荐只是前菜,MiniMax 真正重头戏的是大模型训练。

而大模型的数据管理远比表面复杂。最新一代模型动辄十多万亿token的训练数据,意味着仅数据预处理和清洗就可能耗费数周甚至数月工程资源。

更关键的是,这些数据并不是静态的。随着模型不断微调、语料持续演进,系统必须支持对亿级数据的“低成本的增量更新”与“高频次的数据同步”。而这正是传统内存数据库和关系型数据库难以胜任的。

举个简单的例子,大模型训练中,百亿级文档是行业常态。但通常来说,这数百亿文档中会存在大量重复冗余内容,不仅浪费计算资源,更导致大模型反复“咀嚼”相同的知识,在重复内容上过拟合,降低了对新信息的泛化能力。

目前主流的去重方法可以分为三类:

1. 精确匹配:通过对整个文件或者数据块进行哈希计算,找出完全相同的文本;

2. 近似匹配:使用如Jaccard 相似度等算法找出“相似但不完全相同”的文本;

3. 语义匹配:用深度学习模型(如 Transformer)将文本转换为向量嵌入(Embeddings),然后在向量空间中通过聚类或计算余弦相似度等方法,找出那些在语义层面表达相同或相似思想的文本。

随着预训练语料体量达到 TB 甚至 PB 级别,传统的精确匹配(如两两比对)根本无法承载计算负载,并且无法高效查找出一些内容高度相似但表述不同的内容;而语义去重则涉及向量生成和大规模匹配,开销巨大。

基于这一背景,Milvus团队为MiniMax在Milvus2.6版本中构建了专门的MinHash + LSH功能。其中,MinHash 负责将文档压缩为签名(目前,MinHash  向量,需要用户自己生成),LSH 负责高效缩小搜索空间,从而快速定位潜在重复,帮助企业完成百亿级语料下的预处理优化。

此外,Milvus 2.6 还将这一能力原生写入数据库索引系统,API 层面也做了统一,兼容 embedding 插入、索引构建与近似查询。更关键的是,它支持分布式、横向扩展,确保了 TB 甚至 PB 级数据量下的处理能力。

该方案相比于MiniMax此前使用的MapReduce 的方案,在处理速度上提升超过 2 倍,并在成本上实现了 3–5 倍的优化。

当然,这个功能的设计不止可以用于MiniMax的大模型训练数据去重问题,如今已经在网页内容清洗、商品目录管理、抄袭检测等场景,于千行百业落地开花。

结语

放眼未来,随着大模型玩家之间的技术路线逐渐趋同,数据管理能力,将成为大模型竞赛中的关键胜负手。

从传统存储到向量数据湖,是从存数据到用数据的进化;

从MapReduce 去重到 MinHash LSH,是数据质量管理能力的升级;

而从 Redis到专业向量数据库,则是企业从传统数据治理结构向AI原生的转变。

而Zilliz 与 MiniMax 的协作,正是这一趋势的缩影与最佳实践。

推荐阅读
90%的AI生成代码都是抄的,但Claude和Gemini连代码检索都不会做
Agent 还是 Workflow?其实80%的agent需求可以用Workflow搞定
ES vs Milvus vs PG vector :LLM时代的向量数据库选型指南
CodeIndexer 开源 | 我用 Gemini CLI+Milvus,做了个替代Cursor的AI coding神器
图片
图片

53AI,企业落地大模型首选服务商

产品:场景落地咨询+大模型应用平台+行业解决方案

承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业

联系我们

售前咨询
186 6662 7370
预约演示
185 8882 0121

微信扫码

添加专属顾问

回到顶部

加载中...

扫码咨询