跳到主要内容

给从业者的建议

要解决的问题​

信息过载、榜单焦虑、工具链日更——如何 投入时间 才能稳定交付 可评测、可维护 的 LLM 产品？

按角色的最短路径​

角色优先精读动手
应用工程师4.1 SFT、5.1 解码、5.6 服务、docs RAG/AgentvLLM + 一个小 benchmark
训练工程师3.1 数据、3.5 并行、3.6 稳定、4.3–4.4 对齐LoRA/QLoRA 复现
推理工程师5.2 KV、5.3 量化、5.5 投机解码压测 TTFT/tokens/s
研究员2.3 改进、6.2 测试时、7.2 评测、8 报告复现一篇论文 ablation
管理者3.4 Scaling、7.1 基准、9.4 边界定义 业务指标 非 MMLU

十条实践原则​

  1. 评测先行：上线前固定 prompt 集与 回归脚本。
  2. 基线朴素：先 zero-shot + RAG，再上大模型微调。
  3. 记录配方：数据 hash、超参、权重版本 可复现。
  4. 分离思考成本：推理模型设 token 预算 与超时。
  5. 工具验证：数学/代码 执行器 优先于 CoT 自洽。
  6. 监控幻觉率：抽样人工 + 自动事实核查（能做的域）。
  7. 对齐合规：用户数据 不进 默认训练；隐私删除路径。
  8. 别追每一个新模型：等 推理栈成熟 再迁移（2–4 周）。
  9. 读 primary source：技术报告 > 自媒体摘要。
  10. 贡献开源：修文档、报 vLLM issue，反哺社区。

学习资源（本仓库）​

常见陷阱​

陷阱对策
只看 MMLU加 业务端到端 指标
微调一切先 prompt + RAG
忽视上下文截断测 真实日志长度分布
开源权重无许可审查法务看 商用条款

职业趋势（个人理解，待验证）​

  • 「LLM 工程师」 分化：数据、对齐、推理、Agent 四条线。
  • 评测与红队 需求上升。
  • 纯提示词岗位 被 Agent 编排 吸收，但 领域知识 更值钱。

检查清单（自学 / 落地）​

步骤动作
1阅读官方 primary source（报告、博客、模型卡）
2固定 prompt 与解码参数，在自有验证集上建基线
3记录延迟、成本、上下文长度与是否启用思考模式
4与相邻章节对照，画出与上下游模块的数据流
5在 paper-reading 或本大纲相关节做深度笔记

常见误区​

误区澄清
公开基准 = 产品表现必须用业务端到端任务回归
长窗口 = 长理解需 Needle + 真实文档任务验证
单次实验可定论固定随机种子、数据版本与评测脚本

延伸练习​

相关章节​