Back to Blog

向量数据库与索引

向量数据库阶段把切片后的文本转换为向量，并将向量、原文、唯一 ID 和元数据一起持久化。它负责索引构建、过滤条件、相似度搜索和数据生命周期管理，不负责生成最终答案。 | 边界 | 数据 | 关键字段或返回值 | | --- | --- | --- | | 输入 | 或文本块 | 、 、 ，必要时带已有 | | E...

Type RAG

Created Aug 08, 2026, 06:30:00 / Updated Aug 08, 2026, 06:30:00

Views — / Comments — / Words 5,308

02 向量数据库与索引

这一阶段做什么

向量数据库阶段把切片后的文本转换为向量，并将向量、原文、唯一 ID 和元数据一起持久化。它负责索引构建、过滤条件、相似度搜索和数据生命周期管理，不负责生成最终答案。

输入与输出

边界	数据	关键字段或返回值
输入	Node[] 或文本块	id_、text、metadata，必要时带已有 embedding
Embedding 输出	list[float]	固定维度的浮点向量；查询和文档必须使用兼容模型
入库记录	向量记录	id、embedding、document/text、metadata
索引输出	VectorStoreIndex 等索引对象	保存索引配置并提供 as_retriever()、as_query_engine() 等入口
持久化输出	Collection / 持久化目录	数据库文件、集合配置、docstore、index store 或框架存储上下文

embed_model.get_text_embedding(text) 通常返回一个浮点数列表。VectorStoreIndex.from_documents(...) 或 VectorStoreIndex(nodes, ...) 返回索引对象。调用入库接口时，很多数据库返回新增 ID、操作结果或空值，不能把它当作检索结果。

主流程

flowchart LR
    A[Node 列表] --> B[准备唯一 ID 与 metadata]
    B --> C[Embedding 模型]
    C --> D[文本向量]
    D --> E{向量库选型}
    E -->|本地 / 原型| F[ChromaDB]
    E -->|分布式 / 大规模| G[Milvus 等]
    F --> H[Collection / Vector Store]
    G --> H
    H --> I[StorageContext / VectorStoreIndex]
    I --> J[持久化]
    J --> K[Retriever / QueryEngine]
    K --> L[进入查询检索]

使用顺序

1. 选定 Embedding 模型并固定向量维度、距离度量和模型版本。
2. 为每个 Node 设计稳定 ID，规划可过滤的元数据字段和多租户隔离字段。
3. 创建 Collection 或 Vector Store，再将其注入 StorageContext 或索引对象。
4. 批量写入向量、原文和元数据，随后执行持久化。
5. 重新加载数据库并做一次相似度查询，确认数据、过滤条件和索引都能恢复。

完成标准

• 文档向量和查询向量使用同一套或明确兼容的 Embedding 模型。
• 每条向量都有稳定 ID、可回溯原文和必要的过滤元数据。
• 重启进程后可以重新加载，记录数、索引配置和查询结果符合预期。
• 权限、多租户、备份、扩容和成本策略与数据规模匹配。

完整技术说明

以下内容保留源文档的全部正文、表格、代码、参数、链接和原有流程图，仅调整标题级别，使其纳入当前文档结构。

向量数据库概念介绍

RAG的入库流程，也称为索引构建或数据摄取 (Ingestion)，这个流程的核心目标是：将非结构化的文本数据，转化为结构化的、富含语义信息“知识碎片”，并建立高效的索引，转化为大型语言模型 (LLM) 可以检索和利用的结构化知识库的过程。入库的质量直接决定了RAG系统检索的上限，一个高质量、易于检索的知识库，直接决定了您的大模型在回答特定领域问题时的准确性和可靠性。

• 做什么：将所有文本块的向量，连同它们对应的原始文本内容，一起存储到专门的数据库（向量数据库）中，并建立高效的索引。
• 为什么：当用户提问时，系统需要快速地从数百万个向量中找到最相关的几个。索引就像图书馆的检索系统，能实现海量数据下的毫秒级查询。
• 关键点：
  • 数据库选择：常用的向量数据库有Chroma, Pinecone, Weaviate, Milvus, Faiss等。
  • 存储内容：数据库中存两样东西：向量（用于快速搜索）和 元数据（如来源文件名、页码、创建时间等，用于后期筛选和溯源）。

代码段

graph LR
    Doc[Documents] --> Loader([Loader])
    Loader -- Text --> Splitter([Splitter])
    
    subgraph Embedding Model
        Embed1{Embedding}
        Embed2{Embedding}
    end
    
    Splitter -- Chunks --> Embed1
    Embed1 -- "[x,x,...,x]" --> VS[(Vector Store)]
    
    User([User]) -- Question --> Embed2
    Embed2 -- "[x,x,...,x]" --> Retrieval([Retrieval])
    VS --> Retrieval
    
    Retrieval -- Relevant Chunks --> Prompt[/Prompt/]
    Prompt --> LLM((LLM))
    LLM -- Answer --> User

Embedding模型介绍

在检索增强生成(Retrieval-Augmented Generation, RAG)系统中, 嵌入(Embedding)模型承担着将文本转换为向量表示的核心职责, 直接决定检索质量的上限与整体系统的可扩展性。本节课围绕LlamaIndex框架, 系统梳理与评估主流Embedding模型的集成路径、性能特征与成本结构, 面向企业级落地给出可操作的选型策略与实施路线。

• Embedding 模型是一位博学的“索引员”。他阅读每一个文本块，然后根据其深层语义（而非表面关键词）为每个块生成一个独一无二的、浓缩了其含义的“身份ID”（即向量）。语义相近的段落，其“身份ID”在空间中也彼此接近。
• 向量数据库是“索引卡系统/GPS”，它不存储书籍原文，而是存储所有文本块的“身份ID”（向量）以及指向原文的链接。当你提出问题时，它能在毫秒级内找到与问题“身份ID”最相近的那些文本块的位置。
• 核心思想：入库的目标是构建能让 LLM 快速、精准找到相关知识的“语义地图”。
• 提示：后续章节将从模型选型、成本与评估、到向量库与组件协同逐步展开，并给出可运行的示例。

2.1 主流Embedding模型对比 (云 API vs 本地开源)

集成类型	典型依赖	配置要点	优势	注意事项
云端API(OpenAI、Cohere)	对应Python客户端、API密钥	通过LlamaIndex的Embedding类配置模型ID与参数;可设置base_url兼容自建兼容层	快速上线、免运维、弹性扩容	成本随调用量线性增长;需关注速率限制与数据出境合规
本地开源 (HuggingFace/SentenceTransformers、 BGE)	sentence-transformers或特定模型库;可选ONNX/Optimum	通过HuggingFaceEmbedding等类加载;可配置最大序列长度、维度与指令模板;可导出ONNX加速	数据可控、长期TCO友好、可离线使用	初期工程投入较高;需自建服务与监控;硬件与吞吐需评估

• 云端 API：免运维、弹性扩容，多语言强；需关注成本、速率限制与数据合规。
• 本地开源：数据可控、长期 TCO 友好；需工程投入与运维能力。
• 选型决策：
  • 合规/数据边界严格 → 本地开源（BGE / M3E）。
  • 多语种与全球化 → 云 API（OpenAI/Cohere）。
  • 成本敏感/入门 → text-embedding-3-small 或 jina-embeddings-v2。
  • 性能精排 → 组合 Embedding + Reranker（OpenAI/BGE Reranker）。

2.2 主流Embedding模型特性对比与中文推荐

模型系列	代表模型	维度	最大序列长度(Tokens)	核心优势	主要适用场景
OpenAI	text-embedding-3-large	3072 / 1536 / 512	8192	顶级通用语义理解、多语言能力强	高质量检索、复杂和多语言业务
OpenAI	text-embedding-3-small	1536 / 512	8192	极高性价比、性能均衡	大规模索引、成本敏感型应用
Cohere	embed-multilingual-v3.0	1024	512	强大的多语言能力，与Rerank模型生态协同好	全球化业务、需要高质量精排的场景
BGE (BAAI)	BGE-M3	1024	8192	多功能（稠密、稀疏、多向量）、长文本、中英文强	混合检索、长文档问答、中英混合场景
M3E (Moka AI)	m3e-base / m3e-large	768	8192	多语混合（中英优），长文本支持、检索表现强	企业多语种检索、中文主导场景、长文档问答
Jina AI	jina-embeddings-v2-base-en	768	8192	性价比高，长文本支持好	预算有限但需要处理长文本的场景
智谱AI	Embedding-3	256 / 512 / 1024 / 2048	8K	维度上进行多种选择	支持中文/英文混合、大段文本、甚至跨模态的语义检索

• 中文入门：BAAI/bge-small-zh 或 moka-ai/m3e-base。
• 进阶：BGE-M3（支持稠密/稀疏/多向量，长文本检索）。
• 生产：参考 MTEB 榜单，结合业务场景做 A/B 测试。
  • MTEB榜单 (Massive Text Embedding Benchmark (大规模文本嵌入基准))，这是一个用于评估和比较文本嵌入模型性能的权威基准测试。
  • 链接：https://huggingface.co/spaces/mteb/leaderboard
  • A/B测试就是将一个“新版本”（B）的大模型应用与当前“线上运行版本”（A）进行对比实验，在真实用户中评估哪个版本的综合表现更好。
• 提示：维度越高通常检索效果更稳，但存储与计算成本更高；最大序列长度影响切分与上下文覆盖。

2.5 评估指标定义与计算逻辑

指标	定义	计算逻辑	解释与适用场景
Hit Rate@k	前k条检索结果包含正确答案的是否命中	Hit Rate = 命中查询数 / 总查询数	衡量“能否找到”,适合召回充分性的对比
MRR@k	正确答案的首次出现位置的倒数,在前k条内的平均值	MRR = (1/rank_i)之和 / 总查询数,其中rank_i为第i个查询的正确答案首次排名	强调“找得准”,适合首条答案质量敏感的业务

• Hit Rate @ k：前 k 条检索结果包含正确答案的查询是否命中，它只关心“有”或“没有”，不关心排名位置，是否存在至少一个相关（即能用来正确回答问题）的文档。
  • 存在则得分为1；否则为0。
  • K值的选择：
    • Hit Rate @ 1：非常严格，要求最相关的文档必须排在第一位。这衡量了系统的“精准度”。
    • Hit Rate @ 5/10：更宽松，更侧重于衡量“召回率”。只要正确答案出现在前5或前10，就算成功。这在实践中更常用，因为后续的LLM可以从多个片段中综合信息。
  • 特点：简单、快速，能宏观反映检索的可靠性。
• MRR @ k：正确答案首次出现位置的倒数，在前 k 条内的平均值，即平均倒数排名。它不仅关心是否检索到了相关文档，还关心相关文档的排名位置。排名越靠前，得分越高。
  • 它比Hit Rate更精细，能反映出排序模型的质量。
  • 对于单个问题，找出排名最高的相关文档所在的位置（排名）。例如，第一个相关文档排在第2位，则其排名为2。
  • 计算这个排名的倒数。在上例中，倒数就是 1/2 = 0.5。没有任何相关文档，则倒数为0。
  • 对所有问题的倒数得分取平均值。

在实际RAG评估中的应用建议

• 结合使用：这两个指标是互补的，而不是互斥的。一个优秀的RAG检索系统应该同时拥有高Hit Rate和高MRR。
  • 高Hit Rate + 低MRR：系统能找到答案，但经常把它们藏在后面。你需要优化排序模型/重排器。
  • 低Hit Rate + 高MRR（较少见）：系统排在前面的东西质量很高，但经常完全漏掉正确答案。你需要优化召回，比如调整分块策略或使用更强大的嵌入模型。
• 与生成指标结合：Hit Rate和MRR是检索器指标。要全面评估RAG，还需要将它们与生成器指标结合，例如：
  • Faithfulness：答案是否基于检索到的上下文，没有胡编乱造？
  • Answer Relevance：答案是否直接回答了问题？
  • Context Relevance：检索到的上下文是否精炼且相关？

2.6 模型使用思考

• 延迟敏感：客服 FAQ/短问短答 → 轻量模型与低 top_k。
• 长文档问答：注意切分策略与最大长度；推荐 BGE-M3、较大维度模型。
• 跨语种：选择多语言模型或分语种路由；可引入翻译与多向量策略。
• 迭代路线：纯向量检索 → 加入 Reranker → 引入 Hybrid Search混合检索。

3.1存储能力矩阵与选择要点

向量存储	存储文本	元数据过滤	混合检索	删除/更新	持久化形态	部署复杂度	典型场景
SimpleVectorStore	是(默认内存,可持久化)	支持(框架层过滤)	依赖后端能力	支持删除与持久化	本地文件	低	快速实验、本地小规模
Chroma	支持(集合中管理文本与元数据)	支持	部分能力(依实现与查询)	支持 add/update/upsert/delete	本地/持久化/容器	中	开发者友好、本地到中小规模
Pinecone	否(侧重向量,文档内容依赖外部存储)	支持	支持(稠密/稀疏/混合)	支持删除与命名空间清理	云托管 (Serverless)	低-中	云端高并发、低延迟
Weaviate	支持(集合中管理对象与文本)	支持	支持(与 BM25 等稀疏结合)	支持(动态批处理)	自托管/云	中	现有集群集成、混合检索
Qdrant	支持(集合中管理 payloads)	支持	支持(稠密+BM25)	支持(集合级操作)	自托管/云	中	混合检索、性能取向
Milvus	依集成与模式(向量为主)	支持(字段过滤)	依索引与实现	支持(集合/分区级)	自托管/云	中-高	亿级向量、毫秒级检索
Faiss	否(仅存储向量)	否	否	删除未实现	本地文件	低	本地高效相似度搜索

3.3 元数据建模与过滤

• 目的：让检索不仅“找得近”，还“找得对”。通过元数据过滤限定业务域、部门、时间段、语种等。

• 建模示例：

  • {"source": "policy.pdf", "section": "leave", "page": 12, "lang": "zh", "department": "HR", "updated_at": "2024-08-01"}

• 统一元数据键名与取值范围；时间使用 ISO 格式；必要时建立“路由层”先根据元数据选择库或命名空间。

• 能力关注：持久化与一致性、元数据过滤、混合检索支持、删除/更新能力、部署复杂度与成本。

• 元数据设计建议：source / section / page / lang / department / updated_at 等，便于过滤与路由。

• 入库执行时机：离线全量与增量更新。

  • 离线构建：上线前对已有知识库全量入库。
  • 增量更新：新文档加入时触发针对新内容的入库流程，索引支持增量更新。

典型工作流程

# 1. 初始化存储组件
vector_store = ChromaVectorStore(chroma_collection)
storage_context = StorageContext.from_defaults(vector_store=vector_store)

# 2. 创建向量索引 (自动使用storage_context)
index = VectorStoreIndex.from_documents(
    documents,
    storage_context=storage_context,
    embed_model=OpenAIEmbedding()
)

# 3. 查询时自动利用存储上下文
query_engine = index.as_query_engine()
response = query_engine.query("查询问题")

两者协同工作关系

组件	职责	数据流向
StorageContext	存储管理、持久化、多存储协调	向下管理具体存储后端
VectorStoreIndex	索引构建、查询处理、相似性计算	向上提供查询接口

数据入库实现方式

• LlamaIndex 内置 + 内存向量 (快速 PoC) : 实现最简单，适合验证。不可持久化、不易扩展到大数据量。
• 本地向量库 (FAISS/Chroma/Milvus) : 低延迟、可离线、成本可控；FAISS 单机扩展有限，Milvus 需运维。
• 云向量服务 (Pinecone/Weaviate/Qdrant/Milvus Cloud) : 高可用与扩展性强；成本与隐私需评估。
• 混合检索 (倒排 + 向量) : 关键词初筛 + 向量精排，兼顾精准命中与语义召回。

两种持久化方法对比

4.1 chromadb.PersistentClient(path=...) (数据库层级持久化)

import chromadb
# 数据库层级的持久化
chroma_client = chromadb.PersistentClient(path="./chroma_db")

特点：自动实时持久化，数据一致性更高；频繁 I/O，资源消耗较高，适合生产。

4.2 vector_store.persist(persist_path=...) (框架层级持久化)

from llama_index.vector_stores.chroma import ChromaVectorStore

# 框架层级的持久化
chroma_client = chromadb.PersistentClient(path="./chroma_db")
vector_store = ChromaVectorStore(chroma_collection=chroma_client.get_or_create_collection("docs"))
# 或者显式调用
vector_store.persist(persist_path="./chroma_db")

• 特点：手动批量持久化，I/O 次数可控；开发调试更灵活，程序异常退出可能丢数据。
• 建议：生产优先使用原生持久化；开发调试可用框架持久化并做好异常保护与备份。

向量检索工具封装

VectorDB 是 LlamaIndex 提供的一个 向量数据库工具封装类，它继承自 BaseToolSpec。

• 作用：将已构建的 VectorStoreIndex 封装为可被智能体 (Agent) 调用的工具，支持多源知识库与路由检索。
• 对比：VectorDB (面向 Agent, 底层 VectorStoreIndex) 、 QueryEngineTool (封装 QueryEngine) 、 ToolSpec (基础类) 、 RetrieverQueryEngine (执行检索) 。
• 支持后端：Milvus、MongoDB Atlas Vector、Pinecone、Weaviate、Qdrant、FAISS、Chroma。
• 推荐搭配：RetrieverQueryEngine + MetadataFilters + Agent, 按用户角色/部门/语种做路由与权限控制。

它不是直接用来检索的，而是把一个“向量检索能力”包装成一个可调用工具 (ToolSpec)；之后，你可以在 Agent、QueryEngineTool、或者多工具组合系统 (Multi-Tool Agent) 中直接使用；它能让大语言模型通过自然语言调用底层向量检索逻辑（例如 Milvus、Pinecone、FAISS等）；同时保留了 LlamaIndex 原有的过滤、权重和组合能力。

使用场景	说明
Agent 工具集成	让一个 LLM (如 GPT) 能通过自然语言调用“知识库检索”功能。
多模态或多知识源融合	当系统有多个 VectorIndex (例如”报告知识库""产品知识库”)，可以给每个建一个 VectorDB，并交给 Agent 动态选择调用。
自定义 Query Engine 集成	将 VectorDB 与 RetrieverQueryEngine 或 RouterQueryEngine 组合，实现多源路由检索。
企业内部知识问答系统	通常配合 Milvus / Pinecone / MongoDB Vector Store 使用，将不同业务库做成不同 Tool。

向量数据库进阶思考

5.1 安全与多租户

在构建基于RAG（检索增强生成）等AI应用时，向量数据库的安全性和多租户能力是确保系统稳定、可靠、合规的基石。多租户架构的核心目标是让多个租户（可以是不同部门、不同业务线或不同客户）共享同一套系统，但保证每个租户的数据、配置和性能表现是相互隔离的。

• 命名空间/集合隔离：按业务域、环境 (dev/prod) 、租户维度划分；避免数据交叉与权限泄漏。
• 访问控制：云向量服务配置 API Key 与 RBAC；自托管结合网关与反向代理控制访问。
• 合规与加密：敏感数据尽量本地化；磁盘与传输加密；日志脱敏；审计与可追溯。

5.2 性能与成本优化

向量数据库的优化是一个系统工程，贯穿了从数据准备、入库到查询的全链路。核心思路在于：“前置减轻负担，中间加速处理，后续精准打击”。 前置：通过合适的模型和量化技术，从源头减少数据体积。 中间：利用批处理和缓存，提升系统整体的吞吐量和响应速度。 后续：在检索时，通过 top_k 与 Reranker 的配合，以最小成本获取最佳答案。

• 降维与模型选择：向量维度越高存储与计算越贵；在可接受精度下选中小型模型 (如 bge-small-zh 512) 。
• 批量与缓存：批量嵌入、批量写入；热点问题与结果缓存；减少重复计算与 I/O。
• top_k 与重排：召回 top_k 不宜过大；结合 Reranker 提升前几条质量而不显著增加成本。
• 删除与更新策略：不支持删除 (如纯 Faiss) 时采用“软删除 + 重建”或旁路过滤；增量更新做好去重与版本标记。

5.3 部署与运维

• 形态：单机 (Chroma/Faiss) → 自托管集群 (Qdrant/Milvus/Weaviate) → 云托管 (Pinecone/Weaviate Cloud) 。
  • 选择自托管集群意味着你对数据和架构有完全的控制力，但需要面对显著的运维挑战。例如，Milvus在设计上就依赖Kubernetes以实现企业级扩展，这意味着你需要具备相应的k8s运维能力。
  • 选择云托管服务则是一种“省心”的方案，供应商会负责所有底层基础设施、软件升级和可用性保障，让你可以专注于业务逻辑开发。
• 持久化与备份：原生持久化优先；定期快照与异地备份；版本化索引目录。
• 监控指标：写入/查询 QPS、p95/p99 延迟、召回质量变化、存储占用、压缩比、失败率；定期索引重建与数据压实 (compaction) 。

---

常见问题

• Embedding 维度变更的影响与迁移：存储大小、索引重建、模型切换的兼容性。
• 中文/英文混合场景：语种路由与多语言模型选择；切分策略是否保留中英文标点。
• Chroma collection 命名与目录组织：按业务域/部门/环境 (dev/prod) 分命名空间。
• Faiss 不支持删除的处理：重建索引或标记失效并旁路过滤。
• Milvus 索引参数选择 (IVF/HNSW/DiskANN) : 结合数据量、延迟与召回需求评估。
• 云 API 速率限制：退避重试与并发控制；网络抖动等问题。

官网参考

各主流向量数据库官网地址

• FAISS https://faiss.ai/
• Milvus https://milvus.io/
• Chroma (又称 ChromaDB) https://www.trychroma.com/
• Pinecone https://www.pinecone.io/
• Qdrant https://qdrant.tech/
• Weaviate https://weaviate.io/

— 商业转载请联系站长获得授权，非商业转载请注明本文出处及文章链接，您可以自由地在任何媒体以任何形式复制和分发作品，也可以修改和创作，但是分发衍生作品时必须采用相同的许可协议。本文采用 CC BY-NC-SA 4.0 - 非商业性使用 - 相同方式共享 4.0 国际 进行许可。

Comments

Notes, questions, and follow-ups are welcome here.

Comments are temporarily unavailable because WALINE_SERVER_URL or PUBLIC_WALINE_SERVER_URL is not configured.