企业官网建设流程全解析

吉林专业做网站,北京注册公司可以申请北京车牌吗,网站建设必须买主机吗,广州企业搜索引擎优化服务本文来自熠智 AI 的一线工程师投稿。熠智 AI#xff0c;是电商智能客服赛道的新锐玩家#xff0c;目前已经打通淘宝、天猫、京东、拼多多、快手、抖音、闲鱼等主流电商平台#xff0c;深度服务多家头部店铺#xff0c;跻身智能客服解决方案一线梯队。在他们看来#xff0c…本文来自熠智 AI 的一线工程师投稿。熠智 AI是电商智能客服赛道的新锐玩家目前已经打通淘宝、天猫、京东、拼多多、快手、抖音、闲鱼等主流电商平台深度服务多家头部店铺跻身智能客服解决方案一线梯队。在他们看来做智能客服容易但做好智能客服却很难做好头部电商的智能客服更是难上加难。不仅客户的SKU 动辄上万、平台规则实时变动 用户需求更是五花八门。这就对答语的准确性、真实性提出更严苛要求。尤其遇上大促节点咨询量暴增十几倍整体技术架构面临的压力也会陡增。因此做好一个电商智能客服其技术架构设计难度以及细节远比我们想象的要多且复杂。以下是熠智AI的技术实现以及完整试错流程。01核心需求拆解正式开始技术落地前我们先梳理了智能客服 RAG 的过程中最核心的几类挑战对象定位难用户大量问题是“这个怎么样/耗电吗/怎么安装”如果没先定位“这个”到底指哪一个商品后面一切都无意义。只要商品检索错了后面生成再好也没用。语义理解与词法匹配的冲突商品检索里既有强语义比如制热快不快也有强词法型号、系列名、SKU、简称。单靠一种检索策略很容易要么“语义对了商品错了”要么“商品对了细节不相关”。知识源多且形态不一既有通用 QA售后、物流、保修也有商品知识参数、卖点、说明书内容还可能有结构化表格活动价、规格清单、库存/渠道数据。如果进同一个知识库后期很难治理、也难迭代。存在完全无法通过语义检索的场景用户可能会查询暖风机表格中价格小于100的商品依托于相似度的语义检索无法精确解决类似问题。时延、成本与稳定性约束客服是高并发、强实时必须在可控的 token 开销与可预测的时延下运行。能规则化解决的问题要前置拦截需要检索的问题要尽量并行检索结果要尽量少而准。02架构演进从单一Ragflow 到多模块RAG系统基于上文提出的五大类挑战在架构搭建的早期版本中我们采用了单一的Ragflow架构。这里必须承认一点RAGFlow的深度文档能力非常优秀在复杂格式文档处理方面无论是复杂表格还是学术论文、技术文档都能很好的解析。但随着公司业务增长我们接入的店铺数据量增长和咨询场景变得复杂单纯的Ragflow开始暴露出了严重的工程与业务痛点首先是Ragflow只能对信息进行粗放式切片Chunk处理检索粒度完全不可控导致大量无关噪音混入上下文。与此同时Ragflow系统本身日益臃肿维护难度大系统脆弱性增加。于是在经过大量的调研与测试以后在技术架构升级的第二阶段我们将语义搜索的向量数据库迁移到了Milvus与postgres传统数据库的精确匹配形成互补。基于这些挑战我们选择把检索与数据链路拆成可演进的模块并采用Milvus 这个开源的向量检索中间件来解决这些问题。具体来说新的思路中我们会把一次对话请求拆成四段Query 理解把口语化对话句转成可检索表达分层并行检索通用知识库QA与商品知识库Product并行召回并使用rerank重排两级回填拼装Milvus 做召回与排序Postgres 做权威字段与内容拼装基于证据生成把检索结果分层注入 prompt约束 LLM 在证据范围内回答同时为提高拓展智能客服的智能上限我们还拓展了Agent智能检索的能力基于Milvus结合LLM开发了自定义表格检索引擎让模型能查结构化数据并保持确定性。03五个核心技术实现设计智能客服的底层技术架构本质是RAG但它的实际工程化以及选型细节却比RAG要复杂得多。我们共计梳理了四大环节的五大技术实现细节供大家参考3.1. 数据收集与预处理单商品单记录策略构建知识库首先要有数据。但与业界通用的将文档切分为碎片化 Chunks 分散存储的方案不同我们发现商品数据具有极强的内聚性。如果把一个商品的参数、描述、评价拆得太散检索时很难拼凑出全貌。因此我们采取了单商品单向量记录的策略 。 我们在同步数据到 Milvus 时将一个商品下的所有内容块预先拼接合并存为一条 Milvus 记录ChunkID 统一格式为product_{productId}。这种设计让 Milvus 中的记录数从N*M降低到了NN商品数不仅显著降低了存储成本更简化了后续的召回拼装逻辑一次命中即可获得该商品的完整上下文。3.2. Embedding 与索引架构两级存储设计有了清洗好的数据接下来是构建索引。我们采用了一套Milvus PostgreSQL的两级检索架构以此来兼顾检索速度与数据的权威性。向量库Milvus负责找得准 我们将数据向量化后存入 Milvus作为索引指针。这里并不存储冗余的业务字段只存储用于计算相似度的向量和主键 IDproduct_{productId}。然后选择IVF_FLAT索引平衡检索速度和存储成本。关系库PostgreSQL负责信息全 商品的实时价格、高清图片 URL、上下架状态等结构化信息存储在 Postgres 中。3.3. 查询前置处理问题重写如前面困境所说用户的 Query 实际是多种多样的有简单的 Query也有指代不明的 Query。比如用户进线看了“美的取暖器”然后问“这个制热快吗”。如果直接拿“这个制热快吗”去检索召回率几乎为零。为此我们在检索前引入了Query 转换模块。 通过QuestionRewriteUtil利用 LLM 对用户问题进行重写将问题转化为最新问题(latestQuestion) 。例如原始问题“这个制热快吗”重写后“美的取暖器制热效果如何”这一步把对话语句转成检索语句对后续的召回准确率起到了决定性作用。3.4. 向量查询这是整个系统的核心。为了解决用户千奇百怪的提问方式我们设计了多维度的检索策略。根据用户输入情况自动选择最合适的检索策略。3.4.1 双层知识库并行检索postgre回填客服场景对响应速度极其敏感。我们的知识库分为两层QA 通用库存储通用的售后政策、退换货流程 。商品专属库存储具体的商品参数、规格 。在Workflow.run()中我们利用线程池进行并行执行。QA 检索使用原始问题。商品混合检索使用重写后的焦点商品问题。其中在Milvus的商品混合检索中我们面临一个经典冲突用户搜“HP21-K6”时需要精确的对象定位搜“适合老人的取暖器”时需要模糊的语义理解。单一的向量索引很难同时满足。 为此我们在 Milvus 中为每条记录维护了两个向量字段并赋予不同权重商品名称向量 (goodnamevector)权重70%。侧重对象定位保证搜出来的是正确的那个商品。描述向量 (describevector)权重30%。侧重语义理解提升回答细节的相关性。 系统并行检索这两个字段确保了“先找对商品再匹配细节”。系统并行检索这两个字段合并得分后进行加权融合重排序。返回的主键 IDproduct_{productId}会到PostgreSQL进一步查询返回最精准的商品数据。最后大模型会根据QA检索以及商品检索返回的topK 个数据生成回复。3.4.2 自定义表格检索引擎上面所说的算是一个比较标准的 RAG 流程但是企业内部有大量的结构化数据如 Excel 价格表、参数对比表。对于“查询价格小于 100 的商品”这类涉及数值比较的问题纯向量检索几乎不可用。为此我们在 Agent 模式下开发了自定义表格检索引擎借助Milvus及Agent的能力实现自定义表格的检索功能既保证了查询的精确性也保证了语义检索的准确性。04实施效果与验证比起单纯使用RAGflow的技术框架我们在Milvus基础上设计了更加灵活集中功能组件的方案,让商品在多种业务场景下检索的召回率大大提升在商品检索的召回率提升至95%。Milvus对检索精度极高的掌控力以及原生支持的混合检索的能力以及极高的性能扩展性和社群活力挖掘出了我们产品更大的潜力。5尾声在 AI 智能电商客服的赛道上智能检索需要面临对象定位、语义与词法冲突等多重挑战但基于 Milvus 搭建的分层检索体系不仅实现了精准的商品定位、高效的多源知识融合、稳定的高并发支撑也让熠智 AI 电商客服的回复质量与服务效率实现双重飞跃赢得了合作头部店铺的广泛认可与信赖。未来熠智AI还将进一步深化对Milvus的使用引入Milvus混合检索等能力在关键词模块使用Milvus的BM25替代对传统数据库的依赖降低后期的系统维护难度。阅读推荐 官宣 | Milvus 2.6云上GA三层存储降本85% 、速度快ES 4-7 倍多数据类型支持 官宣Milvus开源语义高亮模型告别饱和检索帮RAG、agent剪枝80%上下文 不会做RAG、agent的本地数据管理都来学Claude Code附深度拆解 都有混合检索与智能路由了谁还在给RAG赛博哭坟