三、如何上手 RAG？

向量数据库

方案	特点	适用场景
`Milvus`	高性能分布式向量数据库	大规模生产环境
`Elasticsearch`	同时支持全文检索与向量检索	需要混合检索、已有 ES 体系
`FAISS`	轻量、适合本地快速验证	本地实验、小规模检索
`pgvector`	PostgreSQL 向量扩展，维护成本低	团队已有 PostgreSQL 技术栈

嵌入模型

方案	特点	适用场景
`OpenAI text-embedding-3`	效果稳定、使用简单	预算充足，优先效果
Hugging Face 开源模型	如 `bge-large-zh`、`m3e-base`，可私有化部署	数据敏感或希望控制成本
国内 Embedding API	如智谱 AI、通义千问	需要更便捷的国内服务接入

评估工具

方案	特点
`RAGAS`	常见开源 RAG 评估框架，适合离线评测
自定义评估	更贴近业务目标，可结合人工标注、点击率、采纳率等指标

选型建议：

已有 Spring Boot 项目，优先考虑 Spring AI。

想快速拼装一条可运行的 RAG 链路，优先考虑 LangChain4j。

需要更强的可控性、精细优化能力或和现有基础设施深度整合，可考虑原生开发。

3.2 Java 实战：四步构建最小可行系统（MVP）

第一步：数据准备与清洗

RAG 的上限，很大程度上取决于知识库的质量。第一步不是”接模型”，而是先把数据整理干净。

技术要点：

使用 Apache Tika 解析 PDF、Word、Excel 等多格式文档。
使用 Jsoup 清理 HTML 标签、样式噪声和特殊字符。
对扫描版 PDF、图片类文档补充 OCR 处理，否则很多内容根本进不了索引。
统一文档编码、标题层级、换行格式与元数据字段，降低脏数据对检索的影响。

分块建议：

优先按语义段落、标题层级或业务字段切分，而不是机械地按固定字符数切块。
建议每块控制在 500~1000 tokens。
相邻块保留 50~100 tokens 的重叠区间，以减少上下文断裂。
为每个块保留来源、页码、标题、版本号、更新时间等元数据，方便后续溯源和过滤。

第二步：索引构建

技术要点：

将切分后的文本通过 Embedding 模型转化为向量。
向量入库时同步写入元数据，如来源文档、页码、创建时间、权限标识等。
建立增量索引机制，支持新增、更新、删除文档后的快速同步。
对高价值文档优先保证索引质量，而不是一开始就追求”全量接入”。

第三步：检索策略优化

技术要点：

不要只依赖单一向量检索，优先采用”向量检索 + 关键词检索”的混合检索方案。
使用 Rerank 模型对召回结果进行二次排序，提升真正相关内容的排名。
针对业务问题加入查询改写、同义词扩展、术语映射等能力，提升召回率。
对结果进行权限过滤、版本过滤和时间过滤，避免”召回到了但不能用”。

第四步：生成与提示工程

技术要点：

设计清晰的 Prompt 模板，引导 LLM 基于检索上下文作答。
明确约束模型”找不到证据就直接说明不知道”，尽量减少幻觉。
要求答案附带引用来源，提升可追溯性与可信度。
控制注入上下文的数量，避免把大量低相关内容塞进 Prompt，导致噪声过高。

RAG MVP 流程

MVP 验收标准：

能基于知识库回答明确问题。
能返回引用来源或文档片段。
对证据不足的问题，能够拒答或明确说明依据不足。
能通过一组简单测试问题，观察到可重复的效果变化。

3.3 Java 开发者的两条上手路径

路径一：低代码快速验证（适合业务方）

Dify / FastGPT：可视化知识库平台，适合快速上传文档、验证问答效果。
MaxKB：国产开源知识库问答系统，支持较快部署，适合内部 PoC。

路径二：工程化开发（适合技术团队）

LangChain4j：适合快速搭建、调试和扩展 RAG 链路。
Spring AI：适合深度集成到现有 Java / Spring 业务系统中。

如果目标是”先验证业务价值”，优先走低代码路径；如果目标是”接入现有 Java 系统，并纳入权限、审计、监控和治理”，优先走工程化开发路径。

3.4 落地过程中常见的难点与优化方向

难点	典型表现	优化建议
文档解析复杂	PDF、PPT、扫描件、图表类内容提取不完整；流程图、架构图多以形状元素呈现，只提文字会丢失大量潜藏信息	引入 OCR、版面分析能力，对高价值文档进行人工抽检；对重要图表提取描述与结构化信息
分块策略不合理	块太大导致召回粗糙，块太小导致语义破碎；固定 top_k 可能漏掉必要信息	按章节/段落切分，保留重叠区间，并按文档类型定制策略；根据块密度动态调整召回数量
专有名词召回差	缩写、内部术语、产品名难以命中；向量查询对专有名词不友好	引入术语词典、同义词映射、查询改写和混合检索
新旧版本并存	回答引用了过期文档或冲突内容；技术报告周期更新导致召回多个版本	增加版本号、生效时间、状态字段，并在排序时优先最新有效版本；明确标注版本来源
仅靠向量检索不稳定	短问题、精确关键词问题效果不佳；向量相似度无法完全反映真实语义匹配	采用向量检索 + BM25/全文检索 + Rerank
复杂逻辑推理困难	需要跨文档、多步骤推理才能得出答案；无法在单段落中直接找到答案	将任务拆成多个子问题，必要时引入工作流或规则引擎
公式计算类问题难	金融、统计等场景需要严格套用公式	将”检索”和”计算”拆开，交给外部计算模块处理
长文本与多轮问答	上下文过长、历史对话污染当前问题	做上下文裁剪、会话摘要、分轮检索和轮次隔离

这些问题说明：RAG 不是”接上向量库就结束”，真正决定效果的往往是数据治理、检索策略和评估闭环。

3.5 常见问题与应对方式

分块策略与 top-k 选择

问题：固定分块大小和固定 top_k 往往难以适应不同文档类型和查询场景。
应对：
- 根据文本长度和结构动态调整分块策略，避免信息破碎或召回粗糙。
- 采用可变 top_k 或按相关性阈值召回，而非固定数字。
- 引入 Rerank 对召回结果做二次排序。

世界知识缺失

问题：RAG 知识库可能和常识或真实世界知识脱节。例如，基于《西游记》数据构建问答，问”人有几个头”，系统可能给出错误答案。
应对：
- 在 Prompt 中提示模型优先依赖常识，只在必要时引用知识库。
- 对明显违背常识的检索结果进行过滤或人工干预。
- 对特定领域知识明确声明边界，避免模型”胡乱发挥”。

多跳问题与推理能力

问题：单次检索无法回答需要多步推理的问题，例如”谁能把 A 介绍给 B（排除 C）”。
应对：
- 将复杂问题拆解为多个子问题，分别检索再综合答案。
- 引入 ReACT 等复杂 Prompt 工程框架，让模型”先规划、再检索、再生成”。
- 在需要强推理的场景，结合外部图数据库或规则引擎辅助。

信息丢失与检索链路噪声

问题：在分块 → 向量化 → 检索 → 重排 → 生成的链路中，每个环节都可能出现信息丢失或噪声累积。
应对：
- 在分块时保留重叠区间，减少上下文断裂。
- 在检索后对结果进行去重、去噪和相关性过滤。
- 在生成前对上下文长度和质量做二次校验。

这些问题说明：RAG 的效果不仅取决于”接了什么模型”，更取决于数据质量、检索策略、评估与调优的工程闭环。

3.6 如何评估一个 RAG 系统？

文档召回率（Document Recall）

文档召回率衡量的是：对于一个问题，所有真正相关的文档中，有多少被系统成功检索出来了。

计算方式如下：

文档召回率 = 成功检索到的相关文档数量 / 所有相关文档数量

如果召回率过低，后面的生成模型再强，也只能”基于错误或不完整的信息认真回答”。因此，RAG 的第一优先级通常不是把答案写得多漂亮，而是先确保该找回来的内容能找回来。

常用评估指标

指标	含义	关注重点
`Context Precision` 上下文精确度	检索结果中，真正相关的上下文是否排在前面	排序质量
`Context Recall` 上下文召回率	检索结果是否覆盖了回答问题所需的信息	检索完整性
`Faithfulness` 忠实度	生成答案是否忠于给定上下文，是否出现幻觉	事实一致性
`Answer Relevance` 答案相关性	最终答案是否真正回答了用户问题	回答相关性

实践建议：

准备一批高质量问答集作为离线评测样本。
同时看”检索指标”和”答案指标”，不要只看最终回答是否流畅。
对线上场景补充人工反馈、点击率、采纳率、追问率等业务指标。
每次改动分块、检索或 Prompt 后，都要回归评测，避免”优化一个点、伤到一大片”。