监控能识别出大语言模型 (LLM)性能何时下降或表现出不期望的行为，例如延迟增加、漂移或输出质量差。然而，仅靠监控通常无法提供解决这些问题所需的具体数据。构建系统化的反馈循环对于直接从模型在生产环境中的使用中收集可操作的信息非常重要，这使得通过微调 (fine-tuning)、提示更新或重新训练等有针对性的干预措施来实现持续改进。
“反馈循环建立了一种结构化的流程，用于捕获关于大语言模型性能的信息，并将这些信息回馈到开发和操作生命周期中。与一般应用程序反馈不同，大语言模型反馈通常需要更细致，捕捉特定提示、生成响应和用户交互的细节。”
设计反馈收集机制
有效的反馈循环始于直接集成到使用大语言模型 (LLM)的应用程序或系统中的收集机制。机制的选择取决于应用程序场景、用户交互模型以及所需信息的类型。
显式反馈
这涉及直接要求用户或评审者提供关于大语言模型输出的意见。常用方法包括：
- 评分： 简单的点赞/点踩、星级评分或与特定响应相关的数值分数。这很容易收集，但提供的信息有限。
- 类别标签： 允许用户选择预定义的表示不满的原因（例如，“不正确”、“无用”、“不安全”、“离题”）。这比简单的评分提供了更有结构的信息。
- 修正： 允许用户编辑模型响应以提供更好的替代方案。这能产生适合监督式微调 (fine-tuning)的高质量数据，但需要用户付出更多精力。
- 自由评论： 用户可以通过文本框解释问题或提供背景信息。这提供了丰富的定性数据，但处理和分析需要大量精力，通常涉及自然语言处理技术或人工审核。
实施显式反馈通常涉及在应用程序界面中添加用户界面元素，并设计后端API来接收和存储这些结构化数据，确保其与特定提示、响应、模型版本和用户上下文 (context)（如果适用且允许）相关联。
隐式反馈
隐式反馈依赖于观察用户行为作为满意度或任务成功的替代指标。它不那么直接，但可以被动地大规模收集。例子包括：
- 用户参与度指标： 跟踪用户是否复制了生成的文本、点击了响应中的链接，或花费大量时间与输出进行交互。
- 任务完成情况： 衡量用户是否在与大语言模型交互后成功完成下游任务（例如，进行购买、查找信息）。
- 会话放弃： 注意用户是否经常放弃会话，或在收到响应后立即重新提问。
解释隐式信号需要谨慎。用户复制文本可能表示满意，或者他们可能是为了报告错误而复制。因此，隐式信号通常在汇总分析或与其他指标关联分析时最有价值。收集通常涉及对应用程序日志进行插桩以捕获相关的用户交互事件。
自动化反馈与评估
自动化系统可以根据预定义的规则或其他模型提供反馈，而不是仅仅依靠人类用户：
- 基于规则的检查： 应用启发式方法或正则表达式来标记 (token)包含敏感信息（PII）、有害语言（使用预定义黑名单）或格式错误的输出。
- 基于模型的评估： 使用专门的较小模型（例如，毒性分类器、事实核查模型）对大语言模型的输出进行评分或分类。甚至可以利用另一个有能力的大语言模型作为评估器，提示它评估主模型响应的质量、相关性或安全性，尽管这会产生额外成本并引入潜在的评估器偏差。
自动化反馈能根据特定标准提供一致、可扩展的评估，但可能会遗漏人工评审员能发现的细节。
人工在环 (HITL) 审核
对于复杂或敏感的应用程序，通常需要专门的人工审核流程。这涉及将部分交互（例如，低评分响应、自动化检查标记的输出、随机样本）路由给经过培训的标注者或领域专家。
人工在环工作流程，通常通过数据标注平台管理，提供高质量、详细的反馈。这对于以下方面特别有价值：
- 理解模型不明显的故障模式。
- 生成高质量数据，用于对复杂指令或边缘情况进行微调。
- 分析比较不同模型或提示的A/B测试结果。
- 确保合规性和安全标准。
人工在环通常是最昂贵的反馈机制，需要对采样策略和标注指南进行仔细规划。
构建反馈管道
一个正常工作的反馈系统不仅需要收集点。它还需要用于存储、处理和触发操作的基础设施。
- 数据摄取与存储： 反馈数据以及相关的元数据（请求ID、时间戳、模型版本、提示、响应、用户ID（如果适用）、反馈类型、反馈内容）需要可靠地摄取和存储。选择能够高效查询并将反馈与原始交互关联起来的存储解决方案（例如，数据库、数据仓库、数据湖）。维护这种关联对分析而言非常重要。
- 处理与分析： 原始反馈通常需要处理。这可能涉及清理自由文本评论、规范化评分、聚合隐式信号，或从人工在环工作流程中结构化标注。分析仪表板可以可视化反馈趋势，突出显示有问题的交互模式，并识别性能不佳的数据切片。
- 行动与集成： 经过处理的反馈必须在LLMOps生命周期内触发适当的操作。这涉及将反馈系统与其他MLOps组件集成：
- 警报： 通知运营团队突然出现的大量负面反馈或安全标记 (token)。
- 数据整理： 自动过滤和格式化反馈数据（例如，用户修正、高质量审核示例），成为适合微调 (fine-tuning)的数据集。
- 管道触发： 当收集到足够的反馈数据时，或当性能指标根据反馈分析突破预设阈值时，启动自动化微调或重新训练管道。
- 实验系统： 使用反馈评估在A/B测试中不同模型或提示的性能。
以下图表展示了一个典型的反馈循环架构：
一个典型的流程是用户交互产生反馈，这些反馈被收集、存储、处理，并用于触发模型更新或警报等操作。
利用反馈改进模型
收集并处理的反馈直接推动持续改进循环：
- 有针对性的微调 (fine-tuning)： 显式修正和高质量的人工在环示例可以被整理成数据集，用于监督式微调（SFT）或用于像人类反馈强化学习 (reinforcement learning)（RLHF）或直接偏好优化（DPO）等技术偏好数据集。这使得模型可以从其在生产环境中的特定错误中学习。
- 提示优化： 分析与不同提示或提示模板相关的反馈，可以显示哪些结构导致更好或更差的结果。这为提示工程 (prompt engineering)工作提供了依据，并允许对生产中使用的提示进行迭代改进。
- RAG系统增强： 如果使用检索增强生成 (RAG)，表明检索到的信息不相关或过时的反馈可以触发矢量数据库索引的更新、优化嵌入 (embedding)模型或调整检索策略。
- 识别再训练需求： 针对不同输入持续出现负面反馈，或表明微调无法解决的漂移反馈，表明需要进行更全面的再训练，可能是使用更新的数据集或进行架构更改。
- 改进自动化防护： 关于不安全或不期望输出的反馈有助于改进自动化监控规则和分类器，使它们在捕获有问题的内容方面更有效。
操作考量
实施反馈循环带来了操作复杂性：
- 可扩展性： 反馈收集和处理系统必须处理生产流量产生的交互量。
- 成本： 显式反馈需要用户付出精力，而人工在环会产生直接的标注成本。使用模型进行自动化评估也会增加计算开销。平衡反馈的质量、数量和成本非常重要。
- 延迟： 反馈能多快被处理并采取行动？对于重要的安全问题可能需要实时反馈，而用于微调 (fine-tuning)的数据可能以批次处理。
- 偏差： 反馈可能无法代表所有用户或使用场景。提供反馈的用户可能不成比例地是那些有过负面体验的用户。采样策略（随机采样、基于不确定性的采样或基于错误的采样）可以帮助缓解这种情况，但在分析时应始终考虑潜在的偏差。
- 隐私： 处理用户反馈，尤其是自由文本或行为数据，需要仔细考虑数据隐私法规和匿名化技术。
构建有效的反馈循环将监控从被动观察活动转变为模型改进的主动推动力。通过系统地收集、处理和对大语言模型 (LLM)在实际中如何表现的信息采取行动，您可以确保其在整个操作生命周期中持续的有效性、安全性以及与用户需求的保持一致。
