核心内容摘要
玩转“jalapskxixi2025kino”：年度狂欢，惊喜不停歇！
还有谁在打开电商APP刷到心仪商品时没有被“找到便宜20%的同款”弹窗截胡过那么但你有想过电商公司究竟是怎么精准找到你正在浏览商品的相似款然后精准推送给你比价嘛今天的这篇文章来自印度最大电商平台的工程师投稿聊一聊他们究竟是怎么做商品比价系统又是如何做infra选型取舍的。
01高速发展的印度电商业务比价系统是重中之重但凡去过印度或者做东南亚出海生意的对我们公司一定不会陌生。
毕竟我司产品的月活已经达到
908亿是超越亚马逊的当地最大电商平台。
当前公司的业务已经覆盖全印度品类横跨电子产品、时尚、杂货和家庭必需品等多个品类。
不仅有自营、第三方商家入驻业务也能通过SaaS部门为企业及在线卖家提供端到端电商解决方案。
在这个过程中我们发现在印度做电商性价比是绕不开的生存法则。
这个拥有14亿人口且互联网用户年增速超15%的市场里消费者对价格的敏感度远超欧美同一商品差价5%就可能直接改写购买决策。
也是因此在服务第三方商家、给自营产品定价时比价系统的建设举足轻重。
但问题在于印度电商市场玩家混杂既有Amazon India这样的全球巨头也有Snapdeal、Paytm Mall等深耕细分赛道的玩家10余家主流平台构成了错综复杂的竞争网络。
也是因此比价服务不仅要在平台内找相似款还要监控全市场动向提供竞对情报、平台动态定价建议并通过跨目录匹配精准识别自家平台上的空白细分品类助力商家优化商品结构。
但这套体系的背后是令人窒息的工程压力我们平台自身就有2000万商品目录需按日甚至按小时更新竞对监控时每新增一个竞争对手就要额外处理500万商品数据工作负载几乎呈指数级增长。
要不了多久这套比价系统重的商品总量就要突破亿级而我们此前沿用多年的关键词FAISS架构已经肉眼可见的走到崩溃边缘。
02为什么通用方案解决不了电商比价的核心难题其实凭良心讲在平台发展早期阶段关键词FAISS架构这套架构很好简单且好上手但后面商品数量越来越多这套方案就会面临包括但不限于以下问题第一数据暴涨带来内存危机。
FAISS作为Facebook开源的向量检索工具本质上更适合离线批量处理单机版架构完全扛不住亿级数据。
仅存储2000万个1024维embedding数据就需要接近400GB内存相当于把几十台高端服务器的内存捆在一起用。
更致命的是每新增一个竞争对手监控内存需求就要额外增加100GB基础设施成本会像滚雪球一样增长。
第二数据管理混乱导致召回率低下在印度电商商品的数据管理堪称野蛮。
举个中文环境的例子同一台洗衣机商家A的标题是“全自动10kg变频滚筒”商家B的标题是“10公斤变频滚筒洗衣机 静音节能”对应的图片分辨率更是从300x300到2000x2000不等甚至有商家用好几个角度的实物图的情况下有的商家只用示意图。
关键词匹配只能搞定完全一致的商品描述面对这种语义相近但表述各异的场景完全失灵。
而且你懂得印度这地方情况还是太复杂了在印度根本没有和汉语、普通话对应的印度语这种说法。
在这里宪法承认的官方语言有22种包括印地语、英语、阿萨姆语、孟加拉语、古吉拉特语等使用人口超过100万的语言有33种。
当然有人说用使用人口最多的印地语可不可以根据2011年的统计数字印度全国有
28亿人以印地语为母语在当年只占印度总人口的43%。
怎么把不同语言、不同表述方式、不同平台的商品一一对应起来可能没有哪个国家能比印度还擅长。
第三比价会直接影响商家的定价决策这个环节几乎0容错。
把低端耳机误匹配成高端款可能导致商家定价过低亏到倒闭把竞品的促销价当成常规价又会让商家主动降价错失利润。
为了解决这个问题团队曾尝试两种替代方案一开始我们曾经试着走垂直扩展路线把服务器内存从256GB升级到512GB再到1TB短期性能确实提升但成本也跟着直线提升而且物理硬件有上限这套方案很快被否掉。
后来我们又想给一直在用的SQL数据库加向量搜索插件结果导致主库过载订单查询延迟飙升差点引发交易故障。
毕竟电商核心事务与非事务检索本就不该挤在同一套数据库里。
经历过多轮失败复盘后团队最终决定跳出修修补补的思维定式从底层彻底重构系统。
这就有了两个核心决策第一训练一套电商专属的embedding模型。
通用embedding模型做知识库之类的场景尚能满足需求但电商场景必须基于真实电商商品数据微调embedding模型才能精准捕捉产品属性、描述、类别等专属语义第二搭建一套专为亿级商品匹配设计的智能商品检索系统不但能搜到商品还要能理解商品属性、竞争关系精准判断当前定价决策需要哪些匹配信息。
而承载这套系统的核心基础设施只能是向量数据库但不是随便一款都能用。
03基于Milvus如何打造企业级比价引擎在敲定最终方案前我们测试了Pinecone、Qdrant、Weaviate等市面上几乎所有主流向量数据库最终选择了Milvus作为核心infra支撑。
最根本的原因在于Milvus的基础能力与我们的业务要求是完全匹配的。
海量存储与效率飞跃Milvus的分布式架构能轻松承载2000万1024维向量未来可无缝扩展至数十亿规模。
更关键的是它把我们的端到端数据处理时间从12天压缩到2天效率提升6倍。
这意味着竞争情报从滞后更新变成近实时同步商家能在对手调价后24小时左右做出反应。
成本直降75%的内存优化Milvus的DiskANN磁盘索引技术是关键它打破了FAISS对内存的强依赖还能把大部分向量数据存储在S
GCP等对象存储中仅将热点数据放入内存。
这一操作直接让内存需求降低75%400GB的内存需求可以减到100GB-200GB。
混合检索与灵活扩展Milvus原生支持语义向量检索关键词检索的混合检索能力不用额外维护两套系统。
灵活扩展与稳定性能Milvus的查询、索引、数据节点可独立伸缩——比如大促前比价查询量暴涨时只需单独扩容查询节点不会影响数据写入与索引构建这对电商平台的峰值应对至关重要。
尤其值得一提的是比价是个对资源消耗极高的过程但Milvus支持的标签预过滤按类别、品牌、价格等属性 向量语义搜索可以帮助我们把效率与精度的平衡做到了极致。
其过程如下第一步基于商品类别、品牌、价格等结构化属性完成预过滤快速缩小候选集范围第二步由 Milvus 在筛选后的候选集内执行向量语义搜索实现目标商品的精准匹配第三步通过后处理评分与阈值过滤机制生成匹配推荐结果第四步人工审核兜底。
对高置信度匹配结果开展人工审核避免误操作。
既减少了搜索空间、提升了性能又最大限度降低了错误匹配率满足了定价场景的零容错要求。
这套流程落地后我们的比价错误匹配率快速下降批量查询延迟也能稳定控制在200ms以内商家对定价建议的信任度大幅提升。
未来我们还进一步深化与Milvus的合作一方面扩展多模态分析能力让系统能直接理解商品图片、视频中的细节比如通过耳机外观设计、包装盒样式进一步提升匹配精度另一方面将AI能力与商家经营全流程融合比如不仅提供定价建议还能结合库存、销量数据给出定价促销补货的一体化方案。
阅读推荐 Claude通过Cowork实现模型主动记忆要如何复现我们还需要RAG吗 Skills 比MCP好在哪儿如何用Milvus-Skills 搭建知识库 熠智AIMilvus:从Embedding 到数据处理、问题重写电商AI客服架构怎么搭 官宣Milvus开源语义高亮模型告别饱和检索帮RAG、agent剪枝80%上下文 都有混合检索与智能路由了谁还在给RAG赛博哭坟