读 Tuning the Stochastic Machine,补几条洞:
1.30 年系统工程师视角这把刀切得真稳。
Andrikopoulos 把 LLM 栈映射到他职业已经操过的"机器"——冻结硅、固件、可加载模块、持久配置、易失存储。这一招价值在「复用既有概念框架,不重发明轮子」。LLM ops 现在最大的问题是大家都在造新词:RAG、prompt engineering、agent orchestration——其实都对应到早已成熟的固件/可加载模块/持久配置那一套。把 SRE 的 mental model 套到 LLM 上,比任何一个 agent framework 都更接近「可运维」这个目标。
2.作者自承的踩坑——「我自己实践中的三个案例,其中有一个控制无声地变成了它旨在防止的确切伤害」。
这不是标准学术范式能写出来的话——它的真正意思是:加护栏有时候只是把同一种伤害换个叫法。LLM 防御里很常见的"permissive whitelist + 静态 deny"被反复绕过,就是这一类。这种"自承自坏"的写作在学术论文里太罕见了,反而给整篇论文加了一分诚实度。
3."持久化纠正的机制存在,但管理它们的纪律不存在"这一句话要划重点。
Claude Memory / Cursor Avante.md / Codex AGENTS.md / Copilot custom instructions——这些"持久纠正机制"2025-2026 已经都发货。问题是:versioning with provenance、recurrence monitoring、counter-metrics、retirement of stale rules 这四条操作纪律,整个领域没人在做。这才是 LLM 运维的最大缺口,不是技术不够,是 SRE 纪律没搬过来。
4.LLM 栈里三个映射失败的点其实是要害。
(a) 随机生成(每一轮都不一定同结果)、(b) 仅概率绑定的配置("按概率有效"是幻觉)、(c) 没有通用退役(验证)阶段——LLM 厂商默认没有"rule retirement API"。要等哪天 OpenAI / Anthropic 把 rule deprecation 做成 system prompt 可卸载 skill,这场运维革命才到临门一脚。这一点也是 Andrikopoulos 姊妹篇(Grouping)的"shot adjustment"真正能落地的工程配套。
下一根最该盯的钉子:作者下一篇会落在哪里?他公开说自己 GitHub george-andrikopoulos 仓库目前只放这两篇论文 + 一份不完整的草稿。我的猜测是下一篇会把"操作纪律"映射到 AI Code Review 上——把人类 code reviewer 的能力当作"override signal"给 LLM ops 学,加上 versioning + retirement + recurrence monitor 完整的 SLI/SLO 体系。这决定这篇是否成为 LLM SRE 第一本 ops runbook。
#LLMops #系统工程师视角 #SRE #纪律 #Andrikopoulos