Views

共 1340 字，阅读约 7 分钟
Categories: 技术流, 知识点

不研究⼤模型本⾝，我们从 RAG 切⼊去 hook ⼤模型

整体概述

从 RAG 切入，因为与 RAG 对应的就是大模型本身内里的东西了，对数据的转化、扩散、对数据的训练、权重、微调、性能调优、GPU 加速、上下文窗口、大模型、小模型等等。

大模型出来之后，就是一个“封闭的黑盒”。

那么，当前是通过什么方式将这样封闭的黑盒“个性化、定制化”去满足应用开发需要，满足各种工程场景的呢？

我把这条路线称为“hook 大模型路线”。

hook 大模型路线 = RAG + Prompt + Tools + 记忆层 + 应用场景化

而从这个公式展开，又会有各种要点：

  • RAG = LLM + 知识库 + 检索器
  • Prompt 工程本身、DSPy（不需要做 Prompt，只需要负责管理好 LLM）
  • 结构化 JSON 返回
  • LangChain
  • Agent
  • function calling / tools
  • 记忆层
  • 向量化、Token 化、Embedding，当然这一块本身也是大模型本身的核心要点。只不过它同时也是 hook 大模型路线的核心，因为在大模型体系里，数据都是需要先向量化的（泛称），它就是计算机体系里的编译成 0 和 1。
  • ……

另一个角度来看，如果你依赖于大模型能力，但又无法研究大模型本身（包括微调，比较高阶了，它做的是把想实现的“大模型能力”相关行为数据集作为训练数据的一部分，对模型进行额外训练，本质还是在搞大模型内里。），就只剩下 prompt 优化（或者更深入的 prompt 工程）可以做，但实际出来的产品/功能大多是垃圾！

所以更应该是：把 prompt 工程能力结合到 RAG 体系中：

  • RAG 主打“让大模型到吃外部资源”这个数据源环节。
  • prompt 工程主打“引导模型的推理或生成过程”这个更末端的环节。

关于大模型本身是怎样实现的，涉及什么关键技术，这个比较深的话题，推荐 Andrej Karpathy。这是 LLM 圈极少的真大佬，真的讲人话。推荐他的 youtube 频道，把那些视频教程学了，视频里讲得已经很明白了，配合源码去理解，很有用。比如：

  • token 化具体是怎么做的：https://github.com/karpathy/minbpe
  • 反向传播又是怎么做的：https://github.com/karpathy/micrograd
  • ……
  • 到后边可以一步一步写出自己的大模型：https://github.com/karpathy/nn-zero-to-hero

btw，这里个用于微调大模型的开源项目：https://github.com/hiyouga/LLaMA-Factory

核心技术

一、RAG

RAG = LLM + 知识库 + 检索器

RAG 让大模型在生成答案时，不仅依赖模型内部的知识，还能动态地从外部数据源中获取相关信息。理解成 RAG 提供了一种方式去把数据 hook 进已经训练好的大模型里，比如文档数据库、网页或其它数据源。当然，这些数据是需要向量化的。具体过程：

RAG 的主要流程

  1. 知识库预处理 1. 在系统启动之前，知识库中的数据会被预先处理成向量形式，存储在一个高效的向量数据库中。 2. 这些向量通常是通过一个预训练好的语言模型（如 BERT、sentence-transformers 等）将文本转化为嵌入向量（embedding）。 3. 这个阶段的处理是静态的，目的是为后续的检索做准备。

  2. 检索阶段（Retrieval），也叫“召回” 1. 当用户提出问题后，系统会将问题转化为向量形式。 2. 通过相似度计算（如余弦相似度），系统会在向量数据库中寻找与用户问题最相关的内容。 3. 检索出的内容一般是一些片段（passages），这些片段会被动态地传递到生成阶段。

  3. 生成阶段（Generation） 1. 检索到的相关内容会和用户的问题一起作为输入，传递给一个生成式语言模型（如 GPT 或 T5）。 2. 模型利用用户问题和外部知识库提供的上下文，生成一个具体的回答。 3. 这一步的生成依赖于模型的语言能力，但回答的知识核心来自动态检索到的内容。

核心：

  • 外部知识库先被预处理成向量形式了。
  • 问题在这个“向量知识库”中检索“关联答案”，得到相关的向量片段，给到大模型去作为上下文。
  • 所谓的生成阶段，其实就是到大模型这一环节了。

btw，有个问题，大模型的网页搜索或者附加文档能力，如果是 RAG 这种模式，现在的性能发展得能这么快实时响应了？查找了一下结论，好像确实是这样。

其实，在检索到生成这两个环节之间，还存在一个关键步骤：

Re-Ranking

re-ranking 主要作用是对从外部知识库中检索到的候选文档或片段进行重新排序，以确保最终传递给生成模型的上下文内容最为相关且高质量。

Reranker 类型主要有两种——基于统计和基于深度学习模型的 Reranker。

基于统计的 Reranker 会汇总多个来源的候选结果列表，使用多路召回的加权得分或倒数排名融合（RRF）算法来为所有结果重新算分，统一将候选结果重排。这种类型的 Reranker 的优势是计算不复杂，效率高，因此广泛用于对延迟较敏感的传统搜索系统中。

基于深度学习模型的 Reranker，通常被称为 Cross-encoder Reranker。由于深度学习的特性，一些经过特殊训练的神经网络可以非常好地分析问题和文档之间的相关性。这类 Reranker 可以为问题和文档之间的语义的相似度进行打分。因为打分一般只取决于问题和文档的文本内容，不取决于文档在召回结果中的打分或者相对位置，这种 Reranker 既适用于单路召回也适用于多路召回。

在 RAG 中，整个流程可以分为两大部分：检索阶段和生成阶段。Re-ranking 通常发生在 检索阶段之后，在将候选文档传递给生成模型之前进行。具体流程如下：

  1. 用户查询或输入传入： 用户提出一个问题或请求，系统将这个输入作为查询输入。
  2. 检索阶段： 1. 在这一阶段，系统通过外部知识库（如一个文档数据库、向量数据库或知识图谱）进行检索。 2. 通常，系统会使用某种相似度度量方法（如余弦相似度）通过向量化查询输入，找出与输入最相关的候选片段或文档。 3. 这些候选片段/文档是基于查询向量与文档向量之间的相似度计算出来的，通常会从数千、数百万个候选项中检索出若干个（如 10-50 个）最相关的候选片段。
  3. Re-ranking 阶段： 1. 在这一步，系统会对从检索阶段返回的候选片段进行重新排序，以确保最相关的片段被传递给生成模型。 2. Re-ranking 的步骤可以基于多个因素，如： - 候选片段的相关性：通过一个更高层次的模型（通常是训练过的预训练模型，可能是一个 fine-tuned 的模型）重新评估这些候选文档与查询的匹配度。 - 文档质量评分：例如，利用模型检查文档的完整性、逻辑性、语言流畅度等因素。 - 上下文匹配：除了单纯的相似度，还可能考虑片段中的信息是否补充了完整的上下文，尤其在复杂问题中，多个片段的配合可能比单独的高相似度文档更重要。 3. 在很多系统中，这一阶段使用一个 二次检索模型 或 生成模型，比如基于 Transformer 的模型，来对候选片段进行评分和排序。
  4. 生成阶段： 1. Re-ranking 阶段的输出是重新排序后的最相关文档，这些文档将作为上下文传递给生成模型，生成模型基于这些文档生成最终的回答。

Re-ranking 的目标

Re-ranking 的目的是确保检索阶段返回的候选文档或片段具有足够的相关性和质量，避免传递给生成模型无关或低质量的内容。这个过程增强了模型生成答案时的精准性和连贯性，特别是在面对复杂问题或大量候选数据时，能够显著提高最终答案的质量。

Re-ranking 的常见方法

  1. 基于相似度的重排序： 使用传统的相似度度量方法（如余弦相似度或距离度量）来对检索到的候选片段进行重新排序。这个方法相对简单，但在面对高质量文档或复杂问题时可能会表现较差。
  2. 基于学习的重排序： 近年来，越来越多的 RAG 系统使用深度学习方法来对候选片段进行重新排序。通过训练一个额外的模型（如使用双塔模型，或者 fine-tune 一个生成模型），系统可以基于更多的语义信息、上下文相关性、句子层次的连贯性等因素进行重排序。
  3. 基于生成模型的重排序： 一些系统会使用生成模型（例如 BERT 或 GPT 系列模型）来对候选片段进行评分。生成模型能够处理更为复杂的语义信息，确保排序后的候选片段更符合问题的背景。
  4. 混合方法： 在某些系统中，re-ranking 过程可能结合了基于规则的方法、相似度计算、以及基于深度学习的生成方法，通过多轮优化来得到最好的排序。

Re-ranking 示例：

假设用户提问 “什么是量子计算？”

  1. 检索阶段： 系统从知识库中检索到如下 3 个候选片段： 1. 片段 1：介绍量子计算的基本原理。 2. 片段 2：介绍量子计算与经典计算的区别。 3. 片段 3：介绍量子计算在物理学中的应用。
  2. Re-ranking 阶段： 这 3 个片段被重新排序，以确保最相关的片段被传递给生成模型。假设： 1. 片段 1 和片段 2 都非常相关，而片段 3 可能偏离问题的核心（如果问题是关于量子计算的定义，而不是应用）。 2. Re-ranking 阶段可能会给片段 1 和片段 2 更高的评分，而降低片段 3 的评分。
  3. 生成阶段： 排序后的片段（片段 1 和片段 2）将传递给生成模型，最终生成关于“量子计算是什么”的回答。

以上是对 RAG 这个技术概念本身的理解。

而具体到 RAG 技术生态的时候，会有一些关键技术信息，以及一些当前的顶流模式与趋势。不会很深，比如前边 reranker 那些什么 RRF 加权得分或倒数排名融合算法啥的这种。。。

VectorRAG

也就是最基础的 RAG 模式，毫无其它设计、策略，就按着 RAG 的概念最简地去做。

Self-RAG

Self-RAG 允许模型在回答过程中，多次调用自身的生成和检索能力，逐步完善答案。这种方式类似于“反复思考问题并查阅资料”。简单讲，大模型先把输入的问题与回答整合后，拆分成更多子问题往下走。

Self-RAG 本质上是基于 RAG（Retrieval-Augmented Generation）架构的一种变体。它的核心思想是通过将 AI 模型自身的生成能力与检索模块相结合，形成一个自反馈、自优化的闭环系统。Self-RAG 可以动态地生成问题、检索相关内容并迭代优化生成的答案，具有较强的自我强化能力。

适用场景：

  • 模糊问题澄清：问题初始信息不足，需要模型主动补充细节。
  • 复杂推理：需要跨多层信息关联的任务。

Self-RAG 的完整流程（动态交互部分）

以下是一个基于 Self-RAG 的多轮交互示例：

  1. 用户输入： 用户提出问题：“GPT 模型在法律领域的常见应用有哪些？”
  2. 初次检索： 检索模块从知识库中找到几个与问题相关的内容片段： 1. 片段 1：描述 GPT 用于合同生成。 2. 片段 2：描述 GPT 用于法律咨询答疑。
  3. 生成初步回答： 生成模块将用户问题 + 检索内容输入到大模型，生成回答： “GPT 常用于合同生成和法律咨询答疑。”
  4. 生成子问题： 大模型基于上下文继续生成子问题： 1. 子问题 1：“合同生成中有哪些具体步骤？” 2. 子问题 2：“GPT 如何提高法律咨询的准确性？”
  5. 动态检索： 检索模块针对每个子问题单独检索： 1. 子问题 1 检索到与合同模板创建相关的内容。 2. 子问题 2 检索到与 GPT 提高回答准确性的方法相关的内容。
  6. 生成深层回答： 生成模块再次根据子问题 + 检索内容生成补充答案，并将其合并： “GPT 在合同生成中负责模板创建与条款自动化；在法律咨询中，通过上下文理解提升了答案的准确性。”

Agentic RAG

Agentic RAG 引入了“代理”概念，让模型不仅仅是被动回答，而是具备主动执行复杂任务的能力。本质上也是 RAG 的一种架构策略，Agentic RAG 引入智能代理（Agent）的概念，能够自主分解任务、选择工具、执行操作并迭代改进生成结果。

Agentic RAG 的逻辑流程

  1. 用户输入分析
  • 系统接收用户的问题或任务，分析其意图和复杂度。
  • 如果问题是复杂任务（如多步骤问题），Agent 会生成任务分解计划。
  1. 自主分解任务
  • 系统将问题拆解为一系列子任务。例如： - 用户问题：如何设计一个 Agentic RAG 系统？ - 任务分解： - 检索 Agentic RAG 的定义和理论基础。 - 查找与 RAG 的差异和改进之处。 - 整合信息并生成具体设计建议。
  1. 工具链调用
  • Agent 根据每个子任务调用对应的工具模块，常见模块包括： - 检索模块：从知识库中找到相关内容。 - 生成模块：基于检索到的内容生成回答或结果。 - 外部 API 接口：如数据库查询、Web 搜索等。
  1. 结果反馈与迭代
  • 系统将每一步的输出结果进行评估，决定是否需要进一步优化。
  • 如果结果不完整或不足以回答问题，系统会生成新的子任务继续检索或生成。
  1. 综合输出
  • 在完成所有子任务后，Agent 将子任务结果进行综合处理，生成最终答案或解决方案，并反馈给用户。

看这个流程，会发现 Agentic RAG 和 Self-RAG 两者都在过程中包含了自我监督（Self-Supervision）或反馈机制来优化任务结果。

适用场景：

  1. 复杂知识问答：如法律、医疗领域中的多步骤问题解决，需要查找多个资料并整合成完整答案。
  2. 任务自动化：Agentic RAG 可以用于企业中的流程自动化，例如对不同任务调用不同 API 或工具。
  3. 科学研究与分析：研究人员可以用 Agentic RAG 系统搜索文献、生成摘要并进行数据分析。
  4. 个性化服务：在客户服务中，根据用户需求动态调用不同模块，为用户提供定制化解决方案。

Agentic RAG 架构也分为单 Agent 和多 Agent 的，单 Agent 的话，其实这个 Agent 相当于只是做个任务路由，多 Agent 的话，在复杂系统中进一步增强任务处理的并发性、模块化协作能力和智能性，超越单 Agent 的任务路由角色，形成多 Agent 之间的协作网络。

GraphRAG

GraphRAG 通过将数据组织为图结构（Graph）来优化检索与生成的过程。在这种方法中，知识库以节点（知识点、实体）和边（它们之间的关系）形式存储。模型不仅检索节点，还能够沿着关系边探索更深层的关联信息。

简而言之，核心是用图的方式作为数据组织的基本形式，在数据向量化之后这些数据也能保留图组织关系，反正是能从这堆向量中检索到关系就是了。

GraphRAG 的革新之处在于：将 VectorRAG 的“最佳优先”搜索策略，转变成了“广度优先”搜索策略，确保了查询结果中能充分考虑到数据集的广度。这是图结构的优势。

适用场景：

  • 复杂关系查询：例如法律文件、科研论文中，某个问题的答案依赖于多个概念之间的关系。
  • 知识图谱系统：企业内的客户、产品、供应链等复杂数据网络。

https://github.com/microsoft/graphrag

btw，召回增强 RAPTOR 策略，树状：

召回增强 RAPTOR 策略是一种用于提升检索增强生成 (Retrieval-Augmented Generation, RAG) 系统性能的方法，尤其在处理长文本和复杂信息检索时表现出色。它通过构建一种递归的树状索引结构来更有效地组织和检索文档信息。

传统 RAG 的局限性：

传统的 RAG 方法通常将文档分割成较小的文本块，然后使用向量相似性搜索来检索与用户查询相关的块。这种方法在处理短文本和主题单一的文档时效果良好，但在处理长文本和包含多个主题的文档时，可能会遇到以下问题：

  • 上下文丢失： 将长文档简单地分割成小块可能会导致上下文信息的丢失，影响检索的准确性。
  • 检索效率低下： 当文档数量巨大时，对所有文本块进行相似性搜索的效率会变得非常低下。
  • 无法捕捉文档的层次结构： 传统方法无法有效地捕捉文档中不同层次的主题和子主题之间的关系。

RAPTOR 策略的核心思想： RAPTOR (Recursive Abstracting and Pruning for Tree-Organized Retrieval) 策略通过构建一个树状索引结构来解决上述问题。它递归地进行文本片段的向量化、聚类和摘要生成，从而构建出一个层次化的文档表示。

RAPTOR 的主要步骤：

  1. 分块与嵌入： 将文档分割成文本块，并使用嵌入模型（例如 Sentence-BERT）将每个文本块转换为向量表示。
  2. 递归构建 RAPTOR 树： 1. 将文本块及其嵌入作为树的叶子节点。 2. 使用聚类算法（例如 k-means）将相似的文本块聚在一起，形成父节点。 3. 为每个父节点生成一个摘要，该摘要概括了其子节点的内容。 4. 重复上述步骤，直到形成一个根节点，该节点代表整个文档的概要。
  3. 查询： 1. 将用户查询转换为向量表示。 2. 从根节点开始，计算查询向量与每个节点的向量之间的相似度。 3. 根据相似度，选择最相关的节点，并递归地向下遍历树，直到到达叶子节点。 4. 将所有选定叶子节点的文本块连接起来，形成检索到的上下文。

RAPTOR 的优势：

  • 捕捉文档的层次结构： RAPTOR 能够有效地捕捉文档中不同层次的主题和子主题之间的关系，从而提供更全面的上下文信息。
  • 提高检索效率： 通过树状结构，RAPTOR 可以避免对所有文本块进行搜索，从而提高检索效率。
  • 提高检索准确性： 通过递归的摘要生成和聚类，RAPTOR 可以更准确地识别与用户查询相关的文本块。
  • 支持多种查询策略： RAPTOR 支持多种查询策略，例如树遍历和折叠树，可以根据不同的应用场景进行选择。

召回增强的含义：

在 RAG 系统中，“召回”指的是从知识库中检索相关信息的过程。召回率是指检索到的相关信息占所有相关信息的比例。召回增强意味着通过改进检索方法，提高检索到的相关信息的数量，从而提高 RAG 系统的性能。RAPTOR 策略通过构建更有效的索引结构和使用更智能的查询策略，实现了召回增强，使得 LLM 可以在更长的上下文窗口找到答案，从而提升回答质量。

RAPTOR 的应用：

RAPTOR 可以应用于各种需要处理长文本和复杂信息检索的场景，例如：

  • 问答系统
  • 文档摘要
  • 信息检索
  • 聊天机器人

总结：

召回增强 RAPTOR 策略是一种强大的 RAG 增强方法，它通过构建递归的树状索引结构，提高了检索效率和准确性，尤其在处理长文本和复杂信息检索时表现出色。它为构建更智能、更高效的 RAG 系统提供了一种新的思路。

LazyGraphRAG

LazyGraphRAG 是 GraphRAG 的优化版本，主打“按需加载”，即仅在需要时动态构建和检索图结构数据，减少了系统资源的占用。

简单讲，LazyGraphRAG 将 VectorRAG 的最佳优先搜索 和 GraphRAG 的广度优先搜索 动态结合，采用迭代深化（Iterative Deepening）的方式，在探索知识图谱时更加高效。首先在有限的深度上进行搜索，之后再通过迭代深入数据集内部。LazyGraphRAG 的数据索引成本与 VectorRAG 相同，而仅为完整 GraphRAG 成本的 0.1%。

  • VectorRAG 方法： 系统根据语义相似度（通常使用嵌入向量）对结果排序，优先返回与查询最相关的文档片段。 优点：检索精准，快速锁定语义最贴近的内容。 不足：当答案隐藏在多层关系中时，可能遗漏其他重要信息。
  • GraphRAG 方法： 沿着知识图谱的边扩展，优先探索与当前节点直接相关的所有邻居节点。 优点：能全面挖掘上下文和关系链的信息。 不足：搜索范围大，可能带来较高的计算成本。

LazyGraphRAG 的整合策略：

  • 系统先以最佳优先搜索快速锁定最可能的节点或文档（如高语义相关性内容）。
  • 然后在这些关键节点上，动态切换到广度优先搜索，逐步探索更深层的关系链。
  • 在回答过程中，采用按需加载的懒加载机制，只加载当前问题需要的部分图谱节点，避免全局图谱的高资源开销。

应用场景： LazyGraphRAG 更适合于 结构化且多层关联的复杂知识库，如：

  • 法律、金融等需要同时考虑精确性和上下文关联的领域。
  • 实时推荐系统，如动态社交网络的好友建议。

都是微软的，只到 GraphRAG，还没升级呢：https://github.com/microsoft/graphrag/discussions/1490

Blended RAG

Blended RAG 策略，主要是在检索层的变革。结合语义搜索技术和混合查询策略，提升 RAG 系统的准确性。通过融合多种检索方法（如关键字检索、向量检索和规则匹配），从不同角度对同一问题进行全面分析。

Blended RAG 的实现逻辑：

  • 针对复杂查询问题，先执行语义搜索，获取语义相关的候选内容。
  • 同时利用混合查询策略补充其他相关信息，特别是在语义搜索不足以完全捕获问题背景时。
  • 最终将多种结果综合，作为生成式AI的上下文输入。

应用场景： Blended RAG 更适合于需要 高覆盖率和多角度理解 的任务，比如：

  • 电商平台：对模糊搜索输入（如“夏天适合的户外鞋”）生成更丰富的推荐列表。
  • 客服系统：针对用户问题同时考虑模糊语义匹配和具体FAQ的规则检索。

似乎还在论文阶段而已：https://github.com/ibm-ecosystem-engineering/Blended-RAG

以下是几个相关项目：

  • 源码可以看到实现了 RAG 的一些环节，架子有了。链、embedding、模型对接、检索（包括向量数据库对接）：https://liduos.com/the-llmops-bisheng-introduce.html
  • 一个基于 RAG 的开源工具，用于与文档进行对话，也有 RAG 架子：https://github.com/Cinnamon/kotaemon
  • RAGFlow 和 Jina，应该是当前在 RAG 这个领域技术上研究最深的两家创企。

二、向量化、Token 化、Embedding

Token 化是将文本分解为基本单元的过程，这些基本单元称为 token。

向量化是将 token 转换为数字向量的过程，这些向量表示 token 的语义信息。

Embedding 是一种特殊的向量化方法，它可以学习 token 之间的语义关系，embedding 通常使用神经网络来训练。

embedding 是一种将高维度、稀疏的数据（如文本、图像、声音等）转换为低维度、稠密的数值向量表示的技术。涉及使用机器学习算法来学习数据的语义和语法关系。具体来说，embedding 方法可以将文本中的词语、图像中的像素点或声音中的音频信号等原始数据表示为向量形式。

  • 想了解基于神经网络的 embedding 技术细节，可以从 Word2Vec 开始切入，这是先驱。但它还比较简单（浅层神经网络，相比于 GPT 以 Transformer 深层神经网络为基础的来说）。

token 化就是把“你好，世界”转变成 token 序列 [177519, 979, 28428]（在 GPT-4o / GPT-4o mini 使用的算法下）。

单纯说“向量化”概念就是把 token 序列转化为向量。

embedding 本质上也是向量化，只不过它高级策略，保留语义关联。

Text → Tokenization → Embedding Model → Vector → Vector Database → Similarity Search

研究 token 化入门：

  1. Token 化后的向量化
  • 在 token 化后，句子已经被转换为 token 序列 [177519, 979, 28428]。
  • 这些数字本质上是词汇表（vocabulary）中的索引，但它们仍然是离散的、没有语义的数字。
  • 向量化 指的就是将这些 token 索引映射为向量，方便神经网络处理。 - 比如，对于 token 177519，可能将其映射为一个稀疏向量： - [0, 0, ..., 1, ..., 0] # 词汇表中第 177519 个位置是 1，其余是 0 - 这是传统的独热编码（One-Hot Encoding），它是一种最简单的向量化方法。

问题： 独热编码虽然可以向量化，但它：

  • 维度很高（词汇表可能有数万个词）。
  • 不能捕捉词语的语义信息（例如“你好”和“世界”的向量完全独立）。 因此，独热编码的向量化在深度学习中效率较低。
  1. Embedding（嵌入）

为了更有效地表示 token，使用 embedding 层 将每个 token 索引转换为稠密的、低维的向量。

过程：

  1. 模型中有一个 embedding 矩阵，假设大小为 (词汇表大小 × 向量维度)。 - 比如词汇表大小是 100,000，向量维度是 512，则矩阵大小为 100,000 × 512。
  2. 每个 token（如 177519）会通过查表操作从这个矩阵中找到对应的行向量，例如：

token 177519 → [0.15, 0.68, -0.47, …, 0.22] # 维度是 512

token 979 → [0.32, -0.11, 0.50, …, 0.89]

token 28428 → [-0.27, 0.44, 0.78, …, -0.31]

结果：

  • 输入的 token 序列 [177519, 979, 28428] 经过 embedding 后，会变成一个矩阵：

[

[ 0.15, 0.68, -0.47, …, 0.22], # token 177519 的向量

[ 0.32, -0.11, 0.50, …, 0.89], # token 979 的向量

[-0.27, 0.44, 0.78, …, -0.31], # token 28428 的向量

]

btw，Meta 研究了一种新的模式做大模型，不再需要 Token 化，估计是另一套体系了。

btw，Token 化被证实是 NP 完备问题。https://www.oschina.net/news/326147/tokenization-tokenisation-is-np-complete

三、Prompt 工程

prompt 工程是一个研究很多、理论很多、方式很多的领域，现在甚至都研究到心理学、情绪掌控等方面。不要简单理解成“提示词怎么写”这个 prompt 工程下的小环节，这是一个误区。

CoT、ReAct 是一个大突破。但其实这些 prompt “框架”本质上可以理解为“直接面对大模型的策略”。本质上也是在大模型之外进行策略并与大模型交互。你会发现下边这个截图中，RAG 也被归到 prompt 工程中了。

Prompt 工程（包括 CoT 和 ReAct）通过设计精妙的输入提示来引导模型的推理或生成过程。即使在某些框架（如 ReAct）中涉及外部资源调用，它们的核心目的是控制模型的思维路径和行为，而不是将信息检索作为系统的主要组成部分。

RAG 强调的是信息检索和生成的结合，它的核心是在生成内容之前从外部知识库中检索相关信息，然后再生成回答。这种方法特别适用于那些需要实时或大量外部知识支持的任务。

RAG 更加依赖于外部信息检索作为生成的一部分，而 Prompt 工程 则通过细化和优化与模型的交互，提升模型的推理和生成能力。

四、DSPy

DSPy 是对 Prompt 工程在模式上的革新。对于开发者来说，不用直面大模型去优化 prompt 一步一步调优来“乞求 LLM 给出更好的回答”。可以更加专注于业务逻辑。

传统Prompt工程中的Prompt

在传统prompt工程中，prompt是直接提供给语言模型的输入，它通常需要精心设计以引导模型生成期望的输出。开发者需要根据模型的回答效果不断调整prompt的内容，这是一个试错的过程。

DSPy中的模板（Template）

在DSPy中，虽然你也提供了一个模板，但这个模板更像是一个指令或者是一个函数签名，它定义了输入和输出的格式，而不是直接控制模型的输出。这个模板是固定的，不需要根据不同的问题或任务进行调整。DSPy框架会使用这个模板，并结合其他技术（如检索、链式思考等）来自动生成和优化实际的prompt。

DSPy的优势

  1. 自动化优化：DSPy可以自动优化prompt的生成策略，而不需要开发者手动调整。这意味着，如果模型在某个任务上表现不佳，DSPy可以通过调整prompt的生成策略来优化性能。
  2. 模块化和可重用性：在DSPy中，你可以定义不同的模块来处理不同的任务，这些模块可以重用，也可以组合起来构建更复杂的系统。
  3. 减少试错：由于DSPy自动处理prompt的优化，开发者不需要花费大量时间尝试不同的prompt来找到最佳效果。

在DSPy中，模板定义了任务的结构，而实际的prompt生成和优化是由框架自动完成的。这样，开发者可以专注于定义任务和逻辑，而不是深陷于prompt的调整中。这就是DSPy所说的“不需要手动编写prompt”的真正含义，即不需要手动调整prompt来获得最佳性能。

DSPy 这个框架也考虑到了 RAG、Agent 等形态的 AI 系统构建，给出相应的“模板”

五、LangChain

LangChain 是一个大模型应用开发框架，它把相关技术上下游各种环节框架式地链式地组装起来了。你会发现前边提到的 Prompt 环节，以及后边要提的 Agent、记忆层、Function Calling / Tools 环节啥的都在框架里了吧。这里的“Data”本质上就是 RAG 入口。

六、Function Calling / Tools

Function Calling 是一种“指令生成”技术，模型负责创建调用逻辑，而执行逻辑则交由外部运行环境。

Tools 是一种“功能集成”技术，模型直接与工具交互，而工具返回的结果可以直接用于生成最终响应。让模型在需要时直接调用预定义的工具或 API 执行操作，并将结果整合进对话中。

一般是整合用，本质上是一体两个侧重方向的概念：模型通过 Function Calling 生成对某个 Tools 工具的调用指令，然后直接调用工具完成任务，实现动态性和执行力的结合。

以往，为了解决多个代理之间需要进行大量协调和推理工作的问题，就只能自己写代码实现各种调用（LangChain 类型），准确率较低。现在 Function Calling 的机制，将这种实现转移到了模型内部，准确率已经大幅提高。

LangChain 的 Tools 作用是将大模型与外部工具（如 API、数据库等）连接起来，只是充当了中介的角色。Function Calling，大模型可以直接和外部 API 或函数结合起来，执行特定的任务，如获取实时数据、执行计算等。

  • LangChain 通过 Prompt 设计 和 外部控制逻辑 驱动大模型使用工具
  • Function Calling 是在大模型内部实现的能力

七、Agent

Agent 的核心能力是自主推理与行动，通常指的是能够在环境中自主执行任务、做出决策并具有一定自主性的系统。

这里的 Agent 当然不是指应用层面的那种“角色扮演智能体”。

本质上也是 LangChain、Dify 之类的“链式框架”架构中衍生出来的中间件思维，但核心是“所谓的智能”，也就是在它这个代理节点可以智能搞定定向任务。

好像在这个上下文里没啥好说的。前边 RAG 里其实有关联到。在研发工程上可能比较值得说道的是它的“独立封装出一个智能模块”这个模式，比如你用 Dify 构建了一个完成某个任务的 Agent，那这个 Agent 是可以独立发布出来调用的，不会局限在 Dify 里。简单类比 Python 包。

  • 比较知名的开源框架，比如 AutoGPT、BabyGPT、MetaGPT，最早应该是 AutoGPT 带来了这种革新。

在大模型应用开发层面，AI Agent扮演着核心角色，涉及到技术架构、开发框架、智能体托管与服务等多个方面。以下是一些关键点：

  1. 技术架构：AI Agent的技术架构通常包括垂直智能体、智能体托管与服务、可观测性、智能体框架和记忆等模块。这些模块各自承担不同的功能和角色，例如垂直智能体专注于特定领域或任务，智能体框架提供开发AI智能体的基础，而可观测性工具则用于监控和分析AI智能体的性能和行为。
  2. 开发框架：存在多种Agent框架，包括单智能体（Single-Agent）和多智能体（Multi-Agent）系统。这些框架提供了开发AI智能体所需的工具和环境，简化了创建和训练AI模型的过程。
  3. 智能体托管与服务：平台如LangGraph、Letta、Amazon Bedrock Agents等提供了托管和运行AI智能体的服务，使得开发者可以更方便地部署和管理AI模型。
  4. 应用开发工具：AI原生应用开发工具，如App Builder和AI Agent开发工具（Agent Builder），为开发者提供了集成了语音识别、自然语言处理、图像识别等技术的AI能力支持，使得开发者能够轻松构建出具备智能化、个性化特点的应用。
  5. 实践案例：例如，Cognition AI推出的AI软件工程师Devin，展示了AI Agent在软件开发领域的应用，它能够处理整个开发项目，包括自学新语言和框架、开发迭代应用、自动Debug等。
  6. 构建AI Agent平台：平台如HuggingFace、Open AI、豆包等提供了丰富的预训练模型和工具，支持开发者快速构建和部署自然语言处理应用，也为AI Agent的开发提供了技术支撑。
  7. 零代码/低代码平台：例如Zion和扣子（Coze），这些平台通过自动化代码生成技术，帮助用户快速、低成本地开发和运营高度定制化的跨平台应用，使得没有技术背景的用户也能创建和训练自己的AI Agent。

https://www.letta.com/blog/ai-agents-stack

八、记忆层

记忆层能够让模型在长时间的交互中保持上下文信息，从而实现更自然和个性化的对话体验。

这个记忆环节，是很好的革新，把上下文拉出来管理。一般提供了面向记忆的增删改查的操作，但本质上还是调用大模型进行记忆的提取和更新这一类的操作。

mem0 是一个开源的、独立出来的 LLM 记忆层项目，源码特别简单，核心就是几个 prompt。

mem0 说比 RAG 牛逼的地方：

九、结构化 JSON 返回

没具体研究，但类比一下这两个图，思考一下结构化 JSON 返回可以怎样实现：

  • OpenAI 的原生 API：https://openai.com/index/introducing-structured-outputs-in-the-api/

构建自己的 RAG 系统方案

具体待尝试与讨论

1、这个体系搭建

2、一些核心技术环节的定制化选型和实现

3、业务整合形态

以下是简要提一些流行的项目。

一、框架搭建

以多 Agent 的 Agentic RAG 模式来说。最直接的框架应该是 RAGFlow：https://github.com/infiniflow/ragflow

https://uee.ai/301/infiniflow

包括它的理念和以 Agentic RAG 为核心，我认为最符合我们的实际。不过开源是开源了，没有架构、开发、源码侧文档，只有使用侧文档。

使用 LangChain 这个框架来构建自己的 RAG 的话，具体到基于 LangChain 来搭建一个 Agentic RAG 架构的业务系统，LangChain 为构建智能代理和任务驱动的应用提供了丰富的模块，很多基础功能（如任务调度、代理行为、工具调用、记忆管理等）都能直接支持 Agentic RAG 的设计思路。不过，由于 Agentic RAG 强调了动态的任务分解、策略选择、工具整合以及跨多个步骤的执行，因此需要进行一些架构调整和自定义开发来实现这一框架。

LangFlow 也是更偏向 LangChain 的框架，并强调可视化/低代码：https://github.com/langflow-ai/langflow

https://github.com/run-llama/llama_index，视角是“数据为核心”来组织开发 LLM 应用。

https://github.com/deepset-ai/haystack，偏搜索侧能力。

当然了，如果要搞 LazyGraphRAG 的话，那直接用微软开源的框架即可，不过还只到 GraphRAG，还没升级呢：https://github.com/microsoft/graphrag/discussions/1490

毕昇，开源了一些简单的部分，但 RAG 架子也是起来了：https://liduos.com/the-llmops-bisheng-introduce.html

二、具体环节的定制化（关键大环节，再细还得具体尝试和探索）

一、Prompt 环节

前边说的：

梳理完这一整个关键环节后，prompt 工程部分，其实可以修改了：

  • RAG 主打“让大模型到吃外部资源”这个数据源环节。
  • DSPy 主打“引导模型的推理或生成过程”这个更末端的环节。

二、re-ranking 环节

三、向量化环节

直接使用成熟的向量数据库，并且直播用原生的吧，连使用这些成熟的向量数据库都需要去研究。在咱们上下文里，更深地研究向量化这个环节是不现实的。

btw，Redis 正在研究向量数据类型。

四、结构化返回环节

因为需要与使用的大模型本身匹配才有更好的效果，所以使用什么返回 JSON 方案还得先看用的是什么模型。这里有一份工具罗列：https://www.boundaryml.com/blog/structured-output-from-llms

如果直接用的是 OpenAI 的大模型，那直接用它原生的 API 就行了，它甚至有个参数可以设定 JSON 样式：

五、Function Calling / Tools 环节

前边说的，Function Calling 能力集成到大模型本身了，才是有保证的，并且（专家说的）：

国内很少有大模型的 Function Calling 准确率能达到 90% 以上，有的甚至低至 20%，因此很难用于实际生产中。而 OpenAI 将 Function Calling 的准确率从 40% 提升到了 100%。

所以其实在我们的上下文里，需要的是在 Tools 环节去事。但其实也就是普通的“工具”能力代码编写，写出执行任务的“工具”，给大模型去调，本身没什么好特别研究的。

最后一个话题：

AutoGPT 这种专门以 Agent 为核心的体系和 Agentic RAG 这种以 RAG 为核心的体系，本质区别在哪里？

AutoGPT 和 Agentic RAG 的本质区别在于 系统核心驱动机制 和 适用场景的设计目标。可以从以下几个方面来分析两者的差异：

  1. 核心驱动机制

AutoGPT：以 Agent 为核心

  • 核心理念： AutoGPT 以多智能体（Agent）的自主性为核心，模拟人类任务执行过程。每个 Agent 都具备一定的决策能力，可以自主完成任务分解、工具调用和迭代优化。
  • 主要特征： - 自主性：Agent 可以基于全局目标动态决定执行的下一步，无需显式指导。 - 任务分解：Agent 会递归地分解任务成子任务，并按顺序执行。 - 动态协作：多个 Agent 可以根据任务需要分工合作。
  • 工作流程： - 用户提供一个高层次的目标（如“生成一份市场报告”）。 - Agent 自主分解为子任务，动态调用工具、检索知识和生成内容，直至目标达成。

Agentic RAG：以 RAG 为核心

  • 核心理念： Agentic RAG 将检索增强生成（RAG）作为任务执行的中心，通过动态代理（Agent）来管理检索、生成和反馈机制。
  • 主要特征： - 以 RAG 为基础：检索模块和生成模块是系统的核心，Agent 负责协调各模块的动态调用。 - 知识驱动：系统依赖知识库或外部资源，侧重基于检索的高质量回答。 - 反馈优化：通过反馈机制验证和优化每个步骤的结果。
  • 工作流程： - 用户提出具体问题或任务。 - 系统动态检索相关文档（或知识），生成初步答案。 - Agent 根据结果验证并调整后续步骤，最终返回精确回答。
  1. 设计目标

AutoGPT：面向泛化任务的自动化

  • 目标： 模拟人类执行复杂任务的过程，适用于需要任务分解和工具调用的泛化任务场景。
  • 适用场景： - 长期规划与执行：如制定业务计划或管理项目。 - 复杂的任务自动化：如多步分析、市场研究等。 - 无特定知识依赖的领域：任务主要依靠逻辑推理与外部工具。

Agentic RAG：面向知识密集型任务

  • 目标： 提供基于知识的高质量生成和回答，适用于需要结合检索和生成的知识密集型任务。
  • 适用场景： - 信息检索与生成：如法律咨询、技术文档解答。 - 高精度的问答系统：如客户服务、知识管理。 - 需要知识库支持的领域：任务对准确性和可靠性要求高。
  1. 数据流与控制流

AutoGPT 的数据与控制流：

  • 数据流： - 输入：高层次目标。 - 数据来源：互联网搜索、API 调用、临时上下文。 - 输出：任务最终结果。
  • 控制流： - 多 Agent 通过递归逻辑分解任务，并自主执行，每个 Agent 可独立完成任务分配。 - 任务完成方式更动态，但也更难保证精确性。

Agentic RAG 的数据与控制流：

  • 数据流： - 输入：具体问题或任务。 - 数据来源：结构化知识库、向量数据库或外部文档。 - 输出：生成的高精度回答。
  • 控制流： - Agent 作为协调者，基于检索结果动态调整生成逻辑。 - 系统内置反馈机制，能对生成的结果进行验证，确保准确性。
  1. 优缺点对比

AutoGPT

  • 优点： - 泛化能力强：可以处理广泛的任务类型。 - 自主性高：Agent 可根据上下文动态决策。
  • 缺点： - 缺乏精确性：适合探索性任务，但难以保证知识准确。 - 资源需求高：执行复杂任务时容易调用过多工具，效率较低。

Agentic RAG

  • 优点： - 高精度：结合检索和生成，适合需要准确回答的场景。 - 模块化设计：检索与生成模块分离，易于优化。
  • 缺点： - 灵活性较低：相比 AutoGPT，其任务种类局限于知识相关任务。 - 复杂性高：需要维护高质量的知识库和检索逻辑。
  1. 示例对比

示例 1：客户要求生成市场研究报告

  • AutoGPT： - 自动分解任务：搜索市场数据、整理分析、生成报告。 - 动态调用工具（如 Google 搜索、Excel 分析工具）。 - 最终生成完整的市场研究报告。
  • Agentic RAG： - 针对用户问题检索现有知识库中的相关数据。 - 使用语言模型生成市场分析的回答。 - 返回基于知识的摘要性市场研究结果。

示例 2：法律咨询

  • AutoGPT： - 搜索法律案例，尝试自行分析。 - 返回一个逻辑上合理但可能不够准确的答案。
  • Agentic RAG： - 检索法律数据库中的具体条款或案例。 - 验证生成内容与检索结果是否一致。 - 返回精确、权威的法律建议。
  1. 选择依据
  • 如果需要一个 泛化任务自动化 系统（例如探索性任务、没有现成知识库的场景）：选择 AutoGPT。
  • 如果需要一个 高精度、知识驱动 的系统（例如高可靠性问答、知识密集型任务）：选择 Agentic RAG。

总之，AutoGPT 更关注动态性和泛用性，而 Agentic RAG 更强调知识的权威性与准确性。

通过 Agentic RAG，可以把所有策略串起来，包括 Agent 模式，组装成更强大的系统。

h4cd avatar
h4cd
This human loves sanbu.

Related