Skip to main content

RAG

RAG

RAG的过程

  1. 拆分文本成文本块
    1. 拆分算法：
  2. 使用嵌入模型进行向量化
    1. 对一段文本使用一堆维度很多的向量进行表示
  3. 存入向量数据库
  4. 对输入进行向量化
  5. 使用传统的向量距离计算算法进行向量数据库的检索
  6. 提取数据库的原文片段，整合成prompt，投喂给LLM打模型
  7. 对输出整理和提取

技术局限性

  1. 切片粗暴
    1. 简单分块算法 (如按段落或固定字数)
    2. 太小了没有全局信息，句子可能被截断, 影响上下文理解
    3. 太大了不能精确统计
  2. 检索不精准
    1. 向量匹配基于数字相似性, 不代表实际含义
      1. 向量本质上不能完全代表“语义”
      2. 本质上需要表示一段文本的 meaning tree
    2. 结果可能与提问无关
  3. 没有大局观
    1. 无法处理结构化数据或统计型问题
    2. 大模型难以从数据碎片中做出准确总结
  4. 不能进行复杂的逻辑推理和动态交互

向量检索方法

  1. 主流向量检索方法都是基于欧几里得距离设计，主要看“谁离你最近”；但有时AI其实更需要比较“语义相关性”，也就是最大内积、看谁最相似。

  2. 内积空间并不是一个严格意义上的“度量空间”。一个空间可以称之为“度量空间”，最重要的属性就是“三角不等式”（三角形中任意两边之和大于第三边，而任意两边之差小于第三边）。HNSW、NSG、SSG等state-of-the-art的向量检索算法之所以能如此高效，就是因为他们都利用了三角不等式对索引结构（图结构）进行了高效的裁剪。

    1. 一是把最大内积转换为最小欧式距离，进而可以用HNSW、NSG来解决
    2. 二是不进行空间转化，直接在内积空间进行检索

进阶方案

  1. 加入重排序模型
    1. 初步检索数据 -> 语义分析
    2. 重新排序, 提高检索精度
  2. 使用MCP Server连接传统的数据库
    1. AI操纵关系型数据库
    2. 解决结构化数据查询问题
  3. 超大上下文模型
    1. 直接拖入资料, AI进行检索
    2. 如JiminI2.0 Pro, 上下文窗口长达2000万token
  4. 知识图谱RAG GraphRAG（见下）
    1. LPG：labeled property graph
    2. 使用大模型+prompt 生成
      1. 识别
      2. 合并
      3. 使用固定程序拼接成图谱

GraphRAG

开源项目

  1. 微软的Graph RAG
  2. 蚂蚁开发了首个对外开源的Graph RAG框架，蚂蚁全自主的开源产品：DB-GPT[50] + OpenSPG[42] + TuGraph[46]
    1. 跨图谱零拷贝融合，连接数据孤岛：替代实现，不断推理，建立逻辑关系
    2. 深度语义上下文关联：替代实现高级抽象
    3. 知识符号化表示，与大模型双向驱动：
    4. SPG-Reasoner逻辑规则推理，通过谓词语义和逻辑规则来定义知识之间的依赖和传递

GraphRAG过程

索引构建过程
  1. 使用文本分段技术将文档进行分块
  2. 关系（LPG）提取，分析每个文本单元并提取图元素：实体、关系和协变量
    1. 把文本加上合适的prompt，喂给LLM，要求 LLM 提供简短的摘要来完成
    2. 实体消歧
    3. 协变量提取
  3. 图增强
    1. 理解图的拓扑结构，并进行分类
      1. 使用分层莱顿算法生成node group的层次结构
    2. 使用 Node2Vec算法生成图中节点的向量表示。使我们能够理解图的隐式结构，并提供额外的向量空间，以便在查询阶段搜索相关概念
  4. node group 总结 -- 总结和推理出额外的信息
    1. LLM 生成每个社区（node group）的摘要
      1. 能够了解每个社区中包含的独特信息，并从高级或低级角度提供对图表的范围理解
      2. 这些报告包含执行概述，并引用社区子结构中的关键实体、关系和声明
    2. 生成社区报告、社区报告摘要和社区报告标题的文本嵌入来生成社区的向量表示
  5. 文件处理
    1. 链接到已经存在的TextUnits
      1. 将每个文档链接到第一阶段创建的文本单元，创建文本块之间的上下文关系
      2. 了解哪些文档与哪些文本单元相关
    2. 文档嵌入
      1. 使用文档切片的平均嵌入来生成文档的向量表示
      2. 对不重叠的块重新分块文档，然后为每个块生成嵌入
      3. 创建这些块的平均值，并按标记计数加权，并将其用作文档嵌入
      4. 能够理解文档之间的隐式关系，并帮助生成文档的网络表示
  6. 网络可视化
    1. 对于每个逻辑图，执行 UMAP降维以生成图的 2D 表示
查询过程
  1. 本地搜索
    1. 从低层级的节点开始搜索指定最大结果数量
    2. 使用向量查询关键Node和相关的Node
      1. MapReduce
    3. 问题+搜索到的原文+总结性描述 一起打包发给LLM
  2. 问题生成
  3. 全局搜索
    1. 从高层级的总结（node）开始搜索指定最大结果数量

缺点

  1. 关系太简单、固定，不能真正表达复杂的内含关系
    1. 关系的种类太少，只能识别简单的类似“A是B”的逻辑关系
    2. 关系的处理的深度太浅，广度太窄
    3. 只能处理自然语言能够表达的逻辑，不能处理非常抽象的概念
  2. 根据已经有的资料库总结和推理出额外的信息的能力不够
    1. 抽象的级别不够高级
  3. 只能处理已经写好的（prompt）里面的逻辑关系
    1. 不能自动不断积累（增加）需要分析的逻辑关系、能力
  4. 不能根据实际内容进行有目的的动态索引
    1. 按照固定算法搜索匹配数据库，不能根据实际逻辑关系动态控制
  5. 效率低
    1. 信息爆炸，需要处理的token非常庞大，导致速度非常慢
  6. 回答的风格和具体的模型非常相关
    1. 好的，用户让我用中文解释“xxx”
    2. ### xxx的定义与核心内涵 ### xxx的技术实现路径 ### xxx的协同创新维度 ### 总结与展望

待解决

  1. 符合需求的数据集
    1. 数据集难以构建和被准确得评估
      1. 通过对数据集得label进行打分，分数是一个可以被量化的指标
  2. 逻辑操作的种类很多，prompt放不下
  3. 基础设施的完善
    1. 图数据库，向量数据库
    2. 逻辑规则推理Reasoner

No comments to display

Back to top