从需求到上线：企业级大模型应用的 6 层工程结构与验收口径

适用读者：正在落地大模型应用的后端 / 平台工程师 环境：Python 3.11、httpx、任一兼容 OpenAI 协议的中转或自建推理服务 结论先行：大多数 AI 项目失败不在模型，在工程。模型只占一层，剩下五层没做好，换再强的模型也没用。

一、先给分层

一个能上生产的大模型应用，可以拆成 6 层。每层都有明确的验收口径，缺一层就会在某个时间点爆掉。

• L1 接入层：鉴权 / 配额 / 会话 / 流式
• L2 编排层：工作流 / 工具调用 / 状态机
• L3 模型网关：多模型路由 / 超时 / 重试 / 降级 / 成本计量
• L4 检索层：切分 / 向量化 / 混合检索 / 重排 / 评测
• L5 数据层：多租户隔离 / 留存策略 / 脱敏 / 删除
• L6 观测层：trace / token / 成本 / 质量抽样

下面逐层说清"做什么"和"怎么验收"。

二、L1 接入层

做什么：统一入口，做身份、配额、并发控制、流式输出。

验收口径：

• 单租户超配额时返回明确错误码，不是静默排队
• 流式响应在客户端断开后，服务端能在 5 秒内停止计费
• 会话上下文有上限策略（按轮数或 token），不是无限拼接

最后一条最容易漏。上下文无限增长，成本会随会话时长线性上升。

三、L2 编排层

做什么：把"一次问答"变成"可重放的工作流"。

验收口径：

• 每一步有独立超时，整条链路有总超时
• 工具调用失败时，能区分"可重试"和"不可重试"
• 中间状态可持久化，进程重启后能续跑
• 同一条输入重放两次，结果结构一致（内容可以不同）

常见坑：把编排逻辑写进 prompt。prompt 里写"如果用户问 A 就调用 B"，一旦模型不遵守就整条链路断。编排应该是代码，模型只做判断，不做调度。

四、L3 模型网关

这一层最值得单独写代码。目标：业务代码不感知具体模型。

import time
import httpx
from dataclasses import dataclass

@dataclass
class Model:
    name: str
    base_url: str
    api_key: str
    price_in: float    # 元 / 千 token
    price_out: float

class Gateway:
    """最小可用网关：优先模型 -> 顺序降级 -> 成本与延迟计量"""

    def __init__(self, models: list[Model], timeout: float = 30, retries: int = 1):
        self.models = models
        self.timeout = timeout
        self.retries = retries

    def chat(self, messages: list[dict], prefer: str | None = None):
        order = sorted(self.models, key=lambda m: m.name != prefer)
        last_err = None

        for m in order:
            for _ in range(self.retries + 1):
                t0 = time.time()
                try:
                    resp = httpx.post(
                        f"{m.base_url}/chat/completions",
                        headers={"Authorization": f"Bearer {m.api_key}"},
                        json={"model": m.name, "messages": messages},
                        timeout=self.timeout,
                    )
                    resp.raise_for_status()
                    data = resp.json()
                    usage = data.get("usage", {})
                    cost = (
                        usage.get("prompt_tokens", 0) / 1000 * m.price_in
                        + usage.get("completion_tokens", 0) / 1000 * m.price_out
                    )
                    meta = {
                        "model": m.name,
                        "cost": round(cost, 6),
                        "latency_ms": int((time.time() - t0) * 1000),
                    }
                    return data, meta
                except Exception as e:
                    last_err = e

        raise RuntimeError(f"all models failed, last error: {last_err}")

验收口径：

• 主模型不可用时，自动切到备用模型，业务无感知
• 每次调用都记录 model / cost / latency，能按天聚合
• 换供应商只改配置，不改业务代码
• 单次调用成本可预估，月度账单能对得上

注意：不同厂商对 temperature、max_tokens、tool_choice 的支持程度不同，网关里要做参数归一化，否则换模型就报错。

五、L4 检索层

RAG 的效果，90% 由这一层决定，跟模型关系不大。

验收口径：

• 有评测集：至少 50 条真实问题 + 标准答案 + 应召回的文档 ID
• 能报出三个数：召回率、引用准确率、无答案时的拒答率
• 切分策略可配置（按标题层级 / 按长度 / 按语义），不是写死
• 混合检索（关键词 + 向量）可开关，能对比效果

最容易糊弄的地方：只演示"问一个问题答得不错"。没有评测集，就没有优化方向，也无法在换模型、换切分策略后判断是变好还是变差。

六、L5 数据层

验收口径：

• 多租户数据物理或逻辑隔离，跨租户查询在代码层面不可达
• 数据留存期可配置，到期自动清理
• 敏感字段在入库前脱敏，脱敏规则可审计
• 客户要求删除时，能在约定时间内删干净（含向量库、备份）

这一层出事，技术问题会变成法律问题。 私有化部署的核心价值也在这里：模型、向量库、原始文档都不出内网。

七、L6 观测层

验收口径：

• 每次请求有 trace id，能串起"用户输入 → 检索命中 → 模型调用 → 输出"
• 按天统计：调用量、token、成本、P95 延迟、错误率
• 有质量抽样机制（人工抽检或模型打分），不是只看"服务没挂"
• 成本异常告警（例如单日超出均值 50%）

没有观测层的系统，出问题时只能靠用户投诉发现。

八、四个最常见的返工点

这几个问题在交付后三个月内暴露的概率很高，前期花半天确认，能省两周返工。

1. 文档解析没有兜底。

PDF 有扫描件、DWG 有外部参照、Excel 有合并单元格。只按"标准文件"设计的解析器，真实数据一进来就崩。验收时要问：解析失败时，是报错、跳过、还是转人工队列？三种处理方式对应的产品逻辑完全不同。

2. 上下文长度当成了记忆。

把历史对话全量拼进 prompt，短期内看起来"记得住"，实际上成本随轮数线性上涨，而且超过窗口后开头会被截断，表现为"聊到后面忘了前面"。正确做法是摘要 + 关键实体抽取，落库存储，按需回填。

3. 权限模型后期才加。

先做成单租户，上线前再补多租户，几乎一定要重写检索层。因为向量检索天然是"全库相似度"，加租户过滤不是加个 where 那么简单，索引结构要一起改。

4. 评测集是上线前一周才编的。

这种评测集通常照着系统现有能力写，测出来自然好看，但覆盖不到真实用户的问法。评测集应该在需求阶段就开始积累，来源是客服记录、销售问答、真实工单。

九、上线前检查表

• 主备模型切换演练过至少一次
• 全链路超时与总超时都配置了
• 检索评测集与基线数字留档
• 多租户越权测试做过（用 A 租户 token 查 B 租户数据）
• 删除流程演练过（含向量库）
• 成本按租户可归集
• trace id 全链路透传
• 错误码有文档，前端能区分"重试有用"和"重试无用"
• 限流阈值按实测 QPS 设定，不是拍脑袋
• 回滚方案与数据迁移脚本准备就绪

十、一点经验

这套分层不是为了"架构好看"，是为了出问题时能定位到层。

线上答得不对，可能是检索没召回（L4）、可能是网关降级到了弱模型（L3）、可能是编排把上下文截断了（L2）。没有分层和 trace，只能靠猜，猜一次要一天。

另外一个现实问题：私有化部署的复杂度主要不在模型，在依赖。向量库、embedding 模型、OCR、文档解析，每一个都可能成为内网部署的阻塞点。选型阶段就要把这些组件列出来逐个确认能不能进内网，而不是等交付前一周才发现某个服务只能走公网。

作者：奇点大数据技术团队

能力边界：不承诺模型效果指标，验收以双方确认的评测集为准。