工程与研究结合的重要性
大模型领域有一个非常典型的“断层”：
研究侧容易停留在：公式、论文指标、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、拒答率、幻觉指标（如引用缺失）
安全策略：权限、敏感过滤、关键动作确认
数据闭环：线上失败样本自动收集→标注/规则→再训练/再评测
本章小结
在大模型里，“系统设计”与“模型方法”是同一个问题的两种表述。
研究给你抽象与可控变量，工程给你约束、证据链与可迭代闭环。
任何章节/项目都应围绕：问题定义、评测标准、系统闭环与失败可控性来构建。