AI系统工程实践

LLM 与工程系统的边界

LLM 是一个强大的概率系统，但它不是万能的。在后端系统中集成 LLM，首先需要明确它的能力边界和适用场景。

AI 术语的工程含义

核心原则：模型负责"决策"，系统负责"可靠性"。

设计 LLM 应用时，需要明确回答：

• 状态存在哪里？
• 控制流谁管？
• 失败时如何回滚？

如果无法回答这些问题，说明该场景的 LLM 集成方案尚未完成工程化。

适合使用 LLM 的场景

1. 模糊意图 → 结构化决策

用户输入是自然语言，模糊、不完整、上下文依赖强，难以用 if/else 或规则覆盖的场景。把"人脑里那套判断"交给模型处理。

典型场景：客服意图识别、文档归类、非结构化查询理解。

2. 高维规则压缩

当系统中规则数量持续增长、各种条件分支交织、产品频繁调整规则逻辑时，用隐式概率模型替代显式规则表。

典型场景：推荐系统排序策略、内容审核规则、金融风控规则。

3. 内容理解与生成

长文总结、日志解释、错误原因描述、用户输入改写——这类任务的输出作为辅助信息，出错后果可接受。

典型场景：日志摘要、文档翻译、内容改写。

不适合使用 LLM 的场景

以下场景应谨慎或避免使用 LLM：

1. 核心业务状态直接修改——LLM 的概率特性不适合执行不可逆的状态变更
2. 强一致性要求——两次相同调用可能产生不同结果
3. 需要严格可复现行为——相同输入不保证相同输出
4. 长时间自主运行的 Autonomous Agent——缺乏可靠的边界控制和可观测性

工程决策框架

使用以下问题清单评估是否适合引入 LLM：

• 全是"是"：适合使用 LLM
• 有 2 个"否"：谨慎评估，缩小使用范围
• 3 个以上"否"：不适合，应寻找其他方案

系统设计的可靠性原则

LLM 集成进入后端系统时，应遵循以下工程原则：

边界清晰：明确 LLM 的职责范围，不将核心业务逻辑托付给模型

可观测：记录输入、输出、模型版本，支持问题复现

可回滚：具备版本控制和回滚机制

成本可控：对最坏情况下的 token 消耗有预估和上限控制

任何进入核心业务路径的能力，必须满足：可版本化、可回滚、可监控、可限流。

本节小结

LLM 的核心价值在于处理模糊输入、做高维规则压缩和内容理解。将其集成到后端系统时，关键是保持工程边界清晰——让系统为可靠性负责，而不是把可靠性寄托在模型的不确定性上。

延伸阅读

• RAG 与知识库 — LLM 与外部知识库结合的工程实践
• 数学基础：反向传播 — 理解 LLM 输出的概率本质从何而来