5种可扩展的LLM架构模式（以及2种不可扩展的）

Source: Dev.to

可扩展的模式

简单提示流

User Input → Prompt Template → LLM API → Response → User

简单。可靠。易于调试。大多数 LLM 功能应从这里开始。

检索增强生成

Query → Vector Search → Context → Prompt → LLM → Response

适用于问答、知识库、任何需要特定信息的场景。

规划 + 工具使用

Task → LLM Planning → Tool Calls → Review → Output

用于需要多步骤的复杂任务。更强大但调试更困难。

缓存

Input → Cache Check → [HIT] → Response
               → [MISS] → LLM → Cache → Response

降低重复查询的成本和延迟。规模化时必不可少。

人在回环审查

LLM Output → Human Review → [APPROVE] → Output
                         → [REJECT] → Retry

用于高风险决策。成本高，但合规所需。

不可扩展的模式

直接写入

User → LLM → Database Write → Response

没有验证。没有审查。记录、输出并破坏数据。只能在演示规模下工作，生产环境会崩溃。

单体提示

Complex Prompt = System + Context + History + Constraints + Examples + ...

一个 2000 token 的提示要完成所有工作。无法测试、调试或进行版本控制。

通用指导

• LLM 架构就是软件架构。相同的原则适用：模块化、测试、版本管理、可观测性。
• 如果你的 LLM 功能在微服务的代码审查中会被否决，那么它在生产环境中也会出问题。

构建可扩展的 LLM 功能？我会分享生产实践中的有效方法。关注我吧。