AI - tag - 沐木https://oldletter.cn/tags/ai/AI - tag - 沐木Hugo -- gohugo.iozh-cnThu, 28 May 2026 00:00:00 +0000问卷考试系统设计（六）：报告生成——模板引擎、AI 接入与 PDF 导出https://oldletter.cn/posts/qnr-06-report-ai/Sat, 25 Apr 2026 00:00:00 +0000mumuhttps://oldletter.cn/posts/qnr-06-report-ai/上一篇：问卷考试系统设计（五）：前端引擎

数据收集、评分计算都做完了，业务方更关心的是末尾一步：拿到一份类似样的报告。报告生成的完整链路：模板定结构、规则填数据、AI 写解读、图表画可视化、末尾拼成 PDF。

报告生成适合异步化，前端只订阅任务进度，不直接等待 PDF 渲染完成：

sequenceDiagram participant API as 报告 API participant Queue as 异步任务 participant Rule as 规则解读 participant AI as AI 文案 participant Chart as 图表渲染 participant PDF as PDF 导出 participant SSE as SSE 进度 API->>Queue: 提交评分结果 Queue->>SSE: 10% 已接收 Queue->>Rule: 生成规则解读 Queue->>AI: 生成辅助文案 Queue->>Chart: 渲染图表 PNG Queue->>PDF: 拼 HTML 并导出 PDF Queue->>SSE: 100% 报告可下载

报告生成的几种模式

模板填充适合格式固定的报告，模板写好，变量一填就完事。

规则引擎解决条件判断问题。焦虑得分 0-4 分是"无焦虑"，5-9 分是"轻度焦虑"，这种区间映射用硬编码也能写，但规则多了维护起来是噩梦。

AI 生成处理自然语言解读。数字摆在那里，但用户要的是一段"读得懂"的文字。

实际项目中三者结合：模板定骨架，规则引擎填确定性结论，AI 只负责把结论写得更类似人话。先保证可复现，再谈润色。

]]>Java 后端的 LLM 实战路线：微调、RAG、Agent 全链路拆解https://oldletter.cn/posts/ai-02-llm-practice-roadmap/Thu, 28 May 2026 00:00:00 +0000mumuhttps://oldletter.cn/posts/ai-02-llm-practice-roadmap/

📅 2026-05-28 | 🏷️ LLM, LoRA, RAG, Agent | 📖 阅读约 25 分钟

写作背景

这篇文章站在 Java 后端的视角写。我的切入点并非训练框架本身，重点是把模型能力接进已有系统：接口怎么设计，流式响应怎么落地，知识库怎么更新，工具调用怎么审计。Python 示例能解释原理，真正上线时还要回到鉴权、限流、日志、回滚和成本控制。 后端同学学习 LLM 时，可以先抓住工程边界：模型负责生成，应用负责上下文、权限、状态和证据。只要这个边界稳住，后续换模型、换向量库、换 Agent 框架都不会牵动整套业务。 Java 生态资料少，不代表 Java 不适合做 AI 应用。训练和实验可以交给 Python，在线服务、管理后台、任务调度、数据治理仍然是 Java 很熟悉的战场。 这篇文章按落地顺序展开：先会调用模型，再做 RAG，再理解微调和 Agent，末尾补评估、部署和安全。 数学细节可以以后补，工程上先把数据链路、接口契约和验证方法跑通。

一、全景图：LLM 落地的四层架构

flowchart TB App["应用层：对话、客服、知识库、文档助手"] Orchestration["编排层：工作流、工具路由、会话状态"] Capability["能力层：检索、重排、Embedding、评测"] Model["模型层：LLM API 或自部署推理服务"] Infra["基础设施：向量索引、业务库、对象存储、GPU"] App --> Orchestration Orchestration --> Capability Orchestration --> Model Capability --> Model Capability --> Infra Model --> Infra

Java 后端开发者的优势在应用层和编排层，你已经会 Spring Boot、会设计 API、会做系统集成。 需要补的是能力层（怎么用 RAG/微调提升效果）和基座层（怎么选模型、怎么部署）。

]]>