HarmonyOS开发者限时福利来啦!最高10w+现金激励等你拿~ 了解详情
写点什么

AIGC 算法揭秘及产业落地应用分享

  • 2023-11-17
    北京
  • 本文字数:8787 字

    阅读完需:约 29 分钟

大小:4.28M时长:24:54
AIGC算法揭秘及产业落地应用分享

嘉宾 | 鱼哲、祝天刚

编辑 | Tina

 

智能客服一直被视为大模型最适合的应用场景之一,而京东在大模型出现后,不仅推出了京东言犀大模型,还利用这些模型升级了智能客服、交互式营销、数字人等产品,并在实际场景中逐步落地,取得了显著成果。在本次“极客有约”对话节目中,鱼哲和京东云言犀算法总监祝天刚讨论了大模型在智能服务领域的落地要点。

 

原视频地址:https://www.infoq.cn/video/idMMYqv5l7whyeZCj1bf

 

亮点:

  • 大模型在数据需求上相对较低,能够更接近端到端处理,生成结果更自然流畅,提供更好的用户体验。

  • 更新不仅限于基础模型的更新,还包括知识库的更新。

  • 使用大模型在某种程度上为我们提供了更多的可能性,但也引入了更多的复杂性。

  • 没有一个通用的模板或规则来告诉我们应该使用哪个模型。

  • 技术的选择应该基于深刻理解的业务需求,以确保问题得到最好的解决。

 

嘉宾简介:

鱼哲,Lepton AI 创始团队成员,产品负责人。

祝天刚,京东云言犀算法总监,主要负责智能客服、交互式营销等产品的算法研发,大模型应用落地等工作,产品服务于京东域内百万商家,域外政府、银行、企业等众多应用场景。

 

在哪些业务场景里应用了大模型

 

鱼哲:京东作为电商领域的佼佼者,在大规模模型的崭露头角后,不管是从商家端还是用户体验方面,表现都非常出色。我们今天将深入探讨京东在自然语言处理和客服技术上的挑战和应用场景。从京东云言犀的首页能看出京东非常贴近实际业务场景,呈现了多种实际业务场景的应用。在大模型技术流行之后,京东云言犀团队采取了哪些措施?京东是如何采纳这一技术的,以及如何将这些新技术应用到业务中的?

 

祝天刚:你刚才提到言犀似乎更贴近业务,这点我非常认同。我们部门坚持一个基本原则,即研究和探索应该源自实际业务需求。一旦我们做出研究并取得成果,我们必须将其应用到业务中,以评估技术在业务中是否能带来收益和价值,以及是否能影响更多人。

 

关于大模型的兴起,特别是在言犀和智能客服领域,我们也采用了一些新的技术。我的主要关注点是言犀,这是一个智能对话平台,我们在这个领域进行了许多工作。在对话过程中,涉及到问答和内容生成,机器人也主动提问。生成的内容不仅仅用于对话,还用于其他场景。因此,在客服对话和内容生成方面,我们进行了许多创新和尝试,并已将这些创新应用到实际业务中,有很多具体的落地应用。

 

鱼哲:在电商领域,客服介入在消费者和商家之间的互动中起着关键作用。无论是在消费者选择商品之前,还是在购买后,我认为客服在这两个环节中发挥着最大的作用。您可以详细展开一下,例如在售后环节中,我们目前是否尝试应用了 AIGC 或大模型技术?

 

祝天刚:客服工作可以简单地分为售前和售后两个基本流程。售前工作通常涉及引导和导购,而售后工作则更侧重解决咨询、商品使用以及各项售后相关问题。在售后工作中,主要方向是解答问题和问题解决。在解答问题时,我们努力提供实际的答案,这可能直接满足需求,也可能引导用户进入解决流程。售后工作可能涉及诸如产品质保和价格保障等问题,所以我们的目标是提供明确的解决方案。

 

另一个方面是质检,这不仅仅局限于对话。在售后,我们进行对话质量检测,以确保对话的质量,并监督保证下一次对话的质量。这有助于提高智能客服的体验,也可以在辅助人工客服起到作用。

 

最后,我们还进行对话后的内容分析,以引导下一次对话和提高客服效率。分析结果可以辅助客服或商家做出后续决策。

 

大模型给业务带来了哪些变化

 

鱼哲:电商领域的客服,特别是售后客服。这个领域虽然不能说非常成熟,但一直存在,一直在不断进行改进和创新。我想请问一下,你能否举一个具体的场景例子,说明在没有大模型之前,业务的效率或效果是怎样的?然后引入大模型后,业务的状态有何变化?我们想了解一下大模型在这个业务中到底有何显著改进,它带来了哪些变化?

 

祝天刚:客服领域,无论是否有大模型,都已相对成熟,尤其是在售后方面更为成熟。大模型的引入,究竟带来了什么改变?举一个经典例子,就像我刚才提到的,解答用户问题的过程。

 

在引入大模型之前,处理用户问题的意图分类或者叫意图理解的过程,通常需要依赖模型,甚至可能通过一些关键词来解决。这种方法虽然有一定的准确性,但泛化性能有限。

 

在传统“小”模型方法中,需要对训练数据进行构建,例如训练一个分类模型,以便将用户的问题分类为不同的意图。同样,回答用户问题的方式也需要模型的处理,因为售后问题的多样性,有的需要直接回答,有的需要引导用户执行一系列步骤来解决。对于这种情况,需要更精细的模型来处理。另一个挑战是训练数据的质量,它对模型效果产生直接影响。因此,传统模型训练需要高质量的训练数据,这是一个重要的工作。这也是传统“小”模型的一个特点。

 

现在,回到问题的核心,大模型是否具有优势?首先,大模型不需要高质量领域标注的训练数据,因为它已经在训练中积累了大量知识,并拥有丰富的指令来引导它进行训练。这使得它对训练数据的需求相对较低。

 

此外,大模型在处理流程方面也具有优势。传统的流程通常是由多个小模型组成的流水线,前一个模型负责一个阶段,然后传递给下一个模型。这种流水线形式可能存在错误传递和效率问题。大模型能够整合多个流程,可能更接近端到端的处理,直接生成结果。大模型通常是生成式的,它能够生成更流畅和人性化的答案,不像小模型那样需要将答案填充到模板中。

 

概括而言,大模型在数据需求上相对较低,能够更接近端到端处理,生成结果更自然流畅,提供更好的用户体验。这是大模型引入前后的一个显著区别。

 

大模型的优缺点

 

鱼哲:您刚刚提到了大模型的优点,但您也提到了我们需要考虑其优缺点。在使用大模型的过程中,您认为有哪些缺点,是否可以简要介绍一下?

 

祝天刚:大模型存在一些缺点。这个问题可以用一个比喻来说明。大模型就像一个有知识的年轻人,可以回答问题,但不是所有问题都能回答。有时,当问题涉及到他未涉及的领域时,可能会提供不准确的答案,或者根本不知道如何回答。虽然大模型具备理解问题和回答的能力,但在某些情况下,当问题不在其知识范围内时,会变得无法应对。

 

如果我们将大模型比作聊天伙伴,那么无论你问什么问题,它通常会提供一些合理的答案,逻辑上都可以接受。但当我们需要将其应用到更严肃的行业场景中,要求根据特定领域的知识来回答问题,而模型没有足够的领域知识时,就会出现问题。这时,控制大模型的回答,使其按照领域知识来回应变得更加困难。如果大模型类似于大学生,他可能会有自己的观点和思辨能力,而不是像小孩子那样听话。这会导致可控性降低,难以满足特定要求。

 

除此之外,大模型的使用需要更多的计算资源,这可能在资源受限的情况下造成问题。此外,大模型可能会在某些情况下提供不恰当的答案,增加了安全和伦理问题。

 

鱼哲:我有一个与实际体验相关的问题,例如,当京东的业务团队考虑采用新技术并保留当前 pipeline 时,您认为新技术在成本和效果方面是否足够有动力来使您选择停用之前 pipeline 并过渡到新的大模型?您对此有何看法?

 

祝天刚:在大模型、甚至模型出现之前,客服团队已经存在。也许随着大模型的引入,客服会变得更加智能化。

 

我们已经看到大模型在多个领域取得了成功,人们对其寄予厚望,希望它能在客服方面带来一些变化。但关键问题是,它将如何改变客服,大模型是会改变整个客服流程,还是只对客服流程的局部部分进行调整?我们是否应该先放下当前的 pipeline,专注于以大模型为核心构建全新的客服系统?目前,我们正在实践和探索两种方法。第一种方法是分析当前 pipeline,找出其中存在的问题。在某些部分,我们可能会发现普通或小型模型在某些环节达到了瓶颈。在这些局部,我们可以将这些节点合并成一个大模型,以提高整体性能。与此同时,我们也在努力探索另一种方法,即围绕大模型构建全新的客服架构和体验。这两种方法我们都在实践和探索中。

 

鱼哲:您刚才提到的是使用多个小型模型结合意图分析(或称为意图映射)的方法。我们可以理解为,如果我们今天有一个相对轻量的模型,它可能不需要像大模型那么庞大,而是可以与一系列较小的模型协同工作,构建一种 MOE 的架构,从而在解决特定业务场景时替代大模型的功能,前提是业务问题保持不变。

 

祝天刚:在某种程度上,用“替代”这个词也许有点绝对。根据我的理解以及我在实践中的观察,大模型的角色通常不是互相替代,而是相互配合。在我们明确了大模型的擅长和不擅长,以及小模型的优缺点之后,在这种相互协作中,有一些相对简单容易、无需高度拟人化的任务,小模型已经足够胜任。

 

对于那些需要更流畅表达、需要精细判断,或者在训练数据方面要求较高的任务,通过指令方式来执行,大模型可以派上用场。同时,根据不同业务领域的需求,我们也在尝试使用一些模型来单独解决特定任务,而整体任务则以 MOE 的形式合并和协同解决。总的来说,大、小模型之间并不是完全的替代关系,而是相互依存于整体业务特点,形成一种相互协作的关系。

 

大模型的幻觉问题

 

鱼哲:您刚才提到的大模型的可控性和幻觉问题确实是相当严重的挑战。就我了解的情况来看,业界在控制大模型的输出方面,通常采取以下方式,要么通过精细的提示工程,编写极为详细的指令,要么创建一种与相关度较高的内容的输入,或者使用 fine tuning 等方法来影响模型的输出。

 

在考虑不同技术使用方式时,我认为并没有一种方法是绝对最佳的,也不应认为某种方式能够完全取代其他方式。回到我们的业务场景,在京东,特别是在智能客服系统中,我们面临的业务挑战相对于传统聊天场景来说更为复杂。这是因为我们需要同时应对用户、京东的坐席客服以及商家等多个参与方的状态,将智能客服融入其中,形成一个四方互动的生态系统。在系统优化方面,您是怎么思考的,以满足多方需求?

 

祝天刚:在这个情境中,我们需要关注四个主要参与方:C 端用户,坐席客服,商家,以及引入的智能客服。这些参与方之间存在复杂的相互制约关系。用户希望获得准确、即时的答案。坐席客服需要迅速找到答案以回应用户的问题。而商家则期望回答用户问题的同时,分析用户的需求,并希望能够推广其商品。

 

现在,我们引入智能客服以满足这些参与方的需求。从技术角度来看,我们的首要任务是确保智能客服能够提供高质量和准确的答案。 对于用户来说,高质量的答案可以提供最佳的用户体验。对于坐席客服,我们需要提供可信赖的答案,同时在辅助判断和决策方面提供支持。商家方面,高质量的答案配合有关商品的推广材料,才能帮助他们提高转化率。 所以答得准是关键。

 

通用大模型和垂直领域模型

 

鱼哲:在面向各种不同行业并处理大量不同的产品 SKU 的情况下,我们是使用通用的大型模型,还是专门训练垂直领域的模型?如何做这方面的决策呢?

 

祝天刚:目前,我们采用一个通用的大型模型来支持所有商品品类。在此之前,我们曾尝试将机器人和模型分别应用于不同品类,例如大家电、服饰、鞋靴、箱包等,但后来我们发现这种结构不合理。分别为每个品类训练一个模型会导致资源浪费,因为其他领域的模型也需要这样的训练,例如搜索引擎的排序模型会面对更繁杂的品类。为了能够适应不同的品类,我们决定使用一个通用的大模型,这个模型需要拥有广泛的知识范围,以应对各种商品品类的需求。

 

对于一些特定品类,它们可能有一些特殊的要求。但即使在这些特殊领域,我们仍然使用基础模型加上特定领域后处理的方式来解决,这样可以在资源与效果之间达到一个平衡。

 

我们的目标是建立一个能够满足电商领域、零售行业各种需求的大型模型,该模型在基础模型的训练和指令微调中融入了电商数据,即京东言犀大模型,是一个产业大模型。

 

数据漂移问题

 

鱼哲:我很关注您刚才提到了模型的更新和数据漂移的问题。因为一旦模型训练完成,它就好像是一棵成熟的白菜,总有一天会烂掉。这就导致了数据漂移的问题,因此需要根据新数据进行模型的更新或微调,以更新模型的权重。在以前的系统中,为了追求数据的实时性,有些应用每隔一定时间就会更新一次模型,例如每隔 15 分钟或 30 分钟。

 

对于京东这样的平台,要保持基础模型的知识跟得上人们日益增长的需求,这是一项重要的挑战。我们需要不断迭代基础模型,以确保它保持最新。关于更新的周期,你们有没有评估过多久需要迭代一次?

 

祝天刚:我们确保更新不仅限于基础模型的更新,还包括知识库的更新。在客服领域,很多答案都是基于商家的知识库来提供的。我们的目标是确保模型具备基本的通识能力,就像之前提到的大学生的例子,大模型就像一名大学生,我们确保它具备了阅读理解和答题的能力。

 

如果我们将客服比作一个开卷考试,我们要求模型具备开卷考试的能力。我们提供一些材料,然后提出问题,模型能够根据提供的材料给出答案。当您提到与知识相关的更新时,这就像提供新材料给学生,只要大模型具备足够的理解能力和答题能力,不管提供的材料如何改变,它都可以应对。

 

总的来说,我们的京东言犀大模型是有产业相关的知识支持的,大模型在基础训练和指令微调时会根据特定领域的需求进行训练。而对实时的知识进行应答,主要表现在建立智能知识库应答上。

 

鱼哲:我对你们的知识库的构建方式很感兴趣。你们是使用了向量或者直接访问数据库等流行方法,还是采用了其他方式来进行知识的检索和召回工作?

 

祝天刚:当我们谈到知识库时,一种现在流行的方式是基于向量进行检索,但也有传统的召回方法,例如基于词或短语的检索,这些方法都有各自的优缺点。并不是说向量检索一定比词语检索好,它们各自有自己的特点和用途,我们现在采用的是二者相结合的形式,发挥他们各自特点的检索方式。

 

模型输出的评估难题

 

鱼哲:在京东的智能客服领域,有时候可以直接生成答案并提供给用户。然而,对于大型模型,控制其输出通常相对困难。这带来了模型输出的评估难题。在如京东这样规模庞大的环境下,如何更智能地进行评估是一个挑战。一种可能的解决方法是主观目视检查,即通过人工审查来判断效果。这种方式至少在主观上看起来准确。但在像京东这样的规模下,如何实现更智能的评估呢?

 

祝天刚:在评估大型模型时,我们需要明确评估的是什么。如果我们关注的是大模型的质量,业界有各种已被公认的评估方法,但这是否等同于大模型应用的效果是值得商榷的。实际上,更重要的是进行业务评估。客户反馈以及运营同学的反馈是重要的,如果他们认为大模型提供的答案更准确,那么这就是有效的评估。

 

在以前,业务指标通常是以问题回答的形式来衡量,比如问题应答覆盖率,它衡量了用户提出的问题中,有多少被回答了。大模型的引入不一定会导致这些指标的变化,但是大模型的引入可能会为用户提供除了答案之外的更多的原因和解释。在这种情况下,新的指标就需要被引入,来评估大模型带来的变化和新的收益,以及如何满足用户需求。

 

举例来说,如果用户询问水壶的容量,我们会告诉水杯容量是 1.5 升,并给出它适合几口之家使用。然而,如果问是否适合户外运动,那机器人可能在回答问题后,给出有关户外运动的建议。这种大模型带来的新的应答方式,能额外给用户带来对商品特点的更好的理解,以满足其需求。

 

大模型的成本问题

 

鱼哲:大模型领域已经出现了多个强者竞逐,但选择合适的资源和模型以满足特定任务的需求仍然是一个具有挑战性的问题。例如,相同的提示和数据集在不同的模型上可能表现不同,这意味着每次切换模型需要耗费较高的适配成本。京东有没有遇到过这样的问题,你们是如何解决的?

 

祝天刚:你提到的问题确实存在。即使我们称这些模型为“大模型”,实际上每个模型的架构和性能都可能不同。有些模型的架构可能是开源的,但也有一些模型并没有公开详细的架构信息。同时,相同的任务在不同的模型上可能需要不同的 prompt 才能达到相同的效果,这也是常见的情况。

 

使用大模型在某种程度上为我们提供了更多的可能性,但也引入了更多的复杂性。为了更好地理解和利用不同类型和品牌的大模型,我们需要不断进行实验和尝试。这需要一种灵活的方法,通过不断试验来理解不同模型的特点和优势,以便在特定任务上获得最佳性能。因此,没有一个通用的模板或规则来告诉我们应该使用哪个模型。这是一项需要根据具体任务和模型特点进行实验和探索的工作。为了提高效率,我们需要同时了解业务需求以及大模型的性能和特点,以便更好地进行任务适配和模型选择。这需要双向的理解和实践。

 

11.11 活动中会应用哪些大模型产品

 

鱼哲:在 11.11 这个特殊的购物节日期间,除了聊天形式,大模型在京东的应用还涉及哪些方面?

 

祝天刚:除了客服领域,大模型还在其他方面发挥关键作用。例如,在营销文案生成领域也用的到。为什么大模型在这个领域如鱼得水呢?首先,我们常常将大模型称为生成式大模型,因为它的模型原理天生擅长文本生成。因此,我们自然会尝试在这个领域的应用和探索。

 

以前的生成模型通常过于依赖训练数据。特别是在先前的序列到序列模型中,这种依赖性较为明显。如果你考虑从事文案生成的工作,你必须明确质量和风格的可控性等方面的要求。这些控制能力在很大程度上受训练数据的质量和规模所限制,因此,模型的性能上限直接关联到你所拥有的训练数据。

 

现在的大模型具有天然的生成潜力,其基础模型已经蕴含了广泛的知识。大模型的参数数量巨大,蕴含了丰富的信息,这意味着它可以在可控性和风格等方面更加灵活。这一切都可以通过适当的指令来实现,大模型擅长的一个场景就是通过指令影响生成内容,这使其成为处理文案生成等任务的理想选择。

 

此外,言犀多模态数字人在电商直播场景也有很多应用。在 11.11 期间,言犀虚拟主播已经在超过 4000 个品牌直播间开播,基于自研电商领域知识增强模型 K-PLUG,仅需在直播后台上传商品链接,便能够智能“阅读”商品详情,自动生成更真实、生动、可阅读性强的直播文案,24h 自动开播。

 

鱼哲:在营销文案生成中,是只负责生成文案,还是可能会包括生成商品的相关配图以及整个展示区的设计呢?

 

祝天刚:这两个方面是结合在一起的。既生成文案,又生成相关的图像,但需要说明的是,图像生成是由我的同事组负责的,而我负责生成文案。

 

如何应对技术的快速迭代

 

鱼哲:京东作为一家技术实力雄厚的公司,早在 2018 年就开始积极涉足大模型领域,并进行了相关技术积累。在这段时间内,大模型技术的认知和应用方式可能发生了一些变化。从 2018 年到现在,对大模型认知有哪些改变?

 

祝天刚:京东是一家在技术领域拥有深厚积累的公司。回顾过去几年,大模型的概念发生了显著的变化。以下是对于大模型认知演变的一些观察:

 

  1. 参数规模定义的变化:随着技术的进步,对于“大模型”这一概念的认知也发生了变化。在过去,亿级别参数的模型被认为是大模型,但随着时间的推移,百亿级、千亿级参数的模型已经成为新的标准。因此,"大"这个概念变得更加相对。

  2. 模型架构的多样性:大模型的架构也在不断演化。GPT 系列模型(decoder-only)目前是大模型的代表,但不同的研究方向和实践也在探索其他架构。例如,还有 encoder-decoder 型的模型,它们的参数规模和应用也在扩大。这表明大模型不仅局限于特定的架构,还涵盖了多种类型。

  3. 技术的突破和创新:技术领域不断创新,包括模型训练的并行方式,模型推理的加速,甚至模型服务的部署等工程化问题,也在不断法神该变化。

 

随着时间的推移,大模型的认知不仅涉及参数规模的变化,还包括模型架构和应用的多样性。这种多样性和不断的技术进步丰富了大模型领域,为不同领域的应用提供了更多可能性。

 

鱼哲:技术变化这么快,你自己是如何跟进这些技术的?有没有一个明确的 roadmap?

 

祝天刚:对于技术的持续跟进,我认为有一个经典的比喻,就是技术就像你手中的工具箱。假设你工具箱里只有一把锤子,你会发现无论遇到什么任务,似乎都是在处理钉子。即使明明有一个需要用锯子切断一段木头的任务,你仍然倾向于使用你手头唯一的工具,也就是锤子。这种情况下,你需要不断充实自己的技术知识,以及积极地了解业务需求,这样你才能明智地选择适当的工具,无论是锤子还是锯子。

 

当你同时拥有锯子和锤子这两个工具时,你必须在使用哪一个工具时做出决策。这个选择过程不仅需要技术洞察力,还需要深刻理解业务需求,以便判断哪个工具更适合解决问题。

 

在跟进技术时,我通常将业务需求放在首位,即去看到钉子和木头,努力深入理解各种业务问题,以便更好地选择或者丰富我的工具,即技术。同时,当我了解到新技术时,我首先思考这个技术是什么,它的优势在哪里,它可以解决哪些问题,以及它是否适用于我当前面临的挑战。

 

随着我掌握了新技术,我会将其应用于解决业务问题,有时甚至会改变问题的处理方式。继续沿用刚刚的比喻,假设我们正在使用锯子切割一段木头,当木头马上要锯完,还剩 5%就能断开的时候,如果你对技术和工具非常了解,你可能会决定停止使用锯子,而改用锤子,因为锤子可能更快速、更有效地完成任务,而且木头的切口也更平整。

 

总结来说,就是根据业务需求去探索新的技术,技术要用于解决问题;要深刻的理解业务需求和技术原理,灵活的使用技术解决业务问题。

 

在技术领域,我们必须不断学习、跟进新的发展。互联网的开放性为我们提供了学习和理解技术的机会,因为总会有人分享清晰的技术知识,也有人不断探索新的领域。我们应该积极主动地学习新技术。

 

此外,需要定期回顾自己的技术知识,确保技能保持最新,以适应不断演进的技术和业务环境。业务需求应该在技术之前,因为技术是解决业务问题的工具,而不是目标。

 

技术跟进和业务理解应该相互补充,构建一个螺旋上升的学习和应用过程。技术的选择应该基于深刻理解的业务需求,以确保问题得到最好的解决。

 

延伸阅读:

AIGC 编程:代码编程模型的应用与挑战

我,一个 95 后,从阿里辞职与贾扬清去硅谷创业

深度对谈:广告创意领域中 AIGC 的应用

文生图大型实践:揭秘百度搜索AIGC绘画工具的背后故事


2023-11-17 08:006078

评论

发布
暂无评论
发现更多内容

Docker 镜像构建之 docker commit

哈喽沃德先生

Docker 容器 微服务

数据隔离、访问授权,用好大数据为什么这么难?

华为云开发者联盟

大数据 数据湖 华为云 DLI 数据隔离

如何在3秒内打开一个网址

BabyKing

第 0 期架构师训练营第 4 周作业 1

fujin

爱技术爱折腾,想要编程到60岁--我的十年

盛安德软件

前端训练营(15)-动画

罗思雨

大前端

CUDA,cuDNN,pytorch 在win10环境下的下载安装

Qx

教程 PyTorch

一周信创舆情观察(8.10~8.23)

统小信uos

白板技术实践:在线教育平台如何保障课件数据安全

ZEGO即构

加密解密 OSS 鉴权

区块链钱包应用开发,数字货币钱包源码

13530558032

奈学:Executor线程池的概述

奈学教育

线程池 Executor

奈学:Executor线程池的概述

古月木易

线程池 Executor

有了MDL锁视图,业务死锁从此一目了然

华为云开发者联盟

MySQL 数据库 华为云 MDL锁视图 元数据

90%的开发都没搞懂的CI和CD!

禅道项目管理

ci DevOps 持续集成 持续交付 持续部署

实用!教学白板跨国低时延互动技术实现指南

ZEGO即构

OSS 全站加速 集群

Docker 之常见应用部署

哈喽沃德先生

Docker 容器 微服务

XSKY星辰天合助力中国五矿打造政企办公新标杆

XSKY星辰天合

第 0 期架构师训练营第 3 周作业2---总结

fujin

第 0 期架构师训练营第 4周作业 2--- 总结

fujin

LeetCode题解:20. 有效的括号,栈,JavaScript,详细注释

Lee Chen

大前端 LeetCode

浅谈业务系统设计哲学

滴滴普惠出行

技术揭秘:华为云DLI背后的核心计算引擎

华为云开发者联盟

大数据 spark 数据湖 华为云 DLI

JAVA,.NET项目开发难上手?Learun敏捷开发框架解君愁

Learun

架构重构之禅

ninetyhe

Java 架构设计 代码重构

区块链承兑支付系统开发,USDT入金支付系统

13530558032

合约跟单交易系统开发,交易所一键跟单模式搭建

13530558032

Week11总结

熊威

netdata安装到redhat7.6最简手册

橙子冰

netdata

第 0 期架构师训练营第3周作业1

fujin

组合模式

永续合约交易系统开发方案,合约交易所源码搭建

13530558032

温故知新——Spring AOP

牛初九

spring aop ioc

AIGC算法揭秘及产业落地应用分享_生成式 AI_Tina_InfoQ精选文章