# 工程与研究结合的重要性

大模型领域有一个非常典型的“断层”：

- 研究侧容易停留在：公式、论文指标、SOTA 结论
- 工程侧容易停留在：代码能跑、吞吐够用、线上不崩

但在 LLM/MLLM 里，这两者必须强绑定：**很多看起来是“模型问题”的失败，本质是系统问题；很多看起来是“系统问题”的瓶颈，本质是建模假设与目标函数问题。**

本章给出一套可复用的方法论：用工程约束反推研究问题，用研究抽象指导工程拆解。

---

## 为什么大模型更需要“工程 × 研究”闭环？

### 1) 成本巨大：你无法靠试错“碰出来”

训练一次模型的成本（数据/算力/时间/人力）很高。如果没有研究层的抽象（问题定义、变量控制、有效评测），工程迭代会退化成“调参玄学”。

### 2) 失败模式多：指标提升并不等于可用

典型例子：

- 生成更流畅，但事实性更差（幻觉更严重）
- benchmark 提升，但线上 domain shift 下崩溃
- 多模态回答更长，但引用证据更少（不可审计）

研究侧要回答“为什么”，工程侧要回答“如何控制与验证”。

### 3) 系统即模型：推理栈会改变模型行为

推理阶段的很多工程决策会直接改变模型输出：

- decoding 策略（温度、top-p、beam）
- 上下文组织（RAG、摘要、记忆）
- KV cache、量化带来的数值误差
- 工具调用与权限边界

这意味着：**模型的“最终能力”不是 checkpoint 的属性，而是系统组合的属性。**

---

## 一个可落地的工作流：把“研究问题”工程化

推荐把任何新方向按以下步骤推进：

### 1) 明确问题定义（Definition）

- 输入是什么？输出是什么？
- 目标函数是什么？可否近似？
- 约束是什么？（安全、合规、时延、成本、可审计）

### 2) 明确评测与失败标准（Evaluation）

- 离线评测指标是否与线上目标一致？
- 是否有“可验证”指标（结构化、可执行、引用证据）？
- 失败是否可定义（拒答/降级/回滚）？

### 3) 拆解成系统闭环（System Loop）

把系统拆成：观察 → 计划 → 行动 → 校验 → 记忆 → 监控 → 数据闭环。

在这个闭环里，模型只负责它擅长的部分；硬约束与审计放在系统层。

---

## 常见误区（非常容易踩坑）

### 误区 1：把“不可验证”的任务当作监督学习

如果标签本身不稳定、reward 不可定义、或者存在强混杂（如医疗决策），端到端学习往往不是“效果差”，而是“问题定义不成立”。

（你在 `posts/end2end_medical_model.md` 已经给了一个非常典型的案例。）

### 误区 2：只追单一指标，忽略行为约束

例如只追 BLEU/CIDEr/Win-rate，但不约束：

- 引用证据
- 格式与结构
- 越权与敏感输出

结果是：指标上去了，系统不可控。

### 误区 3：把推理性能当作“部署后再优化”

LLM/MLLM 的推理瓶颈（KV cache、带宽、batching、量化误差）会反过来限制你能用的上下文与策略，从而改变最终效果。正确做法是：**从第一天就把 P95/P99、成本与可观测性放进设计。**

---

## 工程视角的“严谨性”：你需要哪些证据？

当你说“这个方法有效”，最好能回答：

- **归因**：是数据变了？目标函数变了？还是推理策略变了？
- **稳定性**：不同 seed、不同 prompt 分布、不同长度下是否稳定？
- **可解释**：失败时能否定位到：数据/模型/推理/系统哪一层？
- **可复现**：能否用固定配置在另一台机器/另一套环境复现？

---

## 最小工程清单（建议作为章节/项目模板）

- **配置管理**：训练/推理配置可追溯（版本、超参、数据 hash）
- **评测集治理**：防泄漏、覆盖关键场景、定期更新
- **在线监控**：时延、token/s、OOM、拒答率、幻觉指标（如引用缺失）
- **安全策略**：权限、敏感过滤、关键动作确认
- **数据闭环**：线上失败样本自动收集→标注/规则→再训练/再评测

---

## 本章小结

- 在大模型里，“系统设计”与“模型方法”是同一个问题的两种表述。
- 研究给你抽象与可控变量，工程给你约束、证据链与可迭代闭环。
- 任何章节/项目都应围绕：问题定义、评测标准、系统闭环与失败可控性来构建。