《FDE前沿部署工程师实战教程》06 - AI Engineering基础：从LLM到RAG的完整技术体系

原创于 2026-09-03 14:07:54 发布 · 150 阅读

0 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

收录于

FDE前沿部署工程师实战教程

FDE真正区别于传统软件工程师的核心能力之一，就是AI Engineering。

但AI Engineering并不等于“会调用一个大模型API”。

一个真正能够落地企业业务的AI系统，通常需要经历：

LLM → Prompt → Structured Output → Embedding → RAG → Vector Database → Tool Calling → Agent → Workflow → MCP → Evaluation → Guardrails → AI Application

本篇将从最基础的LLM开始，一步一步建立完整的AI Engineering知识体系，并最终理解：

如何把一个大语言模型变成真正能够解决企业业务问题的AI应用。

一、什么是AI Engineering？

过去的软件工程主要解决：

如何让计算机按照确定的规则执行任务。

例如：

用户下单
 ↓
检查库存
 ↓
扣减库存
 ↓
生成订单
 ↓
支付

流程通常比较确定。

而AI Engineering面对的是：

如何让系统理解自然语言、处理非结构化信息，并根据上下文完成复杂任务。

例如：

用户：

“帮我分析一下最近库存异常的SKU，
并告诉我哪些商品需要补货。”

AI系统需要：

理解问题
 ↓
获取数据
 ↓
分析数据
 ↓
判断异常
 ↓
计算补货需求
 ↓
生成结果

这已经不是简单的CRUD。

因此产生了：

AI Engineering

它关注的是：

如何把AI模型、数据、工具、业务系统和软件工程结合起来，构建可靠的AI应用。

二、AI Engineering完整技术地图

可以把整个体系理解成：

这张图可以看成FDE的AI技术路线图。

三、第一层：LLM

AI Engineering的起点是：

LLM

Large Language Model，即大语言模型。

例如：

GPT
Claude
Gemini
Llama
Qwen
DeepSeek

不同模型在：

推理
编程
长上下文
多模态
成本
速度
工具调用

等方面存在差异。

FDE不需要掌握所有模型。

但必须理解：

如何根据业务场景选择合适的模型。

四、LLM到底解决什么问题？

LLM最核心的能力可以理解成：

输入自然语言
        ↓
理解上下文
        ↓
推理
        ↓
生成结果

例如：

用户：

为什么今天仓库出库效率下降了？

LLM可以根据提供的数据：

昨天：
出库订单 1200
平均处理时间 18分钟

今天：
出库订单 1500
平均处理时间 31分钟

分析：

订单量增加
 ↓
作业压力增加
 ↓
平均处理时间上升
 ↓
需要进一步分析拣货环节

但是这里有一个非常重要的问题：

LLM自己并不知道你的WMS数据。

所以需要下一层技术。

五、第二层：Prompt Engineering

Prompt就是：

告诉模型应该做什么。

例如：

你是一名仓库运营分析专家。

请根据下面的库存数据：

SKU：SKU001
当前库存：800
安全库存：1000
过去30天销量：1500

分析：
1. 当前库存风险
2. 是否需要补货
3. 给出补货建议

请用JSON格式输出。

好的Prompt通常包含：

角色
 ↓
任务
 ↓
上下文
 ↓
约束
 ↓
输出格式

六、Prompt不是“魔法指令”

很多初学者会认为：

Prompt写得越复杂，AI就越厉害。

其实不是。

Prompt Engineering真正关注的是：

如何让模型更加稳定、准确地完成任务。

例如：

错误：

帮我分析库存。

改进：

你是一名仓库运营分析专家。

请分析提供的库存数据。

判断：
1. 是否低于安全库存
2. 是否存在缺货风险
3. 是否需要补货

输出：
SKU、当前库存、安全库存、风险等级、建议。

这样模型的输出会更加稳定。

七、第三层：Structured Output

企业应用不能只接受一段自然语言。

例如：

这个SKU库存比较低，建议及时补货……

程序很难直接处理。

企业系统更希望得到：

{
  "sku": "SKU001",
  "inventory": 800,
  "safety_stock": 1000,
  "risk_level": "HIGH",
  "recommendation": "REPLENISH"
}

这就是：

Structured Output

结构化输出。

八、为什么Structured Output非常重要？

因为：

AI需要和传统软件系统连接。

例如：

LLM
 ↓
JSON
 ↓
Backend
 ↓
Database

或者：

LLM
 ↓
JSON
 ↓
Workflow
 ↓
ERP

如果AI只输出自然语言：

“建议补货。”

系统不知道：

补多少？
哪个SKU？
哪个仓库？
优先级？

结构化输出可以解决这个问题。

九、第四层：Embedding

当企业开始使用自己的数据以后，就出现一个问题：

“如何让AI找到企业内部相关资料？”

例如企业有：

仓库管理制度.pdf
采购管理制度.pdf
质量管理制度.pdf
设备操作手册.pdf
员工手册.pdf

用户问：

“仓库盘点出现差异应该怎么处理？”

传统关键词搜索可能只搜索：

盘点
库存
差异

而Embedding解决的是：

语义搜索。

十、Embedding到底是什么？

Embedding可以简单理解成：

把文本转换成向量。

例如：

“仓库盘点出现库存差异”

↓

Embedding Model

↓

[0.12, -0.31, 0.77, ...]

另一句话：

“库存盘点结果与系统数量不一致”

↓

[0.15, -0.29, 0.72, ...]

虽然两句话使用的词不同：

库存差异

和：

数量不一致

但是语义非常接近。

Embedding可以帮助系统发现这种：

语义相似性。

十一、第五层：Vector Database

Embedding产生向量以后：

放在哪里？

答案通常是：

Vector Database

常见方案包括：

Milvus
Qdrant
pgvector
Weaviate

基本流程：

企业文档
 ↓
文本切分
 ↓
Embedding
 ↓
Vector
 ↓
Vector Database

用户查询：

问题
 ↓
Embedding
 ↓
向量搜索
 ↓
找到相关内容

十二、为什么不能直接把所有文档交给LLM？

假设企业有：

10000份PDF
5000份Word
10000份Excel

不可能每次用户提问都：

全部读取
 ↓
全部发送给LLM

因为会带来：

上下文限制
成本过高
延迟过高
信息噪声
检索准确率下降

因此需要：

先检索，再生成。

这就是RAG。

十三、第六层：RAG

RAG：

Retrieval-Augmented Generation

中文通常称为：

检索增强生成。

基本流程：

这就是最基础的RAG。

十四、一个完整的RAG案例

假设企业有一本：

《仓库库存管理制度》

其中规定：

库存低于安全库存80%时，
仓库管理员需要提交补货申请。

用户：

“SKU001库存低了怎么办？”

RAG流程：

用户问题
 ↓
Embedding
 ↓
Vector DB
 ↓
找到相关制度
 ↓
交给LLM
 ↓
结合制度生成答案

最终：

SKU001库存低于安全库存阈值，需要按照库存管理制度提交补货申请。

这时候AI回答的依据：

来自企业自己的知识。

十五、RAG的完整工程流程

一个生产级RAG通常包含：

注意：

真正的RAG远比“向量搜索+LLM”复杂。

十六、为什么需要Chunk？

假设一本PDF有500页。

不能把整本PDF作为一个向量。

通常需要：

文档
 ↓
章节
 ↓
段落
 ↓
Chunk

例如：

Chunk 1
库存定义

Chunk 2
库存状态

Chunk 3
安全库存

Chunk 4
库存盘点

Chunk 5
库存调整

然后分别进行Embedding。

十七、Chunk不是越小越好

如果Chunk太小：

信息不完整
上下文丢失

如果Chunk太大：

检索不精准
无关信息增加

因此FDE需要根据实际业务调整：

Chunk Size
Overlap
Metadata

例如：

文档：
WMS库存管理制度

章节：
库存盘点

Metadata：
{
  "document": "WMS库存管理制度",
  "chapter": "库存盘点",
  "version": "2026"
}

这可以提高后续检索能力。

十八、第七层：Function Calling

RAG解决：

AI如何获取知识。

但还有一个问题：

AI如何执行操作？

例如用户说：

“查询WMS里的库存。”

知识库解决不了。

需要：

Function Calling

例如定义：

{
  "name": "get_inventory",
  "description": "查询指定SKU库存",
  "parameters": {
    "warehouse": "string",
    "sku": "string"
  }
}

模型判断：

这个问题需要调用工具。

于是：

LLM
 ↓
get_inventory()
 ↓
WMS API
 ↓
库存数据
 ↓
LLM
 ↓
生成回答

十九、Tool Calling

Tool Calling和Function Calling在很多AI开发框架中经常一起出现。

核心思想就是：

让模型能够调用外部工具。

工具可以是：

API
数据库
搜索引擎
代码执行器
企业系统
文件系统
业务服务

例如：

get_customer()
get_order()
get_inventory()
create_ticket()
send_email()
query_report()

二十、从“聊天机器人”到“AI Agent”

到了这里，AI能力发生了一个重要变化：

以前：

用户
 ↓
LLM
 ↓
回答

现在：

用户
 ↓
Agent
 ↓
LLM
 ↓
判断需要什么工具
 ↓
调用Tool
 ↓
获得结果
 ↓
继续推理
 ↓
完成任务

这就是：

AI Agent

二十一、Agent到底是什么？

可以简单理解为：

Agent = LLM + Tools + Memory/Context + Decision/Execution Loop

例如：

用户：

“帮我分析一下今天库存异常。”

Agent可能执行：

1. 查询库存
        ↓
2. 查询历史销量
        ↓
3. 查询安全库存
        ↓
4. 判断异常SKU
        ↓
5. 生成分析

如果需要：

6. 创建补货任务

甚至可以继续调用：

ERP / WMS API

二十二、Agent的核心不是“聊天”

这是理解Agent最重要的一点。

普通Chatbot：

Question
 ↓
Answer

Agent：

Goal
 ↓
Plan
 ↓
Tool
 ↓
Observation
 ↓
Reasoning
 ↓
Action
 ↓
Result

所以Agent更接近：

能够执行任务的软件系统。

二十三、第八层：Workflow

但是：

是不是所有任务都应该使用Agent？

不是。

如果流程非常确定：

订单异常
 ↓
查询订单
 ↓
查询库存
 ↓
查询物流
 ↓
生成报告

完全可以设计成Workflow。

二十四、Agent与Workflow怎么选择？

简单理解：

Workflow

流程固定
规则明确
步骤确定

适合：

审批流程
数据同步
报表生成
固定业务流程

Agent

目标明确
路径不固定
需要自主判断
需要动态选择工具

适合：

复杂分析
智能客服
业务调查
多系统协作

二十五、最好的企业AI往往是Agent + Workflow

真实企业系统不一定是：

纯Agent

也不一定是：

纯Workflow

而可能是：

这才是更加工程化的AI系统。

二十六、第九层：MCP

当AI需要连接越来越多的：

工具
数据
系统
服务

就会出现：

标准化连接问题。

MCP就是为解决这一类问题而出现的重要协议体系。

可以把它简单理解成：

AI模型与外部工具、数据、资源之间的标准化连接方式之一。

例如：

二十七、为什么FDE需要学习MCP？

因为FDE经常面对：

客户A
 ↓
ERP

客户B
 ↓
CRM

客户C
 ↓
WMS

客户D
 ↓
MES

如果每次都重新设计一套AI连接方式：

开发成本很高。

标准化工具协议可以帮助FDE降低系统连接成本。

因此：

MCP是未来企业AI系统集成值得重点掌握的技术。

二十八、第十层：Evaluation

AI应用最大的特点之一：

输出不是完全确定的。

传统程序：

输入A
 ↓
代码
 ↓
输出B

通常比较确定。

AI：

输入A
 ↓
LLM
 ↓
输出B

可能出现：

正确
错误
部分正确
幻觉
格式错误
工具调用错误

所以AI系统必须进行：

Evaluation

二十九、AI系统需要评估什么？

至少包括：

回答准确率
检索准确率
任务完成率
工具调用成功率
幻觉率
响应时间
Token消耗
成本

例如：

100个测试问题

正确：
87

错误：
13

Accuracy：
87%

这样才能知道：

系统到底有没有真正变好。

三十、RAG Evaluation

RAG需要分别评估：

Retrieval

有没有找到正确文档？

Generation

LLM有没有根据正确文档回答？

因此：

用户问题
 ↓
Retriever
 ↓
是否找到正确内容？
 ↓
LLM
 ↓
答案是否正确？

如果答案错误：

不一定是LLM的问题。

可能是：

Chunk错误
 ↓
Embedding错误
 ↓
Retriever错误
 ↓
Context错误

所以AI工程排查问题必须具备：

全链路思维。

三十一、第十一层：Guardrails

当AI进入企业生产环境以后：

安全问题就会变得非常重要。

例如：

用户：

“把所有订单删除。”

如果Agent拥有删除订单的Tool：

用户
 ↓
Agent
 ↓
delete_all_orders()
 ↓
数据库

后果可能非常严重。

所以需要：

Guardrails

即：

AI应用的安全防护和行为约束机制。

三十二、Guardrails需要解决什么？

至少包括：

输入安全
输出安全
权限控制
敏感信息
Prompt Injection
工具权限
高风险操作
数据泄露

例如：

AI Agent
 ↓
工具调用
 ↓
权限检查
 ↓
风险判断
 ↓
人工确认
 ↓
执行

三十三、企业Agent必须建立权限边界

这是FDE设计Agent时必须考虑的问题。

例如：

普通员工：

查询库存 ✓
查询订单 ✓
删除订单 ✗
修改价格 ✗

仓库主管：

查询库存 ✓
调整库存 ✓
创建盘点任务 ✓
删除订单 ✗

管理员：

高级操作

所以：

Agent的权限不能大于用户权限。

三十四、把所有技术串起来

到这里，我们可以把整个AI Engineering体系串起来：

这就是一套完整的AI Engineering思维。

三十五、FDE第一个AI项目：企业知识助手

现在开始真正做项目。

假设客户有：

企业制度
产品手册
业务流程
操作说明
FAQ

需求：

“员工可以直接问AI企业内部问题。”

三十六、第一版架构

这就是：

企业知识库AI助手。

三十七、第二版：增加企业系统

客户进一步提出：

“除了回答问题，我还想查询订单。”

架构变成：

现在AI已经开始进入企业业务系统。

三十八、第三版：增加Workflow

客户继续提出：

“如果订单异常，能不能自动生成处理建议？”

于是：

系统开始从：

问答

进化成：

业务自动化。

三十九、第四版：增加MCP

当系统需要连接：

ERP
CRM
WMS
MES
BI
知识库

可以进一步考虑标准化的工具与资源连接方式。

最终：

这时FDE真正开始发挥价值：

把AI与企业数字化系统连接起来。

四十、AI Engineering不是“模型工程”

需要特别区分两个概念。

AI Model Engineering

主要关注：

模型训练
模型微调
模型架构
数据集
GPU
推理

AI Engineering

更加关注：

LLM
RAG
Agent
Tools
Workflow
API
Database
MCP
Evaluation
Security
Deployment

FDE更加接近：

AI Engineering。

而不是单纯的模型训练工程。

四十一、FDE学习AI Engineering的正确顺序

建议：

第一阶段

LLM
 ↓
Prompt
 ↓
Structured Output

第二阶段：

Embedding
 ↓
RAG
 ↓
Vector DB

第三阶段：

Function Calling
 ↓
Tool Calling
 ↓
Agent

第四阶段：

Workflow
 ↓
MCP

第五阶段：

Evaluation
 ↓
Guardrails

最终：

AI Application

四十二、不要一上来就学习Agent

这是很多初学者最容易犯的错误。

看到AI Agent很火：

直接学习Agent
 ↓
调用十几个Tool
 ↓
做复杂Workflow

最后发现：

连LLM为什么会产生错误都不知道。

正确顺序应该是：

LLM
 ↓
Prompt
 ↓
Structured Output
 ↓
Embedding
 ↓
RAG
 ↓
Tool Calling
 ↓
Agent

一步一步建立理解。

四十三、FDE的AI能力最终应该是什么？

不是：

“我会调用GPT。”

而是：

这才是：

AI Engineering能力

四十四、FDE AI项目的完整生命周期

一个真实项目可以形成：

这就是FDE完整的AI项目闭环。

四十五、本篇总结

本篇从LLM开始，一直学习到AI Application。

完整技术路线：

如果把它们分别理解：

技术	解决的问题
LLM	理解与生成
Prompt	指导模型
Structured Output	让AI输出可被程序处理的数据
Embedding	让文本具备语义表示
RAG	让AI使用外部知识
Vector DB	存储与检索向量
Function Calling	让模型调用函数
Tool Calling	让AI使用外部工具
Agent	让AI完成复杂任务
Workflow	编排确定性流程
MCP	标准化连接工具与资源
Evaluation	衡量AI效果
Guardrails	控制AI风险
AI Application	最终业务应用