检索增强生成（RAG）

一、主流向量数据库

排名	数据库	核心逻辑	最佳场景	关键优势
1	Pinecone 「我只想写业务，不想管数据库」	Serverless（无服务器）的代名词。	例如 DreamLog 要快速上线，又不想在 Linux 上配 Docker、调内存、管磁盘。	像用 Stripe 一样简单：调 API 就能存取向量。
2	pgvector（Postgres）「我有现成数据库，不想乱加新东西」	已在用 PostgreSQL 存用户与文本时，只需加一个扩展。	文本数据与向量要强一致（ACID 事务）时。	几乎零额外学习成本；不必新学查询语言，SQL 仍够用。
3	MongoDB Atlas Vector Search 「我习惯文档格式，别让我大改 Schema」	针对 JSON 等非结构化数据的深度集成。	数据很杂、字段常改，且你已是 MongoDB 老用户。	同一查询里既能做语义搜（如「梦里有蛇」），又能按作者性别等过滤，体验顺滑。
4	Weaviate 「我要 AI 自己理解数据之间的逻辑关系」	语义优先，而不只是「算个相似度」。	要做知识图谱：例如梦里「水」与「母亲」在心理学上的关联。	自带不少模块（如自动分词、自动向量化），对 AI 开发者友好。
5	Qdrant 「我是性能怪兽，还要极速过滤」	Rust 实现，效率极高。	几千万条量级，且要极复杂的条件过滤（如：加州、2026 年、关于飞行的梦）。	Payload（负载元数据）过滤极强，延迟极低。
6	Chroma 「我只想本地跑 Demo，不想先折腾云端」	极简、轻量。	个人笔记本上的小项目，或做原型验证。	几行代码就能跑起来；本地版可免费起步。
7	Zilliz Cloud / Milvus 「我有十亿级数据，别的库扛不住」	分布式架构取向，面向超大规模。	全球级应用：例如要覆盖全美用户、向量规模到 Billion（十亿）级。	工业级稳定性，支持多种复杂索引与检索策略。

二、普通RAG

1) RAG 核心原理：

LLM 的局限：

知识截止：训练数据静态，难以及时覆盖最新事实。
幻觉：参数化「记忆」不可靠。
上下文长度：即便长上下文模型，也无法塞下整个企业知识库。

RAG 在做什么：生成前先从外部知识库取出与问题相关的上下文，把「上下文 + 用户查询」一起交给 LLM，形成检索 → 增强 → 生成的闭环。

为什么需要向量数据库？传统关系型数据库与文档数据库主要面向结构化数据与精确匹配；向量数据库则面向非结构化内容下的模糊语义相似检索

1. 精确匹配 vs. 语义相似度

2. 检索效率与算法

传统数据库：广泛使用 B+ 树等索引支撑点查、范围与条件过滤

向量数据库：核心是 ANN（近似最近邻），例如 HNSW、IVF 等

2) RAG 全生命周期架构

A. 数据处理

清洗：去 HTML 标签、噪声、格式统一等。

分块：

切分方式直接决定召回粒度与上下文是否完整，工程上常从规则 → 结构启发 → 语义逐级加码。

1. 基础物理分块：

做法：固定长度如每块约 500 token（可按模型与成本调整）；块与块之间设 重叠窗口（Overlap），常见约 10%～20%，减轻长句被拦腰切断。
优点：实现简单，几乎无额外算力。
缺点：仍可能在句中切开，造成语义丢失。

2. 增强型启发式分块：

标题 / 段落分块：按文档逻辑结构下刀，例如 HTML 的 <h1>、<p>，或 Markdown 的 ## 等。
父子索引（Parent-Document）：先用很小子块（如约 100 token）做向量检索以提高匹配精度；命中后通过 ID 取对应父块（如约 1000 token）再送给 LLM，兼顾「检得准」与「上下文够长」。

3. 语义分块

与只管字数或字符的物理切分不同，语义分块先把全文落到句子级，再把每句映射进向量空间，用相邻句之间的语义距离判断「是否换话题」，在转折处切块。

（1）拆解：从句子到向量

动作：将整篇文档拆成一条条独立句子（而非直接在原始字符流上滑窗）。
目的：句子通常是表达相对完整意思的最小常用单元，以此为颗粒度再算相似度，比任意字符边界更符合「话题」的直觉。

（2）核心：语义空间里的「距离」

嵌入：每个句子经模型变成一组数（嵌入向量 / Embedding），落在同一语义空间里。
计算：对相邻句对计算相似度；工程上极常用余弦相似度（或与之一致的距离度量），度量两句在方向上的接近程度。
逻辑：若两句仍在同一话题上，向量往往彼此靠近；若叙述突然转向另一话题，对应距离（或 1−相似度）会明显拉大，这一步是整个方法的枢纽。

（3）决策：「断裂」阈值

阈值（Threshold）：事先设定一个断裂标准（相似度低于某值，或距离高于某值，依实现而定）。
过程：按文档顺序遍历相邻句对；一旦相邻句的度量跨过了阈值，即判定「这里话题断了」，并在该位置切开，结束当前 Chunk、开始下一块。

优点：块内主题更一致，减少「半句话两个主题」的碎片。
缺点：需对大量句子跑 Embedding 并两两（沿序）比较，算力与延迟显著高于纯规则切分；阈值与语种、领域强相关，需调参；常与规则 / 启发式组合以控成本。

4. 结构化预切分 + 内部语义细分

思路：当前最主流的组合之一——先用规则或启发式识别文档天然边界（Markdown 的 # 标题、PDF 章节、HTML 区块等）。
做法：先按章节切成较大的「基础块」，再在每个章节内部做语义分块。
优势：避免语义边界跨过章节（例如把「第一章总结」和「第二章开头」硬拼成一块）；相比全文纯语义切分，计算量更可控。

5. 固定窗口 + 语义检查

做法：以约 500 token 的滑动窗口作为物理基准。
语义介入：窗口推进时不立刻切断，而检查窗口末尾若干句的相似度；若仍很高，说明意群未完，可动态拉长窗口，直到出现清晰语义断点。
优势：在遵守长度上限的前提下，尽量保证每个 Chunk 语义完整。

6. 语义重心 + 物理上下文覆盖

场景：复杂长报告、多小节并列时。
做法：用语义分块标出话题转折点，作为「语义重心」。
规则介入：在重心前后用启发式补齐可读上下文（一旦确定语义重心，自动向后取 3 句话，向前取至当前段落的开头），并通过元数据路径注入把所属文档标题、章节、页码等写入元数据，供过滤或与正文一并送入 LLM。

7. 元数据路径注入（缓解指代不明）

问题：长文档里单独切出「它的额定功率为 100W。」时，模型不知道「它」指哪款产品。
标题树：分块前用解析工具（如 Unstructured）或正则遍历文档，构建目录 / 标题层级。
路径挂载：让每个 Chunk 带结构化前缀，例如原始为「它的额定功率为 100W。」，注入后为「[产品手册 › 户外电源 › Pro 系列] 它的额定功率为 100W。」
效果：即使片段很短，嵌入也能带上品类 / 章节语义，生成阶段也易还原指代。

8. 多级索引

分块：子块约 100～200 token，父块约 1000 token（量级可按业务调）。
索引：向量库里通常只给子块建索引；子块元数据记录所属父块 ID。
检索：查询命中 Top-K 子块后，不按子块直接答，而是按 ID 从 KV / 关系库取出完整父块再交给 LLM。
优势：小块提高向量匹配精度，大块保证上下文连贯

9. 千万级规模下的性能与成本

采样策略：不必全库做重语义切分；规则切分打底，仅对检索热点或结构特别复杂的文档启用高成本语义流程。
Embedding 缓存：文本哈希 → 向量，内容未变则不重复调用嵌入接口。
混合精度：用小模型做初判或粗分，仅在确需细切时再调用更大嵌入 / 模型。

B. 向量化与索引

1. 向量化

模型与架构：基于 Transformer / BERT 类编码器的向量模型如OpenAI text-embedding-3 等。输入一段文本，输出固定长度的稠密向量。

2. 索引与 ANN

规模到数百万乃至上亿向量时，对每条候选逐一算距离（暴力搜索）延迟过高。向量数据库用 ANN（近似最近邻）在「延迟、召回率、内存、更新成本」之间折中。

索引类型	核心原理	适用场景
Flat	与库中每条向量计算距离，无近似，结果精确。	数据量极小（如 < 1 万量级）、基准评测，或作为子步骤中的精确重算。
IVF	用聚类把空间划成多个「簇」，检索时先找最近的若干簇，再在簇内搜。	希望在内存、速度、召回之间平衡；常与 PQ 组合；候选簇过少时召回可能掉。
HNSW	多层图：上层边稀疏、步长大，类似跳表式「远跳」逼近目标区域；下层渐密，局部精搜。	生产级高并发、低延迟检索的主流方案之一；极度依赖内存，更新与删除策略需单独设计（见下节）。
PQ	将向量分段，各段用码本编码，用近似距离代替精确距离，显著省存储。	向量数亿级、内存极贵时；通常以轻微精度损失换空间，常与 IVF / 其他结构组合。

向量数据库不仅是某一种 ANN 实现，而是持久化、副本、元数据与过滤、资源隔离、监控与扩缩容等组成的检索与存储系统；

3. 生产痛点一：

图与连通性：HNSW 依赖小世界网络式的连通结构；检索从入口点在高层走向查询附近，再下沉细化。中间节点若被不当移除，可能出现逻辑孤岛或导航质量下降。
插入：一般支持在线插入：新点通过寻邻建边接入多层图。
删除的难点：物理删除中间节点可能破坏图的可达性；全图频繁重写成本又高。
软删除：标记删除，检索结果中过滤；索引结构仍占空间且点仍可能参与部分导航，需配合合并策略。
定期重构：当软删除或碎片比例达阈值（例如约 20%）时，在后台构建新索引，完成后原子切换，平衡空间与图质量。

4. 生产痛点二：

方案 A：所有租户向量共存在一个大索引里，检索时带 WHERE tenant_id = 'A' 等条件。优点：空间利用率高、扩租户只增数据不改拓扑；对小规模，先向量搜出较大候选集再按租户过滤。
方案 B：每租户或大客户独立索引。优点：安全与配额边界最清晰。缺点：索引元数据、句柄与每索引固定开销叠加，海量小索引会拖慢启动与调度，且 HNSW 在小数据量上「吃不饱」、性价比差。
预过滤：先限定在符合元数据的子集上再做 ANN。子集很大时往往高效；若单租户在全局中极稀疏，在 HNSW 上从入口点出发时，大量邻居被条件挡掉，难以沿图跳跃，可能退化为低效扫描或召回变差。
后过滤：先取全局 Top-K（如 100），再按租户筛。风险：若这 100 条都不属于该租户，则结果为空，需增大 K、动态扩候选或使用两阶段策略。

5. 生产痛点三：

热数据：索引结构 + 向量尽量常驻 RAM
温数据：图或导航结构在内存，原始向量在 SSD：先在内存中走近似索引定位候选 ID，再按需从盘读向量算精确距离。
冷数据：全量或大部在对象存储，适合低频、离线或合规归档；在线检索延迟可到秒级，一般不作为交互式 RAG 主路径。

6. 典型场景：

为何不优先每租户一索引：内存上，大量 HNSW实例的元数据与图开销累加会很快吃满资源；运维上，万级 Collection 对协调节点、冷启动与扩容都是负担；算法层面，每户几十条难以发挥多层图的优势。

为何倾向元数据过滤 + 共享大索引：单索引维护成本低、扩租户只写带 tenant_id 的行即可；过滤与重排可在应用或数据库层完成。

强预过滤 + 全局 HNSW 的坑：某租户的向量在全局语义空间中可能彼此并不邻接，图上属于该租户的点之间未必有有效连边；检索时层层「跳跃」若总落在不符合条件的邻居上，易出现路由断裂感。

C. 检索与增强

1. 混合检索

混合检索同时利用两类信号，互为补充：

关键词检索：字词索引，擅长专名、缩写、型号、错误码等需要字面一致或高度可区分的场景。
向量检索：关注语义相似。

工程痛点：语义漂移：向量检索很强，但有时会把看起来像的条目排在真相关之前。例如搜特定错误码 ERR_502 时，嵌入可能因与 ERR_504 在训练语义上相近而把后者提前。此类场景下关键词侧的精确命中往往能把正确块拉回视野；混合后通常再经加权融合或重排定序。

2. 查询变换

用户原始问题常过短、含糊或有歧义。可用 LLM 先把问题「重塑」再检索，提高召回与稳定性。

A. Multi-Query

做法：让 LLM 将用户问题改写成若干条（常见 3～5 条）同义但侧重点不同的子查询。
原理：同一意图的不同表述在向量空间中位置略有差异；多路检索能从不同方向捞取候选，再合并、去重，降低「单一问法漏召回」的概率。

B. HyDE

做法：（1）先让 LLM 针对用户问题生成一段假设性答案/伪文档（允许不完全正确，作检索锚点即可）；（2）用该伪答案的嵌入去向量库检索，而不是仅用原始问题的嵌入。
原理：在常见嵌入空间里，「答案式表述」与真实文档块的距离往往比「简短问题」与文档块更近；用伪答案作中介，有时能更稳地对齐知识库中的陈述型段落。

D. 粗排与后处理

在 RAG 链路里，向量检索常被称为粗排：目标是在海量 Chunk 中以毫秒级先捞出一批最相关的候选，而不是对全库做线性翻阅。

1. 向量化与索引

向量化：各文档块经 Embedding 模型变成固定维度的浮点向量（「坐标」）。
索引：在向量上建立 ANN 结构（如 HNSW、IVF 等）
加载：为追求延迟，索引与向量常常驻 RAM；超大规模时再配合量化、磁盘索引等。

2. 查询向量化

3. 近似最近邻搜索

数据量巨大时，一般不采用全库暴力比对作主路径，而用 ANN 在精度与速度间折中。
以 HNSW 为例：多层图上由疏到密「跳跃—收敛」，快速把搜索范围缩到查询附近的邻域，再细化。

4. 距离打分与 Top-K 召回

在 ANN 给出的候选邻域内，计算查询向量与各候选的相似度 / 距离，按得分排序。
输出：取前 K 个块（如 K = 50、100）进入后续环节。

补：距离度量怎么选（几何长度 vs. 语义方向）

欧氏距离（L2）：两点直线距离，对向量模长敏感。篇幅/能量尺度差较大的两段文字，即使语义相近，L2 也可能偏大。
余弦相似度：只看夹角、弱化长度；语义方向一致的长短文本仍可被判为相近，因此 RAG 中极为常用。
内积：若业务刻意保留「越长越强」的强度信号且模型按内积训练，可选用；否则多与归一化 + 余弦同用。

补：HNSW 为何能「快」

小世界：图中多数点可通过少量「远程边」在很少步内到达远端邻域，适合先做大跨步定位。
层级：类比跳表：顶层极稀疏，越往下点与边越全；检索自顶向下：先长途跳跃逼近区域，再层层加密精炼。
复杂度直觉：分层使绝大多数无关区域根本不会被细致展开，实践中常表现为近对数级的扩展规律。

补：量化

亿级规模时内存往往是瓶颈，乘积量化（PQ）用精度换空间：将高维向量切段，每段用聚类码本标成短码。

后处理

1. 重排序（Reranking）

动机：粗排可能返回数十～上百条片段，但上下文窗口有限；且存在 Lost in the Middle 现象——模型对开头与结尾更敏感，中间内容易被弱化，因此「谁排第几」直接影响最终回答质量。
Bi-Encoder vs Cross-Encoder：向量检索（Bi-Encoder）对问题与文档分别编码再比相似度，快但交互弱。Cross-Encoder把 [问题 + 粗排的单个文档块]拼在一起输入模型，用注意力联合编码，得到更贴合语义的相关性分数。

2. 上下文压缩

问题：单块 Chunk 常为 512～1024 token 量级，其中往往只有一两句高度切题；整段塞进 LLM 会费钱、占位、冲散注意力。
做法 A：摘要式压缩：用小模型对块内句子/段落做相关性扫描，删或折叠与当前问题无关的句子。
做法 B：嵌入过滤器：把块拆句，逐句与问题算嵌入相似度，只保留超过阈值的句子（或 Top-n 句），再拼回片段。

3. Prompt 注入

元数据并入：在正文中或段落前缀附上来源（如「《XX 手册》第 5 章、第 12 页」），便于模型引用与可解释性，增强可信溯源与用户侧核对。
排列顺序：精排后把最高分片段放到最前或最后，以缓解 Lost in the Middle；中间放次要材料或更短的摘要。

三、GraphRAG

GraphRAG 到底是什么？

它是一组利用图结构进行检索的 RAG 模式——不是一种单一算法，而是一族做法；每种模式往往依赖与之匹配的数据结构或图模式才能稳定发挥效果。

知识图谱：

知识图谱特别适合表达既有结构化又有非结构化、且元素之间相互勾连的数据，更可伸缩，便于承载现实世界里盘根错节的信息。

在 RAG 链路中，知识图谱常常扮演 LLM 能力的外挂记忆：总结、翻译、抽取等语言任务产出的结构化结果可以写回图中，检索阶段再按关系与模式取出来，与纯向量片段形成互补。

在图里，事实与实体建模为带属性的节点；节点之间由带类型、常带约束或限定语属性的关系边连接。这样的模型可以很轻（例如小型家谱），也可以很重（公司级数字孪生：员工、客户、流程、产品、伙伴、资源等，动辄百万、十亿级关系）。

图模式里常见的实体

领域实体：代表你应用所关心的对象、概念或业务对象。
领域关系：实体之间带类型与语义的连接（供应、属于、提及、因果等）。
文档节点：表示被摄入图中的非结构化文档整体（文件、网页、工单正文等）。
分块节点：由文档切分得到的文本片段节点，是多数 GraphRAG 管线里和向量检索直接对接的一层。

其中分块节点几乎是各类 GraphRAG 的公共地基，通常至少带有两类属性：文本（人类可读的分块字符串）与嵌入（该文本经嵌入模型得到的向量），供相似检索与下游生成共同使用。