SpringBoot集成大模型应用开发企业级项目--【篇八：SpringBoot中集成RAG使用】

八、SpringBoot集成RAG

1、检索增强生成RAG

1.1、如何让大模型回答专业领域的知识

• LLM的知识仅限于它所训练的数据。如果你想让LLM了解特定领域的知识或专有数据，你可以：

  • 使用RAG
  • 使用你的数据微调LLM
  • 结合RAG和微调

1.2、微调大模型

• 在现有大模型的基础上，使用小规模的特定任务数据进行再次训练，调整模型参数，让模型更精确地处理特定领域或任务的数据。更新需重新训练，计算资源和时间成本高。

  • 优点：一次会话只需一次模型调用，速度快，在特定任务上性能更高，准确性也更高。
  • 缺点：知识更新不及时，模型训练成本高，训练周期长。
  • 应用场景：适合知识库稳定、对生成内容准确性和风格要求高的场景，如对上下文理解和语言生成质量要求高的文学创作、专业文档生成等。

1.3、RAG

• 检索增强生成（Retrieval-Augmented Generation）

• 将原始问题以及提示词信息发送给大语言模型之前，先通过外部知识库检索相关信息，然后将检索结果和原始问题一起发送给大模型，大模型依据外部知识库再结合自身的训练数据，组织自然语言回答问题。通过这种方式，大语言模型可以获取到特定领域的相关知识，并能够利用这些信息进行回复。

  • 优点：数据存储在外部知识库，可以实时更新，不依赖对模型自身的训练，成本更低。
  • 缺点：需要两次查询；先查询知识库，然后再查询大模型，性能不如微调大模型。
  • 应用场景：适用于知识库规模大且频繁更新的场景，如企业客服、实时新闻查询、法律和医疗领域的最新知识问答等。

1.4、RAG常用方法

• 全文（关键词）搜索。这种方法通过将问题和提示词中的关键词与知识库文档数据库进行匹配来搜索文档。根据这些关键词在每个文档中的出现频率和相关性对搜索结果进行排序。
• 向量搜索。也被称为“语义搜索”。文本通过嵌入模型被转换为数字向量。然后，它根据查询向量与文档向量之间的余弦相似度或其他相似性 / 距离度量来查找和排序文档，从而捕捉更深层次的语义含义。
• 混合搜索。结合多种搜索方法（例如，全文搜索 + 向量搜索）通常可以提高搜索的效果。

2、向量搜索(Vector search)

2.1、向量 Vectors

• 可以将向量理解为从空间中的一个点到另一个点的移动。例如，在下图中，我们可以看到一些二维空间中的向量。很多时候，我们处理的向量是从原点(0,0) 开始的，比如b。这样我们可以省略向量起点部分，直接说b是向量(100, -50).

• 如何将向量的概念扩展到非数值实体上呢（例如文本）?

2.2、维度 Dimensions

• 如我们所见，每个数值向量都有 x 和 y 坐标（或者在多维系统中是 x、y、z，...）。x、y、z... 是这个向量空间的轴，称为维度。对于我们想要表示为向量的一些非数值实体，我们首先需要决定这些维度，并为每个实体在每个维度上分配一个值。

• 例如，在一个交通工具数据集中，我们可以定义四个维度：“轮子数量”、“是否有发动机”、“是否可以在地上开动”和“最大乘客数”。然后我们可以将一些车辆表示为：

• 因此，我们的汽车Car向量将是 (4, yes, yes, 5)，或者用数值表示为 (4, 1, 1, 5)（将 yes 设为 1，no 设置为0）

• 向量的每个维度代表数据的不同特性，维度越多对事务的描述越精确，我们可以使用“是否有翅膀”、“是否使用柴油”、“最高速度”、“平均重量”、“价格”等等更多的维度信息。

2.3、相似度 Similarity

• 如果用户搜索"轿车car"，你希望能够返回所有与"汽车automobile"和"车辆vehicle"等信息相关的结果。向量搜索就是实现这个目标的一种方法。

• 如果确定哪些是最相似的？

  • 每个向量都有一个长度和方向。例如，在这个图中，p 和 a 指向相同的方向，但长度不同。p 和 b 正好指向相反的方向，但有相同的长度。然后还有c，长度比p短一点，方向不完全相同，但很接近。

-   那么，哪一个最接近p呢？

-   如果“相似”仅仅意味着指向相似的方向，那么a 是最接近 p 的。接下来是 c。b 是最不相似的，因为它正好指向与p 相反的方向。如果“相似”仅仅意味着相似的长度，那么 b 是最接近 p 的（因为它有相同的长度），接下来是 c，然后是 a。

-   由于向量通常用于描述语义意义，仅仅看长度通常无法满足需求。大多数相似度测量要么仅依赖于方向，要么同时考虑方向和大小。

2.4、相似度测量 (Measures of similarity)

• 相似度测量即相似度计算。四种常见的向量相似度计算方法（这里不展开讨论）：

  • 欧里几得距离 Euclidean distance
  • 曼哈顿距离 Manhattan distance
  • 点积 Dot product
  • 余弦相似度 Cosine similarity

3、RAG的过程

• RAG过程分为2个不同的阶段：索引和检索。

3.1、索引阶段

• 在索引阶段，对知识库文档进行预处理，可实现检索阶段的高效搜索。

  • 以下是索引阶段的简化图：

  • 加载知识库文档 --> 将文档中的文本分段 --> 利用向量大模型将分段后的文本转换成向量 --> 将向量存入向量数据库

• 为什么要进行文本分段？

• 大语言模型（LLM）的上下文窗口有限，所以整个知识库可能无法全部容纳其中。

  • 你在提问中提供的信息越多，大语言模型处理并做出回应所需的时间就越长。
  • 你在提问中的提供的信息越多，花费也就越多。
  • 提问中的无关信息可能会干扰大语言模型，增加产生幻觉（生成错误信息）的几率。

• 我们可以通过将知识库分割成更小，更易于理解的片段来解决这些问题。

3.2、检索阶段

• 以下是检索阶段的简化图：

• 通过向量模型将用户查询转换成向量 --> 在向量数据库中根据用户查询进行相似度匹配 --> 将用户查询和向量数据库中匹配到的相关内容一起交给LLM处理。

4、文档加载器（Document Loader）

4.1、常见文档加载器

• 来自 langchain4j 模块的文件系统文档加载器 (FileSystemDocumentLoader)
• 来自 langchain4j 模块的类路径文档加载器 (ClassPathDocumentLoader)
• 来自 langchain4j 模块的网址文档加载器 (urlDocumentLoader)
• 来自 langchain4j-document-loader-amazon-s3 模块的亚马逊 S3 文档加载器 (AmazonDocumentLoader)
• 来自 langchain4j-document-loader-azure-storage-blob 模块的 Azure Blob 存储文档加载器 (AzureBlobStorageDocumentLoader)
• 来自 langchain4j-document-loader-github 模块的 GitHub 文档加载器 (GitHubDocumentLoader)
• 来自 langchain4j-document-loader-google-cloud-storage 模块的 谷歌云存储文档加载器 (GoogleCloudStorageDocumentLoader)
• 来自 langchain4j-document-loader-selenium 模块的 Selenium 文档加载器 (SeleniumDocumentLoader)
• 来自 langchain4j-document-loader-tencent-cos 模块的 腾讯云对象存储 文档加载器 (TencentCosDocumentLoader)

5、文档解析器 （Document Parser）

5.1、常见文档解析器

• 文档可以是各种格式的文件，比如PDF、DOC、TXT等等。为了解析这些不同格式的文件，有一个“文档解析器”（DocumentParser）接口，并且我们的库中包含了该接口的几种实现方式：

  • 来自 langchain4j 模块的文本文档解析器 (TextDocumentParser) ，它能够解析纯文本格式的文件（例如 TXT、HTML、MD等）

  • 来自 langchain4j-document-parser-apache-pdfbox 模块的 Apache PDFBox 文档解析器 (ApachePdfBoxDocumentParser)，它可以解析PDF文件。

  • 来自 langchain4j-document-parser-apache-poi 模块的 Apache POI 文档解析器 (ApachePoiDocumentParser)，它能够解析微软办公软件的文件格式（DOC、DOCX、PPT、PPTX、XLS、XLSX等）。

  • 来自 langchain4j-document-parser-apache-tika 模块的 Apache Tika 文档解析器（ApacheTikaDocumentParser），它可以自动检测并解析几乎所有现有的文件格式。

  • 假如我们想解析PDF文档，那么原有的 TextDocumentParser 就无法工作了，我们需要引入 langchain4j-document-parser-apache-pdfbox

  • 添加依赖

    <!--解析pdf文档-->
    <dependency>
      <groupId>dev.langchain4j</groupId>
      <artifactId>langchain4j-document-parser-apache-pdfbox</artifactId>
    </dependency>
    

6、文档分割器（Document Splitter）

6.1、常见文档分割器

• LangChain4j 有一个“文档分割器”（DocumentSplitter）接口，并且提供了几种开箱即用的实现方式：

  • 按段落文档分割器（DocumentByParagraphSplitter）
  • 按行文档分割器（DocumentByLineSplitter）
  • 按句子文档分割器（DocumentBySentenceSplitter）
  • 按单词文档分割器（DocumentByWordSplitter）
  • 按字符文档分割器（DocumentByCharacterSplitter）
  • 按正则表达式文档分割器（DocumentByRegexSplitter）
  • 递归分割：DocumentSplitters.recursive(...)
  • 默认情况下每个文本片段最多不能超过300个token

6.2、测试向量转换和向量存储

• Embedding (Vector) Stores 常见的意思是 “嵌入（向量）存储” 。在机器学习和自然语言处理领域， Embedding 指的是将数据（如文本、图像等）转换为低维稠密向量表示的过程，这些向量能够保留数据的关键特征。而 Stores 表示存储，即用于存储这些嵌入向量的系统或工具。它们可以高效地存储和检索向量数据，支持向量相似性搜索，在文本检索、推荐系统、图像识别等任务中发挥着重要作用。

• LangChain4j支持的向量存储：

  • docs.langchain4j.dev/integration…

  • 添加依赖：

    <!--简单的rag实现-->
    <dependency>
      <groupId>dev.langchain4j</groupId>
      <artifactId>langchain4j-easy-rag</artifactId>
    </dependency>
    

6.3、token和token计算

• DeepSeek：

  • Token用量计算

    • api-docs.deepseek.com/zh-cn/quick…

  • DeepSeek API Docs

    • api-docs.deepseek.com/zh-cn/quick…

• 阿里百练：

  • bailian.console.aliyun.com/?spm=5176.2…

• LangChain4j：

  @Test
  public void testTokenCount() {
  String text = "这是一个示例文本，用于测试 token 长度的计算。"; UserMessage userMessage = UserMessage.userMessage(text);
  ​
  //计算 token 长度
  //QwenTokenizer tokenizer = new QwenTokenizer(System.getenv("DASH_SCOPE_API_KEY"),
  "qwen-max");
  HuggingFaceTokenizer tokenizer = new HuggingFaceTokenizer();
  int count = tokenizer.estimateTokenCountInMessage(userMessage); System.out.println("token长度：" + count);
  }
  

6.4、工作方式

1. 实例化一个 “文档分割器”（DocumentSplitter），指定所需的 “文本片段”（TextSegment）大小，并且可以选择指定characters 或token的重叠部分。
2. “文档分割器”（DocumentSplitter）将给定的文档（Document）分割成更小的单元，这些单元的性质因分割器而异。例如，“按段落分割文档器”（DocumentByParagraphSplitter）将文档分割成段落（由两个或更多连续的换行符定义），而 “按句子分割文档器”（DocumentBySentenceSplitter）使用 OpenNLP 库的句子检测器将文档分割成句子，依此类推。
3. 然后，“文档分割器”（DocumentSplitter）将这些较小的单元（段落、句子、单词等）组合成 “文本片段”（TextSegment），尝试在单个 “文本片段”（TextSegment）中包含尽可能多的单元，同时不超过第一步中设置的限制。如果某些单元仍然太大，无法放入一个 “文本片段”（TextSegment）中，它会调用一个子分割器。这是另一个 “文档分割器”（DocumentSplitter），能够将不适合的单元分割成更细粒度的单元。会向每个文本片段添加一个唯一的元数据条目 “index”。第一个 “文本片段”（TextSegment)将包含 index = 0，第二个是 index = 1，依此类推模型上下文窗口，可以通过模型参数列表查看：阿里云百炼

• 期望的文本片段最大大小：

  1. 模型上下文窗口：如果你使用的大语言模型（LLM）有特定的上下文窗口限制，这个值不能超过模型能够处理的最大 token 数。例如，某些模型可能最大只能处理 2048 个 token，那么设置的文本片段大小就需要远小于这个值，为后续的处理（如添加指令、其他输入等）留出空间。通常，在这种情况下，你可以设置为 1000 - 1500 左右，具体根据实际情况调整。
  2. 数据特点：如果你的文档内容较为复杂，每个段落包含的信息较多，那么可以适当提高这个值，比如设置为 500 - 800 个 token，以便在一个文本片段中包含相对完整的信息块。相反，如果文档段落较短且信息相对独立，设置为 200 - 400 个 token 可能就足够了。
  3. 检索要求：如果希望在检索时能够更精确地匹配到相关信息，较小的文本片段可能更合适，这样可以提高信息的粒度。例如设置为 200 - 300 个 token。但如果更注重获取完整的上下文信息，较大的文本片段（如 500 - 600 个 token）可能更有助于理解相关内容。

• 重叠部分大小：

  1. 上下文连贯性：重叠部分的主要作用是提供上下文连贯性，避免因分割导致信息缺失。如果文档内容之间的逻辑联系紧密，建议设置较大的重叠部分，如 50 - 100 个 token，以确保相邻文本片段之间的过渡自然，模型在处理时能够更好地理解上下文。
  2. 数据冗余：然而，设置过大的重叠部分会增加数据的冗余度，可能导致处理时间增加和资源浪费。因此，需要在上下文连贯性和数据冗余之间进行平衡。一般来说，20 - 50 个 token 的重叠是比较常见的取值范围。
  3. 模型处理能力：如果使用的模型对输入的敏感性较高，较小的重叠部分（如 20 - 30 个 token）可能就足够了，因为过多的重叠可能会引入不必要的干扰信息。但如果模型对上下文依赖较大，适当增加重叠部分（如 40 - 60 个 token）可能会提高模型的性能。

• 例如：在处理一般性的文本资料，且使用的模型上下文窗口较大（如 4096 个 token）时，设置文本片段最大大小为 600 - 800 个 token，重叠部分为 30 - 50 个 token 可能是一个不错的选择。但最终的设置还需要通过实验和实际效果评估来确定，以找到最适合具体应用场景的参数值。

福利：项目地址：

gitee.com/xuegang001/…