原创教学拆解 · 核对：2026-10-11。下面的产品、数据和预算都是自拟的，不代表某家公司架构或真实压测结果。
“我负责模型”听起来很明确，实际还得问：你改的是训练目标、召回向量、线上排序，还是服务性能？同一个产品里，这些很可能是不同团队的工作。理解完整系统，不是要求一个人全做，而是知道自己的输入从哪里来、输出交给谁。
我们用一个资料搜索产品走一遍：用户输入问题，也可以附一张截图；系统返回有权限查看的资料，必要时再生成带引用的摘要。没有生成需求时，到搜索结果就可以结束，不必为了画图完整而接一个 LLM。
按你现在的问题读
| 想弄清什么 | 阅读入口 |
|---|---|
| 没做过完整项目，想先知道有哪些环节 | 读完本页的全貌与团队交接 |
| 数据怎么变成模型、index 和可发布版本 | 数据到模型 |
| 一次请求怎么跑，线上慢了或答错了怎么查 | 上线与反馈 |
| FSDP、vLLM、SGLang 分别放在哪里 | FSDP 的位置见数据到模型，vLLM / SGLang 见上线以后，再读训练框架与推理引擎 |
| 图片怎么和文字一起检索（retrieval） | CLIP → SigLIP，再回来检查索引兼容性 |
先分开三条时间线
- 01 / 内容更新资料 → 清洗 → 编码 → 索引新文档今天来了，不必等下一次模型训练才能搜到。删除与权限变更也要沿这条线生效。
- 02 / 在线请求查询 → 检索 → 排序 → 展示需要摘要时再接生成引擎。这条线关注当下的权限、质量、延迟与失败处理。
- 03 / 模型迭代反馈 → 数据集 → 训练 → 评估 → 发布线上日志只是候选证据，不会直接变成可信标签。新版本先验证，再改变用户看到的结果。
一个常见误会是把完整系统画成“数据 → 训练 → 推理”。这样看不到索引更新、客户端重试、删除传播，也看不到线上决策怎样改变下一轮训练数据。Hidden Technical Debt in ML Systems讨论的正是模型以外的数据依赖和反馈等维护问题；本页用自拟系统把这些问题具体展开。
每个环节到底交出什么
| 环节 | 输入 → 输出 | 必须讲清的约定 |
|---|---|---|
| 需求与指标 | 用户问题 → 成功标准、限制 | 查得对、可访问、足够快；什么错误不能接受 |
| 数据接入 | 原始文档 / 事件 → 带版本的记录 | 唯一 ID、来源、时间、授权、删除事件 |
| 清洗与划分 | 记录 → 可训练和可评估样本 | 去重、泄漏检查、无效与缺失的含义 |
| 特征与编码 | 文本 / 图片 → 特征或向量 | preprocessing、维度、模型版本、缺失策略 |
| 学习目标 | 样本与标签 → loss | 正负例、mask、样本 / token 权重 |
| 训练运行 | 数据快照（data snapshot）与配置 → checkpoint | 可重试、可恢复、知道每次更新用了什么 |
| 离线验收 | 候选（candidate）版本 → 切片（slice）指标与失败样本 | 不只看总分，不用测试集反复调参 |
| 产物发布 | 权重、processor、index → 版本包 | 哪些文件必须一起切换，如何退回 |
| 在线服务 | 请求 → 候选、分数、回答 | 鉴权、超时、限流、缓存、取消与降级（fallback） |
| 监控与回流 | 结果与曝光（exposure） → 排错和下一轮数据 | 记录当时真正展示了什么；保留隐私边界 |
“每个环节都有”不代表每个环节都得引入一款平台。第一个可运行版本可以只用少量文件、一个进程和固定数据集。随着规模增长，再把真正需要独立扩缩容、访问控制或故障隔离的部分拆出去。
这些工作通常怎么分？
下面是一种可用的分工示意，不是业界统一的组织结构。小团队可能一个人兼几项，大团队也可能把同一项拆得更细。MLE、SWE、RS（research scientist）这些职位名称本身不足以判断负责范围。
| 工作边界 | 可能主要负责的团队 | 交给下游的东西 | 谁需要一起验收 |
|---|---|---|---|
| 需求、体验与业务约束 | 产品、应用团队 | 指标定义、交互和失败预期 | ML、数据、服务团队 |
| 文档与行为流水 | Data engineering | schema、快照、质量检查、删除通知 | 特征与训练团队 |
| 检索 / 排序 / 视觉模型 | Applied ML、research | 模型、processor、评估与局限 | 数据、平台、应用团队 |
| 训练计算与恢复 | ML platform、training infra | 作业接口、资源、checkpoint 能力 | 模型团队确认目标没有改变 |
| 索引与线上执行 | Search、inference、backend | 可调用接口、延迟预算、fallback | 模型团队确认输出兼容 |
| 发布、可靠性与安全 | 服务 owner、SRE、security 等 | 发布开关、告警、runbook、权限策略 | 相关数据与模型 owner |
比如模型团队把向量维度从 768 改到 1024，不能只通知“新模型更准了”。索引服务要重建、请求 schema 要能区分版本、回滚要保留旧索引，评估还要覆盖新旧切换。接口和验收是共同工作，模型质量不能靠单向扔文件来保证。
一个模块最少要说清六件事
以 embedding 服务为例：
| 问题 | 这次的明确回答示例 |
|---|---|
| 吃什么输入？ | 已授权的文本或图片引用，带内容 revision |
| 输出什么？ | 固定维度向量、encoder revision、归一化约定 |
| 怎么判断正确？ | 与固定样本对照；离线 / 在线预处理一致 |
| 多久返回？ | 正常负载的目标、deadline、超时错误码 |
| 失败怎么办？ | 返回明确失败；是否可退到关键词检索由调用方约定 |
| 谁负责变更？ | 指定 owner、兼容窗口、迁移和回滚步骤 |
交接不只是 API 文档。还要能用一个 request ID 追到上游输入版本、当前模型和下游 index。否则出了问题，各服务单独看都“成功”，用户得到的却是错的。
同一张全貌图，不必对应同一种产品
| 产品 | 变化最大的部分 | 仍然要保留的检查 |
|---|---|---|
| 表格分类 / 风险预测 | 特征计算、标签延迟、分类阈值；未必有检索与 LLM | 时点一致、校准（calibration）、漂移和回滚 |
| 推荐 Feed | 用户历史、候选池、曝光、排序与探索 | 选择偏差、内容新鲜度（freshness）、切片和反馈循环 |
| RAG / 知识助手 | 文档权限、检索、上下文与引用 | 证据版本、幻觉、工具边界与成本 |
| 多模态搜索 | 图片预处理、跨模态表征（representation）与索引 | 图文配对、分辨率、encoder 兼容性 |
理解全链路，是为了知道哪些环节与你的任务有关，不是背下一张包含所有工具的架构图。
怎么把它做成一个练习
先准备 20 篇你有权使用的公开资料和 10 个自己写的问题。第一版只做关键词搜索，保存每次返回的文档 ID 与版本。第二版加入向量检索，保持评估问题不变，比较到底新增了哪些相关资料。第三版再选一个明确的失败模式处理：文档更新、权限撤回、索引版本不匹配，或服务超时。
暂时不训练也没关系。能解释数据何时更新、结果为什么出现、失败怎样恢复，已经比“接了几个 API”多理解一大步。需要训练时，再读下一篇从数据到可发布模型。
本页术语 9
- 检索 retrieval
- 从外部语料里找出相关内容
- 数据快照 data snapshot
- 固定在某个时间点可见的数据版本，避免重跑时读到未来状态
- 候选 candidate
- 召回阶段捞出来、等待精排挑选的内容
- 切片 slice
- 按内容或用户属性划分的子群体，用来检查平均值掩盖了什么
- 降级 fallback
- 主路径不可用时切换到较简单但语义明确的备用行为
- 曝光 exposure
- 内容真的被展示给用户这件事，和「被检索到」不是一回事
- 校准 calibration
- 模型给出的置信度是否等于真实正确率
- 新鲜度 freshness
- 内容产生到可被检索之间的延迟
- 表征 representation
- 将原始信息转换成模型可以使用的形式，例如向量