欢迎光临
我们一直在努力

【AI应用--白话大模型(篇十)】《一文全系列搞懂RAG技术:RAG从原理到应用,文本分块,向量嵌入,数据入库以及RAG未来的趋势发展》

背景

检索增强⽣成(Retrieval-Augmented Generation, RAG)已成为当下⼈⼯智能领域最重要的技术范式之⼀。它的核⼼价值在于巧妙地结合了信息检索的精准性与⼤语⾔模型(LLM)的⽣成能⼒,为⼤语⾔模型装上⼀个能够实时查阅资料的“外接⼤脑”,从⽽解决了⼤模型落地中的关键难题


RAG解决了“⼤模型⽆法稳定访问外部知识”这个核⼼问题。这个对于企业使⽤AI场景⾮常有⽤

  • 企业内部的知识库不允许对外,⾖包、千问、DeepSeek等⼤模型没办法学习,企业希望有个助⼿能根据需要提供智能问答⾮常困难
  •  企业发布了新的新闻和内容,模型怎么能⻢上⽤上
  •  ⼤模型说了⼀堆内容,和企业的说明书哪⾥能对上,把使⽤的来源标记下,尤其在法律、医疗等对准确性要求极⾼的领域⾄关重要

  • 一.RAG是什么

    RAG (Retrieval-Augmented Generation,检索增强⽣成) 是⼀种将强⼤的信息检索 (InformationRetrieval, IR) 技术与⽣成式⼤语⾔模型 (LLM) 相结合的框架。

    • 检索:从海量的、外部知识源(如公司⽂档、数据库、⽹⻚等)中,根据⽤⼾的问题,找到最相关的信息⽚段。
    • 增强:将这些检索到的相关信息,作为额外的上下⽂,提供给⼤语⾔模型。
    • ⽣成:⼤语⾔模型基于原始的⽤⼾问题 和 检索到的增强上下⽂,⽣成更准确、更可靠、更具事实性的答案。

    ⼀句话概述就是先从你的知识库⾥检索相关内容,把检索到的内容塞进Prompt,再让模型基于这些内容⽣成回答。

    可以想象是开卷考试,模型并不知道你的业务知识,但是查资料,然后组织答案。

      


      二. 为什么需要RAG

    2.1.知识过时与信息孤岛

    LLM在存储形态上就是⼀个很⼤的⽂件,这个⽂件是离线训练的,⼀旦训练好了,⼤模型的知识就固定了,⽬前⼤模型没有办法做的实时训练,也就是说⼤语⾔模型的知识完全来⾃训练数据,⽽且训练数据主要来⾃⽹络公开数据。这就有以下为

    • 模型的"知识"被定格在训练截⽌时间点。对于新的知识(⽐如今天的新闻)模型内部是不知道的。

    • 企业的产品规格⽂档、内部流程规范、医疗机构的诊断指南、法律机构的判例汇编——这些数据从没出现在公开⽹络上,通⽤⼤模型对此⼀⽆所知。不借助外部⼿段,模型在这些领域的回答质量会⼤打折扣。


    2.2 ⼤模型幻觉

    LLM是⼀个条件概率模型,以前⽂作为条件的词表概率逐词⽣成⽂本,这⼀机制导致其可能出现看似逻辑严谨(概率⾼)但其实缺乏事实依据的⽣成,也就是“⼀本正经地胡说⼋道”。 LLM的训练过程,是对训练数据的知识进⾏压缩提炼的过程,但不是⽆损压缩知识。 可以看到⼜说到26年4⽉没公布,⼜说⼀般每年10⽉公布,逻辑⽭盾。


    2.3 数据安全

    对企业来说,数据安全是⽣死攸关的议题。没⼈愿意承担核⼼商业机密泄露的⻛险,因此⼏乎没有企业愿意将私有数据上传到第三⽅平台进⾏模型训练或推理。在功能和保密上,企业往往选择的是保密,宁愿不⽤也不能泄露数据。


    三.体验下RAG

    1. 准备数据,准备一个pdf


    2. 了解下Coze

    Coze(中⽂名“扣⼦”)是字节跳动推出的⼀站式 AI 智能体开发平台,主打零代码/低代码开发体 验,让即使没有编程背景的⽤⼾也能快速创建 AI 聊天机器⼈、智能助⼿或其他 AI 应⽤,并可⼀键发布到多个社交平台或集成进业务系统。


    3. 进⼊Coze官⽹(扣子 Coze – 字节跳动旗下职场AI伙伴扣子与一站式AI开发平台扣子编程 PPT数据分析小程序开发APP开发网页开发平面设计教学备课报告写作自媒体播客视频智能体工作流

    ),找到免费开始,完成账号注册


    4. 输⼊之后我们找到Coze编程,默认是个⼈免费版,免费版每天登录会赠送使⽤积分


    5. 我们点击新建项⽬


    6. 选择智能体开发


    7. 我们进⼊创建智能体环节,我们选择标准创建


    8. 我们进⼊智能体配置⻚⾯,可以看到我们可以给智能体配置⼈设、知识库、⼯作流等信息,我们本次主要关⼼知识库,我们先来问⼀个我们私有⽂档⾥⾯的信息,可以看到模型根据已有知识猜测回答,幻觉严重


    9. 我们添加上知识库,选择知识下⾯的⽂本,然后点击添加按钮


    10. 导⼊知识库,我们选择⽂本格式,⽀持导⼊PDF


    11. 上传⽂件


    12. 我们使⽤默认设置进⾏解析


    13. 预览解析效果


    14. 开始处理


    15. 处理完成后,我们添加到智能体


    16. 我们再次询问价钱看下效果,可以看到模型可以回复价格50元。


    17. 我们点击发布


    18. 我们点击发布,可以直接发布为在线应⽤。


    19. 我们直接对话看下效果


    20. 发布后直接对话可以看到能够读取到我们的私有知识库内容来回答

    可以看到这样的⼀个机器⼈可以企业内部的知识快速有效使⽤起来,⽽不会受限于⼤模型。


    四.RAG的常⻅应⽤场景

    智能客⼾服务

    RAG在客服领域的落地最为成熟,核⼼价值体现在:将企业分散的FAQ、业务⼿册与实时政策转化为可以⾃动响应的智能知识体系。 ⼀汽丰⽥智能客服系统:该公司借助腾讯云RAG能⼒接⼊DeepSeek⼤模型,构建"检索-增强-⽣成"的智能客服体系。效果显著:智能在线客服独⽴解决率从37%提升⾄84%,⽉均⾃动解决咨询问题达1.7万次。技术关键在于——通过RAG将企业专属知识(如⻋型参数、售后政策等)"注⼊"⼤模型,⽣成更精准的答案。

    腾讯云助力一汽丰田落地DeepSeek 全面升级智能客服体验_车家号_发现车生活_汽车之家


    企业知识库

    如果说智能客服⾯向"外部客⼾",企业知识中枢则⾯向员⼯⾃⾝,⽬标是"让组织知识可沉淀、可复 ⽤、可搜索"。 ⼴西地理信息测绘院"组织智慧⼤脑":运⽤"向量知识库+RAG"技术,将1200多篇技术⽂档、论⽂和专利结构化⼊库,覆盖全院85%技术岗位,查询准确率⾼达80%,⽤⼾满意度稳定在90%。系统实现"问即所得,答有所据",有效化解了"⼈⾛技失"的困境,推动知识管理从"被动存储"向"主动赋能"演进

    广西地测院构建“智慧大脑”破解知识管理难题 打造“24小时在线的AI专家” – 工作动态 – 广西壮族自治区自然资源厅网站 – dnr.gxzf.gov.cn


    专业垂直领域应⽤

    医疗健康:基于最新的临床指南、病历记录和医学⽂献,辅助医⽣进⾏诊断、查询⽤药指南。 ⾦融合规与分析:通过分析实时⾦融报告、法律法规、市场资讯,提供投资报告⽣成、财务数据查询等服务。法律法规查询:基于合规要求,检索最新的法规条⽂并辅助⽣成法律⽂书。 ⽐如

    北京⼤学第三医院以DeepSeek⼤模型为技术基座,通过RAG技术实现医学知识的动态检索与知识蒸馏,使模型在医疗场景中的精准度与灵敏度得到显著提升。该系统⾯向医教研、服管控多⻆⾊,完成医⽣⻔急诊、住院⼯作场景的全覆盖,可提供罕⻅病推荐、鉴别诊断、治疗⽅案优化、⼿术规划等智能⽀持。以罕⻅病的早期诊断为典型应⽤场景,RAG系统通过输⼊病历资料给出准确的诊断推荐,对年轻医⽣的临床教学起到关键作⽤

    北京大学第三医院“三院灵智”智能体系发布 开启智能应用新生态

    贵州⼤学依托千万级法律数据库、⾼价值语料库和RAG技术,联合律皓科技发布“法管家”法律⼤模 型,成为国内⾸个通过国家⽹信办“双备案”的法律垂类⼤模型,注册⽤⼾已突破10万。该系统已 在贵州省司法厅、爽贵阳等多个便⺠服务平台实现接⼝接⼊。⽤⼾上传租房合同后,3秒即可提⽰14类⻛险点并⽣成维权建议书,⼤幅降低了普通⺠众获取法律服务的⻔槛。

    “法管家”上线,租房合同风险秒变“纸老虎”!-博爱云


    五.RAG的⼯作机制

    我们先看⼀幅图对RAG整个⼯作过程的全貌有个了解。

    完整的RAG应⽤流程主要包含两个阶段知识库构建和应⽤阶段,知识库构建阶段主要是构建知识的向量化索引,通常是离线的,应⽤阶段根据⽤⼾的输⼊RAG 系统进⾏在线推理,⼀般是在线的服务。下⾯详细介绍⼀下各环节的技术细节和注意事项:


    知识库构建: 数据加载

    将原始数据处理为结构化格式,为后续切换做准备。 常⻅处理逻辑 数据加载不仅仅是读取⽂件,⼀般包含以下处理

    • 数据解析

    ⼀般需要⽀持多模态/多格式数据的读取处理

    • ⾮结构化数据:PDF、Word (.docx)、Markdown、TXT、HTML。
    • 结构化数据:Excel、CSV、SQL 数据库导出。
    • 多媒体数据:图⽚(通过 OCR 提取⽂字)、甚⾄⾳频转录稿。
    • 数据清洗

    原始⽂档往往包含很多噪⾳(不需要考虑的信息)。处理包括:

    • 去除冗余:删掉 HTML 标签、⼴告弹窗⽂字、⻚眉⻚脚。
    • 格式统⼀:将所有格式统⼀转为纯⽂本或 Markdown。
    • 异常处理:处理乱码、修正 OCR 识别错误。
    • 元数据获取

    提取数据中关键信息,例如⽂件名、⻚码、标题、URL、时间等 。


    ⽂档数据的基本分类: ⼤模型看数据和⼈看数据不⼀样,往往分为两类:

    1. 有标记的⽂档

    有标记的⽂档是指在原始⽂本内容基础上,添加了⽤于分类、标注实体或描述结构的特定标签或注解的⽂档。如Word、Markdown、HTML、JSON 等,这些⽂档具有明确的结构,计算机可以直接解析和理解。

    举个例⼦我们⼈看到的CSDN的Markdown⽂档编辑后的⽂章如下

    计算机看到的Markdown⽂档,可以看到有清晰的⼀级标题,⼆级标题,代码块标记

    # 冒泡排序
    冒泡排序是⼀种基础的排序算法,通过重复⾛访数列,⽐较并交换相邻元素,使较⼤元素逐渐“下沉”或
    较⼩元素“上浮”,最终完成排序 。
    ## 算法特性
    时间复杂度:最坏与平均情况为 O(n²),最好情况(已有序且优化)为 O(n)。
    空间复杂度:O(1),属于原地排序,不需要额外存储空间 。
    稳定性:是稳定排序,相等元素的相对位置在排序后不会改变 。
    ## 实现与优化
    基本逻辑:使⽤双层循环,外层控制排序趟数(n-1 趟),内层进⾏相邻元素⽐较与交换 。
    ```
    def bubble_sort(arr):
    """
    冒泡排序(升序)
    :param arr: 待排序列表
    :return: ⽆返回值,原地排序
    """
    n = len(arr)
    for i in range(n – 1):
    swapped = False
    # 每轮把最⼤的元素“冒泡”到最后
    for j in range(n – 1 – i):
    if arr[j] > arr[j + 1]:
    arr[j], arr[j + 1] = arr[j + 1], arr[j]
    swapped = True
    # 如果本轮没有交换,说明已经有序
    if not swapped:
    break
    # ⽰例
    if __name__ == "__main__":
    test_list = [64, 34, 25, 12, 22, 11, 90]
    print("排序前:", test_list)
    bubble_sort(test_list)
    print("排序后:", test_list)
    ```


    2. ⽆标记的⽂档

    ⽆标记的⽂档是指不包含任何⼈为添加的分类标签、实体标注或结构标记的纯原始⽂本内容。如图 像、 PDF 等。这些⽂档缺乏结构信息,计算机⽆法直接理解其内容。 我们以PDF为例,PDF(Portable Document Format,便携式⽂档格式)⽂件由⼀系列绘图指令(如“在坐标 (X,Y) 处放置字符 Z”)构成,⽽不是⽤语义化标签(如 HTML 的 <p> 或 <table> )定义标题、段落、表格等逻辑结构。这使得计算机在解析 PDF 时,难以直接获取其中的结构化信息。数据解析的挑战 我们以PDF为例,来看下解析的困难

    • 1. 结构缺失

    ⽐如PDF的源⽂件码格式显⽰⼀个加粗的Hello PDF,PDF is a widely used format.

    %PDF-1.7
    1 0 obj
    << /Type /Catalog /Pages 2 0 R >>
    endobj
    2 0 obj
    << /Type /Pages /Kids [3 0 R] /Count 1 >>
    endobj
    3 0 obj
    << /Type /Page
    /Parent 2 0 R
    /Resources << /Font << /F1 4 0 R >> >>
    /Contents 5 0 R
    >>
    endobj
    4 0 obj
    << /Type /Font
    /Subtype /Type1
    /BaseFont /Helvetica-Bold
    % 这⾥是实现加粗的关键:指定加粗变体
    >>
    endobj
    5 0 obj
    << /Length 44 >>
    stream
    BT
    /F1 24 Tf
    % 使⽤ 4 号对象定义的字体,字号 24
    50 700 Td
    % ⽂本起始坐标 (x, y)
    (Hello PDF) Tj
    % 绘制字符串
    % 核⼼处理:换⾏ (Td 指令是相对于上⼀个⽂本位置的偏移)
    0 -40 Td
    % 第⼆⾏:切换为普通字体
    /F2 16 Tf
    (PDF is a widely used format.) Tj
    ET
    单独的⽂本流指令:BT (Begin Text), ET (End Text)
    endstream
    endobj
    xref
    0 6
    0000000000 65535 f

    trailer
    << /Size 6 /Root 1 0 R >>
    %%EOF

    实际我们看到的效果,可以看到我们完全没办法推理出来标题和内容,因为PDF主要是来描述如何绘制内容的,⽽我们要的是逻辑结构。(这里新建一个文本文档,把上面的加进去,然后改文件后缀名改为pdf再次打开)


    • 2. 排版复杂

    ⽐如PDF⾥⾯包含了图像,数学公式,⽽且有些表格跨⻚解析也容易出错,还有多栏布局,我们来看⼀些效果.下⾯是PDF⾥⾯的不同的复杂格式

    (1) 分栏

    https://arxiv.org/pdf/2603.06822


    (2)复杂公式


    (3)复杂图像含义

    https://arxiv.org/pdf/2604.07926


    (4) PDF的复杂表格


    • 3. 元素遮挡

    ⽐如印章、⼿写批注、⽔印等覆盖在⽂本上,⼲扰内容识别。


    ⽆标记⽂档数据解析处理思路:

    1. ⽂档预处理

    (1)类型识别与分类:以PDF为例,如果是⽂本型PDF,使⽤普通规则化解析⼯具;如果是扫描件或图⽚型PDF,则需引⼊OCR技术。 (2)版⾯分析与布局理解:使⽤深度学习的模型,⽐如⽬标检测,⾃动识别⽂档中的标题、段落、表格、图⽚等区域理清布局。 (3)重建顺序:识别出元素后,需要重建其正确的逻辑阅读顺序 (4)OCR⽂本识别:使⽤OCR引擎将图像转换为机器可读⽂本


    2. 复杂元素专项处理

    复杂表格、图表、公式专项处理:可以使⽤专⻔的模型识别和处理表格、图标和公式,⽐如合并单元格、跨⻚表格等复杂情况。


    3. 结构化输出与元数据增强 (1)将解析结果统⼀输出为结构化格式,如Markdown或JSON,⽽Markdown这作为模型输⼊⽅式这⽅⾯优势明显

    • ⽂档结构清晰:⽀持多层标题、粗体、斜体、列表、表格、数学公式等,能够完整地表达⽂档的信息。
    • 格式较少,更多关⼼内容:Markdown 关注内容本⾝,⽽⾮排版,符合⼤模型的训练特点。
    • 模型使⽤较多:⼤模型在训练过程中,接触了⼤量的 Markdown 语料,对其有良好的理解能⼒。

    (2)补充⽂件名、标题、作者、章节、⻚码等信息。


    常⻅解析⼯具

    我们来看下常⻅的解析⼯具,如果我们使⽤LangChain或者Llamaindex这些框架他们往往内置了⼀些解析⼯具类,可以直接使⽤,解析可以使⽤的⼯具⾮常多,⼀个项⽬中往往要结合不同的⼯具的优势共同来完成解析任务。

    名称简介特点地址
    MinerU 企业级多模态解析利器 多模型集成,高精度提取 PDF 正文、表格、公式,支持 84 种语言 OCR https://github.com/opendatalab/MinerU
    Docling 企业级文档处理引擎 IBM 出品,模块化设计,表格解析精度高(98%+),与企业 AI 框架集成友好 https://github.com/DS4SD/docling
    Marker 轻量级 PDF 转 Markdown 神器 速度快,专注于将 PDF(含扫描件)转换为 Markdown,对公式和代码块支持良好 https://github.com/VikParuchuri/marker
    Unstructured 最通用的文档预处理库 支持超 50 种文件格式(PDF/Word/PPT 等),智能分区,是构建复杂 ETL 流程的基础 https://github.com/Unstructured-IO/unstructured
    PyMuPDF 高性能 PDF 处理底层库 极速的 PDF 渲染、文本 / 图像提取能力 https://github.com/pymupdf/PyMuPDF
    LlamaParse 专为 RAG 设计的原生解析服务 由 LlamaIndex 出品,解析复杂 PDF(表格 / 图表)精度极高,与 LlamaIndex 生态无缝集成 https://cloud.llamaindex.ai/
    Markitdown 微软开源的万能文档转换器 利用 AI 大模型能力,支持将 Word/Excel/PPT/ 图像 / 音频等几乎所有格式转为 Markdown https://github.com/microsoft/markitdown
    PyMuPDFLoader LangChain 内置的高性能 PDF 加载器 基于 PyMuPDF,速度快,适合快速处理文本型 PDF https://docs.langchain.com/oss/python/integrations/document_loaders/pymupdf
    SimpleDirectoryReader LlamaIndex 的万能目录加载器 最简单的入门方式,自动检测目录下的多种文件格式并加载 https://developers.llamaindex.ai/python/framework/module_guides/loading/simpledirectoryreader/

    实战-论⽂PDF⽂档解析

    我们使⽤百度的PaddleOCR来完成对⽂档的解析,我们找到⼀篇图标,公式都有的论⽂Kimi K1.5: Scaling Reinforcement Learning with LLMs (https://arxiv.org/pdf/2501.12599)

    1. 进⼊官⽹(PaddleOCR – 文档解析与智能文字识别 | 支持API调用与MCP服务 – 飞桨星河社区

    ),点击右上⻆登录注册


    2. 上传PDF进⾏解析,我们选择模型PP-StructureV3来进⾏解析


    3. 服务器处理⼀段时间后,完成解析,左侧为原始⽂件,右侧为解析结果


    4. 查看⽂字解析结果,可以看到⽂字识别准确率极⾼


    5. 查看公式解析结果,可以看到公式的LaTex(⼀种排版系统,⾮常适⽤于⽣成⾼印刷质量的科技和数学类⽂档)⽂本已经⽣成


    6. 查看图⽚解析结果,图⽬前是进⾏了原始图⽚的截取。


    7. 可以看到Paddle OCR⽣成了结构化的输出JSON⽂件


    实战-Word⽂档解析

    1. 我们使⽤商⽤的LlamaParse来进⾏解析Word ,PPT等,我们进⼊官⽹(https://cloud.llamaindex.ai/),使⽤邮箱注册或者直接使⽤⾕歌账号完成登录


    2. 登录成功后,左侧有Parse,我们进⼊Parse模块,这⾥我们输⼊⽂档


    3. 我们自己整一份word,放进去:


    4. 经过⼀段等待后完成解析,可以看到解析的结果还原度很⾼


    5. 我们点击下载可以完成Markdown下载,可以看到复杂的word变成了⼤模型友好的Markdown。


    六.⽂本分块(Chunking)

    ⽂本分块是什么? ⽂本分块(Text Chunking / Splitting),顾名思义,就是将原始的、可能⾮常庞⼤的⽂本资料(例 如,⼀篇⻓篇报告、⼀本电⼦书、⼀个复杂的⽹⻚)通过分割器(Splitter)分割成⼀系列更⼩、更易于处理的⽂本⽚段(Chunks)的过程。

    分块就是在⽣成 Embedding 之前,把⼤段⽂本拆成更⼩语义单元的过程。检索器真正搜索的对象⽽不是整篇⽂档就是这些分块。分块做得好,⽂档中的内容就能被⼲净地捕获,上下⽂得以保留LLM 能做出有意义的推理。分块做得差,语义被割裂检索充满噪声。 我们来看个例⼦,按照8个字符分割下这句话

    西红柿炒鸡蛋是⼀道经典的家常菜,酸甜开胃、做法简单,⽽且营养丰富。

    效果如下


    为什么需要分块?

    • 应对模型限制:⼤语⾔模型(如GPT-4)有上下⽂⻓度限制(例如8K、128K token),超过限制的⽂本⽆法⼀次处理。分块确保了输⼊给 LLM 的每⼀段信息都在其“消化能⼒”范围之内。
    • 提升检索精度:在检索增强⽣成(RAG)系统中,与⽤⼾问题相关的内容往往只存在于⽂本的某个段落中。⽤⼩分块检索,⽐⽤整篇⽂档检索更精准。⽐如你查询论⽂的⼀个⽚段,结果把整个论⽂放过去,⼲扰信息太多了。
    • 降低成本:只把相关块送⼊⼤模型,⽽不是整个⻓⽂本,可减少token消耗。

    ⽂本分块的策略:

    固定⼤⼩分块 固定⼤⼩分块(Fixed-size Chunking),将⽂本按固定⻓度(如字符数或token数)切分,每个块⼤⼩⼀致,可能通过重叠保留上下⽂连贯性。例如,将⽂档每256个字符切分为⼀个块,重叠20个字符以减少边界信息丢失。

    优点:

    • ⽆需复杂算法,代码实现⾼效
    • 块⼤⼩⼀致,便于批量处理和向量化
    • 适合⼤规模⽂本处理,降低计算成本。

    缺点:

    • 语义割裂:可能在句⼦或概念中间切分,破坏上下⽂完整性。
    • 信息冗余:重叠区域可能导致重复存储和计算。
    • 适⽤性受限:对结构化⽂本(如代码、技术⽂档)效果较差。

    ⽰例:

    ⽐如按照6个字符分割效果如下,可以看到语义已经被拆乱了。


    Overlap

    在切分⽂档块(Chunk)时,让相邻的块之间有⼀部分重叠的内容。 优势:语义连贯性好。 ⼏乎不会出现⼀句话被切成两半导致 AI 看不懂的情况。 劣势:冗余度⾼,存储成本增加。 同样的内容存了好⼏遍,浪费数据库空间,检索时也可能搜到重复信息。

    ⽐如我们做⼀个⾼等数学的知识库,需要切分⾼等数学教材,如果你只是死板地每 10 ⻚撕下来装订成⼀份,很有可能⼀个复杂的公式在第 10 ⻚结尾写了⼀半,推导过程却在第 11 ⻚开头。如果我们使⽤滑动窗⼝,每⼀份资料都包含前⼀份资料的最后 2 ⻚。这样当你看到第 11-20 ⻚的内容时,开头还能看到第 9-10 ⻚的衔接内容。


    句⼦分块 句⼦分割是将⼀段连续的⽂本按照句⼦边界(如句号、问号、感叹号、换⾏等)切分成独⽴的句⼦。它需要处理歧义,例如“Mr.”、“Dr.”中的点号不是句⼦结束。

    优点:

    • 简单快速:基于标点符号和规则,计算开销极⼩,实现也简单
    • 保持句内完整性:每个句⼦内部语义完整,不会切断⼀个句⼦的主谓宾结构。
    • 标准化:绝⼤多数语⾔处理任务(分词、词性标注、句法分析)以句⼦为基本单位。

    缺点:

    1. ⽆法合并相关句⼦:语义上紧密相连的多个短句(如“今天很热。开了空调。”)会被分开,丢失上下⽂关联。 2. 对标点错误敏感:⽤⼾输⼊的⽂本缺少句号或误⽤标点会导致分割失败。 3. 处理缩写困难:需要特殊规则识别“U.S.”、“e.g.”等,否则会错误切分。


    ⽰例: 原始⽂本

    Dr. Smith is here. He lives in U.S.A. Is it 3 p.m. already? Let's go!

    分割后的⽂本,注意Dr. 不是句⼦的分割符。

    1. Dr. Smith is here.
    2. He lives in U.S.A.
    3. Is it 3 p.m. already?
    4. Let's go!

    语义分块

    语义分块(Semantic Chunking),根据句⼦、段落、主题等有语义内涵的单位对⽂档进⾏分段创建嵌⼊,如果第⼀个段的嵌⼊与第⼆个段的嵌⼊具有较⾼的余弦相似度,则这两个段形成⼀个块。通过合并相似内容,确保每个块表达完整的语义内容。由于每个分块的内容更加丰富,它提⾼了检索准确性,让⼤模型产⽣更加连续和相关的响应。但是它依赖于⼀个阈值来确定余弦相似度是否显著下降,⽽这个阈值在不同类型⽂档中可能涉及不同的参数设置。

    处理过程如下:⾸先将⽂本拆分为句⼦或段落,把chuank转换为向量,计算相邻单元的相似度,如果在相似度⾼,那么合并,如果不⾼认为是⼀个新的chunk。

    优点:

    • 语义完整性

    保留⾃然语义结构,提升检索准确性。 例如 “苹果是⼀种⽔果。它富含维⽣素C。但‘苹果’也是⼀家科技公司。” 语义分块会依据话题切换,将前两句(⽔果话题)切为⼀个块,第三句(公司话题)切为另⼀个块。

    • 每个块内部逻辑完整,不会把“但”后⾯的转折与⽔果描述强⾏切分。

    减少跨块信息丢失:⽐如“因为温度升⾼导致冰川融化。海平⾯因此上升。沿海城市⾯临威胁。” 固定分块可能把第⼀句切到块A,后两句切到块B。当查询“海平⾯上升的原因”时,块B缺少“温 度升⾼”的原因,块A⼜缺少“海平⾯上升”的结论。语义分块会将这三句作为⼀个完整因果链保 留在同⼀块中。

    • 适应⾃然语⾔结构:

    ⽐如⼀篇游记,先写“上午参观博物馆”,然后另起⼀段写“中午品尝当地美⻝”。语义分块⾃然按照段落和话题转换切分,读起来就像原⽂的⼩章节;⽽固定分块可能把博物 馆段落的最后⼀句与美⻝段落的第⼀句切进同⼀块,造成话题混杂。


    缺点:

    • 计算成本⾼:需要计算句⼦嵌⼊、相似度矩阵,⽐固定⼤⼩分块耗时且消耗资源。
    • 块⼤⼩不统⼀:有的块可能很短(⼀个句⼦),有的可能很⻓(整个段落),可能超过模型上下⽂限制,需要进⼀步处理。
    • 对噪声敏感:⽂本格式混乱、标点错误或话题频繁跳跃时,语义边界检测可能失败。
    • 依赖模型质量:使⽤的嵌⼊模型或分割算法如果不够好,会导致错误切分(如将紧密相关的句⼦分开,或合并⽆关内容)。
    • 实现复杂度较⾼:需要调参(相似度阈值等),⽽固定分块⼏乎零配置。

    ⽰例: 原始⽂本

    我关掉电脑,结束了今天的⼯作。然后⾛进厨房,煮了⼀碗⾯条。

    语义分块结果

    • 块1: 我关掉电脑,结束了今天的⼯作。
    • 块2: 然后⾛进厨房,煮了⼀碗⾯条。

    递归分块

    递归分块(Recursive Chunking),先按主题或段落初步划分,再对超⻓块递归细分,直⾄满⾜⼤⼩限制。递归分块融合了结构化与⾮结构化处理逻辑,与固定⼤⼩的分块不同,这种⽅法保持了语⾔的⾃然流畅性并保留了完整的内容语义。

    优点:

    1. 保持语义边界优先:尽可能按段落、句⼦等⾃然边界切分,避免破坏语义完整性。

    2. ⾃适应块⼤⼩:不会像固定⼤⼩分块那样切断单词或句⼦,也不会像纯语义分块那样产⽣超⼤块。

    缺点:

    1. 对格式依赖性⾼: 如果⽂档本⾝排版混乱(例如:完全没有换⾏符的 PDF 扫描件),递归分块的效果会退化成普通的固定⻓度切分。 2. 缺乏深度理解: 它⽆法感知“话题转换”。如果⼀个⻓段落前半部分在讲 A 话题,后半部分在讲B 话题,只要总⻓度没超标,它就会把它们切在⼀起,导致检索噪⾳。 3. “⻓尾”截断: 如果某⼀个句⼦本⾝就超过了 chunk_size ,递归分块最终还是会粗暴地从某 个空格或字符处切断


    ⽰例:

    原始⽂本

    你好。今天天⽓不错。
    明天会下⾬。

    切分步骤

    块⼤⼩上限为 8 字符:
    第 1 层(按 \\n):块1 = 你好。今天天⽓不错。(12 > 8 ❌)
    第 2 层(对块1按 。):
    块1.1:你好。(4 ≤ 8 ✅)
    块1.2:今天天⽓不错。(8 ≤ 8 ✅)
    块2(明天会下⾬。)⻓度 7 ≤ 8 ✅
    切分的chunk

    你好。 今天天⽓不错。 明天会下⾬。


    基于⽂档结构的分块

    基于⽂档结构的分块(Document Specific Splitting / Structure-Aware Chunking)是指利⽤⽂档本 ⾝的标记语⾔语法(如 Markdown 的 # 、HTML 的 <div> 、LaTeX 的 \\section )或特定的⽂ 件格式属性,将⽂档划分为逻辑独⽴的单元。 它不再简单地追求“块的⼤⼩”,⽽是追求“块的完整性”。每⼀块通常对应⽂档中的⼀个章节、⼀ 个⼦项或⼀个完整的表格。

    这种分块适⽤于⽂档有清晰的结构,但很多时候,⼀个⽂档的结构会⽐想象中复杂,此外,很多时候⽂档章节内容⼤⼩不⼀,很容易超过块的⼤⼩限制,需要结合递归拆分再进⾏合并处理。

    优点:

    • 保持结构完整性:每个分块都对应⼀个完整的逻辑单元(如⼀个章节、⼀个段落),避免了关键信息被切断。
    • 信息组织性强:特别适合法律合同、学术论⽂等对格式和层级有严格要求的⽂档,有助于模型理解上下⽂关系。
    • 提升检索精度:当⽤⼾针对特定章节提问时,基于结构的分块能直接定位到相关逻辑单元,提供更精准的回答

    缺点:

    • 依赖⽂档质量:如果⽂档结构混乱或没有清晰的结构(如纯⽂本⽂档),这种⽅法就⽆法有效应⽤
    • 块⼤⼩可能不均:⽣成的⽂本块⻓度可能差异很⼤,有的块(如⼀个章节)可能过⼤,超出模型输⼊限制
    • 实现有⼀定复杂度:需要⾼质量的⽂档解析器来准确识别标题、段落、表格等元素,实现⽐固定⼤⼩分块更复杂。
    • 解析可能存在误差:对复杂⽂档(如带多层⼦标题)的结构识别可能存在错误,影响最终分块效果。

    ⽰例: 假设我们有⼀份Markdown格式的产品使⽤说明⽂档,内容如下:

    # 智能⾳箱X1使⽤指南
    ## ⾸次设置
    1. ⻓按⾳箱顶部的电源键3秒,等待指⽰灯闪烁。
    2. 在⼿机上下载并打开“SmartLife”App,点击“添加设备”。
    3. 根据App提⽰,输⼊Wi-Fi密码完成配⽹。
    ## 常⻅问题
    ### Q: ⾳箱⽆法连接⽹络怎么办?
    A: 请检查路由器是否正常⼯作,并确保输⼊的Wi-Fi密码正确。
    ### Q: 如何恢复出⼚设置?
    A: 同时按住“⾳量+”和“静⾳”键5秒,听到提⽰⾳后即可完成。

    切分结果

    块 1: 智能⾳箱X1使⽤指南 包含⽂档的⼀级标题及其下属内容。 块 2: ⾸次设置 包含⼆级标题及下⽅的操作步骤列表。 块 3: 常⻅问题 这是⼀个⼆级标题。其下内容由两个三级标题及其回答组成。 块 4: ⽆法连接⽹络 (基于“Q: ⾳箱⽆法连接⽹络怎么办?”) 块 5: 恢复出⼚设置 (基于“Q: 如何恢复出⼚设置?”)


    基于LLM的分块

    基于LLM的分块是指利⽤⼤语⾔模型(如GPT、Claude、Llama)来智能地确定⽂本切分边界的⽅ 法。它不依赖固定分隔符、字符数或预定义规则,⽽是通过向LLM提供提⽰(prompt),让模型根据语义理解、主题连贯性、逻辑结构等因素,⾃主决定在哪⾥切分以及如何合并句⼦。

    优点

    • 语义完整性最强:LLM能理解深层语义、主题转换、逻辑转折,切分结果最符合⼈类认知。
    • 适应复杂⽂档:对于法律合同、学术论⽂、⽂学作品等具有复杂结构或隐含话题的⽂本,效果远超规则⽅法。
    • 可定制化:可以通过提⽰词控制块的⼤⼩、粒度、⻛格(如“每个块包含⼀个完整的论点”)。
    • 处理边界歧义:能正确处理缩写、列表、引⽤等容易让规则分块出错的情况。
    • 合并能⼒强:不仅会切分,还能将多个短句合并成⼀个语义块(区别于句⼦分割)。

    缺点

    • 成本⾼昂:调⽤LLM API需要付费,处理⼤量⽂档时费⽤可观;本地部署也需要GPU资源。
    • 延迟较⼤:LLM推理速度⽐规则⽅法慢⼏个数量级,不适合实时或⼤规模离线处理。依赖提⽰质量:结果对提⽰词⾮常敏感,需要反复调试才能获得稳定、满意的分块。
    • 输出不确定性:LLM的输出具有随机性,导致分块结果不可完全复现。
    • 上下⽂限制:LLM本⾝有输⼊⻓度限制,超⻓⽂本需要先粗切分,可能丢失全局信息。
    • 过度切分或合并:LLM可能错误判断边界,例如将紧密相关的段落分开,或将⽆关内容合并。

    ⽰例 原始⽂本

    养猫可以降低压⼒。研究表明,与猫互动能减少⽪质醇⽔平。猫的呼噜声甚⾄有治愈效果。不过,养猫
    也需要承担责任。你需要定期清理猫砂盆。还要给猫打疫苗和驱⾍。另外,猫可能会抓坏家具。

    提⽰词

    请将以下⽂本按照语义连贯性切分成多个块。每个块应包含⼀个完整的主题。⽤“===”分隔块。只输出
    分块结果。

    分块结果

    养猫可以降低压⼒。研究表明,与猫互动能减少⽪质醇⽔平。猫的呼噜声甚⾄有治愈效果。
    ===
    不过,养猫也需要承担责任。你需要定期清理猫砂盆。还要给猫打疫苗和驱⾍。另外,猫可能会抓坏家
    具。


    ⽂本分块策略选择建议

    1. ⽂档结构清晰(Markdown、HTML、法律合同、论⽂):基于⽂档结构 2. ⽂档话题频繁切换(如新闻聚合、论坛帖⼦、多主题报告):语义分块 3. 构建⾼质量知识库(如专家系统、医疗问答、法律助⼿):择基于LLM分块 4. ⽂档是纯⽂本、来源不可控(⽤⼾上传的TXT、OCR结果),不想引⼊额外模型或API,希望轻量级 实现:递归分块

    具体实施过程中,我们需要根据具体需求与⽂档类型选择分块策略,或组合多种⽅法(如“结构分块+语义细分”)以实现最佳效果。


    实战-在线⽂本分块

    1. 我们使⽤在线分块体验⼯具ChunkViz

    (ChunkViz)来感受下分块,⾸先我们打开⼯具,可以看到分块的⽰例


    2. 我们可以选择不同的分块策略,感受下切分结果


    3. ⽐如我们选择Markdown,配置Chunk为300,可以看到⽂档按照Markdown的格式进⾏了切分。


    4. 我们也可以切换其他的分块⽅式来体验分块的能⼒。


    七.向量嵌⼊(Embedding)

    什么是向量嵌⼊

    向量嵌⼊(Embedding)是将⾮结构化数据(如单词、句⼦、图像或⾳频)转换为⼀列数字(向量)的过程。这个向量是⾼维空间中的⼀个点,并且具有这样的性质: 语义上相似的对象,在向量空间中的距离也更近 。 简单来说,它把复杂的事物(⽐如单词、句⼦、图⽚)转化成“机器能理解的数字”,但这些数字不 仅仅是随便的编码,⽽是带有意义的,⽐如让相似的东西靠得更近。就是⽐如猫、狗、汽⻋都会转成向量

    猫 → [0.95, 0.2] 狗 → [0.90, 0.5] 汽⻋ → [0.05, 0.8]

    通过⼀些距离算法如余弦相似度,欧式距离等经过计算后发现猫和狗很近,但是汽⻋离猫和狗很远。


    相似度计算

    向量嵌⼊中语义相似可以⽤向量空间中的距离来表⽰。语义越相似,两个向量在空间中的距离越近,接下来我们来简单了解下两种常⻅的距离计算⽅式。 余弦相似度 余弦相似度是计算两个向量之间夹⻆的余弦值。余弦距离(Cosine distance)就是⽤1减去这个获得的余弦相似度。

    核⼼特点是只关⼼⽅向,不关⼼⻓度。即使向量⻓度相差百倍,只要⽅向相同,余弦相似度仍为1。


    欧式距离(Euclidean distance)

    简单理解两点之间是指连接这两点的线段的⻓度。

    当然扩展到三维,多维空间欧⽒距离变成了

    如果⽤两个向量表⽰

    核⼼特点同时受⽅向和⻓度影响。两个向量即使⽅向相同,如果⻓度差异⼤,欧⽒距离也会较⼤。


    点积距离(Dot Product)

    代数上:

    dot product,或者内积 inner product(更宽泛的⼀种运算),定义为两个向量对应位置元素乘积的 总和。

    假设我们有两个向量。这⾥直接简单地写成了⾏的形式:

    v = [2, 4, 6]
    w = [1, 3, 5]
    v . w = (2 x 1) + (4 x 3) + (6 x 5) = 2 + 12 + 30 = 44

    点积的取值范围从负⽆穷到正⽆穷,负值表⽰⽅向相反,正值表⽰⽅向相同,当向量垂直时为0。点积值越⼤表⽰相似性越⼤。 ⼏何上:

    两向量的点积:A⋅B可以理解为向量A在向量B上的投影再乘以B的⻓度。

    当你在向量数据库中看到点积得分很⾼时,想象⼀下其中⼀个向量在另⼀个向量⽅向上延伸得很远,且夹⻆很⼩,这便是“语义接近”的⼏何体现。夹⻆⼩可以理解为⽅向⼀样和模⻓(这件事聊得深不深/重不重要),即使⽅向完全⼀致,点积的⼤⼩依然取决于两者的⻓度,可以理解为延伸得很远。


    距离算法的选择

    总体来说,欧⽒距离体现数值上的绝对差异;⽽余弦距离体现⽅向上的相对差异;点积距离同时考虑⽅向和模⻓。 (1)例如,统计两部剧的⽤⼾观看⾏为,⽤⼾A的观看向量为(0,1),⽤⼾B为(1,0);此时⼆者的余弦距很⼤,⽽欧⽒距离很⼩;我们分析两个⽤⼾对于不同视频的偏好,更关注相对差异,显然应当使⽤余弦距离。 (2)当我们分析⽤⼾活跃度,以登陆次数(单位:次)和平均观看时⻓(单:分钟)作为特征时,余弦距离会认为(1,10)、(10,100)两个⽤⼾距离很近;但显然这两个⽤⼾活跃度是有着极⼤差异的,此时我们更关注数值绝对差异,应当使⽤欧⽒距离。 (3)⽐如我们使⽤⾕歌搜索苹果⼿机,⼀个⽂档写的苹果⼿机很详细,⼀个写的苹果⼿机很简单,还有⼀个是写的苹果这种⽔果,那么我们给⽤⼾优先推荐的应该是写的苹果⼿机很详细的这个⽂章,不仅⽅向⼀样,⽽且模⻓(详细)很⼤。


    实战-感受下距离

    1. 了解下Google Embedding Projector

    Google Embedding Projector 是⼀个开源的可视化⼯具,专⻔⽤于交互式地查看和分析⾼维数据 (如向量嵌⼊)。由于⼈类⽆法直觉地理解成百上千维的空间,这个⼯具通过降维算法将复杂的向量映射到 3D 或 2D 空间中。提供了在线操作⽹址https://projector.tensorflow.org/


    2. 我们打开官⽹(https://projector.tensorflow.org/),可以看到进去默认是Word2Vec数据集的可 视化


    3. 我们在右侧输⼊cat,点击确定


    4. 点击后,默认使⽤余弦相似度计算距离,dog和cat的距离还是⽐较近的,左侧的三维图像也可看到


    5. 使⽤欧式距离再观察下,可以看到cat和dog的距离也很近。


    向量嵌⼊的核⼼特点

    语义相似性 语义相似指的是两段⽂本在表达的意思、意图或内涵上相近,⽽不仅仅是在字⾯⽤词上相同。⽐如“猫坐在垫⼦上”和“⼀只⽑茸茸的猫咪在垫⼦上休息”字幕相似度很低,但是语义相似度很⾼。语义相近的⽂本在向量空间中彼此靠近(余弦相似度⾼或欧⽒距离⼩);语义不同的⽂本远离。我们已经观察了猫和狗相似性,此处不再赘述。 可计算 向量嵌⼊最强⼤的能⼒之⼀,是⽀持代数运算。经典的例⼦是: 向量(国王) – 向量(王后) ≈ 向量(男⼈) – 向量(⼥⼈) 。这意味着模型能捕捉并执⾏“类⽐推理”。

    国王 – 男⼈ + ⼥⼈ = ⼥王”在数学上的争议,但这种⽅向性偏移在局部依然是真实存在的,在⼀个好的嵌⼊模型中,“中国”到“北京”的⽅向向量,与“德国”到“柏林”的⽅向向量,在⽅向上是⾮常接近的。


    低维稠密(Low-dimensional Dense) 相⽐于传统的独热(one-hot)编码(极⾼维且稀疏),嵌⼊是 低维且稠密 的。例如,词表⼤⼩10万,one-hot是10万维(只有⼀个1,其他都是0),⽽嵌⼊通常只有128~1024维,且每个元素都是实数。这⼤⼤降低了计算和存储成本,同时保留了丰富的语义信息。 下⾯我们看个例⼦来感受下: One Hot编码 独热编码为每个类别分配⼀个向量,该向量中只有⼀个位置是 1(“热”),其余所有位置都是 0 (“冷”)。⽐如下⾯的宠物的独热编码

    向量嵌⼊ 向量嵌⼊每个单元格都是具体的实数,相当于⽤很多⻆度来描述这些宠物,⽐如哺乳动物,陆地还是⽔⽣,体型怎么样,对⽐独热编码很短(低纬),数据都是实数,⽐独热编码稠多了。


    跨模态处理

    ⽆论是⽂本、图像、⾳频还是⼆进制代码,最终都可以被转换为同样维度的向量。 这意味着我们可以计算⼀张“猫的照⽚向量”与⼀段“‘猫’的⽂字向量”之间的距离。如果它们距离很近,机器就实 现了“理解”:它知道这段⽂字描述的就是这张图⽚。


    嵌⼊模型 嵌⼊模型(Embedding Model)就是具体的模型,它把⽂字、图⽚、声⾳这些⼈类能理解的东西,转换成计算机能理解和计算的向量。 如果你把向量嵌⼊⽐作不同的语⾔译本(有英⽂译本、中⽂译本、盲⽂译本),那么嵌⼊模型就是⽣产这些译本的翻译机。


    嵌⼊模型排⾏榜

    1. MTEB

    Embedding模型排⾏榜可以在https://huggingface.co/spaces/mteb/leaderboard中找到:

    以上模型排⾏榜的评估标准是MTEB(Massive Text Embedding Benchmark)是嵌⼊模型的评估基准。 论⽂地址:[2210.07316] MTEB: Massive Text Embedding Benchmark


    2. C-MTEB

    MTEB则是专⻔针对中⽂⽂本向量的评测基准,被公认为是⽬前业界最全⾯、最权威的中⽂语义向量评测基准之⼀,涵盖了分类、聚类、检索、排序、⽂本相似度、STS等6个经典任务,共计35个数据集,为深度测试中⽂语义向量的全⾯性和可靠性提供了可靠的实验平台。阿⾥、腾讯、商汤、百川等多家⼚商在此榜单测评发布模型。

    https://huggingface.co/spaces/mteb/leaderboard筛选语⾔


    向量嵌⼊的常⻅模型

    模型名称嵌入数据类型特点链接地址
    Qwen3-Embedding 文本 基于 Qwen3 底座,专为文本表征与检索优化,提供 0.6B/4B/8B 三种尺寸,性能较上代提升 40% https://huggingface.co/Qwen/Qwen3-Embedding-8B
    Youtu-Embedding 文本 腾讯优图开源参数模型,支持检索、分类、聚类等多任务 https://huggingface.co/tencent/Youtu-Embedding
    OpenAI text-embedding 文本 OpenAI 旗舰模型具备动态语义编码能力 https://developers.openai.com/api/docs/guides/embeddings
    CLIP 多模态(图文) OpenAI 经典双塔架构模型,通过对比学习对齐图像和文本,支持零样本跨模态检索。 https://openai.com/index/clip/
    Qwen3-VL-Embedding 多模态(图文 / 视频) 开源多模态向量模型,将视觉与文本映射到同一语义空间,支持 30+ 语言 https://huggingface.co/Qwen/Qwen3-VL-Embedding-8B
    tongyi-embedding-vision-plus 多模态(图文 / 视频) 阿里云商用多模态模型,基于 Qwen3 底座,支持多分辨率、多维度输出 https://help.aliyun.com/zh/model-studio/models?spm=a2c4g.11186623.help-menu-2400256.d_0_2.39083ba2wRklln
    F2LLM 文本 / 代码 蚂蚁集团联合上海交大开源,全尺寸家族(80M-14B),支持 282 种语言和 40+ 种代码 https://github.com/codefuse-ai/CodeFuse-Embeddings/tree/main
    Word2Vec 文本 作为首个大规模实用化的词嵌入模型,Google 提出的 Word2Vec 开创了 “用向量表示词义” 的范式。 https://code.google.com/archive/p/word2vec/
    BERT 文本 BERT(Bidirectional Encoder Representations from Transformers)的出现标志着 embedding 技术进入 “深度语义理解” 时代。其核心突破是用双向 Transformer 替代 LSTM,并通过创新的预训练任务学习深层语义。 https://github.com/google-research/bert
    BGE 文本 北京智源人工智能研究院(BAAI)2023 年 8 月推出的中英英文语义向量模型。(注意有多款模型) https://huggingface.co/BAAI/bge-large-zh-v1.5

    实战-⽂本向量嵌⼊

    1. 我们来通过实战来感受下⽂本嵌⼊到底是怎么⼯作的,实战的架构如下


    2. 启动LMStudio,进⼊模型搜索⻚⾯,我们搜索 QWen的Embedding模型

    LMStudio:跨平台桌面 GUI 软件,在自己电脑本地离线跑开源大模型,不用敲复杂命令,Windows/Mac/Linux 都支持.。底层基于 llama.cpp,主要跑 GGUF 量化模型。

    LM Studio 是本地大模型的一站式工作台,可以本地跑 LLM、提供 API 接口,用来搭建本地 RAG、本地 Agent CLI,不用依赖云端大模型,所有推理在本机完成,数据不外流。


    3. 点击下载模型,等待下载完成,我们根据电脑配置选择,这次我选择最⼩的0.6B模型


    4. 进⼊模型管理界⾯,左侧筛选⽂本嵌⼊模型


    5. 点击加载模型,完成模型加载


    6. 查看服务状态确保启动


    7. 这个时候服务已经运⾏了,我们启动Postman,新建⼀个HTTP请求


    8. 回到LM Studio 点击CURL按钮进⾏拷⻉


    9. 拷⻉内容输⼊到Postman(前面的文章有介绍)的编辑框中,会⾃动进⾏识别


    10. 我们把input的内容改成我们想要进⾏向量化的⽂本,⽐如⽐特就业课


    11. 点击send按钮,触发请求


    12. 可以看到请求结果⽣成了⼀个Embedding向量


    八.数据⼊库

    数据库是什么 数据库(Database)是存放数据的仓库。它的存储空间很⼤,可以存放百万条、千万条、上亿条数据。但是数据库并不是随意地将数据进⾏存放,是有⼀定的规则的,否则查询的效率会很低。当今世界是⼀个充满着数据的互联⽹世界,充斥着⼤量的数据。即这个互联⽹世界就是数据世界。数据的来源有很多,⽐如出⾏记录、消费记录、浏览的⽹⻚、发送的消息等等。除了⽂本类型的数据,图像、⾳乐、声⾳都是数据。 数据库管理系统(DBMS)是⽤于管理数据库的软件,通过接⼝或者某些语⾔(如SQL)实现数据的增删改查(CRUD)。 举个例⼦,我们可以把数据库想想为⼿机⾥的“通讯录”

  • 通讯录⾥实际保存的所有联系⼈信息(姓名、电话、地址等),就像⼀本写满了记录的笔记本。数据库就是存放这些原始数据的地⽅。
  • DBMS就是你⼿机上那个⽤来管理通讯录的软件(⽐如 iOS 的“通讯录”App 或 Android 的“联系⼈”应⽤)。
  • 增删改查就是通过APP对通讯录的操作
    • 增:新建⼀个联系⼈“张三,138****0000”
    • 删:删除⼀个过时的联系⼈
    • 改:把张三的电话号码改成新号码
    • 查:搜索“张三”找到他的电话

    向量数据库是什么 向量数据库是⼀种专为⾼效存储、索引和查询⾼维向量数据⽽设计的数据库系统。它通过将⾮结构化数据(如⽂本、图像、⾳频、视频)转化为数值向量(Embeddings),实现基于语义相似性的快速查找,⽽⾮传统的关键字匹配。它是⽀撑AI⼤模型(LLM)和语义搜索的核⼼基础设施。 简单说就是存放向量的数据库。

    向量数据⼊库是什么

    把⾮结构化数据(⽂本、图像等)转化的固定⻓度的浮点数数组(向量),然后把这些向量连同原始数据、元数据⼀起存储到向量数据库中。

    为什么需要⼊库

    • ⾼效检索:普通数据库⽆法对向量做近似最近邻搜索。向量数据库内置了专⻔的索引(如 HNSW、IVF),能在百万、亿级向量中快速找到最相似的 Top-K 个结果。怎么理解呢?⽐如警察局有⼀张模糊的嫌疑⼈照⽚,需要从全市1000万⼈的⾝份证照⽚库中,找出最相似的10张脸,如果这些数据在Excel⾥⾯,“眼睛颜⾊=棕⾊”、“⿐⼦⾼度=2.5cm”,但是其他脸⻓得像你怎么匹配呢,⽽向量数据库提前把每张⼈脸照⽚转换成⼀个⼈脸特征向量(⼏百个数字)。当你输⼊模糊照⽚,也转成向量,能在秒级内找出最相似的Top-10向量,即使有千万张也很快。

    • 持久化管理:避免每次查询都重新对所有⽂档做 Embedding,⼊库后数据持久化,⽀持增删改查、版本管理。

    这就像我们⼿机上的照⽚⼀样,拍照后只要我们不删除,照⽚是不会消失的。

    ⼊库时的典型结构 ⼊库的典型数据包如下:

    • 向量:Embedding 模型输出的数值数组(例如 768 维或 1536 维的 float 列表)。
    • 元数据:来源⽂件、⻚码、时间戳、作者等,⽤于过滤或展⽰。
    • 原始⽂本块:向量对应的原⽂⽚段(⽤于最终送给⼤模型⽣成答案)。
    • 唯⼀ ID:⽤于快速定位和更新。

    常⻅的向量数据库

    数据库名称简介官网开源地址
    Milvus 为大规模相似性搜索设计的云原生向量数据库。支持 CPU/GPU 异构计算,可扩展至数十亿向量,是生产级应用的热门选择 https://milvus.io/zh https://github.com/milvus-io/milvus
    腾讯云向量数据库(Tencent Cloud VectorDB) 腾讯自研的企业级分布式向量数据库服务,可处理十亿级向量,满足毫秒级实时更新,并提供全套 AI 集成方案 https://cloud.tencent.com/product/vdb
    火山引擎向量数据库(VikingDB) 字节跳动旗下的高性能向量数据库,支持多模态向量化存储与检索,可实现百亿级向量的毫秒级检索 https://www.volcengine.com/product/vikingdb
    向量检索服务 DashVector 基于阿里自研引擎 Proxima 的全托管云原生向量数据库,专为大模型、多模态检索等场景设计,可与通义千问等 AI 服务无缝集成 https://www.aliyun.com/product/ai/dashvector
    向量检索服务 Milvus 版 全托管、100% 兼容开源 Milvus 的云服务,在开源版基础上增强了稳定性和可扩展性,方便自建集群迁移上云 https://www.aliyun.com/product/milvus
    Zilliz Cloud 由 Milvus 原厂打造的全托管 SaaS 及 BYOC 服务,提供开箱即用、深度优化的 Milvus 体验,并具备智能运维能力 https://www.zilliz.com.cn/
    Pinecone 全托管的无服务器向量数据库,以易用性、高性能和自动扩展能力著称,是快速上线生产应用的流行选择 https://www.pinecone.io/
    ElasticSearch 老牌分布式搜索引擎,通过插件支持向量检索,可实现 “关键词 + 语义” 的混合搜索 https://www.elastic.co/ https://github.com/elastic/elasticsearch
    PGVector pgvector 是 PostgreSQL 的开源扩展,使其原生支持向量数据类型和相似性搜索,适合希望统一操作型数据和向量数据的团队 https://www.postgresql.org/ https://github.com/pgvector/pgvector
    Redis 通过 RediSearch 模块支持向量检索,可利用其内存存储实现亚毫秒级低延迟搜索,适合高吞吐、实时性要求高的场景 https://redis.io/ https://github.com/redis/redis
    Chroma AI 原生的开源嵌入式数据库,为 LLM 应用打造,能轻松集成到 LangChain 等框架中。API 简单易用,尤其适合快速原型开发 https://www.trychroma.com/ https://github.com/chroma-core/chroma
    MongoDB 通过 Atlas Vector Search 功能支持向量搜索,允许开发者在熟悉的文档模型中对向量数据进行索引和查询 https://www.mongodb.com/ https://github.com/mongodb/mongo
    Qdrant 一款高性能的开源向量数据库,采用 Rust 开发,支持二进制量化技术。它提供多种索引策略和向量混合搜索功能,能够实现极高的性能(RPS>4000)和低延迟搜索。Qdrant 特别适合性能敏感应用、高并发场景以及中小规模部署 https://cloud.qdrant.io/ https://github.com/qdrant/qdrant
    weaviate 一款支持 GraphQL 的 AI 集成向量数据库,提供 20+AI 模块和多模态支持。它采用 GraphQL API 设计,支持 RAG 优化,特别适合 AI 开发、多模态处理和快速开发场景。Weaviate 具有活跃的社区支持和易于集成的特点 https://weaviate.io/developers/weaviate/ https://github.com/weaviate/weaviate

    本地原型 / 学习、小体量 RAG(入门首选)

    • Chroma:嵌入式,开箱即用,LangChain/LlamaIndex 集成最好,适合本地 demo,不适合海量数据
    • PGVector:复用 Postgres,一套库同时存业务数据 + 向量,熟悉 SQL 团队优先,数据量中等
    • Qdrant:轻量开源,Rust 高性能,本地部署简单,中小规模高并发场景

    2. 生产级大规模向量检索(企业、十亿级向量)

    • Milvus:开源标杆,扩展性强,支持 GPU,大规模 RAG 主流选型;Zilliz Cloud 是 Milvus 原厂托管云
    • 腾讯 VDB、火山 VikingDB、阿里 DashVector:国内云厂商托管向量库,开箱即用,自带国内大模型生态,不用自己运维
    • Pinecone:海外主流全托管向量库,Serverless,海外项目快速上线

    3. 存量数据库改造,不想新增独立组件

    • ElasticSearch:已有 ES 集群,需要关键词 + 向量混合检索
    • Redis:追求极低延迟、高吞吐实时检索,向量规模不宜过大
    • MongoDB Atlas Vector Search:业务本身在用 MongoDB,直接增加向量检索能力

    做 Demo 选 Chroma;中小项目选 PGVector/Qdrant; 大规模生产选 Milvus;云上直接用各大厂商托管向量库; 已有数据库,优先在 ES/Redis/Mongo 上扩展向量能力。


    实战-向量数据库数据操作

    我们体验下向量数据库的完整操作,对向量数据⼊库有⼀个宏观的了解。使⽤使⽤milvus数据库进⾏操作

    1. 进⼊官⽹https://milvus.io/zh,点击开始使⽤,注意milvus的云上版本叫Zilliz Cloud,社区也提 供了Milvus Lite(在笔记本/笔记本电脑上运⾏),Milvus Standalone(⽤于⽣产或测试的完整向 量数据库,百万级)和Milvus Distributed(企业级⽔平扩展以处理数⼗亿个向量)。


    2. 我们可以注册或者直接使⽤⼯号完成登录


    3. 输⼊验证码


    4. 输⼊个⼈信息


    5. 登录进去后可以看到管理后台,默认会创建好⼀个组织

    注意不要删除,免费计划只能1次使⽤


    6. 创建完成组织以后,我们进⼊到组织管理,组织主要是⼈员管理,组织⾥⾯默认创建好了项⽬


    7. 项⽬下⾯我们需要创建⼀个集群,我们选择Free Plan


    8. 会⽣成⼀个⽤⼾名和密码,注意只有1次,我们下载保存


    9. 等待状态变为Running


    10. 我们创建⼀个Collecion,我们的数据都是放到这个集合⾥⾯的


    11. 刚建好数据是空的


    12. 我们点击插⼊数据进⼊到数据API操作⻚⾯


    13. 接⼝功能如下

    Vector Operations (V2) | Zilliz Cloud Developer Hub

    a. Insert Data:插⼊数据 b. UpSert Data: 更新数据 c. Delete Data: 删除数据 d. Query Data: 通过查询条件检索 e. Search Data: 向量相似度检索 f. Hybird Search(混合检索):此操作基于向量相似性、过滤条件搜索实体,并使⽤指定的策略对结果进⾏重新排序。 g. Get Data: 按照id检索


    14. 我们对向量数据库的CRUD进⾏操作,直观感受下。我们选择 Insert Data,可以看到默认随机造好了⼀组向量,这个向量就是我们的那个Embedding向量嵌⼊的输出

    {
    "collectionName": "bite",
    "data": [
    {
    "primary_key": 3,
    "vector": [
    0.19957012762393778,
    0.7593638181507967,
    0.07930106157112249,
    0.13013780895307947,
    0.15280594043530482,
    0.22755604066243673,
    0.5398079720143641,
    0.7713481737744752,
    0.40183703762284817,

    0.22634526972689595,
    0.3582652296101356
    ]
    }
    ]
    }


    15. 点击Run之后,显⽰成功,可以看到数据进⼊了我们向量数据库


    16. 我们点击Data,可以看到数据已经进⼊


    17. 我们多次点击insert data,多插⼊⼏次数据


    18. 我们按照id查询


    19. 也可以按照向量查询


    20. 我们通过upset指定主键可以按照id更新数据


    21. 最后通过Delete Data可以通过Delete删除数据


    22. 删除后看数据3已经消失了


    实战-⽀持Embedding的向量数据库

    1. 上⾯通过zilliz感受到了向量⼊库,这次我们使⽤另外⼀个向量数据库感受下,这个向量数据库将 Embedding Model已经集成了,我们使⽤Pinecone来感受下,进⼊官⽹The vector database to build knowledgeable AI | Pinecone


    2. 我们点击Sign up来完成注册


    3. 输⼊验证码后完成注册


    4. 选择我们的⽬的,个⼈使⽤


    5. 我们跳过调研


    6. 可以看到默认会创建⼀个组织和Default的Project


    7. 然后进⼊到数据库Database,这⾥管理Collection 对应的是index,我们create index创建⼀个


    8. 可以看到创建的时候我们可以选择嵌⼊模型,也就是说嵌⼊这个过程⾃动完成了,⽽且可以看到嵌⼊模型的距离算法是cosine

    pinecone的这个嵌⼊模型使⽤的是点积


    9. 下⾯是云和区域的设置,我们单击创建


    10. 可以看到Index创建成功了


    11. 我们点击设置数据


    12. 我们输⼊⼀些记录


    13. 录⼊后效果


    14. 我们同样可以有不同的检索⽅式


    15. ⽐如安装id检索


    16. 安装向量检索


    17. 同样也有编辑和删除能⼒,可以对记录进⾏操作。


    九.应⽤阶段

    回顾下检索的流程如下

    数据检索 检索过程可以概括为:将⽤⼾查询与知识库中的相关⽂档⽚段进⾏匹配,并召回最相关的内容。具体步骤如下:


    ⽤⼾查询 ⽤⼾查询(User Query)是⽤⼾在检索系统或对话系统中输⼊的原始问题、指令或关键词,⽤于表达其信息需求。在 RAG 系统中,它是整个检索与⽣成流程的起点。简单来说就⽤⼾向应⽤发起提问。⽐如我们问⼀个AI应⽤的内容就是⽤⼾查询,例如我们问公司的AI助理,“公司新发布的休假政策是什么?”


    查询向量化

    ⽤⼾输⼊问题后,系统使⽤与索引阶段相同的嵌⼊模型将查询⽂本转换为向量表⽰,使其与知识库中的⽂档向量处于同⼀语义空间。这个步骤和我们将语句块转为向量化的过程⼀样,我们不再重复赘述。


    向量检索

    将⽤⼾查询转换为向量后,系统需要在向量数据库中快速找到语义最接近的⽂本块。这个过程本质上是向量相似度检索,⽤搜索算法检索查询向量与库中所有向量的 “距离”,距离越近,语义越相似。距离之前我们已经介绍过了,这⾥就不重复介绍了。


    我们来看下检索算法,⾸先我们

    KNN(K-Nearest Neighbor) KNN是个暴⼒搜索的过程

    • ⼯作流程:

    想象你在⼀个派对上,想通过⼀个⼈的⾐着打扮来判断他的职业。KNN 的逻辑如下: a. 确定 k 值: 决定看周围⼏个邻居(⽐如 k=3)。 b. 计算距离: 计算你和派对⾥每个⼈的“距离”(在算法⾥通常是欧⼏⾥得距离)。 c. 找邻居: 找出离你最近的 3 个⼈。 d. 少数服从多数: 如果这 3 个⼈⾥有 2 个是程序员,1 个是设计师,那么算法就判定你也是程序员。

    KNN的缺点⽐较明显, 每次预测都要计算和所有已知点的距离。如果数据量达到百万级,速度会慢得让⼈抓狂。


    ANN(Approximate Nearest Neighbor)

    Approximate Nearest Neighbors(近似最近邻)牺牲微⼩的精度换取指数级的速度提升。

    • ⼯作流程:

    a. 建索引:提前把数据库⾥的向量建成⼀张导航地图(⽐如 HNSW 图)或者分类⽂件夹(⽐如IVF 聚类)。 b. 查询:查询向量 Q 来了之后,只在地图的⼀⼩⽚区域⾥找,不去管数据库另⼀头⼋竿⼦打不着的向量。

    想象你要在⼀座藏书 500 万册的图书馆⾥,找⼀本和你⼿⾥这本内容最像的书。KNN 的做法是把 500万本书从架⼦上全部搬下来,⼀本⼀本翻⽬录对照,耗时数年但能找到绝对最像的那本。⽽ ANN 是先看⼀眼图书馆楼层导航图,直接冲到 “计算机类 / 四楼”,只在那⼏百本书⾥细挑,两分钟就找出三本内容⼏乎⼀样、⾁眼根本分不出差别的书来。


    提⽰词增强(Augmented)

    如果说R(Retrieval,检索)是“找资料”,G(Generation,⽣成)是“写答案”,那么 A(增强) 就是“把资料和问题揉在⼀起,喂给模型,并告诉模型怎么⽤”的那个核⼼过程。 “增强”了什么东西? “增强”不是简单地把问题和检索到的⽂本块粘在⼀起。它通常包含三个关键动作:

    1. 知识补全: 将⼤模型原本不知道的私域数据、实时新闻或⻓⽂本细节补充进 Prompt(提⽰词)。 2. 约束⾏为:明确告诉LLM:“请基于下⾯提供的【参考内容】来回答,不要使⽤你⾃⼰的知识。” 3. 格式化:把检索到的多个⽂本块(可能格式各异)转换成LLM(⼤语⾔模型)最容易理解和遵循的统⼀格式

    “增强”的基本步骤

    1.提⽰词模板化 (Prompt Template) 系统会将你的“原始问题”和“搜索到的⽂本块”填⼊⼀个预设的模板中。 ⽐如系统后台预设的模板如下:

    你是{⻆⾊名称}。请根据以下提供的【参考上下⽂】回答⽤⼾的问题。
    【参考上下⽂】:
    {检索到的⽂本块 1}
    {检索到的⽂本块 2} …
    【⽤⼾问题】:
    {⽤⼾提问内容}
    【回答要求】:
    请⽤专业且亲切的⼝吻回答,如果⽂档中未提及补贴⾦额,请提⽰⽤⼾咨询财务部。


    2. 上下⽂压缩与过滤 (Optional but Recommended) 有时候检索回来的东西太多(⽐如找回了 10 个⽂本块,但模型处理不了这么⻓),“增强”环节会对这些块进⾏重排序(Reranking)或者摘要提取,只留下相关度最⾼的。 ⽐如搜索的原始⽂本块

    员⼯连续服务满 1 年后可享受年假。
    具体标准:
    服务 1 年以上不满 5 年的,每年 10 个⼯作⽇;
    服务 5 年以上不满 10 年的,每年 15 个⼯作⽇;
    服务 10 年及以上的,每年 20 个⼯作⽇。
    年假需在当年内使⽤,最多可结转 10 个⼯作⽇⾄次年 3 ⽉底,逾期作废。
    离职时,未休年假按⽇基本⼯资的 300% 补偿(含正常⼯资,实际额外⽀付 200%)。

    摘要后的⽂本块

    年假:⼯龄 1-5 年 10 天,5-10 年 15 天,10 年以上 20 天。可结转 10 天,离职按3倍结算。


    3. ⻆⾊设定 (System Instruction) 在 Prompt 中加⼊指令,明确告诉模型:你是基于参考资料的助⼿。

    “你现在是 ‘⽐特科技 HR 政策专家’。
    忠实原则: 你只能依据给定的【参考上下⽂】回答。如果上下⽂中没有提到具体的数额,绝对严禁引
    ⽤你记忆中的通⽤知识,只能回答‘公司暂未公⽰’。

    当然增强的步骤不是固定的要根据业务具体情况来进⾏专⻔的处理。


    举个例⼦ 1. ⽐如我们设计⼀个客服助⼿,可以查询⽤⼾的订单和公司的正常回复客⼾,⽤⼾问题如下

    我的笔记本电脑保修期是多久?


    2. 我们从库⾥⾯召回了下⾯的内容

    ⽂本块A:本公司消费级笔记本电脑享受⾃购买之⽇起2年的有限硬件保修。
    ⽂本块B:订单号#12345,产品型号X1 Carbon,购买⽇期2023年1⽉15⽇。
    ⽂本块C:我上次修电脑说只保1年,太坑了。


    3. 进⾏增强,完成格式化,完成要求,并且去除了⽆⽤的⽂本块

    【系统指令】
    你是⼀个专业的客服助⼿。你必须严格根据下⾯【参考内容】中的信息回答问题。
    – 如果【参考内容】中没有答案,请直接说“找不到相关信息”。
    – 如果【参考内容】中存在⽭盾,请优先采⽤来⾃官⽹政策或订单记录的信息。
    – 不要使⽤你预训练知识中的任何保修政策信息。
    – 回答要简洁、肯定。
    【参考内容】
    1. (来源:官⽹政策) 本公司消费级笔记本电脑享受⾃购买之⽇起2年的有限硬件保修。
    2. (来源:⽤⼾订单记录) 订单号#12345,产品型号X1 Carbon,购买⽇期2023年1⽉15⽇。
    【⽤⼾问题】
    我的笔记本电脑保修期是多久?
    【回答格式】
    根据您的订单记录和公司政策,您的答案是:


    4. 如果直接拼接,效果如下

    问题:我的笔记本电脑保修期是多久?
    资料:
    ⽂本块A:本公司消费级笔记本电脑享受⾃购买之⽇起2年的有限硬件保修。
    ⽂本块B:订单号#12345,产品型号X1 Carbon,购买⽇期2023年1⽉15⽇。
    ⽂本块C:我上次修电脑说只保1年,太坑了。
    请回答。

    LLM可能会被⽂本块C误导,或者混⽤信息,给出“保修期可能是1到2年”这样模糊甚⾄错误的答案。


    LLM⽣成

    LLM 将进⼊“知识拼图”环节,把⽤⼾问题与精选出来的⽂本块按“提⽰模板(Prompt Template)”组合,⽣成融合外部知识的精准回答。

    LLM 核⼼作⽤如下:

    • 融合检索信息:将检索模块返回的多个⽂本⽚段与原始查询(或对话历史)进⾏整合。
    • ⽣成最终输出:以⾃然语⾔形式⽣成答案、摘要、解释等,⽽不是简单地返回检索到的原⽂。
    • 处理不确定性:当检索结果不完整或⽭盾时,利⽤模型⾃⾝的知识进⾏合理推断或指出信息不⾜。
    • 保持⻛格与流畅性:确保输出符合预期的语⽓、格式和语⾔习惯。
    • ⽐如⽤⼾问:“我买的笔记本电脑⽤了13个⽉,屏幕坏了,能免费保修吗?”

    检索到信息如下:

    ⽚段 A:“本品牌电脑整机免费保修12个⽉,主要部件(主板、CPU、内存、屏幕)免费保修24个⽉。”
    ⽚段 B:“屏幕属于主要部件,保修期24个⽉,但需排除⼈为损坏。”

    ⽣成结果

    “您的电脑⽤了13个⽉,虽然整机保修(12个⽉)已经过了,但屏幕属于主要部件,保修期是24个⽉,
    所以屏幕本⾝可以免费保修。不过需要确认不是⼈为损坏(⽐如摔裂、进⽔)。”


    实战-使⽤Dify创建⼀个知识库聊天机器⼈

    1. 了解下Dify

    Dify 是⼀个⽤于构建 AI 应⽤程序的开源平台。Dify融合了后端即服务(Backend as Service)和 LLMOps理念。它⽀持多种⼤型语⾔模型,如Claude3、OpenAI等,并与多个模型供应商合作,确保开发者能根据需求选择最适合的模型。Dify通过提供强⼤的数据集管理功能、可视化的Prompt编排以及应⽤运营⼯具,⼤⼤降低了AI应⽤开发的复杂度。 简单点说 ,Dify 就是⼀个“AI 乐⾼积⽊⼯⼚”, 就像拼乐⾼,Dify 把AI的各种能⼒(理解话、查⽂ 档、写代码、查天⽓)做成了积⽊块。你只需要像连连看⼀样把它们连起来,⼀个AI应⽤就⽣成了。以前做AI应⽤要写成百上千⾏代码,现在在 Dify 界⾯上“拖拉拽”就⾏,只要会⽤电脑,就能做出个性化的AI机器⼈。


    2. 接下来我们完成⽤⼾注册,进⼊官⽹

    https://dify.ai/zh,点击⽴即开始


    3. 我们输⼊邮箱或者直接使⽤⾕歌账号完成登录


    4. 登录以后我们进⼊到⼯作区,我们选择知识库,我们需要先创建⼀个知识库,然后才能使⽤知识库


    5. 我们选择通过流⽔线创建知识库


    6. 这次我们的数据源是Q&A的关于医疗知识的,数据如下

    数据节取⾃https://huggingface.co/datasets/InfiniFlow/medical_QA


    7. 接下来我们观察下节点

    a. 第⼀个是⽂件节点,⽤于配置数据源


    b. 第⼆个是解析和分块节点


    c. 第三个是知识库节点,⽤于将chunk⼊库


    8. 我们可以点击运⾏来完成节点的测试,⼀步步往下测试


    9. Q&A处理器⽀持配置问题和答案所在列


    10. 知识库我们可以配置模型,使⽤哪个模型完成嵌⼊


    11. 配置完成后我们可以测试运⾏,输⼊中间的内容就可以完成测试了。


    12. 测试完成后,我们可以点击发布


    13. 运⾏成功后,我们可以在左侧进⾏召回测试.


    14. 接下来我们回到⼯作室模块


    15. 选择从应⽤模板创建


    16. 我们选择知识库+聊天机器⼈


    17. 可以看到有以下节点,知识库检索是检索过程,LLM进⾏了增强和⽣成,参数提取进⾏了⽣成后处理,最后的直接回复完成⽤⼾交互


    18. 我们来点击预览进⾏测试


    19. 可以看到使⽤了我们的知识库


    20. 检索内容如下


    21. 增强内容如下


    22. ⽣成内容如下


    23. 可以看到完整的RAG过程,我们也可以添加各种节点来完成前处理和后处理确保知识库的效果,Dify提供了⾮常丰富的⼯具可以辅助我们来完成。

    也提供了⼀个庞⼤的⼯具市场


    十.RAG的发展

    朴素RAG(Naive RAG)

    Naive RAG是RAG系统的最基本实现,使⽤单⼀的全⽂检索或向量检索,从⽂档集合中检索出与query相关的⽂档,直接将检索的⽂档⽤于增强LLM的⽣成。 Naive RAG具有⼏个局限性: 缺乏语义理解:全⽂匹配依赖词汇匹配,⽆法捕捉到query与⽂档之间的语义关联;向量检索受限于间接匹配,语义理解能⼒也不⾜。 输出效果差:由于缺乏对query、⽂档的⾼级预处理、后处理,召回的⽂档容易包含过多或过少信息,导致最终⽣成的回答过于宽泛。 效果优化困难:系统过于依赖单⼀检索技术,未对query、⽂档进⾏增强,导致优化局限于检索技术。


    ⾼级RAG(Advanced RAG)

    Advanced RAG是对Naive RAG各环节进⾏精细化优化和增强的产物。它从检索前、检索时、检索后三个维度提升效果,引⼊了⼤量⼯程技术。 主要增强点: 预检索:优化索引策略和查询改写等。

    检索:采⽤混合检索(如结合向量检索和关键词检索),并引⼊重排序模型优化结果相关性。

    后检索:对检索到的内容进⾏上下⽂压缩与筛选。 优点:检索质量和⽣成效果相⽐Naive RAG有显著提升。 缺点:计算成本增加,系统复杂度更⾼

    适⽤场景:⾼精度问答(如法律、技术⽂档)


    模块化RAG(Modular RAG)

    Modular RAG的核⼼是将整个RAG流⽔线拆解为独⽴的模块,每个模块可以独⽴开发、升级和替换。 核⼼理念:解耦(如检索、重排序、⽣成、路由等模块)。你可以⽤不同的嵌⼊模型、向量数据库、⼤模型来⾃由组合,像搭乐⾼⼀样构建系统。它超越了传统的线性架构,⽀持路由、调度和多源融合。 优点:系统灵活,可插拔,易于扩展和维护。 缺点:设计更复杂,模块间的接⼝和协调需要精⼼规划。 适⽤场景:复杂的企业级RAG系统,需要根据业务需求灵活定制。


    基于图的RAG(Graph RAG)

    Graph RAG是由微软研究院提出的,它利⽤知识图谱(KG)来增强检索。知识图谱以节点(实体)和边(关系)的形式组织信息,能清晰展现事物间的关联。

    GraphRAG 由微软研究院于 2024 年推出,旨在解决⼤型语⾔模型 (LLM) 的局限性。((2))传统 LLM 往往在难以处理复杂的⼯作流,尤其是在私有或结构化数据推理⽅⾯,因为它们缺乏理解实体之间关系的能⼒。GraphRAG 通过使⽤图形数据库对这些关系进⾏建模,来解决这个问题,使其能够处理复杂的查询、检索上下⽂信息,并提⾼⽣成式 AI 应⽤程序的准确性。

    • ⼯作原理:

    a. 索引:从⽂档中抽取实体和关系,构建知识图谱并存⼊图数据库。 b. 检索:根据⽤⼾查询,在图数据库中进⾏图遍历(如BFS/DFS)或查询,检索出相关的⼦图或社区作为上下⽂。 c. ⽣成:将检索到的⼦图转化为⽂本,与查询⼀起输⼊LLM⽣成答案

    • 优点:能捕捉复杂关联、实现多跳推理、理解全局语义,答案可解释性强。
    • 缺点:图谱构建和维护成本⾼,依赖数据质量。
    • 适⽤场景:知识图谱问答、科研⽂献分析、反欺诈等需要复杂关系推理的任务。

    基于智能体的RAG(Agentic RAG)

    Agentic RAG是RAG架构的集⼤成者,通过引⼊AI Agent,使RAG系统具备⾃主规划、决策和执⾏的能⼒。

    • 核⼼能⼒:
  • ⾃主规划与反思:Agent能将复杂任务分解为多个步骤,并⾃我反思、修正计划。
  • 主动检索:Agent能根据对⾃⾝知识的评估,主动判断是否需要检索。
  • ⼯具调⽤:Agent可以⾃主选择并调⽤外部⼯具或API(如⽹络搜索、计算器、数据库)来完成任务。
    • 架构特点:它不是⼀个固定流程,⽽是⼀个“感知-决策-执⾏”的闭环系统,能够动态地规划⾏动路径。
    • 优点:能⼒强⼤,适应性强,能处理⾼度复杂和开放式的任务。
    • 缺点:设计和调试难度⾼,计算开销⼤,输出的不确定性更⾼。
    • 适⽤场景:复杂的任务处理、⾃动化⼯作流、需要与外部环境交互的智能应⽤。

    单智能体 RAG(Single-Agent Agentic RAG)

    核⼼思想:由⼀个单⼀的AI智能体,全权负责从理解查询、制定检索策略、调⽤⼯具,到最终⽣成 答案的完整流程。 ⼯作机制:该架构通常遵循“查询 → 规划与检索 → 评估与反思 → ⽣成”的循环路径。例如,在单 路由器模式中,Agent作为路由器,根据查询类型动态选择最优的检索⼯具或数据源(如向量数据 库、Web API等)。 优点与缺点:

    • 优点:架构简单、易于实现,适合任务边界清晰、流程相对固定的场景。
    • 缺点:处理⾼度复杂或需要多种专业知识的任务时能⼒受限,且单点故障⻛险⾼,所有决策都依赖⼀个核⼼

    多智能体 RAG (Multi-Agent Agentic RAG)

    核⼼思想:使⽤多个AI智能体,各⾃承担不同⻆⾊,通过分⼯协作完成复杂任务。 ⼯作⽅式:不同智能体各司其职。例如⼀个团队可由以下⻆⾊组成:

    • 规划者:接收⽤⼾问题,将其拆解为可执⾏的⼦任务。
    • 检索者:执⾏具体的检索⼯作。
    • 评估者:检验检索结果的相关性与完整性。
    • ⽣成者:综合所有信息,⽣成最终答案。

    优点:任务分解更精细,扩展性强,准确性更⾼。 缺点:架构复杂,系统开销⼤,智能体之间的协调与通信可能带来性能瓶颈和延迟。


    层次化智能体RAG(Hierarchical Agentic RAG)

    核⼼思想:将代理⼈按层级结构组织起来,以便更好地确定任务优先级和进⾏任务委派。 ⼯作流程:

    a. 顶层代理协调下层代理之间的⼦任务。 b. 每个下级代理负责处理流程中的特定部分。 c. 结果经过反复改进,并在更⾼层级进⾏整合

    优势:

    可扩展以应对⼤型复杂任务。 模块化设计有利于专业化分⼯。

    局限性:

    需要复杂的协调机制。 层级较⾼处可能存在瓶颈。


    基于图的智能体RAG(Graph-Based Agentic RAG)

    核⼼思想:

    利⽤图知识库(如知识图谱)和反馈回路,动态地将任务分配给专⻔的智能体代理,通过结构化关系与⾮结构化数据的融合,实现⾼精度的迭代式检索增强⽣成。

    ⼯作⽅式:

    1. 关系提取:从图知识库中提取实体之间的结构化关系(例如,疾病 → 症状、药物 → 副作⽤等映射)。 2. 数据补充:从外部来源(如⽹⻚、⽂档、数据库)获取⾮结构化数据,与图知识进⾏融合。 3. 验证与迭代:使⽤评价模块对⽣成结果进⾏验证,并将反馈信息回传⾄系统,驱动下⼀次检索或推理的改进。

    优势

    多源数据融合:能够同时利⽤结构化图数据和⾮结构化⽂本,提供更丰富的上下⽂。 模块化与可扩展:各组件(提取、检索、评价、⽣成)解耦,便于针对复杂任务进⾏定制和扩展。 ⾼精度迭代改进:通过反馈回路持续优化结果,有效减少错误和幻觉。

    劣势

    可扩展性受限:⾯对⼤规模、⾼动态的数据源时,图检索与更新的性能瓶颈明显。 数据质量依赖强:⾼度依赖⾼质量、标注完善的图数据,在⾮结构化或噪声数据上效果下降。 集成复杂度⾼:将图数据库与传统向量检索系统集成,显著增加系统设计和实现难度。

    更多的RAG参考论⽂(RAG综述)论⽂综述 https://arxiv.org/pdf/2501.09136


    十一.未来RAG的可能发展趋势

    1. 从“朴素RAG”向“Agentic RAG”升级 RAG 将不仅仅是⼀个被动的信息检索⼯具,⽽是演变为以代理(Agent)为核⼼的智能系统。AgenticRAG 具备⾃主规划、推理、⼯具使⽤和反思能⼒,能够主动分析⽤⼾意图,拆解复杂问题,并多次迭代检索和⽣成的过程。


    2. 多模态 RAG 未来的RAG系统将突破⽂本限制,实现跨模态(⽂本、图像、视频、⾳频、图表)的联合检索与⽣成。例如,从PDF⽂档中同时检索出⽂字和图表,并综合⽣成包含多模态数据的报告。


    3. 个性化与知识定制 RAG 将能更好地结合⽤⼾的个性化信息、历史记录和偏好,为⽤⼾提供私有化、个性化的回答,⽽不仅仅是基于通⽤知识。


    4. 记忆驱动的实时 RAG 传统的RAG依赖向量数据库,⽽未来的RAG可能利⽤LLM的KV缓存(Key-Value Cache)作为动态的、⻓期或短期记忆。这允许模型在对话过程中即时学习新信息并更新知识,实现更⾼的灵活性和适应性。


    5. 轻量化RAG 优化检索和⽣成模型,使其能在移动端或边缘设备运⾏(如⼿机上的智能助⼿)。


    实战-Graph RAG创建使⽤ 1. 了解Neo4j Neo4j 是⼀种图数据库管理系统,专⻔⽤于存储和查询具有复杂关联关系的数据。它使⽤图结构(节点、关系、属性)⽽不是传统的⼆维表格(关系型数据库),因此⾮常适合处理社交⽹络、推荐系统、知识图谱、欺诈检测等需要深度关联分析的场景。 Neo4j 由 Neo4j, Inc.(Neo4j 公司)开发并提供⽀持,总部位于美国加州圣⻢特奥。 官⽅⽹站:Neo4j Graph Intelligence Platform


    2. 打开Neo4j的官⽹,点击免费开始


    3. 我们完成账号注册


    4. 注册过程中会有⼀些调研信息按照情况填写就好


    5. 登录进去后选择Instances,注意不要直接点下就变成试⽤版本了


    6. 创建实例,我们选择免费版本,每⼈1个,然后输⼊实例的名字


    7. 创建好后,我们可以浏览下,看到内容都是空的


    8. 打开Neo4j提供的图RAG构建在线体验应⽤https://llm-graph-builder.neo4jlabs.com/,同样点击 右上⻆的login


    9. 完成账号的注册


    10. 登录进去后效果如下


    11. 我们点击右上⻆的链接到Neo4j


    12. 输⼊系统 提供的⽤⼾名和密码


    13. 连上去之后我们可以导⼊数据


    14. 我们选择web数据源,导⼊维基百科袁隆平爷爷的资料

    链接地址
    https://zh.wikipedia.org/wiki/%E8%A2%81%E9%9A%86%E5%B9%B3


    15. 提交后开始导⼊,导⼊成功


    16. 点击⽣成图谱


    17. 等待⼀会⽣成成功


    18. 可以看下⽣成的图谱结构


    19. 我们点击右边的聊天框就可以进⾏聊天了


    20. 聊天使⽤了我们的资料库


    21. 可以看到检索信息


    常⻅问题

    1. 为什么 Long Context 不会杀死 RAG

    ⾯上的疑问,既然现在模型上下⽂已经能做到⼏⼗万、上百万 token,我是不是可以把⼀整本书塞 进去?我是不是可以把所有⽂档都塞进去?那我为什么还需要 RAG? 真正的问题不是“能不能塞”,⽽是“应不应该塞”,Long Context 解决的是:

    • ⼀次能读更多材料
    • 更适合跨段落推理
    • 更适合⻓⽂精读

    但它没有解决:

    • 从海量知识⾥筛选相关信息
    • 脏上下⽂污染
    • 知识的信息量远远⼤于上下⽂窗⼝,百万级别随意就可以塞满了

    2. 简述 RAG 的标准流⽔线。

    概述流⽔线如下:

    • 载⼊(Loading):读取 PDF、HTML、Markdown 等⽂档。
    • 切分(Chunking):将⻓⽂本切分为固定⻓度或语义完整的块。
    • 向量化(Embedding):利⽤ Embedding 模型将⽂本块转为向量。
    • 检索(Retrieval):基于⽤⼾ Query,通过 ANN(Approximate Nearest Neighbor) 等算法在向量数据库中匹配最相似的 Top-K 块。
    • ⽣成(Generation):将检索到的上下⽂与 Query 拼接,输⼊ LLM ⽣成答案。

    3. 什么是RAG?它解决的核⼼问题是什么?

    RAG(Retrieval-Augmented Generation)是⼀种结合信息检索(Retriever)和⽣成式模型 (Generator)的技术⽅案。其核⼼思想是:当⽤⼾提出问题时,系统先通过检索模块从外部知识库(如⽂档库、数据库)中召回相关的⽂档或⽂本⽚段(Context),再将这些检索到的内容与⽤⼾问题(Query)⼀起输⼊⼤语⾔模型(如GPT、LLaMA),辅助模型⽣成更准确、有事实依据的回答(Answer)。 解决的核⼼问题:

    • 知识时效性问题:⼤模型参数固定,⽆法实时更新知识;RAG通过连接外部动态知识库,解决“模型不知道最新信息”的问题(例如企业最新政策、实时新闻)。
    • 知识覆盖问题:⼤模型的训练语料有限,对垂直领域(如法律、医疗、⾦融)或⻓尾知识覆盖不⾜;RAG通过接⼊专业⽂档库,扩展模型的“知识边界”。
    • 幻觉(Hallucination)问题:⼤模型可能⽣成看似合理但实际错误的答案;RAG通过检索真实⽂档约束⽣成内容,降低虚构信息的概率。
    赞(0)
    未经允许不得转载:171主机测评 » 【AI应用--白话大模型(篇十)】《一文全系列搞懂RAG技术:RAG从原理到应用,文本分块,向量嵌入,数据入库以及RAG未来的趋势发展》
    分享到: 更多 (0)

    评论 抢沙发

    • 昵称 (必填)
    • 邮箱 (必填)
    • 网址