User-Profile-Image
hankin
  • 5
  • Java
  • Kotlin
  • Spring
  • Web
  • SQL
  • MegaData
  • More
  • Experience
  • Enamiĝu al vi
  • 分类
    • Zuul
    • Zookeeper
    • XML
    • WebSocket
    • Web Notes
    • Web
    • Vue
    • Thymeleaf
    • SQL Server
    • SQL Notes
    • SQL
    • SpringSecurity
    • SpringMVC
    • SpringJPA
    • SpringCloud
    • SpringBoot
    • Spring Notes
    • Spring
    • Servlet
    • Ribbon
    • Redis
    • RabbitMQ
    • Python
    • PostgreSQL
    • OAuth2
    • NOSQL
    • Netty
    • MySQL
    • MyBatis
    • More
    • MinIO
    • MegaData
    • Maven
    • LoadBalancer
    • Kotlin Notes
    • Kotlin
    • Kafka
    • jQuery
    • JavaScript
    • Java Notes
    • Java
    • Hystrix
    • Git
    • Gateway
    • Freemarker
    • Feign
    • Eureka
    • ElasticSearch
    • Docker
    • Consul
    • Ajax
    • ActiveMQ
  • 页面
    • 归档
    • 摘要
    • 杂图
    • 问题随笔
  • 友链
    • Spring Cloud Alibaba
    • Spring Cloud Alibaba - 指南
    • Spring Cloud
    • Nacos
    • Docker
    • ElasticSearch
    • Kotlin中文版
    • Kotlin易百
    • KotlinWeb3
    • KotlinNhooo
    • 前端开源搜索
    • Ktorm ORM
    • Ktorm-KSP
    • Ebean ORM
    • Maven
    • 江南一点雨
    • 江南国际站
    • 设计模式
    • 熊猫大佬
    • java学习
    • kotlin函数查询
    • Istio 服务网格
    • istio
    • Ktor 异步 Web 框架
    • PostGis
    • kuangstudy
    • 源码地图
    • it教程吧
    • Arthas-JVM调优
    • Electron
    • bugstack虫洞栈
    • github大佬宝典
    • Sa-Token
    • 前端技术胖
    • bennyhuo-Kt大佬
    • Rickiyang博客
    • 李大辉大佬博客
    • KOIN
    • SQLDelight
    • Exposed-Kt-ORM
    • Javalin—Web 框架
    • http4k—HTTP包
    • 爱威尔大佬
    • 小土豆
    • 小胖哥安全框架
    • 负雪明烛刷题
    • Kotlin-FP-Arrow
    • Lua参考手册
    • 美团文章
    • Java 全栈知识体系
    • 尼恩架构师学习
    • 现代 JavaScript 教程
    • GO相关文档
    • Go学习导航
    • GoCN社区
    • GO极客兔兔-案例
    • 讯飞星火GPT
    • Hollis博客
    • PostgreSQL德哥
    • 优质博客推荐
    • 半兽人大佬
    • 系列教程
    • PostgreSQL文章
    • 云原生资料库
    • 并发博客大佬
Help?

Please contact us on our email for need any support

Support
    首页   ›   More   ›   正文
More

LangChain+RAG—构建知识库(一)

2024-06-05 10:44:32
4283  0 10
参考目录 隐藏
1) 大语言模型简介
2) 模型简介
3) 大语言模型特点
4) LLaMA 系列模型
5) 大型语言模型四要素
6) 大语言模型应用
7) 检索增强生成(RAG)
8) LLM面临的挑战有哪些
9) RAG技术的解决的问题
10) 长上下文处理能力会杀死RAG吗
11) RAG具备性价比
12) 1. 预训练:打造基石模型的挑战
13) 2. 微调:适配领域数据的策略
14) 3. 提示工程:优化输入的艺术
15) RAG VS Finetune
16) RAG / Finetune / BERT / GPT 之间的关系
17) RAG技术概述与原理
18) RAG系统的主要组件和工作流程
19) 检索引擎:数据的精准定位
20) 增强引擎:上下文的深度融合
21) 生成引擎:智能响应的构建
22) RAG工作流程的全景视图
23) 第一步,数据索引:构建检索的基石
24) 第二步,输入查询处理:理解并转化用户需求
25) 第三步,搜索和排名:找到最相关的信息
26) 第四步提示增强:丰富输入,提升输出
27) 第五步,响应生成:构建最终答案
28) 第六步,评估:持续优化的关键
29) RAG范式
30) 第一阶段,朴素RAG
31) 第二阶段,高级RAG
32) 第三阶段,模块化RAG
33) 新模块
34) 模块化 RAG 的优势
35) 预检索
36) 检索
37) 检索后
38) 生成
39) 向量数据库与Embedding模型
40) RAG 场景对向量数据库的需求
41) 向量数据库对比
42) Pinecone
43) Weaviate
44) Qdrant
45) Milvus/Zilliz
46) Chroma
47) LanceDB
48) Vespa
49) Vald
50) Elasticsearch、Redis 和 pgvector
51) 什么是Embedding
52) Embedding的重要性
53) 向量之间的距离
54) 1. 欧几里德距离度量(Euclidean Distance)
55) 2. 曼哈顿距离度量(Manhattan Distance)
56) 3. 余弦距离度量(Cosine Distance)
57) 4. 切比雪夫距离度量(Chebyshev Distance)
58) 如何选择嵌入模型
59) 常见的类Embbedding模型
60) Embbedding模型在RAG种的应用场景
61) 在哪里找到合适Embbedding模型?
62) Embbedding模型选型
63) 嵌入是如何生成的

阅读完需:约 78 分钟

大语言模型简介

模型简介

语言模型犹如一艘艘探索船,它们通过预测单词序列的概率,解码语言的奥秘。这些由人工神经网络构成的模型,经过海量文本数据的洗礼,不仅理解语言的本质,更能预测序列中的下一个单词。当我们将这些模型的参数规模扩大到一个全新的量级时,便诞生了所谓的大型语言模型(LLM),它们以其庞大的参数数量,学习语言中的复杂模式,为世界带来了革命性的影响。

预训练语言模型(PLM):NLP的瑞士军刀

在NLP的征途上,预训练语言模型(PLM)以其在处理各种任务时展现的卓越能力,成为了研究者们的得力助手。随着模型规模的扩展,研究人员发现,这不仅提升了模型的性能,更解锁了小规模模型所不具备的特殊能力。这种现象,就像是在AI的进化树上,找到了一个新的分支——大语言模型(LLM)。

大语言模型(LLM):AI进化的里程碑

LLM的研究揭示了一个有趣的现象:当模型的规模达到一定程度时,它们开始展现出一些被称为“涌现能力”的特质。这些能力在小规模的PLM中是难以观察到的。例如,GPT-3通过上下文学习(ICL)解决了小样本任务,而GPT-2则在这方面表现平平。ChatGPT的出现,更是将LLM的应用推向了一个新的高度,它在对话领域的卓越表现,让人们对通用人工智能(AGI)的实现充满了期待。

LLM与PLM:大小之间的质变

LLM与PLM之间的主要区别在于它们是否具备涌现能力,以及它们的使用方式和开发过程。LLM的出现,预示着人工智能开发和使用方式的彻底变革。研究人员和工程师需要紧密合作,共同解决在大规模数据处理和分布式并行训练中遇到的复杂工程问题。

大语言模型的涌现能力:AI的新技能

LLM的涌现能力包括上下文学习、指令遵循和逐步推理。这些能力使得LLM在解决复杂任务时表现出色,尤其是当它们通过思维链(CoT)提示策略来解决涉及多个推理步骤的问题时。

大语言模型的关键技术:构建AI的基石

LLM的成功,离不开一系列关键技术的发展,包括扩展定律、大规模训练、能力引导、对齐微调和工具操作。这些技术不仅提升了LLM的性能,更使得LLM能够更好地与人类价值观对齐,并利用外部工具扩展其能力。

大语言模型特点

具备涌现能力

LLM 的涌现能力被正式定义为 “在小型模型中不存在但在大型模型中产生的能力”,模型具有从原始训练数据中自动学习并发现新的、更高层次的特征和模式的能力,这是区别 LLM 与先前 PLM 的最显著特征之一。

类似物理学中的相变现象,涌现能力就像是模型性能随着规模增大而迅速提升,超过了随机水平,也就是我们常说的量变引起质变。

涌现能力可以与某些复杂任务有关,但我们更关注的是其通用能力。接下来,我们简要介绍三个 LLM 典型的涌现能力:

  1. 上下文学习:上下文学习能力是由 GPT-3 首次引入的。这种能力允许语言模型在提供自然语言指令或多个任务示例的情况下,通过理解上下文并生成相应输出的方式来执行任务,而无需额外的训练或参数更新。
  2. 指令遵循:通过使用自然语言描述的多任务数据进行微调,也就是所谓的 指令微调。LLM 被证明在使用指令形式化描述的未见过的任务上表现良好。这意味着 LLM 能够根据任务指令执行任务,而无需事先见过具体示例,展示了其强大的泛化能力。
  3. 逐步推理:小型语言模型通常难以解决涉及多个推理步骤的复杂任务,例如数学问题。然而,LLM 通过采用 思维链(CoT, Chain of Thought) 推理策略,利用包含中间推理步骤的提示机制来解决这些任务,从而得出最终答案。据推测,这种能力可能是通过对代码的训练获得的。

这些涌现能力让 LLM 在处理各种任务时表现出色,使它们成为了解决复杂问题和应用于多领域的强大工具。

训练数据大且难度大

基于海量数据(书籍、文章和对话)进行训练(TB级,甚至PB级),接受大量未标记文本的训练,可能达到数千亿个单词,GPT-3 使用 45 TB 的文本进行训练,而 Codex 则使用 159 GB 的文本进行训练。

常见的开源底座模型细节概览:

底座模型通常指的是作为基础的大型语言模型(LLM)架构,它为各种NLP任务提供了预训练的权重和结构。

在 2021 年,斯坦福大学等多所高校的研究人员提出了基座模型(foundation model)的概念,清晰了预训练模型的作用。这是一种全新的 AI 技术范式,借助于海量无标注数据的训练,获得可以适用于大量下游任务的大模型(单模态或者多模态)。这样,多个应用可以只依赖于一个或少数几个大模型进行统一建设。

大语言模型是这个新模式的典型例子,使用统一的大模型可以极大地提高研发效率。相比于每次开发单个模型的方式,这是一项本质上的进步。大型模型不仅可以缩短每个具体应用的开发周期,减少所需人力投入,也可以基于大模型的推理、常识和写作能力,获得更好的应用效果。因此,大模型可以成为 AI 应用开发的大一统基座模型,这是一个一举多得、全新的范式,值得大力推广。

可以参考

底座 包含模型 模型参数大小 训练token数 训练最大长度 是否可商用
ChatGLM ChatGLM/2/3 Base&Chat 6B 1T/1.4 2K/32K 可商用
LLaMA LLaMA/2/3 Base&Chat 7B/13B/33B/65B 1T/2T 2k/4k 部分可商用
Baichuan Baichuan/2 Base&Chat 7B/13B 1.2T/1.4T 4k 可商用
Qwen Qwen/1.5 Base&Chat 7B/14B/72B 2.2T/3T 8k/32k 可商用
BLOOM BLOOM 1B/7B/176B-MT 1.5T 2k 可商用
Aquila Aquila/2 Base/Chat 7B/34B – 2k 可商用
InternLM InternLM/2 Base/Chat/Code 7B/20B – 200k 可商用
Mixtral Base&Chat 8x7B – 32k 可商用
Yi Base&Chat 6B/9B/34B 3T 200k 可商用
DeepSeek Base&Chat 1.3B/7B/33B/67B – 4k 可商用
XVERSE Base&Chat 7B/13B/65B/A4.2B 2.6T/3.2T 8k/16k/256k 可商用

LLaMA 系列模型

  • LLaMA 官方地址
  • LLaMA2 开源地址
  • LLaMA3 开源地址

LLaMA 系列模型是 Meta 开源的一组参数规模 从 7B 到 70B 的基础语言模型。LLaMA 于2023 年 2 月发布,并于 2023 年 7 月发布了 LLaMA2 模型。LLaMA 模型使用了大规模的数据过滤和清洗技术,以提高数据质量和多样性,减少噪声和偏见。LLaMA 模型还使用了高效的数据并行和流水线并行技术,以加速模型的训练和扩展。特别地,LLaMA 13B 在 CommonsenseQA 等 9 个基准测试中超过了 GPT-3 (175B),而 LLaMA 65B 与最优秀的模型 Chinchilla-70B 和 PaLM-540B 相媲美。

新的 8B 和 70B 参数 Llama 3 模型是 Llama 2 的重大飞跃,并为这些规模的 LLM 模型建立了新的最先进技术。训练数据集比 Llama 2 使用的数据集大七倍,并且包含四倍多的代码。超过 5% 的 Llama 3 预训练数据集由涵盖 30 多种语言的高质量非英语数据组成。

大型语言模型由可能具有数千亿,数万个参数的神经网络组成,使它们能够学习语言中的复杂模式,一般来说,大型语言模型的大小为数十 GB。

训练基础模型需要上千块,甚至上万块高性能GPU才能完成。

大型语言模型四要素

大模型要素:算力、算法、数据、场景。 大模型是”大数据 + 大算力 + 强算法”结合的产物,大模型要到具体场景应用才能发挥最大的价值。

算力:AI的心脏

在AI的宏伟蓝图中,算力是那颗不断跳动的心脏。它决定了数据处理的能力,就如同血液的流动速度。芯片,作为算力的核心,其性能的优劣直接关系到大模型处理能力的速度。黄仁勋在2023年2月的财报会上提到,过去十年间,通过不断的技术创新和合作,大语言模型的处理速度实现了质的飞跃,提高了惊人的100万倍。

算法:AI的大脑

算法,作为AI的大脑,是解决问题的核心机制。不同的算法就像是通往解决方案的不同路径,而它们的效率和效果可以通过空间和时间复杂度来衡量。GPT,这个在Transformer模型基础上发展起来的明星,自2017年由Google提出以来,就在NLP领域掀起了一场革命。它摒弃了传统的RNN和CNN,以更好的并行性和更短的训练时间,在处理长文本时展现出了无与伦比的优势。

数据:AI的养料

数据,是算法训练的养料。在模型的早期训练阶段,需要大量数据的喂养,以形成模型的理解能力。而在中后期,数据的质量则直接决定了模型的精度。在机器学习的过程中,使用标注好的数据进行训练是至关重要的。数据标注是对原始数据进行加工处理,使其转化为机器可识别的信息。只有通过大量训练,覆盖尽可能多的场景,才能孕育出一个优秀的模型。目前,大模型的训练数据集主要来源于公开数据,如维基百科、书籍、期刊、Reddit链接、Common Crawl等。而在中后期,高质量数据的引入将显著提升模型的精度。例如,更加事实性的数据将提高模型的准确性,而更加通顺的中文语言数据将增强模型对中文的理解能力。此外,高质量的反馈数据也能提升模型性能,如ChatGPT采用的人类强化学习RLHF技术,通过专业的问题、指令和人类反馈排序等方式,加强了模型对人类语言逻辑的理解。最终,通过更精准的垂直领域数据,可以构建出更细分领域的专业模型。

场景:AI的舞台

大预言模型的应用场景众多,技术与场景的结合是诞生有价值应用的温床。从文本生成到语言理解,从机器翻译到智能对话,LLM在各个领域都有着广泛的应用。随着技术的不断进步和创新,LLM将在更多的场景中展现出其独特的价值,为人类社会的发展贡献AI的力量。

大语言模型应用

在当前的人工智能领域,大型语言模型(Large Language Models,简称LLM)已成为推动业务创新和操作效率的关键技术。通过在庞大的数据集上进行预训练,这些模型不仅展现出卓越的通用性和泛化能力,还极大地降低了人工智能应用的技术门槛。用户可以借助零样本或小样本学习迅速实现先进的应用效果,而“预训练+精调”的开发模式标准化了研发流程,显著降低了技术难度,促进了AI技术在各行各业的广泛应用。大型语言模型为企业带来的主要好处包括:

业务流程自动化

大型语言模型能够自动化处理多种业务流程,如客户服务、文本生成、预测和分类任务等。这种自动化减少了人工操作的需求,降低了相关成本,使员工能够将精力集中在更加核心和有价值的任务上。例如,在客户支持领域,通过自动响应客户的查询,大大提高了处理效率和客户满意度。

促进个性化交互

通过运用大型语言模型,聊天机器人和虚拟助理能够实现全天候的客户服务,这些系统能够分析和处理大量数据,深入理解客户的行为和偏好,从而实现高度个性化的交互。不论是在电子商务推荐、个性化营销还是内容创建中,这种个性化的能力都极大地提升了用户体验和客户忠诚度。

提升任务准确性

大型语言模型通过分析和处理大量的数据来提高任务执行的准确性,这在数据密集型的任务中尤为重要。例如,通过分析数千条客户反馈,模型能够精确地识别和归类客户的情绪和意见,无论是在市场研究、公关监控还是社交媒体分析中,都能够提供深入且准确的洞察。

检索增强生成(RAG)

检索增强生成(RAG)是指对大型语言模型输出进行优化,使其能够在生成响应之前引用训练数据来源之外的权威知识库。大型语言模型(LLM)用海量数据进行训练,使用数十亿个参数为回答问题、翻译语言和完成句子等任务生成原始输出。在 LLM 本就强大的功能基础上,RAG 将其扩展为能访问特定领域或组织的内部知识库,所有这些都无需重新训练模型。这是一种经济高效地改进 LLM 输出的方法,让它在各种情境下都能保持相关性、准确性和实用性。

检索增强生成技术(Retrieval-Augmented Generation)受到了广泛关注,并被应用于各种场景,如知识库问答、法律顾问、学习助手、网站机器人等。

LLM面临的挑战有哪些

尽管ChatGPT和Claude等LLM展现了令人印象深刻的能力,但它们也面临着一些挑战:

  • 产生臆想的答案(幻觉):在没有确切答案的情况下,LLM可能会产生误导性信息。
  • 知识更新慢:当用户需要基于最新情况的具体响应时,LLM可能提供过时或不具体的信息。
  • 知识来源缺乏引用:LLM可能引用非权威来源的信息,影响回答的准确性。
  • 术语混淆:不同训练数据中相同的术语可能指向不同概念,导致LLM产生混淆。
  • 领域专业知识不足: 尽管LLM拥有广泛的知识基础,但它们并不了解特定业务的细节,如公司的私有数据。

RAG技术的解决的问题

  • 避免“幻觉”问题:RAG 通过检索外部信息作为输入,获取领域特定的知识,辅助大型模型回答问题,这种方法能显著减少生成信息不准确的问题,。
  • 信息的实时性: RAG 允许从外部数据源实时检索信息,RAG允许LLM访问最新的客户记录、产品规格和实时库存信息,解决知识时效性问题。
  • 解决黑匣子问题:RAG技术使GenAI应用程序能够提供其使用的数据来源,增加透明度,类似于学术论文中的引用,增加回答的可追溯性。
  • 数据隐私和安全: RAG 可以将知识库作为外部附件管理企业或机构的私有数据,避免数据在模型学习后以不可控的方式泄露。
  • 降低应用成本:RAG提供了一种经济高效的方法,使得组织能够在不重新训练模型的情况下,提升LLM的输出质量。

长上下文处理能力会杀死RAG吗

长上下文处理能力的提升确实为大型语言模型(LLMs)带来了显著的进步,尤其是在处理长篇文档和复杂查询方面。然而,尽管LLMs的上下文长度得到了扩展,RAG(Retrieval-Augmented Generation)依然保有其独特的价值和应用场景,并不会完全被长上下文处理所替代。以下是RAG保持其重要性的几个关键优势:

  • 白盒模型的透明度和可解释性:RAG的工作流程相对透明,模块之间的关系清晰,这为模型的效果调优和可解释性提供了优势。在检索召回的内容质量不高或置信度不足时,RAG系统有能力避免生成误导性信息,选择不生成回答而非提供错误的信息。
  • 成本效益和响应速度:与微调模型相比,RAG的训练周期更短,成本更低。与长文本处理相比,RAG能够提供更快速的响应和更低的推理成本。在工业界和产业应用中,成本是一个至关重要的因素,而RAG在这一点上具有明显的优势。
  • 私有数据管理与安全性:RAG通过将知识库与大型模型分离,为私有数据的管理提供了一个安全的实践基础。这种方法有助于企业更好地控制和管理其知识资产,同时解决了知识依赖问题。此外,RAG底座数据库的访问权限控制和数据管理相对容易实现,而这对于大模型来说则较为困难。
  • 灵活性和适应性:RAG能够适应不同的数据源和检索需求,为特定领域或任务提供定制化的解决方案。这种灵活性使RAG在多种应用场景中都能找到其适用之处。
  • 模块化和可扩展性:RAG的模块化设计允许它轻松集成新模块或调整现有模块之间的交互流程,以适应不断变化的任务需求和数据环境。

因此,尽管长上下文处理为LLMs带来了新的机遇,RAG仍然在多个方面保持其独特的价值和应用潜力。在未来,RAG可能会继续与长上下文处理和其他先进技术相结合,共同推动自然语言处理技术的发展。

RAG具备性价比

如果没有RAG那么,我们处理之前提到问题还能通过以下方式进行处理

1. 预训练:打造基石模型的挑战

在AI的征途上,构建基础模型的第一步便是资金的筹集。对于大多数企业而言,这是一个几乎不可能完成的任务。OpenAI的Sam Altman曾估算,训练ChatGPT背后的基石模型成本高达1亿美元。除了原始的计算成本,人才的稀缺性同样令人头疼:你需要一支由机器学习博士、顶尖系统工程师和高技能操作人员组成的梦之队,来攻克生成此类模型及其每个模型所面临的众多技术难题。全球的AI公司都在争相抢夺这些稀有人才。获取、清洗和标记数据集以生成功能强大的基础模型,是另一个挑战。以法律发现公司为例,如果你打算训练模型以回答有关法律文件的问题,那么还需要法律专家投入大量时间来标记训练数据。

2. 微调:适配领域数据的策略

微调,即根据新数据对基础模型进行再训练,无疑是一种成本相对较低的方法。然而,它同样面临着与创建基础模型相同的诸多挑战:稀缺而深入的专业知识需求,充足的数据资源,以及在生产中部署模型的高昂成本和技术复杂性。LLM与向量数据库的结合,用于上下文检索,使得微调成为一种不太实用的手段。一些LLM提供商,如OpenAI,已不再支持对其最新一代模型进行微调。微调,作为提升LLM输出质量的传统方法,需要主题专家进行重复、昂贵且耗时的标记工作,并持续监控质量的漂移,以及由于缺乏定期更新或数据分布变化导致的模型准确性的偏差。随着时间的推移,即使是经过微调的模型,其准确性也可能下降,这就需要更昂贵且更耗时的数据标记、持续的质量监控和重复的微调。

3. 提示工程:优化输入的艺术

提示工程,即精心设计和调整输入到模型中的指令(prompts),以引导模型执行特定的任务或操作,是提高通用人工智能(GenAI)应用程序准确性的一种成本较低的方法。通过简单地更改提示,可以快速迭代和更新模型的输入,而无需重新训练整个模型。通过快速工程,可以优化模型返回的响应,使其更加准确和相关。尽管提示工程可以改善模型的响应,但它并不能为模型提供新的或动态的上下文信息。这意味着如果模型的输入仅依赖于静态的提示,它可能无法考虑到最新的信息或环境变化。由于缺乏最新上下文,模型可能产生与现实不符的输出,这种情况被称为“幻觉”(hallucination)。幻觉是大型语言模型在生成文本时可能遇到的问题之一,尤其是在需要最新信息的任务中。RAG 优势的一个示例 ChatGPT 可以解决超出训练数据范围无法回答的问题,并生成正确的结果。该技术通过获取外部数据来响应查询来补充模型,从而确保更准确和最新的输出。

RAG VS Finetune

在提升大语言模型效果中,RAG 和 微调(Finetune)是两种主流的方法。

微调: 通过在特定数据集上进一步训练大语言模型,来提升模型在特定任务上的表现。

特征比较 RAG 微调
知识更新 直接更新检索知识库,无需重新训练。信息更新成本低,适合动态变化的数据。 通常需要重新训练来保持知识和数据的更新。更新成本高,适合静态数据。
外部知识 擅长利用外部资源,特别适合处理文档或其他结构化/非结构化数据库。 将外部知识学习到 LLM 内部。
数据处理 对数据的处理和操作要求极低。 依赖于构建高质量的数据集,有限的数据集可能无法显著提高性能。
模型定制 侧重于信息检索和融合外部知识,但可能无法充分定制模型行为或写作风格。 可以根据特定风格或术语调整 LLM 行为、写作风格或特定领域知识。
可解释性 可以追溯到具体的数据来源,有较好的可解释性和可追踪性。 黑盒子,可解释性相对较低。
计算资源 需要额外的资源来支持检索机制和数据库的维护。 依赖高质量的训练数据集和微调目标,对计算资源的要求较高。
推理延迟 增加了检索步骤的耗时 单纯 LLM 生成的耗时
降低幻觉 通过检索到的真实信息生成回答,降低了产生幻觉的概率。 模型学习特定领域的数据有助于减少幻觉,但面对未见过的输入时仍可能出现幻觉。
伦理隐私 检索和使用外部数据可能引发伦理和隐私方面的问题。 训练数据中的敏感信息需要妥善处理,以防泄露。

RAG / Finetune / BERT / GPT 之间的关系

具体来说,以下是这些概念之间的联系:

  • Finetune(微调):这是一种技术,通常用于预训练语言模型(如BERT或GPT)在特定任务或领域的适应过程中。通过使用一个大型且高质量的标记数据集,可以对预训练的语言模型进行额外的训练,使其更好地理解和处理特定类型的数据或问题。
  • RAG(Retrieval-Augmented Generation,检索增强生成):这是另一种方法,它通过使语言模型在生成过程中能够访问和利用外部知识源来提升其能力。与Finetune不同,RAG不依赖于大量的标记数据,而是依赖于能够检索相关信息的能力,以辅助模型生成更准确的输出。
  • BERT(Bidirectional Encoder Representations from Transformers):BERT是一种预训练的语言表示模型,它在多种自然语言处理任务中表现出色。BERT模型可以通过Finetune的方式进行适应,以便更好地处理特定任务的数据。
  • GPT(Generative Pre-trained Transformer):GPT是另一种预训练的语言模型,它强调了生成能力。与BERT类似,GPT也可以通过Finetune来适应特定的任务或领域。

综上所述,RAG和Finetune是提高预训练语言模型性能的两种方法,它们可以单独使用,也可以结合使用以发挥各自的优势。而BERT和GPT则是具体的预训练语言模型实例,它们可以通过Finetune来适应特定任务,并且理论上也可以与RAG技术结合使用。

RAG技术概述与原理

幻觉现象在大型语言模型(LLM)中主要因其无法访问最新信息而产生,这一问题根源于模型对其训练数据集的严重依赖。为了解决这一局限,提出了一种名为RAG(Retrieval-Augmented Generation)的方法,该方法允许LLM通过外部信息源动态地补充训练数据,从而提高回答的准确性。

RAG通过结合传统的检索方法和预训练的语言模型,实现了对LLM输入信息的实时更新,避免了对模型进行昂贵且耗时的微调和再训练。这种方法增强了模型的灵活性和扩展性,使其可以轻松地应用于不同的LLM,满足多样化的需求。

在实际应用中,RAG通过引入人类编写的现实世界数据作为信息源,不仅简化了回答生成过程,还大幅提高了生成响应的可靠性。随着技术的进步,RAG不断发展,已经能够支持检索与生成组件之间的多轮交互,通过多次迭代检索提高信息准确性,同时逐步优化生成的输出质量。

平台如langchain和llamaindex已经对RAG方法进行了模块化处理,这些平台通过实现多轮搜索迭代到连续生成的不同策略,提高了方法的适应性,并扩展了其在实际应用中的范围。这些创新表明,尽管各平台对RAG的具体实施方法各不相同,但它们都遵循了基本的RAG工作流程,展示了这一技术在现代AI应用中的广泛适用性和有效性。

一个典型的 RAG 应用主要包含两个部分:

  • 第一部分: 索引
  • 第二部分: 检索与生成

第一部分 索引:

从源数据中加载数据并进行索引,通常离线进行,并且支持动态更新,分为:

  1. 加载:根据不同的数据源选择合适的加载器,加载数据得到文档。
  2. 切分:使用文本切分器将文档切分成更小的片段,使用小片段一方面可以更好地匹配用户问题,同时也可以适应模型的有限上下文窗口。
  3. 存储:存储和索引切片,以便在检索时能够快速找到相关的数据,通常使用 Embeddings 模型和向量数据库(VectorStore)来完成。

第二部分 检索与生成:

实际的 RAG 链,接收用户问题,从索引中检索相关数据,基于问题和这些数据生成结果,分为:

  1. 检索:给定用户输入,使用检索器从存储中检索相关的切片。
  2. 生成:使用包括问题和检索到的数据的提示调用 LLM 来生成答案。

RAG系统的主要组件和工作流程

RAG(Retrieval-Augmented Generation,检索增强生成)系统是一个将生成式AI的优势与搜索引擎的功能相结合的复杂系统。要深入理解RAG,关键在于剖析其核心组件以及这些组件是如何协同工作的,以提供无缝的AI体验。

检索引擎:数据的精准定位

RAG过程的首步是检索引擎的介入。这一环节涉及对庞大的信息库进行搜索,以定位与输入查询相匹配的相关数据。检索引擎运用精细的算法,确保所检索到的信息不仅相关性强,而且保持最新,为生成准确的响应打下坚实基础。

增强引擎:上下文的深度融合

检索得到的相关信息随后被送入增强引擎。这一引擎的职责是将检索到的数据与原始查询紧密结合,从而扩充上下文的深度,为生成过程奠定一个更加明智的基础。增强引擎的介入,使得生成的响应更加精准和全面。

生成引擎:智能响应的构建

最终,经过增强的输入信息被送入生成引擎。这里,通常是利用复杂的语言模型,基于扩充后的上下文创建出既连贯又紧密相关的响应。这种响应的生成,不仅依托于模型内部的先验知识,还通过检索引擎提供的外部数据得到了显著增强。

RAG工作流程的全景视图

RAG的基本工作流程始于创建一个包含外部信息源的索引库。这个索引库是检索器模型的基石,它根据特定查询检索出相关的信息。在这一过程的最后阶段,生成器模型将检索到的信息与原始查询融合,形成最终的输出结果。

RAG(Retrieval-Augmented Generation,检索增强生成)应用程序的成功依赖于一系列精心设计的步骤,确保了输出的准确性和相关性。以下是RAG系统关键步骤的深入分析。

第一步,数据索引:构建检索的基石

在RAG系统中,数据索引是基础。它涉及将文档分割成块,编码为向量,并存储于向量数据库中,为检索引擎提供参考点。文本规范化,包括标记化、词干提取和停用词去除,是增强文本适用性的重要步骤。深度学习技术的应用,特别是预训练的语言模型(LM),为文本生成语义向量表示,极大地提升了索引的效率和检索的精确度。

第二步,输入查询处理:理解并转化用户需求

用户的输入是RAG过程的起点。系统需要准确处理和理解这些输入,以形成检索引擎的搜索查询。这一步骤是确保检索结果与用户需求高度相关的关键。

第三步,搜索和排名:找到最相关的信息

检索引擎根据输入查询的相关性对索引数据进行搜索和排名。利用语义相似性,检索与问题最相关的前k个块,这一步骤是RAG系统的核心,它决定了后续生成响应的质量和相关性。

第四步提示增强:丰富输入,提升输出

将检索到的最相关信息与原始查询结合,形成增强的提示。这一步骤为生成引擎提供了更丰富的信息源,有助于生成更准确和相关的响应。

第五步,响应生成:构建最终答案

生成引擎结合原始问题和检索到的信息,输入LLM生成最终答案。这一步骤需要在保持与检索内容一致性和准确性的同时,引入创造性,以生成既准确又具有洞察力的文本。

第六步,评估:持续优化的关键

评估是确保RAG应用成功的最后一步。它提供了关于系统输出准确性、忠实性和响应速度的客观衡量,是持续优化RAG策略的关键环节。我们仔细看看RAG内部从索引,检索,增强到最后生成每一步都是怎么运行的,以及使用RAG和不使用RAG对返回结果的效果影响如何。

RAG范式

RAG研究范式在不断发展,我们将其分为三个阶段:Naive RAG、Advanced RAG和Modular RAG。尽管 RAG 方法具有成本效益并且超越了LLM的性能,但它们也表现出一些局限性。 Advanced RAG 和 Modular RAG 的发展正是针对 Naive RAG 的这些具体缺点的回应。

第一阶段,朴素RAG

Naive RAG 研究范式代表了最早的方法,在 ChatGPT 广泛采用后不久就得到了重视。

Naive RAG 遵循传统的过程,包括索引、检索和生成,也被称为“检索-生成”框架,前面讲的RAG是朴素RAG,它是最基础的,最核心的架构。

随着大模型落地不断深化,朴素RAG也有一些缺点:

检索挑战——检索阶段经常在【精确度】和【召回率】方面遇到困难,导致选择错位或不相关的块,并丢失关键信息。

生成困难——在生成响应时,模型可能会面临幻觉问题,即生成【检索到的上下文不支持的内容】。此阶段还可能会受到输出的【不相关性、毒性或偏差】的影响,从而降低响应的质量和可靠性。

增强障碍——将检索到的信息与不同的任务集成可能具有挑战性,有时会导致【输出脱节或不连贯】。当从多个来源检索类似信息时,该过程还可能遇到【冗余,从而导致重复响应】。确定各个段落的重要性和相关性并确保风格和语气的一致性进一步增加了复杂性。面对复杂的问题,基于原始查询的【单一检索可能不足以获取足够的上下文信息】。

第二阶段,高级RAG

Advanced RAG 引入了特定的改进来克服 Naive RAG 的局限性。

它着眼于提高检索质量,采用检索前和检索后策略。

为了解决索引问题,Advanced RAG 通过使用【滑动窗口方法】、【细粒度分段】和【合并元数据】来改进其索引技术。此外,它还结合了多种优化方法来简化检索过程。

预检索过程——这一阶段的主要重点是【优化索引结构和原始查询】。优化索引的目标是提高索引内容的质量。这涉及到策略:增强数据粒度、优化索引结构、添加元数据、对齐优化、混合检索。而查询优化的目标是让用户的原始问题更清晰、更适合检索任务。常见的方法包括查询重写、查询变换、查询扩展等技术。

检索后过程——一旦检索到相关上下文,将其与查询有效集成就至关重要。检索后过程中的主要方法包括【重新排序块和上下文压缩】。重新排列检索到的信息以将最相关的内容重新定位到提示的上下文中是一个关键策略。

第三阶段,模块化RAG

模块化 RAG 架构超越了前两种 RAG 范例,提供了增强的适应性和多功能性。

它采用了多种策略来改进其组件,例如添加用于相似性搜索的搜索模块以及通过微调来改进检索器。

重组 RAG 模块等创新并重新排列 RAG 管道的引入是为了应对特定的挑战。

向模块化 RAG 方法的转变正在变得普遍,支持跨其组件的顺序处理和集成的端到端训练。

尽管具有独特性,模块化 RAG 仍建立在高级 RAG 和朴素 RAG 的基本原则之上,展示了 RAG 系列的进步和完善。

新模块

模块化 RAG 框架引入了额外的专用组件来增强检索和处理能力。

搜索模块适应特定场景,使用LLM生成的代码和查询语言,可以跨搜索引擎、数据库和知识图谱等各种数据源直接搜索。

RAG-Fusion 通过采用多查询策略将用户查询扩展到不同的视角,利用并行向量搜索和智能重新排序来揭示显式和变革性知识,从而解决了传统搜索的局限性 。

内存模块利用LLM的内存来指导检索,创建一个无限的内存池,通过迭代的自我增强使文本与数据分布更紧密地对齐。

RAG系统中的路由可导航不同的数据源,为查询选择最佳路径,无论是涉及汇总、特定数据库搜索还是合并不同的信息流 。

Predict模块旨在通过LLM直接生成上下文来减少冗余和噪音,确保相关性和准确性。

任务适配器模块根据各种下游任务定制 RAG,自动提示检索零样本输入,并通过少数样本查询生成创建特定于任务的检索器 。这种综合方法不仅简化了检索过程,而且显着提高了检索信息的质量和相关性,以更高的精度和灵活性满足了广泛的任务和查询。

模块化 RAG 的优势

模块化 RAG 通过允许模块替换或重新配置来解决特定挑战,从而提供卓越的适应性。这超越了 Naive 和 Advanced RAG 的固定结构,其特点是简单的“检索”和“读取”机制。

此外,模块化 RAG 通过集成新模块或调整现有模块之间的交互流程来扩展这种灵活性,从而增强其在不同任务中的适用性。

重写-检索-读取等创新模型利用LLM的能力通过重写模块和LM反馈机制来细化检索查询来更新重写模型,从而提高任务性能。

类似地,像Generate-Read 用LLM生成的内容取代传统检索,而背诵阅读强调从模型权重中检索,增强模型处理知识密集型任务的能力。混合检索策略集成了关键字、语义和向量搜索来满足不同的查询。

此外,采用子查询和假设文档嵌入(HyDE)旨在通过关注生成的答案和真实文档之间嵌入相似性来提高检索相关性。

模块布局和交互的调整,例如演示-搜索-预测(DSP)框架和 ITER-RETGEN 的迭代检索-读取-检索-读取流程 ,展示了模块输出的动态使用来支持另一个模块的功能,说明了对增强模块协同作用的复杂理解。

Modular RAG Flow 的灵活编排展示了通过 FLARE 等技术进行自适应检索的优势 和自我 RAG 。

该方法超越了固定的RAG检索过程,根据不同场景评估检索的必要性。

灵活架构的另一个好处是RAG系统可以更轻松地与其他技术(例如微调或强化学习)集成 。

模块化RAG的核心在于将各种功能解耦,将其作为独立的模块进行处理。具体来说,模块化RAG包括了「搜索」、「预测」、「记忆」、「评估」、「验证」和「对齐」等外层模块,以及内层的「检索」、「重排序」、「重写」和「阅读」等RAG核心过程。

在处理信息和响应用户查询的过程中,模块化RAG采用了多种信息处理流程。

例如,传统的Navie RAG模式仅包括基本的「检索」和「阅读」步骤。

而在更复杂的Advanced RAG模式中,包括了「重写」→「检索」→「重排序」→「阅读」的路径,这在提高检索和生成内容的质量方面尤为有效。

DSP(Demonstrate-Search-Predict)模式则专注于验证、搜索和预测阶段,这些模块和模式的组合赋予了模块化RAG极大的灵活性和适应性,使其成为一种强大且可扩展的工具,能够有效地应对各种信息处理挑战,并在多样化的应用场景中提供高质量的回答。

预检索

检索增强生成的预检索阶段为成功的数据和查询准备奠定了基础,确保高效的信息检索。此阶段包括为有效数据访问做好准备的基本任务。

索引

该过程从索引开始,索引建立一个有组织的系统,以实现快速、准确的信息检索。索引的特殊性取决于任务和数据类型。例如,句子级索引有利于问答系统精确定位答案,而文档级索引更适合总结文档以了解其主要概念和思想。

查询操作

建立索引后,将执行查询操作来调整用户查询,以便更好地匹配索引数据。这涉及查询重构,重写查询以更符合用户的意图;查询扩展,它扩展了查询以通过同义词或相关术语捕获更多相关结果;查询规范化,解决拼写或术语的差异,以实现一致的查询匹配。

数据修改

数据修改对于提高检索效率也至关重要。此步骤包括预处理技术,例如删除不相关或冗余信息以提高结果质量,并使用元数据等附加信息丰富数据以提高检索内容的相关性和多样性.

检索

搜索与排名

检索阶段是搜索和排序的结合。它专注于从数据集中选择文档并确定其优先级,以提高生成模型输出的质量。此阶段使用搜索算法来浏览索引数据,查找与用户查询匹配的文档。识别相关文档后,对这些文档进行初始排名的过程开始根据它们与查询的相关性对它们进行排序。

检索后

检索后阶段用于细化最初检索的文档,以提高文本生成的质量。此阶段包括重新排序和过滤,每个阶段都旨在优化最终生成任务的文档选择。

重排序

在重新排序步骤中,先前检索到的文档将被重新评估、评分和重新组织。目的是更准确地突出显示与查询最相关的文档,并降低不太相关的文档的重要性。此步骤涉及合并额外的指标和外部知识源以提高精度。在这种情况下,由于可用的候选文档集有限,可以有效地使用精度较高但效率较低的预训练模型

过滤

过滤的目的是删除不符合指定质量或相关性标准的文档。这可以通过多种方法来完成,例如建立最小相关性分数阈值以排除低于特定相关性级别的文档。此外,使用用户反馈或先前的相关性评估有助于调整过滤过程,保证只保留最相关的文档用于文本生成。

生成

生成阶段是 RAG 流程的重要组成部分,负责利用检索到的信息来提高生成响应的质量。此阶段包含几个子步骤,旨在生成可读、引人入胜且信息丰富的内容。

增强

生成阶段的核心是增强步骤,其目标是将检索到的信息与用户的查询合并,以创建连贯且相关的响应。这包括阐述的过程,向检索到的内容添加额外的细节以丰富它。努力的重点是通过改写和重组等方法提高清晰度、连贯性和风格吸引力,从而提高产出的质量。综合各种来源的信息以提供全面的视角,并进行验证以确保内容的准确性和相关性。

定制化

定制是一个可选步骤,涉及调整内容以符合用户的特定偏好或请求的上下文。这种定制包括调整内容以满足目标受众的需求或呈现内容的格式,并压缩信息以简洁地传达内容的本质。该过程还需要创建强调要点或论点的摘要或摘要,确保输出内容丰富且简洁。熟悉推荐和广告系统的人员对此应该不陌生,推荐系统和广告系统只是缺少了生成过程,前面的索引,检索,排序和重排序都是同样的原理,主打一个精准。

向量数据库与Embedding模型

RAG的核心之一就是向量数据库,这种数据库专门用于处理向量数据,为机器学习和人工智能等领域提供了强大的支持。

随着AI时代的到来,向量数据格式日益重要,在未来的数据基础设施建设中,向量数据库很可能会成为一个关键组成部分。

向量数据库作为一种专为存储和检索高维向量数据而优化的数据库,在RAG框架中,其作用至关重要。这种数据库的主要优势在于它能高效地处理和存储大量的向量化数据,它们通常采用了特殊的数据结构和索引策略,来有效组织和检索向量数据,这对于RAG系统的检索组件来说是核心功能。

这些数据库能够处理高维度数据的同时,提供近似最近邻(ANN)查询,这种查询可以快速找到与查询向量相似的数据项。

使得RAG系统能够快速从海量数据中检索出与用户查询最相关的信息,显著提高信息处理的速度。此外,向量数据库在提高数据处理的精确度方面也发挥着关键作用。它能确保检索结果的精确性和相关性,从而增强RAG系统生成模型的输出质量。

RAG 场景对向量数据库的需求

而检索系统对向量数据库的需求可以抽象描述为:

  • 高精度的召回:向量数据库需要能够准确召回与查询语义最相关的文档或信息片段。这要求数据库能够理解和处理高维向量空间中的复杂语义关系,确保召回内容与查询的高度相关性。这里的效果既包括向量检索的数学召回精度也包括嵌入模型的语义精度。
  • 快速响应:为了不影响用户体验,召回操作需要在极短的时间内完成,通常是毫秒级别。这要求向量数据库具备高效的查询处理能力,以快速从大规模数据集中检索和召回信息。此外,随着数据量的增长和查询需求的变化,向量数据库需要能够灵活扩展,以支持更多的数据和更复杂的查询,同时保持召回效果的稳定性和可靠性。
  • 处理多模态数据的能力:随着应用场景的多样化,向量数据库可能需要处理不仅仅是文本,还有图像、视频等多模态数据。这要求数据库能够支持不同种类数据的嵌入,并能根据不同模态的数据查询进行有效的召回。
  • 可解释性和可调试性:在召回效果不理想时,能够提供足够的信息帮助开发者诊断和优化是非常有价值的。因此,向量数据库在设计时也应考虑到系统的可解释性和可调试性。

向量数据库对比

Pinecone

  • 优点:非常容易启动和运行(没有托管负担,它完全是云原生的),用户不需要了解有关矢量化或矢量索引的任何信息。文档也写得不错。
  • 缺点:完全专有,如果无法在 GitHub 上跟踪他们的进展,就不可能知道幕后发生了什么以及他们的路线图上有什么。此外,某些用户的体验凸显了依赖完全外部的第三方托管服务的危险,以及从开发人员的角度来看完全缺乏对数据库设置和运行方式的控制。考虑到现有开源、自托管替代方案的数量庞大,从长远来看,依赖完全托管、闭源解决方案的成本影响可能会很大。
  • 评价:在 2020-21 年,当矢量数据库非常不受关注时,Pinecone 远远领先于潮流,并以其他供应商没有的方式为开发人员提供了便利的功能。快进到 2023 年,坦率地说,Pinecone 现在几乎没有其他供应商提供的功能,而且大多数其他供应商至少提供自托管、托管或嵌入式模式,更不用说他们的算法的源代码了它们的底层技术对最终用户是透明的。
  • 官方页面:pinecone.io

Weaviate

  • 优点:优秀的文档(最好的文档之一,包括技术细节和正在进行的实验)。 Weaviate 似乎确实专注于构建尽可能最佳的开发人员体验,并且通过 Docker 启动和运行非常容易。在查询方面,它可以生成快速、亚毫秒级的搜索结果,同时提供关键字和矢量搜索功能。
  • 缺点:因为 Weaviate 是用 Golang 构建的,所以可扩展性是通过 Kubernetes 实现的,而且当数据变得非常大时,这种方法(与 Milvus 类似)需要相当数量的基础设施资源。从长远来看,Weaviate 的完全托管产品的成本影响尚不清楚,将其性能与其他基于 Rust 的替代方案(如 Qdrant 和 LanceDB)进行比较可能是有意义的(尽管时间会告诉我们哪种方法在最具成本效益的情况下可以更好地扩展)方式)。
  • 评价:Weaviate 拥有庞大的用户社区,并且开发团队正在积极展示极端的可扩展性(数千亿个向量),因此看起来他们的目标市场确实是拥有海量数据的大型企业。进行矢量搜索。提供关键词搜索和矢量搜索,以及强大的混合搜索,使其能够推广到各种用例,直接与 Elasticsearch 等文档数据库竞争。 Weaviate 积极关注的另一个有趣领域涉及通过向量数据库进行数据科学和机器学习,将其带出传统搜索和检索应用程序的领域。
  • 官方页面:weaviate.io

Qdrant

  • 优点:虽然比 Weaviate 新,但 Qdrant 也有很好的文档,可以帮助开发人员轻松地通过 Docker 启动和运行。它完全用 Rust 构建,提供开发人员可以通过 Rust、Python 和 Golang 客户端使用的 API,这些是当今后端开发人员最流行的语言。由于 Rust 的潜在功能,它的资源利用率似乎低于 Golang 中构建的替代方案。目前可扩展性是通过分区和 Raft 共识协议来实现的,这是数据库领域的标准实践。
  • 缺点:作为一个比竞争对手相对较新的工具,Qdrant 在查询用户界面等领域一直在追赶 Weaviate 和 Milvus 等替代品,随着每个新版本的发布,这种差距正在迅速缩小。
  • 评价:我认为 Qdrant 有望成为许多公司的首选矢量搜索后端,这些公司希望最大限度地降低基础设施成本并利用现代编程语言 Rust 的强大功能。在撰写本文时,混合搜索尚不可用,但根据他们的路线图,它正在积极开发中。此外,Qdrant 不断发布有关如何优化内存中和磁盘上的 HNSW 实施的更新,这将极大地有助于其长期的搜索准确性和可扩展性目标。很明显,根据 Qdrant的 GitHub 星级历史记录,Qdrant 的用户社区正在快速增长(有趣的是,比 Weaviate 的速度更快)!。
  • 官方页面:qdrant.tech

Milvus/Zilliz

  • 优点:非常成熟的数据库,具有大量算法,因为它在矢量数据库生态系统中长期存在。提供了很多矢量索引选项,并在 Golang 中从头开始构建,具有极高的可扩展性。截至 2023 年,它是唯一一家提供有效 DiskANN 实现的主要供应商,据说这是最有效的磁盘向量索引。
  • 缺点:在我看来,Milvus 似乎是一个解决可扩展性问题的解决方案——它通过代理、负载均衡器、消息代理、Kafka 和 Kubernetes的组合实现了高度的可扩展性,这使得整个系统变得非常复杂并且资源密集。客户端 API(例如 Python)也不像 Weaviate 和 Qdrant 等较新的数据库那样可读或直观,后者往往更注重开发人员体验。
  • 评价:Milvus 的构建理念是实现将数据流式传输到向量索引的大规模可扩展性,并且在许多情况下,当数据大小不太大时,Milvus 似乎有些过大了。对于更静态和不频繁的大规模情况,Qdrant 或 Weaviate 等替代方案可能更便宜,并且在生产中启动和运行速度更快。
  • 官方页面:milvus.io和zilliz.com

Chroma

  • 优点:为开发人员提供方便的 Python/JavaScript 界面,以快速启动和运行矢量存储。它是市场上第一个默认提供嵌入式模式的矢量数据库,其中数据库和应用程序层紧密集成,允许开发人员快速构建、原型化并向世界展示他们的项目。
  • 缺点:与其他专门构建的供应商不同,Chroma 主要是围绕现有 OLAP 数据库(Clickhouse)和现有开源矢量搜索实现(hnswlib)的 Python/TypeScript 包装器。目前(截至 2023 年 6 月),它尚未实现自己的存储层。
  • 评价:矢量数据库市场正在迅速发展,Chroma似乎倾向于采取“等待和观望”的理念,并且是少数旨在提供多种托管选项的供应商之一:无服务器/嵌入式、自托管(客户端-服务器)和云原生分布式 SaaS 解决方案,可能同时具有嵌入式和客户端-服务器模式。根据路线图,Chroma 的服务器实施正在进行中。 Chroma 引入的另一个有趣的创新领域是量化“查询相关性”的方法,即返回的结果与输入用户查询的接近程度。可视化嵌入空间(也在他们的路线图中列出)是一个创新领域,可以让数据库用于除搜索之外的许多应用程序。然而,从长远来看,我们从未见过嵌入式数据库架构在矢量搜索领域成功商业化,因此它的演变(与 LanceDB 一起,如下所述)将会很有趣!
  • 官方页面:trychroma.com

LanceDB

  • 优点:旨在对多模式数据(图像、音频、文本)执行分布式索引和本地搜索,构建在Lance 数据格式之上,Lance 数据格式是一种用于 ML 的创新型柱状数据格式。就像 Chroma 一样,LanceDB 使用嵌入式、无服务器架构,并且是用 Rust 从头开始构建的,因此与 Qdrant 一起,这是唯一一家利用速度 、内存安全性和相对较低的资源利用率的其他主要矢量数据库供应商。
  • 缺点:在 2023 年,LanceDB 是一个非常年轻的数据库,因此许多功能正在积极开发中,并且由于工程团队不断壮大,直到 2024 年功能的优先级将成为一个挑战。
  • 评价:我认为在所有矢量数据库中,LanceDB与其他数据库的区别最大。这主要是因为它在存储层本身(使用 Lance,一种比 parquet 更快的新列格式,专为非常高效的扫描而设计)和基础设施层上进行了创新 – 通过在其云版本中使用无服务器架构。结果,大量基础设施的复杂性降低,大大增加了开发人员构建以分布式方式直接连接到数据湖的语义搜索应用程序的自由度和能力。
  • 官方页面:lancedb.com

Vespa

  • 优点:提供最“企业就绪”的混合搜索功能,结合了久经考验的关键字搜索功能和 HNSW 之上的自定义矢量搜索。尽管 Weaviate 等其他供应商也提供关键字和矢量搜索,但 Vespa 是最早推出此产品的供应商之一,这让他们有充足的时间来优化其产品,使其变得快速、准确和可扩展。
  • 缺点:由于应用程序层是用 Java 编写的,因此开发人员的体验不如使用 Go 或 Rust 等面向性能的语言编写的更现代的替代方案那么顺畅。此外,直到最近,它还没有使设置和拆除开发实例变得非常简单,例如通过 Docker 和 Kubernetes。
  • 评价:Vespa 确实提供了非常好的产品,但它的应用程序主要是用 Java 构建的,而后端和索引层是用 C++ 构建的。随着时间的推移,这使得维护变得更加困难,因此,与其他替代方案相比,它往往会给开发人员带来不太友好的感觉。如今,大多数新数据库完全是用一种语言编写的,通常是 Golang 或 Rust,而且 Weaviate、Qdrant 和 LanceDB 等数据库的算法和架构创新速度似乎要快得多。
  • 官方页面:vespa.ai

Vald

  • 优点:旨在通过高度分布式架构处理多模式数据存储,以及索引备份等有用功能。使用非常快的 ANN 搜索算法 NGT(邻域图和树),当与高度分布的向量索引结合使用时,该算法是最快的 ANN 算法之一。
  • 缺点:似乎比其他供应商的整体吸引力和使用量要少得多,并且文档没有清楚地描述使用什么矢量索引(“分布式索引”相当模糊)。它似乎也完全由一个实体——雅虎!日本,关于其他主要用户的信息很少。
  • 评价:我认为 Vald 是一个比其他供应商更小众的供应商,主要迎合 Yahoo!日本的搜索要求较高,并且总体上用户社区要小得多,至少从 GitHub 上的星数来看是这样。部分原因可能是它的总部位于日本,营销力度不如欧盟和湾区其他地位较高的供应商。
  • 官方页面:vald.vdaas.org

Elasticsearch、Redis 和 pgvector

  • 优点:如果您已经在使用 Elasticsearch、Redis 或 PostgreSQL 等现有数据存储,那么利用它们的矢量索引和搜索产品非常简单,而无需求助于新技术。
  • 缺点:现有数据库不一定以最佳方式存储或索引数据,因为它们被设计为通用目的,因此,对于涉及百万级矢量搜索及以上的数据,性能会受到影响。 Redis VSS(矢量搜索存储)之所以快,主要是因为它纯粹在内存中,但当数据变得大于内存时,就有必要考虑替代解决方案。
  • 评价:我认为专用矢量数据库将在需要语义搜索的领域慢慢超越现有数据库,这主要是因为它们在矢量搜索方面最关键的组件(存储层)上进行创新。像 HNSW 和 ANN 算法这样的索引方法在文献中有详细记录,大多数数据库供应商都可以推出自己的实现,但是专门构建的向量数据库具有针对手头任务进行优化的优点(更不用说它们是使用 Go 和 Rust 等现代编程语言编写),并且出于可扩展性和性能的原因,从长远来看,它很可能会在这个领域胜出。

什么是Embedding

矢量数据库不仅存储原始数据(可以是图像、音频或文本),还存储其编码形式:Embedding。

这些Embedding本质上是存储数据上下文表示的数字(即vector)列表。直观上,当我们提到Embedding时,我们谈论的是实际存在于更高维度的数据(图像、文本、音频)的压缩、低维表示。

Embedding基于一个技巧:获取一段内容(文字,图片,视频…..)并将该内容转换为浮点数数组。

{
  "word": "Valentine's Day",
  "vector": [0.12, 0.75, -0.33, 0.85, 0.21, ...etc...]
}

Embedding的重要性

它建立了一座桥梁,连接了人类语言的丰富多彩与算法的冷冰冰的计算效率。

算法擅长数字游戏,却不通人情,而通过文本向量化,它们仿佛获得了解读和处理语言的新技能。其应用范围广泛,从推荐触动人心的内容,到让聊天机器人更具人情味,再到在浩瀚的文本海洋中寻找微妙的规律,文本向量化无处不在。

文本向量化 让机器能够进行情感分析、语言转换等看似高深的任务,以一种越来越接近人类的方式来理解和处理语言。

这个图的左边,我们看的每一列(维)的数字代表一种特征,比如有代表是否是人类,年龄,性别等。

在二维平面里用图形化表示,我们可以理解Embeddings就是在x和y上的坐标,相同的类会聚集在一起,但是为什么又叫做向量或者矢量,矢量是代表有方向的。我们看的男人和女,与国王和女王线是平行的。

说明沿着这条线的方向就代表性别的强度。越往右上角越代表越女性化。当维度越多,表征就更多,代表的语义就更加丰富。

演示地址:https://projector.tensorflow.org/?ref=mlq.ai

向量之间的距离

向量可能非常长且复杂。例如,OpenAI 的向量大小通常为 1536,这意味着每个Embeddings都是 1536 个浮点数的数组。

就其本身而言,这些数据并没有多大意义:它只是为了找到其他接近的Embeddings。

当我们将图像或文本片段表示为向量嵌入时,它们的语义相似性由它们的向量在向量空间中的接近程度来表示。

因此,我们想要查看的是对象向量之间的距离。这些向量表示(嵌入)通常是根据输入数据和任务通过训练模型创建的。

Word2Vec、GLoVE、USE 等是从文本数据生成嵌入的流行模型,而像 VGG 这样的 CNN 模型通常用于创建图像嵌入。

我们之前提到,我们通过计算对象向量之间的距离来发现对象之间的相似性。

我们可以根据最适合我们问题的距离度量来计算向量空间中这些向量之间的距离。

机器学习中常用的一些距离度量包括:

  • 欧几里德距离度量
  • 曼哈顿距离度量
  • 余弦距离度量
  • 切比雪夫距离度量。

下图将帮助我们理解每种方法背后的原理。

下面是关于这四种常见的距离度量方法的介绍:

1. 欧几里德距离度量(Euclidean Distance)

欧几里德距离是最常见的距离度量方法之一,用于测量欧几里德空间中两个点之间的直线距离。

对于二维空间中的两个点 𝑃(𝑥1,𝑦1)P(x1,y1) 和 𝑄(𝑥2,𝑦2)Q(x2,y2),欧几里德距离可以表示为:

对于多维空间中的点,欧几里德距离的计算方式类似,即每个坐标的差的平方和的平方根。

2. 曼哈顿距离度量(Manhattan Distance)

曼哈顿距离又称为城市街区距离,它是从一个点到另一个点沿着网格线的距离总和。在二维空间中,曼哈顿距离可以表示为两点坐标差的绝对值之和:

在多维空间中,曼哈顿距离的计算方式类似,即每个坐标的差的绝对值之和。

3. 余弦距离度量(Cosine Distance)

余弦距离是一种用于测量两个向量方向的相似性的度量方法,而不考虑它们的大小。对于两个向量 𝑢u 和 𝑣v,余弦距离可以表示为它们的夹角的余弦值的补数:

4. 切比雪夫距离度量(Chebyshev Distance)

切比雪夫距离是在数学中定义的一种度量方法,用于衡量两个点之间的最大距离。在二维空间中,切比雪夫距离可以表示为两点坐标差的最大绝对值:

在多维空间中,切比雪夫距离的计算方式类似,即每个坐标的差的最大绝对值。

这些距离度量方法各自适用于不同的情况和任务,根据具体的需求选择合适的度量方法非常重要。

如何选择嵌入模型

常见的类Embbedding模型
  • 检索用Embbedding
  • 重排序用Embbedding
Embbedding模型在RAG种的应用场景
  • 知识库存入向量数据库之前,需要使用Embbedding模型
  • 用户提问时的问题,需要使用使用Embbedding模型
  • 检索完成之后重排序的时候,需要 Rank Embbedding模型
在哪里找到合适Embbedding模型?

MTEB被公认为是目前业界最全面、最权威的中文语义向量评测基准之一,涵盖了分类、聚类、检索、排序、文本相似度、STS等6个经典任务,共计35个数据集,为深度测试中文语义向量的全面性和可靠性提供了可靠的实验平台。

通过这个网站可以看到所有开源的语义向量模型: https://huggingface.co/spaces/mteb/leaderboard

Embbedding模型选型

说了那么多的模型,怎么选择一个好的Embbedding模型,它是由很多个维度可以选择的,首先要考虑几个公共的维度,让后还需要考虑场景,因为不同的Embbedding模型训练的语料不一样,业务数据与Embbedding模型训练的语料匹配度越高,效果越佳。

  • Retrieval Average: NDCG是衡量检索系统性能的常用指标。 NDCG 较高表示模型能够更好地在检索结果列表中将相关项目排名靠前。
  • 模型大小:模型的大小(以 GB 为单位)。它给出了运行模型所需的计算资源的概念。虽然检索性能随模型大小而变化,但值得注意的是,模型大小也会对延迟产生直接影响。在生产设置中,延迟与性能的权衡变得尤为重要。
  • 最大令牌数:可以压缩为单个嵌入的令牌数。您通常不想放置超过一个文本段落(~100 个代币) 到单个嵌入中。因此,即使模型的最大令牌数为 512,也应该绰绰有余。
  • Embbedding维度:嵌入向量的长度。较小的嵌入可提供更快的推理,并且存储效率更高,而更多的维度可以捕获数据中的细微细节和关系。最终,我们希望在捕获数据的复杂性和运营效率之间取得良好的权衡。
  • 支持的语言 (Languages): 中文 (zh),英文 (en) 等

嵌入是如何生成的

方式一:模型托管方式生成 嵌入:比如一些MaaS(模型即服务)服务厂商会提供嵌入模型的API,比如OpenAI的text-embedding-3-large

方式二:自己部署模型生成 嵌入:另外一种是使用开源的嵌入模型,然后通过使用GPU服务器运行起来,自己封装接口。

如本文“对您有用”,欢迎随意打赏作者,让我们坚持创作!

10 打赏
Enamiĝu al vi
不要为明天忧虑.因为明天自有明天的忧虑.一天的难处一天当就够了。
543文章 68评论 294点赞 593201浏览

随机文章
Java—网络编程(Socket)
4年前
Java—Byte Buddy字节码编程
3年前
SpringBoot—中实现定时任务的两种方式 + 异步任务
5年前
Mybatis—Mapper补充
5年前
Flowable—流程引擎(待修缮)
3年前
博客统计
  • 日志总数:543 篇
  • 评论数目:68 条
  • 建站日期:2020-03-06
  • 运行天数:1926 天
  • 标签总数:23 个
  • 最后更新:2024-12-20
Copyright © 2025 网站备案号: 浙ICP备20017730号 身体没有灵魂是死的,信心没有行为也是死的。
主页
页面
  • 归档
  • 摘要
  • 杂图
  • 问题随笔
博主
Enamiĝu al vi
Enamiĝu al vi 管理员
To be, or not to be
543 文章 68 评论 593201 浏览
测试
测试
看板娘
赞赏作者

请通过微信、支付宝 APP 扫一扫

感谢您对作者的支持!

 支付宝 微信支付