向量库原理知识总结
向量管"像不像"，元数据管"要不要"——理解这一句，就理解了向量库的核心设计。
向量库RAGAI基础设施知识管理
一、核心概念
向量（Vector）
- 一组数字（如512个或1024个），用来表示一段内容的"语义坐标"
- 由向量模型（Embedding Model）自动计算生成，人类读不懂，但机器能用它计算相似度
- 任何内容（文本、图片、音频）都可以被转化为向量
向量库（Vector Database）
- 专门存储、索引、检索高维向量数据的数据库
- 核心能力：给定一个查询向量，快速找到最相似的向量
- 三件事：存（向量+元数据）、搜（索引加速的相似度搜索）、管（增删改查、过滤、持久化）
RAG（检索增强生成）
- 一种架构模式，不是单一技术
- 三步流程：
- R（Retrieve）：把用户问题向量化，在向量库中搜索相关片段
- A（Augmented）：把搜到的片段拼进 Prompt，告诉大模型"参考这些资料回答"
- G（Generation）：Chat 模型基于资料生成回答
- RAG 系统的各个环节（切片、向量化、检索、重排序、生成）各自独立存在，组装在一起叫"RAG 系统"
二、完整流程
存储流程
选择向量库 → 选择向量模型 → 读取数据源 → 切片 → 向量化 → 存入向量库
检索流程
用户提问 → 元数据过滤（缩小范围）→ 向量搜索 + 关键词搜索（多路召回）
→ Rerank 重排序（精选最相关的）→ 拼装 Prompt → Chat 模型生成回答
三、向量库选型
选型核心考量（按优先级）
- 数据规模：百万级以下都行，千万级选 Milvus/Qdrant，十亿级基本只有 Milvus
- 数据安全：数据能否出外网，不能则必须私有化部署
- 运维能力：有专业团队选 Milvus，团队小选 Qdrant，不想运维选云服务
- 已有技术栈：已有 PostgreSQL 可先试 pgvector
- 是否需要分布式
专用向量库 vs 传统数据库加插件
- 专用向量库（Milvus、Qdrant）：向量搜索性能强，索引算法丰富，适合向量搜索是核心能力的场景
- 传统数据库加插件（pgvector）：无额外运维成本，适合向量搜索只是辅助功能的场景
主流向量库对比
| Milvus | Qdrant | Chroma | Pinecone | |
|---|---|---|---|---|
| 定位 | 企业级重型 | 企业级轻型 | 开发/学习 | 云托管 |
| 数据规模 | 十亿级 | 亿级 | 百万级 | 亿级 |
| 部署复杂度 | 高 | 低 | 极低 | 无 |
| 国内使用 | 最多（中国公司） | 在增长 | 学习用 | 少 |
四、向量模型选择
核心差异维度
- 语言能力：中文专精（bge-zh）vs 多语言（bge-m3、e5-large）
- 维度：512 / 1024 / 1536 / 3072，越高精度越好但成本越高
- 最大输入长度：决定单个切片能多长，超过会被截断导致语义丢失
- 训练数据/语料：通用语料 vs 领域语料，影响特定领域的检索准确率
- Benchmark 跑分：MTEB/C-MTEB 榜单的实测检索准确率
选型考量
- 数据能否出外网？不能 → 本地部署（bge 系列）；能 → 可用 OpenAI API
- 纯中文 → bge-large-zh；中英混合 → bge-m3
- 一旦选定，迁移成本极高（换模型 = 全部数据重新向量化），选型要审慎
向量模型 vs Chat 模型
| 向量模型 | Chat 模型 | |
|---|---|---|
| 输入 | 一段文本 | 一段对话 |
| 输出 | 一组数字（向量） | 一段文字（回答） |
| 体积 | 轻量（几十MB~2GB） | 很重（几GB~几百GB） |
| 部署 | CPU 就够 | 通常需要 GPU |
| 在 RAG 中的角色 | 负责"找到相关资料" | 负责"基于资料写回答" |
五、切片策略
核心矛盾
- 切太小：搜索精准但丢失上下文
- 切太大：保留上下文但语义混杂、浪费 Token
四种策略
| 策略 | 原理 | 适用场景 |
|---|---|---|
| 固定长度 | 每 N 字切一段，相邻段重叠 | 快速原型、要求不高 |
| 按分隔符/章节 | 识别文档结构（标题、条款），在自然边界切 | 有清晰结构的文档（规章、手册、API文档） |
| 递归切片 | 先试大分隔符，太长再试小的，层层递归 | 混合类型文档，大多数企业场景 |
| 语义切片 | 用模型判断话题转折点，在转折处切 | 结构不规则的文档（会议纪要、随笔） |
切片参数
- 目标长度（如 300-500 字）
- 重叠长度（如 50-100 字，防止切断语义）
- 分隔符选择
- 切片长度不能超过向量模型的最大输入长度
实际定策略的方式
- 不是理论推导，是测出来的：选 2-3 种策略，准备测试问题，跑对比，选效果最好的
- 通常按知识库级别配置（同一知识库里文档类型相似，用同一套策略）
六、元数据（Metadata）
是什么
- 和向量一起存储的结构化描述信息
- 向量管"像不像"，元数据管"要不要"
一条完整记录的结构
id: 唯一标识
vector: [0.02, -0.03, ...] ← 语义搜索用
metadata: {source, department, author, date, ...} ← 过滤用
text: 原始文本内容 ← 展示用
元数据来源
- 个人场景：工具自动生成（文件名、切片序号）
- 企业场景：自动生成 + 业务元数据（部门、权限、文档类型等），来源于业务系统中已有的结构化信息
元数据更新
- 文档内容变了 → 向量和元数据都要更新（通常删旧存新）
- 只是元数据变了（如员工调部门）→ 只更新元数据，向量不用重算
七、搜索机制
相似度计算（数学层面）
| 方式 | 原理 | 适用 |
|---|---|---|
| 余弦相似度 | 比较方向是否一致 | 文本搜索（最常用） |
| 欧氏距离 | 比较空间直线距离 | 图像相似度 |
| 点积 | 方向×长度综合考虑 | 推荐系统 |
不管什么数据类型（文本/图片/音频），都是先变成向量，再用上面的函数计算。区别在向量化模型不同，不在计算方式。
元数据过滤 + 向量搜索的三种配合方式
| 策略 | 做法 | 特点 |
|---|---|---|
| Pre-filtering | 先按元数据筛，再在结果中向量搜索 | 快，但可能漏结果 |
| Post-filtering | 先向量搜索，再按元数据筛结果 | 不漏语义相关的，但可能结果太少 |
| Integrated | 搜索和过滤同时进行 | 效果最好，主流向量库默认方式 |
检索增强手段
- 切片策略优化：存的时候就决定了搜索上限
- 元数据过滤：缩小搜索范围
- 多路召回：向量搜索 + 关键词搜索（BM25），取并集
- Rerank 重排序：搜完后用专门模型重新打分排序，更精确但更慢
八、索引与性能
为什么需要索引
- 暴力搜索（逐条比对）在大数据量下不可行：100万条约需2秒，1000万条约20秒
- 索引的核心思路：先分区，再局部搜索（ANN - 近似最近邻）
- Approximate（近似）：不保证绝对最优，但足够相似，速度快几百倍
主流索引算法
| 算法 | 思路 | 特点 |
|---|---|---|
| IVF | 数据分成 N 个区，搜索时只去最可能的几个区 | 简单高效 |
| HNSW | 层层缩小范围（类似社交网络找人） | 精度最高，吃内存 |
| PQ | 压缩向量维度，牺牲精度换空间 | 数据量特别大时用 |
核心调参（以 HNSW 为例）
- ef_construction：建索引时的精度，值越大索引质量越高但建索引越慢
- ef_search：搜索时的精度，值越大结果越准但搜索越慢
- 平衡方式：先用默认参数，再根据准确率和性能测试结果调整
九、企业级设计要点
隔离策略
| 级别 | 做法 | 场景 |
|---|---|---|
| 物理隔离 | 不同的向量库实例 | 不同租户/子公司 |
| 应用隔离 | 不同的 Collection（集合） | 不同业务模块（HR vs 销售） |
| 数据隔离 | 同一集合内用元数据标记+查询时过滤 | 同一模块内不同用户权限 |
应用隔离的必要性（不只是安全）
- 搜索质量：不同业务语义互相干扰
- 索引效率：语义空间混杂，聚类质量下降
- 运维灵活性：独立操作，互不影响
多集合搜索
- 实现方式：分别搜索 → 合并结果 → 重新排序
- 路由判断：用户手动选 / 规则路由 / 大模型判断
- 关键约束：所有集合最好用同一个向量模型，否则相似度分数不可比较
数据源管理
- 企业数据源多样：OA、文档系统、邮件、数据库、外部数据
- 每种数据源需要对应的解析器
- 结构化数据（数据库记录）→ 先拼成自然语言再向量化
- 增量同步：企业数据每天在变，需要只处理新增和修改的数据
数据更新同步的触发方式
| 触发方式 | 怎么做 | 适合场景 |
|---|---|---|
| 手动触发 | 改完文档后自己调一下同步脚本 | 最简单，个人使用足够 |
| 文件监听 | 脚本监听目录的文件变更（如 Python watchdog），有变化自动调 API | 实时性好，需常驻后台进程 |
| 定时任务 | cron 定时扫描文件修改时间，变化的文件调 API 更新 | 简单可靠，如每天凌晨同步一次 |
| Git Hook | 笔记在 Git 仓库时，commit 触发同步 | 笔记用 Git 管理时很自然 |
| 平台内置 | 如 Dify 2.0 的知识管道（Knowledge Pipeline），支持多数据源自动采集 | 使用支持此功能的平台时 |
增量同步的核心逻辑：扫描数据源 → 比对文件修改时间或 hash → 变化的文件调更新 API → 新文件调创建 API。
企业产品需要管理的配置
- 数据源接入与解析
- 切片策略选择与参数配置（按知识库级别）
- 向量模型选择
- 元数据结构设计（权限、业务标签等）
- 检索增强策略（多路召回、Rerank 开关）
- 效果评估与持续优化
十、大模型记忆体系全景图
五种"记住东西"的方式
| 方式 | 知识存在哪 | 更新方式 | 成本 | 知识量上限 |
|---|---|---|---|---|
| Context Window | Prompt 里 | 随时换内容 | Token 消耗大 | 受窗口限制 |
| RAG | 外部向量库 | 更新向量库 | 中等 | 理论无限 |
| Fine-tuning | 模型参数里 | 重新训练 | 训练成本高 | 受模型容量限制 |
| Agent Memory | 外部存储 | 自动积累 | 中等 | 理论无限 |
| Knowledge Graph + LLM | 图数据库 | 更新图谱 | 构建成本高 | 理论无限 |
Context Window vs RAG
Context Window 越来越大（GPT-3 的 4K → Gemini 的 1M+），但不能完全取代 RAG：
- 数据量大（企业百万篇文档）→ 塞不进窗口，必须 RAG
- 需要精准溯源（回答标注来自哪个文件）→ RAG 才能做
- 成本敏感（每次只发相关片段 vs 每次发全文）→ RAG 更省
- 需要元数据过滤/权限控制 → Context Window 做不了
- 个人少量笔记、不需要溯源 → Context Window 够用
智能体长期记忆技术细分
| 记忆方式 | 原理 | 适合场景 | 典型例子 |
|---|---|---|---|
| 向量知识库（RAG） | 外挂知识，语义检索后注入上下文 | 大量文档/知识的查询 | Dify 知识库、自建 RAG 系统 |
| 对话历史持久化 | 把对话记录存数据库，下次对话时加载 | 连续多轮对话的延续 | ChatGPT 的历史记录 |
| 记忆摘要/压缩 | 用大模型把长对话压缩成摘要存储，下次加载摘要 | 长期对话不丢失关键信息 | MemGPT 的方案 |
| 结构化记忆（数据库/文件） | 提取关键信息存成结构化数据（JSON/数据库/文件） | 用户偏好、事实性记录 | Claude Code 的 MEMORY.md |
| 知识图谱（Graph RAG） | 把信息组织成实体-关系网络，支持多跳推理 | "张三的上级负责的项目"这种链式查询 | Neo4j + LLM |
| 参数化记忆（微调/LoRA） | 通过微调把知识写入模型权重 | 高频使用的领域知识内化 | 企业定制模型 |
| 超长上下文 | 直接把大量信息塞进上下文窗口 | 信息量可控时的"暴力"方案 | Gemini 的百万 token 上下文 |
实际趋势：组合使用
一个成熟的 AI 应用可能同时用多种方式：
- 简单问题 → Context Window
- 复杂问题 → RAG 检索后塞入 Context
- 跨对话偏好 → Agent Memory
- 企业结构化知识 → 知识图谱 + RAG
- 领域专业术语/风格 → Fine-tuning
什么数据值得向量化
- 高频检索 + 语义模糊的内容（用自然语言搜的）→ 值得向量化
- 低频访问的归档数据 → 不值得，浪费存储和计算
- 结构化且查询条件明确的数据 → 用传统数据库更合适
- 重复/过时/低质量的内容 → 先清洗再决定
- 敏感数据 → 需要评估安全风险后再决定
十一、非文本数据的 RAG 处理难点
各类数据格式的处理方式
| 数据类型 | 难点 | 处理方式 | 成本 |
|---|---|---|---|
| Markdown/纯文本 | 无 | 直接切片向量化 | 低 |
| 排版复杂、表格/图片混排 | PDF 解析器（marker、pdfplumber） | 中 | |
| PPT | 图文混排、布局信息 | 解包提取文字（PPT 本质是 zip 包），图表信息可能丢失 | 中 |
| 手写内容 | OCR 识别率不稳定 | 视觉模型（qwen-vl 等） | 中高 |
| 视频 | 同时有音频和画面 | 语音转文字（ASR）+ 截帧图像理解，画面信息易丢失 | 高 |
多模态处理的成本考虑
- 文本类数据：本地向量模型（如 bge-small，90M）即可，CPU 够用
- 图片/视频等多模态：需要视觉模型，本地跑吃配置，用 API 有成本
- 低成本视觉 API 选择：qwen-vl、gemini-flash 等
- 务实策略：先跑通文本 RAG，多模态数据后续再处理
十二、多路召回的实现层级
多路召回（关键词搜索 + 向量语义搜索）总要有人做，区别在于做在哪一层：
| 实现层级 | 怎么做 | 适合场景 |
|---|---|---|
| Agent 自主做 | Agent 分别调不同工具（如 Claude Code 内置 Grep + MCP 向量检索），自己综合结果 | 有 Agent 能力的客户端（Claude Code、Cursor） |
| MCP Server 内部做 | MCP 内部同时做关键词搜索和向量搜索，合并结果后返回 | 客户端没有内置文件搜索能力（如 Cherry Studio） |
| 平台配置做 | 平台直接提供混合检索选项（如 Dify 知识库节点选"混合检索"） | 使用支持此功能的平台 |
| 后端代码做 | 自建后端服务，代码中编排多路召回逻辑 | 给别人用的产品 |
越接近底层做，对上层客户端的要求越低。
十三、Agentic RAG（智能体驱动的检索）
普通 RAG vs Agentic RAG
普通 RAG 是单次检索：用户问题 → 向量化 → 检索 → 拼 Prompt → 生成回答。
Agentic RAG 加了一个循环：
用户问题
↓
查询改写（把模糊问题转成明确的检索查询）
↓
检索（向量搜索 + 关键词搜索）
↓
结果评估（大模型判断：检索到的信息够不够回答问题？）
↓ 不够 → 换角度改写查询，回到"检索"步骤（循环）
↓ 够了 → 基于所有收集到的片段生成回答
核心差异：有没有**"判断够不够 → 不够就换角度再检索"的循环**。
为什么需要 Agentic RAG
简单向量检索解决不了的场景：
- "上次跟客户聊的方案" → 需要理解"上次"指什么时间、"客户"是谁，拆解后检索
- "跟竞品比我们的优势" → 需要分别检索"竞品信息"和"我方产品信息"，多次检索后综合
- "最近三个月的项目进展" → 需要时间过滤 + 多次检索不同项目
共性特征：用户的问题不能直接当检索关键词用，需要先理解、拆解、改写。
实现方式（按场景）
| 实现方式 | Agentic 逻辑在哪 | 灵活性 | 开发成本 | 适合场景 |
|---|---|---|---|---|
| Agent 客户端（Claude Code） | Agent 自身（大模型自主循环） | 最高 | 零 | 个人使用 |
| 平台工作流（Dify） | 可视化编排（循环节点 + 条件分支） | 中等 | 低 | 需要可视化管理的团队 |
| MCP Server 内部 | MCP 厚封装（内部自己跑检索循环） | 中等 | 中 | 客户端能力弱时 |
| 后端代码 | 自己写循环逻辑 | 最高 | 高 | 开发产品 |
| Agent 框架（LangChain/LlamaIndex） | 框架封装好的组件 | 高 | 中 | 快速原型、中型项目 |
核心模块
不管在哪一层实现，Agentic RAG 都需要这几个模块：
| 模块 | 职责 | 实现方式 |
|---|---|---|
| 查询改写器 | 把模糊问题变成明确的检索查询 | LLM 调用（提示词工程） |
| 检索执行器 | 实际去向量库/关键词引擎搜 | API 调用 |
| 结果评估器 | 判断当前检索结果够不够 | LLM 调用 |
| 循环控制器 | 控制最多几轮、什么时候停 | 程序逻辑（max_rounds + 停止信号） |
| 最终生成器 | 基于所有收集到的信息生成回答 | LLM 调用 |
与多路召回实现层级的关系
和多路召回的逻辑一致：越往底层做，对上层客户端要求越低。Claude Code 天然支持 Agentic RAG 是因为它本身就是 Agent，会自主决定"搜一次不够再换个角度搜"。如果客户端不是 Agent（普通聊天框），Agentic 逻辑就得自己在封装层或后端实现。