写点什么

AI 托管商家经营: 1688 电商 AI 落地实战

刘祥宇

  • 2024-11-11
    北京
  • 本文字数:8898 字

    阅读完需:约 29 分钟

大小:4.48M时长:26:04
AI 托管商家经营: 1688 电商 AI 落地实战

如何通过 AI 技术帮助商家提升线上运营能力,从而提升商家的经营效果是一个具有挑战性的命题。在 10 月 18-19 日举办的 QCon 全球软件开发大会 2024(上海站) 上,阿里巴巴淘天集团技术专家刘祥宇分享了《AI 托管商家经营:1688 电商 AI 落地实战》,他结合 1688 商家端的 AI 实战,向参会者介绍了面向商家提供的 AI 智能化服务,包括咨询问答、 客户管理、 商品运营、经营计划等工作,以及业界领先的 AI 经营托管能力,并阐述相关的技术方案和踩坑经验。演讲内容备受好评,在本次 QCon 刘祥宇获得了「明星讲师」荣誉。12 月 13 日 -14 日,InfoQ 中国旗下的 AICon 全球人工智能开发与应用大会将在北京举办,AI Agent 技术突破与应用、大模型行业落地实践等精彩专题正陆续上新,欢迎关注。


以下是 QCon 新晋明星讲师刘祥宇老师的演讲实录,作者第一视角整理。

什么是电商托管


这一年来,托管的经营模式可谓是电商领域最“时髦”的词,我们的 AI 落地,也围绕托管模式展开,所以,请允许我花一点时间梳理一下。


简单来说,托管的意思,是我跟你买断货权,然后我来卖,这叫做(全)托管。


在全托管模式下,电商平台不再只充当流量入口的角色,而是直接面向消费者充当卖家,承担实际的销售责任。


在这种模式下,平台不仅提供流量入口,还直接负责商品销售和物流配送等环节,从而实现对整个销售过程的全程管控。


比如卖家只需要把货交给平台在国内的集货仓,后续的物流、履约和售后工作全部由平台方来完成。甚至你的店铺运营工作都可以交给平台,除了负责供货之外,别的什么都不用管,做个甩手掌柜就好了。


如下图所示,电商运营过程中,有很多个环节。每个环节里的每个细分领域,都有人在挖掘赚钱机会。而机会也会因为长链路上的分工重组而不断涌现。而所谓的全托管和半托管,不用过于纠结其定义(每家都不一样),重点要留意的是,托管逻辑的盛行,验证了在新环境里重新梳理分工的价值。不同平台可以根据自身情况,在行业长链路上找新的优化空间。


为什么要做托管?


不论是传统外贸还是跨境电商,相较于国内电商,都繁复很多。


以亚马逊为例,我梳理了跨境电商的主要环节和操作,虽然已经大幅简化,但是还是能看到在备货、物流、资金等领域都复杂很多。



此外,传统外贸则更加专业,光报价环节的价格条款就有 FOB、CIF、CFR 等多种模式。


因此,如果你是一个商家想做外贸,那么冷启动和前期踩坑交学费是不可避免的。这时,托管模式的优越性就显现出来,商家只需要供货,其他全部由平台来代理。

托管模式的优缺点


这里的优缺点从商家视角和平台视角两方面来阐述。



首先,对于商家来说:


优点

  • 简单、省人力成本:跨境业务链路很长,商家除了做电商都需要的选品、研发、定价以外,还要涉及国内电商没有的报关、清关、海外仓等国际物流问题,以及收汇、结汇等跨境支付问题,门槛较高。通过全托管,商家专注于提供货品、备货入仓,简单很多。对于部分商家来说,传统跨境电商平台,人工、物流等方面的成本要占据产品售价的 30%,但 Temu 上这些成本仅为 10%。举个例子,一个商家在美国、法国卖帽子,原来至少要请 2~3 个翻译运营店铺,月成本 1.2~1.8 万左右,现在这些都省下来了。

  • 爆单、清库存:由于平台具有更强的信息优势,更容易补货市场需求,且 temu 对于低价商品会有大量流量倾斜,因此,虽然很多人对平台压价有怨言,但难以拒绝“爆单”和“清库存”的诱惑。通过 temu 常常可以一日千单几千单,或者快速的将库存低价清出。

  • 风险更小:平台承担了市场预测、选品、发货、销售等环节,并可以更好的规避知识产权等法务问题,综合来看经营的风险更小。


缺点

  • 利润被压低:在托管模式下,商家的主动经营空间很小,失去了对定价和销量把控能力的商家,在平台的低价导向之下,只能以降价换取销量提升,导致利润空间被不断挤压。在小红书搜索“Temu 核价”,可以看到很多卖家晒出报价截图,建议申报价格相比原价对半砍也不算夸张。有卖家分享经验道,利润至少要把产品成本、退货费、运费、差评罚款等费用填平,不然就是赔本帮平台赚钱。

  • 很难营造品牌:对商家来说,全托管更像短期有效的兴奋剂,踩中平台爆款时可以获得大量订单。长期来看商家不能掌握销售主动权,也就永远无法直接接触消费者,难以真正了解市场需求,这也是所有想要转型发展品牌的生产商面临的最大难点。


然后,对于平台来说:


优点

  • 规模效应显著,成本优势:通过规模化采购压价、物流集运、营销推广,托管模式可以比 POP 模式下更极致的压缩全链条的成本,从而在终端价格上产生显著的优势。作为对比,同样的小商品,在 temu 上的售价往往是亚马逊的的 1/3~1/2,有些商品甚至是亚马逊同款价格的 1/10。而这么低的价格,商品的净利润依然可以做到 10% 以上。

  • 更懂市场,信息差:上架就出单,平台运营起来比工厂更懂市场。平台有更强的技术能力和资源优势,对欧美各平台的爆款研究的了然于胸,因此具有非常强的选品和打爆能力。对于跨境电商来说,商品是非常重要的,但它不是最难啃的一块骨头。难啃的骨头是,市场需求预测、品控、引流、物流、售后等。


缺点

  • SKU 规模受限:全托管下商品 SKU 广度受限、对仓网调配能力要求高,该模式更适合作为精选场打造标杆、提升平台调性,平台流量进一步扩大后全托管模式可能无法全量承接。以 temu 为例,所有的商品均需要买手发布商机、审核、上架和补库存,商家还需要发送到指定仓库,在仓储和运力紧张的情况下,商品上架速度明显减慢(因此也开启了半托管,开始放权)。目前 temu 的 sku 数量约 500 万,而亚马逊 sku 约 6000 万,temu 仅为亚马逊的 1/10。

  • 投入成本高:全托管由于承担了更多的经营环节,所面临的经营压力、营销投入、物流成本和库存和售后风险都要大得多,因此前期投入巨大,且运营风险也大。

托管和自营的区别


不是,但是十分接近了。


我的第一反应是,托管就是传统的自营电商的模式。在仔细研究以后,发现还是有差别。


对比一下几种电商经营模式,自营、POP、托管。



亚马逊、京东、shein 都是做自营起家的,但是现在也都逐渐转向 POP 模式。原因无他,虽然自营可以更极致地控制终端体验,但是投入也很大,规模效应不强。POP 依然是解决天花板的不二之选。


全托管模式是平台自营和 pop 跳蚤市场生态之间的均值回归。 与其说平台方、供应链和商家之间的关系在“融合”,不如说这三者之间的边界在平台方的予取予夺之间变得更清晰了。

各个平台的托管的区别


随着 shein 和 temu 的崛起,现在各大跨境电商都发布了自己的托管服务。这里对比一下各个公司托管能力的异同。


从商家的角度,分析一下各个平台的特点:



在从平台的角度,对比一下各个平台。这里选取了两张网友的图。


主要的结论是:


  1. temu 在市场营销上最舍得花钱,在平台流量和价格力上有显著优势

  2. tiktok shop 自带巨大流量,同时流量分配机制更加合理,对小商家更友好

  3. 亚马逊作为老牌跨境电商,虽然不做托管,但是也拿来做个比较。亚马逊沉淀多年,在货品的丰富度和履约时效上有很大优势。


托管适合什么样的商家


一图胜千言


上面这张图,将商家所处的发展阶段分为:新手(New company)、进阶(Advanced company)、到成熟(Mature company)。


将商家获取利润的主要来源分为:依靠供应链(Supply chain)驱动的工厂型商家、依靠精细化运营(Operation)驱动的运营型商家,以及依靠品牌溢价(Branding)驱动的品牌型商家。


因此商家分类的编号为:



对于复合类型的商家来说,会出现 NSO、NSOB 等。


目前全托管模式合作的商家以中小商家为主,他们对于建立品牌的诉求远小于规模商家,全托管模式更符合中小商家的利益。

国内电商有托管概念吗?


有,对标托管概念的,其实就是代运营行业。本质上就是把经营行为托管给代运营公司。


不过代运营提供的都是“半托管”服务,这得益于国内发达的电商基础设施。


代运营行业非常成熟,这里截取了一份研报的资料来说明。


总的来说,代运营的服务范围涉及到了商家经营的方方面面,不过从我们走访的情况来看,基本上代运营服务都是不保效果的,他们只承诺帮助商家做多少确定性的工作。极少部分的客户会进行利润分成,但是一般占代运营公司业务的 10% 以下。

AI 在其中的机会


当下电商行业越来越“卷”,商家的利润越来越薄,根据我们走访的调研,从商家的净利润来看,基本上是淘系 7~8%、抖音 4~5%、拼多多 0~1%。在这种微利的情况下,商家对降本增效的诉求,其实是非常强的。因此在国内,2B 的 AI 落地场景很多,而且相对 2C 更有确定性。


下面,我们就重点展开 AI 在电商商家端的应用场景,并介绍一下其中的核心方案。

AI 产业应用发展,雨后春笋,百花齐放


让我们先 Step-Back Prompting 一下,看看产业界 AI 应用的发展情况。



从 2022 年 11 月 open AI 推出 chatGPT 以来,到今天已经快 2 年时间,整个 AI 的学术界和工业界进入一个黄金发展期,AI 的应用如雨后春笋般涌现。


在基础模型侧,这是一个靠着算力和数据驱动的领域,巨头们进行着军备竞赛,小企业玩家数量不多但也有一些特色的产品出现。整体而言,这是一个残酷的赛道,最终比拼的是资源的总量,未来可能会剩下 2~3 个最终赢家。


做平台工具的,都是一些聪明人,他们就像是淘金热里卖铲子、卖水、卖牛仔裤的人,通过搭桥铺路来获取回报。这些厂商是否可以长足发展,取决于上层的应用侧是否可以进一步发展。


而上层应用端,2B 应用侧重于生产力提升,关注效率和成本,这也是比较容易说得清价值的。2C 应用的上限更高,但是难度也更大,目前比较火的有知识问答、AI 搜索等领域。

回到电商领域,商家为什么需要 AI


1688 是一个 B2B 起家的业务,这里有全中国最丰富的工厂类的商家,他们有很强的线下生产的能力,开模、生产、质量把控、物流交付无所不能。


但是,这些商家却严重的缺乏线上经营能力


就是我们的商家体质和现状,从商家视角来看,他们不懂运营,不熟悉规则,持续被头部商家剥削,他们的多数会逐渐走向流失。


从平台视角来看,这些商家始终不响应平台号召,无法更好的服务买家,也很难贡献商业化价值。


而 AI,给了我们这样一个契机。通过 AI 技术,让我们获取“智能”和“技能”的成本变得低廉。


由于当前的大语言模型具备了不错的通识技能和常识,并拥有了一定的推理能力,叠加上领域内数据的优化,我们完全可以创造出一个比大部分人更懂电商的智能体。

商家经营链路梳理和 AI 水位评估


我们梳理了商家电商经营的全链路,把商家的经营分成了 10 个大环节,50 个小环节,并对其中 AI 应用的水位做了评估。




图中,颜色越深代表着 AI 应用的深度越深。


可以看到,在流量运营、商品运营、广告投放等数字化程度较高的领域,AI 有较好的落地。但是在企业管理、供应链领域,AI 应用的程度还不深。

常被问的一个问题,你的目标客户是谁?


在项目的初期,很多人会问我们:你们的目标客户是谁?


对于这个问题,我们做了很多讨论和分析,有这样的结论。


  • 小公司或者创业团队,他们的目标客户一定是头部商家,因为只有这些客户有能力和意愿为他们的 AI 产品付费。

  • 对于平台来说,我们想服务的是腰尾的客户,正如前面所言,他们缺乏专业的运营团队,没有专门的运营对接他们,常常在生存线上徘徊。

  • 但是这些用户还是太多,所以我们又细化了 种子用户的画像,他们具备 3 个特征

  • :线上经营能力弱。这决定了提升空间大。

  • :线下生产能力强。这决定了提升天花板高。

  • :愿意花钱,愿意投入。这决定了可以用的手段多。


我们的演进路线:从流程智能化,到流程体验重塑


商家端 AI 我们做了一年多,前半段,我们重点在做 AI 工具,比如商品标题优化、素材优化、自动回复、广告投放等。


简单来说,就是把商家经营全链路上的事情,用 AI 重新做一遍



就这样做了半年,我们发现一个问题。借助 AI,商家的经营环节确实更简单了一点,但是,商家该有的动作一个没少


于是我们决定换换脑子,大家走访了很多商家和代运营公司,分析了这个产业,然后决定通过 AI 做出一个“代运营公司”,帮助商家简化他们的经营环节。


关键,我们还免费。


AI 经营托管的技术架构


我们除了向商家提供单点的 AI 工具以外,核心建设了 AI 经营托管,下面是一个产品截图。


整体思路是,从交付工具价值(处理多少张图片,生成多少个视频),改为交付结果价值(多少个新品破零、多少个新品起量,多少 GMV、多少买家数)。



这使得,我们可能是业界第一个通过 AI 直接向商家交付最终结果的团队。也意味着整体技术难度指数级上升。


打个简单的比方,以前只是提供道路保持能力就行,而现在,我们胆大妄为地踏入了自动驾驶的领域。



这是我们的技术架构图,整体的设计上,我参考了自动驾驶技术,因为我发现两者非常相似。


自动驾驶里,需要通过摄像头进行环境感知(识别道路、行人、红绿灯、其他车辆等),需要有路线规划能力,需要有决策系统,更要有执行控制系统来控制汽车部件(油门、刹车、方向盘等)。


我们也包含了决策规划系统,执行控制系统等,细节不必赘述,大家一看就懂。

什么是一个好的经营计划


对于我们提供的托管类产品来说,如何制定出一个科学的有效的经营计划(Plan)是困难但重要的。这需要同时具备有效性、专业性和可解释性。



在我们当前的方案里,首先会进行选品,不同的商品给出不同的方案。然后进入计划设计环节,会针对广告、营销等不同的方面制定经营计划。这里会针对整体费用做预估和控制,防止生成的计划产生资损。在执行阶段,通过 PID 和 RL 来控制线上运行的效果,保持计划执行的稳定性。


我们认为,一个好的经营计划,应该包含目标、时间、人群,品类、定价、营销等要素,综合成一个完整的经营方案。

自动优化图片落地中的踩坑实录


图片生成和优化,是 AI 落地的第一个场景。在电商领域,可控图片生成是重点工作。


我们团队并没有自研电商图像生成技术,主要是联合集团内团队和三方生态公司的方式提供图片 GC 能力。



在应用端,由于我们是托管模式,因此相比于工具模式(生成结果并交由商家选择),落地难度陡增。


相当于,我们除了要具备图片生成能力,还要有一套完整的判断图片优劣的上线流程。


这个环节中,如下图所示,我们做了如下工作。



在图片上线的过程中,我们解决了很多困难,比如图片产能的问题,生成效果问题,审核人力问题等。


我们也在实践的过程中发现,商品图片在美学上的“美”,并不等价于用户端的“好”,因此也联合算法团队建设了图片质量评价、CTR 预估等工作。


后续这块还会有专题的文章分享。

自动标题优化落地的版本迭代


标题 SEO 优化是另一个落地场景。这里我们做了三个版本的尝试。



第一版,我们尝试直接用大模型端到端输出,但是效果一般,因为商品的标题本身并不是一句“正常”的话,而是一堆关键词的堆砌,因此模型的表现并不好。


第二版本,我们放弃了用大模型直接输出,而是通过小模型产出一些可替换的关键词,比如热搜词等,然后再结合大模型做整合和标题重写。


这里有个有意思的数据洞察,我们分析了标题优化前后的效果,发现一个“失望”的事实,就是标题优化的效果很不明显。


这意味着,大部分的标题优化可能对商品最终的效果影响不大,我们的工作可能无法被商家感知到。但是,换个角度想,这同时意味着,我们可以适度地“瞎搞”,反正商家也感知不出来 [狗头]



在实践中,我们还遇到了一个问题,就是大模型对商品的理解能力不足,会导致一个商品明明是棉袜,但是我们会给它添加“丝袜”的关键词。这可能会带来新增的流量(因为可能是近期热点),但是会导致商家支付转化降低,以及可能会引起潜在的买家投诉。


所以我们利用多 Agent 来优化标题优化体验。



这里,我们采用了“六顶思维帽”的方法来优化。我们借鉴了其中的思路来进行多 Agent 联合优化。分别是负责事实新的白色帽子,负责乐观建议的黄色帽子,负责创新的绿色帽子,负责批判的黑色帽子,负责管理的蓝色帽子。还有一个负责情感的红色帽子,这里我们没用上。通过这六个 Agent 协作,产出最终的结果。


商家端对话任务介绍


B 端对话任务和 C 端对话任务的差异是,B 端对话任务更强调效率,不会有太多闲聊、娱乐的内容,重视专业性、准确性。


我们认为有三类问题需要重点去解决。分别是专业知识问答业务目标牵引经营数据分析。具体可见上图。


  • 专业知识问答解决领域专业问题的回答准确性问题。

  • 业务目标牵引解决指定目标下对话系统的目标导向问题。

  • 经营数据分析解决日常取数分析和复杂业务归因问题。


RAG 优化


在专业知识问答领域,最常用最好用的技术莫过于 RAG 了,对于 RAG 的优化,可以参考下图。



我们做的优化主要在两个环节:


第一,在索引阶段,我们做了 chunking 优化,针对大的 document 拆解成段落进行索引;同时在 query 时改写问题,这个后面也会介绍。


第二,在生成阶段,我们采用了更强的 embedding 模型,提升向量的表征效果;对于部分场景,采用多路数据源召回并做重排序,以及采用时间衰减因子来提升回答的实效性。综合使用这些方法,让我们的 RAG 效果在我们自己构建的评测集上,准确率从 40% 提升至 88%,大大提升了线上使用的体验。

多轮对话


对于第二个任务,我们主要依赖多轮对话来提升效果。下面是一个对话任务的流程图。


当用户发起提问的时候,会进行意图识别,先判断是单轮意图还是多轮意图,如果是单轮意图则需要细化是什么具体的意图,然后该用 RAG 就用 RAG,该调用工具就调用工具。


如果是多轮意图,则需要调用历史对话信息,输入到多轮对话中,然后触发问题改写,提升问题回答的质量。



多轮对话问题改写有几个常见的任务,以下是常见的改写情况,分为领域内改写,跨领域改写,跨领域跳转和追问场景。



对于多轮对话改写,我们内部称之为“伪多轮”,因为并没有真正使用大模型本身的长上下文能力。随着大模型本身的发展,以及越来越便宜的 token,“真多轮”在我们的场景内也得以应用。


这里说的“真多轮”就是指利用大模型本身的长上下文理解能力,自发的进行多轮对话任务。我们使用剧本方法来约束大模型的行为,保障特定任务下多轮对话不至于太发散。比如下面这个例子,用户在对话中咨询自己的店铺数据情况,这里会触发我们的剧本,剧本要求大模型分析用户的数据并牵引他开通我们的经营计划。于是大模型就会不断的牵引商家完成计划的开启,从而实现业务目标。


数据分析


第三个任务,数据分析,这是 B 端非常常见的应用场景。数据分析任务可以分为几个难度等级,最简单的就是昨天我的 GMV 是多少,这种任务通过 NL2SQL 可以比较容易的实现。关于 NL2SQL 的优化,网上已经讨论的很多了,这里我重点讨论一下 LV5 难度的问题,就是流量归因类型的问题。



为什么我的流量涨了,为什么我的流量跌了,为什么我的流量不涨不跌? 这是商家对我们的灵魂拷问。


流量归因类问题比较复杂,通常不是简单的通过 NL2SQL 任务可以完成。这里我们借鉴了蚂蚁团队的 Agent 分析框架 PEER Pattern,来更好的完成分析类任务。



在原先的方案中,对于这种复杂的分析类问题,如果直接通过大模型输出,通常会出现一个问题,就是车轱辘话。大模型会回答的面面俱到,但是讲不到要点上,给人一种“说了又好像没说”的感觉。本质上,这是归因能力欠缺导致的。


我们的解决方案,第一是尽可能地收集全面的数据并做好抽象,避免 token 爆炸,第二是利用 PEER Pattern 来提升归因的准确度。具体的方案可参见上图。


举个例子,利用新的方案,我们评估了一个商家的流量波动情况。这个商家近期的流量有激增,经过专家人工定位,发现是奥运会期间跳水冠军全红婵意外带火了夜光乌龟盲盒这样一个品类,而这个商家就是销售这个产品的,因此有流量上的异动。


通过我们新的方案,让大模型比较准确地捕捉到了外部事件这个因素,给出了“夜光乌龟”的归因定位。


后续展望


得益于整个 AI 生态的快速发展,外加团队一年多的努力,我们在商家智能经营领域取得了一些小小的成果。特别是对于 AI 经营托管这个命题,最初团队内部大家都不知道怎么做,业界也没有参考,我们都把它归属于“混沌”这个象限。随着时间的推移,经历过很多停滞、纠结、摸索后,我们找到了一些行之有效的路径。现在,我认为这个问题已经从“混沌”变成了“复杂”,部分任务甚至变成了“繁杂”



未来,依然有很多问题需要解决,比如经营计划的有效性问题,Agent 执行效果问题,风险控制问题等。我相信伴随着大家的努力,再叠上 AI 产业发展的 buff,这些问题都可以解决。



最后,对于这波 LLM 带动起来的 AI 产业发展,我认为目前还是极早期阶段,有几个观察:


  1. AI 产业链里目前的利润分布,基本还是在硬件公司和能源公司,大模型本身目前都很少有盈利的,应用端利润就更少

  2. AI 应用相对简单,基本上还处于拿着锤子找钉子的阶段,缺少复杂场景的 AI 应用落地

  3. AI 学术界和工业界依然更新很快,新的能力、应用层出不穷,这表明 AI 产业的活力比较高,势能较强


对于 AI 应用未来会在哪里产生质变,我觉得需要具备几个条件:


  1. 首先,要找复杂 + 重复的事情,复杂意味着 AI 优化的价值大,一个熟练的人和一个新手会有显而易见的差距。而重复,则意味着 AI 能改进的环节有多少。直觉上,复杂和重复是矛盾的,重复机械的活不会复杂。但是,即使是眼科手术这样精密复杂的活,手术流程和操作也是高度标准化的。复杂意味着流程多、繁杂、异常分支多、风险大,而重复意味着对于一个熟练的人来说,这些复杂只是应对了不同的 SOP 而已。很多领域都具备这个特点,驾驶、手术、电商运营。

  2. 复杂、重复之外,另一个最重要的要素是数据。这很好理解,有了数据,才有 AI 应用的基石。目前很多领域,其实是严重缺乏数据的,因此这些领域首先需要完成数字化的工作,这其实是一个枯燥而且漫长的工作,作为 AI 应用者,还是应当优先选数据化相对充分的领域。

  3. 最后,应用场景应该是受益于 LLM 发展的,而不是反之。我们看过很多早期的应用,比如帮人写 prompt,随着 LLM 的发展就消失了。


以上就是我们在 AI 应用上的实践和思考。欢迎一起交流,微信联系 hongshaorou2330


作者简介

刘祥宇,阿里巴巴淘天集团 1688 技术专家,商家智能经营团队和开放生态团队负责人。具备算法、工程、数据科学的交叉技术背景,在语言模型、工程架构、因果推断等领域均有实践经验,推动了 1688 自动化营销导购的技术和产品体系发展。目前带领团队负责 1688 商家 AI 托管经营项目,从 0 到 1 建设智能经营解决方案,并取得初步成效。

2024-11-11 11:355230

评论 2 条评论

发布
用户头像
目前在做相关的,请问如何联系作者哈
2024-11-12 08:42 · 广东
回复
看到最后,有作者的联系方式。微信号: hongshaorou2330
2024-11-13 15:48 · 湖北
回复
没有更多了
发现更多内容

Spring如何控制Bean的加载顺序

快乐非自愿限量之名

Java spring 后端

什么是云原生架构,我们该如何做好云原生安全,引领云计算时代的应用程序革新

德迅云安全杨德俊

爆爽,英语小白怒刷 50 课!像玩游戏一样学习英语~

Immerse

英语 学英语

inBuilder 低代码平台新特性推荐 - 第十八期

inBuilder低代码平台

低代码

IBM发布开源AI编程模型Granite Code

算AI

人工智能 AI AI编程

服务器托管与租赁的有什么区别

Finovy Cloud

服务器 服务器托管 服务器租

手把手系列!使用 Zilliz Cloud 和 AWS Bedrock 搭建 RAG 应用

Zilliz

AWS Zilliz zillizcloud Amazon Bedrock

Mybatis-Plus常见注解

百度搜索:蓝易云

sql 云计算 Linux 云服务器 Mybatis-Plus

克服 Prometheus 单值数据模型的局限性:GreptimeDB 的新路径

Greptime 格睿科技

数据库 sql Prometheus PromQL

金融大模型,要听见远方的风

脑极体

AI

MySQL面试二之binlog日志

Hunter熊

MySQL Binlog

当AI遇见低代码:数智化时代发展新趋势

不在线第一只蜗牛

人工智能 低代码 数智化

ETL中如何执行Python脚本

RestCloud

Python 脚本 ETL 数据集成工具

第六届·2024 MindSpore 量子计算黑客松热身赛赛题解读

华为云开发者联盟

人工智能 华为云 华为云开发者联盟 企业号2024年5月PK榜

Linux中的chsh命令及示例

百度搜索:蓝易云

云计算 Linux 运维 Shell 云服务器

SVN 合并到 Git 时有文件大于 100 M 被限制 Push

HoneyMoose

2023年TCL实业营收突破1,200亿元,同比增长13%

Geek_2d6073

DockerCompose部署es和kibana

百度搜索:蓝易云

Docker Linux 运维 ES 云服务器

浅析Jetty与tomcat区别

百度搜索:蓝易云

Java tomcat 运维 Web jetty

详解GaussDB(DWS)中的行执行引擎

华为云开发者联盟

数据库 华为云 华为云开发者联盟 华为云GaussDB(DWS) 企业号2024年5月PK榜

智谱AI亮相2024 ICLR,分享面向AGI的三大技术趋势

Geek_2d6073

聊聊微软Power平台

这届南京码农

低代码 SaaS Power Platform

苹果再失资深设计师,Jony Ive 团队基本离开;OpenAI 或于下周发布 AI 搜索丨 RTE 开发者日报 Vol.201

声网

低代码技术赋能未来乡村建设:创新与实践

快乐非自愿限量之名

低代码 信息化 乡村振兴

智能助手上线,大模型提供云服务专属顾问

Baidu AICLOUD

大模型 Copilot AI智能客服

Spring与Docker:如何容器化你的Spring应用

百度搜索:蓝易云

Java Docker spring Linux 运维

出海企业必备神器:海外云手机的秘密你了解多少?

Ogcloud

云手机 海外云手机 云手机海外版 国外云手机 跨境云手机

智慧公厕案例-深圳大梅沙海滨公园

光明源智慧厕所

智慧公厕

3个免费图片网站,助你轻松创建PPT素材库!

彭宏豪95

职场 PPT 在线白板 效率软件 素材库

Ubuntu系统编译OpenCV4.8源码

芯动大师

ubuntu 操作系统 编译

AI 托管商家经营: 1688 电商 AI 落地实战_AI&大模型_InfoQ精选文章