1. 为什么 Java 工程师做 AI真正的战场在落地1.1 一个被反复验证的行业判断过去一年多我身边不少 Java 后端朋友都在焦虑同一件事AI 来了自己是不是要被淘汰了。有人跑去啃深度学习框架有人花大价钱买 GPU 在家训练小模型还有人干脆转行做算法。折腾一圈下来大部分人的结论是——训练这条路对 Java 工程师来说性价比极低。原因很直接。模型训练这件事本质上是算力、数据和算法研究的三角博弈。头部团队动辄几千张卡、几百 TB 清洗过的语料、一整个研究团队调参个人或小团队在这个维度上几乎没有胜算。你花两周训出来的 7B 模型效果大概率不如直接调用一个成熟的开源模型加一套好的提示词工程。但反过来看另一面企业真正需要的是什么是把大模型能力接进现有业务系统是让客服工单自动分类、让合同审查半自动化、让内部知识库能被自然语言检索、让老系统的数据能被 AI 用起来。这些事情恰恰是 Java 工程师的主场。我接触过的几个真实项目里团队里最抢手的不是会训模型的人而是能把 RAG 链路搭稳、能把 Spring Boot 服务和向量库打通、能把大模型输出做成可靠接口的人。这类工作有个共同名字——落地。1.2 落地到底在做什么先把概念说清楚。所谓 AI 落地指的是把已经训练好的大模型能力通过工程手段嵌入到具体业务场景中让它稳定、可控、可维护地产生价值。它包含几个典型环节接入层怎么调用大模型 API怎么做流式输出怎么处理超时和重试。检索层RAG检索增强生成怎么搭知识库怎么切分、怎么存、怎么召回。编排层多轮对话怎么管理工具调用怎么调度Agent 怎么串起来。服务层怎么用 Spring Boot 把上面这些包装成对外的接口怎么做鉴权、限流、监控。评估层怎么判断效果好不好怎么持续迭代。你会发现这里面除了“模型本身”几乎全是 Java 工程师熟悉的东西接口设计、并发处理、数据存储、服务治理。模型是别人训好的但把它用好、用稳、用出业务价值是工程问题。1.3 谁适合看这篇内容这篇内容写给三类人第一类有 Java 后端基础想切入 AI 但不知道从哪下手的工程师。你不需要先去学反向传播先把 RAG 和 Spring Boot 集成跑通就能接到真实需求。第二类正在做企业级 AI 项目卡在检索效果、性能瓶颈、服务稳定性上的开发者。后面我会讲具体的排查思路和参数取舍。第三类技术负责人需要判断团队该招什么人、该投什么方向。看完你应该能清楚训练和落地是两条完全不同的能力曲线。下面我按“整体设计思路 → 核心细节 → 实操过程 → 问题排查”的顺序展开尽量把每一步的“为什么”讲透让你不只是抄代码而是能自己判断和调整。2. 整体设计与思路拆解2.1 为什么选 RAG 而不是微调这是每个项目启动时都会被问的问题我要让模型懂我们公司的业务是微调一个好还是做 RAG 好先给结论绝大多数企业场景RAG 优先微调作为补充。理由有三条。第一成本。微调需要准备高质量标注数据需要 GPU 资源需要反复实验。一个中等规模的知识问答场景微调一次的成本可能是 RAG 方案的十倍以上而且模型更新、知识更新时还要重训。RAG 只需要更新知识库里的文档模型本身不动。第二可解释性。RAG 的答案能追溯到具体文档片段用户问“你这个结论哪来的”你能把原文甩出来。微调模型的输出是黑盒出了问题很难定位是数据问题还是训练问题。第三时效性。企业知识每天都在变政策、产品、价格随时调整。RAG 改文档即时生效微调要重新走一遍流程。那微调什么时候用当你的任务有强烈的风格或格式要求比如必须输出特定结构的 JSON、必须用某种专业口吻且这种要求用提示词很难稳定约束时微调才有明显优势。或者当你的领域术语极其特殊通用模型的 embedding 完全召不回正确内容时可以考虑微调 embedding 模型。我个人的经验是先用 RAG 把 80% 的场景跑通剩下 20% 的硬骨头再考虑微调。很多团队一上来就搞微调结果数据不够、效果不稳白白浪费两个月。2.2 技术栈选型的取舍逻辑Java 生态做 AI 落地绕不开几个选型决策。我把常见的组合和取舍列一下。环节常见选项取舍要点大模型接入官方 SDK、HTTP 直连、LangChain4j官方 SDK 最稳LangChain4j 抽象好但版本迭代快向量库Milvus、PgVector、Redis、Elasticsearch已有 PG 就用 PgVector量大用 Milvus要混合检索用 ES编排框架LangChain4j、Spring AI、自研简单场景自研更可控复杂 Agent 用框架服务框架Spring Boot 2.x / 3.x新项目直接 3.x老系统升级看依赖兼容文档解析Apache Tika、PDFBox、POI格式杂用 TikaPDF 精细处理用 PDFBox这里重点说两个决策。向量库怎么选。如果你的系统已经在用 PostgreSQL我强烈建议先用 PgVector。理由很简单少引入一个中间件运维成本低事务一致性容易保证数据量在百万级以内性能完全够用。等到数据量上千万、召回延迟成为瓶颈时再迁到 Milvus 也不迟。很多团队一上来就上 Milvus结果运维复杂度陡增收益却不明显。编排框架要不要用。LangChain4j 和 Spring AI 都能大幅减少样板代码但它们的抽象层有时候会挡住你排查问题。我的建议是如果只是“检索 拼接提示词 调用模型”这种线性流程自己写反而更清楚如果要处理多轮工具调用、条件分支、Agent 循环用框架能省很多事。选型时一定要看框架的版本活跃度和社区规模AI 领域半年就是一个代际。2.3 一个典型的落地架构我参与过的一个企业知识助手项目架构大致是这样的前端发起提问请求打到 Spring Boot 的/chat接口。接口层做鉴权和限流然后把问题交给检索服务。检索服务把问题向量化去 PgVector 里做相似度搜索召回 Top-K 片段。召回结果经过重排序Rerank筛掉不相关的。拼接提示词带上召回的上下文调用大模型。模型流式返回通过 SSE 推给前端。全程记录日志包括召回片段、模型输入输出用于后续评估。这个架构里Java 工程师负责的是除了“模型推理”之外的所有环节。而恰恰是这些环节决定了最终体验好不好。模型再强召回不准、拼接混乱、超时没处理用户照样骂。3. 核心细节解析与实操要点3.1 文档切分RAG 效果的第一道分水岭很多人做 RAG 效果差第一反应是模型不行其实问题往往出在文档切分上。切分策略直接决定了召回质量。切分粒度怎么定。太粗一个片段里混了好几个主题召回后噪声大太细语义不完整模型拿到的上下文支离破碎。我的经验值是中文场景下每个片段 300 到 500 字比较合适同时保留 50 到 100 字的重叠避免关键信息被切断。按什么切。最粗暴的是按固定长度切但效果最差。好一点的是按段落、按标题层级切。最好的是语义切分——用 embedding 判断相邻句子的语义相似度相似度骤降的地方就是切分点。LangChain4j 里有现成的DocumentSplitter但语义切分需要自己实现或调用模型。元数据一定要带。每个片段除了文本内容还要存来源文档、章节标题、页码、更新时间。这些元数据在召回后可以用来过滤和展示引用。我见过不少项目只存了文本结果用户问“这个结论出自哪份文件”系统答不上来信任度直接打折。注意切分后的片段不要直接存原始文本建议同时存一份清洗后的版本。PDF 解析出来的文本经常带页眉页脚、乱码、断行不清洗会污染 embedding。3.2 Embedding 与向量检索的关键参数Embedding 模型的选择和检索参数的设置是第二个容易踩坑的地方。Embedding 模型怎么选。中文场景优先考虑对中文优化过的模型。选型时看三个指标维度、最大输入长度、检索效果。维度不是越高越好768 维和 1024 维在实际检索中差距不大但存储和计算成本差不少。最大输入长度要匹配你的片段长度如果模型只支持 512 token你的片段就不能超过这个数。相似度度量怎么选。常见的有余弦相似度、内积、欧氏距离。大多数 embedding 模型训练时用的是余弦相似度所以检索时也用余弦最一致。PgVector 里对应的是操作符。Top-K 设多少。K 太小可能漏掉关键信息K 太大噪声多还会撑爆模型的上下文窗口。我的经验是先召回 20 到 30 个再用 Rerank 模型筛到 3 到 5 个送给大模型。这样既保证召回率又控制噪声。要不要加阈值。要。设置一个相似度下限比如 0.7低于这个值的片段直接丢弃。否则用户问一个知识库里完全没有的问题系统也会硬凑几个不相关的片段导致模型胡编。3.3 提示词工程把召回结果用好召回了正确的片段还得把它们组织成模型能理解的提示词。这一步看似简单实则有很多讲究。结构要清晰。我通常用这样的模板你是一个企业知识助手请根据下面提供的资料回答问题。 如果资料中没有相关信息请明确说“根据现有资料无法回答”不要编造。 资料 [片段1] [片段2] [片段3] 问题{用户问题}要明确约束。告诉模型不要编造、不要超出资料范围、回答要简洁。这些约束能显著降低幻觉率。片段要标号。给每个片段加编号方便模型引用也方便你后续做归因分析。如果模型回答里提到“根据资料 2”你就能快速定位。长度要控制。拼接后的提示词不能超过模型的上下文窗口。如果片段太多要么减少 K要么做摘要压缩。我一般会把总长度控制在模型窗口的 70% 以内留出余量给模型生成。3.4 Spring Boot 集成大模型服务的工程要点到了工程层面Java 工程师的优势就体现出来了。这里说几个关键点。流式输出怎么实现。大模型生成慢如果等全部生成完再返回用户要等十几秒。用 SSEServer-Sent Events做流式推送用户能边生成边看。Spring Boot 里可以用SseEmitter配合 WebFlux 的Flux更顺。注意设置合理的超时时间别让连接一直挂着。超时和重试怎么做。大模型 API 偶尔会超时或返回 5xx。要设置连接超时和读取超时读取超时建议给到 60 秒以上因为长回答生成确实慢。重试要谨慎生成类请求重试可能导致重复计费建议只对连接失败重试不对生成中途失败重试。并发怎么控制。大模型 API 通常有 QPS 限制。用信号量或令牌桶做限流超出的请求排队或快速失败。别让突发流量把配额打爆。日志怎么记。每次请求要记录用户问题、召回片段 ID、拼接后的提示词、模型输出、耗时、token 消耗。这些数据是后续优化和成本核算的基础。注意脱敏别把用户敏感信息原样落盘。提示把大模型调用封装成一个独立的 Service接口定义清晰方便替换模型供应商。今天用 A 家明天可能因为价格或效果换 B 家封装好能少改很多代码。4. 实操过程与核心环节实现4.1 环境准备与依赖引入假设你用的是 Spring Boot 3.x 加 Maven先引入核心依赖。向量库用 PgVector文档解析用 TikaHTTP 客户端用 WebClient。dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-webflux/artifactId /dependency dependency groupIdorg.postgresql/groupId artifactIdpostgresql/artifactId /dependency dependency groupIdorg.apache.tika/groupId artifactIdtika-core/artifactId version2.9.1/version /dependency数据库要装 PgVector 扩展CREATE EXTENSION IF NOT EXISTS vector; CREATE TABLE knowledge_chunk ( id BIGSERIAL PRIMARY KEY, content TEXT NOT NULL, embedding vector(768), source_doc VARCHAR(255), section_title VARCHAR(255), chunk_index INT, created_at TIMESTAMP DEFAULT NOW() ); CREATE INDEX ON knowledge_chunk USING ivfflat (embedding vector_cosine_ops) WITH (lists 100);这里的lists参数和你的数据量有关经验公式是lists rows / 1000数据量小于百万时取 100 左右即可。索引类型用ivfflat适合中等规模数据量特别大时考虑hnsw。4.2 文档入库流程入库分四步解析、清洗、切分、向量化。解析用 Tika 统一处理各种格式public String parseDocument(InputStream inputStream) throws Exception { AutoDetectParser parser new AutoDetectParser(); BodyContentHandler handler new BodyContentHandler(-1); Metadata metadata new Metadata(); parser.parse(inputStream, handler, metadata, new ParseContext()); return handler.toString(); }清洗主要是去页眉页脚、合并断行、去多余空白。这一步没有通用方案得根据文档来源定制。我一般会写几个正则规则先处理最常见的噪声。切分按段落优先段落太长再按句子切public ListString splitText(String text, int maxLen, int overlap) { ListString chunks new ArrayList(); String[] paragraphs text.split(\n\n); StringBuilder current new StringBuilder(); for (String para : paragraphs) { if (current.length() para.length() maxLen) { chunks.add(current.toString()); // 保留重叠部分 String tail current.length() overlap ? current.substring(current.length() - overlap) : current.toString(); current new StringBuilder(tail); } current.append(para).append(\n\n); } if (current.length() 0) chunks.add(current.toString()); return chunks; }向量化调用 embedding 接口批量提交提高效率。注意控制批量大小太大容易超时一般 16 到 32 条一批。4.3 检索与重排序实现检索分两阶段向量召回和重排序。向量召回用 PgVector 的余弦距离public ListChunk search(float[] queryVector, int topK) { String sql SELECT id, content, source_doc, section_title, 1 - (embedding ?::vector) AS similarity FROM knowledge_chunk ORDER BY embedding ?::vector LIMIT ? ; // 执行查询映射结果 }重排序可以用专门的 Rerank 模型也可以用一个更小的交叉编码器。如果不想引入额外模型可以用简单的规则按相似度加权、按来源可信度加权、去重。我实测下来加一层 Rerank 能把准确率提升 15% 到 25%值得投入。4.4 大模型调用与流式返回调用大模型用 WebClient流式返回用 SSEGetMapping(value /chat/stream, produces MediaType.TEXT_EVENT_STREAM_VALUE) public FluxString chatStream(RequestParam String question) { ListChunk chunks retrievalService.search(question, 5); String prompt promptBuilder.build(question, chunks); return llmClient.streamGenerate(prompt) .doOnNext(token - log.debug(token: {}, token)) .onErrorResume(e - { log.error(llm error, e); return Flux.just(抱歉服务暂时不可用); }); }llmClient内部用 WebClient 调大模型 API解析 SSE 流逐 token 转发。注意处理背压别让下游消费不过来导致内存堆积。4.5 效果评估怎么做没有评估就没有优化。我一般会准备一个测试集包含 50 到 100 个真实问题每个问题标注期望召回的文档和期望答案要点。每次调整切分策略、embedding 模型、提示词后跑一遍测试集看召回率和答案准确率的变化。召回率看 Top-K 里有没有包含正确文档答案准确率可以人工打分也可以用另一个模型做自动评估。自动评估省钱但不够准关键决策还是要人工看。5. 常见问题与排查技巧实录5.1 召回不准的排查路径召回不准是最常见的问题。排查顺序建议这样先看切分。把召回失败的片段原文打出来看是不是切得太碎或太粗。如果关键信息被切断了调整切分参数。再看 embedding。拿一个已知问题手动算它和正确文档的相似度如果相似度很低说明 embedding 模型不适合你的领域考虑换模型或微调 embedding。然后看检索参数。Top-K 是不是太小阈值是不是太高。临时把 K 调到 50看正确文档有没有进来。如果进来了说明是 K 的问题如果还是没进来说明是 embedding 或切分的问题。最后看查询改写。用户的问题往往口语化、有指代直接拿去检索效果差。可以先用大模型把问题改写成更适合检索的形式再去做向量搜索。5.2 模型胡编乱造的抑制手段幻觉是 RAG 的顽疾。抑制手段有几个层次提示词层面明确要求“只根据资料回答”“资料没有就说不知道”。这一层能解决大部分问题。检索层面提高召回质量设置相似度阈值过滤掉不相关片段。资料越准模型越不容易编。后处理层面对模型输出做校验比如检查回答里提到的实体是否在召回片段中出现过。没出现过的标记为可疑。模型层面选择指令遵循能力强的模型。有些模型天生更“听话”有些则喜欢自由发挥。这个只能实测。5.3 性能瓶颈的定位与优化RAG 链路的延迟主要来自三块检索、重排序、模型生成。定位方法是在每个环节打点计时。检索慢通常是向量库索引没建好或者数据量太大。检查索引类型和参数必要时分库分表。重排序慢如果是模型推理考虑用更小的模型或批处理。如果是规则检查规则复杂度。生成慢这是大模型的固有特性只能通过流式输出改善体验或者换更快的模型。有些场景可以用小模型先出草稿大模型再润色但会增加复杂度。5.4 常见问题速查表现象可能原因排查方向召回内容不相关切分过粗、embedding 不匹配检查切分粒度测试 embedding 相似度模型答非所问提示词结构混乱、上下文过长简化提示词减少召回片段数回答编造事实召回质量差、无阈值过滤提高召回精度加相似度阈值响应特别慢检索慢、模型慢、无流式分环节计时开启流式输出并发上不去连接池小、无限流调大连接池加限流保护成本超预期召回片段多、模型选型贵压缩上下文评估更便宜的模型5.5 几个我踩过的坑第一个坑embedding 和检索用的模型不一致。入库时用 A 模型检索时用 B 模型向量空间对不上召回全是乱的。一定要保证入库和检索用同一个 embedding 模型。第二个坑文档更新后没重新向量化。知识库文档改了但向量还是旧的召回的是过时内容。要建立文档变更触发重新入库的机制。第三个坑忽略 token 消耗。上线前没算成本跑了一个月发现账单吓人。一定要在日志里记录 token 消耗设置预算告警。第四个坑没有降级方案。大模型服务挂了整个功能不可用。要准备降级策略比如返回缓存答案、返回检索到的原文让用户自己看。6. 给 Java 工程师的转型建议6.1 该学什么不该学什么该学的RAG 原理和实操、向量数据库使用、提示词工程、Spring Boot 集成 AI 服务、基本的模型评估方法。这些是落地的核心技能投入产出比高。不该深究的模型训练细节、反向传播数学推导、GPU 集群运维。除非你确定要转算法岗否则这些对你做落地帮助有限。6.2 从现有项目切入最实际最好的学习方式是拿公司现有的一个需求练手。比如内部文档搜索、客服问答、工单分类。这些场景数据现成、需求明确、效果可衡量。做完一个你就有了完整的落地经验比看十篇教程都管用。6.3 保持对模型能力的敏感度模型迭代很快今天效果不好的方案下个月可能因为模型升级就可行了。保持关注但不要盲目追新。选型时优先考虑稳定、有长期支持的方案别为了用最新模型把系统搞得不稳定。我在实际项目中的体会是Java 工程师做 AI 落地最大的优势不是懂 AI而是懂工程。模型是别人的但把模型变成可靠产品的活儿是我们的。把检索做准、把服务做稳、把成本控住这些事做好了价值一点不比训模型低。