LLM 应用架构
LLM 应用是一个带有非确定性依赖的分布式系统。我们把应用层与编排层分开，由编排层负责提示词、上下文组装、模型路由、重试、流式输出和降级，这样更换模型时无需重写产品代码。推理管道与其他关键路径一样，配备超时、队列和背压机制。
- 模型网关与路由
- 带 Schema 校验的结构化输出
- 流式响应
- 降级与重试策略
- 提示词缓存与语义缓存
- 上下文窗口管理
- 批量与在线推理管道
概览
AI 工程是一门把模型能力转化为组织可以依赖的系统的学科。模型只是其中一个组件，它的周围还有检索、编排、工具、护栏、评估、访问控制、成本管理和遥测，大部分工程投入都花在这些部分上。
它之所以重要，是因为语言模型本质上是概率性的。同样的输入可能得到不同的输出，行文流畅的回答也可能是错的；模型提供方更新模型，或者你的文档发生变化，系统行为都会随之漂移。建立在这类组件之上的系统，必须有可度量的质量、有边界的失效模式，以及在用户察觉之前发现回归的手段。
Starone 把 AI 视为一条完整链路：数据、模型、编排、应用、评估与可观测性。我们的工作覆盖 LLM 应用、检索增强生成（RAG）、智能体工作流、文档智能、计算机视觉和预测分析，并始终选用能满足需求的最简单技术。有时答案是梯度提升模型或规则引擎，而不是 LLM。
我们构建什么
技术领域
检索、搜索与知识
检索增强生成让回答立足于你自己的内容，而不是模型的训练数据。质量主要取决于模型上游的环节：文档如何解析、切分、嵌入、建立索引，以及如何按权限过滤。我们把向量检索与关键词检索、重排序结合起来构建知识库；当问题取决于实体之间的关系时，再引入知识图谱。
- 嵌入管道
- 向量与 BM25 混合检索
- Cross-encoder 重排序
- 切分与元数据策略
- 权限感知检索
- 知识图谱
- 索引增量更新
智能体与工具调用
AI 智能体（Agent）让模型能够规划步骤并调用工具，也就是带有类型化 Schema、用于查询系统或执行操作的函数。我们设计智能体工作流时，会采用显式状态、步数上限和幂等工具，并对影响重大的操作设置人工审批。只有当任务能按角色清晰拆分、且各角色需要不同的上下文或权限时，才使用多智能体系统，因为每增加一个智能体，都会带来额外的延迟、成本和失败路径。
- 基于类型化 Schema 的工具调用
- 持久化的工作流状态
- 规划器与执行器模式
- 多智能体协作
- 人在回路（Human-in-the-loop）审批
- 步数与预算上限
提示词工程与评估
提示词就是代码：需要版本管理、评审，并在发布前用数据集测试。我们从真实任务中构建评估集，用确定性检查、模型按评分标准打分和人工评审共同评分，并把评估接入 CI，任何会拉低质量的提示词、模型或检索改动都无法上线。降低幻觉的手段包括事实依据约束、强制引用来源、受约束的输出格式，以及允许系统拒绝作答。
- 版本化的提示词注册表
- 黄金数据集与回归测试集
- 以人工评审校准的 LLM-as-judge
- 事实依据与引用检查
- 检索召回率与精确率指标
- 线上 A/B 评估
AI 安全与治理
LLM 无法可靠地区分指令与数据，因此它读到的任何文本，包括检索到的文档和工具返回的结果，都可能试图改变它的行为。我们把模型输出视为不可信输入，在模型之外执行授权，并限制每个工具的能力范围。数据泄露则通过权限感知检索、PII 脱敏、租户隔离，以及关于哪些数据可以发送给哪家提供方的明确规则来控制。
- 提示注入防御
- 最小权限的工具授权
- 输出校验与过滤
- PII 检测与脱敏
- 按租户隔离的索引
- 提示词与操作的审计日志
LLM 之外的应用机器学习
许多问题更适合用面向特定任务的模型来解决。文档智能结合 OCR、版面分析和抽取模型，把发票、合同和表单转化为经过校验的结构化数据。计算机视觉覆盖检测、分类与质检；预测分析则在表格数据和时序数据上完成预测、评分与异常检测。
- OCR 与版面感知抽取
- 目标检测与图像分类
- 预测与异常检测
- 特征管道
- 模型服务与批量评分
- 漂移监控
实验与生产级 AI 工程的区别
实验只回答一个问题：模型究竟能不能完成这项任务。一个 Notebook、几条样例和一段提示词就够了，成败靠肉眼判断。这项工作有其价值，但它只证明了在作者想到的那些输入上是可行的。
生产级 AI 工程则必须弄清楚：在真实的输入分布上输出正确的比例有多高，提供方超时或更换模型时会发生什么，谁可以看到哪些数据，一次请求的成本是多少，p95 延迟是多少，以及如何发现回归并回滚。
两者之间的差距，大部分是把常规工程方法应用到一个不寻常的组件上。跳过这一步的团队，往往要靠一次又一次的事故才逐一发现缺失的部分。
- 手工挑选的样例，变成持续维护、设有通过阈值的评估数据集
- 就地修改的提示词，变成经 CI 发布的版本化制品
- 单次模型调用，变成带超时、降级和缓存的路由调用
- 不受限的数据访问，变成带审计日志的权限感知检索
- 肉眼查看输出，变成链路追踪、质量抽样和成本看板
架构
生产级 AI 应用的构成
用户
- Web 应用
- 移动应用
- 对话界面
- 内部工具
应用层
负责身份、权限与用户体验
- 会话管理
- 访问控制
- 流式响应
- 反馈采集
AI 编排层
提示词、工具与策略在此版本化并测试
- 提示词管理
- 工具调用
- 护栏
- 模型路由
模型 / 智能体
- 托管 LLM
- 自托管模型
- 任务智能体
- 嵌入模型
知识与数据层
检索遵循调用方的权限
- 向量索引
- 文档存储
- 关系型数据
- 语义缓存
企业系统 / API
- ERP 与 CRM
- 身份提供方
- 内部 API
- 文档库
基础设施与可观测性
按请求度量链路、成本与质量
- Kubernetes
- GPU 与 API 容量
- 链路追踪与评估
- 成本监控
生产级 AI 系统的分层架构
把生产级 AI 系统按层来理解会更清晰。用户与应用层交互；应用层调用 AI 编排层，由它调用模型和智能体；模型和智能体依托知识与数据层，并通过企业系统和 API 采取行动；基础设施与可观测性则支撑着以上所有层。
让应用直接连接 LLM API，等于把这些层压缩成一次函数调用。这种做法一直可行，直到系统需要这次调用提供不了的能力：让回答立足于私有数据、按用户划分的权限、用更便宜的模型处理简单请求、记录某个回答的由来，或者防范含有指令的文档。这些能力各自属于特定的层，事后再补就意味着重构应用。
同一条链路也可以看作一个生命周期：数据、模型、编排、应用、评估、可观测性。数据质量限定了检索所能返回内容的上限，评估决定了什么可以发布，可观测性则把真实的失败案例反馈回评估集。
- 应用层：身份、会话、业务规则、界面与流式输出
- AI 编排层：提示词组装、路由、工具执行、护栏与缓存
- 模型与智能体：托管或自托管的 LLM、嵌入模型和特定任务模型
- 知识与数据层：向量索引、搜索、知识图谱、源文档与特征
- 企业系统与 API：工具读取和写入的记录系统（System of Record）
- 基础设施与可观测性：计算、队列、密钥、链路追踪、评估与成本遥测
检索、上下文与幻觉
模型根据上下文窗口里的内容作答。因此上下文管理是一个设计问题：放入哪些指令、检索片段、对话历史和工具结果，按什么顺序排列，对话变长后哪些内容要摘要或丢弃。上下文并非越多越好，无关片段会降低回答质量，同时抬高成本和延迟。
企业系统中的幻觉大多源于检索失败：正确的片段没有被检索出来，模型便自行填补了空白。我们把检索与生成分开度量，用混合检索和重排序提高召回率，要求回答引用检索到的来源，并让系统在来源中没有答案时如实说明。对于要输入其他系统的输出，则用 Schema 约束生成和校验取代自由文本。
向量嵌入捕捉的是语义相似度，适合语义搜索和单个片段就能回答的问题。跨越多个实体和关系的问题，例如哪些合同引用了已被取代的政策，更适合用知识图谱或结构化查询来回答；设计良好的系统会在这些方式之间做路由。
成本、延迟与可观测性
推理成本随 Token 数量和模型规模增长；延迟则随输出长度和串行模型调用次数增长。主要的调节手段包括：把简单请求路由到较小的模型，缓存稳定的提示词前缀和重复的回答，裁剪上下文，把离线任务批量处理，以及采用流式输出让用户尽快看到首批 Token。一个串行调用十次模型的智能体，无论用什么模型都会很慢，所以并行工具调用和减少步数，比更快的端点更重要。
模型可观测性把链路追踪延伸到 AI 路径上。每次请求都会记录提示词版本、检索到的文档、工具调用、所用模型、Token 数量、延迟和结果，敏感内容会先行脱敏。在追踪数据之上，我们抽样输出做自动化和人工质量评分，跟踪用户反馈，并在质量、单次请求成本和拒答率出现漂移时告警。缺少这些，提供方一侧的模型变更或索引质量下降，就会一直无人察觉，直到有人投诉。
我们如何构建
我们的方法
我们从任务本身及其可接受的错误率出发，再构建能够据此度量的最小系统。
- 01
定义任务与质量标准
明确系统必须做什么、答错的代价是什么，以及哪些决策仍由人来做。由此确定准确率、延迟和成本目标，后续一切都以这些目标来衡量。
- 02
评估并准备数据
审查源内容：格式、时效性、归属、权限和缺口。构建摄取、解析和嵌入管道，并把访问控制模型作为元数据一路带到下游。
- 03
先构建评估集
在调优提示词之前，先整理出有代表性的输入及其预期结果。这个数据集就是回归测试集，并随着每一次生产故障不断扩充。
- 04
构建编排层
在稳定的内部 API 之后实现检索、提示词组装、路由、工具调用和护栏，并配备超时、降级和结构化输出。
- 05
针对安全与故障做加固
围绕提示注入、数据泄露和工具滥用对系统做威胁建模。用对抗性输入进行测试，并在模型之外执行授权。
- 06
发布、观测与迭代
通过功能开关向小范围用户灰度发布，追踪每一次请求，抽样检查质量，并把失败案例反馈到评估中。提示词和模型的变更与代码走同一条发布管道。
取舍
决定设计走向的决策
在确定架构之前，我们会与您的团队逐一厘清的问题。
- 该用 RAG、微调，还是两者并用？
- 当系统需要的知识会变化、必须注明出处或受访问控制约束时，使用 RAG；更新索引比重新训练更便宜，也更易审计。当你需要提示词无法实现的一致格式、语气或任务行为，或者希望小模型在某个狭窄任务上达到大模型的水平时，选择微调。两者解决的是不同的问题，经常组合使用：微调模型负责行为，检索负责事实。
- 使用托管模型 API，还是自托管开放权重模型？
- 托管 API 让你无需做容量规划就能使用最强的通用模型，适合大多数工作负载。当数据不能离开你的环境、请求量足够大且稳定以至于专用 GPU 比按 Token 计费更便宜，或者需要掌控模型版本时，再考虑自托管。自托管意味着要承担 GPU 运维、推理服务优化和升级工作，因此应根据数据驻留要求、请求量和团队能力来决定。
- 用一个能力强的模型处理一切，还是在多个模型之间路由？
- 先用一个模型，以减少变量。当流量明显分化为简单请求和困难请求，或者延迟、成本目标无法达成时，再引入路由。路由会增加评估负担，因为每条路由上的每个模型都需要单独度量质量。
- 采用确定性工作流，还是自主智能体？
- 如果步骤事先已知，就把它们编码成工作流，在特定节点调用模型；这样更便宜、更快，也可测试。当路径取决于过程中发现的信息时，例如跨多个系统的排查或调研，再使用智能体。要为它限定工具范围、设置步数预算，并对任何不可逆的操作设置审批关卡。
- 使用专用向量数据库，还是在现有数据库中做向量检索？
- PostgreSQL 中的 pgvector，或 OpenSearch 的向量功能，足以应对许多语料库，并且能把事务、过滤和权限放在同一处。当索引规模非常大、查询量很高，或需要高级过滤和量化时，再选择 Qdrant、Milvus 这类专用引擎。只要嵌入和检索封装在接口之后，日后迁移是可控的。
- 单个智能体何时该拆成多智能体系统？
- 当不同角色需要不同的工具、权限或上下文，且这些内容不应共存于同一个提示词中时再拆分，例如一个只有读权限的研究者和一个拥有写权限的执行者。不要仅仅为了对应组织架构图而拆分。智能体之间的协调会成倍增加 Token 消耗，也让故障更难追踪。
生产就绪
怎样才算生产就绪
如何保障安全
授权在检索层和工具层强制执行，绝不依靠要求模型“守规矩”来实现。输入、检索内容和输出一律视为不可信，工具以最小权限运行，敏感数据在到达提供方或写入日志之前先行脱敏。
如何扩展
编排服务无状态，可水平扩展；长时间运行的智能体任务转入队列，并使用持久化状态。提供方的速率限制通过基于 Token 的限流、退避和备用模型来应对，索引则随语料库增长进行分片或复制。
如何监控
每次请求都会生成一条追踪记录，涵盖检索、工具调用、模型、Token、延迟和成本，并关联到具体的提示词版本。质量按评分标准持续抽样，准确率、延迟或开销出现漂移时触发告警。
如何部署
提示词、模型配置和检索设置都纳入版本管理，经由带评估关卡的 CI 逐级发布。变更通过功能开关或金丝雀用户群发布，回滚只是一次配置变更。
如何集成
工具以类型化 Schema、幂等键和明确的权限范围封装现有 API，在合适的场景采用 Model Context Protocol 等开放约定。AI 层对外提供自己的版本化 API，Web、移动端和后台系统可以像调用其他服务一样使用它。
技术
根据工作负载和您现有的技术资产来选择。
- Python
- TypeScript
- PostgreSQL with pgvector
- Qdrant
- OpenSearch
- Neo4j
- LangGraph
- Temporal
- vLLM
- PyTorch
- Redis
- Kubernetes
- OpenTelemetry
- Langfuse
从零到生产
工程生命周期
- 01
想法
- 02
探索
- 03
系统架构
- 04
UX / 产品设计
- 05
应用工程
- 06
AI / 数据层
- 07
云基础设施
- 08
安全
- 09
质量保证与性能
- 10
部署
- 11
可观测性
- 12
持续演进
常见问题
常见问题
我们需要训练自己的模型吗？
很少需要。大多数企业场景用现有模型加上检索、经过充分测试的提示词和评估就能满足。只有在任务范围狭窄且有大量标注数据、延迟或成本限制严格，或者提示词无法让行为保持一致时，训练或微调才值得投入。
如何防止系统凭空编造内容？
幻觉无法根除，只能减少和检测。我们让回答立足于检索到的来源，要求给出引用，约束输出格式，允许系统在证据不足时拒绝作答，并在评估集上度量事实依据程度，使残余的幻觉率是已知的，而不是靠假设。
我们的数据能留在自己的环境或所在地区内吗？
这取决于所选提供方的条款和部署方式，我们会针对这一约束进行设计。可选方案包括：使用数据处理和驻留条款合适的端点，在请求发出前对敏感字段脱敏，或在你自己的环境内自托管开放权重模型。
如何判断一项 AI 功能可以发布了？
当它在评估集上达到约定的质量、延迟和成本阈值，通过了对抗性测试，并且链路追踪和回滚机制都已就绪。发布就绪是一道经过度量的关卡，而不是看完演示后做出的主观判断。
模型提供方发布新版本时会怎样？
在切换任何流量之前，新版本要先跑一遍回归测试集。由于模型访问位于锁定版本的网关之后，切换只是一次配置变更，可以金丝雀发布，也可以回退。