业务阶段​

刚开始每天评价量不高，运营主要关注回复效率。

方案​

评价
 ↓
情感分类
 ↓
Prompt模板
 ↓
LLM生成回复

例如：

用户评价：

苹果很好吃

Prompt：

你是电商客服，请礼貌回复用户好评

生成：

感谢您的支持，欢迎再次购买。

遇到的问题​

随着评价量增长，回复开始出现：

草莓不甜

模型可能回复：

感谢您的支持

或者

水果甜度因人而异

明显与运营预期不符。

第二阶段：意图识别+知识库匹配

业务阶段​

差评开始增多。

运营希望：

不同问题有不同回复逻辑。

方案​

增加意图分类：

评价
 ↓
情感分类
 ↓
意图识别
 ├─物流问题
 ├─商品质量
 ├─包装问题
 ├─售后问题
 ↓
知识库匹配
 ↓
Prompt组装
 ↓
LLM

例如：

快递太慢了

识别：

物流问题

匹配：

物流FAQ

Prompt：

参考以下物流说明回复用户：

......

遇到的问题​

知识库越来越大：

500+
1000+
5000+

关键词匹配开始失效。

例如：

收到的时候已经烂了

可能命中：

水果不甜

而不是：

运输损坏

第三阶段：向量检索RAG

业务阶段​

商品数快速增长。

水果
零食
酒水
生鲜
家电

知识库达到数千条。

方案​

引入Embedding。

评价
 ↓
Embedding
 ↓
Vector Search
 ↓
TopK召回
 ↓
Prompt
 ↓
LLM

例如：

评价：

荔枝打开全是黑的

向量检索：

水果腐坏处理规范

而不是：

荔枝商品介绍

收益​

Recall明显提升。

运营开始能够接受AI回复质量。

第四阶段：Hybrid Search

业务阶段​

发现向量检索并不是万能。

例如：

A123型号

订单998812

阳光玫瑰葡萄

Embedding效果反而不好。

方案​

Hybrid Search。

用户评价
     ↓
 ┌─────────┐
 │Keyword  │
 └─────────┘
     ↓
      Merge
     ↑
 ┌─────────┐
 │Vector   │
 └─────────┘
     ↓
   Recall

常见实现：

ES BM25
+
Qdrant

效果​

商品型号、品牌名称召回率大幅提升。

第五阶段：ReRank重排

业务阶段​

召回结果越来越多。

Top10里面：

相关
相关
不相关
相关
不相关

Prompt中混入噪声。

导致回复质量下降。

方案​

增加ReRank。

Query
 ↓
Recall Top50
 ↓
Cross Encoder
 ↓
ReRank
 ↓
Top5
 ↓
LLM

例如：

草莓收到后发酸

召回：

水果变质
水果成熟度
物流时效
退款规则
...

ReRank后：

水果变质处理规范

排到第一位。

效果​

准确率进一步提升。

第六阶段：Query Rewrite

业务阶段​

用户评价越来越口语化。

例如：

不行

差

一般般

检索效果很差。

方案​

增加Query Rewrite。

评价
 ↓
Rewrite
 ↓
检索
 ↓
回复

例如：

原评价：

不甜

改写：

用户反馈水果甜度不足

原评价：

都坏了

改写：

用户反馈收到商品存在腐坏问题

效果​

召回准确率提升。

第七阶段：在线评测闭环

业务阶段​

运营开始关注：

AI回复是否真的有效？

方案​

建立评测体系。

用户评价
 ↓
AI回复
 ↓
人工审核
 ↓
用户反馈
 ↓
效果统计

指标：

知识命中率
召回准确率
审核通过率
人工修改率
用户满意度

最终企业级架构

用户评价
    ↓
情感分析
    ↓
意图识别
    ↓
Query Rewrite
    ↓
Router
    ↓
Vector
    ↓
ReRank
    ↓
Prompt Builder
    ↓
LLM
    ↓
AI回复
    ↓
人工审核
    ↓
反馈回流
    ↓
RAG评测平台

因此，对于已经进入AI应用落地阶段的企业来说，建设统一的AI平台往往比单独开发某个AI应用更重要。平台的目标并不是替代业务团队，而是提供统一的模型能力、知识库能力、Agent能力以及监控治理能力，让业务团队能够专注于业务创新，而不需要重复建设底层基础设施。

本文结合企业AI应用建设过程中常见的技术方案，介绍一个从0到1搭建企业AI平台的整体思路。

一、企业AI平台总体架构

企业AI平台本质上是一套分层架构，其核心目标是将业务逻辑与AI能力解耦，使模型升级、知识更新以及Agent能力扩展不会影响上层业务应用。

整体架构如下：

应用层
 ↓
Agent层
 ↓
Workflow层
 ↓
RAG层
 ↓
Model层

其中每一层都承担着不同的职责。

Model层​

Model层是整个AI平台最底层的能力中心，负责统一接入各种大模型。

在实际建设过程中，很少会只接入单一模型。因为不同模型的优势并不相同，有些模型推理能力较强，有些模型生成速度更快，有些模型成本更低，因此平台通常需要支持多个模型的统一管理。

例如：

• DeepSeek
• GPT
• Claude
• Qwen
• Gemini

为了避免业务系统直接依赖某个厂商SDK，通常会在平台内部封装统一的模型网关。

业务侧只需要关注：

chatModel.chat(prompt);

至于最终路由到哪个模型、是否进行重试、是否启用流式输出、是否进行降级处理，都由平台统一管理。

这种设计最大的价值在于模型切换成本极低，当出现新的模型或者模型价格发生变化时，只需要调整配置即可完成迁移。

RAG层​

对于企业应用而言，仅依赖模型自身知识往往无法满足业务需求。

例如：

• 商品信息
• 客服话术
• 企业制度
• 产品文档
• 运维知识

这些内容都在不断变化，而模型训练数据通常无法实时同步。

因此RAG（Retrieval Augmented Generation）成为企业AI平台中的核心组成部分。

RAG层主要负责：

文档解析、Chunk切分、Embedding生成、向量存储、检索召回以及重排序等能力。

用户提问后，系统首先完成向量检索，然后将检索结果与用户问题一起发送给大模型，从而获得更加准确的回答。

这一层通常是企业AI项目效果差异最大的地方，因为真正决定回答质量的往往不是模型，而是检索出来的上下文是否准确。

Workflow层​

当业务逻辑逐渐复杂之后，单次Prompt调用已经无法解决问题。

例如一个商品评价自动回复场景：

评价内容
 ↓
情感分析
 ↓
意图识别
 ↓
知识库检索
 ↓
Prompt构建
 ↓
模型生成
 ↓
人工审核

整个过程实际上已经形成了一个工作流。

Workflow层负责管理这些节点之间的执行关系。

包括：

• 顺序执行
• 并行执行
• 条件路由
• 人工审核
• 异常处理
• 重试机制

很多企业在项目初期会将这些逻辑全部写在Service层中，但随着场景增加，代码会迅速失控，因此需要引入统一的工作流引擎进行管理。

Agent层​

如果说Workflow解决的是流程编排问题，那么Agent解决的是自主决策问题。

传统Workflow更像预先设计好的流程图，而Agent则可以根据目标动态决定下一步应该做什么。

例如：

用户提出问题：

查询本月销售情况，并分析销量下降原因。

Agent可能自动完成：

调用销售系统
 ↓
获取数据
 ↓
分析异常指标
 ↓
查询运营活动
 ↓
生成分析报告

整个过程不再依赖固定流程，而是依赖模型的推理能力和工具调用能力。

因此Agent层通常包含：

• Tool Calling
• Memory
• Planning
• Reflection
• Multi-Step Reasoning

这些能力共同构成了企业级Agent的基础设施。

应用层​

应用层是最终面向业务的部分。

例如：

• AI客服
• AI运营助手
• AI知识库
• AI代码助手
• AI数据分析平台

这些应用并不直接依赖底层模型，而是通过平台能力进行快速构建。

这样能够避免重复建设，提高整体研发效率。

二、技术选型

在Java技术栈下，构建企业AI平台的技术组合相对成熟。

SpringBoot3​

SpringBoot3依然是整个系统的基础框架。

其优势在于：

• 企业级生态完善
• 与微服务体系兼容
• 易于整合缓存、中间件和数据库

对于绝大多数企业而言，没有必要为了AI项目重新引入新的后端框架。

LangChain4j​

如果说SpringBoot负责系统建设，那么LangChain4j负责AI能力建设。

其提供了：

• ChatModel
• StreamingChatModel
• AiService
• Tool Calling
• RAG
• Memory

等能力。

很多原本需要大量Prompt拼接和模型调用逻辑的代码，通过LangChain4j可以快速完成封装。

对于Java团队来说，其学习成本远低于Python生态中的LangChain。

Qdrant​

Qdrant是目前比较流行的向量数据库之一。

主要负责：

• 向量存储
• 相似度检索
• Metadata过滤

在企业知识库场景中，经常会同时利用向量搜索和元数据过滤。

例如：

产品 = 手机
部门 = 客服
时间 >= 2025

先完成过滤，再进行向量检索，能够显著提升召回质量。

Redis​

Redis承担多个角色。

包括：

• Prompt缓存
• 会话缓存
• Token缓存
• 限流控制
• 分布式锁

尤其是在高并发场景下，大量重复问题实际上没有必要重复调用模型，通过缓存可以显著降低成本。

Elasticsearch​

很多企业在建设RAG系统后发现，仅依赖向量搜索并不能解决所有问题。

例如：

产品型号查询。

iPhone16 Pro Max

这种精确匹配场景往往关键词检索效果更好。

因此实际项目中经常采用：

Keyword Search
+
Vector Search
=
Hybrid Search

而Elasticsearch正是关键词搜索的重要基础设施。

三、可观测性建设

很多团队把大量精力投入到模型效果优化，却忽略了可观测性建设。

实际上，线上问题排查往往比功能开发更重要。

日志体系​

一次完整请求通常需要记录：

用户问题
Prompt
模型名称
Token消耗
响应结果
耗时
异常信息

这样在出现幻觉或者回复异常时，能够快速定位问题。

如果缺少这些日志，后续排查几乎无从下手。

Tracing链路追踪​

随着Agent和Workflow的复杂度提升，一个请求可能触发多个模型调用。

例如：

意图识别
 ↓
知识检索
 ↓
模型生成
 ↓
审核模型

如果没有链路追踪，很难知道时间消耗在哪个环节。

因此平台通常会引入类似OpenTelemetry的方案，对整个执行过程进行追踪。

这样可以清晰看到：

• 哪个节点耗时最长
• 哪个工具调用失败
• 哪次检索未命中

从而快速定位问题。

Token统计​

对于企业来说，Token实际上就是成本。

因此平台必须具备完善的Token统计能力。

统计维度通常包括：

• 用户维度
• 应用维度
• 部门维度
• 模型维度
• 租户维度

很多企业在项目初期并不关注Token消耗，等到应用规模扩大后才发现成本增长速度远超预期。

因此从第一天开始建立Token监控体系是非常必要的。

四、多租户设计

当AI平台开始服务多个业务部门时，多租户能力就成为必备功能。

平台通常需要隔离：

• 知识库
• Prompt
• 模型配置
• Agent配置
• 工作流配置

例如：

租户A
 ├─ 知识库A
 ├─ AgentA
 └─ WorkflowA

租户B
 ├─ 知识库B
 ├─ AgentB
 └─ WorkflowB

在数据库设计上，一般会引入TenantId作为核心隔离字段。

所有查询都会自动附带租户条件。

这样既保证数据安全，又能够共享底层基础设施。

五、高并发设计

AI平台与传统系统最大的区别在于，大模型调用耗时通常远高于普通接口。

传统接口可能几十毫秒完成响应。

而模型请求可能需要数秒甚至十几秒。

因此必须从架构层面考虑并发问题。

首先需要采用异步化设计。

对于长时间任务，尽量避免同步阻塞线程。

其次需要引入流式输出。

用户在数百毫秒内看到首个Token，体验会明显提升。

此外还需要建立：

• 模型连接池
• 请求队列
• 熔断降级
• 限流机制

当模型服务出现波动时，系统能够自动保护自身而不是整体崩溃。

在实际生产环境中，很多性能问题并不是数据库瓶颈，而是模型调用能力成为新的系统瓶颈，因此容量规划也需要围绕模型QPS重新设计。

六、未来演进方向

AI平台仍然处于快速发展阶段，很多能力还在持续演进。

MCP​

MCP正在逐渐成为AI工具调用领域的重要标准。

未来企业内部的ERP、CRM、订单系统以及数据平台，都有可能通过MCP协议向Agent开放能力。

这样Agent无需针对每个系统开发专用接口。

A2A​

随着Agent数量增加，Agent之间协同工作将成为新的需求。

A2A（Agent To Agent）希望解决不同Agent之间的通信问题。

例如：

客服Agent
 ↓
物流Agent
 ↓
运营Agent

多个Agent共同完成复杂任务。

未来企业内部很可能会出现大量专业Agent协同工作的场景。

Multi-Agent​

单个Agent的能力终究有限。

对于复杂任务，更合理的方式是让多个Agent分别承担不同职责。

例如：

Planner Agent
 ↓
Research Agent
 ↓
Execution Agent
 ↓
Review Agent

每个Agent负责特定领域的工作，最终形成完整结果。

这种模式已经开始在复杂业务流程中展现出较大的潜力。

总结

企业AI平台建设本质上并不是简单地接入一个大模型接口，而是在模型能力之上构建一套完整的工程体系。从模型管理、知识库管理、工作流编排，到Agent执行框架、可观测性体系以及多租户治理，每一个环节都会直接影响平台最终的稳定性和可扩展性。

对于Java工程师而言，SpringBoot3、LangChain4j、Qdrant、Redis以及Elasticsearch已经能够支撑绝大多数企业AI平台建设需求。而随着MCP、A2A以及Multi-Agent逐渐成熟，未来的AI平台也会从“调用模型”逐步演进为“管理智能体”，这或许才是企业AI建设真正值得投入和长期积累的方向。

很多团队在接触AI开发时，关注点往往集中在模型选型、Prompt设计、RAG实现以及Agent编排等技术问题。

但当AI应用真正进入生产环境后，会发现一个新的问题：

系统上线只是开始，治理才是真正的挑战。

一个内部试点阶段表现优秀的AI系统，当面对数十万用户、数百万次调用时，很容易出现各种问题：

• Prompt被频繁修改导致效果波动
• 知识库内容过期
• 模型成本快速上涨
• 响应时间不稳定
• 输出内容存在风险

因此，企业级AI应用不仅需要开发能力，更需要完善的治理体系。

本文结合实际项目经验，介绍AI应用规模化后的核心治理方案。

一、企业AI项目为什么容易失控

传统软件系统的逻辑是确定性的。

例如：

if(score > 60){
    return "pass";
}

同样的输入永远得到同样的输出。

但AI系统并不是这样。

AI应用本质上由多个动态组件组成：

用户问题
 ↓
Prompt
 ↓
知识库
 ↓
模型
 ↓
结果输出

其中每个环节都可能发生变化。

例如：

• Prompt调整
• 知识库更新
• Embedding模型升级
• LLM切换版本

这些变化叠加后，很容易导致线上效果不可预测。

因此企业AI治理的目标可以总结为：

让AI系统具备可观测、可控制、可回滚、可审计能力。

二、Prompt治理

Prompt已经成为AI应用中的核心资产。

很多企业AI项目中，Prompt数量甚至超过业务代码。

如果缺乏管理机制，很快就会变成：

prompt_v1
prompt_v2
prompt_v2_final
prompt_v2_final_new
prompt_v2_final_new2

最终没人知道线上到底在运行哪个版本。

1. 版本管理​

Prompt需要像代码一样进行管理。

例如：

name: product_review_reply

version: 1.0.3

description: 商品评价回复Prompt

owner: ai-team

企业通常会将Prompt存储在：

• Git
• 配置中心
• Prompt管理平台

每次修改都记录：

• 修改人
• 修改时间
• 修改内容
• 影响范围

这样出现问题时能够快速回滚。

2. 灰度发布​

Prompt修改后不要直接全量上线。

推荐采用：

新Prompt
   ↓
5%流量
   ↓
20%流量
   ↓
50%流量
   ↓
100%流量

重点观察：

• 用户满意度
• 点击率
• 人工接管率
• 回复准确率

如果指标下降，可以立即回退。

这种方式与传统互联网系统的灰度发布完全一致。

三、知识库治理

很多团队认为：

只要搭建RAG，知识库问题就解决了。

实际上知识库往往是AI项目中最容易失效的部分。

1. 增量更新​

企业文档每天都在变化。

例如：

• 商品信息更新
• 仓储规则调整
• 物流政策变化
• 售后流程修改

如果每次都全量重建向量库：

重新解析
 ↓
重新切Chunk
 ↓
重新Embedding
 ↓
重新写入

成本会非常高。

因此需要增量更新机制：

文档变更
 ↓
变更检测
 ↓
重新切分
 ↓
更新向量

仅更新变化部分。

这样能够显著降低Embedding成本。

2. 文档质量检查​

很多RAG效果差，并不是检索问题，而是文档质量问题。

常见问题：

内容重复​

退款流程
退款流程
退款流程

会影响召回结果。

内容缺失​

商品保质期：

关键信息为空。

OCR错误​

七天无理由退货

↓

七天无理由退贷

Embedding后会产生错误语义。

上线前建议增加文档质检流程：

上传文档
 ↓
格式检查
 ↓
内容检查
 ↓
重复检查
 ↓
入库

从源头保证知识质量。

四、模型治理

企业级AI系统通常不会依赖单一模型。

原因很简单：

• 成本不同
• 性能不同
• 稳定性不同

因此需要模型治理能力。

1. 模型路由​

典型架构：

用户请求
 ↓
Router
 ├─ GPT
 ├─ DeepSeek
 ├─ Qwen
 └─ Claude

根据任务自动选择模型。

例如：

简单问答​

使用低成本模型：

DeepSeek-V4-Flash

复杂推理​

使用高性能模型：

GPT
Claude

内容审核​

使用专门审核模型。

这样能够平衡：

• 效果
• 延迟
• 成本

2. 降级策略​

模型服务不可能100%稳定。

需要设计降级链路：

GPT
 ↓
DeepSeek
 ↓
Qwen
 ↓
规则回复

例如：

try{
    return gpt.generate();
}catch(Exception e){
    return deepseek.generate();
}

即使上游服务异常，也能保证业务连续运行。

五、成本治理

AI项目进入规模化阶段后，成本往往成为最大的挑战。

很多团队上线后才发现：

Token费用远远超过预期。

1. Token监控​

需要监控：

输入Token
输出Token
请求次数
模型费用

例如：

GPT-4
今日消耗：
1200万Token

费用：
350美元

做到按天、按业务、按用户维度统计。

常见指标：

• Token总量
• 人均Token
• 单次请求成本
• 模型成本排行

2. 缓存机制​

大量请求其实存在重复。

例如：

退货流程是什么？

退货规则是什么？

如何申请退款？

经过标准化后，本质是同一问题。

可以增加缓存层：

Query
 ↓
Cache
 ↓
LLM

命中缓存直接返回结果。

企业实践中：

缓存命中率
20% ~ 50%

并不罕见。

对于高频问答场景，成本下降非常明显。

六、风险治理

AI应用最终面向用户，因此风险治理不可缺少。

1. 敏感词检测​

用户输入可能包含：

• 政治敏感内容
• 违法内容
• 广告内容
• 恶意攻击内容

处理流程：

用户输入
 ↓
敏感词检测
 ↓
风险判断
 ↓
模型调用

高风险内容直接拦截。

2. 内容审核​

除了输入审核，还需要审核模型输出。

因为模型可能产生：

• 幻觉内容
• 错误承诺
• 不当言论
• 违规回复

典型流程：

用户问题
 ↓
LLM生成
 ↓
审核模型
 ↓
输出用户

对于高风险业务：

• 金融
• 医疗
• 法律

通常还会增加：

AI生成
 ↓
人工审核
 ↓
最终发布

确保结果安全可靠。

总结

随着AI应用从PoC走向生产环境，技术重点会逐渐从“如何生成答案”转向“如何稳定运行”。

一个成熟的企业AI治理体系通常包括：

Prompt治理
Knowledge治理
Model治理
Cost治理
Risk治理

前期决定项目能否做出来，

而治理体系决定项目能否长期稳定运行。

一、业务背景

在电商平台中，商品评价不仅影响用户购买决策，也是商家运营的重要数据来源。

以东方甄选为例，每天会产生大量商品评价：

• 好评感谢
• 商品质量反馈
• 物流问题投诉
• 售后服务咨询
• 商品使用建议

随着业务规模增长，商品评价总量已经达到百万级。

传统运营模式下：

• 人工逐条查看评价
• 根据经验编写回复
• 不同运营人员回复风格不统一
• 差评处理效率低

因此我们希望构建一套AI商品评价自动回复系统，实现：

• 自动识别评价内容
• 自动生成回复
• 人工审核后发布
• 提升回复效率和一致性

二、核心流程设计

整个系统采用多阶段AI工作流设计。

评价
 ↓
情感分析
 ↓
意图识别
 ↓
知识库检索
 ↓
Prompt组装
 ↓
多模型生成
 ↓
审核
 ↓
回复

每个节点只负责单一职责。

1. 情感分析​

首先判断评价属于：

• 好评
• 中评
• 差评

例如：

苹果很甜，下次还会买

输出：

{
  "sentiment": "positive"
}

而：

收到时已经坏了

输出：

{
  "sentiment": "negative"
}

情感结果决定后续流程走向。

2. 意图识别​

对于差评，需要进一步识别用户真实诉求。

例如：

水果不甜

识别为：

{
  "intent":"product_quality"
}

快递太慢了

识别为：

{
  "intent":"logistics"
}

客服一直没人回复

识别为：

{
  "intent":"service"
}

通过意图分类，实现后续知识库精准召回。

3. 知识库检索​

根据意图进入对应知识域。

商品知识库​

包含：

• 商品卖点
• 商品参数
• 常见问题

例如：

商品：山东烟台红富士

糖度：
13%-15%

成熟周期：
10月采摘

物流知识库​

包含：

• 仓储信息
• 发货规则
• 配送规则

售后知识库​

包含：

• 退款规则
• 补发规则
• 客诉处理规范

4. Prompt组装​

系统会动态拼接Prompt。

示例：

你是一名电商客服。

用户评价：
水果不甜。

商品知识：
本商品属于自然成熟水果，
糖度受天气影响较大。

请生成专业且礼貌回复。

Prompt模板统一由运营维护。

5. 多模型生成​

为了保证生成质量，我们采用多模型并行策略。

同时调用：

• DeepSeek
• Qwen
• GPT

生成三份回复。

例如：

回复A：

非常抱歉未能达到您的预期...

回复B：

感谢反馈，我们已将问题同步给供应链团队...

回复C：

水果甜度受天气和批次影响...

6. 人工审核​

AI不直接发送。

运营后台展示：

• 原评价
• 检索知识
• AI回复结果

审核员可：

• 直接采用
• 修改后采用
• 重新生成

确保回复质量可控。

三、Agent工作流设计

项目采用Agent Workflow模式，而非单次Prompt调用。

工作流结构：

ReviewAgent
        │
        ▼
SentimentAgent
        │
        ▼
IntentAgent
        │
        ▼
RetrieverAgent
        │
        ▼
PromptAgent
        │
        ▼
GeneratorAgent
        │
        ▼
AuditAgent

每个Agent负责独立任务。

Java实现中采用：

StateMachine

管理状态流转。

状态定义：

RECEIVED

SENTIMENT_DONE

INTENT_DONE

RETRIEVE_DONE

GENERATED

AUDITING

FINISHED

通过状态机实现：

• 可追踪
• 可重试
• 可扩展

后续增加节点无需重构主流程。

四、知识库设计

知识库是系统效果的关键。

分层结构​

商品知识库

物流知识库

售后知识库

客服话术库

Chunk切分​

采用：

512 Token
+
50 Token Overlap

避免上下文断裂。

检索方案​

Hybrid Search：

Keyword Search
+
Vector Search

优势：

• 保证召回率
• 提高语义匹配能力

ReRank排序​

召回后使用ReRank模型排序。

Top20
 ↓
ReRank
 ↓
Top5

降低噪声数据进入Prompt。

五、多模型对比方案

项目上线前进行了大量AB实验。

评测维度​

准确率​

是否回答用户问题。

礼貌度​

是否符合客服规范。

知识引用率​

是否正确使用检索内容。

幻觉率​

是否编造事实。

最终采用：

DeepSeek
+
Qwen

作为主模型。

复杂场景降级切换GPT。

六、效果评估

项目上线后进行了持续监控。

运营效率提升​

回复效率：

人工回复：
30秒/条

AI辅助：
5秒/条

效率提升约80%。

自动采纳率​

AI回复直接采纳率

≈ 75%

差评处理时效​

从：

24小时

缩短到：

2小时以内

成本收益​

整体运营成本下降约：

60%

同时保持回复质量稳定。

总结

AI商品评价自动回复系统本质上并不是简单的大模型问答，而是一个融合了：

• Agent工作流
• RAG知识库
• Prompt工程
• 多模型协同
• 人工审核

的企业级AI应用。

对于开发者而言，真正的挑战也并非调用大模型API，而是如何构建一套稳定、可扩展、可治理的AI工作流系统。

随着大模型能力不断增强，越来越多企业开始尝试构建自己的 AI Agent。然而在真实业务场景中，很多团队很快会发现：

一个大模型 + 一个Agent，远远无法支撑复杂企业流程。

真正能够落地生产环境的，往往不是单个 Agent，而是一套可编排、可治理、可审计的 Agent Workflow（Agent工作流）。

本文将从工程视角介绍企业级 Agent 工作流设计思想。

1. 为什么单Agent不够

很多初学者理解的 Agent：

用户问题
    ↓
    LLM
    ↓
调用工具
    ↓
返回结果

例如：

用户：

帮我查询订单状态

Agent：

调用订单系统API
↓
获取结果
↓
生成回复

这种模式适合简单任务。

但企业真实场景往往更加复杂：

例如客服场景：

用户投诉商品质量
    ↓
识别情绪
    ↓
识别意图
    ↓
查询订单
    ↓
查询商品知识库
    ↓
生成处理方案
    ↓
人工审核
    ↓
发送回复

此时问题出现：

• 多步骤依赖
• 多系统调用
• 多个模型协作
• 需要人工介入
• 需要失败重试
• 需要审计日志

如果全部交给一个 Agent 自主决策：

Agent自己思考
Agent自己决定
Agent自己调用工具

将产生：

• 不稳定
• 不可预测
• 难以调试
• 难以监管

因此企业更倾向于：

Agent能力
+
Workflow编排

而不是完全自治 Agent。

2. 工作流与Agent区别

很多人容易混淆 Workflow 和 Agent。

Agent​

核心特点：

自主决策

执行过程：

Thought
Action
Observation
Thought
Action
Observation

Agent每一步都由模型决定。

例如：

用户：
帮我分析这个客户

Agent可能：

查CRM
↓
查订单
↓
查聊天记录
↓
生成报告

整个路径是不确定的。

Workflow​

核心特点：

流程确定

例如：

情绪分析
 ↓
意图识别
 ↓
知识库检索
 ↓
生成回复
 ↓
人工审核

路径提前定义。

模型只负责某个节点能力。

企业为什么偏爱Workflow​

因为：

可观测
可调试
可回放
可审计
可治理

生产环境稳定性远比智能程度更重要。

因此很多企业Agent本质上是：

Workflow + Agent

而不是纯Agent。

3. LangGraph思想

目前最火的 Agent Workflow 框架之一是：

LangGraph

它的核心思想非常简单：

Graph
=
Node + Edge

即：

节点 + 连线

例如：

用户输入
    ↓
意图识别
    ↓
知识库检索
    ↓
答案生成

对应：

Node A
 ↓
Node B
 ↓
Node C

LangGraph进一步增加：

状态​

State

条件路由​

Conditional Edge

循环​

Loop

例如：

生成答案
    ↓
质量检查
    ↓
不合格
    ↓
重新生成

形成闭环。

4. 状态机设计

企业级Agent最重要的设计其实不是Prompt。

而是：

State

状态管理。

例如客服工作流：

public class CustomerServiceState {

    private String userQuestion;

    private String sentiment;

    private String intent;

    private List<Document> documents;

    private String draftReply;

    private boolean needHumanReview;

}

整个流程都围绕 State 展开。

流程执行：

节点1
更新 sentiment
↓
节点2
更新 intent
↓
节点3
更新 documents
↓
节点4
更新 draftReply

最终形成：

共享上下文

而不是节点之间互相传参数。

推荐原则：

节点无状态
状态集中管理

这样：

• 易扩展
• 易测试
• 易回放

5. 条件路由

企业流程一定会出现分支。

例如：

好评
↓
自动感谢

差评
↓
进入售后处理

路由节点：

if(sentiment.equals("positive")){
    goto(POSITIVE_FLOW);
}else{
    goto(NEGATIVE_FLOW);
}

流程图：

          情绪分析
             ↓
      ┌──────┴──────┐
      ↓             ↓
    好评          差评
      ↓             ↓
 自动回复      售后处理

再比如：

意图识别：

物流问题
商品问题
退款问题
发票问题

分别路由：

物流Agent
商品Agent
退款Agent
财务Agent

形成多Agent协作架构。

6. 人工审核节点

这是企业落地中极其重要的一环。

很多团队上线Agent失败的原因：

没有Human-in-the-Loop

即：

人工介入能力

典型设计：

生成回复
 ↓
风险检测
 ↓
人工审核
 ↓
发送用户

高风险场景：

金融​

贷款审批
投资建议

医疗​

诊断建议
用药建议

客服​

赔偿金额
退款金额

审核节点设计：

public class ReviewNode {

    public ReviewResult review(State state){

        if(state.isHighRisk()){
            return WAIT_HUMAN;
        }

        return PASS;
    }

}

企业往往还会提供：

通过
驳回
修改后通过

三种操作。

形成：

Human Approval Workflow

7. 企业客服Agent案例

下面以电商客服Agent为例。

整体架构​

用户评价
    ↓
情感分析
    ↓
意图识别
    ↓
条件路由

好评流程​

好评
 ↓
商品知识库
 ↓
生成感谢回复
 ↓
自动发送

差评流程​

差评
 ↓
意图识别

可能识别：

水果不甜
物流太慢
包装破损
售后问题

进入对应Agent：

商品Agent
物流Agent
售后Agent

各Agent执行：

RAG检索
 ↓
知识增强
 ↓
Prompt组装
 ↓
生成回复

随后进入：

风险检测
 ↓
人工审核
 ↓
发送用户

整体流程图：

                用户评价
                    ↓
                情感分析
                    ↓
          ┌─────────┴─────────┐
          ↓                   ↓
         好评               差评
          ↓                   ↓
      自动感谢          意图识别
                              ↓
                ┌──────┬──────┬──────┐
                ↓      ↓      ↓
            商品Agent 物流Agent 售后Agent
                ↓
             RAG检索
                ↓
             回复生成
                ↓
             风险检测
                ↓
             人工审核
                ↓
             回复用户

总结

企业级 Agent 的核心并不是让模型拥有无限自主能力，而是将大模型能力嵌入到可治理的业务流程中。

一个成熟的企业 Agent 系统通常具备：

• Workflow编排
• 状态机管理
• 条件路由
• 多Agent协作
• RAG知识增强
• Human-in-the-Loop
• 全链路日志与审计

当 Agent 与工作流结合后，AI 才真正具备进入企业核心业务系统的能力。

最近尝试着把原来基于 LangChain4j 的串行流程改造成 LangGraph 工作流，遇到了一个问题。 这种场景在实际项目里非常常见，而且很容易让人怀疑是框架 Bug，最后却发现是自己对 LangGraph 状态机制理解不够。

节点明明执行了，状态却丢了

整体流程很简单：

用户评价
    ↓
情感分析
    ↓
意图识别
    ↓
知识库检索
    ↓
回复生成
    ↓
人工审核

因为后面还计划增加条件路由和人工节点，所以决定尝试一下LangGraph。

刚开始开发的时候非常顺利，节点也都跑通了。

结果到了第三个节点突然出现一个特别诡异的问题。

问题现象​

情感分析节点输出正常：

state.put("sentiment", "NEGATIVE");

日志也能看到：

EmotionNode execute
sentiment=NEGATIVE

到了意图识别节点：

String sentiment = state.get("sentiment");

结果直接变成：

null

整个流程继续往下走。

然后生成回复时报错：

java.lang.NullPointerException

第一反应是：

LangGraph状态没有传递成功？

于是开始疯狂排查。

第一轮排查​

先怀疑是不是Spring Bean作用域问题。

因为节点都是：

@Component
public class EmotionNode implements Node

怀疑多个请求共享状态。

于是加日志：

System.out.println(state);

发现每个请求拿到的 state 都不一样。

排除。

第二轮排查​

怀疑是不是异步执行导致。

因为工作流配置里用了：

ExecutorService executor =
    Executors.newFixedThreadPool(10);

于是把线程池全部关掉。

改成单线程。

问题依旧。

第三轮排查​

开始翻官方文档。

看到一句不起眼的话：

State updates are merged using reducers.

当时完全没理解。

继续往下看源码。

发现异常点​

在 LangGraph 中：

节点并不是直接修改全局状态。

而是：

return Map.of(
    "sentiment",
    "NEGATIVE"
);

框架会把节点返回结果合并到 State 中。

而我写成了：

state.put("sentiment", "NEGATIVE");
return state;

看起来没问题。

实际上问题就出在这里。

LangGraph状态机制原理​

很多人第一次接触 LangGraph 都会下意识认为：

Node A
    ↓
修改State
    ↓
Node B读取State

实际上内部更接近：

State
   ↓
Node A
   ↓
Delta
   ↓
Reducer
   ↓
New State

也就是说：

节点返回的是状态增量（Delta）。

框架负责合并。

而不是直接共享同一个对象。

所以：

state.put(...)

只是改了当前节点拿到的对象。

最终状态树未必会使用这个对象。

尤其涉及：

并行节点
条件路由
Checkpoint恢复

时更明显。

为什么设计成这样​

后来读源码才理解。

假设有两个并行节点：

          → NodeB →
NodeA →
          → NodeC →

NodeB返回：

{
    "intent":"物流问题"
}

NodeC返回：

{
    "product":"苹果"
}

框架最后统一合并：

{
    "intent":"物流问题",
    "product":"苹果"
}

如果所有节点都直接修改同一个对象：

sharedState

那么并发冲突会非常严重。

所以 LangGraph 采用：

节点输出
    ↓
Reducer
    ↓
新State

的不可变状态思想。

这其实和 React 的 State 更新逻辑很像。

真正解决方案​

节点不要修改原 State。

只返回变更内容。

错误写法：

public Map<String,Object> execute(
    Map<String,Object> state){

    state.put("sentiment","NEGATIVE");

    return state;
}

正确写法：

public Map<String,Object> execute(
    Map<String,Object> state){

    return Map.of(
        "sentiment",
        "NEGATIVE"
    );
}

再次执行：

EmotionNode execute
sentiment=NEGATIVE

IntentNode execute
sentiment=NEGATIVE

恢复正常。

第二个隐藏坑：字段覆盖​

问题解决后没两天又遇到一个新坑。

知识库检索节点：

return Map.of(
    "documents",
    docs
);

生成节点：

return Map.of(
    "documents",
    rerankDocs
);

结果发现最终 State 中只剩下：

rerankDocs

原始召回结果消失。

最开始以为是框架缓存问题。

后来发现是 Reducer 默认行为。

默认情况下：

同名字段
=
后写覆盖前写

即：

documents = newValue

而不是：

documents.addAll(...)

为什么官方一直强调Reducer​

看到这里终于理解官方文档为什么一直在讲：

Reducer
State Schema
Merge Strategy

因为 LangGraph 本质上不是流程编排框架。

而是：

状态驱动框架

流程只是表象。

State 才是核心。

所有节点都围绕 State 演化。

这也是它和传统工作流引擎最大的区别。

这个坑背后的启示​

这次问题前后排查了接近两个小时。

从 Spring Bean、线程池、异步执行一路查到 LangGraph 源码，最后发现根本不是框架问题，而是自己把 LangGraph 当成了普通责任链模式来理解。

如果把 LangGraph 看成：

Node1
 ↓
Node2
 ↓
Node3

很多设计都会觉得奇怪。

但如果换个视角：

State
 ↓
Node
 ↓
State
 ↓
Node
 ↓
State

很多源码设计瞬间就合理了。

最近在做的系统中集成RAG，需要将商品知识库、物流知识库写入Qdrant，实现RAG检索。

技术栈：

Spring Boot
LangChain4j
Qdrant
OpenAI Embedding

整体流程非常简单：

文档
 ↓
Chunk切分
 ↓
Embedding
 ↓
Qdrant存储
 ↓
向量检索
 ↓
LLM生成

结果测试时，出现了一个非常奇怪的问题。

问题现象​

数据写入完全正常。

Qdrant后台也能看到数据：

{
  "id": 1,
  "vector": [...]
}

插入日志：

INFO Insert 5000 points success

但是查询始终为空：

List<ScoredPoint> result = client.search(...)

返回：

[]

完全搜不到数据。

第一轮排查​

怀疑Embedding有问题。

打印向量长度：

Embedding embedding =
    embeddingModel.embed(text).content();

System.out.println(
    embedding.vector().length
);

结果：

1536

正常。

再查看Qdrant Collection：

curl localhost:6333/collections/docs

返回：

{
  "vectors": {
    "size": 1536
  }
}

维度一致。

排除Embedding问题。

第二轮排查​

怀疑相似度阈值过高。

代码：

SearchParams.newBuilder()
    .setHnswEf(128)
    .build();

搜索：

scoreThreshold=0.8

改成：

scoreThreshold=0.3

还是查不到。

第三轮排查​

开始怀疑数据没写进去。

查看point数量：

curl localhost:6333/collections/docs

结果：

{
  "points_count": 5000
}

确实存在。

甚至通过ID查询：

retrieve(1)

也能返回数据。

说明：

数据存在
向量存在
Collection存在

但就是搜不到。

真正原因​

最后查看官方文档才发现问题。

创建Collection时：

VectorParams.newBuilder()
    .setSize(1536)
    .setDistance(Distance.Cosine)

后来项目切换Embedding模型：

bge-large-zh

向量维度变成：

1024

但是Collection没有重建。

此时出现：

Qdrant Collection: 1536维
Embedding结果: 1024维

写入时因为封装层没有显式报错。

查询时：

1536 vs 1024

向量根本不在同一个空间。

自然检索不到结果。

为什么会这样？​

这里涉及Qdrant底层原理。

Qdrant本质上是：

向量ID
↓
向量数组
↓
HNSW索引

例如：

[0.12,0.33,0.55...]

HNSW建立的是固定维度空间。

比如：

1536维空间

所有向量必须：

长度完全一致

否则无法计算：

Cosine Similarity
Euclidean Distance
Dot Product

因为：

A=[1,2,3]

B=[1,2]

数学上根本无法求距离。

所以Qdrant要求：

Collection创建后
Vector Size不可变

深入源码​

Qdrant创建Collection时：

message VectorParams {
  uint64 size = 1;
  Distance distance = 2;
}

对应：

CreateCollection.newBuilder()
    .setCollectionName("docs")
    .setVectorsConfig(...)

最终保存到：

Collection Config

后续所有Point都会校验：

vector.length == size

一旦不一致：

Wrong input vector dimension

或者某些SDK直接吞掉异常。

如何避免​

方案一：启动时校验​

项目启动时读取Collection信息：

CollectionInfo info =
    client.getCollection("docs");

检查：

info.getConfig()
    .getParams()
    .getVectors()
    .getSize();

与Embedding模型配置对比：

1536 == embeddingDimension

不一致直接启动失败。

方案二：Collection版本化​

不要复用Collection。

例如：

knowledge_v1
knowledge_v2
knowledge_v3

Embedding模型升级：

text-embedding-3-small
↓
bge-large-zh

直接创建：

knowledge_v4

重新构建索引。

方案三：记录Embedding模型​

Payload中增加：

{
  "model":"bge-large-zh"
}

检索异常时快速定位：

到底是哪批数据生成的Embedding

后续引出的Qdrant原理​

这个问题解决后，又顺带理解了几个以前没注意的知识点：

Collection为什么不能随便改维度​

因为HNSW索引是基于固定维度建立的。

修改维度意味着：

整个索引失效

必须重建。

为什么Embedding模型不能随便切换​

因为不同模型生成的是不同向量空间：

OpenAI
↓
1536维

BGE
↓
1024维

Jina
↓
768维

即使维度相同：

语义空间也不同

老数据和新数据混存会导致召回效果急剧下降。

为什么RAG要做全量重建​

很多团队升级Embedding后发现：

检索命中率下降

根本原因往往不是Qdrant。

而是：

旧Embedding
+
新Embedding

混在同一个Collection里。

这个案例在真实项目里非常常见，而且很有迷惑性，因为：

数据能写进去
Collection也存在
没有明显报错
查询结果却永远为空

最后定位下来并不是Spring问题，也不是LangChain4j问题，而是Qdrant最核心的设计原则——一个Collection只能对应一个固定维度、固定语义空间的Embedding模型

一个大模型 + 一个Agent，远远无法支撑复杂企业流程。

真正能够落地生产环境的，往往不是单个 Agent，而是一套可编排、可治理、可审计的 Agent Workflow（Agent工作流）。

本文将从工程视角介绍企业级 Agent 工作流设计思想。

1. 为什么单Agent不够

很多初学者理解的 Agent：

用户问题
    ↓
    LLM
    ↓
调用工具
    ↓
返回结果

例如：

用户：

帮我查询订单状态

Agent：

调用订单系统API
↓
获取结果
↓
生成回复

这种模式适合简单任务。

但企业真实场景往往更加复杂：

例如客服场景：

用户投诉商品质量
    ↓
识别情绪
    ↓
识别意图
    ↓
查询订单
    ↓
查询商品知识库
    ↓
生成处理方案
    ↓
人工审核
    ↓
发送回复

此时问题出现：

• 多步骤依赖
• 多系统调用
• 多个模型协作
• 需要人工介入
• 需要失败重试
• 需要审计日志

如果全部交给一个 Agent 自主决策：

Agent自己思考
Agent自己决定
Agent自己调用工具

将产生：

• 不稳定
• 不可预测
• 难以调试
• 难以监管

因此企业更倾向于：

Agent能力
+
Workflow编排

而不是完全自治 Agent。

2. 工作流与Agent区别

很多人容易混淆 Workflow 和 Agent。

Agent​

核心特点：

自主决策

执行过程：

Thought
Action
Observation
Thought
Action
Observation

Agent每一步都由模型决定。

例如：

用户：
帮我分析这个客户

Agent可能：

查CRM
↓
查订单
↓
查聊天记录
↓
生成报告

整个路径是不确定的。

Workflow​

核心特点：

流程确定

例如：

情绪分析
 ↓
意图识别
 ↓
知识库检索
 ↓
生成回复
 ↓
人工审核

路径提前定义。

模型只负责某个节点能力。

企业为什么偏爱Workflow​

因为：

可观测
可调试
可回放
可审计
可治理

生产环境稳定性远比智能程度更重要。

因此很多企业Agent本质上是：

Workflow + Agent

而不是纯Agent。

3. LangGraph思想

目前最火的 Agent Workflow 框架之一是：

LangGraph

它的核心思想非常简单：

Graph
=
Node + Edge

即：

节点 + 连线

例如：

用户输入
    ↓
意图识别
    ↓
知识库检索
    ↓
答案生成

对应：

Node A
 ↓
Node B
 ↓
Node C

LangGraph进一步增加：

状态​

State

条件路由​

Conditional Edge

循环​

Loop

例如：

生成答案
    ↓
质量检查
    ↓
不合格
    ↓
重新生成

形成闭环。

4. 状态机设计

企业级Agent最重要的设计其实不是Prompt。

而是：

State

状态管理。

例如客服工作流：

public class CustomerServiceState {

    private String userQuestion;

    private String sentiment;

    private String intent;

    private List<Document> documents;

    private String draftReply;

    private boolean needHumanReview;

}

整个流程都围绕 State 展开。

流程执行：

节点1
更新 sentiment
↓
节点2
更新 intent
↓
节点3
更新 documents
↓
节点4
更新 draftReply

最终形成：

共享上下文

而不是节点之间互相传参数。

推荐原则：

节点无状态
状态集中管理

这样：

• 易扩展
• 易测试
• 易回放

5. 条件路由

企业流程一定会出现分支。

例如：

好评
↓
自动感谢

差评
↓
进入售后处理

路由节点：

if(sentiment.equals("positive")){
    goto(POSITIVE_FLOW);
}else{
    goto(NEGATIVE_FLOW);
}

流程图：

          情绪分析
             ↓
      ┌──────┴──────┐
      ↓             ↓
    好评          差评
      ↓             ↓
 自动回复      售后处理

再比如：

意图识别：

物流问题
商品问题
退款问题
发票问题

分别路由：

物流Agent
商品Agent
退款Agent
财务Agent

形成多Agent协作架构。

6. 人工审核节点

这是企业落地中极其重要的一环。

很多团队上线Agent失败的原因：

没有Human-in-the-Loop

即：

人工介入能力

典型设计：

生成回复
 ↓
风险检测
 ↓
人工审核
 ↓
发送用户

高风险场景：

金融​

贷款审批
投资建议

医疗​

诊断建议
用药建议

客服​

赔偿金额
退款金额

审核节点设计：

public class ReviewNode {

    public ReviewResult review(State state){

        if(state.isHighRisk()){
            return WAIT_HUMAN;
        }

        return PASS;
    }

}

企业往往还会提供：

通过
驳回
修改后通过

三种操作。

形成：

Human Approval Workflow

7. 企业客服Agent案例

下面以电商客服Agent为例。

整体架构​

用户评价
    ↓
情感分析
    ↓
意图识别
    ↓
条件路由

好评流程​

好评
 ↓
商品知识库
 ↓
生成感谢回复
 ↓
自动发送

差评流程​

差评
 ↓
意图识别

可能识别：

水果不甜
物流太慢
包装破损
售后问题

进入对应Agent：

商品Agent
物流Agent
售后Agent

各Agent执行：

RAG检索
 ↓
知识增强
 ↓
Prompt组装
 ↓
生成回复

随后进入：

风险检测
 ↓
人工审核
 ↓
发送用户

整体流程图：

                用户评价
                    ↓
                情感分析
                    ↓
          ┌─────────┴─────────┐
          ↓                   ↓
         好评               差评
          ↓                   ↓
      自动感谢          意图识别
                              ↓
                ┌──────┬──────┬──────┐
                ↓      ↓      ↓
            商品Agent 物流Agent 售后Agent
                ↓
             RAG检索
                ↓
             回复生成
                ↓
             风险检测
                ↓
             人工审核
                ↓
             回复用户

总结

企业级 Agent 的核心并不是让模型拥有无限自主能力，而是将大模型能力嵌入到可治理的业务流程中。

一个成熟的企业 Agent 系统通常具备：

• Workflow编排
• 状态机管理
• 条件路由
• 多Agent协作
• RAG知识增强
• Human-in-the-Loop
• 全链路日志与审计

当 Agent 与工作流结合后，AI 才真正具备进入企业核心业务系统的能力。

然而很多团队上线后会发现：

• 检索结果不准确
• 明明知识库里有答案却找不到
• 上下文过长导致成本升高
• 用户反馈效果时好时坏

实际上，企业RAG的难点并不在于搭建一个Demo，而在于如何持续优化召回率和答案准确率。

本文结合实际项目经验，介绍企业RAG系统常见的优化方案，以及背后的工程实现思路。

1 Chunk大小如何确定

Chunk（文本切片）是影响RAG效果最关键的因素之一。

很多初学者直接采用：

每500个字符切一块

这种方式虽然简单，但往往效果并不好。

Chunk过小的问题​

例如：

订单已发货。

物流单号：
SF123456789

预计3天送达。

如果切片长度过小：

Chunk1:
订单已发货

Chunk2:
物流单号：SF123456789

Chunk3:
预计3天送达

用户提问：

订单什么时候到？

可能只召回Chunk3。

模型缺少上下文。

Chunk过大的问题​

如果一个Chunk包含：

商品介绍
物流政策
售后政策
优惠券规则
会员权益

Embedding会变得不聚焦。

用户问：

如何退货？

召回结果可能包含大量无关信息。

企业常用策略​

Fixed Size​

固定长度切分

Chunk Size = 500~1000 Tokens
Overlap = 100~200 Tokens

适合：

• FAQ
• 产品说明书
• 运营文档

Sliding Window​

滑动窗口切分

Chunk1 0~500

Chunk2 400~900

Chunk3 800~1300

保留上下文连续性。

适用于：

• 长文档
• 技术手册
• 法律合同

Semantic Chunk​

基于语义切分

例如：

# 售后政策

...
...

# 物流规则

...
...

按标题进行切分。

优点：

• 语义完整
• Embedding质量高
• 召回更准确

实际经验​

企业项目中通常采用：

标题切分
+
滑动窗口
+
最大Token限制

组合方案。

效果往往优于单纯固定长度切分。

2 Hybrid Search

很多团队上线后发现：

只做向量检索

效果并不好。

原因在于：

Embedding擅长理解语义。

但不擅长精确匹配。

Keyword Search​

典型实现：

BM25
ElasticSearch
OpenSearch

例如：

用户搜索：

SKU123456

向量模型未必理解SKU。

但关键词检索能够精准命中。

Vector Search​

流程：

Query
 ↓
Embedding
 ↓
向量检索
 ↓
TopK

适用于：

快递太慢

召回：

物流延迟
配送超时
运输异常

等语义相近内容。

Hybrid Search​

生产环境通常采用：

BM25
+
Vector Search

架构如下：

用户问题

      ↓

BM25召回
--------
向量召回

      ↓

 Merge

      ↓

 ReRank

优势：

• 提高召回率
• 减少漏召回
• 提升长尾问题覆盖率

3 ReRank原理

很多团队误以为：

TopK检索结果
直接喂给LLM

即可。

实际上这是效果下降的重要原因。

为什么需要ReRank​

假设用户提问：

水果不甜怎么办？

检索返回：

A 商品种植基地介绍

B 水果糖度标准

C 售后赔付规则

向量相似度：

A 0.82

B 0.81

C 0.80

差距非常小。

真正最有价值的是：

C 售后赔付规则

但可能排在最后。

ReRank流程​

Query

 +
 
Candidate Docs

      ↓

Cross Encoder

      ↓

重新打分

      ↓

TopN

常见模型​

开源：

• BGE-Reranker
• BCE-Reranker

商业：

• Cohere Rerank

效果提升​

实际项目中：

仅向量召回

准确率：
70%左右

加入ReRank：

80%~90%

属于投入产出比最高的优化手段之一。

4 查询改写（Query Rewrite）

用户的问题往往并不适合直接检索。

例如：

这个东西为什么还没到？

Embedding很难理解：

这个东西

指什么。

Query Rewrite流程​

原始问题

 ↓

LLM改写

 ↓

检索

例如：

这个东西为什么还没到

改写为：

订单物流延迟原因是什么

多轮对话场景​

用户：

苹果怎么样？

助手：

甜度较高。

用户：

那坏了怎么办？

改写后：

苹果收到后腐烂怎么办

才能正确检索。

企业实现​

通常增加一个轻量模型：

Rewrite Model

负责：

• 指代消解
• 上下文补全
• 同义词扩展

降低检索难度。

5 多路召回

大型知识库中，单一路径召回往往不够。

企业通常采用：

Multi Retrieval

常见召回源​

FAQ知识库​

运营维护

商品知识库​

商品属性
商品卖点

售后知识库​

退货规则
赔付规则

业务数据库​

实时查询：

订单状态
物流状态
库存状态

多路召回架构​

     用户问题

        ↓

  Intent Router

        ↓

 FAQ | 商品 | 售后

        ↓

     Merge

        ↓

     ReRank

工程实现​

常见做法：

CompletableFuture

并行召回：

faqRetriever.retrieve();

productRetriever.retrieve();

aftersaleRetriever.retrieve();

最终聚合。

这样能够将整体耗时控制在：

200~500ms

以内。

6 线上效果评估

很多团队上线后面临的问题：

用户说不好用

但不知道哪里出了问题。

因此必须建立评估体系。

Retrieval指标​

Recall@K​

正确答案是否被召回

Recall@5

Recall@10

MRR​

Mean Reciprocal Rank

衡量正确结果排名。

NDCG​

考虑排序质量。

适用于：

ReRank评估

Generation指标​

Answer Correctness​

答案正确率

Groundedness​

答案是否来自知识库

用于评估幻觉。

Faithfulness​

回答是否忠于检索内容。

A/B实验​

线上通常同时运行：

方案A
旧检索策略

方案B
新检索策略

比较：

• 点击率
• 采纳率
• 用户满意度
• 人工评分

总结

企业RAG的优化，本质上是一个搜索工程问题，而不仅仅是大模型问题。

一个成熟的RAG系统通常包含：

Chunk优化
        ↓
Hybrid Search
        ↓
Query Rewrite
        ↓
多路召回
        ↓
ReRank
        ↓
Prompt组装
        ↓
LLM生成
        ↓
效果评估

对于Java工程师而言，真正的竞争力不在于调用一次大模型API，而在于构建一套可扩展、可观测、可持续优化的RAG工程体系。

当知识库规模从几百篇文档增长到几十万篇文档时，决定系统效果的往往不是模型参数，而是检索链路上的每一个工程细节。

上一篇文章介绍了 RAG（Retrieval-Augmented Generation）的整体架构，以及为什么它已经成为企业 AI 应用的标配。

本篇将通过 Java 实战，从零实现一个完整的 RAG 系统，包括：

• 文档解析
• Chunk 切分
• Embedding 向量生成
• Qdrant 存储
• 向量检索
• 大模型生成最终答案

最终实现如下流程：

用户问题
    ↓
Embedding
    ↓
Qdrant向量检索
    ↓
获取相关知识片段
    ↓
Prompt组装
    ↓
LLM生成答案

技术栈：

• Spring Boot 3
• LangChain4j
• OpenAI Compatible API
• Qdrant
• Apache POI
• PDFBox

1. 文档解析

企业知识库中的数据通常来自：

• PDF
• Word
• Markdown
• Wiki
• Excel

第一步需要将这些文档统一转换成纯文本。

PDF解析​

使用 PDFBox：

<dependency>
    <groupId>org.apache.pdfbox</groupId>
    <artifactId>pdfbox</artifactId>
    <version>3.0.2</version>
</dependency>

public String parsePdf(File file) throws IOException {

    try (PDDocument document = Loader.loadPDF(file)) {

        PDFTextStripper stripper = new PDFTextStripper();

        return stripper.getText(document);
    }
}

Word解析​

使用 Apache POI：

<dependency>
    <groupId>org.apache.poi</groupId>
    <artifactId>poi-ooxml</artifactId>
</dependency>

public String parseWord(File file) throws Exception {

    try (XWPFDocument document =
             new XWPFDocument(new FileInputStream(file))) {

        return document.getParagraphs()
                .stream()
                .map(XWPFParagraph::getText)
                .collect(Collectors.joining("\n"));
    }
}

Markdown解析​

Markdown最简单：

String content = Files.readString(
        Path.of("rag.md"));

统一抽象：

public interface DocumentParser {

    String parse(File file);
}

这样后续新增 Excel、HTML、Wiki 解析器也非常方便。

2. Chunk切分策略

大模型无法一次读取几十万字文档。

因此需要将文档拆分成多个 Chunk。

Fixed Size​

最简单方案：

每500字符
切一次

示例：

public List<String> split(
        String text,
        int chunkSize) {

    List<String> chunks = new ArrayList<>();

    for (int i = 0; i < text.length(); i += chunkSize) {

        chunks.add(
                text.substring(
                        i,
                        Math.min(
                                i + chunkSize,
                                text.length()
                        )
                )
        );
    }

    return chunks;
}

优点：

• 实现简单
• 速度快

缺点：

• 容易截断语义

Sliding Window​

生产环境最常见。

Chunk1
[1-500]

Chunk2
[400-900]

Chunk3
[800-1300]

重叠部分保留上下文。

public List<String> split(
        String text,
        int chunkSize,
        int overlap) {

    List<String> chunks = new ArrayList<>();

    for (int i = 0;
         i < text.length();
         i += chunkSize - overlap) {

        chunks.add(
                text.substring(
                        i,
                        Math.min(
                                i + chunkSize,
                                text.length()
                        )
                )
        );
    }

    return chunks;
}

推荐：

Chunk Size = 500~1000 Token
Overlap = 100~200 Token

Semantic Chunk​

按照语义切分。

例如：

# 商品评价系统

介绍...

# AI回复系统

介绍...

切分结果：

Chunk1
商品评价系统

Chunk2
AI回复系统

LangChain4j 已经提供相关实现：

DocumentSplitter splitter =
        DocumentSplitters.recursive(
                500,
                100
        );

企业知识库一般采用：

语义切分
+
Sliding Window

效果最佳。

3. Embedding生成

Chunk完成后，需要生成向量。

<dependency>
    <groupId>dev.langchain4j</groupId>
    <artifactId>langchain4j-open-ai</artifactId>
</dependency>

配置Embedding模型：

@Bean
EmbeddingModel embeddingModel() {

    return OpenAiEmbeddingModel.builder()
            .baseUrl(baseUrl)
            .apiKey(apiKey)
            .modelName("text-embedding-v4")
            .build();
}

生成向量：

Embedding embedding =
        embeddingModel.embed(text)
                .content();

float[] vector = embedding.vector();

返回结果：

[0.123,
 0.555,
 -0.233,
 ...]