企业官网建设流程全解析

1. 为什么 Java 工程师做 AI，真正的机会在落地

1.1 训练大模型这件事，跟大多数 Java 工程师没关系

先把一个残酷的事实摆在桌面上：大模型的预训练和微调，本质上不是 Java 工程师的主战场。你打开任何一个招聘网站，搜“大模型训练工程师”，要求里写的基本都是 PyTorch、CUDA、分布式训练框架、Megatron-LM、DeepSpeed，语言栈清一色 Python。这不是歧视 Java，而是生态决定的——从 HuggingFace 到 vLLM，从 LoRA 微调到 RLHF，整条训练链路的工具几乎都长在 Python 上。

我身边有不少 Java 老哥，看到 AI 火就想转训练，花三个月啃 Transformer 论文，结果发现自己连一张 A100 都摸不到，公司也没有那个预算。训练一个像样的模型，动辄几十万上百万的算力成本，这不是个人能玩的游戏。所以如果你是一个写了五六年 Spring Boot、天天跟 MyBatis 和 MySQL 打交道的后端工程师，硬往训练方向挤，性价比极低。

但反过来看，企业真正缺的，是把大模型用起来的人。模型训练出来是一回事，怎么让它在一个真实的业务系统里稳定跑起来、怎么跟现有的订单系统对接、怎么处理并发、怎么做权限、怎么保证输出可控——这些全是 Java 工程师的舒适区。这就是我说的“落地”机会。

1.2 落地到底指什么：从模型到业务的那段脏活累活

所谓“落地”，说白了就是把一个能力不确定、输出不稳定、成本不便宜的大模型，包装成一个业务系统能放心调用的服务。这里面包含的东西非常多：

• 接口封装：把大模型的 HTTP 调用封装成内部统一的 SDK，处理超时、重试、降级。
• RAG 检索增强：让模型基于企业自己的知识库回答，而不是胡编。
• Prompt 工程与模板管理：不同业务场景用不同的提示词，还要能版本管理。
• 上下文与记忆管理：多轮对话怎么存、怎么裁剪、怎么控制 token 成本。
• 权限与审计：谁能问什么、问了什么、答案有没有风险，都要留痕。
• 性能与成本：缓存、批处理、流式输出、模型路由，都是钱。
• 可观测性：调用量、延迟、token 消耗、失败率，得能监控。

你看，这里面几乎没有一项是“训练”的活，全是工程活。而这些工程活，恰恰是 Java 生态最擅长的：Spring Boot 做服务编排、MyBatis 做数据持久化、Redis 做缓存、Kafka 做异步、Prometheus 做监控。你不需要重新学一门语言，你需要的是把已有的工程能力迁移到 AI 场景。

1.3 一个真实的判断：谁在招这类人

我观察了一段时间的招聘市场，发现一个明显的趋势：越来越多的岗位叫“AI 应用开发工程师”“大模型应用后端”“RAG 平台开发”，JD 里明确写“熟悉 Java/Spring Boot 优先”。这些岗位要的不是你去训模型，而是让你去搭平台、接模型、做检索、做 Agent 编排。

典型的需求场景包括：企业内部知识问答、智能客服、合同/文档审阅辅助、代码助手、数据分析助手。这些场景的共同点是——模型是现成的（调用 API 或私有部署），难点在于怎么把它嵌进业务流程。而这，就是 Java 工程师可以立刻上手、并且有长期积累价值的方向。

提示：不要被“AI 工程师”这个 title 吓到。很多所谓 AI 工程师，日常工作就是写 Prompt、调 API、搭 RAG 管道，技术含量集中在工程侧，而不是算法侧。

2. 落地场景的核心技术栈拆解

2.1 Spring Boot 作为 AI 应用的编排中枢

为什么是 Spring Boot？因为它解决了一个核心问题：把大模型能力变成一个有状态、可管理、可扩展的服务。你不可能让前端直接去调大模型 API，那样密钥暴露、无法限流、无法审计。中间必须有一层服务，而 Spring Boot 就是这层服务最成熟的载体。

具体来说，Spring Boot 在 AI 落地里承担几个角色：

• 统一网关：所有模型调用都经过它，方便做鉴权、限流、日志。
• 业务编排：一次用户请求可能要先查数据库、再检索知识库、再调模型、最后落库，这套流程用 Spring 的 Service 层组织最自然。
• 异步与流式：用 WebFlux 或 SSE 做流式输出，让用户看到字一个个蹦出来，体验好很多。
• 配置管理：不同环境用不同的模型、不同的 key，Spring 的 Profile 机制天然适配。

我自己的做法是，把模型调用抽象成一个LlmClient接口，底下可以有OpenAiClient、QwenClient、LocalModelClient等多个实现，通过配置切换。这样业务代码只依赖接口，换模型不用改业务逻辑。这个思路跟当年做多数据源、多支付渠道是一模一样的。

2.2 RAG：让大模型说“人话”和“实话”的关键

RAG（检索增强生成）是当前落地最火的技术，没有之一。原因很简单：大模型本身不知道你公司的内部知识，而且它会一本正经地胡说八道。RAG 的思路是，在模型回答之前，先从你的知识库里检索出相关内容，塞进 Prompt 里，让模型基于这些内容回答。

一个完整的 RAG 流程大致是这样：

1. 文档入库：把 PDF、Word、网页、数据库记录等切成小块（chunk）。
2. 向量化：用 Embedding 模型把每个 chunk 转成向量。
3. 存储：把向量存进向量数据库（Milvus、Qdrant、pgvector 等）。
4. 检索：用户提问时，把问题也向量化，找出最相似的 top-k 个 chunk。
5. 重排：用 Rerank 模型对检索结果再排一次序，提高精度。
6. 生成：把问题和检索到的内容一起塞给大模型，让它生成答案。

这里面每一步都有坑。比如切块，切太大检索不准，切太小语义不完整；比如检索，纯向量检索对关键词不敏感，往往要配合 BM25 做混合检索；比如重排，加了 Rerank 精度上去了但延迟也上去了。这些取舍，就是工程经验的价值所在。

2.3 向量数据库与知识库的选型逻辑

选向量库这件事，我的建议是先看你的数据量和团队熟悉度，别一上来就上重型武器。

我个人的经验是，大部分企业内部知识库，数据量根本到不了千万级，几万到几十万条 chunk 是常态。这种情况下，pgvector 或者 Qdrant 完全够用，没必要为了“先进”去折腾 Milvus 集群。选型的核心是匹配业务规模，而不是追新。

注意：向量库的维度要和 Embedding 模型对齐。比如用 1536 维的模型，建表时维度就得是 1536，换了模型要重新灌数据，这个成本要提前想清楚。

2.4 大模型接入：API 调用还是私有部署

这是每个团队都会纠结的问题。我的判断标准很简单：看数据敏感度和调用量。

• 数据不敏感、调用量小：直接用云厂商 API，省事，按 token 付费。
• 数据敏感（比如涉及内部文档、客户信息）：私有部署开源模型，数据不出内网。
• 调用量大且稳定：算一下私有部署的 GPU 成本 vs API 费用，往往私有部署更划算。

私有部署现在也不难，Ollama、vLLM、TGI 这些工具把门槛降得很低。一台带 24G 显存的卡，跑个 7B 或 14B 的量化模型，支撑内部几百人的问答完全没问题。Java 侧要做的，就是把这些服务的 HTTP 接口封装好，做好负载均衡和故障转移。

3. 从零搭一个 RAG 服务的实操过程

3.1 项目结构与依赖准备

我以一个典型的企业知识问答服务为例，走一遍完整流程。技术栈选型：Spring Boot 3.x + pgvector + 通义千问 API（或本地 Ollama）+ Redis 缓存。

先看依赖，核心就几个：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-webflux</artifactId> </dependency> <dependency> <groupId>org.postgresql</groupId> <artifactId>postgresql</artifactId> </dependency> <dependency> <groupId>com.pgvector</groupId> <artifactId>pgvector</artifactId> <version>0.1.6</version> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency>

WebFlux 是为了做流式输出，pgvector 的 Java 客户端负责向量读写。项目结构上，我习惯分这么几层：controller（对外接口）、service（业务编排）、llm（模型客户端）、retrieval（检索）、ingest（文档入库）。这样职责清晰，换任何一个组件都不影响其他层。

3.2 文档切块与向量化的参数选择

切块（chunking）是 RAG 里最容易被忽视、但影响最大的环节。我的经验参数是：

• chunk size：中文场景 300-500 字比较合适，英文 500-800 token。
• chunk overlap：设置为 chunk size 的 10%-20%，保证跨块的语义连续。
• 切分策略：优先按语义切（段落、标题），其次按固定长度切。

为什么 overlap 重要？举个例子，一句话被从中间切开，前半句在 chunk A，后半句在 chunk B，检索时可能只命中一个，语义就断了。加 overlap 就是让边界内容在两个块里都出现，降低这种风险。

向量化用 Embedding 模型，中文推荐 bge-large-zh 或 text-embedding-v3 这类。调用时要注意批量处理，一次传几十条比一条条传快得多，也省钱。入库时把 chunk 文本、向量、来源文档 ID、页码等元数据一起存，方便后续过滤和溯源。

public void ingest(Document doc) { List<String> chunks = splitter.split(doc.getContent()); List<float[]> vectors = embeddingClient.embedBatch(chunks); for (int i = 0; i < chunks.size(); i++) { chunkRepo.save(new Chunk(doc.getId(), i, chunks.get(i), vectors.get(i))); } }

3.3 检索环节：混合检索与重排的取舍

纯向量检索有个毛病：对精确的关键词、编号、专有名词不敏感。比如用户问“报销标准第 3.2 条”，向量检索可能找不准。所以生产环境我一般用混合检索：向量检索 + 关键词检索（BM25 或 PostgreSQL 的全文检索），两路结果合并后再重排。

合并的算法常用 RRF（Reciprocal Rank Fusion），简单说就是按排名倒数加权，不需要调权重，鲁棒性好。重排用 Rerank 模型（如 bge-reranker），把 top-50 精排到 top-5。这一步能显著提升答案质量，但会增加 100-300ms 延迟，要不要加看业务对延迟的容忍度。

public List<Chunk> retrieve(String query, int topK) { float[] qVec = embeddingClient.embed(query); List<Chunk> vecHits = vectorSearch(qVec, 50); List<Chunk> kwHits = keywordSearch(query, 50); List<Chunk> merged = rrfMerge(vecHits, kwHits); return reranker.rerank(query, merged, topK); }

提示：检索的 top-k 不要设太小。检索阶段宁可多召回，把精排交给 Rerank。我一般检索取 30-50，重排后取 3-5 塞进 Prompt。

3.4 Prompt 组装与流式输出实现

Prompt 组装的核心是把检索到的内容和用户问题清晰地分开，并给出明确的指令。一个可用的模板：

你是一个企业知识助手，请严格根据以下参考资料回答问题。 如果参考资料中没有相关信息，请直接说“根据现有资料无法回答”，不要编造。 参考资料： {context} 用户问题：{question}

这里的关键是“不要编造”这句约束，能大幅降低幻觉。context 部分把检索到的 chunk 拼起来，注意控制总长度别超模型上下文窗口。

流式输出用 Spring WebFlux 的Flux<String>配合 SSE，前端用 EventSource 接收。这样用户能边生成边看，体验比等半天一次性返回好太多。实现上，模型 API 一般支持 stream 参数，返回的是 SSE 流，Java 侧透传即可。

@GetMapping(value = "/chat/stream", produces = MediaType.TEXT_EVENT_STREAM_VALUE) public Flux<String> chatStream(@RequestParam String question) { return ragService.answerStream(question); }

3.5 缓存与成本控制的实际做法

大模型调用是花钱的，能省则省。我常用的几招：

• 问题缓存：把用户问题做归一化（去空格、转小写）后做 key，命中直接返回。相似问题可以用向量相似度做语义缓存。
• Embedding 缓存：同一段文本的向量是固定的，缓存起来避免重复计算。
• 模型路由：简单问题用小模型，复杂问题才用大模型。
• 上下文裁剪：多轮对话只保留最近 N 轮，老的做摘要压缩。

语义缓存这块，我用 Redis 存问题向量，查询时先算相似度，超过阈值（比如 0.95）就认为命中。实测下来，客服场景命中率能到 30% 以上，省下的钱很可观。

4. 落地过程中踩过的坑与排查技巧

4.1 检索不准的常见原因与排查顺序

检索不准是 RAG 最高频的问题。我的排查顺序是：

1. 先看切块：把命中的 chunk 打出来看，是不是切得乱七八糟。切块质量差，后面全白搭。
2. 再看 Embedding：同一句话两次向量化结果是否一致，模型是否适合中文。
3. 再看检索策略：纯向量还是混合，top-k 够不够。
4. 最后看 Prompt：检索对了但模型没用上，往往是 Prompt 没组织好。

我遇到过一个典型案例：用户问“年假怎么算”，检索出来的全是“请假流程”，因为“假”字匹配上了。后来加了 Rerank 和关键词权重才解决。这类问题靠调参解决不了，得从检索策略上动刀。

4.2 大模型输出不稳定、爱编造的应对

幻觉是绕不开的。除了 Prompt 里加约束，还有几个工程手段：

• 引用溯源：让模型在答案里标注来源 chunk，前端展示可点击的原文。
• 置信度过滤：检索相似度低于阈值时，直接告诉用户“没找到相关资料”。
• 输出校验：对关键字段（如金额、日期）做正则校验，异常就拦截。
• 人工兜底：高风险场景（如医疗、法律）必须人工复核。

注意：不要指望 Prompt 能 100% 消除幻觉。工程上要做的是“降低概率 + 可检测 + 可兜底”，而不是追求完美。

4.3 并发与超时：AI 服务的稳定性设计

大模型调用慢（几秒到几十秒），并发一上来就容易雪崩。我的做法：

• 超时设置：连接超时 5s，读超时按业务设 30-60s，流式另算。
• 限流：按用户和全局两个维度限流，防止单用户刷爆。
• 熔断降级：模型服务挂了，降级到“稍后再试”或走缓存。
• 异步化：非实时场景（如批量文档处理）走消息队列，别占着 HTTP 线程。

线程池要单独给模型调用配一个，别用默认的 Tomcat 线程池，否则一个慢请求能把整个服务拖垮。这个坑我在早期项目里踩过，印象深刻。

4.4 常见问题速查表

这张表我基本是贴在工位上的，出问题先对一遍，能省不少时间。

5. 给 Java 工程师的转型路径建议

5.1 需要补的知识和不需要碰的领域

需要补的，其实不多：

• Prompt 工程：会写清晰的指令，理解 few-shot、CoT 这些技巧。
• RAG 原理：切块、向量、检索、重排，知道每步在干嘛。
• 向量数据库：会用一个就行，pgvector 或 Qdrant 上手很快。
• 模型 API：会调、会处理流式、会算 token 成本。

不需要碰的：CUDA 编程、分布式训练、模型架构推导。这些是算法工程师的活，你了解概念即可，别陷进去。

5.2 从现有项目切入的最小可行路径

最实际的转型方式，是在现有项目里找一个 AI 能增强的点，先做出来。比如：

• 给内部管理系统加一个“智能问答”入口，接 RAG。
• 给客服系统加一个“回复建议”功能，用模型生成草稿。
• 给文档系统加一个“自动摘要”，批量处理。

这些都不需要大改架构，一个 Spring Boot 模块就能搞定。做出来之后，你就有真实的落地经验了，面试时也有的聊。我见过太多人卡在“想学但不知道从哪下手”，其实答案就是——从你手上正在做的业务里找一个痛点，用 AI 去解。

5.3 面试中如何讲清楚你的 AI 落地经验

面试被问到 AI 项目，别一上来就讲模型多牛。面试官想听的是你怎么解决工程问题。可以按这个结构讲：

• 业务背景：什么场景，为什么要用 AI。
• 技术选型：为什么选 RAG 而不是微调，为什么选这个向量库。
• 核心难点：检索不准怎么优化，成本怎么控制。
• 效果数据：准确率提升多少，成本降了多少，延迟多少。
• 踩坑经验：遇到什么问题，怎么排查的。

这套讲下来，比背一堆算法名词有说服力得多。因为面试官知道，能落地的人比会调参的人稀缺。

我个人在实际操作中的体会是，Java 工程师做 AI 落地，最大的优势不是技术多新，而是工程素养扎实。你知道怎么做限流、怎么做降级、怎么设计接口、怎么排查线上问题，这些能力在 AI 场景里一样值钱，甚至更值钱。模型会迭代，框架会过时，但把复杂系统做稳的能力，是长期饭票。所以别焦虑，把你手上的 Spring Boot 玩透，再往 AI 场景迁移，这条路走得通，而且走得稳。