胶水层与核心引擎

两种架构定位

LLM 在应用架构中的定位只有两种基本模式，所有变体都是这两种模式的组合或中间状态。

胶水层模式： LLM 负责连接、转换和路由，核心业务逻辑由确定性代码承载。LLM 理解用户意图并将其映射为系统调用，但不直接执行业务决策。

核心引擎模式： LLM 本身就是业务逻辑。内容生成、创意写作、对话交互、复杂推理——LLM 的输出直接就是产品的价值所在。

区分这两种模式的标准很简单：如果把 LLM 替换为一个完美的自然语言理解模块（总是正确解析意图）加上一组 if-else 路由，系统的核心功能是否还能工作？ 如果能，LLM 是胶水层；如果不能，LLM 是核心引擎。

这个区分的工程意义在于：两种模式对可靠性、测试策略和架构设计的要求截然不同。

胶水层模式的架构特征

用户输入 → [LLM: 意图识别 + 参数提取] → [确定性逻辑: 业务处理] → [LLM: 结果格式化] → 输出

胶水层模式中，LLM 出现在系统的边缘位置：输入端负责理解和结构化，输出端负责自然语言生成。中间的业务逻辑是确定性的——数据库查询、规则引擎、计算流程。

这种架构的优势：

可靠性可控。 核心业务逻辑是确定性的，其正确性可以通过传统测试保证。LLM 的不确定性被限制在系统边缘，即使 LLM 偶尔解析出错，影响也有限。

可替换性强。 LLM 模块可以独立升级或替换，不影响核心逻辑。从 GPT-4 切换到 Claude，或者从云端 API 切换到本地模型，改改边缘模块的适配层就行。

成本可预测。 LLM 调用的频率和复杂度可以被精确控制——每次用户请求固定调用 1-2 次 LLM，token 消耗可以估算。

多数商业应用应该选择这种模式。电商客服、企业知识问答、数据分析助手——这些应用的核心价值在于后端的业务系统和数据，LLM 的角色是让用户能用自然语言与这些系统交互。

核心引擎模式的架构特征

用户输入 → [LLM: 核心处理] → 输出
           ↑ 可选的工具辅助 ↓

核心引擎模式中，LLM 是价值创造的主体。用户请求"写一篇技术博客""把这段代码重构为函数式风格""为这个 API 设计测试用例"——这些任务的输出质量直接取决于 LLM 的能力，没有确定性代码可以替代。

这种架构的特征：

质量上限取决于模型。 系统的能力天花板就是 LLM 的能力天花板。模型升级可以直接提升产品质量，但反过来，产品的核心竞争力也就绑定在了你选的模型上。

不确定性本身就是产品特性。 内容生成的价值恰恰在于每次输出的不同——如果每次生成完全相同的文本，就不需要 LLM 了。所以传统的"输入-输出一致性"测试策略不适用。

成本与质量强正相关。 更长的上下文、更多的推理步骤、更强大的模型——这些提升质量的手段都直接增加成本。成本优化可能损害产品质量。

混合模式与边界判断

实际系统通常是两种模式的混合。关键是为每个组件做出正确的定位判断。

# 混合模式示例：智能客服系统

# 胶水层：意图识别（LLM 可被规则替代）
intent = classify_intent(user_message)  # LLM 调用

# 确定性逻辑：业务处理
if intent == "check_order":
    result = order_service.get_status(order_id)  # 数据库查询
elif intent == "request_refund":
    result = refund_service.initiate(order_id)   # 业务流程

# 核心引擎：个性化回复生成（LLM 不可替代）
response = generate_response(result, user_context)  # LLM 调用

意图识别是胶水层——理论上可以用规则引擎替代，LLM 只是让它更灵活。业务处理是确定性逻辑——必须精确执行。回复生成是核心引擎——自然、个性化的回复需要 LLM 的生成能力。

边界判断的原则：凡是需要精确性和一致性的操作（计算、数据查询、状态变更），用确定性代码；凡是需要灵活性和自然性的操作（理解意图、生成文本、处理模糊输入），用 LLM。 不要让 LLM 做它不擅长的事（精确计算），也不要让确定性代码做它不擅长的事（理解自然语言）。

架构定位决定测试策略

胶水层模式下，LLM 模块的测试重点是分类准确率和参数提取准确率——拿一组输入去测，LLM 是否正确识别了意图、是否正确提取了参数。这可以用传统的准确率/召回率指标来衡量，可以构建标注数据集进行回归测试。

核心引擎模式下，测试重点是输出质量的统计分布——多次输出的质量是否稳定在可接受的水平。这需要第六章讨论的评估即测试方法。

混合模式下，每个组件按其定位采用对应的测试策略。确定性部分用单元测试，胶水层部分用分类测试，核心引擎部分用统计评估。这种分层测试策略比端到端测试更高效，因为它把不确定性限制在尽可能小的范围里。