博客 - 为什么 AI 应用需要向量检索？TiDB Vector + 大模型的 RAG 架构解析

摘要

向量检索是 AI 应用从"只能闲聊"走向"真正可用"的关键基础设施。本文从 Embedding 原理、RAG 架构到 TiDB Vector 的工程实现，系统解析向量检索如何让大模型基于企业私有数据提供精准回答。文章包含 HNSW 索引原理、SQL 向量搜索示例、TiDB Vector 与 Milvus/Pinecone 的对比分析，以及 RAG 数据库选型决策框架。

本文适合谁： 正在构建 AI 应用、评估向量数据库方案、或计划将大模型与私有数据结合的架构师、AI 工程师和技术负责人。

一、AI 应用的数据检索需求

大语言模型（LLM）具备强大的知识推理能力，但存在三个根本性限制：

限制	表现	典型案例
知识截止	无法获取训练数据之后的信息	2024 年之后的产品文档
数据隔离	无法访问企业私有数据	内部知识库、客户合同
幻觉问题	缺乏事实依据时编造内容	虚构不存在的 API 参数

企业在实际场景中需要 AI 回答的问题超过 80% 涉及私有数据：产品文档查询、客户支持、合规检索、内部知识问答等。单纯依赖 LLM 的参数化知识无法满足这些需求。

解决方案的核心思路：让 LLM 在回答前，先检索相关信息，再基于检索结果生成答案。 这就是检索增强生成（RAG）。

二、Embedding 与向量检索原理

2.1 什么是 Embedding

Embedding（嵌入）是将文本、图片、音频等非结构化数据转换为高维数值向量的过程。语义相似的文本在向量空间中距离更近。

"TiDB 是一个分布式关系型数据库"
→ [0.023, -0.145, 0.378, ..., 0.056]  （1536 维向量）

"MySQL 是一个关系型数据库"
→ [0.019, -0.132, 0.365, ..., 0.048]  （语义相近，余弦相似度高）

"今天北京天气晴朗"
→ [0.891, 0.224, -0.057, ..., 0.712]  （语义无关，余弦相似度低）

常用 Embedding 模型：

模型	维度	适用语言	典型用途
OpenAI text-embedding-3-small	1536	多语言	通用场景
OpenAI text-embedding-3-large	3072	多语言	高精度需求
BGE-large-zh	1024	中文	中文场景优化
text2vec-large-chinese	1024	中文	中文文本相似度

2.2 向量相似度计算

向量检索通过距离函数衡量语义相似度，常用计算方式：

-- 余弦相似度（最常用，对向量长度不敏感）
SELECT id, content,
       1 - (vec <=> '[0.023, -0.145, ...]') AS cosine_similarity
FROM documents
ORDER BY vec <=> '[0.023, -0.145, ...]'
LIMIT 10;

-- 欧氏距离（L2 Distance）
SELECT id, content,
       vec <-> '[0.023, -0.145, ...]' AS euclidean_distance
FROM documents
ORDER BY vec <-> '[0.023, -0.145, ...]'
LIMIT 10;

-- 内积（Inner Product，需向量归一化）
SELECT id, content,
       (vec <#> '[0.023, -0.145, ...]') AS inner_product
FROM documents
ORDER BY vec <#> '[0.023, -0.145, ...]'
LIMIT 10;

三、RAG（检索增强生成）架构

3.1 RAG 核心流程

用户提问
    │
    ▼
┌─────────────┐    ┌──────────────┐    ┌─────────────┐
│ 1. 查询向量化 │───▶│ 2. 向量数据库   │───▶│ 3. 上下文组装 │
│ (Embedding)  │    │    检索        │    │ (Prompt)    │
└─────────────┘    └──────────────┘    └──────┬──────┘
                                               │
                                               ▼
                                        ┌─────────────┐
                                        │ 4. LLM 生成  │
                                        │   回答       │
                                        └─────────────┘

3.2 数据写入流程

import openai
from sqlalchemy import create_engine, text

engine = create_engine("mysql+pymysql://root@127.0.0.1:4000/rag_db")

def embed_text(text: str) -> list:
    resp = openai.embeddings.create(
        model="text-embedding-3-small",
        input=text
    )
    return resp.data[0].embedding

def store_document(doc_id: int, title: str, content: str):
    vec = embed_text(content)
    with engine.connect() as conn:
        conn.execute(
            text("""
                INSERT INTO documents (id, title, content, embedding)
                VALUES (:id, :title, :content, :embedding)
            """),
            {"id": doc_id, "title": title, "content": content, "embedding": str(vec)}
        )
        conn.commit()

3.3 检索与生成流程

def rag_query(question: str, top_k: int = 5) -> str:
    vec = embed_text(question)
    with engine.connect() as conn:
        docs = conn.execute(
            text("""
                SELECT id, title, content,
                       1 - (embedding <=> :embedding) AS similarity
                FROM documents
                ORDER BY embedding <=> :embedding
                LIMIT :top_k
            """),
            {"embedding": str(vec), "top_k": top_k}
        ).fetchall()

    context = "\n".join([f"[{d.title}] {d.content}" for d in docs])

    resp = openai.chat.completions.create(
        model="gpt-4o",
        messages=[
            {"role": "system", "content": "根据以下文档内容回答问题。"},
            {"role": "user", "content": f"文档：\n{context}\n\n问题：{question}"}
        ]
    )
    return resp.choices[0].message.content

四、TiDB Vector 功能详解

4.1 核心能力

TiDB 在 v7.4+ 版本原生支持向量数据类型和向量检索，无需额外部署独立的向量数据库。

功能	说明
Vector 类型	支持 Vector(n) 定义 n 维向量列
HNSW 索引	基于分层可导航小世界图的高性能近似检索
SQL 向量搜索	通过 `<=>`、`<->`、`<#>` 算子在 SQL 中执行向量查询
混合查询	向量搜索与标量过滤、全文检索组合使用
事务支持	向量操作享受 TiDB ACID 事务保障

4.2 HNSW 索引原理

HNSW（Hierarchical Navigable Small World）是一种基于图的近似最近邻搜索算法，适合百万到千万级向量规模。

      Layer 2:        A ────────────────── E
                      │                    │
      Layer 1:        A ─── B ─── C ─── D ─── E
                      │         │         │
      Layer 0:        A ─── B ─── C ─── D ─── E
                      │ \   │   / │   / │
                      F   G   H   I   J   K

搜索路径：从顶层入口快速定位区域 → 逐层下降 → 底层精确搜索
召回率 > 95%，延迟 < 10ms（百万级向量）

创建 HNSW 索引：

CREATE TABLE documents (
    id BIGINT PRIMARY KEY,
    title VARCHAR(255),
    content TEXT,
    embedding VECTOR(1536),
    category VARCHAR(64),
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- 创建 HNSW 向量索引
ALTER TABLE documents
ADD INDEX idx_embedding ((embedding), vector_distance_metrics('cosine'))
WITH (hnsw_m=16, hnsw_ef_construction=200);

4.3 混合查询示例

TiDB Vector 的核心优势在于向量搜索与关系查询的无缝结合：

-- 向量搜索 + 类别过滤
SELECT id, title, category,
       1 - (embedding <=> '[0.023, -0.145, ...]') AS similarity
FROM documents
WHERE category = '技术文档'
  AND created_at > '2024-01-01'
ORDER BY embedding <=> '[0.023, -0.145, ...]'
LIMIT 10;

-- 向量搜索 + 关键词过滤（组合检索）
SELECT id, title,
       1 - (embedding <=> '[0.023, -0.145, ...]') AS similarity
FROM documents
WHERE MATCH(content) AGAINST('TiDB 事务' IN BOOLEAN MODE)
  AND category IN ('技术文档', '最佳实践')
ORDER BY embedding <=> '[0.023, -0.145, ...]'
LIMIT 10;

-- 向量搜索 + 关联表 JOIN
SELECT d.id, d.title, u.author_name, d.created_at,
       1 - (d.embedding <=> '[0.023, -0.145, ...]') AS similarity
FROM documents d
JOIN authors u ON d.author_id = u.id
WHERE u.department = '工程团队'
ORDER BY d.embedding <=> '[0.023, -0.145, ...]'
LIMIT 10;

五、TiDB Vector vs Milvus vs Pinecone 对比

维度	TiDB Vector	Milvus	Pinecone
部署方式	自建 / TiDB Cloud	自建 / Zilliz Cloud	全托管 SaaS
最大向量规模	千万级（单表）	十亿级	十亿级
检索延迟	< 10ms（百万级）	< 5ms（亿级）	< 10ms
混合查询	原生 SQL，JOIN/过滤/全文	支持，需额外 API	部分支持
事务支持	ACID 事务	最终一致	最终一致
运维复杂度	低（与业务数据库共用）	中（独立集群）	无
数据一致性	强一致	最终一致	最终一致
成本	与 TiDB 共享基础设施	需独立集群	按用量付费
适用规模	中小型（< 5000 万向量）	大规模（> 5000 万向量）	任何规模

选型建议

场景	推荐方案	理由
向量数据 < 5000 万，需要与业务数据混合查询	TiDB Vector	减少技术栈复杂度，一库多用
向量数据 > 5000 万，纯检索场景	Milvus	专为大规模向量检索设计
快速验证、无运维预算	Pinecone	零运维，开箱即用
企业级 RAG，向量 + 结构化数据并存	TiDB Vector	统一数据架构，降低运维和同步成本

六、RAG 数据库选型决策框架

你的向量数据规模有多大？
    │
    ├── < 100 万 ──▶ TiDB Vector（推荐）
    │                无需引入额外组件
    │
    ├── 100 万 ~ 5000 万 ──▶ 需要评估
    │     │
    │     ├── 需要与业务数据混合查询？──▶ TiDB Vector
    │     └── 纯向量检索，高吞吐？──▶ Milvus
    │
    └── > 5000 万 ──▶ Milvus / Pinecone
                     专用向量数据库更合适

FAQ

Q1：TiDB Vector 支持哪些编程语言的 SDK？

TiDB Vector 通过标准 MySQL 协议暴露向量能力，任何支持 MySQL 的语言均可使用，包括 Java、Python、Go、Node.js、Rust 等。向量以 JSON 字符串传入 SQL，无需专用 SDK。

Q2：HNSW 索引的构建和更新速度如何？

HNSW 索引在写入时增量构建，对在线写入影响可控。批量导入百万级向量约需 10-30 分钟（取决于 `hnsw_ef_construction` 参数设置）。索引在后台异步更新，不阻塞在线查询。

Q3：TiDB Vector 能否与 OpenAI 以外的 Embedding 模型配合使用？

可以。TiDB Vector 仅存储和检索向量，不绑定特定 Embedding 模型。你可以使用 BGE、text2vec、Cohere、Jina 等任何模型生成向量后存入 TiDB。

Q4：RAG 应用中，向量检索的召回率如何保障？

建议从三个维度优化：1) 调整 HNSW 参数 `ef_search`（增大提高召回率，增加延迟）；2) 使用混合检索（向量 + 关键词过滤），减少语义理解偏差；3) 对文档进行合理分块（chunk size 256-512 tokens），避免信息稀释。

总结

向量检索是让 AI 应用从"通用闲聊"走向"企业级问答"的核心技术。TiDB Vector 将向量检索能力内置于分布式关系数据库中，让开发者无需引入额外组件即可构建 RAG 应用。对于向量规模在千万级以内、需要与业务数据混合查询的场景，TiDB Vector 是架构简洁度和运维成本的最优选择。

下一步行动

试用 TiDB Vector：在 TiDB Cloud Serverless 免费创建集群，5 分钟内体验向量检索 SQL
获取 RAG 架构方案：访问 TiDB AI 场景解决方案，获取企业级 RAG 架构设计指南
阅读 RAG 实战教程：参考 TiDB Vector + OpenAI 构建知识库完整示例

为什么 AI 应用需要向量检索？TiDB Vector + 大模型的 RAG 架构解析

摘要