索引 / 标签
#检索增强
共 38 篇
- Ch13 RAG
深挖-分块策略实测
一句话理解 「分块该切多大」这个问题，我在自己的 131 万字笔记上真跑了一遍。结论和教科书不一样：在本来就有标题结构的文档上，「按标题切」比任何固定字数都强，而且强得不是一点。 零基础理解
约 10 分钟3,048 字 - Ch13 RAG
概念-重排序
一句话理解 重排序（Reranking）是 RAG 系统中的"精挑细选"环节：从初步检索返回的几十条结果中，用更精确的模型重新排序，挑出最相关的 Top-K 送给 LLM。 为什么需要重排序
约 1 分钟334 字 - Ch11 模型微调
RAFT（深挖）
RAFT（Retrieval Augmented Fine-Tuning，检索增强微调）是 2024 年提出的微调策略：在微调阶段就把检索文档混入训练数据，让模型学会"查阅资料再回答"，而不是像传统 RAG 那样只在推理时做检索。RAFT 训练出的模型在推理时配合检索，效果优于纯
约 3 分钟1,031 字 - Ch13 RAG
Bi-Encoder (双塔模型/双编码器)
概述 Bi-Encoder (双编码器) 是一种双塔架构的神经网络模型，核心思想是将两个输入 (如 Query 和 Document、User 和 Item) 分别通过独立的编码器编码为向量表
约 3 分钟892 字 - Ch13 RAG
概念-ColBERT
一句话理解 ColBERT（Contextualized Late Interaction over BERT）是一种延迟交互检索模型，它的核心思想是：不对 query 和 document
约 4 分钟1,272 字 - Ch13 RAG
Cross-Encoder (交叉编码器)
概述 Cross-Encoder（交叉编码器）是一种将查询（Query）和文档（Document）同时输入同一个编码器进行联合编码的架构。与 Bi-Encoder 不同，Cross-Encod
约 3 分钟919 字 - Ch13 RAG
概念-CrossEncoder
一句话理解 Cross-Encoder（交叉编码器）是同时输入 query 和 document、通过 Transformer 的全注意力机制进行深度交互、输出一个相关性分数的模型。它是检索系
约 3 分钟1,040 字 - Ch13 RAG
概念-Embedding模型
一句话理解 将文本、图像、音频等非结构化数据映射为稠密向量（Dense Vector）的模型。语义相近的输入在向量空间中距离近，语义不相关的输入距离远。 零基础理解 给每个词、每句话分配一个"
约 4 分钟1,158 字 - Ch13 RAG
HyDE (Hypothetical Document Embeddings)
概述 HyDE (Hypothetical Document Embeddings) 是 2022 年由 Gao 等人提出的一种检索增强生成 (RAG) 技术，被认为是 RAG 领域最具影响力
约 4 分钟1,377 字 - Ch13 RAG
RAG (Retrieval-Augmented Generation)
概述 RAG（Retrieval-Augmented Generation，检索增强生成）是一种将信息检索与文本生成相结合的 AI 技术架构。在 RAG 中，LLM 在生成回答之前，先从外部知
约 3 分钟943 字 - Ch13 RAG
Self-RAG 与 Corrective RAG
概述 Self-RAG 和 Corrective RAG (CRAG) 代表了 RAG 范式从"被动检索"到"主动反思"的进化。传统的 RAG 系统无条件地对每个查询执行检索，而 Self-R
约 4 分钟1,279 字 - Ch13 RAG
上下文压缩 (Context Compression)
概述 上下文压缩（Context Compression）是解决 LLM 上下文窗口限制和推理成本问题的关键技术。当需要处理大量文档、长对话历史或长代码文件时，直接输入全部内容可能超出模型的上
约 4 分钟1,364 字 - Ch13 RAG
深挖-向量数据库
一句话理解 专门存储和检索高维向量的数据库系统，是 RAG（检索增强生成）的核心基础设施，支撑语义搜索、推荐系统、相似度去重等场景。 零基础理解 传统数据库存的是数字和文本，查询时做精确匹配；
约 4 分钟1,386 字 - Ch13 RAG
深挖-向量数据库选型
一句话理解 根据数据量级、运维能力、预算、功能需求（混合检索、GPU 加速、过滤能力）综合评估，选择最适合当前场景的向量数据库——没有"最好"的数据库，只有最匹配的。 选型决策树 按优先级依次
约 6 分钟1,849 字 - Ch13 RAG
深挖-重排序
一句话理解 对初检阶段召回的候选结果进行二次排序，将最相关的文档排到最前面，显著提升 RAG 系统的精度和答案质量。 零基础理解 想象你在图书馆查询"人工智能的历史"： - 初检（Retrie
约 4 分钟1,298 字 - Ch13 RAG
项目三：搭一个能查资料的 AI
30 分钟。需要一点点 Python（复制粘贴即可）。做一个能回答"关于你的文档"问题的 AI。 你要做什么 用 Python 搭一个最小的 RAG 系统。给它几篇文档，它能基于文档内容回答问
约 2 分钟508 字 - Ch13 RAG
13.1 为什么需要 RAG
13.1.1 LLM 的三大局限 AI（人工智能）的知识来自训练数据。训练完之后就不会自动更新了。你问它"今天北京天气怎么样"，它不知道——训练数据里没有"今天"。具体来说，大语言模型（LLM
约 4 分钟1,295 字 - Ch13 RAG
13.10 第五代：知识图谱辅助（Graph RAG）
有些问题需要"多跳推理"——不是搜一次能解决的。 比如"张三的老板的老板是谁"——你得先找到"张三的老板是谁"，再找"那个人的老板是谁"。传统 RAG 搜一次只能回答第一跳。 13.10.1 Graph RAG 的原理 2024 年微软开源了 Graph RAG——它不把文档当纯
约 4 分钟1,169 字 - Ch13 RAG
13.12 RAG 高级技术
五代进化讲的是 RAG 的宏观演变路径。但在每一代内部，还有大量"高级技术"可以提升效果。这些技术不是独立的一代，而是可以在任何一代上叠加的优化手段。 13.12.1 HyDE（假设文档嵌入） 2023 年提出的反直觉但有效的技术。核心思路：用生成来增强检索。 传统 RAG 的问
约 4 分钟1,277 字 - Ch13 RAG
13.13 RAG 评估
你搭了一个 RAG 系统，改了分块策略，换了重排序模型——你怎么知道它变好了还是变差了？RAG 评估就是回答这个问题的。 13.13.1 为什么 RAG 评估这么难 评估一个聊天机器人相对容易——你问一个问题，看它回答得好不好。但 RAG 系统有两层：检索层和生成层。答案不好，可
约 4 分钟1,201 字 - Ch13 RAG
13.14 RAG vs 微调 vs 长上下文
RAG 不是唯一的选择。面对"让 LLM 知道更多信息"这个问题，你有三种方案：RAG、微调、长上下文。2026 年，这三种方案各有各的位置。 13.14.1 三种方案对比 RAG：检索 + 生成。知识存在外部数据库里，查询时动态检索。知识更新：实时（改数据库就行）。成本：每次查
约 3 分钟907 字 - Ch13 RAG
13.15 RAG 生产部署
从 Jupyter Notebook 里的 Demo 到生产环境可用的系统，中间有一大段路要走。这一节讲 2026 年 RAG 生产部署的实践建议。 13.15.1 2026 RAG 技术栈推荐 入门级（个人项目 / MVP）： - 向量数据库：Chroma（开源，Python
约 3 分钟1,050 字 - Ch13 RAG
13.16 动手搭一个 RAG
前面讲了这么多理论，这一节用最少的代码，让你真正跑起来一个 RAG 系统。 13.16.1 30 行代码搭一个最小 RAG 13.16.2 逐步解释 第 1-3 行：导入库。chromadb 是向量数据库，openai 提供 Embedding 和 LLM 能力。 第 6-12
约 2 分钟519 字 - Ch13 RAG
13.2 RAG 系统架构
RAG 看起来很直观，但背后是一套工程系统。理解它的架构，你才能理解为什么"分块大小"、"检索策略"、"重排序"这些细节如此重要。 13.2.1 两条管线：离线索引 + 在线查询 RAG 系统由两条管线组成，一条在用户提问前运行（离线），一条在用户提问时运行（在线）。 离线索引管
约 3 分钟1,006 字 - Ch13 RAG
13.3 分块策略 —— RAG 的地基
分块（Chunking）是 RAG 系统中最容易被低估的环节。检索质量的上限，很大程度上由分块策略决定。分得太大，检索不准；分得太小，语义不完整；分得不合理，后面全白搭。 13.3.1 为什么需要分块 三个原因。第一，Embedding 模型有输入长度限制。 很多开源 Embed
约 6 分钟1,777 字 - Ch13 RAG
13.4 第一代：关键词搜索（稀疏检索）
最早的做法：把用户的问题当成搜索关键词，在文档库里找包含这些词的文档。 比如用户问"头疼吃什么药"，系统搜索包含"头疼""什么""药"这些词的文档，找到一堆相关文章，塞给 AI。AI 读完后回答。 13.4.1 稀疏检索的原理 这种方法叫关键词检索，在信息检索领域有更专业的名字—
约 3 分钟864 字 - Ch13 RAG
13.5 第二代：语义搜索（稠密检索）
后来有了更好的办法：把文本变成一串数字（叫"向量"），语义相近的文本，数字也相近。 "苹果手机"和"iPhone"在向量空间里离得很近——因为它们意思一样。即使用词完全不同，系统也能找到。 13.5.1 稠密检索的原理 这种方法叫语义检索（也叫稠密检索——"稠密"的意思是每个词的
约 3 分钟1,024 字 - Ch13 RAG
13.6 第三代：混合检索
关键词检索和语义检索各有优点。关键词检索在搜人名、地名、专有名词时更准。语义检索在搜意思相近的内容时更准。 2025 年开始，实际系统都是混合检索——两边一起搜，把结果合并，再做一次排序，挑最相关的内容给 AI。这样既不会漏掉精确匹配的关键词结果，也能找到语义相近的内容 ^Sta
约 2 分钟749 字 - Ch13 RAG
13.7 重排序 —— 提升精度的关键
混合检索给了你 Top-K 个候选文档（K 通常取 20-50），但这些候选文档的质量参差不齐。你需要一个"精选"环节——从 50 个候选中挑出最相关的 3-5 个，塞进 LLM 的 Prompt。这就是重排序。 13.7.1 为什么需要重排序 初检（Embedding + BM
约 3 分钟923 字 - Ch13 RAG
13.8 生成阶段 —— 让 LLM 用上检索结果
检索和重排序完成了"找资料"的工作，但最终的质量取决于 LLM 怎么"用"这些资料。生成阶段的设计同样重要。 13.8.1 Prompt 模板设计 RAG 的 Prompt 模板通常包含四个部分： 1. 系统角色设定：告诉 LLM 它是谁。"你是一个专业的技术文档助手"和"你是一
约 3 分钟1,050 字 - Ch13 RAG
13.9 第四代：AI 自己决定怎么搜（Agentic RAG）
前三代的做法都是人预先定好的流程——搜几次、怎么搜、搜什么，都是固定的。 2025 年出现了新思路：让 AI 自己决定。AI 拿到问题后，自己判断——这个问题需要搜几次？每次搜什么关键词？搜索结果够不够好？不够就换个方式再搜一次。 13.9.1 Agentic RAG 的核心思想
约 3 分钟985 字 - Ch13 RAG
- Ch13 RAG
- Ch13 RAG
图谱检索 RAG（深挖）
前四种检索方法都基于"文档"——搜到文档，给 AI 读，AI 回答。但有些问题需要对关系进行推理，而不是对文档进行匹配。 "张三的老板的老板是谁？" 传统 RAG 搜到"张三的老板是李四"这篇文档。但"李四的老板是谁"在另一篇文档里。传统 RAG 看不到这个跨文档的关系。Grap
约 3 分钟893 字 - Ch13 RAG
混合检索（深挖）
深挖-稀疏检索 能精确命中，但不懂语义。深挖-稠密检索 懂语义，但精确匹配容易漂移。混合检索把两条路合在一起，取各自的长处。2025-2026 年，生产环境几乎都是混合检索。
约 3 分钟1,007 字 - Ch13 RAG
- Ch13 RAG
- Ch14 Agent原理
自主检索 RAG（深挖）
前三种检索方式（深挖-稀疏检索、深挖-稠密检索、深挖-混合检索）都是固定流程——搜一次，返回结果，给 AI。Agentic RAG（自主检索增强生成）打破了固定流程：AI 自己决定搜几次、怎么搜、搜完要不要再搜。 和传统 RAG 的根本区别 传统 RAG：用户问 - 检索 - 给
约 2 分钟786 字