← 返回概念解读

Concept Fable精修版

大语言模型运维

LLMOps · Operations / platform

先读故事。这里不急着给定义,先让问题自己长出来。

寓言故事

会写信的书记员上岗以后

石桥镇原来只有三名书记员。镇民要写契约、回商函、查旧案,都排队等他们。书记员慢,但每个人的章、纸、柜子和责任都清楚。

镇里后来请来一批会自动写信的木偶。它们写得快,也能翻旧档案。第一天,队伍短了很多,镇长觉得旧流程可以全部撤掉。

复杂很快出现。木偶有时引用过期条款,有时把相似人名混在一起,有时为了显得完整,补上没人说过的细节。更麻烦的是,不同木偶、不同信纸模板、不同档案柜组合出来的结果都不一样。

镇长的修补是把每个木偶前面贴一句更长的训令:务必准确、务必谨慎、务必遵守规矩。训令越贴越长,出错时却没人知道是训令、档案、木偶版本还是审阅流程出了问题。

一次大客户收到错误契约后,镇里才停下来复盘。老书记员说,自动写信不是只买木偶,它需要一整套工坊:模板谁维护,档案怎么取,结果怎么测,成本怎么看,风险由谁放行。

他们建立了新的书信司。每个模板有版本,每个档案来源有标记,每次生成都留下那套机器、提示词、检索片段、工具调用和审阅记录。高风险信件必须经过评测和人工放行。

书信司还规定了月度体检:抽样看质量,追踪延迟和费用,检查哪些问题频繁触发回退,哪些模板已经不适合新的业务。

木偶仍然负责大量书写,但它们不再像散落的聪明工具,而是进入一条能部署、监控、评测、治理和回滚的生产线。镇长后来明白,大语言那套机器能写出答案,不能自动给企业带来可运营的系统;真正难的是让答案在业务里长期稳定、可控、可解释地交付。后来,又来了一件更棘手的活。表面看只是旧问题放大,实际把藏在流程里的缝隙都逼了出来:谁先接手、谁能改动、出了错怎样回到上一步,过去靠熟人默契混过去的地方,现在都必须说清楚。

揭示

这个故事讲的是:大语言模型运维

LLMOps 是面向大语言模型应用的运维体系,重点管理提示词、检索、评测、安全、成本、延迟和模型版本。它把 LLM 应用从 demo 推向生产:提示词要版本化,RAG 要可追踪,评测要可回归,模型路由和回退要有策略,成本与延迟要被监控,安全和治理要进入发布流程。

它重要的地方在于:它不只是一个术语,而是在真实 AI / Agent 系统里会反复出现的结构性问题。理解它,才能判断什么时候该加模型,什么时候该改流程,什么时候该补治理。

隐喻映射

  • 会写信的木偶:LLM 和 Agent 能力
  • 训令越贴越长:只靠 prompt 加强约束的天真修补
  • 模板、档案、木偶版本混杂:提示词、检索、模型和工具链共同影响输出
  • 书信司:LLMOps 平台与运行体系
  • 生成记录:prompt、context、model、tool call、trace 和审计日志
  • 月度体检:evals、监控、成本分析和风险复查
  • 人工放行:HITL、审批与高风险控制
  • 最后洞察:LLMOps 管的是 LLM 应用的持续交付质量,而不只是模型调用

Soloharness 判断

这个概念的实战价值,是帮你把“看起来聪明的 AI 功能”拆成可交付、可验收、可治理的工作单元。

Prompt managementRAGevalsguardrailsmodel routingtoken costobservability