RAG 技术完全指南（二）：Embedding 模型选型与 Chroma 数据库实战

一、Embedding 嵌入模型

1.1 概念

Embedding 模型 是一种将 离散数据（如文本、图像、音频） 转换为 连续向量（高维数值表示） 的机器学习模型。它的本质是 在高维空间（如 768 维或 3072 维）中建立数据的语义映射，使得相似的数据在向量空间中距离相近，不相似的数据距离较远。

1.2 核心思想

数据数值化
- 计算机无法直接理解文字、图片等非结构化数据，Embedding 将其转换为 数学向量（如 [0.2, -0.5, 0.7, ...]），便于相似度计算和处理。
- 通过余弦相似度、欧氏距离等度量向量关联性，支撑检索增强生成（RAG）、推荐系统等应用。
- 一般采用余弦相似度进行度量，因为欧氏距离取值范围为 [0, +∞) ，不易度量，而余弦相似度取值范围为 [-1, 1] ，便于度量，负数可表示负相关，0 表示不相关，正数表示正相关，一般使用 [0, 1] 即可。
  示例：
  - 单词 “cat” → [0.3, -0.2, 0.8]
  - 单词 “dog” → [0.4, -0.1, 0.7]
  - 单词 “car” → [-0.5, 0.6, 0.1]
  - 则 cosine_sim("猫", "狗") > cosine_sim("猫", "汽车")
语义编码
- Embedding 不仅编码数据本身，还捕获其 语义关系。
  - 相似语义："国王" - "男人" + "女人" ≈ "女王"
  - 类比关系："巴黎 - 法国 ≈ 东京 - 日本"
降维与稠密表示
- 原始数据（如 One-Hot 编码）通常是 稀疏高维 的（维度=词汇表大小），而 Embedding 将其压缩为 稠密低维 向量（如 300 维），同时保留关键信息。

1.3 关键技术

上下文依赖：现代模型（如 BGE-M3）动态调整向量，捕捉多义词在不同语境中的含义
训练方法：对比学习（如 Word2Vec 的 Skip-gram/CBOW）、预训练+微调（如 BERT）。

1.4 局限性

数据依赖：质量取决于训练数据（如领域偏移问题）。
黑箱性：难以解释向量每一维的具体含义。
维度灾难：过高维度可能导致计算成本增加，需权衡性能与效率。

1.5 模型分类

1.5.1 通用全能型

BGE-M3：多语言混合检索（稠密+稀疏）），8K 长文本支持，适合企业级知识库、跨境电商搜索。
NV-Embed-v2：基于 Mistral-7B 微调，复杂语义理解，需较高计算资源，适合法律、医疗专业检索。

1.5.2 垂直领域特化型

中文场景：
- BGE-large-zh-v1.5：合同条款特殊优化、政策文件解析，适合政务文档智能检索。
- M3E-base：网络用语适应、短文本强化，适合社交媒体分析。
多模态场景：
- BGE-VL： OCR 文本融合、视觉语义对齐，适合电商商品图文搜索。

1.5.3 轻量化部署型

nomic-embed-text：知识蒸馏+量化，768 维向量，推理速度比 OpenAI 快 3 倍，适合边缘设备。
gte-qwen2-1.5b-instruct：模型剪枝，1.5B 参数，16GB 显存即可运行，适合初创团队原型验证。

1.6 模型选型

1.6.1 主要因素

因素	说明
任务性质	匹配任务需求(问答、搜索、聚类等)
领域特性	通用 vs 专业领域(医学、法律等)
多语言支持	需处理多语言内容时考虑
维度	权衡信息丰富度与计算成本
许可条款	开源 vs 专有服务
最大 tokens	适合的上下文窗口大小

1.6.2 选型决策

中文为主：BGE 系列 > M3E；
多语言需求： BGE-M3 > multilingual-e5；
预算有限：开源模型（如 Nomic Embed）

二、Chroma 数据库

官方文档

GitHub 仓库

2.1 Chroma 是什么？

定位：一款轻量级、开源的嵌入式向量数据库，专为 AI 应用设计。
核心功能：存储和检索 Embedding 向量，支持相似性搜索和元数据过滤。
设计哲学：简化开发流程，让开发者快速集成向量检索功能，无需复杂部署。

2.2 核心特性

轻量易用：以 Python/JS 包形式嵌入代码，无需独立部署，适合快速原型开发。
灵活集成：支持自定义嵌入模型（如 OpenAI、HuggingFace），兼容 LangChain 等框架。
高性能检索：采用 HNSW 算法优化索引，支持百万级向量毫秒级响应。

多模式存储：内存模式用于开发调试，持久化模式支持生产环境数据落地

存储模式	适用场景	性能表现
内存模式	快速原型开发	极快，但重启丢失
SQLite	轻量级持久化（单文件）	适合中小规模数据
DuckDB	高性能分析（实验性）	百万级向量支持

内置 Embedding 支持，默认使用 all-MiniLM-L6-v2 模型（384 维，Sentence-BERT 系列）。支持替换为：本地模型（Hugging Face）和云服务 API（OpenAI、Cohere）
元数据管理
- 支持为每个向量附加键值对标签，实现混合查询

2.3 技术架构

graph LR
    A[Client API] --> B[向量索引 HNSW/Faiss]
    A --> C[元数据存储 SQLite/DuckDB]
    A --> D[Embedding 模型]
    D -->|可选| E[本地模型]
    D -->|可选| F[云API]

向量索引：默认采用 HNSW 算法（近似最近邻搜索），平衡精度与速度。
持久化：数据以 SQLite 文件存储，便于迁移和备份。
扩展性：单机设计，适合千万级以下向量数据。

2.4 典型应用场景

RAG（检索增强生成）
多模态搜索
推荐系统

2.5 与同类数据库对比

特性	Chroma	Pinecone	Weaviate	Qdrant
部署复杂度	⭐（无需部署）	⭐⭐⭐（全托管）	⭐⭐（需 Docker）	⭐⭐（需配置）
Python 集成	⭐⭐⭐（原生）	⭐⭐⭐（SDK）	⭐⭐（客户端）	⭐⭐（客户端）
分布式支持	❌	✅	✅	✅
元数据查询	✅（基础）	✅（高级）	✅（GraphQL）	✅（过滤）
适合数据规模	<1 千万	十亿级	千万级	亿级

2.6 局限性及应对

单机限制：数据量超千万时性能下降 → 迁移至 Milvus/Qdrant。
无事务支持：需保证幂等性写入 → 业务层实现重试机制。
社区版功能限制：企业需求（如 RBAC）需自行扩展或选商业方案。

2.7 快速开始

1 2	`# 安装 pip install chromadb`

import chromadb

# 默认 chromadb 采用的 embedding 模型是 all-MiniLM-L6-v2，其维度是384
DEFAULT_DIMENSION = 384
# ======================== 初始化客户端 ========================
# 内存模式（开发环境）
client = chromadb.Client()
# 持久化模式（生产环境）
# client = chromadb.PersistentClient(path="/path/to/save")

# ======================== 创建集合 ========================
# 创建集合（类似数据库表，默认使用 all-MiniLM-L6-v2 作为嵌入模型）
collection = client.create_collection(
    name="docs",  # 类似数据库表名
    metadata={"hnsw:space": "cosine"},  # 指定余弦相似度计算
    # embedding_function=HuggingFaceEmbeddings(
    #     model_name="BAAI/bge-small"
    # ),  # 自定义嵌入模型
)

# ======================== 添加数据 ========================
# 自动生成向量
collection.add(
    documents=["文档内容1", "文档内容2"],
    metadatas=[{"source": "book"}, {"source": "paper"}],
    ids=["doc1", "doc2"],
)
# 手动传入向量
collection.add(
    embeddings=[
        [0.1] * DEFAULT_DIMENSION,
        [0.2] * DEFAULT_DIMENSION,
    ],
    documents=["文档内容3", "文档内容4"],
    ids=["doc3", "doc4"],
)

# ======================== 相似性查询 ========================
# 文本查询
results = collection.query(
    query_texts=["什么是Chroma数据库？"],  # 查询文本
    n_results=1,  # 返回最相似的1个文档
    where={"source": "book"},  # 按元数据查询
    where_document={"$contains": "文档内容1"},  # 按文档内容查询
)
print(f"文本查询结果：{results['documents'][0]}")

# 向量查询
results = collection.query(
    query_embeddings=[[0.1] * DEFAULT_DIMENSION],  # 查询向量
    n_results=1,  # 返回最相似的1个文档
)
print(f"向量查询结果：{results['documents'][0]}")

# ======================== 更新 ========================
print(f"更新前：{collection.get(ids=['doc1'])}")
collection.update(
    documents=["文档内容5"],
    metadatas=[{"source": "book"}],
    ids=["doc1"],
)
print(f"更新后：{collection.get(ids=['doc1'])}")
# ======================== 删除/获取条目数 ========================
print(f"删除前：{collection.get(ids=['doc1'])}")
print(f"现存条目数：{collection.count()}")
collection.delete(ids=["doc1"])
print(f"删除后：{collection.get(ids=['doc1'])}")
print(f"现存条目数：{collection.count()}")

2.8 总结

适用场景：原型开发、中小规模生产、需要快速迭代的 AI 应用。
优势：零配置起步、Python 原生接口、内置 Embedding 支持。
推荐搭配：LangChain/LlamaIndex 构建完整 AI 工作流。

ai > rag

#AI大模型 #检索增强生成 #Embedding #Chroma

RAG 技术完全指南（二）：Embedding 模型选型与 Chroma 数据库实战

https://blog.echo-silence.top/posts/79e4cc85.html

作者

极客奶爸

发布于

2025年5月21日

许可协议

RAG技术完全指南（三）：LamaIndex架构解析与私有知识库搭建上一篇

RAG技术完全指南（一）：检索增强生成原理与LLM对比分析下一篇