大模型应用到底由哪些组件组成一张架构图看懂 LLM 应用码海寻道 · 大模型、智能体与 RAG 工程组件系列第 1 篇很多人第一次接触大模型开发时会先问一个问题“我调用一个大模型 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业务元数据例如文件名、上传者、所属部门和权限文本片段及其向量用于语义检索。这三类数据的访问方式不同通常不会全部塞进同一个存储系统。PostgreSQL保存业务事实PostgreSQL 适合保存结构化业务数据例如用户、组织和角色文档、版本和处理状态知识库与部门的关联关系文档片段的来源、页码和更新时间对话记录、反馈和审计日志。它还支持 JSONB、事务和全文检索等能力适合承担 AI 应用中的“业务数据库”角色。PostgreSQL 官方文档也提供了tsvector、to_tsvector等全文检索能力这意味着它并不只是简单保存表格数据。Milvus保存和检索向量Milvus 是面向向量相似度检索的数据库适合管理大规模 Embedding并通过近似最近邻搜索快速找到语义相近的数据。Milvus 官方文档将其定位为用于向量相似度搜索的开源向量数据库并提供 Milvus Lite、Standalone 和 Distributed 等部署形态。在 RAG 里Milvus 通常保存文本片段的向量片段 ID文档 ID租户或知识库 ID用于过滤的元数据。但 Milvus 不应该替代 PostgreSQL 的全部业务职责。检索到片段后应用往往还要回 PostgreSQL 查询权限、来源、版本和完整业务信息。Redis保存短期状态Redis 常用来保存登录会话和短期 Token对话上下文缓存热门问题和检索结果接口限流计数器异步任务状态。它的特点是读写速度快但不适合直接作为所有业务数据的永久唯一存储。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、消息队列和监控1. 消息队列处理长任务上传一个 300 页 PDF可能要经历下载、解析、OCR、切分、向量化和写入数据库。如果让 HTTP 请求一直等待接口很容易超时。更合理的方式是上传文件 → 创建任务 → 立即返回任务 ID ↓ 消息队列 ↓ Worker 异步解析和建立索引 ↓ 更新任务状态RabbitMQ、Kafka 或 Redis Stream 都可以承担异步任务但它们的定位、吞吐和运维方式不同不能只因为“都能发消息”就认为完全等价。2. 监控回答质量与系统质量传统后端主要监控 CPU、内存、错误率和延迟大模型应用还要关注Prompt 和模型输出Token 数量和调用成本检索结果是否相关答案是否引用了正确上下文工具调用是否成功用户是否点击“有帮助”。Langfuse、OpenTelemetry、Prometheus 和 Grafana 等工具可以分别用于链路追踪、指标采集和可视化。没有观测能力很多“模型变笨了”的问题其实无法定位。九、一个最小项目和一个生产项目组件可以完全不同个人学习项目Python 一个大模型 API Embedding 模型 PostgreSQL pgvector FastAPI这个组合足够完成一个小型文档问答应用部署简单便于学习完整流程。中大型企业知识库React / Vue FastAPI LangGraph 或其他工作流编排 大语言模型 Embedding Reranker PostgreSQL Milvus Redis MinIO / S3 RabbitMQ / Kafka Langfuse Prometheus Grafana Docker / Kubernetes组件变多以后能力更强但部署、升级、备份、权限和故障排查的成本也会同步增加。十、选型时最容易犯的三个错误错误一一开始就堆满所有组件如果只有几千份文档却一开始部署 Milvus、Kafka、Kubernetes 和多套监控项目可能还没验证需求就先被基础设施拖慢。建议先用最小闭环验证上传文件 → 解析 → 切分 → 向量检索 → 生成回答错误二把向量数据库当成知识库本身向量数据库解决的是相似度检索不会自动解决文档权限、版本、引用、删除和审核问题。知识库是业务系统向量库只是其中一个检索组件。错误三只关注模型效果不关注数据和流程很多回答质量问题来自文档解析错误、切分不合理、权限过滤遗漏、检索召回不足或 Prompt 组装混乱而不是模型参数不够大。十一、码海寻道的组件学习路线接下来的系列会沿着这条路线展开先理解整体架构 ↓ 再理解 RAG、Agent、Workflow 的边界 ↓ 学习 Embedding、向量检索和 Reranker ↓ 掌握 PostgreSQL、pgvector 与 Milvus ↓ 构建文档解析、切分和知识库索引 ↓ 加入 Redis、对象存储和异步任务 ↓ 实现 Agent、Tool Calling 和工作流 ↓ 补齐评估、监控、安全和生产部署结语先画清数据流再决定使用什么组件大模型应用的核心问题从来不是“现在最流行的组件是什么”而是用户的问题、业务数据、外部工具和模型输出应该怎样安全、稳定、可追踪地流动起来当你能画清楚这条数据流PostgreSQL、Milvus、Redis、MinIO、消息队列和工作流框架就不再是一堆孤立名词而会变成架构图中各司其职的部件。下一篇我们继续讨论一个最容易混淆的问题RAG、Agent 和 Workflow 到底有什么区别参考资料Milvus DocumentationWhat is MilvusMilvus DocumentationBasic Vector SearchPostgreSQL DocumentationText Search Functions and Operators本文为“码海寻道”原创技术文章。组件版本、模型接口和部署方式会持续变化正式实施时应以对应项目的最新官方文档为准。