典型向量数据库 RAG E2E 能力

RAG整体过程

RAG 概念最近比较火，RAG，Retrieval-Augmented Generation，检索增强生成。结合检索技术+大模型生成技术提供整体大模型生成的效果。同时 RAG 解决了大模型幻觉，知识更新不及时等等问题。

RAG 整体效果

RAG 的效果，其实是和文档处理，embedding，召回，以及最后的大模型效果都关联，可以简单用下面一个公式来表示：

两家典型厂商背景‍‍

• 腾讯 VectorDB

  • 基于 faiss 扩展而来

  • 2023 年 8 月上线

  • 2023 年 10 月份对外公测（单节点，EIP）

  • 2024 年 3 月 20 日开始计费

  • 2024 年 4 月10 日开始商用

  • 国内云厂商第一个发向量数据库

  • 腾讯云团队和内部团队合作共建（内部团队叫 Andon）

  • 向量数据库包含向量数据库+AI 套件，两者 API 单独，AI 套件导入的数据不支持修改

• Azure AI Search

  • 以前叫 “AI 认知搜索”

  • 2023 年 6 月向量检索公测

  • 2023 年 11 月向量搜索正式发布

  • 2024 年 2 月，向量的维度上限现在从 2048 增加到 3072

每个阶段的关键点‍‍‍‍

先来看看 RAG 每个阶段的一些关键点和优化经验。

步骤	关键点
数据提取	数据清洗：包括数据Loader，提取PDF、word、markdown以及结构化的数据库数据和API数据等； 数据处理：包括数据格式处理，不可识别内容的剔除，压缩和格式化等； 元数据提取：提取文件名、时间、章节title、图片alt等信息，非常关键。 文档类型 word 文档 TXT 文档 CSV数据表 Excel 表格 PDF 文件 PPT 文件 图片 视频
		数据分块（Chunking）	固定大小的分块方式：一般是256/512个tokens，取决于embedding模型的情况。但是这种方式的弊端是会损失很多语义，比如“我们今天晚上应该去吃个大餐庆祝一下”，很有可能就会被分在两个chunk里面——“我们今天晚上应该”、“去吃个大餐庆祝一下”。这样对于检索是非常不友好的，解决方法是增加冗余量，比如512tokens的，实际保存480tokens，一头一尾去保存相邻的chunk头尾的tokens内容； 基于意图的分块方式： 句分割：最简单的是通过句号和换行来做切分。当然也有通过专业的意图包来切分的，常用的意图包有基于NLP的NLTK和spaCy； 递归分割：通过分治的方法，用递归切分到最小单元的一种方式； 特殊分割：还有很多不常见的，用于特殊场景，这里就不提了。 影响分块策略的因素： 取决于你的索引类型，包括文本类型和长度，文章和微博推文的分块方式就会很不同； 取决于你的模型类型：你使用什么LLM也会有不同，因为ChatGLM、ChatGPT和Claude.ai等的tokens限制长度不一样，会影响你分块的尺寸； 取决于问答的文本的长度和复杂度：最好问答的文本长度和你分块的尺寸差不多，这样会对检索效率更友好； 应用类型：你的RAG的应用是检索、问答和摘要等，都会对分块策略有不同的影响。 复杂各式，错误影响最终效果 合理的拆分可以避免信息失真等。 一般是 300/400字节一个 chunk,bge 模型对短小文本相似度会非常高
embedding	各种算法，算法准确性 文本类，文关联图等
query 预处理	完整的 RAG 检索流程，在几个环节都有提升空间 query 预处理 结果召回 排序
检索召回
rerank
prompt	针对性优化 分布式引导



腾讯 VectorDB 主要优化点

腾讯向量数据库做了一些优化，看看其中的关键点

步骤	腾讯 VectorDB
数据提取	没有明显的优化
数据分块（Chunking）	对下面四种文档做了优化： pdf MD word ppt 主要优化是： 可以处理 pdf 表格，段落和标题标识出来，跨页/跨栏做了单独处理 AI 套件会对文档按照树重新组织，叶子节点重新拆分。保留主题和 chunk的关系，召回的时候，提供 api可以指定召回 chunk上下文。 内容增强
embedding	支持以下开源 embedding 模型 bge-base-zh（推荐） m3e-base text2vec-large-chinese e5-large-v2 multilingual-e5-base 还提供垂类embedding 模型微调，提升效果
query 预处理	query 预处理几个提升 意图识别，判断合适的问题决定走 RAG 链路 针对 query 生成同义词，不同问法，检索结果合并 query 预处理，将专有名词，简写，英文做标准化处理
检索召回	向量检索召回支持 FLAT，HNSW，IVF 索引算法 不支持全文检索和混合检索
rerank	基于 learning2Rank 思路提升文本语义排序效果，比开源的 bge-reranker-large(开源 SOTA）效果好
prompt	做了分布式引导，引导模型分布执行 代码化，提升模型推理能力
API&SDK	AI 套件： AI 类 Database 是专门用于 AI 套件上传和存储文件的向量数据库系统，可用于构建知识库。用户可以直接将文件上传至 AI 类 Database 下的 CollectionView 中，自动构建个性化的知识库。 AI 类 Database 不支持直接对向量数据进行操作，已上传的文件不支持更新文件内容。 为便于区别，腾讯云向量数据库将可直接操作向量数据的数据库称为 Base 类 Database。用户可以将向量数据上传至 Base 类 Database 中进行存储和管理，并可以直接对向量数据进行操作和处理。更多信息，请参见 Database。 示例：https://cloud.tencent.com/document/product/1709/102334 向量检索 API：https://cloud.tencent.com/document/product/1709/95820



Azure AI Search 主要优化点

Azure AI Search 能力很全，一起看看 AI Search 的关键能力。‍‍‍‍‍‍‍‍‍

步骤	Azure AI Search
数据提取	任何源，JSON 格式 连接各种数据源，包括 AzureSQL 数据库，Azure CosmosDB，Azure Blob存储
	Azure AI 服务集成 多语言搜索的翻译和语言检测 实体识别，从大型文本块中提取人员姓名、位置和其他实体 关键短语，提取识别和输出重要术语 光学字符识别 (OCR)，识别二进制文件中的印刷体文本和手写文本 图像分析，描述图像内容并将描述输出为可搜索的文本字段 通过 AI 服务生成文本再进入到切分，embedding 流程
数据分块（Chunking）	无特殊优化
embedding	集成 OpenAI embedding模型 OpenAI CLIP Ada text-embedding-3-large text-embedding-3-small 文本模型 图像模型：
query预处理	无特殊优化‍‍
检索召回	全文检索 向量检索  HNSW KNN 混合检索 包含search和vectors查询参数的单一查询请求 并行执行 利用查询响应中的合并结果，使用倒数排名融合 (RRF)打分 混合查询是全文搜索和矢量搜索的结合，执行的对象是一个包含可搜索的纯文本内容和生成的嵌入的搜索索引。 就查询而言，混合搜索定义如下： 混合搜索将全文查询和矢量查询的结果相结合，使用 BM25 和 HNSW 等不同的排名函数。倒数排名融合 （RRF）算法合并结果。 查询响应仅提供一个结果集，使用 RRF 从每个查询中选择最相关的匹配项。
rerank	全检检索：BM25 排名，关键词查找 混合查找（RRF） 倒数排名融合 (RRF) 是一种算法，可评估多个以前的排名结果中的搜索分数以生成统一的结果集。 每个查询都会生成一个排名结果集，RRF 可用于将排名合并和同质化为单个结果集，在查询响应中返回。 始终使用 RRF 的示例方案包括混合搜索和并行执行的多个矢量查询。 语义排序： 语义排序是一组与查询相关的功能，可提高基于文本的查询的初始 BM25 排序或 RRF 排序搜索结果的质量。 首先，它在使用 BM25 或 RRF 评分的初始结果集的基础上添加了二次排名。 此二次排名使用改写自 Microsoft 必应的多语言深度学习模型来提升在语义上最相关的结果的排名。 其次，它会提取并返回响应中的描述和答案，你可以在搜索页面上呈现它们以改进用户的搜索体验。
prompt	无特殊优化
知识存储	在物理上，知识存储是一个 Azure 存储，可以是 Azure 表存储和/或 Azure Blob 存储。 知识存储是 Azure AI 搜索中的技能组创建的 AI 扩充内容的辅助存储。 在 Azure AI 搜索中，索引编制作业始终将输出发送到搜索索引，但如果将技能集附加到索引器，还可以选择将 AI 扩充的输出发送到 Azure 存储中的容器或表。 知识存储可用于非搜索场景中的独立分析或下游处理，例如知识挖掘。 搜索索引和知识存储这两个索引编制输出是同一管道的互斥产品。 它们派生自相同的输入并包含相同的数据，但它们的内容会在不同的应用程序中结构化、存储和得到使用。
缓存扩充	增量扩充(预览)是指可在技能集执行期间重复使用的缓存扩充。 缓存在包括 OCR 和图像分析的技能组（处理成本很高）中尤其有用。