Spring Boot 后台接入 AI 能力：低成本内部落地方案

TPBoreas

328人浏览 · 2026-07-09 17:13:25

TPBoreas · 2026-07-09 17:13:25 发布

5 类能力：

场景	本质能力
AI 待办	自然语言理解 + 任务结构化 + 提醒/执行
AI 处理文件事务	文档解析 + 信息抽取 + 业务动作触发
AI 流程	意图识别 + 流程编排 + 节点决策
语义识别	NLU / 分类 / 实体抽取
文件检索	RAG（检索增强生成）+ 向量检索

内部项目最大的优势：不必追求通用 SaaS 能力，可以按部门场景做深、做窄，成本能控很多。

一、总体架构（建议分层，不要一把梭）

核心原则：

业务系统不直接调大模型，统一走 AI 接入层
按场景拆能力，不要一个「万能 AI 接口」
能检索的不全量喂给模型，能规则化的不全用模型
内部项目优先「够用 + 可控成本」，不追求最前沿

二、你需要新增哪些功能模块？

模块 1：AI 网关 / AI 编排层（必做）

这是整个方案的「中枢」，建议作为 Spring Boot 里的独立模块或独立服务。

职责：

统一接收 AI 请求（聊天、文件处理、流程触发）
统一鉴权、限流、日志、审计
管理 Prompt 模板（按场景切换）
决定走「直接问答 / RAG 检索 / 工具调用 / 流程引擎」
统一封装各家大模型 API，避免业务代码散落调用

为什么必做：
否则每个业务模块自己调模型，后期 Prompt 混乱、成本不可控、无法审计。

模块 2：Prompt 与场景模板管理（必做）

内部项目也要做，但可以做得很轻。

建议管理的场景模板：

场景	模板用途
AI 待办	把自然语言转成待办字段
文件事务	从合同/报销单/通知里抽关键信息
AI 流程	判断用户意图，决定走哪个流程
语义识别	分类、实体抽取、情感/意图判断
文件检索	检索后组织回答

低成本做法：

先放数据库或 YAML 配置，不必一开始做可视化平台
每个场景 1～3 个固定 Prompt 就够
版本号 + 修改记录即可

模块 3：文档处理中心（强烈建议）

服务于：AI 处理文件事务 + 文件检索

需要的能力：

能力	说明
文件上传与存储	对接现有 OSS/MinIO/本地存储
格式解析	PDF、Word、Excel、PPT、图片
文本切块	长文档切片，便于检索
OCR（可选）	扫描件、图片文字识别
元数据提取	文件名、上传人、部门、业务类型
异步处理	大文件解析走 MQ，不阻塞接口

推荐策略：

结构化文件（Excel 表格）→ 优先程序解析，不全扔给 AI
半结构化（合同、通知）→ 解析 + AI 抽取
非结构化（会议纪要）→ 解析 + 摘要 + 入库检索

模块 4：向量检索 / RAG 服务（文件检索必做）

文件检索如果只靠关键词搜索，效果一般；要做「语义检索」，就需要 RAG。

组成：

文件上传 → 解析文本 → 切块 → Embedding 向量化 → 存入向量库
用户提问 → 问题向量化 → 检索相关片段 → 拼 Prompt → 大模型回答

你需要新增：

Embedding 服务（文本转向量）
向量数据库
检索策略（TopK、相似度阈值、重排序）
引用溯源（回答附带原文档片段，方便内部审计）

低成本向量库选择：

方案	成本	适合
PostgreSQL + pgvector	很低	数据量中小，已有 PG 更佳
Milvus 单机	低	文档量较大
Elasticsearch 向量检索	中	已有 ES，可复用
云向量库	中高	不想自建运维

内部项目建议：文档量 < 几十万片段，优先 pgvector 或 Milvus 单机。

模块 5：语义识别服务（可复用）

多个场景都会用到，建议独立成通用能力。

建议拆成 4 个子能力：

子能力	用途	示例
意图识别	判断用户想干什么	「帮我提报销」→ 发起报销流程
文本分类	文件/消息归类	合同、发票、通知、会议纪要
实体抽取	抽结构化字段	金额、日期、对方单位、项目名称
语义匹配	相似问题/相似文档	找类似历史案例

降本技巧：

高频固定意图 → 先用规则/关键词
分类场景稳定后 → 可训练小模型或微调
复杂抽取再上 LLM

模块 6：AI 待办服务

目标：用户说一句话，系统自动生成待办，并可关联业务。

需要的能力：

自然语言输入解析
待办字段结构化（标题、截止时间、负责人、优先级、关联业务）
与现有待办/任务系统对接
可选：到期提醒、自动跟进、状态变更建议

流程建议：

用户输入
→ 语义识别（意图=创建待办）
→ LLM 抽取待办字段
→ 规则校验（负责人是否存在、时间是否合法）
→ 写入现有待办表
→ 返回确认信息

注意：
AI 只负责「理解 + 建议」，最终创建待办建议保留人工确认，内部系统更稳妥。

模块 7：AI 文件事务服务

目标：上传文件后，AI 自动完成分类、填单、发起流程、归档等事务。

典型场景：

上传合同 → 自动识别甲乙方、金额、期限 → 生成合同登记
上传发票 → 识别金额税号 → 发起报销
上传会议纪要 → 提取决议事项 → 生成待办
上传审批附件 → 判断附件类型是否齐全

需要的能力：

文档分类
关键信息抽取
业务规则校验
调用现有业务 API（创建单据、发起流程）
人工确认页（AI 预填 + 用户修改）

推荐模式：AI 预填 + 人工确认，不要全自动直通，内部项目风险低很多。

模块 8：AI 流程服务

目标：用自然语言驱动流程，或让 AI 辅助流程决策。

两种玩法：

玩法 A：自然语言发起流程（性价比高）

「我要申请采购笔记本，预算 8000」

→ 意图识别

→ 匹配流程模板（采购申请）

→ 自动填表

→ 发起审批

玩法 B：流程节点 AI 辅助（更实用）

审批前自动摘要申请内容
自动判断风险点
给审批人建议意见
自动归类附件

不建议一开始做：
让 AI 完全自主决定流程走向（成本高、风险大、难审计）。

更稳的做法：

现有流程引擎（Flowable / Camunda / 自研）继续负责流转
AI 只做：识别意图、填参数、生成摘要、推荐审批意见

模块 9：工具调用 / Agent 能力（中期再加）

当你希望 AI 不只「说」，还能「做事」，就需要工具调用。

可注册给 AI 的内部工具示例：

查询待办
创建待办
查询文件
发起流程
查用户信息
查项目/客户/合同

内部项目建议：

第一阶段：不做自由 Agent
第二阶段：做「固定场景 Agent」
- 例如：AI 秘书、AI 文件助手、AI 流程助手
每个 Agent 只允许调用白名单接口

这样比开放式 Agent 成本低、可控得多。

模块 10：审计、权限、成本控制（必做）

内部项目反而更要重视，因为涉及公司数据。

必须具备：

能力	原因
操作审计	谁问了什么、用了哪个文件、生成了什么结果
数据权限	只能检索本部门/本人有权限的文件
敏感信息脱敏	手机号、身份证、薪资等
调用限额	每人每天调用次数、每部门 Token 配额
模型调用日志	方便排错和优化 Prompt
人工复核	关键业务动作必须确认

三、模型怎么选，成本更低？

内部项目建议「云 API 为主 + 本地开源为辅」的混合策略。

1. 大模型（生成、理解、抽取）

优先考虑国内 API，成本和接入都更友好：

模型	适合场景	成本特点
通义千问	通用理解、中文办公场景	国内性价比高
文心一言	通用问答、文档理解	国内生态好
智谱 GLM	抽取、对话	价格适中
DeepSeek	推理、代码、复杂理解	当前性价比很高

建议：

日常办公场景：选中 1 家主模型即可，不要多模型并存
复杂推理少量使用：可备一个便宜模型兜底

2. Embedding 模型（文件检索必用）

方案	说明
云厂商 Embedding API	省事，按量计费
开源本地 Embedding	成本低，适合大量文档

文档量大的内部系统，Embedding 本地化往往比 LLM 本地化更划算。

3. 小模型 / 规则（降本关键）

这些场景尽量别用大模型：

固定意图识别（「创建待办」「发起流程」）
文件类型判断（pdf/doc/xls）
简单字段校验
关键词检索
模板化回复

经验法则：

能用规则解决的，不上模型；
能用小模型的，不上大模型；
必须用大模型的，尽量先做 RAG，少喂全文。

四、结合你现有 Spring Boot 框架，怎么接入最省事？

你现在是 Spring Boot 后台，建议采用「业务系统 + AI 模块」，而不是推翻重来。

为什么建议独立 ai-module？

不污染原有业务代码
模型供应商切换方便
Prompt、日志、限流集中管理
后期可拆成独立 ai-service

与现有系统的关系

现有系统	AI 如何接入
待办系统	AI 生成草稿，确认后写入
文件系统	上传后异步解析入向量库
流程系统	AI 识别意图并预填表单
权限系统	检索和工具调用都走原权限
消息系统	AI 处理结果通过通知推送

五、每个场景对应的最小实现方案

场景 1：AI 待办

最小方案：

一个对话入口
意图识别：创建待办 / 查询待办 / 修改待办
LLM 抽字段
调现有待办 API 创建

需要的功能：

Prompt 模板
语义识别
业务 API 对接
人工确认

不需要一开始做：

复杂 Agent
自动执行所有办公动作

场景 2：AI 处理文件事务

最小方案：

文件上传
文档解析
文档分类 + 字段抽取
生成业务草稿
人工确认提交

需要的功能：

文档处理中心
OCR（按需）
抽取 Prompt
业务单据映射规则

关键点：

先挑 1～2 种高频文件做透，比如「合同」「报销单」
不要一开始支持所有文件类型

场景 3：AI 流程

最小方案：

用户自然语言描述需求
匹配流程模板
AI 填表
调用原流程引擎发起

需要的功能：

意图识别
流程模板映射表
参数抽取
流程引擎对接

更划算的方向：

先做「自然语言发起流程」
再做「审批摘要 / 风险提示」

场景 4：语义识别

最小方案：

提供统一 NLU 接口
支持：分类、意图、实体抽取
给 AI 待办、AI 流程、文件事务复用

建议做成基础能力，不要每个业务各写一套。

场景 5：文件检索

最小方案：

文件上传后自动入库向量库
用户自然语言提问
检索相关片段
LLM 基于片段回答，并返回引用文件

需要的功能：

文档切块
Embedding
向量库
RAG 检索
权限过滤

这是最值得优先做的能力之一，因为能立刻提升内部知识查找效率，投入产出比高。

六、低成本技术选型建议

必选组件

组件	建议
后端框架	现有 Spring Boot
大模型	1 家国内 API（通义 / DeepSeek 二选一）
Embedding	云 API 起步，量大后本地化
向量库	PostgreSQL+pgvector 或 Milvus 单机
文件存储	现有 OSS/MinIO
异步任务	Redis + MQ（RabbitMQ 即可）
文档解析	Apache Tika / pdfbox / poi + OCR 按需
缓存	Redis
审计日志	MySQL

可暂缓组件

组件	原因
自研 Agent 平台	早期不需要
模型微调	先用 Prompt + RAG
复杂可视化 Prompt 平台	先用配置表
多模型路由平台	一家主模型够用
独立 AI 前端框架	先嵌到现有后台页面

七、成本怎么控？

1. 按场景计费，不按「全站 AI 化」

先上 3 个高价值场景：

文件检索（知识问答）
AI 文件事务（自动填单）
AI 待办（自然语言创建任务）

流程类 AI 可以第三批再上。

2. 控制 Token 消耗

文档检索只喂 Top 3～5 片段，不喂全文
长文档先摘要，再问答
相同问题走缓存
高频模板回复不走模型

3. 异步化重任务

这些操作不要同步调用大模型：

大文件解析
批量入库
长文档摘要
历史文件重建索引

4. 权限前置过滤

检索前先按部门/项目过滤，减少无效检索和胡答。

5. 内部项目可自建一部分

自建	外包/API
向量库	大模型生成
文档解析	OCR（看量）
Embedding（量大时）	复杂推理
流程编排	—

八、推荐实施路线（最省钱）

第一期（1～2 个月）：打地基

目标：先让 AI 能查文件、能答问题

建 ai-module
接入 1 家大模型 API
文档上传解析
向量检索 RAG
权限过滤 + 审计日志

交付效果：

「这份合同付款条件是什么？」
「上周会议纪要里有哪些待办？」
「找一下关于 XX 项目的采购文件」

第二期（1～2 个月）：接业务

目标： AI 能帮你干活，但不越权

AI 待办
AI 文件事务预填
自然语言发起流程
人工确认机制

交付效果：

一句话创建待办
上传发票自动生成报销草稿
说一句话发起请假/采购流程

第三期（按需）：增强智能化

审批摘要与风险提示
固定场景 Agent
部门知识库
调用统计与成本看板
模型效果评估

九、你这个项目建议重点加的 8 个功能

按优先级排序：

优先级	功能	价值
P0	AI 统一接入层	后续所有能力基础
P0	文档解析与入库	文件事务和检索都依赖
P0	向量检索 RAG	文件语义检索核心
P0	权限与审计	内部项目必做
P1	语义识别服务	待办/流程/文件分类复用
P1	Prompt 场景管理	控效果、控成本
P1	AI 待办	用户感知强
P2	AI 流程辅助	提升审批效率

十、一个务实的最终方案

如果你现在要的是「能落地、成本低、别折腾」，我建议你这样定：

架构定案

继续在 Spring Boot 上加独立 ai-module
大模型用 1 家国内 API
文件检索用 RAG + 向量库
业务流程继续走你现有流程引擎
AI 只做：理解、抽取、检索、预填、摘要
关键动作全部人工确认

能力定案

场景	实现方式
AI 待办	NLU + 字段抽取 + 待办 API
AI 文件事务	文档解析 + 分类抽取 + 业务草稿
AI 流程	意图识别 + 模板映射 + 流程发起
语义识别	独立基础服务
文件检索	向量库 + RAG