基于书籍简单记录要点
一种借助“外挂”的提示工程
最核心的思想:给大模型补充外部知识以提高生成质量
大模型的 RAG 应用中,最常见的检索方式是借助基于向量的语义检索来获得相关的数据块,并根据其相似度排序,最后输出最相关的前 K 个数据块(简称top_K)
自然语言处理中用于把各种形式的信息转换成向量表示的模型叫嵌入模型
基于向量的语义检索就是通过计算查询词与已有信息向量的相似度(如余弦相似度),找出与查询词在语义上最接近的信息。
如果大模型是一个优秀学生,正在参加一门考试,那么 RAG 和微调的区别如下。
- RAG:在考试时给他提供某个领域的参考书,要求他现学现用,并给出答案。
- 微调:在考试前一天对他进行辅导,使他成为某个领域的专家,然后让他参加考试。
大模型与 Prompt 并不只在最后生成结果时才需要,在 RAG 应用流程的很多阶段都需要用到它们,比如在生成摘要、查询转换、查询路由、智能体推理、响应评估等很多阶段,都需要利用设计的Prompt 来让大模型完成任务。
与查询引擎相关的几个关键组件如下。
- (1)VectorIndexRetriever:向量索引检索器。用于完成相关知识的检索,基于索引来完成,输出多个相关 Node。
- (2)Synthesizer:响应生成器。借助大模型来完成 Prompt 组装,并根据响应生成模式的要求来生成响应结果。
- (3)NodePostProcessor:节点后处理器。通常用于在检索完成之后,对检索器输出的 Node 列表做补充处理,比如重排序。
Agent 就是通过 AI 模型驱动,能够自主地理解、规划、执行,并最终完成任务的 AI 程序。Agent 与大模型的区别类似于人与大脑的区别:大脑指挥人的行动,但是只有人才是执行任务的完整体。
Agent 就是在大模型作为智慧大脑的基础上实现记忆(Memory)、自我规划(Planning)、使用工具(Tool)等能力,从而开发一个具有自主认知与行动能力的完全“智能体”。
与 RAG 应用相比,Data Agent 具备以下能力。
- (1)兼具 RAG 应用的数据检索与查询生成能力。
- (2)通过观察环境与任务目标推理出完成下一个数据任务的步骤。
- (3)通过调用外部服务工具(API)完成复杂任务,并返回执行结果。
- (4)具备长期记忆能力(如使用向量库)与短期记忆(一次任务中的交互历史等)能力。
与 RAG 应用相比,Data Agent 的主要增强之处如下。
- (1)规划与推理出完成任务的步骤的能力。
- (2)定义与使用工具的能力。
LlamaIndex 框架整体结构
- (1)Core Framework:这是 LlamaIndex 的核心框架,实现了 LlamaIndex 框 架中大量可扩展的基础组件与工具组件。
- (2)Integrations:这是在 Core Framework 基础上由官方或者第三方提供的 大量扩展组件。这些组件大大扩充了 LlamaIndex 框架的兼容能力与应用场景, 包括各种类型的数据加载器、大语言模型与嵌入模型、向量库、Agent 工具等。
- (3)Templates:这是官方或者第三方提供的更上层的应用模板。开发者可 以基于这些模板来修改和开发自己的应用。
- (4)Eval Datasets:评估数据集。这是一些用于测试评估的现成数据集。 一个数据集通常包含两个部分:一部分是用于开发 RAG 应用的原始知识数据 集;另一部分是用于评估 RAG 应用的测试数据集。
LlamaIndex 的向量存储索引和传统数据库(如 MySQL)的索引的区别
- From Grok3 (2025-02-24)
传统数据库索引(如 MySQL) vs 向量存储索引
1. 传统数据库索引(B-树、哈希索引等)
- 目的:加速精确匹配或范围查询,比如在
WHERE id = 5
或WHERE age > 30
时快速定位数据。 - 数据结构:通常基于 B-树、B+树 或哈希表,存储的是原始数据(如整数、字符串)的某种排序或映射。
- 存储内容:索引本身不保存完整数据,而是指向数据库中实际数据的引用(行指针)。
- 使用场景:结构化数据的高效检索。
2. LlamaIndex 的向量存储索引
- 目的:支持语义相似性搜索,比如找到与“人工智能是什么”语义最接近的文档。
- 数据结构:基于向量空间的高效搜索结构(如 FAISS、HNSW、Annoy),存储的是文本的嵌入向量(高维浮点数数组)。
- 存储内容:索引里直接保存的是嵌入向量(通常还会关联原始文本或其引用),而不仅仅是指针。这种嵌入向量本身就是数据的某种“表示”。
- 使用场景:非结构化数据(如文本、图像)的语义搜索。
所以你说得对,向量存储索引和 MySQL 的索引在设计目标和实现上完全不同。传统索引是为了快速定位具体值,而向量存储索引是为了快速找到“最相似”的内容。
为什么叫“向量存储索引”而不是“向量存储数据”?
“索引”在这里的含义:
- 在向量搜索领域,“索引”指的是一个经过优化的数据结构,用于加速向量之间的相似性计算和检索。它不只是存数据,而是以某种方式组织数据(比如 FAISS 用聚类或倒排索引),让查询效率更高。
- 比如 FAISS 可能会把向量分桶(clustering),HNSW 用图结构连接向量,这些都是“索引”的体现。
为什么不叫“向量存储数据”:
- “数据”听起来像是原始的、未经组织的存储,比如直接把向量一股脑扔进数据库。而“索引”强调的是结构化和查询优化。
- LlamaIndex 的向量存储索引不仅存了向量,还为快速检索做了预处理(比如降维、构建树或图)。它是个功能性工具,而不仅是数据的容器。
命名习惯:
- 在向量搜索和机器学习领域,像 FAISS、Annoy、HNSW 这些工具都叫“索引”(index),因为它们的核心是构建一个可搜索的结构。LlamaIndex 沿用了这种惯例。
举个类比
- MySQL 的 B-树索引就像图书馆的卡片目录,按书名首字母排序,帮你快速找到某本书。
- LlamaIndex 的向量存储索引更像是推荐系统,根据你喜欢的书,找到内容相似的其他书,靠的是“向量空间的距离”而不是精确匹配。
总结
LlamaIndex 的向量存储索引确实和 MySQL 的索引差别很大,它更像是一个专门为高维向量设计的“搜索加速器”。叫“索引”是因为它不仅存向量,还组织向量以提升查询效率,而不是简单的数据存储。
个人对于深度强化学习的思考
- 对于RAG应用,优化方法有很多。我的想法是,把这些优化方法想象成一堆‘工具’,然后用强化学习这个‘聪明助手’来挑出最好用的组合。
- “优化策略”变成了“工具”,“强化学习”变成了“聪明助手”,“奖励函数”简化为“任务需求”
扩展
如果嵌入模型知道“你好”和“再见”的向量,它可以将“你好再见”转化为一个向量吗?
- From Grok3 (2025-02-25)
- 嵌入模型可以将“你好再见”转化为向量。
- 对于词嵌入模型(如 Word2Vec 或 GloVe),通常通过平均或相加“你好”和“再见”的向量来生成短语向量。
- 对于句嵌入模型(如 BERT 或 Ada-002),模型可以直接处理“你好再见”序列,生成反映上下文关系的向量。
RAG的相关原理
From Grok3 (2025-02-25)– 基于自身理解由Grok优化
文本向量化:在RAG中,知识库中的文档会被分割成适当的文本片段(例如句子或段落),然后使用预训练模型对这些片段整体进行向量化,生成语义丰富的稠密向量。这一过程不同于传统的单词嵌入,目的是捕捉整个片段的语义信息。
向量检索:当用户提出问题时,系统会将问题同样向量化,并在向量数据库中查询与问题语义最相似的文本片段。这些检索结果是原始文档中的真实内容,而不是由模型生成的文本。
上下文整合与生成:检索到的文本片段会以纯文本形式插入到一个提示模板中,作为上下文连同用户的问题一起输入到生成模型中。生成模型(如大语言模型)基于这些上下文生成最终的回答。
其他
精通RAG架构:从0到1,基于LLM+RAG构建生产级企业知识库
- 向量数据库对比
- 如何选择嵌入模型:https://huggingface.co/spaces/mteb/leaderboard
-
- CoRAG 的核心创新在于其动态查询重构机制。该模型不再依赖单次检索,而是根据中间推理状态迭代优化查询。这一过程确保了每个阶段检索到的信息都与上下文相关,进而逐步构建出更完整的最终答案。
-
- 如果你用图数据库来检索信息,那么这种方式被称为 GraphRAG,它是知识图谱在 RAG 中的具体应用
- 向量相似性检索依赖于知识库中的明确提及,只有明确提到的信息才会被检索出来。而知识图谱则能通过整体数据来推理出更多信息
- 使用 Langchain 的实验功能 LLMGraphTransformer,如果是 LlamaIndex,可以尝试它的 KnowledgeGraphIndex。
- LLM 可以从纯文本中提取图谱信息,并将其存储到像 Neo4J 这样的数据库
-
- 感觉做这个东西就是在不停找各种优化方法反复尝试看效果,而且目前还处于很乱的早起阶段
-
- 传统方法(如基于向量的 RAG)在处理局部化任务时表现良好,例如从特定文本片段中检索直接答案。然而,当涉及需要全面理解数据集的全局性查询时,这些方法往往难以胜任。
- 相比之下,图支持的 RAG 系统通过利用数据结构中的关系,可以更好地解决此类更广泛的问题。然而,与图 RAG 系统相关的高索引成本,使其难以被成本敏感的场景所接受。因此,在可扩展性、经济性和质量之间实现平衡,仍然是现有技术的关键瓶颈。
- 相比之下,图支持的 RAG 系统通过利用数据结构中的关系,可以更好地解决此类更广泛的问题。然而,与图 RAG 系统相关的高索引成本,使其难以被成本敏感的场景所接受。因此,在可扩展性、经济性和质量之间实现平衡,仍然是现有技术的关键瓶颈。
- LazyGraphRAG 将 VectorRAG 与 GraphRAG 相结合,“同时克服了二者的各自局限性”。
Reference
- 《基于大模型的RAG应用开发与优化——构建企业级LLM应用》