客户案例|100M 768 维向量数据,Zilliz Cloud 稳定支持 Shulex VOC 业

2024-03-12 22:52

本文主要是介绍客户案例|100M 768 维向量数据,Zilliz Cloud 稳定支持 Shulex VOC 业,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

日前,国际化 VOC SaaS 公司数里行间(Shulex)将上亿数据量的核心业务从开源向量数据库 Milvus 迁移至全托管的向量数据库云服务 Zilliz Cloud。

相比于 Milvus,Zilliz Cloud 实现了 Shulex VOC 评论分析洞察报告生成速度 30% 的提升,VOC 智能客服召回率 98%,且系统稳定,0 宕机,大大降低了企业在向量数据库的运维成本。

alt

01.从内卷到出海,Shulex 为电商打造基于大模型的 VOC 服务

近几年,国内电商市场竞争日益激烈,跨境电商异军突起,这也无形中增高了中小商家入局的门槛,Shulex 正是在这样的背景下迅速崛起。Shulex 专注品牌出海,面向海外客户和中国出海客户,基于大模型为企业提供 VOC SaaS 服务,帮助企业通过数智化来引领产品创新、驱动客户品牌增长。

02.从 Milvus 到 Zilliz Cloud,向量数据库支撑 Shulex 核心业务场景

随着业务的高速发展,仅在 VOC 评论分析业务上,Shulex 就训练了 10,000 条以上电商类目的评论标签,产生了上亿规模的向量数据。以往基于开源向量数据库 Milvus 自建方案,费时费力,稳定性无法保障,运维成本非常高昂,当出现故障的时候往往需要几个小时甚至一天才能恢复,运营疲于处理由于系统不稳定导致的客户吐槽和投诉,客户满意度也持续走低。

Shulex 技术专家李辰辉表示:“业务发展到这个阶段,对向量数据库的要求也就更严苛了,要能弹性扩容以支撑海量的向量存储与搜索,向量匹配速度要更快、SLA 足够高,运维成本一定要够低。”

在与 Milvus 的背后商业公司 Zilliz 的专家团队进行充分沟通后,Shulex 技术团队决定将核心业务的向量数据库部分搬迁至 Milvus 的全托管云服务 Zilliz Cloud 上。目前 Zilliz Cloud 主要支持了 Shulex 的 VOC 评论分析及智能客服两大块核心业务。

| 文本搜索场景——VOC 评论分析

Shulex 是排名第一的 Amazon ChatGPT 选品工具,而 VOC 评论分析服务核心是通过向量数据库对海量的 Amazon 评论/社媒数据,进行分类打标和实时分析,为客户提供实时的商品评论洞察报告,包括但不限于:用户画像、使用场景、购买动机、商品卖点、商品不足点等。

向量数据库是该业务场景的关键组件,基于 Zilliz Cloud 的 VOC 评论分析流程包含建库、选品、分析样本、全量打标、报表生成 5 个步骤,具体来看:

  • 建立用来判断评论的标签库:在向量数据里面存储的表结构包括评论文本、评论的 embedding、评论的正负情感标签等等;

  • 选择待分析的商品类目:在上万个类目的商品中选择感兴趣的品类作为后续进行评论分析的对象;

  • 基于大模型的评论分析:选择上一步中品类的数万条评论(包含正负评论、意思相近的评论)输入给大模型,让 GPT-4 对每个评论进行标签,将这些标签而后进行聚类后生成标签的样本库;

  • 用向量数据库做分类打标:将生成的标签样本输出给向量数据库里进行该类目商品的全部评论 embedding数据的检索,结合向量数据库来进行分类,判断这些评论的正负情感;

  • 生成结构化的统计报表:基于向量数据库的分类情况,进行用户对该商品属性的情感、正负向的分析,然后生成报表。

alt 图 1 |基于 Zilliz Cloud 的 VOC 评论分析流程

Zilliz Cloud 的引入在 Shulex VOC 评论分析业务中取得的收益显著,总结而言包括以下几点:

报表生成速度提升 30%:Zilliz Cloud 提供更高性能的向量搜索能力,其搜索引擎性能比开源 Milvus 提升超过 5 倍,稳定支持了 1000 QPS 的商品评论的高频次搜索。同时,相比于 Milvus,搜索时延降低了 50%,这使生成结构化的统计报表速度提升 30%;

数据分析成本降低 50%:由于无需将所有的商品评论信息通过大模型进行分析来获取评论标签,仅需要基于评论原文与向量数据库,实时召回评论标签即可生成高质量标签,去除了对大模型的依赖,极大的降低了评论数据分析的成本。

分钟级响应大促等突发流量:对于突发的客户访问量剧增,如大促周期,以往需要客户请求排队半个小时甚至 1 个小时,而 Zilliz Cloud 支持弹性扩缩容,集群增减分钟级即可完成,客户排队的状况也顺利解决。

| 大模型 RAG 应用——VOC 智能问答系统

Shulex 提供 VOC 企业智能问答系统,通过训练企业与外部数据,自动解析成 FAQ,2 分钟生成专业客服机器人,可以显著提升响应效率,同时降低运营成本。

alt 图 2 |基于 Zilliz Cloud 的 VOC 智能问答系统

当前,Shulex VOC 智能客服业务采用大模型+向量数据库的标准范式构建了 RAG 应用,除了自动提取公网链接,还将企业文件、邮件、工单等多渠道的知识 embedding 后存入 Zilliz Cloud 来构建企业专属知识库,为大模型增加外接记忆体。而 Zilliz Cloud 使得大模型能够快速有效地检索和处理大量的向量数据,实时召回知识,稳定支撑 Shulex VOC 智能客服业务每秒 90 次的客户询问,稳定召回率在 98% 以上,据统计,Shulex 智能客服机器人已经可以承担 80% 以上的客服工作。

03.客户说

Shulex CTO 潘胜一表示:“从开源的向量数据库 Milvus 切换到托管云服务 Zilliz Cloud 后,我们的业务收益显著提升,实现了更低的运维成本、更高的业务速度、更灵活的系统架构以及更稳定的用户体验。通过使用 Zilliz Cloud,我们能够享受到专家团队的支持,他们能够高效沟通并快速解决业务中遇到的问题。总的来说,Zilliz Cloud 为我们带来了更大的便利和竞争优势,我们对这一转变感到非常满意和乐观。”

04.关于 Zilliz

Zilliz 作为向量数据库技术的开创者,推出的全球最受欢迎的的开源向量数据库--Milvus,受到了全球 5000 家以上企业用户的支持与青睐。2023 年,Zilliz推出了基于 Milvus 的全托管云服务 Zilliz Cloud。

截至目前,Zilliz Cloud 已实现全球 4 大云 11 个节点的全覆盖,是全球首个提供海内外多云服务的向量数据库企业,其企业注册用户已超过 40,000 家,付费用户遍及全球多个国家和地区,覆盖 AIGC 领域、电商、在线教育等场景。作为 AIGC 关键基础设施和 RAG 技术的基本组件提供商,Zilliz 完成了与全球头部大模型生态的对接,赋能大模型应用落地。

加入 Zilliz AI 初创计划

Zilliz AI 初创计划是面向 AI 初创企业推出的一项扶持计划,预计提供总计 1000 万元的 Zilliz Cloud 抵扣金,致力于帮助 AI 开发者构建高效的非结构化数据管理系统,助力打造高质量 AI 服务与运用,加速产业落地。点击 https://zilliz.com.cn/ 了解更多。

本文由 mdnice 多平台发布

这篇关于客户案例|100M 768 维向量数据,Zilliz Cloud 稳定支持 Shulex VOC 业的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/802844

相关文章

大模型研发全揭秘:客服工单数据标注的完整攻略

在人工智能(AI)领域,数据标注是模型训练过程中至关重要的一步。无论你是新手还是有经验的从业者,掌握数据标注的技术细节和常见问题的解决方案都能为你的AI项目增添不少价值。在电信运营商的客服系统中,工单数据是客户问题和解决方案的重要记录。通过对这些工单数据进行有效标注,不仅能够帮助提升客服自动化系统的智能化水平,还能优化客户服务流程,提高客户满意度。本文将详细介绍如何在电信运营商客服工单的背景下进行

基于MySQL Binlog的Elasticsearch数据同步实践

一、为什么要做 随着马蜂窝的逐渐发展,我们的业务数据越来越多,单纯使用 MySQL 已经不能满足我们的数据查询需求,例如对于商品、订单等数据的多维度检索。 使用 Elasticsearch 存储业务数据可以很好的解决我们业务中的搜索需求。而数据进行异构存储后,随之而来的就是数据同步的问题。 二、现有方法及问题 对于数据同步,我们目前的解决方案是建立数据中间表。把需要检索的业务数据,统一放到一张M

关于数据埋点,你需要了解这些基本知识

产品汪每天都在和数据打交道,你知道数据来自哪里吗? 移动app端内的用户行为数据大多来自埋点,了解一些埋点知识,能和数据分析师、技术侃大山,参与到前期的数据采集,更重要是让最终的埋点数据能为我所用,否则可怜巴巴等上几个月是常有的事。   埋点类型 根据埋点方式,可以区分为: 手动埋点半自动埋点全自动埋点 秉承“任何事物都有两面性”的道理:自动程度高的,能解决通用统计,便于统一化管理,但个性化定

Hadoop企业开发案例调优场景

需求 (1)需求:从1G数据中,统计每个单词出现次数。服务器3台,每台配置4G内存,4核CPU,4线程。 (2)需求分析: 1G / 128m = 8个MapTask;1个ReduceTask;1个mrAppMaster 平均每个节点运行10个 / 3台 ≈ 3个任务(4    3    3) HDFS参数调优 (1)修改:hadoop-env.sh export HDFS_NAMENOD

使用SecondaryNameNode恢复NameNode的数据

1)需求: NameNode进程挂了并且存储的数据也丢失了,如何恢复NameNode 此种方式恢复的数据可能存在小部分数据的丢失。 2)故障模拟 (1)kill -9 NameNode进程 [lytfly@hadoop102 current]$ kill -9 19886 (2)删除NameNode存储的数据(/opt/module/hadoop-3.1.4/data/tmp/dfs/na

异构存储(冷热数据分离)

异构存储主要解决不同的数据,存储在不同类型的硬盘中,达到最佳性能的问题。 异构存储Shell操作 (1)查看当前有哪些存储策略可以用 [lytfly@hadoop102 hadoop-3.1.4]$ hdfs storagepolicies -listPolicies (2)为指定路径(数据存储目录)设置指定的存储策略 hdfs storagepolicies -setStoragePo

Hadoop集群数据均衡之磁盘间数据均衡

生产环境,由于硬盘空间不足,往往需要增加一块硬盘。刚加载的硬盘没有数据时,可以执行磁盘数据均衡命令。(Hadoop3.x新特性) plan后面带的节点的名字必须是已经存在的,并且是需要均衡的节点。 如果节点不存在,会报如下错误: 如果节点只有一个硬盘的话,不会创建均衡计划: (1)生成均衡计划 hdfs diskbalancer -plan hadoop102 (2)执行均衡计划 hd

性能分析之MySQL索引实战案例

文章目录 一、前言二、准备三、MySQL索引优化四、MySQL 索引知识回顾五、总结 一、前言 在上一讲性能工具之 JProfiler 简单登录案例分析实战中已经发现SQL没有建立索引问题,本文将一起从代码层去分析为什么没有建立索引? 开源ERP项目地址:https://gitee.com/jishenghua/JSH_ERP 二、准备 打开IDEA找到登录请求资源路径位置

深入探索协同过滤:从原理到推荐模块案例

文章目录 前言一、协同过滤1. 基于用户的协同过滤(UserCF)2. 基于物品的协同过滤(ItemCF)3. 相似度计算方法 二、相似度计算方法1. 欧氏距离2. 皮尔逊相关系数3. 杰卡德相似系数4. 余弦相似度 三、推荐模块案例1.基于文章的协同过滤推荐功能2.基于用户的协同过滤推荐功能 前言     在信息过载的时代,推荐系统成为连接用户与内容的桥梁。本文聚焦于

【Prometheus】PromQL向量匹配实现不同标签的向量数据进行运算

✨✨ 欢迎大家来到景天科技苑✨✨ 🎈🎈 养成好习惯,先赞后看哦~🎈🎈 🏆 作者简介:景天科技苑 🏆《头衔》:大厂架构师,华为云开发者社区专家博主,阿里云开发者社区专家博主,CSDN全栈领域优质创作者,掘金优秀博主,51CTO博客专家等。 🏆《博客》:Python全栈,前后端开发,小程序开发,人工智能,js逆向,App逆向,网络系统安全,数据分析,Django,fastapi