智能软件工程导论（二）大模型推理优化与可解释性 + 软件需求设计与架构设计
目录
LLM推理优化
1. Chain of Thought（思维链，CoT）
引导模型将复杂问题分解为一系列连续的中间推理步骤。
a) 零样本CoT：
在问题末尾直接附加一个触发指令，如“让我们一步步地思考”。
b) 少样本CoT：
先给模型提供几个已解答的示例，这些示例都明确展示了推理步骤。
# 定义少样本示例
few_shot_examples = """
Q: 小明有5个苹果，他又买了3袋苹果，每袋有4个。他现在有多少个苹果？
A: 首先，计算新买的苹果数量：3袋 * 4个/袋 = 12个苹果。
然后，加上原有的苹果：5个 + 12个 = 17个苹果。
所以，答案是17。
Q: 一本书有80页。第一天读了1/4，第二天读了剩余部分的一半。还剩多少页没读？
"""2. Tree of Thoughts（思维树，ToT）
多路径的：通过“生成多个想法 -> 评估 -> 选择”来探索不同的可能性。
有三大核心组件：
-
思维生成器：在给定问题状态下，生成多个后续推理步骤
-
状态评估器：评估每个推理状态的进展质量
-
搜索算法：管理推理树的搜索策略
3. ReAct（推理+行动）
Reasoning + Action。让LLM在一个循环中交替进行“思考”和“行动”。
因为模型本身的知识只有之前训练好的参数，在发现未知的时候，调用外部工具。
ReAct的典型工作流程（循环）
对于一个任务（如“谁是2023年诺贝尔文学奖得主？”），ReAct循环如下：
思考：模型会想：“我的内部知识截止于2023年初，可能不准确。我需要查找2023年诺贝尔奖的最新信息。我应该使用搜索工具。”
行动：模型执行动作：Search("2023 Nobel Prize in Literature winner")
观察：外部工具（如Google Search API）返回结果：“2023年诺贝尔文学奖得主是约恩·福斯”。
思考：模型消化这个信息：“根据搜索结果，得主是约恩·福斯。问题已回答，不需要进一步行动。”
最终答案：模型基于观察到的信息生成最终答案：“2023年诺贝尔文学奖得主是挪威作家约恩·福斯。”4. Reflection 迭代改进
让LLM对自己的初始回答进行批判性检查，识别错误或不足，然后生成改进后的答案。
初始答案 → 反思批评 → 改进答案 → 再次反思 → 进一步改进...5. LATS：将搜索树与ReAct结合
将Tree of Thoughts的搜索策略应用到了ReAct框架中。
-
规划器：负责在给定状态下生成多个候选动作（
Thought+Action对）。 -
工具执行器：负责执行
Action并返回Observation。 -
评估器：负责评估一个状态的“价值”或“成功可能性”（打分）。
-
搜索算法：如蒙特卡洛树搜索或光束搜索，负责管理整个树结构，决定扩展哪个节点、模拟哪条路径。
6. Agent 相对大模型的个性化
| 个性化维度 | 大模型 | AI Agent |
|---|---|---|
| 记忆连续性 | ❌ 有限上下文 | ✅ 长期记忆 |
| 目标一致性 | ❌ 会话级目标 | ✅ 长期个性化目标 |
| 能力专门化 | ❌ 通用能力 | ✅ 定制化工具集 |
| 行为稳定性 | ❌ 每次可能不同 | ✅ 稳定的人格特质 |
| 学习适应性 | ❌ 不会记住偏好 | ✅ 从交互中持续学习 |
| 上下文感知 | ❌ 当前会话 | ✅ 完整历史背景 |
Requirement and Design 需求和设计
什么时候使用 AI？
内在困难问题（如写不出来规约）；
大规模问题（如音乐推荐）；
变化很快的问题（难维护）
什么时候不用AI？
明确的规约；
简单的启发式规则已经非常好；
机器学习构造成本超出收益；
出错的代价太高
比如我想去北京开会，如何构建酒店推荐器？
用户需求：地铁沿线附近；连锁；价格区间；距离会场比较近……
目标：点击率、交易率
老人摔跤检测系统的需求：
摔倒行为检测、自动警报与通知、人工求助功能、误报消除与确认、数据记录与健康管理。
功能需求&非功能需求
功能需求描述了软件应该提供的具体功能或服务。（能力 会做什么）
主要类型：
-
业务功能：满足用户核心目标的功能，如“用户应该能够将商品加入购物车”。
-
管理功能：支持系统运行的功能，如“管理员应该能够禁用违规用户账户”。
-
系统功能：软件与硬件或其他系统交互的功能，如“系统应该在每天凌晨2点自动备份数据库”。
非功能需求描述了系统运行的约束和质量属性。（质量 效果要求）
-
核心问题：系统在何种约束条件下运行？其质量如何？
-
特点：通常是全局性的、衡量系统质量的、面向约束的。
-
描述方式：必须是可衡量的，不能是模糊的形容词。
-
性能：系统对用户操作的响应速度。
-
”在95%的情况下，网页在用户点击后2秒内完全加载。在峰值负载下（同时10000用户在线），关键API的响应时间不应超过500毫秒。“
-
-
可用性/易用性：用户学习和使用系统的容易程度。
-
”一个新用户应该能在10分钟内完成注册并成功下单第一个商品。系统应通过用户测试，达到85分以上的SUS（系统可用性量表）分数。“
-
-
可靠性：系统在指定条件下无故障运行的能力。
-
”系统应保证99.9%的可用性（即每月宕机时间不超过43.2分钟）。数据丢失率应低于0.001%。“
-
-
安全性：保护系统和数据免受未授权访问和攻击的能力。
-
”用户密码在数据库中必须进行哈希加密。系统应能抵御常见的SQL注入和跨站脚本（XSS）攻击。所有敏感数据传输必须使用TLS 1.2或以上协议加密。“
-
-
可扩展性：系统处理负载增长的能力。
-
”系统架构应支持水平扩展，以便在用户量增加50%时，通过增加服务器实例即可维持性能，而无需重构代码。“
-
-
可维护性：修改和修复软件的容易程度。
-
”代码应具有良好的注释和文档。新增一个简单的功能模块（如新的支付方式）不应超过5人/天的工作量。“
-
Architecture and Design 架构和设计
例：眼镜实时翻译系统
三个核心部分：
-
前端捕获（眼镜端）：视频、音频、环境信息采集
-
AI处理管道（边缘/云端）：实时处理和理解内容
-
后端呈现（眼镜端）：翻译结果的显示和播报
关键性能指标目标
-
端到端延迟：语音翻译<300ms，文本翻译<500ms
-
电池续航：连续使用≥3小时，待机≥8小时
-
翻译准确率：常用场景>95%，专业场景>85%
-
文字识别率：清晰场景>98%，复杂场景>90%
用户场景感知 → 输入模式选择（文本/语音） → 领域识别（餐饮/医疗/通用）
先过边缘处理层（语音活动检测、基础文字检测、音频预处理）
简单任务 / 环境网络不佳：边缘直接处理（快）
复杂任务 / 环境网络延迟低：发送到云端（调用模型 更准确）
云端处理层（高质量TTS生成）
├── 高精度文字检测 + 版面分析├── 上下文感知翻译引擎 ├── 领域自适应模块
结果融合与呈现
├─ 文本AR叠加（保持空间位置）├─ 语音播放（可调节延迟）└─ 交互反馈（翻译置信度显示）
Constraints（约束）系统必须遵守的硬性限制或边界条件。 Trade-offs（权衡）多目标决策。
Explainability 可解释性：
1. surrogate model 代理模型：
用一个简单、好懂、可解释的“学生”模型，去模仿一个复杂、难懂的“老师”模型的行为。
2. 特征重要性
通过“捣乱”某个特征，看模型表现变差多少，来评估这个特征有多重要。
3. 部分依赖图
保持其他所有因素不变，观察单个特征的变化如何影响模型的最终预测结果。（边际效应）
4. LIME
多次选取局部扰动 再输入模型，那些扰动后预测分数急剧下降的位置说明 对预测很重要。
5. SHAP
博弈论的Shapley 值：参与者的贡献应由他在所有可能的联盟中的边际贡献（指当一个参与者加入或离开一个联盟时，对整个联盟的价值变化）衡量
考虑所有可能的特征联盟。也就是，我们轮流“屏蔽”一些特征，观察模型的预测会如何变化。
最终，一个特征的 Shapley 值，就是它在所有可能的加入顺序中，所带来的边际贡献的加权平均。
可以：清晰地展示了一个具体样本的预测是如何由各个特征“叠加”而成的。
prototype 代表点（典型的） criticism 离群点（不太典型的）
大模型可解释性
1. Chain/Tree/Graph of Thought 思维链/树/图 展示推理的每一步分支过程。
2. Logically-Constrained Reasoning - 逻辑约束推理
将形式化逻辑引入模型的推理过程。
模型必须在其生成的内容上遵守预设的逻辑规则。
逻辑约束可以强制模型保持一致性，避免生成自相矛盾的内容，从而提高推理的严谨性和可信度。
3. Symbolically-Aided Reasoning - 符号辅助推理
神经模型、大模型负责推理、理解和规划；
符号系统（如计算器、数据库查询器、定理证明器）负责精确准确执行
更多推荐
16
0- 0
已为社区贡献10条内容
所有评论(0)