Java后端转AI工程（二）：AI深化篇 —— RAG + Agent + 模型部署 + 可观测性
本系列共 4 篇，完整覆盖 Java 后端向 AI 工程转型的 6 个月学习路径。
这是第二篇，聚焦第 2-3 月的核心内容：RAG 知识库、Agent 多工具协作、模型私有化部署、AI 应用可观测性。
如果你还没读过第一篇（AI基础 + Spring AI + LoRA微调），建议先补课。
系列导航：Java后端转AI工程：一份6个月全脱产学习计划
前情提要
第一篇结束后，你应该已经：
- 能用 Spring AI 搭一个带 Function Calling 的对话 API
- 独立完成过一次 LoRA 微调实验，理解微调和 RAG 的选择逻辑
接下来两个月是整个计划最硬核的部分——把 AI 能力从"调 API"升级到"工程化落地"。
阶段二：AI深化 + 架构按需补（第2-3月）
核心原则：AI 主线不中断，架构只在做 AI 项目遇到具体需求时查阅"架构工具书"补短板。前一个月跑通 RAG + Agent，后一个月搞定模型部署 + 可观测性，同时启动 AI 中台项目。
Week 5-6：RAG 架构
核心重点
| 序号 | 重点 | 一句话解释 |
|---|---|---|
| 1 | RAG 解决 LLM 两大短板 | 知识时效性（不知道最近的事）+ 幻觉（编造不存在的事实），通过检索外部知识库补充 |
| 2 | RAG 的经典链路 | 加载文档 → 文本切分(chunking) → 向量化(Embedding) → 存入向量库 → 检索召回(Top-K) → 重排序 → 注入上下文 → LLM 生成 |
| 3 | Chunk Size 的权衡 | 过大：检索精度低、噪声多、超上下文限制；过小：语义不完整、丢失上下文；推荐 256-512 tokens |
| 4 | 混合检索 = 关键词 + 向量 | 纯向量检索对专有名词、缩写不敏感；加 BM25 关键词检索互补 → 召回率大幅提升 |
| 5 | pgvector 是 Java 生态最优解 | PostgreSQL 原生扩展，和你的 MyBatis/JPA 体系无缝集成，免去多一套数据库运维 |
架构师视角
知识点：RAG vs 微调 的架构选型决策
架构师决策场景：老板说"让 AI 能回答公司内部产品文档的内容"。
RAG 适用场景（优先考虑）： - 知识频繁更新（产品文档每天改）→ RAG（更新向量库即可） - 需要引用来源（回答要标注"出自哪个文档第几页"）→ RAG 天然支持 - 领域太多（公司有 50 个产品线）→ RAG（同一套系统，不同知识库） - 需要精确事实（文档版本号不能错）→ RAG（检索原文，不靠模型记忆） 微调适用场景： - 需要特定表达风格（如用"亲"开头的客服语气）→ 微调 - 高频固定问答（用户问的问题 80% 都一样）→ 微调 + 缓存，降成本 - 合规要求（某些回答必须固定措辞）→ 微调 架构决策原则： - 你的场景能用 RAG 就别微调（成本低、维护简单、知识可热更新） - RAG + 微调结合是银弹：微调改风格，RAG 补知识 - 向量数据库选择考虑运维成本——PGVector 对 Java 团队是零额外运维2周安排
| 周 | 任务 | 产出 |
|---|---|---|
| Week 5 | 文档加载+切分实验 + Embedding+pgvector入库+向量检索 | 切分策略对比 + 检索效果数据 |
| Week 6 | 混合检索+重排序 + 完整RAG链路打通 + 评测集构建+自动化评分 | RAG 知识库问答系统 v1.0 |
动手项目：RAG 知识库问答系统
需求：上传 PDF → 自动切分入库 → 用户提问 → 检索相关片段 → LLM 生成回答（带引用来源）
验收标准
- 支持 PDF/Word/HTML 上传自动入库
- 检索结果带引用来源（“根据《XXX文档》第X段…”）
- 混合检索（向量 + BM25）的 Recall@5 > 0.85
- 整个 RAG 链路延迟 < 3 秒
- 有 20 条问答的评测集，能自动化跑评分
核心代码骨架
@RestControllerpublicclassRagController{privatefinalVectorStorevectorStore;// pgvectorprivatefinalChatClientchatClient;@PostMapping("/rag/query")publicRagResponsequery(@RequestBodyQueryRequestreq){// 1. 检索相关文档片段List<Document>docs=vectorStore.similaritySearch(SearchRequest.query(req.getQuestion()).withTopK(5).withSimilarityThreshold(0.7));// 2. 拼接上下文Stringcontext=docs.stream().map(d->d.getContent()).collect(Collectors.joining("\n"));// 3. 生成回答Stringanswer=chatClient.prompt().system("基于以下文档内容回答问题，注明引用来源。如果文档中找不到答案，说'抱歉，没有找到相关信息'。\n文档：\n"+context).user(req.getQuestion()).call().content();returnnewRagResponse(answer,docs);}}常见报错
| 报错 | 根因 | 解决 |
|---|---|---|
| 检索结果完全不相关 | Embedding 模型不匹配 / chunk 太大 | 换 text-embedding-3-small、调 chunk_size 256 |
| 引用来源张冠李戴 | 检索到的文档片段不包含答案 | 加重排序（Reranker），提高 Top-K 精度 |
| pgvector 查询慢 | 无索引或索引未建 | CREATE INDEX ON docs USING ivfflat (embedding vector_cosine_ops) |
| 回答包含幻觉 | 检索结果不准确 → LLM 被误导 | 加强 system prompt:“文档中没有的信息就说不知道” |
面试实战
Q1: RAG 的核心链路是什么？
- 文档加载 → 文本切分 → Embedding 向量化 → 存入向量数据库 → 用户提问 → 检索 Top-K 相关片段 → 注入 Prompt 上下文 → LLM 生成回答。核心价值：把 LLM 的回答建立在"可追溯的外部知识"之上。
Q2: Chunk Size 过大/过小各有什么问题？
- 过大：一个 chunk 包含太多无关信息 → 检索精度下降、噪音多、可能超出 LLM 上下文限制。过小：语义不完整（一个句子切两半）、丢失上下文、Embedding 质量差。推荐 256-512 tokens，按语义边界切（不是固定长度硬切）。
Q3: 混合检索比纯向量检索好在哪里？
- 向量检索对专有名词、缩写、数字不敏感（如"API-2301"这种编号，Embedding 很难准确匹配）。加 BM25（关键词匹配）互补，能大幅提升这类查询的召回率。召回后再用 Reranker 融合排序。
Week 6-7：Agent 开发
核心重点
| 序号 | 重点 | 一句话解释 |
|---|---|---|
| 1 | Agent = 感知 + 决策 + 执行 | LLM 是大脑（决策），工具是手脚（执行），记忆是经验（状态）。Agent 是这三者的编排循环 |
| 2 | ReAct 模式 | 交替"思考(Thought)→行动(Action)→观察(Observation)"，LLM 每一步都解释自己是思考还是行动 |
| 3 | 工具即 API | 一个工具就是一个可被 LLM 调用的函数：名称、功能描述（给 LLM 看）、参数 schema（JSON Schema）、执行逻辑 |
| 4 | 生产环境三把锁 | 步数限制（防止死循环）、超时控制（防止单个工具卡死）、权限控制（退款/删数据必须人工确认） |
| 5 | MCP 协议 | Model Context Protocol，标准化的工具/资源发现协议，让不同 AI 应用共用同一套工具生态 |
架构师视角
知识点：Agent 的死循环问题
架构师决策场景：Agent 调用"查订单"工具返回空结果，它可能继续换参数查，陷入无限循环。
生产环境 Agent 设计三原则： 1. 步数限制：最多执行 10 步，超过强制终止 → Agent 不是越聪明越好，是越可控越好 2. 超时控制：每个工具调用设超时（如 5s），Agent 整体设超时（如 60s） → 用户等不起模型反复"思考" 3. 权限分层： - 读操作（查订单、查天气）→ 自动执行 - 写操作（创建订单、修改配置）→ 需要用户确认 - 危险操作（退款、删数据）→ 必须人工审批，不走 Agent 架构师价值：不是做一个"什么都能干的 Agent"，而是设计一个"不会闯祸的 Agent"2周安排
| 周 | 任务 | 产出 |
|---|---|---|
| Week 6 | Function Calling → Agent：ReAct 循环 + 多工具协作（3+工具） | 多工具 Agent Demo |
| Week 7 | 生产加固（步数限制、超时、权限、重试）+ MCP协议 + 评测 | 生产级 Agent + 评测报告 |
动手项目：Agent Demo
验收标准
- 至少 3 个工具（如查订单、查天气、计算器）
- Agent 能自主决定"先查订单再发通知"这样的多步骤任务
- 步数上限 + 超时控制 + 人工确认点
- 支持 MCP 协议接入外部工具
- 有 10 个多步骤测试用例
面试实战
Q1: Agent 和普通的 Function Calling 有什么区别？
- Function Calling 是单次调工具（一问一调），Agent 是循环（观察→决策→执行→观察→…）。Agent 能处理"需要多步推理、中途根据结果调整策略"的复杂任务。
Q2: ReAct 和 Plan-and-Execute 两种 Agent 模式的区别？
- ReAct：交替思考和行动，灵活但可能绕弯路。Plan-and-Execute：先制定完整计划再执行，路径清晰但中途无法调整。复杂任务用 ReAct，流程明确的任务用 Plan-and-Execute。
Q3: 生产环境部署 Agent 需要注意什么？
- 步数上限防止死循环、工具超时防止卡死、读写权限分离、审计日志记录工具调用链、成本监控（每次 Agent 调用可能消耗大量 Token）。
Week 7-8：模型私有化部署
核心重点
| 序号 | 重点 | 一句话解释 |
|---|---|---|
| 1 | Ollama 是本地部署最快路径 | ollama pull qwen2.5:7b+ Java 调/v1/chat/completions= 10 分钟搞定私有模型 |
| 2 | GGUF 量化 = 消费级硬件跑大模型 | 7B 模型从 14GB → Q4_K_M 量化后约 4GB，MacBook 16GB 也能跑 |
| 3 | vLLM = 生产级推理引擎 | PagedAttention + 连续批处理，高并发吞吐量是 Ollama 的 5-10 倍 |
| 4 | 量化的精度损失 | INT8：精度损失 < 1%，Q4_K_M：损失 1-3%，Q2_K：损失 5-10%（不推荐） |
| 5 | 部署前必须测基线 | 首 token 延迟、生成速度(tokens/s)、最大并发、显存占用——这些是选模型的依据 |
动手项目：私有模型服务
验收标准
- Ollama/vLLM 部署至少 2 个开源模型
- 跑基准测试：首 token 延迟、生成速度、并发吞吐
- 模型量化到 GGUF Q4_K_M，测精度损失
- Java 应用通过 API 调用私有模型（和调 OpenAI API 一样）
面试实战
Q1: Ollama 和 vLLM 有什么区别？
- Ollama 面向个人开发者，一键部署、GGUF 量化、API 兼容 OpenAI。vLLM 面向生产环境，PagedAttention + 连续批处理，高并发吞吐量大。个人学习用 Ollama，生产部署用 vLLM。
Q2: 量化后有精度损失吗？
- INT8 量化损失 < 1%，几乎无感。Q4_K_M 量化损失 1-3%，大多数场景可接受。Q2_K 损失 5-10%，不推荐。建议从 Q4_K_M 开始，效果不够再往上提。
Week 8：可观测性与评估
核心重点
| 序号 | 重点 | 一句话解释 |
|---|---|---|
| 1 | 可观测性三支柱 | Logs（日志）说发生了什么，Metrics（指标）说有多严重，Traces（链路追踪）说卡在哪 |
| 2 | AI 独有的评估维度 | 准确性（答对了吗）、相关性（答偏了吗）、幻觉率（编了吗）、延迟（多快）、成本（多少钱） |
| 3 | 评测集 = 防退化的基线 | 每次改 Prompt/模型/参数后自动跑评测集，发现退化立即回滚 |
| 4 | Langfuse / OpenTelemetry | Langfuse 记录 LLM 调用的完整链路，OpenTelemetry 统一采集指标和 Trace |
| 5 | 成本监控 | Token 消耗 × 单价 = 每次调用的实际成本，按用户/会话/功能维度聚合，防止费用爆炸 |
动手项目：AI 应用可观测面板
验收标准
- 完整追踪一次 LLM 调用的全链路（用户请求 → Prompt → LLM → 回复）
- 监控核心指标：QPS、P95 延迟、Token 消耗、成本
- 构建 20 条评测集，每次发版前自动跑
- Grafana 仪表盘，一眼看清 AI 应用健康状况
架构按需补
你不是要成为一个脱离业务的"纯架构师"，而是要在做 AI 项目过程中，遇到什么补什么。架构工具书的完整内容见第三篇。
补什么取决于你做什么：
| AI 项目需求 | 需要补的架构知识点 | 查阅章节 |
|---|---|---|
| RAG 系统需要缓存热点答案 | Redis 缓存穿透/击穿/雪崩、分布式锁 | 第三篇 §Redis |
| RAG 系统文档量百万级、检索变慢 | MySQL 索引优化、B+树原理 | 第三篇 §MySQL |
| Agent 要异步处理长任务 | 消息队列、死信队列、幂等消费 | 第三篇 §MQ |
| AI 中台要处理多服务间一致性 | 分布式事务、Seata AT/TCC | 第三篇 §微服务 |
| 微服务拆多了，调用链太长 | Sentinel 熔断降级、限流策略 | 第三篇 §微服务 |
| 内存溢出排查 | JVM 内存模型、GC、MAT/Arthas | 第三篇 §JVM |
| 线程池爆了 | JUC 线程池参数、拒绝策略 | 第三篇 §JUC |
| 重组代码结构 | DDD 限界上下文、聚合设计 | 第三篇 §DDD |
第二篇检查清单
- 有 RAG 知识库系统上线，支持 PDF 上传和语义问答，带引用来源
- 能解释 Chunk Size 过大/过小的权衡、混合检索比纯向量检索好在哪里
- 有 Agent Demo，包含至少 3 个工具，能完成多步骤任务
- 能描述 ReAct 和 Plan-and-Execute 两种 Agent 模式的区别
- 在自己的电脑/服务器上成功部署过 Ollama + 开源模型（量化+基准测试）
- AI 应用有可观测面板：追踪、指标、评测集自动化
上一篇：Java后端转AI工程（一）：AI入门篇 —— 从零搭建 Spring AI 对话 API + LoRA 微调实战
下一篇：Java后端转AI工程（三）：AI中台+架构篇 —— 整合项目 + 完整架构工具书
第三篇教你把前两个月的 RAG、Agent、模型服务整合成一个完整的 AI 中台系统，同时附一份按需查阅的架构工具书（JVM/JUC/微服务/MySQL/Redis/MQ/DDD）。
返回系列导航
