仅用于站内搜索，没有排版格式，具体信息请跳转上方微信公众号内链接
在当今数字化时代，数据正以惊人的速度增长，而其中非结构化数据的飞速发展尤为引人注目。根据IDC的预测，从2023年到2028年，全球数据量将持续攀升，到2028年，非结构化数据占比将高达82.3%，远超结构化数据。这一趋势在互联网领域表现得尤为明显，非结构化数据的占比已经超过80%。
非结构化数据涵盖了音频、视频、图片和文本等多种形式。这些数据类型具有以下特点：
数据规模大：非结构化数据的生成速度极快，数据量呈爆发式增长。
信息密度高：每一段音频、每一帧视频或每一张图片都可能包含丰富的信息。
处理成本高：由于缺乏统一的结构，非结构化数据的处理和分析需要复杂的算法和技术支持。
向量化表示是解决非结构化数据管理难题的关键技术之一。通过深度学习模型，我们可以从非结构化数据中提取特征，并将其转化为向量形式。这些向量不仅能够高效地表示数据的特征，还具备强大的语义表达能力。例如，通过神经网络提取图像或文本的特征向量后，我们可以利用这些向量进行相似性检索。
向量化表示的优势在于：
语义表达能力：向量能够捕捉数据的内在语义，使得相似的内容在向量空间中更接近。
高效检索：向量检索可以通过计算向量之间的距离（如内积或欧式距离）来快速找到最相似的内容。
向量检索技术是向量化表示的自然延伸。通过构建向量索引，我们可以以图或倒排索引的方式组织数据，从而加速检索过程。向量检索的核心在于通过向量之间的距离计算，快速找出与查询向量最相近的向量。
向量检索的关键步骤包括：
向量索引构建：使用图或倒排索引的方式组织向量数据，以便快速定位。
距离计算：通过内积或欧式距离等方法，计算查询向量与数据向量之间的相似度。
近邻搜索：检索过程本质上是近邻图的遍历过程，需要进行大量的浮点运算以找到最相近的向量。
RAG（Retrieval-AugmentedGeneration）范式是一种结合了检索（Retrieval）和生成（Generation）的混合模型架构，旨在解决大语言模型的上述挑战。RAG范式的核心思想是通过检索外部数据源来增强模型的生成能力，从而提供更准确、更及时的信息。
RAG范式的主要特点包括：
数据预处理：对数据进行清洗、标注和向量化处理，使其能够被高效检索。
查询改写：将用户的自然语言查询转换为更精确的检索表达式，以提高检索效果。
多数据源：整合多个数据源，包括结构化数据、非结构化数据和半结构化数据，以提供更全面的信息。
并行混合检索：结合向量检索和传统文本检索，通过并行处理提高检索效率和准确性。
通过RAG范式，模型可以实时检索最新的信息，避免幻觉问题，同时确保生成内容的可溯源性。
向量数据库是RAG范式的重要支撑技术。它通过将数据向量化存储，并利用高效的向量检索算法，能够快速找到与查询向量最相似的内容。向量数据库的优势在于：
高效检索：支持大规模数据的快速检索，能够处理复杂的向量相似性计算。
语义理解：通过向量表示，能够捕捉数据的语义特征，提供更精准的检索结果。
动态更新：支持数据的实时更新和插入，确保检索结果的时效性。
向量检索的高资源消耗不仅仅是硬件层面的问题，它还涉及到算法和工程架构的全面挑战：
算力需求：向量检索需要进行大量的浮点运算，尤其是向量之间的距离计算（如内积或欧式距离）。这些运算对CPU和GPU的计算能力要求极高。
内存需求：由于向量数据的高维度和大规模，向量检索需要大量的内存来存储索引和数据。这不仅增加了硬件成本，还对内存管理提出了更高的要求。
工程架构：为了支持高效的向量检索，需要设计复杂的分布式架构和优化算法。这包括数据分片、索引构建、缓存机制等多个方面，以确保系统的可扩展性和稳定性。
在向量检索中，召回率是指检索到的相关结果与所有相关结果的比例。对于许多应用场景来说，召回率的高低直接决定了系统的实用性和可靠性。然而，当召回率接近100%时，每提升一个百分点，都需要付出巨大的代价。
搜索延迟的增加：为了提高召回率，检索系统需要进行更全面的搜索，这往往会导致搜索延迟的显著增加。例如，将召回率从99%提升到99.9%，可能需要增加接近一倍的搜索延迟。这意味着系统需要更强大的计算资源和更复杂的数据处理机制。
索引的近似性问题：向量检索通常依赖于近似最近邻（ANN）算法来加速检索过程。然而，这种近似性可能会导致某些相关结果被遗漏，尤其是在面对未知查询时，召回率难以保证。
索引的静态性问题：传统的向量索引往往是静态的，一旦构建完成，就很难动态调整。这可能导致部分查询总是陷入局部最优解，从而无法找到全局最优解。
向量检索技术的性能挑战主要体现在以下几个方面：
高QPS（每秒查询次数）需求：在许多实时应用场景中，如广告推荐、智能客服等，系统需要在极短的时间内响应用户的查询请求。这意味着向量检索系统必须具备高QPS的处理能力，以确保用户体验的流畅性。
低延迟要求：除了高QPS，向量检索还需要在极短的时间内完成复杂的向量计算和检索任务。例如，在广告投放系统中，延迟过高可能导致广告无法及时展示，从而影响广告效果和用户体验。
大规模数据处理：随着数据量的不断增长，向量检索系统需要处理的数据规模也越来越大。这不仅对存储提出了更高的要求，还对检索效率和扩展性提出了挑战。
水平扩展难：在大规模数据场景下，向量检索系统的水平扩展能力至关重要。然而，由于向量检索的复杂性和资源消耗，实现高效的水平扩展并非易事。
向量检索技术的核心目标是高效地检索出与查询向量最相似的结果。然而，在实际应用中，我们常常需要在成本、精度和性能之间做出权衡：
成本（Cost）：成本是向量检索系统的重要考量因素。为了降低成本，我们通常会采用量化或降维等技术来减少存储和计算资源的消耗。然而，这些优化手段往往会牺牲一定的精度。
精度（Accuracy）：精度是向量检索系统的核心指标。为了提高检索精度，我们可以通过增加向量的维度或扩大检索深度来实现。但这些方法会显著增加算力需求，进而导致成本上升。
性能（Performance）：性能包括检索延迟和吞吐量。为了提升性能，降低延迟和提高吞吐量，我们需要更强大的硬件支持，这无疑会增加硬件成本。
在向量检索中，成本和精度是一对典型的矛盾。为了降低成本，我们常常采用以下方法：
量化：通过将浮点数向量量化为低位整数或二进制向量，可以显著减少存储空间和计算量。然而，量化会导致信息丢失，从而降低检索精度。
降维：通过降维技术（如PCA、t-SNE等）将高维向量映射到低维空间，可以减少计算复杂度。但降维同样会丢失部分信息，影响检索结果的准确性。
UCS是蚂蚁集团自研的行列混合存储系统，旨在为向量数据库提供高效、灵活且可扩展的存储解决方案。其核心设计理念包括以下几点：
行列混合存储：UCS同时支持行存和列存，能够根据不同的查询需求灵活选择存储方式。行存适合点查和更新操作，列存则适合向量检索和聚合查询，这种混合存储方式兼顾了效率和灵活性。
存算分离：UCS采用存算分离架构，将存储和计算资源解耦，使得存储和计算可以独立扩展。这种架构不仅提高了资源利用率，还增强了系统的可扩展性。
读写分离：通过读写分离机制，UCS能够将读操作和写操作分离到不同的节点，避免读写冲突，提高系统的并发处理能力。
独立Compactor：UCS配备了独立的Compactor模块，负责数据的压缩和整理。这一模块可以异步运行，避免对主业务流程的干扰，同时提高存储效率。
VectorDB是蚂蚁集团基于自研存储底座UCS开发的向量数据库。它不仅继承了UCS在行列混合存储、存算分离和高可扩展性方面的优势，还增加了向量索引和混合检索引擎，进一步提升了向量检索的效率和精度。VectorDB的整体架构设计如下：
存储层（StorageLayer）：基于UCS的行列混合存储，支持行存和列存，能够高效处理大规模向量数据。存储层通过DFS（分布式文件系统）实现数据的持久化存储，并通过异步复制机制保证数据的高可用性和容错能力。
索引层（IndexLayer）：VectorDB引入了向量索引，支持多种索引算法（如HNSW等），以加速向量检索过程。索引层通过Compactor进行索引构建和优化，确保索引的高效性和准确性。
检索层（RetrievalLayer）：VectorDB新增了检索代理服务（Uni-Proxy），负责接收用户查询请求，并将其分发到相应的检索节点。检索层结合向量索引和混合检索引擎，能够快速返回最相似的结果。
接入层（AccessLayer）：提供统一的接口，供用户与VectorDB进行交互。接入层支持多种编程语言和协议，方便用户快速接入和使用。
在某些场景下，可以结合多种索引方案，例如先使用IVF-PQ进行粗略检索，再通过HNSW对候选结果进行精排，从而在成本、召回率和性能之间找到最佳平衡。
#加好友领取PDF#
#学习大模型&讨论Kaggle#
△长按添加竞赛小助手
每天大模型、算法竞赛、干货资讯
与36000+来自竞赛爱好者一起交流~
