关于 RAG

一、什么是检索增强生成（RAG）

rag 是一项技术，是为了解决模型幻觉，优化输出内容出现的，目的是为了可以让模型回答时引用用户自己的知识库。

二、为什么检索增强很重要

由于大模型是在海量的数据下训练而成，大模型回答时是有不确定性，所以需要引入权威数据类似写论文那样可以给大模型回答背书，提高真实性，可靠性。目前大模型的回答往往有几个问题

• 当大模型不知道时，他会胡编乱造，而用户不自知

• 大模型由于训练数据原因，回答的问题会出现过时，虚假消息

特别是当他一本正经的回答时，很难察觉其中混淆的概念和真实性

三、检索增强的原理

传统的用户与大模型交互的过程是用户输入 prompt，然后直接把 prompt 传入到 llm 那里， 没有中间过程，而检索增强实际上就是在用户输入到 llm 中间新增一层，将用户的输入给拆解成关键词，通过关键词，语义等去匹配数据库，从数据库中获取到最相关的内容，与 prompt 拼凑起来，变成一个最终的提示词，一起发给 llm 的过程，这理解起来很简单，但是实际上比较困难的步骤如下：

• 如何找到最准确的数据引用？

• 如何准确的把数据进行分割？

• 如何选取最合适的数据库？

• 数据的索引如何构建？

• 数据如何实时更新？

workflow

四、RAG 准确率影响因素

实践过程中，rag 的效果往往不如人意，检索出来的内容五花八门，如果想要提升主要是几个方面：

• embedding模型的选择

• 判断相似度的算法

• 索引的建立

• 文本分块策略

• 检索结果重排序

Embedding 是什么？

Embedding 是将文本、图像等信息映射到高维向量空间的过程，使语义相似的内容在这个空间中距离更近。

简单来说，embedding 将抽象的信息数值化，使机器能够理解内容间的语义关系。例如，在一个向量空间中：

• "狗"和"猫"的embedding向量可能比较接近，因为它们都是宠物

• "汽车"和"交通"也会相对接近

• 而"狗"和"汽车"的向量则相距较远

现代 embedding 模型(如 OpenAI 的 text-embedding-3-large 或 Cohere 的 embed-multilingual )通常生成数百至上千维的向量，能够捕捉文本的细微语义差异。

相似度算法

从初等数学我们就学习了，欧氏距离，余弦相似度，这些计算坐标之间距离的算法，这里也同样进行介绍

1. 余弦相似度(Cosine Similarity): 计算两个向量夹角的余弦值，范围为[-1,1]，值越大表示越相似。不受向量长度影响，适合文本相似度计算。

2. 欧几里得距离(Euclidean Distance): 计算向量间的直线距离，值越小表示越相似。对向量长度敏感。

3. 点积(Dot Product): 简单快速，但需要向量归一化才能作为相似度指标。

4. 汉明距离(Hamming Distance): 适用于二进制向量，计算对应位置不同的数量。

选择相似度方法应根据具体应用场景和embedding特性决定。例如，对于文本语义搜索，余弦相似度通常是首选。

索引

高效的索引结构对大规模向量检索至关重要：

1. HNSW(Hierarchical Navigable Small World): 构建多层图结构，平衡查询速度和准确率，是当前最流行的向量索引方法之一。

2. IVF(Inverted File Index): 将向量空间分割为多个聚类，查询时只搜索最相关的聚类，提高检索速度。

3. PQ(Product Quantization): 通过向量压缩减少内存占用，适合超大规模数据集。

索引参数调优(如HNSW的M值、ef_construction)对检索性能影响显著。

文本分块

分块将初始文档分割成一定大小的块，尽量不要失去语义含义，将文本分割成句子或段落，而不是将单个句子分成两部分。

其中块的大小，如何去分块，按照句号分？按照语义分？如何判断哪些上下文是没有关联的，这都是重要的策略，后续单开一节来讲

检索结果重排序

最后一步我们成功的从数据库中找到了相似的十个文本，但是这个时候我们并不能一股脑丢过去，我们要进行过滤，筛选，排序，这实际上是一个资料库需要给大模型学习，如果你给的东西人类看不懂，那么 llm 大概率也是懵逼的。

可以根据相似度得分、关键词、元数据过滤结果，或者使用LLM等其他模型对结果进行重新排名，句子转换器交叉编码器，Cohere重排序端点或者基于日期新近度等元数据。

五、向量数据库对比

特性	Qdrant	Chroma	MongoDB Atlas	PGVector	Pinecone	Milvus	Infinity
主要特点	高性能向量搜索，丰富过滤功能	轻量级，为RAG优化	NoSQL数据库+向量搜索	PostgreSQL扩展，SQL兼容	托管服务，自动扩展	分布式架构，高可扩展性	混合搜索，SQL兼容
多模态支持	★★★★☆	★★★★☆	★★★★★	★★★☆☆	★★★★☆	★★★★☆	★★★★★
查询灵活性	★★★★★	★★★☆☆	★★★★☆	★★★★★	★★★☆☆	★★★★☆	★★★★★
易用性	★★★★☆	★★★★★	★★★☆☆	★★★☆☆	★★★★★	★★☆☆☆	★★★☆☆
扩展性	★★★★☆	★★☆☆☆	★★★★☆	★★★☆☆	★★★★★	★★★★★	★★★★☆
实时索引	★★★☆☆	★★★☆☆	★★★☆☆	★★☆☆☆	★★★☆☆	★★★☆☆	★★★★★
部署选项	自托管/云	自托管	云/自托管	自托管	云服务	自托管/云	自托管/云
开源状态	开源	开源	部分开源	开源	闭源	开源	开源
社区支持	★★★★☆	★★★★☆	★★★★★	★★★★☆	★★★☆☆	★★★★☆	★★☆☆☆
全文搜索	★★☆☆☆	★★☆☆☆	★★★☆☆	★★★☆☆	★★☆☆☆	★★☆☆☆	★★★★★
元数据过滤	★★★★★	★★★★☆	★★★★★	★★★★☆	★★★★☆	★★★★☆	★★★★☆
适合RAG	★★★★★	★★★★★	★★★★☆	★★★☆☆	★★★★★	★★★★☆	★★★★☆
适合大规模	★★★★☆	★★☆☆☆	★★★★☆	★★★☆☆	★★★★★	★★★★★	★★★★☆
SQL支持	❌	❌	部分	✅	❌	部分	✅
混合搜索	★★★☆☆	★★★☆☆	★★★☆☆	★★★☆☆	★★★☆☆	★★★☆☆	★★★★★

各数据库最适合的场景

数据库	最适合的场景
Qdrant	需要高性能和复杂过滤的RAG应用；需要精细控制搜索参数的场景
Chroma	快速原型开发；中小规模RAG应用；需要简单集成的项目
MongoDB Atlas	已使用MongoDB的项目；需要结合传统数据库功能和向量搜索的应用
PGVector	已有PostgreSQL基础设施的组织；需要SQL接口进行向量搜索
Pinecone	需要无服务器向量搜索解决方案；大规模生产环境；需要高可用性
Milvus	大规模向量搜索应用；需要自定义部署；高吞吐量要求
Infinity	需要混合搜索（全文+向量）；实时索引需求；SQL友好性要求高

选择建议

项目需求	推荐数据库	理由
快速原型开发	Chroma	简单易用，快速设置，与RAG框架集成良好
生产级部署	Qdrant/Pinecone	高性能，可扩展，生产就绪
已有PostgreSQL	PGVector	利用现有基础设施，SQL兼容
混合搜索需求	Infinity	结合全文和向量搜索能力
多模态内容	MongoDB Atlas/Infinity	原生支持多种数据类型存储
大规模部署	Pinecone/Milvus	设计用于大规模数据和高并发
实时更新内容	Infinity/Qdrant	更好的实时索引能力