漫画图解 Easysearch RAG —— 让大模型拥有“自己知识库”的关键技术

铭毅天下Elasticsearch 2026-02-27

115

大家好，我是铭毅天下。

最近在用 Cursor 结合各种大模型写代码、做开发时，经常有粉丝在群里问：大模型确实牛，但一问到咱们公司内部的业务代码，或者 Elasticsearch 9.x、Easysearch 2.X 的最新特性，它就开始胡说八道了，怎么破？

这就引出了咱们今天的主角：RAG（检索增强生成）。

RAG 检索增强系统实战实现

这篇文章，咱们就配着 10 幅手绘漫画，把 RAG 这个 AI 时代最关键的技术盘得明明白白。

一、为什么需要 RAG？聊聊大模型在实际应用中最要命的“硬伤”

ChatGPT、Claude 等大语言模型（LLM）虽然强大，但在真实的生产环境和企业级应用中，存在着致命的弱点：

图1：大模型的“知识盲区”

知识截止日期与私域数据盲区：

大模型的知识是被“冻结”在它训练完成的那一刻的。你问它 2026 年的最新技术，它只能翻旧报纸。更致命的是，它绝对不可能知道你们公司内部的《2026年Q1产品规划文档》。

图2：一本正经胡说八道

幻觉问题 (Hallucination)：

这是最让人头疼的。当 LLM 遇到知识盲区时，它往往不会坦白说“我不知道”，而是会极其自信地给你编造一个不存在的 API 接口或者参数。这在严谨的技术和商业场景中，堪称灾难。

二、什么是 RAG？给大模型“开个外挂”

为了解决这些痛点，RAG（Retrieval-Augmented Generation，检索增强生成） 应运而生。

用一句通俗的话解释：RAG 就是让大模型从“闭卷考试”变成“开卷考试”。

图3：闭卷改开卷

大模型不再仅凭肚子里背过的知识硬答，而是我们在它身边放了一个实时更新的“超级图书馆”（外部知识库）。

遇到问题先查资料，再根据查到的资料来组织语言回答。

对比维度	传统 LLM（闭卷）	RAG（开卷）
知识来源	训练时学到的参数	实时检索的外部知识库
时效性	受限于训练数据时间	可随时接入最新数据
私域数据	无法访问	可安全接入企业内部文档
幻觉风险	较高（容易瞎编）	大幅降低（有据可查）

三、 RAG 是如何工作的？（硬核拆解）

RAG 听起来神奇，但剥开外衣，核心就两大步：离线建库 和 在线检索生成。

图4：第一步：知识向量化

1. 离线阶段：构建知识库（知识喂食）想要机器能快速查资料，得先把人类语言翻译成机器语言：

文本分块 (Chunking)：
把长文档切分成语义完整的片段。干货经验：通常按 500 字符切块，保留 50 字符的重叠（Overlap），防止一句话被从中间硬生生切断，丢失上下文。
向量化 (Embedding)：
利用 Embedding 模型（比如 BAAI/bge-small-zh-v1.5
），将文本转化为高维空间中的坐标点（向量）。
存入数据库：写入支持向量检索的底层系统（如 Easysearch）。

图5：第二步：精准检索

2. 在线阶段环节一：检索 (Retrieval)

用户提问时，系统会把用户的“问题”也变成一个向量磁铁。

在多维空间里，这个磁铁会精准吸附距离它最近的几个知识块。不再是死板的关键词匹配，而是“意思相近”就能找到。

图6：第三步：上下文拼装

3. 在线阶段环节二：生成 (Generation)

搜到干货后怎么用？就像图里画的，我们把“用户的原始问题”和“刚刚搜出来的知识素材”一起打包，塞进一个名为 Prompt（提示词）的大信封里，直接喂给 LLM。

告诉它：“结合这些参考资料，回答用户的问题。”

图7：全流程图解

总结一下，一张图看懂全流程：用户提问查询向量化检索底层库上下文拼装 LLM 生成答案。 建议大家把这张图长按保存。

四、技术选型：RAG vs Fine-tuning (微调)

很多朋友会问：“想让模型变聪明，我直接拿企业数据去微调（Fine-tuning）不行吗？”

图8：RAG vs 微调

看这张对比图就明白了：微调是让模型“改变说话的语气和内在逻辑”，而 RAG 是给模型“塞一本最新的字典”。

维度	RAG (检索增强)	Fine-tuning (微调)
知识更新	实时更新，改库即可，无需训练	需重新训练，耗时数小时到数天
成本	极低（仅需算力跑 Embedding）	极高（需要大量 GPU 算力）
可解释性	高（生成的答案可追溯参考来源）	低（黑盒输出，不知道从哪学来的）
适用场景	知识密集、数据常更新的企业知识库	学习特定行业黑话、固定任务格式输出

铭毅决策建议：绝大多数企业级问答场景，优先无脑上 RAG；如果是极其复杂的垂直领域（比如医疗诊断语气），再考虑 RAG + 微调结合。

五、核心枢纽：为什么 Easysearch 是 RAG 的绝佳底座？

在整个 RAG 流程中，扮演“图书馆管理员”角色的检索系统至关重要。作为 Elastic Stack 老兵，我强烈建议使用 Easysearch (及 Elasticsearch) 作为基础设施。

图9：Easysearch 的超能力：混合检索

为什么不直接用纯向量数据库？

因为向量检索也有弱点！它懂“语义”，但容易忽略“精确度”。比如你搜“Elasticsearch 8.13 报错”，向量检索可能会给你推“ES 7.x 的类似报错”，因为它觉得意思差不多。

这就需要 混合检索 (Hybrid Search) 登场了：

检索方式	优势	局限
传统 BM25 关键词检索	精确匹配，擅长搜特定产品型号、代码片段	无法理解同义词，词不达意就搜不到
向量语义检索	理解深层语义，支持模糊表达	精确度不足，容易丢失关键细节

Easysearch 能在一个索引里同时搞定这两件事！

在 Easysearch 中，实现这种强大的混合检索只需要一段优雅的 JSON：

https://docs.infinilabs.com/easysearch/main/docs/features/vector-search/vector-and-semantic-search/

POST /my-index/_search
{
  "size": 10,
  "query": {
    "bool": {
      "must": [
        {
          "knn_nearest_neighbors": {
            "field": "embedding",
            "vec": { "values": [0.12, -0.03, ...] },
            "model": "lsh",
            "similarity": "cosine",
            "candidates": 100
          }
        }
      ],
      "should": [
        {
          "match": {
            "content": {
              "query": "分布式搜索引擎",
              "boost": 2.0
            }
          }
        }
      ]
    }
  }
}