春哥Agent通关秘籍12：本地RAG实战中下向量化与落库

时间：2026-06-01 12:05

在开启新内容前，先快速回顾前两节课的核心要点：第10课通过 ollama 的API，将一段文本成功转换为了【句向量】。第11课使用Python代码，把一篇Markdown文档切分成适合生成句向量的短文本片段。没错，本节课的目标非常明确：借助已有的工具生成句向量，并将其妥善存储起来。一、向量存

在开启新内容前，先快速回顾前两节课的核心要点：

第10课通过 ollama 的API，将一段文本成功转换为了【句向量】。
第11课使用Python代码，把一篇Markdown文档切分成适合生成句向量的短文本片段。

没错，本节课的目标非常明确：借助已有的工具生成句向量，并将其妥善存储起来。

一、向量存储库的选择

市面上向量数据库种类繁多，例如老牌的 Milvus、云端的 Pinecone、以及 Qdrant。但最终我们选择了 ChromaDB，原因就两个字：便捷。

无需 Docker、无需端口映射、无需操心繁杂的环境配置——简单高效。不过它有一个容易踩坑的地方：采用“写入时推断 (Schema-on-Write)”模式。

它不要求像写 SQL 那样预先定义表结构、维度或相似度算法。你只需将模型计算出的向量丢入，它就自动锁定对应的格式。一旦提交，终身锁定。

二、双引擎，更强力

ChromaDB 的能力远不止向量存储与查询，它内部集成了两种引擎：

结构化引擎： SQLite（专门管理元数据）
向量引擎： hnswlib（专门负责距离计算）

当我们拆分数据并插入时，实际上执行了两次写入：

第一次：带有元数据（比如 {"source": "company_rules.md", "章节": "考勤管理"}）和原始文本的数据，存入本地的 SQLite 关系型数据库。
第二次：由 bge-small 计算出的 512 维向量数组，并未存入 SQLite（关系型数据库无法高效计算高维距离），而是被插入到由 C++ 编写的基础图索引库——hnswlib。

查询时采用分层方式：先查 SQLite，再查 hnswlib，从而实现极致提速。

三、计算向量

按照常规编程思路，流程通常是：

调用 Ollama 的 API，获取每个文本片段的句向量。
调用向量数据库的 API，将这些句向量连同元数据存储起来。

思路完全正确！但实际编码时并不完全依照这个步骤，因为本次使用的向量数据库 chromadb 天然就是为此场景设计的。因此实际编码思路应为：

定义好向 Ollama 发送请求的函数。
准备好文本切片和元数据。
把这些交给 chromadb，它会自动完成上述步骤。

核心代码如下：

import chromadb
import ollama

class OllamaEmbeddingFunction:
    def __init__(self, model_name):
        self.model_name = model_name
    def __call__(self, input):
        # 自动调用本地 Ollama 计算句向量
        response = ollama.embed(model=self.model_name, input=input)
        return response['embeddings']
    def name(self):
        return self.model_name

def main():
    client = chromadb.PersistentClient(path=DB_PATH)
    # 获取或创建集合
    collection = client.get_or_create_collection(
        name=COLLECTION_NAME,
        embedding_function=OllamaEmbeddingFunction(model_name=MODEL_NAME)
    )
    collection.add(
        documents=docs_texts,
        metadatas=docs_metadatas,
        ids=docs_ids
    )

你可能会好奇：上面的代码里怎么多了一个 docs_ids？它是什么？为什么一定要手动传入？

四、chromadb 拒绝自动生成主键

使用 chromadb 之前，必须了解它与传统关系型数据库最大的不同：

chromadb 不提供自动生成主键的能力。

为什么不呢？

原因很现实：如果数据库帮你自动生成 ID（比如 1, 2, 3 或随机的 abc-123），会引发两个致命问题：

无法更新和删除： 假如文档中改了一个错别字，你想更新向量库，但你根本无法知道 ChromaDB 当初给这段话分配了什么 ID，也就无法精准替换。
灾难级的重复存入： 如果不小心又把脚本跑了一遍，自动生成 ID 会导致数据库里出现两份完全相同的文本和向量。搜索时前两个结果可能就是一模一样的内容。

因此，从工程角度出发，ChromaDB 把 ID 的控制权交给开发者——必须在插入时主动传入 ids。

五、选择你的 id

目前最常见的方式有两种：

插入前生成 uuid，简单直接，但每次生成的 ID 必然不同。
计算切片的 hash，再与文档名拼接，实现“文本不变则 ID 稳定”的机制。

如果对 ID 稳定性要求高，选择方案2；如果只是做 demo 或文档检索，先用方案1更高效。

docs_ids.append(str(uuid.uuid4()))

六、先删后插

当原始文档更新后（比如改了一个错别字、增加了一段话），切分后的块会发生剧烈的“雪崩位移”。

此时重新训练并再次入库，为了避免重复存储或数据污染，最稳妥简单的做法是：

collection.delete(where={"source": SOURCE_NAME})
# 执行写入 (因为前面已经删干净了，这里直接用 add 即可)
collection.add(
    documents=docs_texts,
    metadatas=docs_metadatas,
    ids=docs_ids
)