很多人第一次接触大模型开发时，会先问一个问题：
“我调用一个大模型 API，不就能做一个 AI 应用了吗？”
做 Demo 的时候，答案可能是“差不多”；但只要应用开始接触真实用户、真实文件和真实业务，单独调用模型 API 很快就会遇到问题：模型不知道企业内部资料，回答无法追溯；用户数据没有权限隔离；文件解析耗时太长，接口容易超时；调用成本和错误率也没人统计。
这时你会发现，大模型只是系统中的一个核心部件，而不是全部。
本文不从某一个框架出发，而是沿着“一次用户提问如何流经系统”的路径，拆解一个典型 LLM 应用需要哪些组件，以及每类组件究竟解决什么问题。
一、先看全貌：大模型应用不是一个模型，而是一条链路
一个具备基本工程能力的问答应用，通常可以抽象成下面这条链路：
用户 ↓ 前端界面 ↓ 后端 API / 鉴权 / 限流 ↓ 工作流编排与会话管理 ├── 直接调用大模型 ├── 检索知识库 ├── 调用外部工具 └── 查询业务数据库 ↓ 大模型生成答案 ↓ 流式返回、日志记录、质量评估如果是企业知识库，还会增加另一条“离线建库链路”：
上传文件 ↓ 对象存储 ↓ 文档解析 / OCR ↓ 文本清洗与切分 ↓ Embedding 向量化 ↓ Milvus / pgvector ↓ PostgreSQL 保存文档与权限元数据前一条链路负责“回答问题”，后一条链路负责“准备答案所需的知识”。两者缺一不可。
二、六类核心组件，分别负责什么？
可以把大模型应用拆成六个层次：
层次 | 典型组件 | 主要职责 |
交互层 | Vue、React、Next.js | 接收问题、展示回答、上传文件 |
应用层 | FastAPI、Django、Node.js | 鉴权、业务逻辑、接口和任务管理 |
编排层 | LangGraph、LlamaIndex、Dify、n8n | 组织模型、检索和工具调用流程 |
智能层 | 大语言模型、Embedding、Reranker | 生成、向量化、排序和推理 |
数据层 | PostgreSQL、Milvus、Redis、MinIO | 业务数据、向量、缓存和文件存储 |
工程层 | RabbitMQ、Kafka、Docker、监控系统 | 异步处理、部署、观测和安全 |
这六层不是严格的产品分类，而是一种帮助我们理解系统的方式。不同项目可能合并其中几层，也可能用一个产品同时承担多个职责。
三、模型层：大语言模型究竟负责什么？
大语言模型主要负责三件事：理解上下文、进行推理、生成文本或结构化结果。
例如，用户问：
“公司差旅报销中，机票改签费用怎么处理？”
模型可以理解问题并组织语言，但它并不知道你所在公司的最新制度。它能回答“语言上合理”的内容，却不一定能回答“业务上正确”的内容。
因此，模型层通常还会包含另外两类模型：
1. Embedding 模型
Embedding 模型把文本、图片或其他数据转换成向量。向量可以理解为一组表示语义特征的数字，语义相近的内容通常在向量空间中更接近。
在 RAG 系统里，文档片段和用户问题都要经过 Embedding，然后才能进行相似度检索。
2. Reranker 模型
向量检索适合快速找出一批候选内容，但候选结果的精确排序可能不够理想。Reranker 会进一步比较“问题”和“候选文本”的相关性，重新排序后再交给大模型。
因此，一条更完整的检索链路是：
用户问题 ↓ Embedding ↓ 向量检索 Top K ↓ Reranker 重排序 ↓ 选出少量高相关片段 ↓ 交给大模型生成答案这里需要注意：Embedding、Reranker 和大语言模型可以来自不同厂商，也不要求必须使用同一系列模型。
四、数据层：为什么 PostgreSQL 和 Milvus 经常一起出现？
在一个知识库项目中，至少有三类数据：
原始文件，例如 PDF、Word、图片和 Excel；
业务元数据，例如文件名、上传者、所属部门和权限；
文本片段及其向量，用于语义检索。
这三类数据的访问方式不同，通常不会全部塞进同一个存储系统。
4.1 PostgreSQL：保存业务事实
PostgreSQL 适合保存结构化业务数据，例如：
用户、组织和角色；
文档、版本和处理状态；
知识库与部门的关联关系；
文档片段的来源、页码和更新时间；
对话记录、反馈和审计日志。
它还支持 JSONB、事务和全文检索等能力，适合承担 AI 应用中的“业务数据库”角色。PostgreSQL 官方文档也提供了tsvector、to_tsvector等全文检索能力，这意味着它并不只是简单保存表格数据。
4.2 Milvus：保存和检索向量
Milvus 是面向向量相似度检索的数据库，适合管理大规模 Embedding，并通过近似最近邻搜索快速找到语义相近的数据。Milvus 官方文档将其定位为用于向量相似度搜索的开源向量数据库，并提供 Milvus Lite、Standalone 和 Distributed 等部署形态。
在 RAG 里，Milvus 通常保存：
文本片段的向量；
片段 ID；
文档 ID；
租户或知识库 ID；
用于过滤的元数据。
但 Milvus 不应该替代 PostgreSQL 的全部业务职责。检索到片段后，应用往往还要回 PostgreSQL 查询权限、来源、版本和完整业务信息。
4.3 Redis：保存短期状态
Redis 常用来保存：
登录会话和短期 Token；
对话上下文缓存；
热门问题和检索结果；
接口限流计数器；
异步任务状态。
它的特点是读写速度快，但不适合直接作为所有业务数据的永久唯一存储。
4.4 MinIO 或 S3：保存原始文件
PDF、图片、视频等二进制文件通常放在对象存储中，数据库只记录文件地址、大小、哈希和处理状态。这样可以避免把大文件直接塞进 PostgreSQL，也方便后续备份和扩展。
五、应用层：FastAPI 不是“调用模型的脚本”
很多 Demo 会把所有逻辑写在一个 Python 文件里：接收问题、调用模型、打印答案。生产系统则需要一个应用层，把这些能力组织成稳定的接口。
典型后端 API 可能包括：
POST /api/chat 发起对话 POST /api/chat/stream 流式返回回答 POST /api/documents 上传文档 GET /api/documents/{id} 查询文档状态 POST /api/knowledge/search 调试知识库检索 GET /api/conversations 查询会话记录应用层通常还负责：
校验用户身份和权限；
判断用户能访问哪些知识库；
组装 Prompt 和检索上下文；
处理模型超时、重试和降级；
记录请求 ID、耗时和 Token 消耗；
通过 SSE 或 WebSocket 向前端推送生成过程。
因此，FastAPI、Django 或 Node.js 并不是“大模型本身”，而是把模型能力包装成可被用户和其他系统调用的业务服务。
六、编排层：什么时候需要 LangGraph、Dify 或 n8n？
当流程只有一步时，直接调用模型即可：
问题 → 模型 → 答案当流程变成多步，就需要编排：
问题 ↓ 判断意图 ├── 普通知识问答 → 检索知识库 ├── 查询订单 → 调用业务 API ├── 需要最新信息 → 调用搜索工具 └── 无法判断 → 转人工编排工具的职责，是定义节点、分支、状态和异常处理。例如：
LangGraph 更适合用代码构建有状态、可循环、可控制的 Agent 图；
LlamaIndex 更偏向数据接入、索引和检索应用；
Dify 适合通过可视化界面搭建知识库、工作流和应用；
n8n 适合把 AI 能力连接到邮件、表格、Webhook 和第三方 SaaS。
它们不是同一层面的完全替代品，应该根据团队的开发能力、可控性要求和部署方式选择。
七、工具层：让模型从“会说”变成“能做”
大模型本身通常不能直接访问你的数据库、订单系统或文件系统。Tool Calling 的作用，是让模型以结构化方式提出工具调用请求，再由后端真正执行。
例如，模型决定调用天气工具时，可能输出类似这样的结构：
{ "name": "get_weather", "arguments": { "city": "上海" } }后端收到请求后，应该完成以下动作：
校验工具名称是否允许调用；
校验参数格式和用户权限；
执行真实 API 或数据库查询；
对结果进行脱敏和大小限制；
把工具结果交回模型继续生成。
关键点是：模型只能“请求调用”，不能绕过后端权限直接执行危险操作。
八、工程层：为什么还需要 Redis、消息队列和监控？
8.1. 消息队列处理长任务
上传一个 300 页 PDF，可能要经历下载、解析、OCR、切分、向量化和写入数据库。如果让 HTTP 请求一直等待，接口很容易超时。
更合理的方式是：
上传文件 → 创建任务 → 立即返回任务 ID ↓ 消息队列 ↓ Worker 异步解析和建立索引 ↓ 更新任务状态RabbitMQ、Kafka 或 Redis Stream 都可以承担异步任务，但它们的定位、吞吐和运维方式不同，不能只因为“都能发消息”就认为完全等价。
8.2. 监控回答质量与系统质量
传统后端主要监控 CPU、内存、错误率和延迟；大模型应用还要关注：
Prompt 和模型输出；
Token 数量和调用成本；
检索结果是否相关；
答案是否引用了正确上下文；
工具调用是否成功；
用户是否点击“有帮助”。
Langfuse、OpenTelemetry、Prometheus 和 Grafana 等工具可以分别用于链路追踪、指标采集和可视化。没有观测能力，很多“模型变笨了”的问题其实无法定位。
九、一个最小项目和一个生产项目，组件可以完全不同
9.1个人学习项目
Python + 一个大模型 API + Embedding 模型 + PostgreSQL + pgvector + FastAPI这个组合足够完成一个小型文档问答应用，部署简单，便于学习完整流程。
9.2 中大型企业知识库
React / Vue + FastAPI + LangGraph 或其他工作流编排 + 大语言模型 + Embedding + Reranker + PostgreSQL + Milvus + Redis + MinIO / S3 + RabbitMQ / Kafka + Langfuse + Prometheus + Grafana + Docker / Kubernetes组件变多以后，能力更强，但部署、升级、备份、权限和故障排查的成本也会同步增加。
十、选型时最容易犯的三个错误
10.1 错误一：一开始就堆满所有组件
如果只有几千份文档，却一开始部署 Milvus、Kafka、Kubernetes 和多套监控，项目可能还没验证需求，就先被基础设施拖慢。
建议先用最小闭环验证：
上传文件 → 解析 → 切分 → 向量检索 → 生成回答10.2 错误二：把向量数据库当成知识库本身
向量数据库解决的是相似度检索，不会自动解决文档权限、版本、引用、删除和审核问题。知识库是业务系统，向量库只是其中一个检索组件。
10.3 错误三：只关注模型效果，不关注数据和流程
很多回答质量问题来自：文档解析错误、切分不合理、权限过滤遗漏、检索召回不足或 Prompt 组装混乱，而不是模型参数不够大。
十一、码海寻道的组件学习路线
接下来的系列会沿着这条路线展开：
先理解整体架构 ↓ 再理解 RAG、Agent、Workflow 的边界 ↓ 学习 Embedding、向量检索和 Reranker ↓ 掌握 PostgreSQL、pgvector 与 Milvus ↓ 构建文档解析、切分和知识库索引 ↓ 加入 Redis、对象存储和异步任务 ↓ 实现 Agent、Tool Calling 和工作流 ↓ 补齐评估、监控、安全和生产部署十二、结语：先画清数据流，再决定使用什么组件
大模型应用的核心问题，从来不是“现在最流行的组件是什么”，而是：
用户的问题、业务数据、外部工具和模型输出，应该怎样安全、稳定、可追踪地流动起来？
当你能画清楚这条数据流，PostgreSQL、Milvus、Redis、MinIO、消息队列和工作流框架就不再是一堆孤立名词，而会变成架构图中各司其职的部件。
下一篇，我们继续讨论一个最容易混淆的问题：RAG、Agent 和 Workflow 到底有什么区别？
参考资料
Milvus Documentation：What is Milvus
Milvus Documentation：Basic Vector Search
PostgreSQL Documentation：Text Search Functions and Operators
1.大模型应用到底由哪些组件组成？一张架构图看懂 LLM 应用
` 方法全解析：将集合映射为字典分组结构)
