概要

提到企业大模型应用，很多方案的第一反应都是：把资料放进向量数据库，搭一套 RAG，再做一个聊天页面。

RAG 很有价值，但它解决的是“从非结构化知识中找到相关证据，并辅助模型生成回答”。如果业务真正需要的是精确计算、实时查询、流程执行或规则判断，先上 RAG 反而可能绕远路。

在企业智能问数、知识检索和自动诊断报告的实践中，我越来越倾向于先判断任务类型，再决定使用 RAG、工具调用、规则引擎还是普通软件功能。

场景一：答案必须来自实时结构化数据

例如：

• 查询本月某区域销售额；
• 统计当前库存、订单和告警数量；
• 对比两个时间段的转化率；
• 按组织、产品和客户层级聚合数据。

概要

企业知识库项目最常见的错觉是：上传几份文档，问几个预先准备好的问题，模型回答得像模像样，于是大家认为项目已经完成了大半。

但 Demo 能回答，不等于系统有人用；有人试用，也不等于能够进入真实业务流程。

我参与过企业智能问数、卡片检索和诊断报告类 AI 应用的设计与交付。实践中真正困难的部分通常不是“把向量数据库接上”，而是让知识、检索、权限、评测和业务动作形成一个可以长期运营的闭环。

本文总结企业知识库从 Demo 走向生产时最容易忽略的五个问题。

一、Demo 验证的是技术链路，用户需要的是任务结果

高级 Java 与 AI 应用工程（六）：企业运营诊断 AI Copilot 架构

架构定位

本章以企业运营诊断 AI Copilot 为例，展示 Java 服务、DDD、消息、检索、LLM 工具调用、实时推送、工作流与 DevOps 如何形成一个完整系统。它不是特定业务的唯一实现，而是一份可用于架构设计和面试阐述的参考蓝图。

这个项目将 Java、Spring、DDD、Redis、RabbitMQ、Elasticsearch、工作流、LLM Function Calling、MCP、SSE、性能与 DevOps 串成一条完整链路。

高级 Java 与 AI 应用工程（四）：LLM、RAG、Function Calling 与 MCP

技术定位

企业 AI 应用的本质是将概率模型嵌入确定性系统：程序负责身份、权限、数据、工具与审计，模型负责语言理解、归纳和受约束的决策。RAG 解决知识与事实来源，Function Calling/Skill 解决受控动作，MCP 解决工具互操作，评测与观测解决持续可信。

1. 从“聊天”到“业务系统”

LLM 擅长语言理解、信息抽取、归纳与受约束的决策；它不天然可靠、不了解实时数据，也不具备权限。生产系统应把模型放在受控流程中：模型负责推理，程序负责权限、数据、动作和校验。