1. 文档目的
本文面向 RAG 工程实践，系统说明以下四类技术的定位、关键原理、工程边界与匹配关系：
- 文本向量化
- 向量数据库
- 向量模型（Embedding Model）
- 本地大模型（Local LLM）
目标是回答两个核心问题：
- 这四者各自解决什么问题？
- 它们之间如何匹配，才能在质量、性能、成本上达到较优平衡？
2. 一句话分工
- 文本向量化：把文本转成可计算相似度的向量表达。
- 向量模型：决定向量表达的语义质量。
- 向量数据库：高效存储与检索向量，并支持过滤、索引、版本管理。
- 本地大模型：基于检索到的证据进行理解、组织和生成。
可记为：
- 召回质量由向量化链路主导。
- 答案表达由本地大模型主导。
- 系统稳定性与规模能力由向量数据库与服务编排主导。
3. 端到端技术链路
典型 RAG 查询链路：
- 离线入库
- 文档解析与切分（chunk）
- 向量模型生成 embedding
- 写入向量数据库（附 metadata、ACL、版本信息）
- 在线查询
- Query 向量化
- 向量检索（TopK）+ 关键词/BM25/规则召回
- 权限过滤与重排
- 证据组装后交给本地大模型生成答案
- 返回答案与引用
4. 文本向量化技术
4.1 本质
文本向量化是从符号空间（词、句、段）映射到连续向量空间。该空间允许通过距离函数衡量语义相近度。
常见相似度：
- 余弦相似度：cos(θ)=a⋅b∥a∥∥b∥cos(θ)=∥a∥∥b∥a⋅b
- 点积
- 欧氏距离（常用于特定索引/归一化场景）
4.2 常见实现类型
- 稀疏表示：TF-IDF、BM25（不属于 dense embedding，但常用于混合检索）
- 稠密表示：sentence-transformers、bge、e5、gte 等
- 哈希向量：成本低、效果一般，适合最小可运行基线
4.3 工程关键点
- 切分质量通常比模型更早成为瓶颈。
- 向量归一化策略会影响相似度计算一致性。
- 多语言场景需关注跨语言语义对齐。
5. 向量数据库技术
5.1 作用
向量数据库并不负责"理解文本"，其核心职责是：
- 高维向量存储
- 近似最近邻检索（ANN）
- 与 metadata 过滤结合
- 多租户、权限、审计、版本切换支持
5.2 常见能力
- 索引结构：HNSW、IVF、PQ、Flat
- 检索模式：纯向量、混合检索、过滤后检索
- 运维能力：分片、副本、冷热分层、备份恢复
5.3 典型选型
- PGVector：生态通用、上手快、事务能力强，适合中小规模和业务系统一体化
- Milvus/Weaviate/OpenSearch Vector：更偏大规模检索能力与专用向量场景
6. 向量模型（Embedding Model）
6.1 模型决定什么
向量模型本质决定"什么文本会被认为相近"。 这直接影响召回 TopK 的可用证据质量。
6.2 选型维度
- 语言覆盖：中文、英文、跨语言
- 领域适配：通用语料 vs 企业垂直语料
- 向量维度与延迟
- 推理吞吐与硬件需求
- 许可协议与离线部署可行性
6.3 常见误区
- 只追求大模型 embedding，不看吞吐与成本
- 不做领域评测，凭直觉选型
- 忽略 chunk 策略导致召回退化
7. 本地大模型（Local LLM）
7.1 角色
本地大模型主要负责：
- 读取检索证据
- 进行推理与组织表达
- 执行拒答与风格控制
它不替代检索，不能自动弥补证据缺失。
7.2 本地化价值
- 数据可控与合规优势
- 成本可预测
- 可做定制化部署（内网、离线、边缘）
7.3 本地化挑战
- 模型服务可用性与资源占用
- 延迟与吞吐压力
- 推理优化（量化、批处理、缓存）
8. 四者之间的"匹配关系"
8.1 不是强耦合，而是协同匹配
- 不要求 embedding 与 LLM 同厂同系列。
- 但需要语义分布、语言能力、领域词汇上具备协同性。
可理解为：
- 向量模型负责"找对证据"。
- 本地大模型负责"用好证据"。
8.2 关键匹配维度
- 语言匹配
- 中文问答建议选中文或多语言优化 embedding。
- LLM 也应具备稳定中文理解生成能力。
- 领域匹配
- 若是制度、法务、运维、代码等专域，embedding 需覆盖该术语分布。
- LLM 需能处理长术语链与规范表达。
- 粒度匹配
- chunk 太小会语义断裂，太大超出上下文预算。
- embedding 与 LLM 的最佳 chunk 粒度可能不同，需实验确定。
- 检索策略匹配
- 仅向量检索通常不够稳，建议向量 + BM25 + metadata 过滤。
- LLM 输入上下文应包含高置信、可追溯引用。
- 性能预算匹配
- embedding 速度、向量检索延迟、LLM 生成延迟共同决定端到端 SLA。
8.3 常见不匹配症状
- 召回看似相关，但生成答案偏题：通常是语义空间和领域词汇不匹配。
- 明明有证据却拒答：可能是检索排序与上下文组装策略不当。
- 答案流畅但引用弱：通常是生成强、检索弱。
8.4 向量数据库与向量模型匹配示例
- 中文企业知识库，中等规模（百万级以内）
- 组合：中文/多语言 embedding（如 bge-m3 或同类）+ PGVector
- 匹配原因：中文语义效果较稳，且 PGVector 过滤、事务、SQL 生态友好，接入企业业务库成本低。
- 风险：超大规模扩展和极限并发能力通常不如专用向量引擎。
- 超大规模检索（千万到亿级向量）
- 组合：高质量 dense embedding + Milvus/Weaviate
- 匹配原因：ANN 索引、分片扩展、检索吞吐能力更强，适配高维向量和大规模在线召回。
- 风险：运维复杂度与资源成本提升，事务一致性需要单独设计。
- 关键词与语义并重场景（电商、FAQ、制度检索）
- 组合：通用 embedding + OpenSearch Vector（向量 + BM25）
- 匹配原因：语义召回与关键词精确命中可融合，模型名、条款号、术语等检索更稳。
- 风险：融合打分策略不当会出现排序互相干扰，需要离线评测持续调参。
- 内网低成本 PoC
- 组合：轻量 embedding（或哈希基线）+ SQLite/PGVector 小规模部署
- 匹配原因：部署简单、上线快，适合先验证权限、引用、审计闭环。
- 风险：语义质量和可扩展性有限，后续需规划平滑迁移。
8.5 如何判断"是否匹配"
- 检索指标
- Recall@K、MRR、NDCG@10 是否达到目标。
- 业务指标
- 引用命中率、拒答正确率、人工评审正确率是否提升。
- 系统指标
- P95 延迟、吞吐、成本是否在预算内。
- 变更稳定性
- 更换 embedding 或向量库后，核心场景是否出现可感知退化。
9. 推荐工程模式
9.1 最小可用模式（MVP）
- embedding：轻量模型或基线哈希
- 检索：向量 + 关键词混合
- 生成：模板摘要或轻量本地 LLM
- 目标：先打通闭环与审计
9.2 生产增强模式
- embedding：中文/多语言高质量模型
- 检索：混合召回 + 重排 + 权限前置过滤
- 生成：本地 LLM + 提示模板版本化 + 拒答策略
- 目标：质量、合规、可运维三者平衡
10. 如何验证"匹配是否足够好"
建议建立分层评测：
- 检索层
- Recall@K、MRR、NDCG@K
- 生成层
- 引用命中率、拒答正确率、人工评分
- 系统层
- P95/P99 延迟、吞吐、单次请求成本、可用性
- 安全层
- 越权拦截率、敏感信息泄露率、审计可回放率
评测原则：
- 固定 LLM 比 embedding
- 固定 embedding 比 LLM
- 用同一批黄金集做 A/B
11. 选型决策建议（面向企业项目）
- 先定义业务目标
- 质量优先、成本优先、时延优先三者权重不同，选型不同。
- 先做小规模 PoC，不直接全量迁移
- 使用代表性语料和真实问题集。
- 保持可插拔
- embedding、向量库、LLM 分层解耦，避免供应商锁定。
- 强制门禁
- 权限前置过滤
- 无证据不回答
- 事件与审计可回放
- 回归测试自动化
12. 落地检查清单
- 是否有清晰的 chunk 策略并可配置？
- 是否支持混合检索而非纯向量？
- 是否有可追溯引用链路？
- 是否定义并验证拒答策略？
- 是否建立检索/生成/系统三层指标？
- 是否具备灰度、回滚与版本切换机制？
13. 总结
文本向量化、向量数据库、向量模型、本地大模型并非替代关系，而是分工协同关系。
在企业 RAG 中，最佳实践通常是：
- 用高质量向量化与混合检索保证证据质量；
- 用本地大模型提升答案组织与交互体验；
- 用治理与门禁机制保障安全、合规与可持续迭代。