RAG · 林煜轩

RAG 之前的知识库检索关键技术

在 RAG 兴起之前，信息检索（Information Retrieval）领域已经积累了几十年的技术。理解这些基础对于设计好的 RAG 系统至关重要。

一、稀疏检索（Sparse Retrieval）

核心思想：用词频统计来表示文档和查询，生成高维稀疏向量（大部分维度为 0）。

1. TF-IDF（Term Frequency - Inverse Document Frequency）

最早的经典方法，两个因子相乘：

TF（词频）：一个词在当前文档中出现的频率越高，越可能与该文档相关。常用 sublinear 处理： $TF = 1 + \log(f_{t,d})$ ，防止高频词权重爆炸。
IDF（逆文档频率）：一个词在越少的文档中出现，区分度越高。 $IDF = \log\frac{N}{df_t}$ ，其中 N 是总文档数， $df_t$ 是包含该词的文档数。"the" 这种词 IDF 接近 0，"vLLM" 这种词 IDF 很高。
最终权重： $w = TF \times IDF$ ，查询和文档都表示成这样的向量后，用 cosine similarity 算相关性。

局限：纯粹基于词面匹配，"automobile" 和 "car" 被视为完全不同的词。

2. BM25（Best Matching 25）

TF-IDF 的改进版，目前仍是稀疏检索的事实标准。

核心公式：

BM25(q, d) = \sum_{t \in q} IDF(t) \cdot \frac{f_{t,d} \cdot (k_1 + 1)}{f_{t,d} + k_1 \cdot (1 - b + b \cdot \frac{|d|}{avgdl})}

相比 TF-IDF 的三个关键改进：

TF 饱和：引入参数 $k_1$ （通常 1.2-2.0），使 TF 的增长有上限。一个词出现 100 次不会比出现 10 次得分高很多，避免了长文档中高频词的过度主导。
文档长度归一化：参数 $b$ （通常 0.75）控制长度惩罚的程度。长文档天然包含更多词汇， $b$ 防止长文档不公平地获得高分。 $avgdl$ 是平均文档长度。
IDF 平滑：使用改进的 IDF 公式，处理极端情况更稳健。

为什么至今仍在用：

不需要训练，开箱即用
精确的关键词匹配能力强（专有名词、型号、ID 等）
计算资源消耗低
用 inverted index 可以做到毫秒级检索
Elasticsearch、Lucene 等成熟工业系统都基于 BM25

二、倒排索引（Inverted Index）

BM25/TF-IDF 之所以能在海量文档中快速检索，靠的就是倒排索引这个数据结构。

原理：正排索引是"文档 → 包含哪些词"，倒排索引反过来——"词 → 出现在哪些文档中"。

正排：doc1 → ["cat", "sat", "mat"]
      doc2 → ["dog", "sat", "sofa"]

倒排：cat  → [doc1]
      sat  → [doc1, doc2]
      mat  → [doc1]
      dog  → [doc2]
      sofa → [doc2]

每个词对应一个 posting list，记录包含该词的文档 ID、词频、位置等
查询时只需找到查询词的 posting list，取交集/并集，再用 BM25 打分排序
时间复杂度和查询词涉及的文档数成正比，而不是和全部文档数成正比

工业实现：Elasticsearch 和 Apache Solr 底层都是 Lucene 的倒排索引。

三、稀疏检索的局限 → 引出稠密检索

稀疏检索的根本问题是 vocabulary mismatch：

用户搜 "如何缓解头疼" ，文档写的是 "偏头痛的治疗方法"——关键词不匹配，BM25 检索不到
同义词、上下位词、隐含关系都无法捕捉

早期的缓解方案包括 query expansion（自动扩展同义词）和 LSA/LDA（降维捕捉主题），但效果有限。

四、稠密检索（Dense Retrieval）

核心思想：用神经网络把文本编码成低维稠密向量（如 768 维），在语义空间中用向量距离衡量相关性。

Embedding 模型

Sentence-BERT（2019）：用 Siamese BERT 架构，把句子编码为固定长度向量，训练目标是语义相似的句子距离近
后续发展：E5、BGE、GTE、OpenAI Embedding、Cohere Embed 等，效果不断提升
训练方式：对比学习（contrastive learning），用 (query, positive_doc, negative_doc) 三元组训练

距离度量

Cosine Similarity： $\cos(\theta) = \frac{a \cdot b}{|a||b|}$ ，最常用，对向量模长不敏感
点积（Dot Product）：在向量已归一化时等价于 cosine
L2 / 欧氏距离：适合某些特定场景

优势

语义匹配："automobile" 和 "car" 的 embedding 会很接近
跨语言能力：多语言 embedding 模型可以用英文 query 检索中文文档

局限

精确匹配反而不擅长：搜型号 "RTX-4090"，稠密检索可能返回 "RTX-3080" 的文档
需要训练数据和 GPU 资源
向量需要预先计算和存储

五、ANN（Approximate Nearest Neighbor）

稠密检索面临一个工程问题：文档库有百万甚至上亿条向量，逐条算距离（暴力搜索）太慢。ANN 用近似算法在可接受的精度损失下大幅提速。

主流算法

1. HNSW（Hierarchical Navigable Small World）

构建多层图结构，上层稀疏用于快速定位大致区域，下层稠密用于精确搜索
类比：先看全国地图定位到哪个省，再看省地图定位到哪个市，最后街道级精确查找
性能：查询速度极快，recall 高（通常 >95%）
代价：内存占用大，需要把整个图放内存；构建索引较慢
适用：中等规模（百万到千万级），对延迟要求高

2. IVF（Inverted File Index）

先用 k-means 把所有向量聚成若干类（如 1024 个 cluster）
查询时先找最近的 $nprobe$ 个 cluster，只在这些 cluster 内做精确搜索
性能：通过控制 nprobe 调节速度-精度权衡
代价：需要训练聚类中心
适用：大规模数据集

3. PQ（Product Quantization）

把高维向量切成若干子段，每段独立做聚类量化，用聚类 ID 替代原始值
768 维 float32 向量（3072 bytes）→ 压缩到几十个 bytes
核心价值：大幅降低内存和存储开销
常与 IVF 组合使用：IVFPQ 是大规模场景的标配

4. LSH（Locality-Sensitive Hashing）

设计哈希函数使得相似向量大概率落入同一个 bucket
理论上优美，但实际性能通常不如 HNSW 和 IVF
在高维场景下 recall 下降较快

性能权衡

算法	查询速度	内存占用	Recall	适用规模
HNSW	极快	高	极高	百万~千万
IVF	快（可调）	中	高（可调）	千万~亿
PQ	快	极低	中等	亿级（内存受限）
LSH	中等	中	中等	通用

主流向量数据库

Faiss（Meta）：底层库，支持上述所有算法，C++ 实现 + Python 接口
Milvus：分布式向量数据库，生产级
Pinecone：托管服务，开箱即用
Weaviate / Qdrant / Chroma：各有侧重

六、Hybrid Search（混合检索）

现代 RAG 系统通常不会只用一种，而是结合稀疏和稠密：

最终分数 = α × BM25_score + (1-α) × Dense_score

BM25 负责精确关键词匹配（型号、人名、专有术语）
Dense 负责语义理解（同义词、隐含关系）
两者互补，效果通常优于任何单一方法

实现方式：Elasticsearch 8.x 原生支持 kNN + BM25 混合；也可以分别检索后做 Reciprocal Rank Fusion (RRF) 合并排序。

七、知识图谱（Knowledge Graph）

在向量检索之外，知识图谱是另一种知识组织方式：

用三元组 (entity, relation, entity) 结构化存储知识
支持多跳推理："A 的导师是 B → B 所在学校是 C → C 在哪个城市"
适合需要精确关系查询和逻辑推理的场景
局限：构建和维护成本高，覆盖范围有限

GraphRAG 是近期的趋势，把知识图谱和 RAG 结合，用图结构增强检索的结构化推理能力。

八、技术演进脉络

TF-IDF → BM25 → 稀疏检索成熟
              ↘
               Embedding 模型 → Dense Retrieval → ANN 加速
              ↘
               Hybrid Search（BM25 + Dense）→ 现代 RAG 的检索层

知识库系统建设与 RAG 全面解析

一、RAG 是什么

Retrieval-Augmented Generation：在 LLM 生成回答之前，先从外部知识库中检索相关信息，把检索结果作为上下文注入 prompt，让模型基于这些"证据"来生成回答。

解决的核心问题：

LLM 的知识有截止日期，无法回答训练数据之后的问题
LLM 会幻觉，编造看似合理但错误的信息
企业私有知识不在 LLM 训练数据中
相比微调，RAG 成本低、可实时更新

二、RAG 完整流程

离线阶段（Indexing Pipeline）

原始文档 → 文档解析 → 分片(Chunking) → Embedding → 存入向量数据库

在线阶段（Query Pipeline）

用户问题 → Query 处理 → 检索(Retrieval) → Rerank → 构造 Prompt → LLM 生成 → 后处理

下面逐个环节展开：

三、文档解析（Document Parsing）

不同格式的文档需要不同的解析策略：

PDF：最复杂，可能包含文字、表格、图片、扫描件。工具如 PyMuPDF、pdfplumber 处理文字型 PDF；OCR（Tesseract、PaddleOCR）处理扫描件；多模态模型直接理解版面布局是新趋势
Word/HTML/Markdown：相对结构化，保留标题层级信息很重要
表格：需要特殊处理，直接拍平成文本会丢失结构信息，可以转成 Markdown 表格或单独存储

四、分片策略（Chunking）——面试高频考点

分片质量直接决定检索质量。分片太大，噪声多、embedding 被稀释；分片太小，语义不完整、缺乏上下文。

常见策略

1. 固定长度分片（Fixed-size Chunking）

按 token 数切割（如 512 tokens），加 overlap（如 50-100 tokens）防止语义被截断
优点：实现简单
缺点：会从语义中间截断，比如把一个完整的论点切成两半

2. 基于结构的分片（Structure-aware）

按文档的自然结构切：段落、章节、标题层级
Markdown 按 ## 分，HTML 按 <section> 分
优点：保留了作者的逻辑组织
缺点：段落长度不一，有的章节可能特别长

3. 语义分片（Semantic Chunking）

用 embedding 计算相邻句子的语义相似度，在相似度骤降处切割
直觉：相似度骤降说明话题转换了，这就是自然的分片边界
优点：语义完整性最好
缺点：计算成本高，需要额外调参

4. 递归分片（Recursive Splitting）

LangChain 的默认策略：先尝试按大结构分（\n\n），超长则按小结构（\n），再超长则按句子，最后按字符
是一种逐级降级的实用方案

分片的工程细节

Chunk size：通常 256-1024 tokens，需要和 embedding 模型的上下文窗口匹配
Overlap：通常 10%-20% 的重叠，确保边界处的语义不丢失
元数据保留：每个 chunk 附带来源文档、页码、标题层级等 metadata，检索时可以用来过滤和溯源

面试加分点：Parent-Child Chunking

小 chunk 用于检索（细粒度匹配更精准），大 chunk 用于生成（上下文更完整）
检索命中一个小 chunk 后，把它的 parent chunk（或周围的 sibling chunks）一起送进 LLM
兼顾了检索精度和生成质量

五、Embedding 模型原理与应用

原理

Embedding 模型把文本映射到高维向量空间，使得语义相似的文本在空间中距离更近。

训练方式——对比学习（Contrastive Learning）：

构造训练三元组：(query, positive_doc, negative_doc)
训练目标：拉近 query 和 positive 的距离，推远 query 和 negative 的距离
损失函数通常用 InfoNCE：

\mathcal{L} = -\log \frac{e^{sim(q, d^+)/\tau}}{e^{sim(q, d^+)/\tau} + \sum_i e^{sim(q, d^-_i)/\tau}}

主流模型选型

模型	维度	特点
OpenAI text-embedding-3-large	3072	商业方案，效果好，需要调用 API
BGE (BAAI)	768/1024	开源，中英文表现优秀
E5 (Microsoft)	768/1024	开源，instruction-tuned
GTE (Alibaba)	768	开源，多语言
Cohere Embed v3	1024	商业，支持多语言
Jina Embeddings	768	开源，支持长文本（8K tokens）

选型考虑因素

语言：中文场景优先考虑 BGE、GTE
维度：维度越高信息容量越大，但存储和计算成本也越高
上下文长度：大部分模型支持 512 tokens，部分新模型支持 8K+
是否需要 fine-tune：领域专业性强时微调 embedding 模型可以显著提升效果

六、向量数据库详解

1. ChromaDB

定位：轻量级、开发友好的嵌入式向量数据库
特点：
- Python-native，pip install chromadb 即可使用
- 默认使用 HNSW 索引
- 支持 metadata 过滤
- 内置 embedding 函数（可自动调用 OpenAI/HuggingFace 模型）
适用场景：原型开发、小型项目、本地实验
局限：不支持分布式、数据量大了性能下降、不适合生产高并发


client = chromadb.Client()
collection = client.create_collection("docs")
collection.add(documents=["text1", "text2"], ids=["id1", "id2"])
results = collection.query(query_texts=["search query"], n_results=5)

2. Milvus

定位：高性能、分布式、生产级向量数据库
架构：存算分离，计算节点和存储节点独立扩展
特点：
- 支持多种索引：HNSW、IVF_FLAT、IVF_PQ、DiskANN 等
- 支持标量过滤 + 向量检索混合查询
- 支持十亿级向量
- 提供云托管版本 Zilliz Cloud
适用场景：大规模生产系统、高并发、需要水平扩展
对比 ChromaDB：重得多，部署复杂（依赖 etcd、MinIO、Pulsar），但能力强很多

3. pgvector

定位：PostgreSQL 的向量搜索扩展插件
特点：
- 不需要额外部署新数据库，直接在现有 PostgreSQL 上 CREATE EXTENSION vector
- 支持 HNSW 和 IVFFlat 索引
- 向量搜索和关系查询可以在同一条 SQL 中完成
- 支持事务、ACL、备份等 PostgreSQL 的全部运维能力
适用场景：
- 已有 PostgreSQL 基础设施的团队
- 向量数据需要和业务数据 JOIN 查询
- 数据量在百万级以内
局限：性能不如专用向量数据库，十亿级数据不适合

CREATE EXTENSION vector;
CREATE TABLE documents (
  id serial PRIMARY KEY,
  content text,
  embedding vector(768)
);
-- 创建 HNSW 索引
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);
-- 检索
SELECT content FROM documents
ORDER BY embedding <=> '[0.1, 0.2, ...]'  -- cosine distance
LIMIT 5;

向量数据库选型总结

	ChromaDB	Milvus	pgvector
部署复杂度	极低	高	低（已有 PG 的话）
数据规模	十万级	十亿级	百万级
分布式	不支持	原生支持	依赖 PG 方案
混合查询	metadata 过滤	标量+向量	SQL 全能力
生产就绪	原型/小项目	大规模生产	中小规模生产
核心优势	开发体验	性能和规模	与现有数据整合

七、知识召回策略——怎么召回得更准？

1. 混合检索（Hybrid Search）

前面已经讲过，稀疏 + 稠密互补：

Final_score = α × BM25_score + (1-α) × Dense_score

或者用 Reciprocal Rank Fusion (RRF) 合并两路结果：

RRF(d) = \sum_{r \in Rankers} \frac{1}{k + rank_r(d)}

其中 k 通常取 60。RRF 不需要分数归一化，实践中非常稳定。

2. Rerank（重排序）——显著提升精度的关键步骤

为什么需要 Rerank：

初次检索（BM25 或向量检索）是bi-encoder 架构——query 和 document 分别独立编码，无法做细粒度的 token-level 交互。这就像只看了两个人的简历就判断他们是否匹配，没有让他们"面对面交流"。

Rerank 怎么做：

用 cross-encoder 对初次检索返回的 top-k（如 top 50）结果重新打分。Cross-encoder 把 query 和 document 拼接后一起送入 Transformer，做完整的注意力交互，打分更精准。

初检索（快，粗糙）→ 返回 top 50 → Rerank（慢，精准）→ 返回 top 5 → 送入 LLM

主流 Rerank 模型：Cohere Rerank、BGE-Reranker、Jina Reranker、bge-reranker-v2-m3

代价：Cross-encoder 不能预计算，每次查询都要跑模型推理，所以只能对小量候选做 rerank，不能对全库做。

3. Query 改写 / 扩展

用户的原始 query 往往不是最优的检索 query：

Query Rewrite：用 LLM 改写用户问题，使其更适合检索。比如"这个东西怎么用"→"XX 产品的使用说明和操作步骤"
HyDE（Hypothetical Document Embedding）：让 LLM 先生成一个"假想的完美答案"，用这个答案的 embedding 去检索，因为答案和文档的语义空间更接近
Multi-Query：把一个问题分解成多个子问题分别检索，合并结果，提高召回覆盖率

4. Metadata 过滤

在向量检索之前或之后，用结构化字段做硬过滤：

时间范围：只检索最近 3 个月的文档
文档类型：只看技术文档，不看营销材料
权限控制：用户只能看到自己有权限的文档

这一步看似简单，但在生产系统中非常重要，能大幅减少噪声。

5. 多路召回 + 融合

       ┌─ BM25 关键词检索 ──────┐
Query ─┼─ Dense 语义检索 ────────┼─ 融合(RRF) → Rerank → Top-K → LLM
       ├─ Knowledge Graph 查询 ──┤
       └─ Metadata 过滤 ────────┘

每一路针对不同类型的匹配需求，融合后效果最优。

八、RAG 的评估指标（RAGAS 框架）

指标	衡量什么
Context Precision	检索到的内容中，多少是真正相关的
Context Recall	应该检索到的内容，实际检索到了多少
Faithfulness	生成的回答是否忠实于检索到的上下文
Answer Relevancy	回答是否切题

九、面试高频追问及回答要点

Q：BM25 和向量检索什么时候该用哪个？ → 精确关键词（型号、人名、代码）用 BM25；语义模糊（换了说法、同义表达）用 Dense。最佳实践是 Hybrid。

Q：chunk size 怎么选？ → 没有银弹，需要根据文档类型和任务实验。通常 512 tokens 是起点，FAQ 类可以更小（256），技术文档可以更大（1024）。核心原则是每个 chunk 应该是一个自包含的语义单元。

Q：RAG 效果不好怎么排查？ → 分层诊断：先看是检索问题还是生成问题。检索问题看 context precision/recall，可能需要优化分片、embedding、加 rerank。生成问题看 faithfulness，可能需要优化 prompt 或换更强的模型。

RAG检索增强生成：17种优化方法完整指南

什么是RAG？

RAG（Retrieval-Augmented Generation，检索增强生成）是一种提升大模型回答质量的技术方案。其核心思想是：当大模型需要回答问题时，不是直接基于训练数据生成答案，而是先从外部知识库中查询相关资料，然后基于查到的内容生成更准确、更具事实依据的答案。

RAG的最终效果取决于三个关键环节：

如何查询：采用什么策略检索信息
查询什么：文档如何切分和组织
如何使用：检索结果如何整合到生成过程中

十种核心优化方法详解

1. Simple RAG（简单RAG）

核心逻辑

这是最基础的RAG实现方式。文本切块时采用固定字符数或TOKEN数进行机械切割，例如每40个字符切一块，或每100个TOKEN切一块。

实际案例

假设有这样一段文本：

"苹果公司于2007年发布了第一代iPhone，这款手机彻底改变了智能手机行业。相比之下，香蕉是一种富含钾的水果。"

按40字切割时，可能会出现这样的分块：

块1："苹果公司于2007年发布了第一代iPhone，这款手机彻底改变了智能"
块2："手机行业。相比之下，香蕉是一种富含钾的水果。"

优缺点分析

✅ 优点：实现极其简单，无需复杂的自然语言处理，计算成本低

❌ 缺点：

切割方式死板，容易在句子中间切断
导致语义断裂，上下文信息丢失
可能将不相关的内容混在同一块中

2. 语义切割（Semantic Chunking）

核心逻辑

不按固定字数切割，而是按句子为单位进行智能切分。系统会计算相邻句子之间的语义相似度，当相似度出现显著下降时，说明话题发生了转换，此处即为切割点。这样能确保每个切块都是语义完整的单元。

实际案例

针对前面的示例文本，语义切割会识别出"iPhone相关内容"与"香蕉相关内容"之间的相似度骤降，从而切分为：

块1："苹果公司于2007年发布了第一代iPhone"
块2："这款手机彻底改变了智能手机行业"
块3："相比之下，香蕉是一种富含钾的水果"

优缺点分析

✅ 优点：每个切块语义完整，检索时能精准匹配核心概念

❌ 缺点：召回率可能较低，因为切块过于精细，可能遗漏部分边缘相关信息

3. 上下文增强检索（Contextual Retrieval）

核心逻辑

当检索到相关文本块后，系统不仅返回该块本身，还会自动附带其前后相邻的"邻居块"，将它们一同提交给大模型。这样可以保留局部上下文信息。

实际案例

假设文档被切分为三块：

块1：苹果公司的历史背景
块2：第一代iPhone的屏幕设计和无物理按键特性（核心相关）
块3：iPhone的电池续航表现

当用户询问"iPhone的设计特点"时，虽然块2是最相关的，但系统会将块1、块2、块3打包返回，让大模型能够了解更完整的背景。

优缺点分析

✅ 优点：

避免信息碎片化
保留局部上下文，帮助大模型更好理解
减少因切块导致的信息丢失

❌ 缺点：会引入一些可能不太相关的内容，增加token消耗

4. 上下文分块标题（Contextual Chunk Headers）

核心逻辑

在文档切块时或切块后，为每个切块添加对应的章节标题或主题标签。将标题与内容一起进行向量嵌入处理，这样检索时可以利用标题信息进行更精准的匹配。

实际案例

原始切块处理：

切块A："苹果公司于2007年发布了第一代iPhone..."
切块B："香蕉是一种富含钾的水果..."

添加标题后：

切块A："[苹果手机的历史和特性] 苹果公司于2007年发布了第一代iPhone..."
切块B："[香蕉的营养和用途] 香蕉是一种富含钾的水果..."

优缺点分析

✅ 优点：

即使不同切块存在相同词汇，也能通过标题区分语境
提高检索精准度，避免歧义
帮助模型快速理解文本块的主题

5. 文本增强（Hypothetical Questions）

核心逻辑

让大模型为每个文本块生成若干个可能的问题。将原始文本块与生成的问题一起进行向量化并存储到知识库中。检索时，用户的问题既可以匹配原文，也可以匹配这些生成的假设性问题。

实际案例

针对文本块"苹果公司于2007年发布了第一代iPhone，这款手机没有物理键盘"，系统生成以下问题：

"第一代iPhone是什么时候发布的？"
"iPhone有物理键盘吗？"
"第一代iPhone的发布年份是？"

当用户提问"iPhone有没有实体按键？"时，即使用词不完全一致，也能通过匹配生成的问题"iPhone有物理键盘吗？"快速定位到该文本块。

优缺点分析

✅ 优点：

大幅提升召回率
扩大检索匹配范围
能够处理用户问题的多种表达方式

❌ 缺点：需要额外的LLM调用生成问题，增加预处理成本

6. 查询转换（Query Transformation）

核心逻辑

针对用户可能存在歧义或表达不清的问题，通过以下三种方式优化查询：

查询重写：将模糊问题改写为更精确的表达
回退提示：提供更通用的备选查询方式
子查询分解：将复杂问题拆解为多个简单子问题

实际案例

原始用户问题："iPhone键盘怎么样？"

查询转换后：

重写版："第一代iPhone是否配备了物理键盘？它的键盘输入方式是什么？"
回退版："iPhone的输入方式"
子查询：
- "第一代iPhone有物理键盘吗？"
- "iPhone使用什么类型的键盘？"
- "iPhone的触摸屏键盘如何操作？"

优缺点分析

✅ 优点：

问题精准度大幅提升
大模型能更准确理解用户意图
减少歧义导致的检索偏差

7. 重排序（Reranking）

核心逻辑

检索过程分为两个阶段：

第一阶段（召回）：快速检索，返回较多候选结果（如Top 20）
第二阶段（重排）：使用专门的Reranker模型对候选结果打分排序，仅保留最相关的少数结果（如Top 5）提交给大模型

实际案例

用户查询："苹果手机的特点"

第一阶段召回20个候选块：

块A：苹果iPhone的设计特性（相关度：9分）
块B：香蕉的营养价值（相关度：2分）
块C：机械键盘的手感（相关度：3分）
块D：苹果公司的发展历史（相关度：7分）
...

第二阶段重排后，最终返回：

块A（9分）
块D（7分）
块M（6分）

优缺点分析

✅ 优点：

筛选出最相关的核心信息
大幅提升检索精准度
平衡了召回率和精确率

❌ 缺点：增加了计算成本和响应时间

核心逻辑

检索到多个相关文本块后，系统会判断这些块在原始文档中是否连续。如果检索到的多个块在原文中是相邻的段落，系统会将它们拼接成完整的连续文本返回。

实际案例

用户询问："iPhone的完整介绍"

检索结果：

块A：iPhone的发布时间（原文位置：第10-12段）
块B：iPhone的设计特性（原文位置：第13-15段）
块C：iPhone的操作系统（原文位置：第16-18段）

由于三个块在原文中连续出现（第10-18段），系统将它们拼接为一个完整段落返回。

适用场景

这种方法特别适合：

说明性文档
技术手册
长篇分析文章
任何需要连贯阅读的内容

优缺点分析

✅ 优点：保证上下文的连贯性和完整性

❌ 缺点：可能引入一些不太相关但位置相邻的内容

9. 上下文压缩（Context Compression）

核心逻辑

对检索到的文本块进行二次筛选，仅保留与用户问题直接相关的句子，删除无关或边缘相关的内容。这是一个"减法"过程，目的是提纯信息。

实际案例

检索到的文本块包含：

"苹果公司成立于1976年，总部位于加州。2007年发布的第一代iPhone采用3.5英寸触摸屏，没有物理键盘，这是一个革命性的设计。当时的竞争对手包括诺基亚和黑莓。"

用户问题："iPhone有物理键盘吗？"

压缩后保留：

"第一代iPhone没有物理键盘，采用触摸屏设计。"

优缺点分析

✅ 优点：

减少无关信息干扰
让大模型聚焦核心问题
降低token消耗
提升回答精准度

❌ 缺点：过度压缩可能丢失有用的背景信息

10. 反馈循环（Feedback Loop）

核心逻辑

类似于大模型的人类反馈强化学习（RLHF）。通过收集用户对回答的反馈（有用/无用），系统会调整文档权重或微调嵌入模型，实现性能的持续优化。

实际案例

第一轮交互：

用户问："iPhone有没有物理键盘？"
系统返回相关答案
用户标记：👍 有用

系统学习：

记录该查询与成功召回的文档块的关联
提升该文档块对类似查询的权重

第二轮交互：

另一个用户问："iPhone有实体按键吗？"
系统更有可能召回之前被标记为有用的文档块

优缺点分析

✅ 优点：

系统能学习人类偏好
越用越智能
检索准确性持续提升
适应特定领域或用户群体的需求

❌ 缺点：

需要积累足够的反馈数据
可能存在反馈偏差
实现相对复杂

其他七种优化方法概览

视频提到共有17种RAG优化方法，除了上述详细介绍的10种外，还有7种优化技术。这些方法同样围绕三大核心方向展开：

提升检索精准度：通过更智能的匹配算法和相似度计算
保留上下文完整性：避免切块导致的信息碎片化
优化交互反馈：改善用户体验和系统迭代能力

这些方法可能包括：

混合检索（结合关键词和语义检索）
多向量索引
层级式检索
动态切块策略
知识图谱增强
跨文档推理
自适应检索策略

如何选择合适的优化方法？

根据应用场景选择

应用场景	推荐方法	原因
技术文档问答	上下文增强 + 重排序	保证技术细节的完整性和准确性
客服聊天机器人	查询转换 + 文本增强	处理用户多样化的表达方式
学术研究助手	语义切割 + 相关段落提取	保持学术论证的连贯性
法律文档查询	上下文分块标题 + 压缩	精准定位条款，去除无关内容

根据资源限制选择

计算资源充足：可以组合使用多种方法，如"语义切割 + 文本增强 + 重排序 + 反馈循环"

资源受限：从Simple RAG开始，逐步引入"上下文增强"或"查询转换"等轻量级优化

根据数据特点选择

文档结构清晰：优先使用上下文分块标题
内容高度相关：使用相关段落提取
数据量大：必须使用重排序
用户查询多样：优先使用查询转换和文本增强

实施建议

1. 从基础开始，逐步迭代

不要试图一次性实现所有优化方法。建议路径：

Simple RAG（建立基线）
语义切割（提升切块质量）
重排序（提升精准度）
根据实际效果引入其他方法

2. 建立评估体系

关键指标：

召回率：相关文档被检索到的比例
精确率：检索结果中相关文档的比例
响应时间：从查询到返回结果的耗时
用户满意度：通过反馈收集

3. 持续优化

收集用户反馈
分析失败案例
A/B测试不同方法组合
定期评估和调整策略

总结

RAG技术的核心是通过外部知识增强大模型的回答能力。17种优化方法各有侧重，从文档切分、检索策略到结果处理，每个环节都有优化空间。

关键要点：

没有一种方法适用于所有场景
组合使用多种方法通常效果更好
要根据具体应用场景和资源限制选择
建立反馈机制，持续优化系统性能

通过合理选择和组合这些优化方法，可以显著提升RAG系统的准确性、相关性和用户体验。

RAG 之前的知识库检索关键技术

一、稀疏检索（Sparse Retrieval）

1. TF-IDF（Term Frequency - Inverse Document Frequency）

2. BM25（Best Matching 25）

二、倒排索引（Inverted Index）

三、稀疏检索的局限 → 引出稠密检索

四、稠密检索（Dense Retrieval）

Embedding 模型

距离度量

优势

局限

五、ANN（Approximate Nearest Neighbor）

主流算法

性能权衡

主流向量数据库

六、Hybrid Search（混合检索）

七、知识图谱（Knowledge Graph）

八、技术演进脉络

知识库系统建设与 RAG 全面解析

一、RAG 是什么

二、RAG 完整流程

离线阶段（Indexing Pipeline）

在线阶段（Query Pipeline）

三、文档解析（Document Parsing）

四、分片策略（Chunking）——面试高频考点

常见策略

分片的工程细节

面试加分点：Parent-Child Chunking

五、Embedding 模型原理与应用

原理

主流模型选型

选型考虑因素

六、向量数据库详解

1. ChromaDB

2. Milvus

3. pgvector

向量数据库选型总结

七、知识召回策略——怎么召回得更准？

1. 混合检索（Hybrid Search）

2. Rerank（重排序）——显著提升精度的关键步骤

3. Query 改写 / 扩展

4. Metadata 过滤

5. 多路召回 + 融合

八、RAG 的评估指标（RAGAS 框架）

九、面试高频追问及回答要点

RAG检索增强生成：17种优化方法完整指南

什么是RAG？

十种核心优化方法详解

1. Simple RAG（简单RAG）

2. 语义切割（Semantic Chunking）

3. 上下文增强检索（Contextual Retrieval）

4. 上下文分块标题（Contextual Chunk Headers）

5. 文本增强（Hypothetical Questions）

6. 查询转换（Query Transformation）

7. 重排序（Reranking）

8. 相关段落提取（RSE - Related Section Extraction）

9. 上下文压缩（Context Compression）

10. 反馈循环（Feedback Loop）

其他七种优化方法概览

如何选择合适的优化方法？

根据应用场景选择

根据资源限制选择

根据数据特点选择

实施建议

1. 从基础开始，逐步迭代

2. 建立评估体系

3. 持续优化

总结