RAG+大模型在电商客服领域-商品推荐的应用

大模型火了之后，RAG（检索增强生成）技术也跟着成了热门话题。在客服管理这块，它被认为是目前大模型落地最靠谱的方案之一。各行各业的头部公司都在疯狂搭建内部知识库，怎么把这些库里的东西真正用起来，跟客服管理结合，给团队赋能，这里面的商机和需求可不少。

电商行业有个头疼的问题——客服流动性太大。淡季的时候，可能就几个外包或者兼职客服撑着；一到旺季，临时招一堆人。培训、管理、质检，每个环节都让人头大。怎么在客服管理上降本增效，是整个行业都在琢磨的事儿。所以，很多企业想把大模型做成客服助手，这是个很自然的选择。

传统的检索系统，你得先建个结构化的知识库，按目录分区，塞进文档和表格。用户用的时候，得像用搜索引擎一样敲关键词，找起来费劲，经常要翻好几份资料、来回跳转才能找到答案。而且传统知识库很容易臃肿混乱，治理成本高，个人查个问题都得分析半天。客服更别提了，根本记不住那么细的知识结构。RAG技术出来之后，事情简单了不少：把相关文档扔给大模型，它靠强大的自然语言处理和理解能力，直接分析总结出答案。让大模型当客服的Copilot，这已经成了很多企业的刚需。

大模型在阅读理解、分析推理、文本生成上确实强，这也在一定程度上降低了我们对输入知识的苛刻要求——正好顺应了知识库向“知识湖”升级的大趋势。

开源领域里，结合大模型的方案有好几种。像fastgpt、askanything这类产品，还有langchain、llama-index这些开源项目，都提供了不少实用案例。它们能解决一部分文档知识的需求，但碰到商品知识这种场景，靠向量相似度做精确匹配，就有点吃力了。举个例子，商品ID通常是一串数字加字母，重复率很高，向量模型在召回效果上往往不好。而且单个商品关联的知识、属性、文档可能超过大模型的token限制，还得裁剪才能处理。

商家的商品参数知识，多数是高度结构化的表格数据，存在关系型数据库里。比如下面这种结构：

（图片位置保持不变）

面对这种知识结构，如果用向量模型、语义检索来做召回，效果会大打折扣。开源的向量模型在商品型号上没做过特殊调优，语义上很难区分那些无语义的内容——比如R075和R075X，明明是两个不同的商品，模型却分不清。而且基于语义或关键词的召回，没法满足范围检索的需求，比如客户问“长度不要超过4m”，这种诉求传统方法就处理不了。所以需要补充一些工程手段，比如在咨询过程中抓取消费者发的商品链接、下单信息，从中提取可能的商品ID。整体解决方案的关键，是要有一个灵活、能适应业务的检索系统——除了常见的FAQ知识和文档，还得支撑表格知识的检索。

商品属性表通常很大，有的品类参数多达几百个，商品数几万个，得扩展一个模型来做更准确的召回。比如商品参数问答、推荐这些场景，需要专门的匹配模型来过滤相关属性。尤其是商品检索、推荐场景，没有限定商品ID，整个知识内容很长，上下文很容易超过大模型的token限制，从成本和性能角度，必须做筛选。

大模型的强项在于分析决策，不是信息检索。如果把整个商品库都交给大模型处理，成本不好控制不说，响应延迟也可能很高，回复质量也没保障。所以更优的做法是：把大模型当作调用检索工具的“大脑”。商品数据通常是结构化存在关系型数据库里的，通过前期属性筛选，能大大降低数据库IO压力。剩下的数据再通过构建规则语法进一步过滤。

比如下面这个例子：让模型根据用户问题生成规则，再用规则匹配数据。

咨询问题：“推荐功率低于1600w的油烟机”
{type = "$gt",name = "功率",value = "1600w"}
// 进行规则运算过滤目标商品

这个方案上线后效果很明显，客服处理咨询时能快速查询和回复，效果像下图这样。我们已经交付给多个客户使用，反馈都不错。

（图片位置保持不变）

话说回来，RAG技术在电商客服领域的潜力远不止于此。从运营需求看，可以用RAG的智能推荐功能突出推广畅销商品，实现精准营销；个性化回复能做到千人千面，提升用户体验。再加上rerank、人设这些环节，客服流程还能进一步优化，问题解决效率更高，也能省下不少人力成本。未来随着电商行业继续发展，RAG在客服领域的应用空间还很广，还有很多没被挖掘的优化点等着去探索。