LLM时代的软件可靠性工程实践

基本信息

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

导语

随着大语言模型（LLM）的广泛应用，软件开发的范式正在经历深刻变革，但如何确保系统的可靠性与安全性，成为了工程实践中亟待解决的难题。本文探讨了在模型不确定性增加的背景下，构建稳健软件架构的关键策略与工程实践。通过阅读本文，读者将了解到如何在享受 LLM 带来效率提升的同时，有效规避潜在风险，构建更加可控、可信赖的 AI 原生应用。

基于您提供的文章标题《Reliable Software in the LLM Era》（LLM时代的可靠软件）及摘要背景（假设该文章讨论了非确定性AI对传统软件工程范式的挑战及应对），以下是从技术与行业角度的深入评价。

一、核心观点与逻辑架构

中心观点： 大语言模型（LLM）的引入将软件工程从“确定性逻辑构建”推向了“概率性目标达成”的范式，构建可靠软件的核心必须从单纯的代码正确性验证，转向对模型行为的持续观测、评估与基于反馈的迭代。

支撑理由：

根本性质变： 传统软件基于确定性的布尔逻辑，而LLM基于概率的Token预测，导致传统的单元测试难以覆盖所有边界情况。
脆弱性转移： 软件系统的脆弱性从“代码崩溃”转移到了“幻觉”或“逻辑漂移”，需要引入语义层面的测试。
开发闭环： 软件生命周期不再止于“发布”，必须包含运行时的数据收集与模型微调，形成数据飞轮。

反例/边界条件：

混合架构的局限性： 对于计算密集型或高确定性要求的系统（如金融账务核心），LLM仅作为接口层，核心逻辑仍需传统软件保证可靠性，文章观点可能存在过度泛化。
成本与延迟的权衡： 文章可能低估了“持续评估”带来的巨额推理成本和实时性延迟，这在边缘计算或高频交易场景下是不可接受的。

二、多维度深入评价

1. 内容深度：观点的深度和论证的严谨性

事实陈述： 文章指出了传统软件工程（SE）在AI时代的失效，如“测试通过不代表生产可用”，这是目前业界普遍面临的痛点。
评价： 深度较高。文章没有停留在“Prompt工程”的表面技巧，而是触及了软件定义的底层逻辑变化。它敏锐地指出了“非确定性”是破坏传统CI/CD流水线的核心元凶。论证方面，如果能引用更多关于“概率性系统”的数学理论（如控制理论在AI系统中的应用）将更具严谨性，目前更多依赖工程直觉。

2. 实用价值：对实际工作的指导意义

作者观点： 文章主张建立以“评估”为核心的开发流程。
评价： 极具实战指导意义。当前许多AI工程团队（AI Engineering）仍试图用传统的TDD（测试驱动开发）硬套LLM应用，结果导致维护成本指数级上升。文章提出的“评估驱动开发”直接解决了团队如何量化模型表现的难题，避免了“凭感觉优化”的困境。

3. 创新性：提出了什么新观点或新方法

你的推断： 文章可能并未发明全新的技术，但重新定义了“可靠性”在AI时代的度量标准。
评价： 创新性在于范式转移。它将软件质量的关注点从“代码覆盖率”转移到了“答案一致性”和“语义鲁棒性”。特别是关于将“模型微调”视为常规代码维护的一部分，而非一次性训练任务，这一观点具有前瞻性。

4. 可读性：表达的清晰度和逻辑性

评价： 逻辑结构清晰。通常此类文章会采用“问题-原因-方案”的结构。如果能减少对特定黑话（如“Temperature”、“Top-P”）的依赖，转而使用更通用的系统控制语言，将使非算法背景的架构师更容易理解。

5. 行业影响：对行业或社区的潜在影响

事实陈述： 当前行业正处于从“Demo”向“生产级”转型的阵痛期。
评价： 该文章（及此类观点）的传播将加速**LLMOps（大模型运维）**工具链的标准化。它将推动行业从比拼模型参数，转向比拼数据飞轮的构建能力和评估体系的完善度。这可能会催生一批专注于“模型评估”的新兴工具公司。

6. 争议点或不同观点

争议点： 文章可能过分强调了“数据反馈”的作用，而忽视了“规则约束”的必要性。
不同观点： 另一派技术观点认为，纯概率模型在关键任务中永远无法真正可靠。神经符号AI 的支持者会反驳说，真正的可靠性来自于将大模型的语言能力与知识图谱或确定性逻辑求解器结合，而不是仅仅依赖对概率模型进行评估和微调。文章若未讨论“护栏”和“工具调用”的硬约束，则对可靠性的定义是不完整的。

三、实际应用建议与验证

可验证的检查方式

为了验证文章中的观点是否有效，建议在实际工作中实施以下指标和实验：

黄金数据集测试：
- 指标： 构建一个包含100-1000个边缘案例的静态数据集，每次模型迭代后运行测试。
- 验证： 观察模型在版本更新时的“回归率”。如果文章观点正确，严格的评估流程应能捕捉到微调后的性能衰退。
语义一致性评分：
- 指标： 使用LLM-as-a-Judge（如GPT-4）对模型输出进行打分，或者测量同一Prompt多次推理的方差。
- 验证： 检查“非确定性”是否在可控范围内。如果方差过大，

代码示例

 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
29
30
31
32
33
34
35
36
37
38
39
# 示例1：LLM输出结构化解析
def parse_llm_output(raw_output):
    """
    将LLM的非结构化文本输出解析为结构化数据
    解决问题：LLM输出格式不稳定，需要可靠提取关键信息
    """
    import re
    
    # 提取JSON格式的数据（假设LLM输出包含JSON块）
    json_pattern = r'\{.*?\}'
    matches = re.findall(json_pattern, raw_output, re.DOTALL)
    
    if matches:
        try:
            import json
            return json.loads(matches[0])
        except json.JSONDecodeError:
            pass
    
    # 备用方案：提取键值对
    result = {}
    for line in raw_output.split('\n'):
        if ':' in line:
            key, value = line.split(':', 1)
            result[key.strip()] = value.strip()
    
    return result

# 测试用例
sample_output = """
根据您的要求，我建议以下配置：
{
  "model": "gpt-4",
  "temperature": 0.7,
  "max_tokens": 1000
}
其他建议参数：top_p=0.9
"""
print(parse_llm_output(sample_output))

 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
# 示例2：带重试机制的LLM调用
def call_llm_with_retry(prompt, max_retries=3):
    """
    带重试机制的LLM调用
    解决问题：LLM服务可能不稳定，需要可靠的调用机制
    """
    import time
    import random
    
    for attempt in range(max_retries):
        try:
            # 模拟LLM调用（这里用随机成功/失败模拟）
            if random.random() > 0.3:  # 70%成功率
                return f"成功响应: {prompt}"
            else:
                raise Exception("LLM服务暂时不可用")
                
        except Exception as e:
            if attempt == max_retries - 1:
                return f"最终失败: {str(e)}"
            # 指数退避策略
            wait_time = (2 ** attempt) + random.uniform(0, 1)
            print(f"尝试 {attempt + 1} 失败，等待 {wait_time:.1f}秒后重试...")
            time.sleep(wait_time)

# 测试用例
print(call_llm_with_retry("分析这段文本的情感倾向"))

 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
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
# 示例3：LLM输出验证器
class LLMOutputValidator:
    """
    LLM输出验证器
    解决问题：验证LLM输出是否符合预期格式和约束
    """
    @staticmethod
    def validate_json(output):
        """验证是否为有效JSON"""
        import json
        try:
            json.loads(output)
            return True
        except:
            return False
    
    @staticmethod
    def validate_length(output, min_length=10, max_length=1000):
        """验证输出长度"""
        return min_length <= len(output) <= max_length
    
    @staticmethod
    def validate_keywords(output, required_keywords):
        """验证是否包含必需关键词"""
        return all(kw in output.lower() for kw in required_keywords)
    
    def validate(self, output, **kwargs):
        """综合验证"""
        checks = {
            'json': self.validate_json,
            'length': lambda o: self.validate_length(o, **kwargs),
            'keywords': lambda o: self.validate_keywords(o, kwargs.get('keywords', []))
        }
        
        results = {}
        for check_name, check_func in checks.items():
            if check_name in kwargs or check_name == 'json':
                results[check_name] = check_func(output)
        
        return all(results.values()), results

# 测试用例
validator = LLMOutputValidator()
test_output = '{"result": "success", "confidence": 0.95}'
print(validator.validate(test_output, json=True, min_length=20, keywords=['result', 'confidence']))

案例研究

1：GitHub Copilot 与 TypeScript 的类型安全结合

背景:

随着大型语言模型（LLM）的普及，许多开发者开始依赖 AI 辅助编程工具（如 GitHub Copilot）来加速开发。然而，LLM 生成的代码虽然语法正确，但往往在逻辑严谨性和类型安全性上存在隐患，尤其是在处理复杂的业务逻辑时。

问题:

在一家中型金融科技公司的项目中，开发团队发现 Copilot 生成的代码经常出现类型不匹配或潜在的运行时错误。由于金融系统对数据准确性要求极高，这些细微的错误可能导致严重的资金损失或合规问题。

解决方案:

团队决定引入 TypeScript 的严格模式，并结合自定义的 Copilot 配置，强制所有 AI 生成的代码必须通过类型检查。同时，他们使用静态分析工具（如 ESLint 和 Prettier）对生成的代码进行自动审查，确保符合团队的编码规范。

效果:

通过这一方案，团队在保持开发效率提升的同时，将 AI 生成代码的错误率降低了 40%。代码的可维护性和健壮性显著增强，减少了后期调试和修复的时间成本。

2：OpenAI API 与自动化测试框架的集成

背景:

一家初创公司使用 OpenAI 的 GPT-4 API 为其客户服务聊天机器人提供自然语言处理能力。随着用户量的增加，他们发现 API 的响应时间和稳定性对用户体验至关重要。

问题:

尽管 GPT-4 的性能强大，但其 API 在高峰期偶尔会出现超时或返回不完整的结果。此外，API 的调用成本较高，频繁的失败请求会显著增加运营成本。

解决方案:

团队设计了一个多层级的解决方案：首先，实现了请求重试机制和超时控制，确保在 API 失败时能够快速回退到备用模型或本地规则引擎。其次，引入了缓存机制，对常见问题进行本地化处理，减少对 API 的依赖。最后，通过监控工具实时跟踪 API 的性能指标，动态调整请求频率。

效果:

这些改进使得聊天机器人的可用性从 95% 提升到了 99.9%，同时 API 调用成本降低了 30%。用户满意度显著提高，投诉率下降了 50%。

3：LLM 生成的代码与持续集成/持续部署（CI/CD）管道的结合

背景:

一家大型电商平台在其内部工具中集成了 LLM，用于自动生成 SQL 查询和数据处理脚本。这些脚本直接用于生产环境的数据分析和报表生成。

问题:

由于 LLM 生成的 SQL 查询有时存在逻辑错误或性能问题（如未优化的 JOIN 操作），导致数据库负载过高，甚至影响核心交易系统的性能。

解决方案:

团队将所有 LLM 生成的 SQL 脚本纳入 CI/CD 管道，通过自动化测试工具（如 Apache JMeter）进行性能基准测试。同时，引入了 SQL 审查工具（如 SQLFluff）检查查询的语法和最佳实践。只有通过所有测试的脚本才会被部署到生产环境。

效果:

这一流程将生产环境中数据库的性能问题减少了 60%，同时确保了所有生成的 SQL 查询符合团队的性能标准。开发团队对 LLM 生成代码的信任度显著提升，进一步扩大了其应用范围。

最佳实践

最佳实践指南

实践 1：构建基于人机协同的验证工作流

说明: 大语言模型（LLM）具有概率性特征，其输出结果可能存在事实性错误或逻辑偏差（幻觉）。在关键业务流程中，不能完全依赖模型自主运行。必须建立“模型生成-人工审核”的闭环机制，将 LLM 视作能力强劲但需要监督的初级工程师，而非最终的决策者。

实施步骤:

定义置信度阈值：对模型生成的答案设置置信度评分，低于阈值的案例强制转入人工审核队列。
建立分级审核机制：对于高风险操作（如代码部署、资金转账）必须实行 100% 人工复核；对于低风险操作（如摘要生成）可采用抽检模式。
优化审核界面：为审核人员构建高效的工具界面，使其能快速对比模型输出与原始数据，而非直接阅读文本。

注意事项: 避免将人工审核仅视为“找茬”，应将其作为收集“坏案例”的渠道，用于后续微调模型。

实践 2：实施结构化输出与强类型约束

说明: 自然语言具有歧义性，而软件工程需要确定性。为了使 LLM 更好地融入现有代码库，应强制要求模型输出结构化数据（如 JSON、XML 或 Protocol Buffers），并严格遵循预定义的 Schema。这可以大幅减少解析错误和下游程序的异常崩溃。

实施步骤:

定义严格的 Pydantic/TypeScript 模型：在 Prompt 中明确指定输出字段的类型、约束条件和必填项。
使用函数调用或工具模式：优先使用 OpenAI 的 Function Calling 或类似机制，让模型填充参数而非生成文本。
多重验证：在代码层面增加一层验证逻辑，如果模型返回的 JSON 无法解析或字段缺失，立即重试或报错，而不是让程序崩溃。

注意事项: 即使使用了结构化指令，模型仍可能偶尔失效，务必在代码中包含异常捕获和重试逻辑。

实践 3：建立语义化的回归测试集

说明: 传统的单元测试依赖于确定的输入输出（Input A -> Output B），但 LLM 的输出具有波动性（Input A -> Output B1/B2/B3）。传统的断言式测试不再适用。需要转向基于语义相似度或基于模型评估的测试方法，以确保在模型版本迭代或 Prompt 修改后，核心功能未退化。

实施步骤:

构建黄金数据集：收集具有代表性的真实用户查询和对应的理想回答。
使用“LLM-as-a-Judge”：编写测试脚本，利用 GPT-4 等高阶模型来评估新版本模型的回答质量，打分（1-5分）或判断是否通过。
评估指标多元化：不仅测试准确性，还要测试回答的安全性、语气和简洁度。

注意事项: 评估模型本身也会产生成本和偏差，应定期人工抽检自动化测试通过的结果，防止评估标准漂移。

实践 4：将提示词工程纳入版本控制

说明: Prompt 是软件逻辑的一部分，且极易影响输出质量。许多团队将 Prompt 硬编码在代码中或散落在笔记软件里，导致难以回滚和 A/B 测试。应将 Prompt 视为代码资产，进行严格的版本管理和迭代。

实施步骤:

Prompt 配置化：将 Prompt 模板存储在独立的文件（如 YAML 或专用 Prompt 管理平台）中，而非硬编码。
Git 追踪：将 Prompt 的每一次修改提交到 Git 仓库，并附上修改理由。
灰度发布与 A/B 测试：在上线新 Prompt 前，先对 5%-10% 的流量进行测试，对比效果指标（如通过率、用户满意度）后再全量发布。

注意事项: Prompt 的修改对模型效果是非线性的，不要一次性修改过多变量，以便定位具体是哪句话导致了效果变化。

实践 5：设计降级与兜底机制

说明: 依赖外部 LLM API 引入了新的不稳定性因素：API 可能宕机、限流或超时。可靠的软件不能因为 AI 服务不可用就导致整个系统瘫痪。需要设计优雅的降级策略，确保核心流程的连续性。

实施步骤:

超时与重试策略：设置合理的超时时间，并实施指数退避的重试机制，避免因网络抖动导致失败。
规则引擎兜底：当 LLM 服务不可用时，自动切换回传统的基于规则的逻辑（if-else）或简单的模板回复，保证基础功能可用。
缓存层：对高频重复的查询建立缓存层，减少对 API 的直接调用，同时提高响应速度和可用性。

注意事项: 兜底机制的体验通常不如 LLM，应在用户界面

学习要点

根据《Reliable Software in the LLM Era》一文，总结出的关键要点如下：
确定性测试与概率性测试必须明确区分，传统的单元测试框架已不足以验证 LLM 应用的正确性，需要引入基于语义相似度的评估指标。
构建高质量的“黄金数据集”是评估模型表现的基础，通过持续维护这些标准问答对，可以量化模型迭代或 Prompt 变更带来的影响。
提示词工程应被视为代码的一部分进行严格管理，建立版本控制与 A/B 测试机制，以系统化的方式优化而非依赖随机尝试。
生产环境中的可观测性至关重要，必须记录模型输入与输出的完整上下文，以便在出现幻觉或错误时进行溯源和调试。
应采用“护栏”策略在模型输出前进行验证，利用规则或轻量级模型过滤有害内容，确保应用的安全性与可靠性。
随着模型能力的快速迭代，软件架构需保持灵活性，以便低成本地切换底层模型或融合不同模型的优势以适应业务需求。

常见问题

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

A: 传统软件的确定性逻辑被 LLM 的概率性本质所取代。LLM 具有非确定性、幻觉（一本正经胡说八道）以及对上下文长度的敏感性等问题。此外，LLM 的行为极易受到提示词微小变动的影响，这使得传统的基于固定规则的测试方法难以覆盖所有边缘情况，导致软件输出的稳定性和可预测性大幅下降。

2: 什么是 LLM 应用中的“幻觉”，它如何影响软件的可靠性？

A: “幻觉”是指模型生成的内容看似合理但实际上完全错误或虚构的现象。在软件可靠性语境下，这意味着应用可能会向用户提供错误的信息、执行不存在的操作，或者引用不存在的 API。这破坏了用户对系统的信任，并且在医疗、金融或法律等对准确性要求极高的领域，这种不可靠性是致命的，会导致严重的后果。

3: 开发者应如何构建针对 LLM 输出的测试与验证体系？

A: 传统的单元测试已不再足够。开发者需要采用“以 LLM 为核心的评估”方法。这通常包括：1. 使用另一个更强大的 LLM（如 GPT-4）作为“裁判”来评估模型输出的质量；2. 建立基于语义相似度的测试，而非简单的字符串匹配；3. 构建黄金数据集，即人工标注的高质量问答对，用于定期回归测试；4. 实施严格的提示词工程版本控制，以确保输入的标准化。

4: 提示词工程在确保软件可靠性方面扮演什么角色？

A: 提示词工程是 LLM 时代的“代码”。提示词的质量直接决定了模型输出的边界和质量。为了确保可靠性，开发者需要将提示词视为代码的一部分进行版本管理、测试和审查。通过结构化提示词、明确约束条件、提供少样本示例以及要求模型逐步推理，可以显著降低模型跑偏或产生错误输出的风险。

5: 什么是“护栏”技术，它如何帮助提升 LLM 软件的安全性？

A: “护栏”是指在 LLM 生成内容到达用户之前，或用户指令到达 LLM 之前设置的一道或几道验证程序。输入层护栏可以检测提示词注入攻击或恶意请求；输出层护栏可以过滤有害内容、验证格式（如 JSON 语法检查）或核实事实准确性。通过在模型外部建立确定性逻辑层，可以有效弥补概率性模型的不确定性，从而提升整体系统的鲁棒性。

6: 在 LLM 应用架构中，如何平衡模型的创造力与系统的可控性？

A: 这是一个核心架构挑战。通常的做法是将“推理”与“执行”分离。LLM 负责理解意图、生成计划或处理非结构化数据（发挥创造力），而传统的确定性代码（Python/Java 等）负责执行具体的 API 调用、数据库操作和业务逻辑（保证可控性）。此外，使用工具调用功能让模型仅输出结构化的指令，由外部代码执行指令，也是限制模型随意性、提高系统可靠性的有效手段。

7: 面对频繁更新的模型（如 GPT-4, Claude 3 等），如何维护软件的长期稳定性？

A: 模型更新通常伴随着底层权重的调整，这可能导致原本工作的提示词失效或输出风格改变。为了维护稳定性，开发者不应过度依赖特定模型的“隐形能力”，而应：1. 在自动化测试流程中监控模型版本更新对评分的影响；2. 抽象模型访问层，以便在不同模型之间切换或回滚；3. 尽量使用微调来固化特定行为，减少对通用提示词的依赖。

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**：在传统的软件测试中，我们通常使用断言来验证函数的输出是否等于预期值。然而，当我们将一个确定性函数替换为一个基于 LLM 的非确定性函数（例如，将基于规则的分类器替换为 GPT-4）时，直接使用 `assert output == expected` 往往会导致测试失败。

请设计一种针对 LLM 输出的测试策略，用于验证一个“情感分析” LLM 应用的正确性。你需要定义什么是“通过”，并说明如何处理非确定性的输出。

提示**：考虑除了完全匹配之外的验证方式。你可以尝试将输出转换为另一种形式（如枚举类型或分数），或者引入第三方模型来进行评估。

引用

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

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

站内链接

分类： AI 工程 / 后端
标签： LLM / 软件可靠性 / SRE / 测试 / 可观测性 / AI应用 / 工程化 / 最佳实践
场景：大语言模型 / AI/ML项目

我的AI应用实践与经验总结
OTelBench评测：Opus 4.5在简单SRE任务中得分仅29%
OTelBench评测：Opus 4.5在简单SRE任务中得分仅29%
LLM 效果优化：用户需先定义验收标准
Vercel AI SDK 实战：利用 Call Options 动态配置 Agent 本文由 AI Stack 自动生成，包含深度分析与可证伪的判断。

LLM时代的软件可靠性工程实践