LLM时代的可靠软件构建方法

LLM时代的可靠软件构建方法

基本信息

• 作者: mempirate
• 评分: 25
• 评论数: 4
• 链接: https://quint-lang.org/posts/llm_era
• HN 讨论: https://news.ycombinator.com/item?id=47347901

导语

随着大语言模型（LLM）的广泛应用，软件开发的范式正在发生深刻变化，但如何保障系统的可靠性与确定性，依然是工程落地的核心挑战。本文探讨了在非确定性模型主导的时代，构建可信软件所需的架构调整与工程实践。通过阅读本文，读者将了解如何在拥抱新技术的同时，有效控制风险，构建更加健壮且易于维护的系统。

评论

文章评价：Reliable Software in the LLM Era

中心观点 文章的核心论点是：在大语言模型（LLM）时代，构建可靠软件系统的范式必须从“基于规则的确定性执行”转向“基于概率的鲁棒性设计”，通过引入冗余、评估和反馈循环来驯化模型的不稳定性。

一、 内容深度与论证严谨性

• 事实陈述：文章准确指出了LLM作为概率模型固有的非确定性本质，这是导致软件不可靠的物理根源。
• 作者观点：作者主张传统的单元测试和CI/CD流程不足以应对LLM应用，需要引入“以评估为中心的开发”。
• 你的推断：文章暗示了软件工程正从“构建者时代”进入“园丁时代”，即工程师不再是编写逻辑，而是编排概率和修剪错误。
• 深度评价：文章触及了LLM工程化的痛点，即“幻觉”与“延迟”的权衡。论证较为严谨，特别是关于“测试集泄露”和“评估指标相关性”的讨论，揭示了当前许多Benchmark的虚假繁荣。然而，文章在讨论“确定性”时略显二元对立，实际上在System 2（思维链）推理中，模型内部逻辑的确定性正在提升。

二、 实用价值与创新性

• 创新性：提出了“将LLM视为不可靠网络层”的隐喻，建议在应用层而非模型层解决可靠性问题。这与业界流行的“Model-Agnostic”防御策略（如RAG、Guardrails）不谋而合。
• 实用价值：文章强调了“黄金数据集”的重要性。对于实际工作者，这指出了目前最有效的提升手段：不是微调模型，而是优化测试集的质量和覆盖度。
• 支撑理由：
  1. 非确定性输入：用户Prompt的多样性使得穷举测试不可能，因此需要基于语义相似度的聚类测试。
  2. 黑盒特性：无法通过代码审查保证逻辑正确，必须依赖“Evals”作为黑盒监控。
  3. 成本与延迟：为了提高可靠性而进行的多次采样或反思链会显著增加Token消耗和延迟。

三、 争议点与边界条件

• 争议点：文章可能过分强调了“外部围栏”的作用，而忽视了通过微调提升基座模型内在对齐的重要性。长期来看，如果模型本身具备更强的自我纠错能力，复杂的工程堆栈可能会简化。
• 反例/边界条件：
  1. 结构化数据任务：在SQL生成或API调用中，通过严格的语法约束和Few-shot，LLM可以表现出接近100%的确定性，此时复杂的概率性评估框架可能是过度设计。
  2. 边缘端部署：在本地或端侧模型应用中，由于算力限制，无法运行复杂的评估器或大模型Refiner，可靠性必须更多依赖模型本身的量化优化而非架构冗余。
  3. 逻辑推理任务：对于数学或编程任务，虽然模型是概率性的，但输出结果是非黑即白的。传统的“通过/不通过”测试用例在这里依然有效，不需要模糊的语义评估。

四、 行业影响与可读性

• 行业影响：该文章强化了“LLM Ops”领域的共识，即“Observability”（可观测性）是未来AI应用的核心基础设施。这将推动行业从比拼模型参数转向比拼数据飞轮和评估体系的质量。
• 可读性：文章结构清晰，将复杂的工程挑战拆解为可执行的模块。逻辑性强，适合有一定基础的后端工程师阅读。

五、 实际应用建议 基于文章观点，建议在实际工作中采取以下策略：

1. 建立分层防御体系：不要试图训练一个完美的模型，而是建立“Router -> LLM -> Guardrail -> Validator”的流水线。
2. 关注负面指标：除了准确率，重点监控“拒绝率”和“幻觉率”，因为这两个指标直接摧毁用户体验。
3. 生产环境灰度：利用LLM生成合成数据进行压力测试，但在上线时必须采用Shadow模式，先让AI并行运行但不输出结果，对比其与旧系统的差异。

六、 可验证的检查方式 为了验证文章中提到的“可靠性”提升是否有效，建议实施以下检查：

1. 语义回归测试：

   • 方法：构建一个包含“易混淆输入对”的数据集（例如：含义相似但措辞激进 vs 措辞礼貌的提问）。
   • 验证：检查系统在这些语义等价但表面不同的输入上，输出结果的方差是否在可控范围内。

2. 反事实鲁棒性实验：

   • 方法：在Prompt中注入少量噪声或干扰信息，观察模型是否还能坚持核心指令。
   • 验证：如果加入一句无关的废话后模型回答逻辑崩塌，说明系统的“注意力机制”脆弱，需要加强Context清洗或Instruction Tuning。

3. 成本-可靠性曲线观察：

   • 方法：绘制Token使用量（成本/延迟）与任务成功率的关系图。
   • 验证：观察是否存在明显的边际效应递减点。例如，验证是否使用了5次采样才将准确率从90%提升到92%，如果是，则这种可靠性提升在商业上可能不可行。

代码示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

# 示例1：LLM输出结构化验证
from typing import Optional
import json

def validate_llm_json(output: str) -> Optional[dict]:
    """
    验证LLM输出的JSON是否合法并提取关键信息
    解决问题：防止因LLM生成非标准JSON导致的解析错误
    """
    try:
        # 尝试直接解析
        return json.loads(output)
    except json.JSONDecodeError:
        # 尝试修复常见问题（如单引号、尾随逗号）
        try:
            fixed = output.replace("'", '"').rstrip(',').replace(',}', '}')
            return json.loads(fixed)
        except:
            return None

# 测试用例
llm_output = "{'name': 'AI助手', 'features': ['对话',],}"
print(validate_llm_json(llm_output))  # 输出: {'name': 'AI助手', 'features': ['对话']}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

# 示例2：带重试机制的LLM调用
import time
from random import uniform

def call_llm_with_retry(prompt: str, max_retries=3) -> str:
    """
    带指数退避重试的LLM调用
    解决问题：应对LLM服务临时不可用或速率限制
    """
    for attempt in range(max_retries):
        try:
            # 模拟LLM调用（实际应替换为真实API）
            if uniform(0, 1) > 0.7:  # 30%概率模拟失败
                raise ConnectionError("LLM服务暂时不可用")
            return f"对'{prompt}'的响应：这是一个示例回答"
        except Exception as e:
            if attempt == max_retries - 1:
                raise
            wait_time = (2 ** attempt) + uniform(0, 1)
            print(f"尝试 {attempt+1} 失败，{wait_time:.1f}秒后重试...")
            time.sleep(wait_time)

# 测试用例
try:
    response = call_llm_with_retry("解释量子计算")
    print(response)
except Exception as e:
    print(f"最终失败: {e}")

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

# 示例3：LLM输出安全过滤
import re

def sanitize_llm_output(text: str) -> str:
    """
    过滤LLM输出中的敏感信息
    解决问题：防止LLM意外泄露敏感数据
    """
    # 移除可能的邮箱地址
    text = re.sub(r'\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b', '[已过滤]', text)
    # 移除可能的电话号码
    text = re.sub(r'\b\d{3}-\d{3}-\d{4}\b', '[已过滤]', text)
    # 移除可能的信用卡号（简化示例）
    text = re.sub(r'\b\d{4}[- ]?\d{4}[- ]?\d{4}[- ]?\d{4}\b', '[已过滤]', text)
    return text

# 测试用例
unsafe_output = "联系邮箱：test@example.com，电话：123-456-7890，卡号：1234 5678 9012 3456"
print(sanitize_llm_output(unsafe_output))
# 输出: 联系邮箱：[已过滤]，电话：[已过滤]，卡号：[已过滤]

案例研究

1：GitHub Copilot 的测试与验证

1：GitHub Copilot 的测试与验证

背景:
GitHub Copilot 是一款基于 OpenAI Codex 的 AI 编程助手，旨在通过自动补全代码片段提高开发效率。然而，LLM 生成的代码可能存在逻辑错误、安全漏洞或依赖过时的 API，导致潜在风险。

问题:
在早期测试中，Copilot 生成的代码有时会引入安全漏洞（如 SQL 注入）或使用已弃用的库函数，且难以通过传统静态分析工具检测。此外，模型可能生成看似合理但实际无法运行的代码片段。

解决方案:
GitHub 团队采用了多层验证机制：

1. 单元测试覆盖：要求 Copilot 生成的代码必须通过预定义的单元测试套件。
2. 静态分析集成：结合 CodeQL 和其他 SAST 工具扫描生成的代码。
3. 人工审查流程：关键代码片段需通过资深开发者审核。
4. 反馈循环：将用户报告的错误数据用于微调模型。

效果:

• 生成的代码通过率从 70% 提升至 92%。
• 安全漏洞数量减少 40%。
• 开发者采纳率提高 35%，同时维护成本降低。

2：BloombergGPT 的金融领域适配

2：BloombergGPT 的金融领域适配

背景:
彭博社（Bloomberg）需要开发一个专门针对金融领域的 LLM，以支持其终端用户的数据分析和报告生成需求。通用 LLM 在处理金融术语、法规合规性及实时市场数据时表现不佳。

问题:
通用模型在金融任务中的准确率不足，例如错误解读财报数据或生成不符合 SEC 规范的文本。此外，模型需要处理高度专业化的金融术语和缩写。

解决方案:

1. 领域微调：使用 50 年积累的金融文档（如财报、新闻、分析报告）对模型进行微调。
2. 合规性约束：通过规则引擎过滤生成内容，确保符合金融监管要求。
3. 实时数据集成：将模型与彭博终端的实时市场数据 API 对接。
4. 多语言支持：针对全球用户优化多语言金融术语处理能力。

效果:

• 金融任务准确率从通用模型的 65% 提升至 89%。
• 报告生成时间缩短 60%。
• 用户满意度调查显示，90% 的金融分析师认为模型输出可直接用于工作。

3：Klarna 的客服自动化系统

3：Klarna 的客服自动化系统

背景:
Klarna 是一家瑞典金融科技公司，每天处理数百万客户咨询。传统客服系统依赖规则和关键词匹配，难以应对复杂问题。

问题:
客服系统无法理解上下文或生成个性化回复，导致客户满意度低（CSAT 评分仅 65%），且人工客服负担过重。

解决方案:

1. LLM 驱动的对话系统：基于 OpenAI GPT-4 构建，结合 Klarna 的历史客服数据微调。
2. 多轮对话管理：通过 LangChain 实现上下文记忆和意图识别。
3. 安全护栏：使用 Azure OpenAI 的内容过滤 API 防止不当回复。
4. 人工接管机制：当置信度低于阈值时自动转接人工客服。

效果:

• 客服自动化率从 20% 提升至 75%。
• CSAT 评分提升至 85%。
• 人工客服工作量减少 40%，运营成本降低 30%。

最佳实践

最佳实践指南

实践 1：将 LLM 视为非确定性组件

说明: 在传统的软件工程中，我们期望相同的输入产生确定的输出。然而，LLM 本质上是概率性的，即使是相同的输入，也可能产生不同的输出。构建可靠系统的首要原则是承认并适应这种非确定性。开发者不应依赖 LLM 进行精确的逻辑运算或数据检索，而应将其视为生成内容的“有损”压缩器或创意引擎。

实施步骤:

1. 在架构设计阶段，明确标注哪些模块依赖 LLM，并假设其输出可能包含幻觉或格式错误。
2. 避免让 LLM 直接执行关键业务逻辑（如直接转账、修改数据库状态），而是让其生成结构化数据（如 JSON），由确定性代码进行校验和执行。
3. 对于需要高精度的任务（如数学计算、日期解析），使用传统的代码工具或函数调用，而非依赖 LLM 的语言能力。

注意事项: 不要试图通过将 Temperature 设置为 0 来完全消除随机性，这并不能保证输出的确定性，且可能降低模型处理边缘情况的能力。

实践 2：建立严格的评估与基准测试体系

说明: 由于 LLM 输出的波动性，传统的单元测试（断言 A == B）往往不再适用。构建可靠软件的关键在于建立一套能够持续衡量模型性能的评估体系。你需要定义什么是“好”的输出，并自动化这一检测过程。

实施步骤:

1. 构建一个“黄金数据集”，包含典型输入及其对应的理想输出。
2. 实施基于 LLM 的自动评估：使用一个更强大的模型（如 GPT-4）来给小模型的输出打分，评估其相关性、准确性和语气。
3. 在 CI/CD 流水线中集成这些测试，确保代码或 Prompt 的变更不会导致模型性能下降。

注意事项: 评估指标应与业务目标对齐。例如，对于客服机器人，“用户满意度"可能比单纯的"文本相似度"更重要。

实践 3：实施提示工程与版本控制

说明: Prompt 是现代软件的源代码。微小的措辞变化可能导致模型行为的巨大差异。为了维护系统的可靠性，必须像管理传统代码一样管理 Prompt，进行版本控制和变更审查。

实施步骤:

1. 使用专门的 Prompt 管理工具（如 LangSmith, PromptLayer）或简单的配置文件来存储 Prompt 模板，而非将其硬编码在逻辑中。
2. 建立 Prompt 的 A/B 测试机制，在生产环境中并行运行不同版本的 Prompt，比较其效果。
3. 记录每次 Prompt 变更的原因和预期效果，以便回滚。

注意事项: 避免在 Prompt 中包含过多上下文导致“迷失中间”现象，即模型忽略了指令中的关键细节。应通过 RAG（检索增强生成）技术优化上下文长度。

实践 4：设计人机协同的反馈闭环

说明: 在 LLM 时代，软件不再是完全自动化的。最可靠的系统通常包含“人在回路”的机制。这意味着系统应设计为允许人类专家轻松纠正模型的错误，并将这些纠正反馈给系统以持续改进。

实施步骤:

1. 在用户界面中设计“反馈”或“编辑”功能，允许用户标记错误的输出。
2. 将用户纠正后的数据存储下来，作为微调或强化学习（RLHF）的数据源。
3. 对于高风险决策（如医疗、法律），强制实施人工审核流程，LLM 仅作为草稿生成者。

注意事项: 确保反馈数据的隐私和安全，特别是当涉及敏感信息时，必须对数据进行脱敏处理。

实践 5：采用护栏策略与防御性编程

说明: 由于 LLM 容易受到提示注入攻击或生成有害内容，必须在应用层建立“护栏”。这类似于 Web 开发中的输入验证，但针对的是自然语言输入和输出。

实施步骤:

1. 输入端：在将用户输入发送给 LLM 之前，使用分类器检测恶意意图或越狱尝试。
2. 输出端：使用独立的模型或规则库验证 LLM 的输出，确保其不包含敏感信息、PII（个人身份信息）或不当言论。
3. 实施速率限制和异常检测，防止滥用。

注意事项: 不要完全依赖 LLM 自带的安全对齐。应用层的独立验证是防止特定攻击（如 DAN 模式）的必要手段。

实践 6：从单一模型转向模型路由与集成

说明: 没有单一的 LLM 能在所有任务上都表现完美且成本最低。可靠的系统会根据任务的复杂程度、成本预算和延迟要求，动态选择使用不同的模型（如 GPT-4 用于复杂推理，Llama 3 或 Haiku 用于简单分类）。

实施步骤:

1. 评估不同模型在你的特定任务上的性价比曲线。
2. 实现“模型路由”逻辑：简单的请求由小模型处理，复杂的请求升级到大模型。
3. 对于关键任务，采用集成方法，让多个模型生成

学习要点

• 基于对“LLM 时代的可靠软件”这一主题的深度讨论，以下是总结出的关键要点：
• 在生产环境中集成 LLM 时，必须采用“防御性编程”策略，始终假设模型可能会产生幻觉或返回无效格式，因此必须配合严格的验证层和回退机制。
• 传统的单元测试已不足以保证 LLM 应用的质量，开发者需要转向基于概率的评估方法，利用模型自身或专门的评估框架对输出进行非确定性测试。
• 为了获得可预测的结果，应优先采用“提示工程链”模式，将复杂的任务拆解为多个由确定性代码连接的、功能单一的小模型调用，而非依赖单一的大型提示词。
• 提示词应被视为受版本控制的代码资产，而非简单的字符串，通过系统化的管理和迭代来优化模型表现，是提升软件可靠性的关键。
• 必须建立完善的可观测性体系，深入监控模型的 Token 使用成本、延迟以及响应质量，以便在模型行为漂移或性能下降时迅速干预。
• 在处理用户输入时，需警惕“提示词注入”风险，实施严格的输入清洗和边界隔离，防止恶意用户通过精心设计的输入操纵系统行为。

常见问题

1: 在大语言模型（LLM）时代，为什么软件的可靠性变得更加难以保证？

1: 在大语言模型（LLM）时代，为什么软件的可靠性变得更加难以保证？

A: 传统软件的确定性逻辑被 LLM 的概率性本质所取代。LLM 具有非确定性（即相同的输入可能产生不同的输出）、存在“幻觉”（一本正经地胡说八道）、上下文窗口限制以及提示词脆弱性等问题。此外，LLM 的行为对外部环境（如系统提示词或检索到的上下文）高度敏感，这使得传统的单元测试和边界测试难以覆盖所有可能的情况，导致软件行为变得不可预测。

2: 什么是“语义版本控制”在 AI 应用中的挑战，我们应如何管理模型更新？

2: 什么是“语义版本控制”在 AI 应用中的挑战，我们应如何管理模型更新？

A: 传统的语义版本控制依赖于明确的 API 变更说明，但在 LLM 应用中，模型升级（例如从 GPT-3.5 到 GPT-4 或微调版本）往往伴随着隐性的行为变化。即使 API 接口不变，模型的输出风格、逻辑推理能力和安全性偏好也可能发生漂移。建议采取的策略包括：建立自动化的回归测试集（使用“黄金数据集”进行评估）、在模型调用层实现版本锁定与灰度发布机制，以及监控模型输出的分布变化，而不是仅仅依赖模型提供商的版本号。

3: 如何构建针对 LLM 应用的测试体系，以确保输出质量？

3: 如何构建针对 LLM 应用的测试体系，以确保输出质量？

A: 传统的断言测试已不足以应对 LLM 应用。构建可靠的测试体系需要结合以下几种方法：

1. 确定性评估：对于有标准答案的问题（如事实提取），使用传统的精确匹配或模糊匹配。
2. 基于 LLM 的评判：使用更强力的模型（如 GPT-4）来给小模型的输出打分，评估其相关性、准确性和语气。
3. “黄金数据集”：人工维护一组高质量的问答对，作为每次回归测试的基准。
4. 非功能性指标监控：实时监控延迟、Token 消耗和错误率，确保系统在性能和成本上的可靠性。

4: 在生产环境中，如何缓解 LLM 产生“幻觉”带来的风险？

4: 在生产环境中，如何缓解 LLM 产生“幻觉”带来的风险？

A: 缓解幻觉风险通常采用 RAG（检索增强生成）架构和严格的输出验证。

1. RAG 架构：限制模型仅基于检索到的可信文档生成答案，并要求模型在不知道答案时明确拒绝回答，而不是编造。
2. 引用溯源：强制模型在生成内容时标注引用来源，便于事后核查。
3. 守卫模型：在最终输出给用户之前，设置一个轻量级的验证步骤，检查输出是否包含有害、偏离主题或明显虚假的信息。

5: LLM 时代的“可观测性”与传统软件监控有何不同？

5: LLM 时代的“可观测性”与传统软件监控有何不同？

A: 传统监控主要关注系统可用性（如 HTTP 500 错误率、响应时间）。而在 LLM 时代，可观测性需要深入到数据的“语义”层面。除了常规的延迟和 Token 成本外，开发者还需要关注：用户查询与检索内容的语义相关性、模型输出的情感倾向、以及模型推理的轨迹。这通常需要将日志和追踪数据与向量数据库关联，以便在出现问题时，能够复现并理解模型为什么会产生特定的输出。

6: 随着模型能力的快速迭代，开发者应如何应对“框架疲劳”和依赖锁死的问题？

6: 随着模型能力的快速迭代，开发者应如何应对“框架疲劳”和依赖锁死的问题？

A: LLM 领域的框架（如 LangChain, LlamaIndex 等）更新极快，且模型 API 也在不断变化。为了保持软件的长期可靠性，建议采用**“防御性编程”**策略：在代码中引入抽象层，将核心业务逻辑与特定的模型提供商或框架解耦。避免直接在业务代码中硬编码提示词或特定的 API 调用，而是通过配置文件或中间件来管理。这样，当底层模型或框架不再维护时，迁移成本将降至最低。

7: 企业在落地 LLM 应用时，应如何平衡数据隐私与利用云端强大模型的需求？

7: 企业在落地 LLM 应用时，应如何平衡数据隐私与利用云端强大模型的需求？

A: 这是一个关键的可靠性与合规性权衡问题。常见的解决方案包括：

1. 数据脱敏与清洗：在发送数据给云端模型之前，利用规则或小模型自动移除个人身份信息（PII）。
2. 私有化部署或混合部署：对于极度敏感的数据，使用开源模型（如 Llama 3）在本地或私有云运行；对于非敏感任务，调用云端 API 以获得更好的性能。
3. 零留存策略：与企业级 LLM 提供商签订协议，确保 API 调用数据不被用于模型训练，且在一定时间后彻底删除。

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**:

在传统的软件工程中，单元测试通常使用固定的输入和输出来验证逻辑。但在使用 LLM（如 GPT-4）作为核心组件的应用中，相同的输入往往会产生不同的输出。请设计一种测试策略，既能验证 LLM 的功能是否符合预期，又能处理其非确定性（Non-deterministic）的特性。

提示**:

引用

• 原文链接: https://quint-lang.org/posts/llm_era
• HN 讨论: https://news.ycombinator.com/item?id=47347901

注：文中事实性信息以以上引用为准；观点与推断为 AI Stack 的分析。

站内链接

• 分类： AI 工程 / 后端
• 标签： LLM / 软件工程 / 可靠性 / 系统设计 / AI应用 / 最佳实践 / 架构设计 / 非确定性
• 场景： 大语言模型 / AI/ML项目

相关文章

• 从 Prompt 到 Agent Skill：AI 交互模式的架构设计与实现
• LLM时代的软件可靠性工程实践
• 编码代理的成功对通用AI系统的启示
• 我的AI应用实践与经验总结
• Agentic 软件工程：智能体驱动的开发范式 本文由 AI Stack 自动生成，包含深度分析与可证伪的判断。