金融场景中的指标体系建设与应用

导读 数势科技是企业服务赛道的新势力,采用新数智技术、新产品理念、新交付范式,结合业务 Know-how,致力于解决企业服务领域中的各种难题和痛点。数势的主要服务对象包括大金融、泛零售和新智能制造领域的优秀企业,专注于为客户提供经营决策和营销相关的数据智能产品。本文将分享金融场景中的指标体系建设思路,希望能够为大家带来新的启发。

主要内容包括以下几大部分:

1. 金融行业指标现状

2. 痛点->技术问题

3. 解法

4. 指标产品合作案例

5. Q&A

分享嘉宾|韩秀锋 数势科技 CTO 

编辑整理|张俊光

内容校对|李瑶

出品社区|DataFun

01

金融行业指标现状

1. 指标化经营是企业数据化经营基础

当前,整个市场已经从流量时代进入了存量竞争时代。特别是在金融领域,经过过去 20 多年的信息化和数字化建设,头部银行、证券和保险等典型金融客户已经积累了海量的数据。然而,如何有效利用这些数据来支持企业的经营、管理和决策,成为了一个亟待解决的大问题。在这个过程中,指标体系发挥着至关重要的作用。一个理想的企业经营模式是,从企业经营的大目标(北极星指标)出发,将目标拆解到各个部门、员工等业务单元。通过构建一个完善的指标体系,实现金融企业的数字管理模式,将每个部门、每个人的工作紧密串联起来。以指标作为指挥棒,确保每项工作和每个角色都能形成闭环。为了实现这一目标,企业需要建立一个统一、准确、高效、集中化管理的指标体系。这不仅是解决当前金融行业痛点的关键,也是推动金融企业持续发展的重要保障。2. 指标是实现企业战略目标的统一组织语言在现实环境中,金融行业的建设长期以来依赖于成熟技术,并投入了大量数据科技人才,通过自下而上或烟囱式的方式构建其基础架构。金融体系已经拥有很好的数字化基础,积累了庞大的数据量,展现出巨大的潜力。然而,尽管具备这些优势,金融行业在迈向智能化企业经营理念的道路上,仍然面临着数据孤岛、指标体系不统一以及难以适应业务变化等多重挑战和问题。

我们抽象出两个主要问题:数据的混乱和需求响应慢。在过往的金融企业数字化建设中,存在大量烟筒式的系统建设方式。根据对头部客户的调研和采访,大部分企业拥有数百个大小各异的业务系统,部门间的数据口径和定义存在明显差异。这种差异在单一部门或闭环业务单元内可能可以通过指标和数据驱动,而一旦涉及集团化管理,部门间的数据口径对齐就变得极为复杂,需要大量的往复沟通和对齐工作。此外,基于这样的数据基础设施,数据仓库中包含了大量的模型口径定义和各种 ETL 任务。在这样的环境下,业务迭代的周期和响应速度已无法满足数字化经营的需求。随着企业规模和数据的不断增长,这种矛盾将愈发凸显。02

痛点->技术问题

1. 痛点分析

从数据的生产和消费两个维度出发,我们重新理清了当前面临的主要痛点。
  • 在数据的消费端,无论是金融企业还是其他类型的企业,其核心都是管理团队和业务团队在进行数据消费。管理团队主要接触的是管理驾驶舱,这里的数据通过一系列复杂的数据加工管道和工作流形成,是管理者最为关注的信息。然而,他们面临的问题在于只能看到数据的表象,却难以深入探究数据的波动原因或进行下钻分析。当管理者需要基于数据进行决策时,他们可能会产生各种猜想和假设,但由于数据使用的灵活性不足,这些猜想和假设难以得到验证,这是管理团队用数的主要痛点。
  • 在数据的生产端,数据加工团队面临着海量且复杂的任务。随着企业规模的扩大,不同部门提出的临时性报表需求和数据加工需求不断增加,导致团队的工作积压严重。更糟糕的是,这些工作往往是一次性的,无法形成企业的数据资产和沉淀,这无疑是一种巨大的资源浪费。这是数据生产者的主要痛点。
2. 痛点具体表述

为了更形象地展现这些问题,我们对从不同企业收集到的典型痛点进行了一定的抽象和汇总,如上图中所示。从管理者的角度来看,数据并不直接等同于洞察或决策。他们面临的挑战在于如何准确解读这些数据,理解其背后的深层含义。然而,由于数据是通过一系列复杂的数据加工管道和分析师的人为处理得到的,其中可能会引入一些主观思考和误解,导致信息扭曲或损失。此外,数据处理的速度和效率也是数据消费过程中面临的重要挑战。3. 痛点问题抽象

我们观察到,尽管企业拥有庞大的数据资源,却未能充分发挥数字化经营的价值。这种供需冲突促使我们深入思考问题的本质。主流的数据管道和加工模式通常涉及多个环节和角色。决策者和业务人员基于经营理念和逻辑,对数据产生需求,这些需求随后被转译为具体的数据需求,并交由数据分析师处理。数据分析师与 BI 工程师协同工作,将业务需求转化为 BI 报表需求。BI 工程师再进一步与数据工程师沟通,明确报表对源数据的需求。而这些源数据通常受到数据管理部门的权限控制。经过这一系列定义和管理流程,数据工程师最终从数据源获取数据,在数据仓库中进行深度加工,形成数据集市,并最终生成报表,满足数据需求方。这一典型的数据加工管道涉及多个角色的交叉协作,流程冗长。其中,关键的矛盾在于每个数据交互环节都需要需求提出方和实现者之间进行信息口径的对齐,不同知识背景的人在沟通中很容易产生信息消耗和损失,需要不断纠偏,使得这一流程效率低下,并且信息损失、质量问题不可避免。03

解法

1. 痛点解法(数据右移、角色解耦)在当前大数据技术、大模型以及生成式人工智能技术迅猛发展的背景下,我们不禁思考:是否有可能实现数据从生产到价值的端到端交付?是否存在一种颠覆性创新方式,能够缩短各环节流程,甚至使环节参与者变为单一角色?这正是数势科技一直在探索的解决方案。我们将其定义为“数据右移、角色解耦”,旨在解决行业痛点,实现数据价值的最大化。

金融系统因其与资金紧密关联,对数据容错率有着极高的要求。无论是银行、证券还是保险,每一笔交易都需精确无误。在数据转化为决策、决策指导营销直至决策执行的过程中,数据的准确性和使用精度至关重要,这是行业的共识。金融体系汇聚了大量具备丰富知识和经验的业务人才,其知识密集度极高。然而,要求这些业务人员直接理解数据(即“业务知识左移”)确实面临巨大挑战,几乎难以实现。因此,我们提出了一个创新的解法:通过产品和技术实现“数据右移”。这意味着让数据建模和解读更加接近业务人员,使他们能够直接参与并操作。这样,数据分析师和 BI 工程师的角色将被解耦,数据消费者能够更直接地获取和使用数据的价值。如果这一路径得以成功实施,我们将真正实现数据价值的普惠化和民主化,让“人人用数”成为可能。这将大大提高金融系统的运行效率,同时降低对专业人才的依赖,推动整个行业的进步。(1)数据语义建在数仓

在技术理念层面,传统的数据指标加工流程涉及从上游业务系统抽取数据源,存储到数据湖中,并进一步将数据拉入数据仓库进行深度处理。在数据仓库中,执行典型的 DWD(数据仓库明细层)、DWS(数据仓库汇总层)以及 ADS(应用数据服务层)等分层建模加工。建立详细的数据口径、权限管理,以及上层对各级各层数据的抽象逻辑,这些都嵌入在数据仓库的复杂结构中。然而,对于非技术人员而言,这个数据仓库就是一个黑盒,其内部的复杂性和运作机制难以直观理解。尽管如此,这个黑盒的下游是企业 BI 大屏和各种典型数据应用场景。这就是传统的数据加工模式,它一定程度保证了数据的准确性和可靠运行,但也带来了技术复杂性、流程的冗长和非技术人员理解上的挑战。(2)数据语义建在仓外

数势科技秉承 HeadlessBI 的理念,这一理念与数智工厂的理念不谋而合,体现了当前企业对于低代码平台的共同期待。我们期望通过这一平台,将数据语义建在数据仓库之外,即构建一个强大的语义化指标平台。借助指标平台,我们的工作可以更加高效和灵活。在数据仓库中,我们只需进行基础的数据加工,如原子指标的构建,而将数据语义和元数据的管理转移到指标平台上。这样,在指标平台上,可以实现数据的管研用一体化,通过简单的拖拉拽即可完成指标的加工。这样企业就可以实现集中化的指标管理。在这一过程中,业务人员和数据管理人员可以直接参与指标的定义、管理和使用,无需依赖传统的数据分析师团队。此外,新平台上的指标加工实现了即用即建,极大地缩短了指标加工的周期,几乎可以趋近于零。基于 HeadlessBI 的指标平台理念,如果设计得当、产品力强大,它将为企业数据消费端的下游应用、Agent 和 BI 等带来更加便捷的体验。这不仅是数据价值释放的关键,更是实现数据建模可视化右移出仓的重要步骤。通过这一平台,业务人员、数据分析师以及其他对数据指标加工和价值释放有需求的角色都可以直接参与指标的开发,从而提升整个企业的数据驱动能力。2. 数据建模右移(1)HeadlessBI 和指标平台

  • HeadlessBI
数势科技致力于实现 HeadlessBI 和指标平台的核心价值。这背后的关键在于深入理解行业,将产品力抽象至极致,形成易于使用且功能强大的产品。当产品足够优秀时,使用门槛将大大降低,指标加工将变得优雅而高效。这一过程中,系统的稳定性和指标管理能力都至关重要,它们为未来大模型应用奠定了坚实基础。我们已成功交付数十家头部客户,并发布了行业首份指标平台白皮书。今年 5 月,我们更成为首家通过信通院认证的指标平台。
  • HME(指标计算引擎)
在服务众多客户的过程中,我们面临一个挑战:如何在满足消费端灵活性和速度的同时,降低计算和存储成本。这构成了一个“不可能的三角”。为解决这一问题,我们打磨出了 HME 指标计算引擎。它确保了我们的产品既具备秒级高性能,又保持优雅的产品能力,同时实现成本、效益最大化。
  • OLAP
对于 OLAP 选型,我们基于 Doris 和 StarRocks 进行了深度优化。这一技术路线选择,确保了我们在大数据处理和分析方面的性能优势。事实上,我们已通过第三方测试验证了这一点,相关测试数据在公网上,均可查阅。我们坚信,这一技术基础将为客户带来更高效、更稳定的数据分析体验(2)HeadlessBI 架构

典型的 HeadlessBI 架构分为三层。底层是物理层,利用 OLAP 技术(如使用外表等方式)将物理数据注册为基础元数据,并捕获基础颗粒度的指标。随后,通过深度理解客户业务逻辑和场景需求,实现指标加工的可视化操作,简化从数据准备到模型构建,再到指标开发的流程。使整个过程是低门槛、优雅且高效的,同时实现集中管理。构建好这一层后,向上提供通用的主流 API 接口,支持 BI 分析、大模型应用以及企业内部的自主数据查询,为其提供高性能、高并发、高吞吐以及高实时性的指标服务。为了满足上述需求,我们服务的客户数据规模常达 TB 甚至 PB 级别,用户数量更是数以亿计。处理如此庞大的数据量和满足客户的复杂分析需求,要求我们拥有高度技术抽象能力的指标引擎,以确保系统的高效运行和数据处理能力。(3)高性能虚拟计算引擎 V3.0

数势科技的指标引擎经过三代演进,现已达到 V3.0 阶段。最初,我们采用基于  Cube 或者大宽表的传统方法,这些方法虽能满足基本的取数需求,但存储成本高昂,空间利用率低下。随后,我们深入洞察不同业务和客户的使用场景,对指标和维度进行了高度抽象,并引入了类似数据集的预计算和预加工技术。这一改进在存储和性能上取得了显著的平衡,但灵活性受到了一定限制,并且在某些语义下仍存在数据冗余的问题。然而,我们始终致力于通过技术创新解决这些挑战,以提供更加高效、灵活且成本效益显著的数据解决方案。(4)HMEV3.0 基于 ROI 智能自迭代加速

HMEV3.0,作为新一代高性能指标引擎,采用了基于结果的后置数据预计算策略,实现了基于 ROI 的智能自迭代加速。这一策略的核心在于,系统通过注册数据的元数据和使用场景,能够自动诊断哪些指标在处理时速度较慢或无法及时生成。针对这些问题,系统会对相关数据进行有针对性的调优和预计算。一旦这些计算完成,新的查询请求到来时,系统会自动改写查询语句,利用已完成的预计算结果,从而显著提升查询速度。这种机制实现了企业数据使用的最小化预计算集合,并且具备自迭代能力。随着企业查询的不断进行,系统能够智能地识别出哪些预计算资源已经不再使用,并释放这些资源,以保持存储空间的优化利用。这种智能查询引擎的引入,使得企业在使用数据时能够体验到查询速度的不断提升,同时降低空间和存储成本,这正是我们持续迭代和优化的理想目标。3. 数据解读右移(1)数势科技 SwiftAgent

在拥有成熟产品和新设计理念的基础上,再加上底层加速引擎的技术支撑,我们进一步探索数据解读的右移。在企业中,数据的消费者可能是管理者、业务人员乃至全员,往往面临一个共同的挑战:他们可能不熟悉BI 工具,导致这一强大工具在企业中的普及度受限。然而,还有更多的人并不知道企业内哪些数据能为他们的工作带来帮助,也不知如何提出和寻找这些数据。即便我们提供了智能助手或与大模型交互的工具,他们也可能因不熟悉而难以利用。基于对行业痛点的深入理解,数势科技通过 SwiftAgent 致力于实现数据解读价值的右移。我们的目标是让企业的每一位数据消费者都能最大限度地挖掘和利用数据,了解哪些数据对他们当前的工作有益,并将这些数据转化为知识和决策支持,从而真正发挥数据的价值。(2)NL2SQL 存在效果瓶颈和性能风险

在当前的行业趋势中,主流技术思路之一是期望通过自然语言直接转换为 SQL 或 Python 代码,以满足数据查询需求。用户可以通过大模型将自然语言描述的数据需求转化为相应的查询语句,然后直接从数据仓库中拉取数据,得到反馈。然而,根据我们的评估,尽管 NL2SQL 的准确率在调优后,能达到百分之六七十的较高水平,但在实际应用中仍面临诸多挑战。首先,生成的 SQL 语句往往缺乏足够的调优,这可能导致查询性能低下,甚至无法正确执行。对于复杂的数据加工和计算任务,可能需要预计算支持,而 NL2SQL 系统通常无法直接处理这类需求。此外,即便能够生成并执行查询语句,频繁的实时查询也会对企业的存储和计算资源造成巨大压力,造成资源的浪费。同时,NL2SQL 技术还需要考虑学习成本、数据安全等一系列问题。因此,虽然 NL2SQL 技术具有一定的潜力和价值,但在实际应用中仍需面对诸多挑战和限制。(3)数势 NL2MQL 之路相比 NL2SQL 优势

鉴于 NL2SQL 在复杂查询场景下遭遇的诸多挑战和限制,数势科技采取了创新的解法,通过整合指标平台和智能代理(agent)的能力,成功实现了自然语言到指标(简称 NL2MQL)的转换,再将指标对应到 SQL,这一路径有效克服了 NL2SQL 的难题。以复杂的查询为例,随着查询复杂度的提升,NL2SQL 的实现难度急剧增加,甚至在某些场景下变得不可行。而数势科技的 NL2MQL 方案则通过先将自然语言转换为细颗粒度的指标语义,再将指标语义转化为 API 请求,最后通过指标平台调用取数 SQL,这一过程不仅确保了查询的准确性和高效性,还使得大模型的数据解读能力得以商业化落地。数势 NL2MQL 的优势在于其能够更精准地理解用户的查询意图,将自然语言转化为更符合业务逻辑的指标语义,进而通过高性能的指标平台快速生成并执行 SQL 查询。这种两段式的处理方式不仅提高了查询的准确性和效率,还降低了对存储和计算资源的消耗,为企业带来了更大的商业价值。此外,数势 NL2MQL 还具备高度的灵活性和可扩展性,能够轻松应对不同行业和不同场景下的数据查询需求。通过不断的优化和迭代,数势科技将继续推动 NL2MQL 技术的发展,为企业提供更高效、更智能的数据分析和决策支持。(4)指标平台+大模型,实现数据价值的端到端

通过多个客户的 POC 验证和交付实践,我们已经充分展示了指标平台与大模型结合后所带来的强大能力。这种结合使得数据质量和问题回答的准确率几乎达到了数据质量的上限,同时显著提升了性能,降低了学习成本,并确保了数据安全。在指标平台上,我们深入整合了数据的权限管理功能。通过与企业的组织划分、人员权限标签等系统紧密连接,我们能够实现从表、纬度、指标乃至更细颗粒度的权限控制。这种精细化的权限管理确保了数据的安全性和合规性,同时为企业提供了更加灵活和高效的数据使用方式。(5)Agent 架构运转流程我们的产品中的 Agent 是一个典型的多智能体解决方案。通过运用 TOT(Task Oriented Thinking)和 COT(Conversation Oriented Thinking)等先进的 Prompt 工程技术,Agent 能够精准地拆解问题,并实现协同决策。在运作过程中,Agent 会充分利用之前提到的指标平台,高效地调用相应的 Actions,获取数据后进行后验推理,并将结果准确、及时地呈现给客户。这一流程确保了数据处理的准确性和高效性,为用户提供了卓越的使用体验。(6)数势科技 SwiftAgent 流程图

这是数势科技 SwiftAgent 的一个典型请求流程图。当用户发出请求时,系统首先接收并处理这一请求。值得一提的是,我们采用 RAG(知识图谱构建方法)的方式,将企业的知识库无缝集成,确保企业内部指标口径的语言或工作语言习惯与指标平台保持一致,为大模型提供友好支持。随后,经过大模型的处理,请求会流转到工具调用部分。在这里,结合前面提到的指标语义平台,我们能够实现足够细颗粒度的 API 调用,确保数据的准确性和高效性。整个流程的设计旨在为用户提供卓越的使用体验,同时确保数据处理的高效和准确。(7)数势科技 SwiftAgent 创造性解决 5 大挑战

借助指标平台与数势科技研发的 Swiftagent 多智能体产品能力,我们成功实现了从数据生产到数据消费的端到端的数据价值流转,创造性地提出了应对五大挑战的解决方案。首先,针对分析准确性的挑战,我们认识到大模型在转换为 SQL 或代码时准确率不足,这限制了产品的实用性。因此,我们利用指标和标签的语义化产品,以及数据虚拟化技术,实现了数据价值的右移,从而显著提升数据分析的准确性。其次,数据全面性是另一个重要挑战。为了深入理解企业数据的语义,我们整合了多源异构数据,包括结构化和半结构化数据,以及企业内部知识库。这一举措有助于我们更全面地理解企业的数据结构。在人机融合创新方面,我们通过 SwiftAgent 产品的精细工程化,为用户提供了智能的数据推荐和洞察。无论用户是数据的消费者还是新手,我们都能通过权限管理、模糊提问、反问和追问机制等,帮助用户澄清问题,降低数据使用的门槛,释放更大的数据价值。此外,我们的模型还具备持续反思、积累和迭代能力,这是实现产品不断优化和进步的关键。最后,面对 LUI 交互模式下灵活取数的需求,我们引入了指标预计算 HME 技术。这一技术能够确保在足够灵活的取数场景下,仍然保持高性能的响应速度。通过这一技术,实现了企业数据价值的普惠化,让每个人都能轻松使用数据。04

指标产品合作案例

1. 某头部证券公司基于指标平台的经营分析平台建设

该案例涉及的是数势科技与某头部券商的合作,该券商在数据分析领域遇到了多个典型问题,包括分析准确性、数据全面性、人机融合创新等方面的挑战。数势科技通过其指标平台和 SwiftAgent 产品,为该券商提供了端到端的数据价值流转解决方案。2. 80% 的新增指标不依赖数据人员

随着我们的第一代和第二代指标平台相继成功实施,企业内部约 80% 的指标开发工作已经实现了通过拖拉拽式的零代码开发,直接由业务人员完成。这一过程中,平台提供了冲突检查以及指标全生命周期的质量管理功能,确保数据的质量与准确性。同时,我们将剩余约 20% 更为底层和复杂的数据工作交给了专业的数据工程师团队。他们运用自己的技术能力,专注于数据仓库的质量管理、生命周期维护以及更深层的数据管理,从而进一步提纯数据的价值。这种分工方式使得整个数据处理流程更加高效,缩短了管道、流程和时间,确保数据能够更快速、更准确地为企业创造价值。3. 面向业务人员的 BI 分析产品,随时随地修改卡片

基于这样一个可以灵活取数的指标平台,当下游 BI 产生新的数据使用需求时,业务人员可以直接在指标平台上通过简单的拖拉拽操作,快速配置所需的数据。4. 面向业务场景,低门槛灵活组装个性化看板

此外,指标平台还支持多种低门槛、灵活的组装方式,帮助业务人员轻松构建出各类指标的看板,实现数据的可视化展示和深度分析。5. 支持业务同学对话式进行数据分析,更好的智能化交互体验

通过 SwiftAgent 的强大能力,我们实现了数据使用的零门槛,让业务人员能够轻松上手。最后进行一下总结,数势科技始终秉持客户、用户至上的理念,通过技术和产品的创新,站在数据消费者的角度,为客户、用户提供端到端的解决方案,真正解决他们在数据使用上的难题。我们诚挚地欢迎感兴趣的同行共同探讨,期待通过我们的共同努力,让数据的价值实现真正的民主化、普惠化。感谢大家的关注与支持!05

Q&A

Q1请问方便说一下 agent 的底座模型是什么?自研还是开源?参数量级是多少?A1在国内,当涉及到大模型的部署,特别是面向 ToB 企业时,我们通常会遇到私有化部署的需求。在这个方面,我们与百川、智普紧密合作,共同探索和创新,以满足企业的特殊需求。然而,随着市场竞争的加剧和价格战的到来,我们注意到一个明显的趋势:越来越多的客户开始接受并倾向于使用大模型的 API 服务方式。为了顺应这一市场变化,我们也积极适配了各大主流平台,如通义、文心以及 OpenAI 等,以确保我们的服务能够覆盖更广泛的客户群体。无论是选择私有化部署还是 API 服务方式,我们都致力于为客户提供最优质、最符合其需求的解决方案Q2指标 Agent 在人效提升上有什么样的促进?比如让每个岗位更好地创造价值,而不是像工具人的值指标对齐。A2指标 Agent 在人效提升上起到了至关重要的作用,它不仅仅是对齐指标的工具,而是每个岗位创造价值的强大助手。正如我之前提到的,ChatGPT 这类聊天工具在处理通识性的问题时表现出色,但当面对专业性问题或期望其替代我们完成工作时,其能力便显得捉襟见肘。这正是 NL2SQL 等技术在应用中遇到的困境,尽管它们有着一定的准确率,但远未达到可以直接应用于工作的程度。然而,通过引入指标平台和 Agent 的结合,我们得以跨越这一障碍。这种方案不仅确保了数据的准确性达到了数据质量的上限,而且真正地对我们的工作产生了实质性的帮助。Agent 不再是一个简单的工具,而是成为了我们工作的延伸,它告诉我们数据的价值,并帮助我们将这些价值转化为知识和决策,进而形成企业的宝贵经验。对于不同的角色——新员工、资深员工、专家以及管理者——他们对数据的解读和洞察能力各不相同。但大模型的引入使得我们可以将企业的知识库与之挂接,让这个大模型在企业的应用中不断学习和提炼,变得越来越聪明。这不仅仅是一个数据分析的专家在训练 Agent,更是一个企业在训练自己的数据分析专家。这样的专家不再局限于某个特定的岗位,而是可以为每个需要数据的员工提供服务,即使他们不擅长提出专业问题,Agent 也能帮助他们最大化地利用手头的数据资源。因此,指标 Agent 的引入不仅仅是提升了人效,更是将数据的价值最大化、普惠化,帮助企业从数据中获取更多的洞察力和决策依据。这个过程已经超越了简单的效率提升,而是为企业的整体发展注入了新的动能。以上就是本次分享的内容,谢谢大家。


分享嘉宾

INTRODUCTION


韩秀锋

数势科技

CTO

13 年+百度产品和研发管理经验,原百度地图场景化业务总经理,具备出色的产品、技术团队管理能力和技术实操经验

往期推荐


弱监督建模技术在蚂蚁风控场景中的探索与应用

京东RaftKeeper2.1发布,让CK告别ZooKeeper!

Apache SeaTunnel——OLAP 引擎的数据动脉

DataFunCon北京站精彩回顾|附PPT 下载方式

数据在零售供应链领域的应用

在交叉小径的花园随机漫步

StarRocks 数据湖查询和迁移实践

基于大模型的群体智能解决方案

阿里妈妈获 NeurIPS 2024 比赛主办权,全球参赛选手报名启动!

RAG 标准和腾讯云 ES 的技术实践

点个在看你最好看

SPRING HAS ARRIVED

相关推荐

  • 7B最强长视频模型! LongVA视频理解超千帧,霸榜多个榜单
  • Meta开发System 2蒸馏技术,Llama 2对话模型任务准确率接近100%
  • 数据匮乏仍是通用具身智能面前的高墙吗?
  • 非法阻止员工披露AI安全风险,OpenAI严厉「封口协议」再遭举报
  • 直击真实的甲方AGI需求,人工智能赋能产业融通发展论坛顺利召开
  • AI大模型有望再扩1000倍!剑桥耶鲁康奈尔:PNN是变革关键
  • AI机器人伴侣成美国老年人新宠!美国每年花70万刀,失去爱人的84岁老人重新笑了
  • 设计师+AI,3个月就能完成一套千字中文字库@智琮科技
  • 明年,每个人都能零基础创作3D内容 | 对话VAST宋亚宸
  • 自动驾驶雨天也能平稳规划,北理港中文腾讯提出端到端学习道路几何图形
  • OpenAI被举报:非法限制员工披露AI安全风险
  • 揭秘快手可灵背后的「关键7人」
  • 台积电宣布2nm芯片,下周见!!!
  • 【Python】流程图神器PygraphViz详解
  • 多所985、双一流高校食堂,牵涉油罐车混装食用油事件
  • 快停下,Redis 都要被你玩坏了
  • 下周,我倒闭 2 年的小网站将重出江湖!
  • 以LLM+KG技术为核心打造四大版块:老刘说NLP技术社区对外持续纳新
  • 有趣的“分而治之RAG”- Speculative RAG实现策略:兼看20240713大模型技术总结回顾
  • SpringBoot+XXL-JOB:高效定时任务管理