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-6RAG 架构核心重点序号重点一句话解释1RAG 解决 LLM 两大短板知识时效性不知道最近的事 幻觉编造不存在的事实通过检索外部知识库补充2RAG 的经典链路加载文档 → 文本切分(chunking) → 向量化(Embedding) → 存入向量库 → 检索召回(Top-K) → 重排序 → 注入上下文 → LLM 生成3Chunk Size 的权衡过大检索精度低、噪声多、超上下文限制过小语义不完整、丢失上下文推荐 256-512 tokens4混合检索 关键词 向量纯向量检索对专有名词、缩写不敏感加 BM25 关键词检索互补 → 召回率大幅提升5pgvector 是 Java 生态最优解PostgreSQL 原生扩展和你的 MyBatis/JPA 体系无缝集成免去多一套数据库运维架构师视角知识点RAG vs 微调 的架构选型决策架构师决策场景老板说让 AI 能回答公司内部产品文档的内容。RAG 适用场景优先考虑 - 知识频繁更新产品文档每天改→ RAG更新向量库即可 - 需要引用来源回答要标注出自哪个文档第几页→ RAG 天然支持 - 领域太多公司有 50 个产品线→ RAG同一套系统不同知识库 - 需要精确事实文档版本号不能错→ RAG检索原文不靠模型记忆 微调适用场景 - 需要特定表达风格如用亲开头的客服语气→ 微调 - 高频固定问答用户问的问题 80% 都一样→ 微调 缓存降成本 - 合规要求某些回答必须固定措辞→ 微调 架构决策原则 - 你的场景能用 RAG 就别微调成本低、维护简单、知识可热更新 - RAG 微调结合是银弹微调改风格RAG 补知识 - 向量数据库选择考虑运维成本——PGVector 对 Java 团队是零额外运维2周安排周任务产出Week 5文档加载切分实验 Embeddingpgvector入库向量检索切分策略对比 检索效果数据Week 6混合检索重排序 完整RAG链路打通 评测集构建自动化评分RAG 知识库问答系统 v1.0动手项目RAG 知识库问答系统需求上传 PDF → 自动切分入库 → 用户提问 → 检索相关片段 → LLM 生成回答带引用来源验收标准支持 PDF/Word/HTML 上传自动入库检索结果带引用来源“根据《XXX文档》第X段…”混合检索向量 BM25的 Recall5 0.85整个 RAG 链路延迟 3 秒有 20 条问答的评测集能自动化跑评分核心代码骨架RestControllerpublicclassRagController{privatefinalVectorStorevectorStore;// pgvectorprivatefinalChatClientchatClient;PostMapping(/rag/query)publicRagResponsequery(RequestBodyQueryRequestreq){// 1. 检索相关文档片段ListDocumentdocsvectorStore.similaritySearch(SearchRequest.query(req.getQuestion()).withTopK(5).withSimilarityThreshold(0.7));// 2. 拼接上下文Stringcontextdocs.stream().map(d-d.getContent()).collect(Collectors.joining(\n));// 3. 生成回答StringanswerchatClient.prompt().system(基于以下文档内容回答问题注明引用来源。如果文档中找不到答案说抱歉没有找到相关信息。\n文档\ncontext).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-7Agent 开发核心重点序号重点一句话解释1Agent 感知 决策 执行LLM 是大脑决策工具是手脚执行记忆是经验状态。Agent 是这三者的编排循环2ReAct 模式交替思考(Thought)→行动(Action)→观察(Observation)LLM 每一步都解释自己是思考还是行动3工具即 API一个工具就是一个可被 LLM 调用的函数名称、功能描述给 LLM 看、参数 schemaJSON Schema、执行逻辑4生产环境三把锁步数限制防止死循环、超时控制防止单个工具卡死、权限控制退款/删数据必须人工确认5MCP 协议Model Context Protocol标准化的工具/资源发现协议让不同 AI 应用共用同一套工具生态架构师视角知识点Agent 的死循环问题架构师决策场景Agent 调用查订单工具返回空结果它可能继续换参数查陷入无限循环。生产环境 Agent 设计三原则 1. 步数限制最多执行 10 步超过强制终止 → Agent 不是越聪明越好是越可控越好 2. 超时控制每个工具调用设超时如 5sAgent 整体设超时如 60s → 用户等不起模型反复思考 3. 权限分层 - 读操作查订单、查天气→ 自动执行 - 写操作创建订单、修改配置→ 需要用户确认 - 危险操作退款、删数据→ 必须人工审批不走 Agent 架构师价值不是做一个什么都能干的 Agent而是设计一个不会闯祸的 Agent2周安排周任务产出Week 6Function Calling → AgentReAct 循环 多工具协作3工具多工具 Agent DemoWeek 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模型私有化部署核心重点序号重点一句话解释1Ollama 是本地部署最快路径ollama pull qwen2.5:7b Java 调/v1/chat/completions 10 分钟搞定私有模型2GGUF 量化 消费级硬件跑大模型7B 模型从 14GB → Q4_K_M 量化后约 4GBMacBook 16GB 也能跑3vLLM 生产级推理引擎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链路追踪说卡在哪2AI 独有的评估维度准确性答对了吗、相关性答偏了吗、幻觉率编了吗、延迟多快、成本多少钱3评测集 防退化的基线每次改 Prompt/模型/参数后自动跑评测集发现退化立即回滚4Langfuse / OpenTelemetryLangfuse 记录 LLM 调用的完整链路OpenTelemetry 统一采集指标和 Trace5成本监控Token 消耗 × 单价 每次调用的实际成本按用户/会话/功能维度聚合防止费用爆炸动手项目AI 应用可观测面板验收标准完整追踪一次 LLM 调用的全链路用户请求 → Prompt → LLM → 回复监控核心指标QPS、P95 延迟、Token 消耗、成本构建 20 条评测集每次发版前自动跑Grafana 仪表盘一眼看清 AI 应用健康状况架构按需补你不是要成为一个脱离业务的纯架构师而是要在做 AI 项目过程中遇到什么补什么。架构工具书的完整内容见第三篇。补什么取决于你做什么AI 项目需求需要补的架构知识点查阅章节RAG 系统需要缓存热点答案Redis 缓存穿透/击穿/雪崩、分布式锁第三篇 §RedisRAG 系统文档量百万级、检索变慢MySQL 索引优化、B树原理第三篇 §MySQLAgent 要异步处理长任务消息队列、死信队列、幂等消费第三篇 §MQAI 中台要处理多服务间一致性分布式事务、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。返回系列导航