> ## Documentation Index
> Fetch the complete documentation index at: https://blog.pig4cloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Java RAG 破局！Spring AI 驱动高质量知识库实践

## **分享大纲 (40分钟)**

### **议程安排**

* **个人介绍** (2分钟)
* **为什么选择Java技术栈** (8分钟)
* **Java AI主流技术栈** (8分钟)
* **RAG实现方式** (10分钟)
* **Java RAG的挑战** (5分钟)
* **PIG AI进阶实践** (15分钟)
* **最佳实践与趋势** (5分钟)
* **Q\&A互动** (剩余时间)

## **个人介绍** *(2分钟)*

### **嘉宾背景**

* Gitee GVP PIG微服务平台作者
* DeepSeek4j、office2md 开源项目作者
* langchain4j、spring ai committer
* 青岛玥明科技有限公司CEO
* 公众号: Java架构日记 博主

### **分享目标**

* 解析Java RAG技术栈选择理由
* 分享Spring AI实战经验
* 探讨企业级RAG系统构建路径

***

## **为什么选择 Java 技术栈** *(8分钟)*

### 企业级优势

Java长期被用于企业级应用开发，许多企业的核心业务逻辑已经用Java实现。Java能够更好地将AI服务与现有业务系统无缝集成，方便企业将AI功能嵌入到生产级应用中

### 社区支持和人才储备

Java拥有庞大且成熟的开发者社区，丰富的教育资源和成熟的开发框架（如Spring），有助于快速构建稳定的AI应用系统。同时，Java开发者在企业中数量众多，便于团队建设和人才招聘

***

## **Java AI 主流技术栈情况** *(8分钟)*

[https://compass.gitee.com/settings/subscribe](https://compass.gitee.com/settings/subscribe)

LangChain4j 和 Spring AI 是当前Java生态中两个主流的开源AI框架，它们各有特点和适用场景，下面从架构设计、开发体验、集成能力、性能表现等方面进行对比分析：

## 1. 框架定位与设计理念

* **Spring AI**：作为Spring家族的一员，Spring AI秉承"约定优于配置"的设计风格，强调与Spring Boot的无缝集成，适合在已有Spring生态中快速构建可扩展的AI应用。它简化了AI模型的集成和管理，支持分布式训练、推理引擎灵活配置以及丰富的AI能力（NLP、计算机视觉、推荐系统等）\[1]\[3]\[5]。

* **LangChain4j**：灵感来源于Python的LangChain，采用分层架构设计，模块化程度高，支持低阶API和高阶服务，灵活性强。它强调显式组合（explicit composition），可以独立于Spring使用，也可以集成到Spring Boot，适合需要深度定制和构建复杂LLM应用的场景\[1]\[4]\[5]。

## 2. 开发体验与集成

| 特性       | Spring AI                  | LangChain4j        |
| -------- | -------------------------- | ------------------ |
| 设计风格     | 约定优于配置，声明式编程               | 显式组合，模块化设计         |
| Spring集成 | 深度集成，自动装配                  | 可选集成，支持纯Java项目     |
| 学习曲线     | 较陡，需掌握Spring相关知识           | 适中，纯Java即可上手       |
| API使用    | 提供丰富的抽象和工具简化开发             | 提供统一API封装多种模型，灵活调用 |
| 生态支持     | 与Spring Data、Security等无缝结合 | 独立生态，支持多种LLM和向量存储  |

## 3. 功能特点

* **Spring AI**支持：
  * 多种AI任务：文本生成、情感分析、命名实体识别、图像分类、目标检测、图像生成、推荐系统、预测分析等\[3]。
  * AI模型管理：加载、缓存、版本管理、性能监控。
  * AI驱动的自动化任务：文档处理、语音转文字、文字转语音。
  * AI增强搜索：语义搜索、向量搜索。
  * 与云端AI服务（OpenAI、Hugging Face、Google Cloud AI等）集成\[3]。

* **LangChain4j**支持：
  * 多达15+ LLM提供商和嵌入存储集成，支持OpenAI、Amazon Bedrock、Mistral等。
  * 双层抽象：低阶模型调用和高阶AI服务。
  * 灵活构建复杂AI应用，如聊天机器人、虚拟助手、RAG（检索增强生成）等。
  * 适合构建高度定制化和模块化的AI工作流\[1]\[2]\[4]\[6]。

## 4. 性能表现（基于AWS c5.2xlarge，Java 21测试）

| 场景   | Spring AI QPS | LangChain4j QPS | 内存使用            |
| ---- | ------------- | --------------- | --------------- |
| 基础聊天 | 1420          | 1560            | LangChain4j高15% |
| 函数调用 | 860           | 920             | LangChain4j高8%  |
| 会话聊天 | 350           | 410             | LangChain4j低12% |
| 流式处理 | 2100          | 2400            | LangChain4j高5%  |

总体来看，LangChain4j在性能上略优，尤其适合轻量级和模块化需求；Spring AI则在Spring生态中表现优异，适合企业级应用\[5]。

## 5. 适用场景推荐

| 使用场景            | 推荐框架        | 理由                      |
| --------------- | ----------- | ----------------------- |
| Spring Boot企业应用 | Spring AI   | 与Spring生态深度整合，安全性和可观测性好 |
| 独立应用或小型项目       | LangChain4j | 轻量灵活，学习曲线适中             |
| 复杂Agent工具链      | LangChain4j | 模块化设计，支持高度定制            |
| 企业AI集成与运维       | Spring AI   | 丰富的模型管理和监控工具            |

Spring AI 优势增加了 多模态  audio 的支持

***

## **RAG 实现方式** *(10分钟)*

### **知识库初始化流程**

```
📄 原始文档 → 🔍 文档解析 → ✂️ 智能切片 → 🧠 向量嵌入 → 💾 向量存储 
```

**离线处理阶段** (一次性构建):

1. **文档收集**: 多格式文档统一收集(PDF/Word/Excel/PPT)
2. **内容解析**: Apache Tika/POI智能提取文本和元数据
3. **智能切片**: 语义感知切分，保持上下文完整性
4. **文本向量**: qwen-embedding模型生成语义向量
5. **向量存储**: Milvus高性能向量数据库存储

### **用户查询处理流程**

```
💬 用户查询 → 🔎 向量检索 → 🤖 LLM生成 
```

### **向量模型选择**

#### **主流开源向量模型对比**

Qwen-Embedding（以Qwen3-Embedding系列为代表）和BGE-M3是当前开源领域中两款常用的中文私有化文本向量模型

#### **qwen-embedding 优势**

* **多语言支持**: 100+种语言覆盖，中文效果突出
* **长文本理解**: 支持8K+上下文长度处理
* **指令优化**: 通过instruct微调提升特定任务效果1-5%
* **模型规模**: 0.6B到8B参数可选，平衡性能与资源

**Java集成方式**:

* Spring AI/Langchain4j原生支持，(使用 OpenAI 协议)
* 模型参数灵活调整
* 批量嵌入性能优化

### **向量数据库选型**

#### **主流向量数据库对比**

| 数据库               | 特色优势               | 适用场景    | Java支持      |
| ----------------- | ------------------ | ------- | ----------- |
| **Milvus**        | 高性能、分布式、云原生        | 大规模生产环境 | Spring AI原生 |
| **Qdrant**        | Rust构建、高精度、易用      | 中小规模应用  | HTTP API    |
| **Elasticsearch** | 成熟生态、混合检索          | 已有ES环境  | 完善支持        |
| **Redis**         | 内存缓存、低延迟           | 高频访问场景  | RedisSearch |
| **PGVector**      | PostgreSQL扩展、SQL兼容 | 传统关系型DB | JDBC支持      |

#### **2024国产向量数据库TOP5**

1. **Zilliz Milvus**: 开源领军，生态完善
2. **腾讯云 VectorDB**: 云原生，企业级
3. **九章云极 DingoDB**: HTAP融合架构
4. **火山引擎 VikingDB**: 字节跳动背景
5. **百度智能云 VectorDB**: AI生态整合

## **Java RAG 的挑战** *(5分钟)*

### **技术生态差距**

* **创新滞后**: 新技术通常Python首发
* **库成熟度**: 部分前沿功能缺乏Java实现
* **社区活跃度**: AI研究主要集中在Python社区

### **开发成本考虑**

* **学习曲线**: AI/ML + Java双技能要求
* **人才储备**: 复合型人才相对稀缺
* **技术债务**: 可能需要包装Python组件

## ![AEWWGT](https://minio.pigx.vip/oss/202506/AEWWGT.png)

## **PIG AI 进阶实践** *(15分钟)*

### **多类型知识的识别和读取**

#### **Office文档处理**

**Apache POI 企业文档解析**

* Word文档(.docx) - 提取文本、表格、图片
* Excel表格(.xlsx) - 数据结构化处理
* PowerPoint(.pptx) - 演示内容提取

**处理能力**:

* 保留格式信息和元数据
* 批量文档处理
* 异常处理和恢复

#### **PDF文档处理**

**Apache Tika 统一解析框架**

* 自动文件类型检测
* 文本和元数据提取
  **核心优势**:
* 统一的解析接口
* 丰富的文件格式支持
* 可扩展的解析器架构

#### **图片、PDF影印件模态处理**

* **OCR集成**: 处理图片中的文字信息
* **图像描述**: 生成图片的文本描述
* **视觉模型**: Qwen 2.5VL 来处理

#### 进阶：

office2md
这是一项基于 Markdown 格式的多功能转换服务，支持将 PowerPoint、Word、Excel、图像、音频和 HTML 等文件转化为 Markdown 格式

mineru: 文档复杂元素精准提取、精准定位图表/公式等复杂元素、多模态解析精准提取

MonkeyOCR: [https://github.com/Yuliang-Liu/MonkeyOCR](https://github.com/Yuliang-Liu/MonkeyOCR)

实际测速上： mineru关于PDF 影印件的和格式保留效果会更好

### **文档切片的不足与改进**

#### **传统切片问题**

**基础切片方式对比**

* 按段落切分，适合结构化文档，保持段落完整性
* 按行切分，适合代码文档或格式化文本
* 按句子切分，保持语义完整性，适合自然语言文档
* 按词切分，粒度较细，适合短文本处理
* 按正则表达式切分，灵活自定义切分规则
* 按字符数切分，固定长度，可能破坏语义

maxSegmentSizeInChars：表示每个切片的最大字符数限制。

maxOverlapSizeInChars：表示相邻切片之间重叠的最大字符数。

这两个参数的策略理解如下：

maxSegmentSizeInChars（最大切片长度）
它限制了每个文本切片的最大长度，通常以字符数计量（也有用token计量的，但这里是字符）。

切片不能超过这个长度，以保证后续的embedding模型或大模型能处理这个片段而不超出其上下文窗口限制。

过大的切片会导致embedding向量过于泛化，难以精准匹配查询；过小的切片则可能丢失上下文信息，导致语义不完整。

这个最大长度一般根据所用embedding模型的最大输入长度（比如OpenAI的text-embedding-3-small最大8191 tokens，折算为字符约32764）和下游大模型的上下文窗口大小来确定。

maxOverlapSizeInChars（切片重叠长度）
为了避免切片边界处信息丢失，通常会让相邻切片有一定的重叠部分。

这个重叠部分可以帮助模型在检索时保持上下文连贯性，避免重要信息被切断。

重叠大小一般占切片大小的10%-20%左右较为常见，但具体数值可根据文本密度和类型调整。

需要注意，过大的重叠会导致同样的信息被重复计算，增加计算成本且可能影响检索效率。

### **解析与切片阶段优化（以 DeepSeek V3 为例）**

在 RAG 的解析与切片阶段，DeepSeek V3 支持多种优化配置，帮助提升后续检索和生成效果。文档导入知识库后会被解析和切片，切片的主要目的是在向量化过程中尽量减少干扰信息，同时保持语义完整性。切片策略对 RAG 效果影响极大，若切片方式不当，可能导致：

* **文本切片过短**：语义缺失，检索时难以匹配。
* **文本切片过长**：包含不相关主题，召回时返回无关信息。
* **语义截断**：强制切分导致内容缺失。

#### **优化建议**

* 创建知识库时，优先选择"智能切分"chunk策略。
* 文档导入后，人工检查文本切片内容，确保语义完整。

#### **智能切分策略**

* 根据文档类型、提示词复杂度等因素自适应选择切片长度。
* 系统内置分句标识符，先按段落划分，再基于语义相关性自适应切分。
* 避免固定长度切分，优先保证语义完整。
* 可结合 LlamaIndex 等工具评估不同切片方法，反复试验以找到最佳长度。

#### **切片内容修正**

* 导入后如发现切分异常或解析错误（如空格被解析为%20），可直接编辑文本切片修正。
* 修正仅影响知识库检索内容，不影响原始文档。
* 后续再次导入需重新检查。

#### **高级切片策略**

#### \*\* NLP语义集成\*\*

* BERT文本分割-中文-通用领域
* 句子检测
* [https://modelscope.cn/models/iic/nlp\_bert\_document-segmentation\_chinese-base/files](https://modelscope.cn/models/iic/nlp_bert_document-segmentation_chinese-base/files)

**前沿进展与局限说明：**

* 近年来，许多基于神经网络的文本分割算法被提出。当前SOTA方法之一是Lukasik等人提出的基于BERT的cross-segment模型，将文本分割定义为逐句的文本分类任务（参考：[https://arxiv.org/abs/2004.14278）。](https://arxiv.org/abs/2004.14278）。)
* BERT分割模型能够捕捉长距离上下文依赖，在新闻、论文等自然语言文本分割任务中表现优异。
* 但在特定领域（如制造业），BERT对专有名词（如MES、装灯等）识别能力有限，容易出现分割错误。
* 对于表单、符号上下文（如"1.25亿元"），BERT模型可能会将其错误分割为"1"和"25"两句，导致语义割裂。
* 因此，针对专业术语和结构化文本，建议结合领域词典、规则引擎或自训练BERT模型，提升分割准确率；对于表单、财务等结构化文本，可结合正则表达式、布局分析等传统方法与BERT模型融合。

#### **基于特定领域的自训练中文OpenNLP的MES概念**

**领域定制化NLP**

* 针对制造执行系统(MES)文档特点
* 自训练中文句子分割模型
* 提升专业术语识别准确率

**实际难点与改进说明：**

* 通用分割模型对MES领域专有名词（如"装箱""装灯"）识别能力不足，容易误分割或混淆。
* 依赖标点符号的分割方式在处理如"1.25亿元"时，常常将其错误分割为"1"和"25"，导致语义割裂。
* 通过在MES领域语料上自训练OpenNLP分割模型，可显著提升对行业术语、专有名词和数字表达的识别与分割准确率。
* 可结合领域词典、正则规则和上下文特征，进一步优化分割效果，减少误分割和信息丢失。

### **文档标签与总结**

#### **智能标签生成**

**LLM驱动的标签提取**

* 基于文档内容自动生成关键标签
* 支持多级分类体系，便于后续检索和过滤
* 标签可用于知识库分层、权限控制、业务归档等

**案例举例：**

* 某制造业RAG系统，技术文档自动打上"装箱工艺""MES流程""质检规范"等标签，便于工程师按主题检索。
* 合同文档自动生成"采购""金额""供应商"等标签，支持财务、法务等多部门协同检索。

#### **文档摘要提取**

**自动摘要生成**

* 控制摘要长度和详细程度，保留核心信息和关键观点
* 支持多种摘要风格（简要/详细/结构化）
* 摘要可用于检索结果预览、知识图谱节点描述等

**案例举例：**

* 技术标准文档自动生成"本标准规定了装箱流程的操作规范和安全要求"等摘要，用户无需打开全文即可快速了解要点。
* 合同文档自动生成"本合同约定了2024年度采购金额及主要条款"，提升检索效率和业务透明度。

### **多路召回优化**

#### **BM25 + 向量混合检索**

**双路检索策略**

* BM25关键词精确匹配
* 向量语义相似度检索
* RRF(倒数排序融合)算法合并结果

**单纯向量检索的弊病案例：**
在传统RAG中，文档通常被拆分为较小的块以便高效检索。虽然这种方法对许多应用效果很好，但当单个块缺乏足够上下文时，可能会导致问题。

例如，假设知识库中包含了一个财务信息集合（如海尔的公开财报文件），收到问题："海尔公司在2025年第二季度的收入增长是多少？"
一个相关的块可能包含："公司收入比上一季度增长了3%。"但该块本身没有指明是哪家公司或哪个季度，导致难以检索到正确答案或有效利用信息。

**全文检索（BM25）的价值：**

* 全文搜索可在文本数据集中检索包含特定术语或短语的文档，并根据相关性排序。
* 克服了语义搜索的局限性（语义搜索可能忽略精确术语），确保获得最准确且与上下文最相关的结果。
* 支持原始文本输入，自动将文本数据转换为稀疏嵌入，无需手动生成向量。
* BM25算法用于相关性评分，在RAG场景中尤为重要，能优先处理与特定搜索词密切匹配的文档。

**技术优势**:

* 提升召回率和准确率
* 平衡词汇匹配和语义理解
* 降低单一检索方式的局限性

**实现要点**:

* Milvus提供向量检索
* Elasticsearch提供BM25检索
* Java应用层实现结果融合

### **检索召回阶段优化（以 DeepSeek V3 为例）**

在检索召回阶段，DeepSeek V3 提供多项优化配置，帮助提升相关文本片段的召回质量。应用观测功能可端到端分析检索召回过程。主要挑战是从众多文本切片中找出与提示词最相关且包含答案的内容。

#### **常见问题与改进策略**

| 问题类型                 | 改进策略                 |
| -------------------- | -------------------- |
| 多轮会话场景下，用户提示词不完整或有歧义 | 开启多轮会话改写，自动补全提示词     |
| 不同类别文档混检             | 为文档添加标签，检索时先筛选标签     |
| 结构内容相似文档混淆           | 提取元数据，向量检索前结构化搜索精准定位 |
| 召回结果不完整              | 降低相似度阈值，提高召回片段数      |
| 召回结果包含无关片段           | 提高相似度阈值，优化召回过滤       |

### **重排机制**

**Reranker原理说明：**

* 重排序模型（Reranker）的核心是计算用户查询与候选文档之间的语义匹配度，并根据该匹配度对结果进行重新排序。
* 对每个候选文档，Reranker会计算一个与用户查询的相关性分数，并按分数高低输出排序后的文档列表。
* 通过这种方式，能够显著提升语义排序的效果，确保最终返回的文档与用户意图最为贴合。

**二阶段检索优化**

* 初检: 快速召回候选文档
* 精排: 深度模型精确评分
* 最终返回最相关的Top-K结果

**重排优势**:

* 显著提升检索精度
* 平衡效率与准确性
* 减少LLM输入噪声

**技术选型**:

* Qwen3-Reranker模型（SOTA，单塔结构，支持多语言，性能领先）
* Cohere Rerank API
* 自训练交叉编码器

**原理与特点（以Qwen3-Reranker为例）**

* Qwen3-Reranker基于Qwen3基础模型，采用单塔结构，输入为"查询-文档"对，输出相关性得分。
* 支持多语言、指令适配优化，适应不同检索场景。
* 在MTEB等多项排序基准测试中，Qwen3-Reranker-8B取得业界领先成绩（如MTEB-R 69.02，MMTEB-R 72.94，2025年6月数据）。
* 相关性排序显著提升最终答案的准确率和用户体验。
* 详见[Qwen3 Embedding官方博客](https://qwenlm.github.io/zh/blog/qwen3-embedding/)

**实际案例举例：**

* 法律文档RAG系统，初检返回10个相关条款，重排后与"2024年新劳动合同法关于试用期的规定"最相关的条款排在首位。
* 医疗问答场景，重排优先呈现与患者症状最匹配的权威文献，避免噪声信息影响生成结果。
* 企业知识库，重排机制过滤掉仅有关键词但无实际关联的文档，确保LLM只接收到最有用的上下文。

### **生成答案阶段优化（以 DeepSeek V3 为例）**

在生成答案阶段，DeepSeek V3 支持多项优化配置，帮助提升RAG系统的最终回答质量。借助应用观测与日志分析功能，您可以端到端地查看和分析RAG的完整生成答案过程。至此，大模型已经可以根据用户的提示词以及从知识库检索召回的内容，生成最终的回答。然而，返回结果有可能还是不及您的预期。

#### **常见问题类型与改进策略**

| 问题类型                    | 改进策略                         |
| ----------------------- | ---------------------------- |
| 大模型未理解知识和用户提示词关系，答案生硬拼凑 | 选择更合适的 DeepSeek V3 模型，提升理解能力 |
| 返回结果不够全面或未按要求           | 优化提示词模板                      |
| 结果不够准确，包含大模型通用知识        | 开启知识库限定，仅基于检索内容回答            |
| 相似提示词希望结果一致或多样          | 调整大模型参数（如温度、采样策略）            |

#### **选择合适的 DeepSeek V3 模型**

DeepSeek V3 提供多种参数规模和能力版本，适用于不同场景：

* 复杂推理、专业领域：优先选择参数量更大、推理能力更强的 DeepSeek V3-Base/Pro。
* 简单信息查询：小参数量模型（如 DeepSeek V3-Turbo）即可。
* 长文档场景：选择支持更大上下文长度的 DeepSeek V3-Long。
* 垂直领域：可结合自训练或微调版本。

实际案例：

* DeepSeek V3-Base 在复杂法律、金融等场景下表现优于小模型。
* DeepSeek V3-Turbo 适合高并发、低延迟的问答场景。

#### **优化提示词模板**

提示词设计直接影响大模型输出质量。常见优化方法：

* **限定输出内容**：在模板中明确要求，如"如信息不足请回复'无法回答'"，减少幻觉。
* **添加示例（Few-Shot Prompting）**：给出输入输出示例，引导模型按预期格式输出。
* **内容分隔标记**：将提示词和知识库内容（如\${documents}）明确分开，且变量只出现一次，避免混淆。

示例：

```
# 要求
请从下方文本中提取技术规格，并以 JSON 格式展示。
${documents}
```

#### **开启知识库限定/拒识**

如需结果严格基于知识库，建议设置"仅知识库范围"回答，排除大模型通用知识影响。可设置未命中知识时的固定回复（如"未找到相关信息"）。

* 推荐"相似度阈值+大模型判断"双重判定，提升准确性。
* 可自定义判断Prompt，明确实体匹配规则。

#### **调整大模型参数**

* **温度系数**：控制生成内容的多样性。高温度适合创意场景，低温度适合确定性问答。
* **Top-p/Top-k采样**：进一步控制生成内容的随机性和多样性。
* **最大回复长度**：控制生成内容的详细程度。
* **携带上下文轮数**：控制参考历史对话的轮数，1表示不参考历史。

通过上述配置，结合 DeepSeek V3 的应用观测与反馈机制，可持续优化RAG系统的生成答案质量，提升用户体验。

***

### **联系方式**

* **微信群**: 扫码加入技术讨论群
* **GitHub**: 关注项目更新
* **博客**: 定期技术文章分享

***

**感谢聆听！期待与大家深入交流** 🚀