AI实践哪家强?来 AICon, 解锁技术前沿,探寻产业新机! 了解详情
写点什么

向量数据库失宠了?OpenAI 力捧检索增强生成(RAG)技术,对行业来说意味着什么?

  • 2023-11-13
    北京
  • 本文字数:3279 字

    阅读完需:约 11 分钟

大小:1.52M时长:08:51
向量数据库失宠了?OpenAI力捧检索增强生成(RAG)技术,对行业来说意味着什么?

在刚刚过去的首届 OpenAI 开发者大会上,OpenAI 不仅公布了新的 GPT-4 Turbo 模型,还推出了多项对现有功能的升级和融合,一系列新产品和新功能的发布让外界大呼过瘾。虽然其中重要内容很多,但一条具有革命性意义的消息让人很难不注意到:消除在某些用例中对纯向量数据库的需求。换言之,OpenAI 将提供一款 Retrieval 检索工具,用户已无需创建或搜索向量。

 

那么,到底什么是 Retrieval 检索工具?它和此前 OpenAI 使用的向量数据库有什么区别?

检索增强生成(RAG)到底是什么?

 

大语言模型尽管具有所有语言能力,但缺乏掌握“现在”的能力。 在快节奏的世界里,“现在” 就是一切。

 

基于大语言模型 (LLM) 构建的产品(例如 OpenAI 的 ChatGPT 和 Anthropic 的 Claude)非常出色,但也存在缺陷:

 

  • 它们的数据集是静态的——大语言模型在静态数据集上进行训练,该数据集仅在某个时间点是最新的。这意味着它们可能无法收集训练数据后发生的事件或发展的信息。

  • 缺乏特定领域的知识——大语言模型接受过通用任务的培训,这意味着它们不能访问某一家公司的私有数据或本地数据。它们只能根据接受过训练的知识生成响应,这可能会限制他们提供个性化或针对具体情况的响应的能力。

  • 幻觉“黑匣子”——很难理解大语言模型在得出结论时考虑了哪些数据来源。大语言模型有时会产生事实上不准确或毫无根据的信息,这种现象被称为“幻觉”。

  • 生产效率低下且成本高昂——很少有组织拥有财力和人力资源来生产和部署基础模型。


不幸的是,这些问题影响了基于大语言模型 (LLM) 构建的应用程序的准确性。而好在,这些问题都可以通过检索增强生成(RAG)来解决。

 

据悉,检索增强生成(RAG)一词来自于 Facebook AI 部门自然语言处理研究员 Lewis 等人在 2020 年发表的一篇论文中。这个想法是使用预先训练的语言模型 (LM) 来生成文本,但使用单独的检索系统来查找相关文档来调节语言模型。

 

也就是说,RAG 提供了一种方法,在不修改底层模型本身的情况下,用目标信息优化大语言模型的输出;有针对性的信息可以比大语言模型更及时也更聚焦某一特定组织和行业。这意味着生成式人工智能系统可以为 Prompt 提供更适合上下文的答案,也可以根据最新的数据提供这些答案。简而言之,RAG 帮助大语言模型(LLM)给出更好的答案。

 

在此之前,如果想要开发基于大语言模型(LLM)的应用,首先需要保证该应用能够识别相关数据(即存放在防火墙之后、或虚拟私有云之内的数据),这就需要用到 LangChain、Llamaindex 以及纯向量数据库等一整套工具组合。相关架构如下图所示:



使用 LangChain 与 Llamaindex 实现检索。

 

这一次,OpenAI 引入了名为 Assistants 的新概念,允许用户以低代码/无代码方式配置出类似的架构。这就消除了对纯向量数据库的需求,并将整个过程简化为两个步骤。此外,在 Assistants 助手创建完成之后,我们可以通过几行代码轻松加以访问。

 

再有,用户现在可以通过 API 向 OpenAI 发送其他文件,而且所能接收的上下文最多可达 128K token,相当于约 300 页的文本内容。在通过代码访问这些 Assistants 时,我们还可以向其提供最多 128 种工具的访问权限,包括调用外部 API 并接收返回的数据以供 Assistants 进行处理。

 

下面来看基于 Assistants 的新架构:

 


OpenAI 的 Assistant 助手与 Retrieval 检索工具。

 

以下是 OpenAI 在官方公告中关于 Retrieval 检索工具的重要说明:“此工具主要是利用我们模型之外的知识以增强助手,例如专有领域数据、产品信息或用户提供的文档。也就是说,您不再需要计算和存储文档嵌入、也无需实现分场和搜索算法。Assistants API 将根据我们在 ChatGPT 中构建知识检索的经验,对所用检索技术进行优化。”

 

未来几天之内,众多开发人员将着手测试这项新功能,并思考新架构之下 Llamindex 与纯向量数据库将往何处去。但这里需要强调一点,尽管新架构消除了个人/独立/业余开发者使用/购买纯向量数据库以构建新应用程序的需求,但大规模企业仍然掌握着 SQL、NoSQL、二进制、HDFS 等各种格式的 PB 级数据。

 

如果您是一家需要构建数据感知大模型应用的规模化企业,那么将仍然需要使用上下文数据库——即能够提供混合搜索(词汇与语义搜索)功能以存储和检索多种数据类型的数据库。但无论如何,看到 OpenAI 保持如此迅猛的发展速度仍然令人欣慰。

 

下图所示,为 OpenAI Retrieval 检索工具目前所能支持的文件类型。

 

RAG 技术的优越性及未来发展方向

 

说了这么多,到底 RAG 技术有哪些具体的优越性?归根结底,RAG 技术可用于提高生成式 AI 系统对提示的响应质量,而不仅仅是大语言模型所能提供的那些。具体的优势包括:

 

  • RAG 可以访问可能比用于训练大语言模型的数据更新鲜的信息;

  • RAG 知识存储库中的数据可以不断更新,而不会产生重大成本;

  • RAG 的知识存储库可以包含比通用大语言模型中的数据更关联上下文的数据;

  • 可以确定 RAG 的向量数据库中的信息来源。由于数据源是已知的,因此可以更正或删除 RAG 中的错误信息。

 

可以确定的是,如今,我们正处于 RAG 的早期阶段,目前该技术还仅被用于为查询提供及时、准确和上下文相关的响应。这些用例适用于聊天机器人、电子邮件、文本消息传递和其他会话应用程序。在未来,RAG 技术可能的方向是帮助生成式人工智能根据上下文信息和用户提示采取适当的行动。

 

RAG 也许还能协助处理更复杂的问题。例如,生成式人工智能或许能够告诉员工公司的学费报销政策;RAG 可以添加更多的上下文数据来告诉员工附近哪些学校有符合该政策的课程,并可能推荐适合员工工作和以前培训的课程——甚至可能帮助申请这些课程并发起报销请求。

 

纯向量数据库厂商何去何从?

 

尽管 RAG 技术有着种种优势,但一直以来 OpenAI 内部一直是向量数据库和 RAG 技术并行采用的状态。而在 OpenAI 发布了这份关于 RAG 技术的最新公告后,各家纯向量数据库厂商“坐不住了”。

 

有创业者调侃,“OpenAI 几乎把上半年的创业项目全都自己做了一遍,也彻底把创业者们打懵了。”

 

此外,一些唱衰向量数据库的言论也此起彼伏:“去死吧向量数据库”,“还要什么向量数据库缓存呢”,“还要什么 LangChain 中间件呢”?

 

在业内竞争已经十分激烈的环境下,OpenAI 的一纸公告给整个向量数据库行业又增添了一丝焦虑。

 

近日,Chroma 的联合创始人 Anton Troynikov 在接受外媒采访时讨论了 RAG 技术以及在传统数据库厂商虎视眈眈下,纯粹的向量数据库初创公司该何去何从的问题。

 

大模型爆火后,向量数据库成了一块人人都想进来分一杯羹的“香饽饽”。现有的数据库厂商也在竞相在传统数据库上增加向量存储功能,当被问及这是否会让 Chroma 和其他向量初创公司难以发展业务时,Anton 表示,“这样的想法太过局限了”。

 

Anton 观察到,Chroma 中存储的大部分数据以前从未存储在数据库中,这表明在一段时间内,至少在基础设施层将会出现大量此类数据,这类数据将为 Chroma 带来越来越多的价值。向量数据库可以让向量检索就变得像将文本转储到文本框中一样简单,这与人们目前使用聊天机器人的方式没有什么不同。这个领域即使有很多传统数据库厂商加入游戏,似乎也不影响 Chroma 取得伟大的成果。

 

而当谈及如今比较火的 RAG 技术时,Anton 表示要保持检索增强生成(RAG)技术在大模型内部循环运行,而不仅仅依赖于外部 API。

 

对于这些唱衰的声音,一位 IDswyx 的用户为在 X 上发表言论称:“对于今年向向量数据库投资 2.35 亿美元的公司来说,他们要的不是基础模型实验室 Sherlocking 和增加上下文长度这些基础功能,因为现有 SQL 和 NoSQL 数据库很容易增加向量支持,从而大幅减少 TAM。在 90%的重度用例中,数据的基本处理功能是占主导地位的。纯粹的向量数据库厂商必须竭尽全力在功能、DX 或性能方面进行创新和领先。”

 


参考链接:

https://medium.com/madhukarkumar/what-does-openais-announcement-mean-for-retrieval-augmented-generation-rag-and-vector-only-54bfc34cba2c

https://cookbook.openai.com/examples/fine-tuned_qa/ft_retrieval_augmented_generation_qdrant

https://arxiv.org/abs/2005.11401

trieval-augmented-generation-rag-and-vector-only-54bfc34cba2c

https://www.oracle.com/artificial-intelligence/generative-ai/retrieval-augmented-generation-rag/

2023-11-13 10:279422
用户头像
李冬梅 加V:busulishang4668

发布了 1114 篇内容, 共 728.5 次阅读, 收获喜欢 1257 次。

关注

评论

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

重学设计模式——你真的面向对象了吗?

黄林晴

设计模式

电商秒杀系统

tony

「架构实战营」

【愚公系列】2022年03月 Docker容器 Windows11安装Docker Desktop

愚公搬代码

3月月更

基于冬奥示范效应,数字孪生将助力建筑运维和集会安全运营

易观分析

数字孪生

在华外企高管谈政府工作报告:共享发展成就 未来机遇可期

科技新消息

DPDK uio 分析 丨DPDK的优势及学习总结

Linux服务器开发

Linux服务器开发 DPDK Linux后台开发 高性能网络 网络虚拟化

「国产替代」,真的是中国SaaS的发展路径吗?

ToB行业头条

英特尔Sierra Forest,市场最需要的能效核至强处理器

科技新消息

数字孪生:如何撑起一个万亿市场的产业变革?

知心宝贝

行业资讯 数字孪生 冬奥 3月月更

对容器在野安全问题的观测和分析

腾讯安全云鼎实验室

网络安全 容器安全 在野攻击

把家电科技产出摆出来!三家实力一目了然

脑极体

「前端CI/CD系列」第三篇:如何用建木CI构建前端项目并部署到CDN

Jianmu

开源 前端 CDN 七牛云 建木CI

堪比JMeter的.Net压测工具 - Crank 入门篇

MASA技术团队

C# .net 微软 测试 压测

GDP Streaming RPC 设计

百度Geek说

后端 RPC Go 语言

医疗数字化,星环科技ArgoDB+KunDB统一分布式数据库解决方案来了

星环科技

数据库 医疗安全

华为被卡脖子,到底卡的是什么?

坚果

金融数据查询增速三倍,服务器成本减半,海尔云链的 OLAP 引擎选型之路

StarRocks

数据库 数据分析 OLAP StarRocks

适用于企业的销售自动化CRM系统

低代码小观

销售管理 CRM CRM系统 客户关系管理系统 企业管理软件

2021年第4季度规模达1381.8亿元!跨境电商结合酒店场景将成亮点

易观分析

跨境电商

python方法——defaultdict详解

Wjq

Python 字典 3月程序媛福利 3月月更 defaultdict

2022官方文档部署MAVEN最新最全

北极的大企鹅

中间件 环境安装 部署与维护

基于 Apache ShardingSphere 构建高可用分布式数据库

SphereEx

Apache 开源 分布式 ShardingSphere SphereEx

专注自主研发,加速大数据基础软件国产化进程

星环科技

数据库 大数据 基础软件

【案例】替代进口数仓,星环科技助力北京银行建设新一代大数据平台

星环科技

数据库

网络安全kali web安全 Kali之msf简单的漏洞利用

学神来啦

网络安全 渗透测试 WEB安全 kali kali Linux

一日为期,极行千里 ——「企业级零代码黑客马拉松」正式启动报名

明道云

低代码 零代码 企业 黑客马拉松

直播预告 | PolarDB-X 动手实践系列——如何在 PolarDB-X 中优化慢 SQL

阿里云数据库开源

数据库 大数据 阿里云 开源 polarDB

两天两夜,1M图片优化到100kb!

沉默王二

Java

技术平台&应用开发专题月 | 如何打造强大的K8S集群

用友BIP

用友 用友iuap

WebGPU小白入门(一): 零基础创建第一个WebGPU项目

Orillusion

开源 WebGL 元宇宙 Metaverse webgpu

Flink 流处理在中信建投证券的实践与应用

Apache Flink

大数据 flink 开源 编程 实时计算

向量数据库失宠了?OpenAI力捧检索增强生成(RAG)技术,对行业来说意味着什么?_数据湖仓_李冬梅_InfoQ精选文章