AI工程架构与用户反馈

1. 是什么

AI工程架构（AI Engineering Architecture）
- 是什么
  - 将基础模型与上下文构建、安全防护、路由、缓存、Agent和可观测性等能力组合起来，形成完整的AI应用系统
- 核心思想
  - 渐进式架构演进
    - 从最简单的Model API调用开始
    - 根据实际问题逐步增加组件
    - 避免过早引入不必要的复杂性
用户反馈（User Feedback）
- 是什么
  - 收集用户对AI应用的评价、行为和交互信息，用于评估应用表现和指导系统优化
- 主要用途
  - 应用评估
    - 判断系统是否满足用户需求
  - 产品优化
    - 发现实际问题和改进方向
  - 个性化
    - 根据用户偏好调整应用表现
  - 模型优化
    - 为后续模型训练提供数据
核心思想
- 渐进式架构演进 + 反馈驱动开发
- 构建应用 → 评估与监控 → 收集反馈 → 分析问题 → 优化系统 → 重新评估

2. 为什么需要

简单的模型调用无法满足复杂的生产需求
- 缺少外部知识
  - 需要RAG和Context Construction
- 存在错误或危险输出
  - 需要Guardrails
- 不同任务需要不同模型
  - 需要Router
- 多个模型API难以统一管理
  - 需要Model Gateway
- 重复请求导致高延迟和成本
  - 需要Cache
- 复杂任务需要动态决策和执行
  - 需要Agent
- 多组件执行流程难以管理
  - 需要Orchestrator
- 系统故障难以定位
  - 需要Observability
AI系统具有额外的不确定性
- 相同输入可能产生不同输出
- 输出可能不符合预期格式
- 可能出现幻觉
- 模型行为可能随版本变化
- 可能遭受提示词注入攻击
- 复杂Agent可能出现中间执行故障
离线评估不能完全代替真实用户反馈
- 测试数据无法覆盖全部真实场景
- 技术指标改善不一定代表用户满意度提升
- 用户可能有未被明确表达的需求
- 需要通过真实使用验证应用价值

3. 如何实现

整体流程
- 应用架构演进
  - 基础Model API
  - 增强Context
  - 增加Guardrails
  - 增加Router与Model Gateway
  - 增加Cache
  - 增加Agentic Patterns
  - 根据复杂度引入Orchestration
  - Observability贯穿整个过程
- 反馈闭环
  - 用户使用AI应用
  - 收集用户反馈与交互数据
  - 分析用户满意度和失败案例
  - 确定改进方案
  - 优化Prompt、Context、Model或系统组件
  - 执行评估
  - 验证改进效果
  - 发布并继续观察
- 注意
  - 架构演进不代表固定的开发顺序
  - 根据实际需求决定组件的引入顺序
  - 可观测性应从设计阶段就考虑
核心组成
- Model API
  - 是什么
    - 提供基础模型推理能力
  - 实现方式
    - 第三方商业模型API
    - 自托管模型服务
- Context Construction
  - 是什么
    - 为模型构建完成当前任务所需的上下文
  - 职责
    - 获取外部信息
    - 筛选和组织相关数据
    - 构建模型输入
- Guardrails
  - 是什么
    - 检测和控制输入输出风险
  - 职责
    - 输入安全检查
    - 输出质量与安全检查
    - 故障处理
- Router
  - 是什么
    - 根据任务选择处理路径或模型
- Model Gateway
  - 是什么
    - 统一访问和管理多个模型服务
- Cache
  - 是什么
    - 缓存可以复用的请求或执行结果
- Agent与Tools
  - 是什么
    - 支持动态决策、工具调用和环境交互
- Orchestrator
  - 是什么
    - 协调多个组件的执行流程和数据传递
- Observability
  - 是什么
    - 记录和分析系统运行状态，帮助发现和定位问题
  - 横切能力
    - 贯穿整个系统
    - 不一定是独立服务
- Feedback System
  - 是什么
    - 收集和分析用户反馈
  - 职责
    - 反馈采集
    - 反馈分析
    - 提供改进依据
- 注意
  - 以上是逻辑职责划分
  - 不要求每个组件独立部署
  - 多个职责可以由同一个组件实现
实现原理与技术方案
- 1. Context Construction（上下文构建）
  - 是什么
    - 为模型准备当前任务需要的相关信息
  - 实现方式
    - RAG
      - 从外部知识源检索信息
    - Tool Calling
      - 获取实时信息或执行操作
    - 文件上传
      - 向模型提供外部文档
    - 其他数据检索
      - 数据库
      - 表格
      - 图像
  - 与传统工程的关系
    - 类似Feature Engineering
      - 为模型准备有效输入
  - 详细原理
    - 复用第6章RAG与Agent知识
- 1. Guardrails（安全防护）
  - 是什么
    - 检测并处理模型输入与输出中的风险和故障
  - 分类
    - Input Guardrails（输入防护）
      - 解决什么问题
        
        敏感数据泄露
        
        恶意提示词
        
        提示词注入
      - 实现方法
        
        检测个人身份信息（PII）
        
        检测业务敏感信息
        
        拦截高风险输入
        
        敏感信息掩码
        
        必要时通过安全映射恢复原始信息
      - 执行过程
        
        输入检测
        
        识别敏感信息
        
        拦截或脱敏
        
        发送安全处理后的输入
    - Output Guardrails（输出防护）
      - 解决什么问题
        
        模型输出可能不符合质量或安全要求
      - 故障类型
        
        格式错误
        
        JSON不符合Schema
        
        事实错误
        
        生成不存在或不准确的信息
        
        质量问题
        
        回答不相关或质量差
        
        有害内容
        
        违反应用安全要求
        
        隐私泄露
        
        输出敏感信息
        
        危险动作
        
        触发未经授权的外部操作
      - 检测方式
        
        程序化规则
        
        专用检测模型
        
        AI评分器
      - 故障处理
        
        重试
        
        拒绝响应
        
        使用备用方案
        
        转交人工
  - 主要权衡
    - 安全性与延迟
    - 安全性与成本
    - 流式输出与完整内容检查
  - 注意
    - 安全防护无法完全消除风险
    - 需要关注误拒率
    - 重试会增加成本和延迟
    - 高风险动作还需要执行层权限控制
- 1. Router（路由器）
  - 是什么
    - 根据任务类型、上下文和执行要求选择处理路径
  - 实现方式
    - Intent Classification（意图分类）
      - 是什么
        
        识别用户意图并选择对应处理方案
      - 示例
        
        密码找回 → FAQ
        
        账单纠纷 → 人工客服
        
        技术问题 → 技术支持Agent
      - 其他用途
        
        识别超出服务范围的请求
        
        识别模糊请求
        
        按任务复杂度选择模型
    - Next-action Prediction（下一步动作预测）
      - 是什么
        
        根据当前状态预测下一步应该执行的操作
      - 示例
        
        选择调用哪个工具
        
        判断是否需要检索
        
        选择对应记忆存储
  - 实现技术
    - 规则路由
    - 分类模型
    - 小型语言模型
  - 优化目标
    - 减少不必要的高成本模型调用
    - 减少路由本身的延迟和成本
- 1. Model Gateway（模型网关）
  - 是什么
    - 为不同模型服务提供统一、安全、可管理的访问接口
  - 主要功能
    - 统一模型API
      - 适配不同模型提供商
    - 访问控制
      - 管理用户和应用的模型权限
    - 成本管理
      - 记录和限制API调用
    - Rate Limiting
      - 限制请求频率
    - Failover
      - 主模型不可用时切换备用模型
    - Load Balancing
      - 分配模型请求
    - Logging
      - 记录模型调用信息
    - 可选功能
      - 缓存
      - 安全防护
  - 与传统工程的关系
    - API Gateway
    - Adapter Pattern
  - Router与Gateway区别
    - Router
      - 决定使用哪个模型或处理方案
    - Gateway
      - 统一调用和管理模型服务
    - 两者可以合并实现
- 1. Cache（缓存）
  - 是什么
    - 复用已有计算结果，降低重复请求的成本和延迟
  - 分类
    - Exact Cache（精确缓存）
      - 是什么
        
        请求与缓存键匹配时直接复用结果
      - 实现方式
        
        使用缓存键查找结果
        
        Hit直接返回
        
        Miss执行模型调用并缓存
      - 存储方案
        
        内存
        
        Redis
        
        PostgreSQL
      - 淘汰策略
        
        LRU
        
        LFU
        
        FIFO
    - Semantic Cache（语义缓存）
      - 是什么
        
        允许语义相似的请求复用缓存结果
      - 实现原理
        
        Embedding
        
        将Query转换成向量
        
        Vector Search
        
        检索相似查询
        
        Similarity Threshold
        
        判断相似度是否超过阈值
      - 执行流程
        
        Query → Embedding → Vector Search → 相似度判断
        
        命中则返回缓存结果
        
        未命中则调用模型并更新缓存
  - 两种缓存的区别
    - Exact Cache
      - 实现简单
      - 命中范围较窄
      - 错误复用风险相对容易控制
    - Semantic Cache
      - 命中范围较广
      - 实现复杂
      - 可能错误匹配不同问题
      - 需要额外的向量检索成本
  - 缓存风险
    - 数据时效性
    - 用户私有信息泄露
    - 跨权限错误复用
    - 语义匹配错误
  - 注意
    - 先考虑Exact Cache
    - Semantic Cache需要验证实际收益
    - 缓存键和命中条件应考虑权限与业务上下文
- 1. Agentic Patterns（智能体模式）
  - 是什么
    - 支持动态决策、循环执行、条件分支和工具调用
  - 为什么需要
    - 固定的线性流程无法满足部分复杂任务
  - 实现方式
    - ReAct
      - 推理 → 行动 → 观察 → 继续推理
    - Tool Calling
      - 获取外部信息
      - 执行外部操作
    - 复杂执行模式
      - 循环
      - 条件分支
      - 并行执行
  - Write Actions（写入动作）
    - 是什么
      - 修改外部环境的操作
    - 示例
      - 发送邮件
      - 下订单
      - 更新数据库
    - 风险
      - 可能产生真实的外部副作用
      - 需要权限控制和必要的审批
  - 详细内容
    - 复用第6章Agent与Harness知识
- 1. Observability（可观测性）
  - 是什么
    - 通过系统埋点和运行数据分析，理解系统状态并定位故障
  - 为什么需要
    - 降低应用故障和安全风险
    - 发现性能与成本优化机会
    - 帮助定位复杂组件的失败原因
  - 核心技术
    - Metrics（指标）
      - 是什么
        
        通过数值衡量系统状态和表现
      - 指标分类
        
        模型质量
        
        任务正确率
        
        事实一致性
        
        格式错误率
        
        安全性
        
        有害内容比例
        
        拒绝率
        
        误拒率
        
        性能
        
        TTFT
        
        TPOT
        
        总响应时间
        
        成本
        
        Token消耗
        
        请求次数
        
        API成本
        
        缓存命中率
        
        组件性能
        
        检索延迟
        
        检索质量
        
        向量数据库查询耗时
        
        用户行为
        
        对话轮数
        
        重新生成率
        
        中途终止率
        
        业务指标
        
        DAU
        
        订阅量
        
        转化率
    - Logging（日志）
      - 是什么
        
        记录系统运行过程中发生的具体事件
      - 记录内容
        
        模型与调用配置
        
        Prompt及其版本
        
        Query与Response
        
        工具调用与执行结果
        
        错误信息
        
        组件执行时间
        
        请求关联ID
      - 作用
        
        复盘具体问题
        
        分析异常事件
    - Tracing（链路追踪）
      - 是什么
        
        关联请求执行过程中各组件的事件，重建完整执行路径
      - 记录内容
        
        组件调用顺序
        
        中间结果
        
        执行耗时
        
        Token消耗
        
        调用成本
        
        异常信息
      - 作用
        
        定位失败发生在哪个组件或步骤
    - Drift Detection（漂移检测）
      - 是什么
        
        检测系统输入、配置或模型行为随时间发生的变化
      - 常见类型
        
        Prompt Drift
        
        提示词模板发生变化
        
        User Behavior Drift
        
        用户查询习惯发生变化
        
        Model Drift
        
        底层模型行为发生变化
  - 传统DevOps指标
    - MTTD
      - 平均检测时间
      - 从问题发生到被发现的时间
    - MTTR
      - 本书指平均响应时间
      - 从检测问题到解决问题的时间
    - CFR
      - 变更失败率
      - 导致故障或需要修复、回滚的变更比例
  - 核心原则
    - 先确定故障模式
    - 再设计指标和告警
    - 按需结合抽样检查与全面检查
    - 将监控问题反馈到离线评估流水线
- 1. Orchestration（流水线编排）
  - 是什么
    - 协调多个模型、工具和数据源的执行与数据流转
  - 实现原理
    - Component Definition（组件定义）
      - 声明系统使用的模型
      - 声明数据源和工具
      - 声明评估与监控组件
    - Chaining（链式组合）
      - 定义组件执行顺序和数据依赖关系
  - 主要能力
    - 数据传递
    - 格式转换
    - 条件分支
    - 并行执行
    - 异常处理
  - 传统工程中的类似技术
    - Workflow Engine
    - Pipeline
  - 常见工具
    - LangChain
    - LlamaIndex
    - Haystack
    - Flowise
    - Langflow
  - 选型标准
    - 集成性与可扩展性
    - 复杂流水线支持
    - 易用性
    - 性能
    - 可伸缩性
  - 作者建议
    - 初期优先尝试不依赖复杂编排框架
    - 复杂度真正增加后再考虑引入
- 1. User Feedback（用户反馈）
  - 是什么
    - 通过用户评价和交互行为获取应用改进信号
  - 分类
    - Explicit Feedback（显式反馈）
      - 是什么
        
        用户主动提供明确评价
      - 示例
        
        点赞与点踩
        
        星级评分
        
        人工评价
        
        答案偏好比较
      - 特点
        
        容易解释
        
        需要用户额外操作
        
        反馈数量可能较少
    - Implicit Feedback（隐式反馈）
      - 是什么
        
        通过用户行为推断满意度和偏好
      - Natural Language Feedback（自然语言反馈）
        
        是什么
        
        从用户对话内容中提取反馈
        
        信号
        
        提前终止
        
        用户停止生成
        
        可能表示回答不符合预期
        
        错误修正
        
        用户指出错误
        
        可能表示模型理解或回答有误
        
        重新表述
        
        用户重新描述请求
        
        可能表示原始问题未得到解决
        
        要求核实
        
        用户要求重新检查或提供证据
        
        可能表示用户缺乏信任
        
        直接编辑
        
        用户修改AI生成内容
        
        可能形成偏好数据
        
        抱怨
        
        用户指出回答冗长、错误或质量差
        
        情绪变化
        
        用户表现出不满或满意
      - Other Interaction Feedback（其他交互反馈）
        
        重新生成
        
        可能表示不满意
        
        也可能只是想比较其他结果
        
        删除对话
        
        可能表示对话不满意
        
        也可能出于隐私考虑
        
        收藏与分享
        
        可能体现用户偏好
        
        对话长度
        
        不同业务中的含义不同
        
        对话多样性
        
        辅助识别无效重复对话
      - 特点
        
        数据来源丰富
        
        不需要用户专门评分
        
        噪声和歧义较多
  - Feedback Design（反馈设计）
    - 什么时候收集
      - 初始使用阶段
        
        了解用户偏好
        
        进行必要的系统校准
      - 出现问题时
        
        收集错误信息
        
        允许用户纠正
        
        必要时提供人工协助
      - 模型不确定时
        
        请求用户确认
        
        提供候选结果进行比较
      - 用户主动反馈时
        
        允许点赞、收藏、评论等
    - 如何收集
      - 将反馈融入正常工作流程
      - 降低反馈操作成本
      - 允许忽略反馈请求
      - 提供清晰的反馈选项
      - 说明反馈数据的用途
      - 控制反馈请求频率
      - 尊重用户隐私与授权
    - 典型案例
      - GitHub Copilot
        
        接受代码建议
        
        忽略代码建议
        
        修改建议内容
      - Midjourney
        
        选择图片放大
        
        生成图片变体
        
        重新生成图片
  - 反馈用途
    - 评估应用表现
    - 指导产品改进
    - 用户个性化
    - 构建偏好训练数据
    - 形成数据飞轮
执行流程详解
- 1. AI请求执行流程
  - 用户发送Query
  - Input Guardrails
    - 检查输入安全性
    - 必要时脱敏或拦截
  - Router
    - 识别任务类型
    - 选择处理路径
  - Cache Lookup
    - 检查是否存在可安全复用的结果
  - Context Construction（按需）
    - 检索外部信息
    - 筛选与组织上下文
  - Model Gateway
    - 调用目标模型
  - LLM Generation
    - 生成模型响应
  - Output Guardrails
    - 检查输出质量与安全性
    - 必要时重试或转交人工
  - 返回Response
  - 注意
    - 具体执行顺序依赖实际架构
    - 部分步骤可以省略或并行
    - Agent任务可能包含多轮工具调用
    - Observability贯穿全部步骤
- 1. 用户反馈闭环
  - 用户接收Response
  - 用户继续交互
  - Feedback Collection
    - 收集显式反馈
    - 提取隐式反馈
    - 收集必要的交互上下文
  - Feedback Analysis
    - 识别失败案例
    - 分析满意度
    - 分析偏好和反馈偏差
  - 确定改进方向
    - Prompt优化
    - Context优化
    - 模型优化
    - 系统组件优化
  - 执行离线评估
  - 验证改进效果
  - 发布并持续观察

4. 如何优化

优化系统质量
- 知识不足
  - RAG与Context Construction
- 模型选择不合理
  - Router
- 输出格式或质量问题
  - Output Guardrails
- 复杂任务执行失败
  - Agentic Patterns
- 复杂工作流难以维护
  - Orchestrator
优化延迟和成本
- 缓存优化
  - 优先使用Exact Cache
  - 按需引入Semantic Cache
- 模型路由
  - 简单任务使用低成本模型
  - 复杂任务使用能力更强的模型
- 并行执行
  - 并行处理相互独立的步骤
- 故障处理
  - 使用重试或备用模型
  - 权衡重试成本与延迟
优化可靠性
- 输入输出校验
- 模型故障回退
- 异常重试
- 人工介入
- 关键操作权限控制
优化可观测性
- 明确故障模式
- 围绕故障设计Metrics
- 记录Logs和Traces
- 设置告警
- 定位问题
- 将失败案例加入回归评估
优化用户反馈质量
- 主要偏差
  - Leniency Bias（宽容偏差）
    - 是什么
      - 用户倾向给出比真实体验更高的评分
    - 原因
      - 避免冲突
      - 负面评价需要额外操作
  - Randomness（随机性）
    - 是什么
      - 用户未认真比较就随机选择反馈
  - Position Bias（位置偏差）
    - 是什么
      - 选项展示位置影响用户选择
    - 缓解方式
      - 随机调整选项位置
      - 按位置进行统计校正
  - Preference Bias（偏好偏差）
    - 是什么
      - 某些容易感知的特征影响用户选择
    - 示例
      - 用户偏好较长回答
      - 但较长回答不一定更准确
  - Recency Bias（近因偏差）
    - 是什么
      - 用户可能偏好后看到的答案
- 优化原则
  - 减少不必要的反馈操作
  - 使用多种信号交叉验证
  - 检查反馈样本分布
  - 避免直接将用户偏好等同于正确性
Degenerate Feedback Loop（恶性反馈循环）
- 是什么
  - 系统输出影响用户反馈，而反馈又影响下一轮系统输出，导致初始偏差持续放大
- 实现机制
  - 某内容被优先展示
  - 获得更多曝光和互动
  - 系统认为该内容更受欢迎
  - 继续提高其优先级
  - 形成自我强化循环
- 可能造成的问题
  - 曝光偏差
  - 流行度偏差
  - 信息茧房
  - 数据分布越来越单一
  - 模型原有偏见被放大
- Sycophancy（迎合行为）
  - 是什么
    - 模型为了获得用户认可而倾向迎合用户观点
  - 风险
    - 用户偏好提高
    - 但事实正确性可能下降
- 核心原则
  - 用户反馈不应成为唯一优化目标
  - 需要结合客观正确性和业务约束

5. 如何评估

评估思想
- 复用第4章的评估方法论
- 从模型级评估扩展到整个应用系统
- 离线评估与在线监控相结合
评估维度
- 功能正确性
  - 任务成功率
  - 格式正确率
- 生成质量
  - 回答正确性
  - 事实一致性
  - 相关性
- 安全性
  - 风险检出率
  - 误拒率
- 可靠性
  - 请求失败率
  - 重试率
- 性能
  - TTFT
  - TPOT
  - 总响应时间
- 成本
  - Token消耗
  - 单次任务成本
- 用户体验
  - 用户满意度
  - 重新生成率
  - 用户纠错率
- 可观测性
  - MTTD
  - MTTR
- 业务价值
  - DAU
  - 转化率
  - 订阅量
评估方式
- 离线评估
  - 是什么
    - 使用预先准备的数据对系统进行测试
  - 适用场景
    - 开发验证
    - 版本回归
    - 方案比较
  - 评估内容
    - 模型质量
    - RAG检索质量
    - Agent任务成功率
    - 输出格式
    - 安全约束
- 在线评估与监控
  - 是什么
    - 利用真实生产环境中的数据观察系统表现
  - 数据来源
    - Metrics
    - Logs
    - Traces
    - User Feedback
    - 必要时使用AI评分器
  - 主要目标
    - 发现生产环境故障
    - 监控模型质量
    - 识别输入和用户行为变化
    - 发现优化机会
- 注意
  - 可观测性提供运行数据和问题定位能力
  - 指标正常不代表任务一定成功
  - 回答正确性仍需要合适的评分机制
评估与优化闭环
- 收集评估数据
- 执行评估
- 分析整体指标
- 分析失败案例
- 定位问题
- 提出改进方案
- 实施改进
- 重新评估
- 将生产失败案例加入评估数据集